LINUX.ORG.RU

Существуют.

Например, гомоиконность.

anonymous
()

Очевидно, что на них проще метапрограммировать.

buddhist ★★★★★
()

Теоретически, нет. Можно написать

AST foo = quote { тут какой-то совсем некрасивый код с кучей сахара };
тут работаем с AST
возвращаем AST если это макрос
или делаем
result = eval(foo);

главное чтобы был quote от синтаксического блока возвращающий структуру данных типа AST (дерево, в том числе и более сложное чем в случае s-выражений) с которой можно работать - возвращать из макросов или отдавать eval. Достигается то же самое что и с гомоиконичностью. Какие остаются преимущества? Только то, что проще печатать и разбирать (но если уже есть готовые read и print в стандартной библиотеке - какая разница), плюс эстетические (но это дело вкуса).

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

Теоретически, нет.

В том же смысле, в котором теоретически ни у какого ЯП нету преимуществ перед брейнфаком. То есть мы можем, конечно:

чтобы был quote от синтаксического блока возвращающий структуру данных типа AST (дерево, в том числе и более сложное чем в случае s-выражений) с которой можно работать - возвращать из макросов или отдавать eval. Достигается то же самое что и с гомоиконичностью.

но с гомоиконностью это будет легко, удобно и естественно, а без гомоиконности - сложно, неудобно и костыльно. В общем, удобная и практичная система метапрограммирования невозможна без гомоиконности.

anonymous
()
Ответ на: комментарий от anonymous

но с гомоиконностью это будет легко, удобно и естественно, а без гомоиконности - сложно, неудобно и костыльно.

А какое вообще точное определение у гомоиконности?

Например, можно ли считать Dylan, Nemerle или Julia гомоиконными?

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

А какое вообще точное определение у гомоиконности?

Гомоиконность - это когда код является представлением АСТ. Дело в общем даже и не столько в самой гомоиконности, сколько в том, что в гомоиконных языках структура АСТ вынужденно тривиальна, потому что программист сразу пишет код в виде этого АСТ (ну а тривиальность АСТ резко упрощает его парсинг и генерацию). То есть мы могли бы поменять хаскель так, чтобы вместо обычного кода писать то, что выблевывает из-под сплайса TH (с конструкторами для всех частей АСТ). Тогда хаскель был бы гомоиконным, но никто бы на нем ничего не писал.

можно ли считать Dylan, Nemerle или Julia гомоиконными?

Нет, нельзя. Я вообще не могу представить себе гомоиконного синтаксиса, который неизоморфен лиспу, форту или машкоду.

anonymous
()
Ответ на: комментарий от anonymous

Я вообще не могу представить себе гомоиконного синтаксиса, который неизоморфен лиспу, форту или машкоду.

В википедии несколько более широкий список приведён. У Julia прямо в документации утверждается что она гомоиконна.

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

В википедии несколько более широкий список приведён.

Ну там используется несколько другое определение:

In computer programming, homoiconicity is a property of some programming languages, in which the primary representation of programs is also a data structure in a primitive type of the language itself

Согласно этому определению любой ЯП является гомоиконным, т.к. всегда можно ввести структуру, представляющую АСТ и потом объявить ее примитивной.

У Julia прямо в документации утверждается что она гомоиконна.

Ну ради бога, пусть утверждается.

anonymous
()
Ответ на: комментарий от dave

Все равно до лиспа как до китая раком.

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

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

Есть еще Nemerle. Попытка, конечно, но опять же совсем не лисп.

Мне кажется, что в смысле макросов лисп просто идеален. У меня к нему только одна претензия. В качестве базиса выбрано такое множество особых операторов (примитивов лиспа), которое не поддается монадическому преобразованию подобному тому, что происходит при использовании «вычислительных выражений» в F#. Зато почти все из этих операторов поддаются преобразованию CPS (пакет cl-cont), что во многом окупает предыдущий недостаток.

Другими словами, я бы выбрал несколько иной базис из особых операторов, до которых раскладывается любая форма на лиспе. В остальном придумано все замечательно, и нет ничего подобного в других известных мне языках.

dave ★★★★★
()
Ответ на: комментарий от dave

Есть еще Nemerle.

у него критичный недостаток для развитого метапрограммирования - статическая типизация. В этом случае правильные макросы должны предоставлять апи к тайпчекеру по крайней мере достаточное, для задания произвольных семантических правил и взаимодействия с типовым контекстом, но это гарантирует возможность сломать тайпчекер, так что ЯП перестает быть статически типизированным де-факто, а типизация становится просто набором макросов.

anonymous
()
Ответ на: комментарий от anonymous

В Nemerle макросы надо определять в отдельных единицах компиляции...

dave ★★★★★
()
Ответ на: комментарий от dave

в смысле макросов лисп просто идеален

Не знаю, что там в CL, но в Scheme макросы — это начищенные до блеска костыли.

buddhist ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.