Здравствуйте, thesz, Вы писали:

T>И это никак не лечится путём переписывания и оптимизаций?..

А как переписывать, если структура нам заранее не известна? Насчёт оптимизаций — не могу такую придумать.

T>Можно, вообще, представить алгоритм, который оптимизирует SYB код до кода ast:visit? Разворачиванием словарей классов, например.

Не понял идею.

Смысл в том, что если есть структура, скажем

data Base = Base ... [Sub] ...

data Sub = Sub ... someField :: SubSub ...

data SubSub = SS Int

и мы хотим сделать например

gmap (\SubSub i -> SubSub (i + 1)) base

то это должно развернуться в

gmapBase (Base ... subs ...) = Base{subs = gmapList subs}
gmapList = map gmapSub -- лень писать
gmapSub Sub{someField} = Sub{someField = gmapSubSub someField}
gmapSubSub (SubSub i) = SubSub (i + 1)

Зная структуру заранее, т.е. во время компиляции, мы это можем сделать. gmap же (SYB) работает runtime.

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, thesz, Вы писали:

T>>И это никак не лечится путём переписывания и оптимизаций?..

L>А как переписывать, если структура нам заранее не известна? Насчёт оптимизаций — не могу такую придумать.

T>>Можно, вообще, представить алгоритм, который оптимизирует SYB код до кода ast:visit? Разворачиванием словарей классов, например.

L>Не понял идею.

L>Смысл в том, что если есть структура, скажем

L>

L>data Base = Base ... [Sub] ...

L>data Sub = Sub ... someField :: SubSub ...

L>data SubSub = SS Int
L>

L>и мы хотим сделать например

L>

L>gmap (\SubSub i -> SubSub (i + 1)) base
L>

L>то это должно развернуться в

L>

L>gmapBase (Base ... subs ...) = Base{subs = gmapList subs}
L>gmapList = map gmapSub -- лень писать
L>gmapSub Sub{someField} = Sub{someField = gmapSubSub someField}
L>gmapSubSub (SubSub i) = SubSub (i + 1)
L>

L>Зная структуру заранее, т.е. во время компиляции, мы это можем сделать. gmap же (SYB) работает runtime.

Как же лиспу удаётся знать структуру заранее? Знает ли компилятор Хаскеля ту же структуру заранее?

Я думаю, что компилятор Хаскеля всё это знает. Единственное, что остаётся, это реализовать это знание.

Это возможно сделать вот, как: зная тип, к которому мы собираемся применить gmap (\SubSub i -> SubSub (i + 1)) base, мы можем вычислить, какие поля каких вариантов этого типа могут иметь не провальное применение gmap. Вроде, для не полиморфных типов это не очень сложно — если поле типа, содержащего SubSub, то успех, если поле примитивного типа, отличного от типа SubSub, то применение будет провальным всегда, если тип составной, то провальность применения определяется рекурсией, что мы только что описали.

Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.

Здравствуйте, thesz, Вы писали:

T>Это возможно сделать вот, как: зная тип, к которому мы собираемся применить gmap (\SubSub i -> SubSub (i + 1)) base, мы можем вычислить, какие поля каких вариантов этого типа могут иметь не провальное применение gmap. Вроде, для не полиморфных типов это не очень сложно — если поле типа, содержащего SubSub, то успех, если поле примитивного типа, отличного от типа SubSub, то применение будет провальным всегда, если тип составной, то провальность применения определяется рекурсией, что мы только что описали.

Только после следующей фразы понял, что ты говоришь про оптимизацию

T>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.

Не аргумент. Во всяких Generic Haskell такую функцию написать можно. Оптимизации нет, потому что уж очень она специфичная — для конкретной функции, уж не проще ли функцию тогда реализовать на TH, или, возможно, на Generic Type Classes.

Здравствуйте, lomeo, Вы писали:

L>Здравствуйте, thesz, Вы писали:

T>>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.
L>Не аргумент. Во всяких Generic Haskell такую функцию написать можно.

А много ли народу пишет?

L>Оптимизации нет, потому что уж очень она специфичная — для конкретной функции, уж не проще ли функцию тогда реализовать на TH, или, возможно, на Generic Type Classes.

О!

Кстати.

Спасибо.

Здравствуйте, D. Mon, Вы писали:

DM>Кто и когда?

Программа при запуске.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, thesz, Вы писали:

А> Альтернативный вариант — Template Haskell. Но у него свои сложности и ограничения есть. И я не уверен, что там всё в порядке с интроспекцией определений типов — давно в последний раз с ним играл.

T>>Я не очень понимаю на словах.
T>>Нельзя ли кода кусочек?
А> Ок, завтра пришлю простенький Лисп, сделанный на TH.

То "завтра" было позавчера или даже раньше, поэтому осторожно поинтересуюсь прогрессом.

Не готов ли простенький Лисп поверх TH?

Здравствуйте, thesz, Вы писали:

T>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, thesz, Вы писали:

TBG>>>>А как сам где-то в этой теме говоришь: "Ценность этого действа сильно преувеличена".

T>>>Я говорю, что ценность метапрограммирования преувеличена.

А>> Qi — по сути, расширение Лиспа. Да и Axiom тоже. И в Qi, и в Qi II, и в Axiom зависимые типы присутствуют.

T>Я, как-то, спровоцировал войну в ru_lisp в ЖЖ.

T>Узнал много нового, например, что пользователю Qi удалось доказать, что 42 имеет тип "строка". Плюс, как выяснилось, никто из пользователей Lisp, присутствующих в ru_lisp, не использует Qi в своей работе.

Дак даж автор Qi уходит

Здравствуйте, thesz, Вы писали:

T>>>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.
L>>Не аргумент. Во всяких Generic Haskell такую функцию написать можно.
T>А много ли народу пишет?

Не знаю. Но то, что в SYB неэффективное решение — я вижу.

Вот одно из решений — Alloy: Fast Generic Transformations for Haskell. Вместо использования дорогого на каждом шаге cast, там втупую генерятся экземпляры класса типов (аналогично строкам функции (по ПМ) в моём примере, по экземпляру на строку). Если поменять на генерацию строк, должно быть ещё быстрее.

Важно, что это возможно. А сколько народу пишет — неважно, да и не знаю я.

Ещё подумал — undecideable instances ведь тоже можно использовать в качестве generic programming. Ведь это тоже форма генерации экземпляров. Но это так — мысли в сторону.

Здравствуйте, thesz, Вы писали:

А>> Ок, завтра пришлю простенький Лисп, сделанный на TH.

T>То "завтра" было позавчера или даже раньше, поэтому осторожно поинтересуюсь прогрессом.

Опачки, склероз!

T>Не готов ли простенький Лисп поверх TH?

http://pastebin.com/f4ee79fd7

Что-то там хреново работает раскраска синтаксиса. Ну да ладно, фигня.

В общем, я пока только одного придумать не могу — как defmacro реализовать (и связанная с этим задача — глобальные определения констант). Протащить контекст между top level expressions в TH нельзя, а уж тем более между модулями. Нужен какой-то грязный хак.

Здравствуйте, thesz, Вы писали:

L>>Зная структуру заранее, т.е. во время компиляции, мы это можем сделать. gmap же (SYB) работает runtime.

T> Как же лиспу удаётся знать структуру заранее?

Определения типов есть, конкретный визитор есть — остальное выводится.

T> Знает ли компилятор Хаскеля ту же структуру заранее?

Знать то он знает, да только вклиниться из Template Haskell в compilation pipeline не дадут, информацию о типах не дадут, да даже определения посмотреть не позволят. Никакой рефлексии. А без reflection метапрограммирование убого и ограниченно.

T>Я думаю, что компилятор Хаскеля всё это знает. Единственное, что остаётся, это реализовать это знание.

Внутри компилятора — запросто. Сторонней библиотекой — фигушки.

T>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.

Лисповодам вон нужно же. О скорости заботятся.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, thesz, Вы писали:

T>>Узнал много нового, например, что пользователю Qi удалось доказать, что 42 имеет тип "строка". Плюс, как выяснилось, никто из пользователей Lisp, присутствующих в ru_lisp, не использует Qi в своей работе.
К>Дак даж автор Qi уходит

Я старался не приводить этот аргумент. Я подумал, что это удар ниже пояса.

Здравствуйте, Аноним, Вы писали:

T>> Знает ли компилятор Хаскеля ту же структуру заранее?
А> Знать то он знает, да только вклиниться из Template Haskell в compilation pipeline не дадут, информацию о типах не дадут

И даже reify не поможет?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, thesz, Вы писали:

L>>>Зная структуру заранее, т.е. во время компиляции, мы это можем сделать. gmap же (SYB) работает runtime.
T>> Как же лиспу удаётся знать структуру заранее?
А> Определения типов есть, конкретный визитор есть — остальное выводится.

Наверное, то же самое можно сделать и в Хаскеле?

Или нет?

T>> Знает ли компилятор Хаскеля ту же структуру заранее?
А> Знать то он знает, да только вклиниться из Template Haskell в compilation pipeline не дадут,

rewrite rules

GHC plugins (будущее)

А>информацию о типах не дадут,

reify

A>да даже определения посмотреть не позволят.

(a,b) = something

Чему равен a?

Just a = anotherthing

Чему равен a?

А>Никакой рефлексии. А без reflection метапрограммирование убого и ограниченно.

Что Брукс писал про метапрограммирование?

T>>Я думаю, что компилятор Хаскеля всё это знает. Единственное, что остаётся, это реализовать это знание.
А> Внутри компилятора — запросто. Сторонней библиотекой — фигушки.

Плагины к GHC. Оформляются в виде сторонних библиотек.

T>>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.
А> Лисповодам вон нужно же. О скорости заботятся.

Они простые задачи решают. Поэтому и стараются выиграть в скорости, просто для того, чтобы в хоть в чём-то выиграть.

Здравствуйте, lomeo, Вы писали:

T>>> Знает ли компилятор Хаскеля ту же структуру заранее?
А>> Знать то он знает, да только вклиниться из Template Haskell в compilation pipeline не дадут, информацию о типах не дадут

L>И даже reify не поможет?

Только в некоторых ограниченных случаях, похоже.

Здравствуйте, lomeo, Вы писали:

L>И даже reify не поможет?

А вообще я похоже зря гоню. Почему-то считал, что он хреново работает с определениями из других модулей. Проверил — таки нормально работает. Тогда, возможно, такое и на TH сделать получится.

Здравствуйте, thesz, Вы писали:

T>Наверное, то же самое можно сделать и в Хаскеле?

Можно. Но сложно.

T>GHC plugins (будущее)

Отдалённое. А работать сейчас надо.

А>>информацию о типах не дадут,

T>reify

Уже понял, что зря на него гнал. С ним раньше проблемы были, но похоже уже всё исправили.

A>>да даже определения посмотреть не позволят.

T>(a,b) = something

T>Чему равен a?

T>Just a = anotherthing

T>Чему равен a?

Я про глобальные определения говорю.

А>>Никакой рефлексии. А без reflection метапрограммирование убого и ограниченно.

T>Что Брукс писал про метапрограммирование?

Мне наплевать на мнение Брукса по этому поводу.

T>>>Я думаю, что компилятор Хаскеля всё это знает. Единственное, что остаётся, это реализовать это знание.
А>> Внутри компилятора — запросто. Сторонней библиотекой — фигушки.

T>Плагины к GHC. Оформляются в виде сторонних библиотек.

Когда ещё я этим смогу на практике воспользоваться...

T>>>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.
А>> Лисповодам вон нужно же. О скорости заботятся.

T>Они простые задачи решают.

Именно. Компиляторы — это очень, очень просто. Не надо усложнять то, что можно сделать легко и непринуждённо.

T> Поэтому и стараются выиграть в скорости, просто для того, чтобы в хоть в чём-то выиграть.

В скорости разработки и читабельности кода тоже одни только выигрыши в конкретно этой задаче (компиляторы).

Здравствуйте, Аноним, Вы писали:

L>>И даже reify не поможет?
А> А вообще я похоже зря гоню. Почему-то считал, что он хреново работает с определениями из других модулей. Проверил — таки нормально работает. Тогда, возможно, такое и на TH сделать получится.

Угу, получится. Внешний вид будет, конечно, не такой красивый, как при прямом вызове функции.

Здравствуйте, Аноним, Вы писали:

T>>(a,b) = something
T>>Чему равен a?
T>>Just a = anotherthing
T>>Чему равен a?
А> Я про глобальные определения говорю.

А это глобальные, так тоже можно

T>>Плагины к GHC. Оформляются в виде сторонних библиотек.
А> Когда ещё я этим смогу на практике воспользоваться...

К сожалению, документация по потрохам GHC для написания этих плагинов очень слабая.

T>>>>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.
А>>> Лисповодам вон нужно же. О скорости заботятся.
T>>Они простые задачи решают.
А> Именно. Компиляторы — это очень, очень просто. Не надо усложнять то, что можно сделать легко и непринуждённо.

T>> Поэтому и стараются выиграть в скорости, просто для того, чтобы в хоть в чём-то выиграть.
А> В скорости разработки и читабельности кода тоже одни только выигрыши в конкретно этой задаче (компиляторы).

(жую попкорн, вылупив зенки)...

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, thesz, Вы писали:

T>>Наверное, то же самое можно сделать и в Хаскеле?

А> Можно. Но сложно.
T>>GHC plugins (будущее)
А> Отдалённое. А работать сейчас надо.

Сейчас можно и без метапрограммирования.

Типы (особенно, ассоциированные) рулят.

A>>>да даже определения посмотреть не позволят.
T>>(a,b) = something
T>>Чему равен a?
T>>Just a = anotherthing
T>>Чему равен a?
А> Я про глобальные определения говорю.

Это и есть "глобальные определения".

(a,b) = findGoodPair [пары]

А>>>Никакой рефлексии. А без reflection метапрограммирование убого и ограниченно.
T>>Что Брукс писал про метапрограммирование?
А> Мне наплевать на мнение Брукса по этому поводу.

О!

А что по этому поводу писал МакКарти?

T>>>>Я думаю, что компилятор Хаскеля всё это знает. Единственное, что остаётся, это реализовать это знание.
А>>> Внутри компилятора — запросто. Сторонней библиотекой — фигушки.
T>>Плагины к GHC. Оформляются в виде сторонних библиотек.
А> Когда ещё я этим смогу на практике воспользоваться...

Своевременно, или несколько позже.

T>>>>Видимо, это никому особенно не нужно, проводить такие оптимизации. Вот их и нет.
А>>> Лисповодам вон нужно же. О скорости заботятся.
T>>Они простые задачи решают.
А> Именно. Компиляторы — это очень, очень просто.

Да, если есть типы.

Я уже приводил пример с преобразованием (AST (WHERE ::: LET)).

То же можно сделать и для SSA, устранив некоторые операции.

А> Не надо усложнять то, что можно сделать легко и непринуждённо.

Именно! Именно!

Поэтому не стоит приплетать оптимизацию по скорости там, где нужна точная логика.

T>> Поэтому и стараются выиграть в скорости, просто для того, чтобы в хоть в чём-то выиграть.
А> В скорости разработки и читабельности кода тоже одни только выигрыши в конкретно этой задаче (компиляторы).

Это желательно бы подтвердить.

Компилятор чего ты разрабатывал последнее время?

Я — VHDL, например. Практически синтезатор большого его подмножества.

Два месяца работы вместе с рантаймом.

Здравствуйте, Аноним, Вы писали:

DM>>Кто и когда?

А>Программа при запуске.

Или не так запускаете (правильный способ выше приведен), или какой-то странный у вас компилятор С++ (это если без оптимизаций не падает, а с ними падает).