AT
Чисто для справки: Ruby/Groovy/Kotlin-style билдеры попадают в категорию цепочек методов ООП?
Size: a a a
2020 April 19
PS
Отражение (рефлексия, reflection) куда встанет в списке? или, оно не важно?
Недавно я вспоминал тот же модуль ast в Питоне — вещь хорошая, но сама по себе недостаточная. Это как в Форте — все можно расширить, но сделать это придется руками :)
AT
Недавно я вспоминал тот же модуль ast в Питоне — вещь хорошая, но сама по себе недостаточная. Это как в Форте — все можно расширить, но сделать это придется руками :)
Справедливости ради, reflection, в отличие от AST, скорее семантический механизм, чем синтаксический...
PS
Тогда почему комбинаторы попали в выразительные средства языка вместо ФВП???
Я просто делаю акцент на особенном использовании ФВП. Хорошо, добавлю информацию во избежание :)
PS
Чисто для справки: Ruby/Groovy/Kotlin-style билдеры попадают в категорию цепочек методов ООП?
Думаю, да. Хотелось бы это назвать каким-то общим термином :)
AG
Ну Вы же помните, как было сделано в учебнике Аппеля? А еще можно, все-таки, ввести новый вариант IR, но сделать это изящно, без многословия, то есть как в Nanopass :)
у аппеля подход, который дальше в кок уехал - условные рефайнменты, т.е. доказательства таскаем не в индуктивном виде, а предикатом
r
Думаю, да. Хотелось бы это назвать каким-то общим термином :)
В XPath есть arrow operator, который работает для функций, передавая первый аргумент неявно.
Вложенный вызов
Можно записать в виде
Вложенный вызов
tokenize((normalize-unicode(upper-case($string))),"\s+")
Можно записать в виде
$string => upper-case() => normalize-unicode() => tokenize("\s+")AG
оно чем-то удобно, но по факту это просто следствие из ограничений системы типов :)
AG
Ну вот. А ведь я уже не первый год в этом чате пишу про Nanopass! Важное замечание — далеко не все полезное для практики компиляторописания выводится непосредственно из лямбда-исчисления или, скажем, теории категорий ;)
https://github.com/nanopass/nanopass-framework-scheme/blob/master/doc/user-guide.pdf
https://github.com/nanopass/nanopass-framework-scheme/blob/master/doc/user-guide.pdf
макросы в общем, понятно
AG
Ну вот. А ведь я уже не первый год в этом чате пишу про Nanopass! Важное замечание — далеко не все полезное для практики компиляторописания выводится непосредственно из лямбда-исчисления или, скажем, теории категорий ;)
https://github.com/nanopass/nanopass-framework-scheme/blob/master/doc/user-guide.pdf
https://github.com/nanopass/nanopass-framework-scheme/blob/master/doc/user-guide.pdf
моя текущая гипотеза что практически вся основная база для компиляторов выводится из теории доказательств и теории моделей :)
ЗП
моя текущая гипотеза что практически вся основная база для компиляторов выводится из теории доказательств и теории моделей :)
как?
AG
синтаксическими и семантическими преобразованиями формальных систем, соответствующих IR :)
ЗП
синтаксическими и семантическими преобразованиями формальных систем, соответствующих IR :)
а есть про это где-то?
AG
ну я же тут уже кидал статьи про исчисления секвенций
AG
в едином виде думаю нигде нет, потому что это моя гипотеза
AG
парсинг тоже можно денсем-техниками организовывать, см https://www.cl.cam.ac.uk/~nk480/parsing.pdf
PS
макросы в общем, понятно
Эх... ;)
AG
скажете я неправ? :)
PS
скажете я неправ? :)
В каком-то смысле это действительно отличная замена заурядным макросам из того же лиспа. Но с точки зрения компиляторщика это очень удобный метаязык. И, кстати говоря, корректность там обеспечивается на уровне спецификаций.
PS
Я просто и так уже пишу здесь многословно — мне кажется, в документе вполне подробно описаны все уникальные черты Nanopass.