ML
Паттерн матчинг - это антиинкапсуляция
Size: a a a
2020 October 10
AB
Dmitry Ponyatov
где можно почитать по реализации интерпретатора объектного языка поверх BEAM/Erlang ?
define объектный язык, для начала
AB
Даже можно с совсем простого начать - чего не хватает в жрланге?
AB
Dmitry Ponyatov
хотя казалось бы pattern matching для этого идеальная фича
Зачем самому, если уже есть родной для ерланга leex/yecc
http://erlang.org/doc/man/leex.html
http://erlang.org/doc/man/yecc.html
Причем, парсер LALR-1. А не LL1 как у некоторых (например Python вроде такой имел, еще LL1 и стейта достаточно для Паскаля, оберона).
leex/yecc вполне нормально может разбирать. Там только на настройку правил инструмента уйдет куча времени. Это явно меньше, чем на создание инструмента самому и его настройку. К тому же, после получения дерева будет еще куча работы. Зачем себе жизнь усложнять? У меня есть примеры, где люди на этом встряли и так дальше парсера не ушли.
http://erlang.org/doc/man/leex.html
http://erlang.org/doc/man/yecc.html
Причем, парсер LALR-1. А не LL1 как у некоторых (например Python вроде такой имел, еще LL1 и стейта достаточно для Паскаля, оберона).
leex/yecc вполне нормально может разбирать. Там только на настройку правил инструмента уйдет куча времени. Это явно меньше, чем на создание инструмента самому и его настройку. К тому же, после получения дерева будет еще куча работы. Зачем себе жизнь усложнять? У меня есть примеры, где люди на этом встряли и так дальше парсера не ушли.
PG
У эликсира есть nimble_parsec, это комбинаторный парсер который компилируется в матчинг бинарей
ML
Зачем самому, если уже есть родной для ерланга leex/yecc
http://erlang.org/doc/man/leex.html
http://erlang.org/doc/man/yecc.html
Причем, парсер LALR-1. А не LL1 как у некоторых (например Python вроде такой имел, еще LL1 и стейта достаточно для Паскаля, оберона).
leex/yecc вполне нормально может разбирать. Там только на настройку правил инструмента уйдет куча времени. Это явно меньше, чем на создание инструмента самому и его настройку. К тому же, после получения дерева будет еще куча работы. Зачем себе жизнь усложнять? У меня есть примеры, где люди на этом встряли и так дальше парсера не ушли.
http://erlang.org/doc/man/leex.html
http://erlang.org/doc/man/yecc.html
Причем, парсер LALR-1. А не LL1 как у некоторых (например Python вроде такой имел, еще LL1 и стейта достаточно для Паскаля, оберона).
leex/yecc вполне нормально может разбирать. Там только на настройку правил инструмента уйдет куча времени. Это явно меньше, чем на создание инструмента самому и его настройку. К тому же, после получения дерева будет еще куча работы. Зачем себе жизнь усложнять? У меня есть примеры, где люди на этом встряли и так дальше парсера не ушли.
Знаешь, это очень сомнительный тезис на тему того, что lex/yacc лучше чем руками.
Я трижды писал парсер нашего конфига и та часть, которую якобы упрощает лекс, пишется за несколько часов.
Я трижды писал парсер нашего конфига и та часть, которую якобы упрощает лекс, пишется за несколько часов.
ML
А потом ты пишешь валидации, трансформации и тп
AB
Ну. На эликсире лексер вроде бы свой, а не leex. Если ничего не путаю.
AB
Знаешь, это очень сомнительный тезис на тему того, что lex/yacc лучше чем руками.
Я трижды писал парсер нашего конфига и та часть, которую якобы упрощает лекс, пишется за несколько часов.
Я трижды писал парсер нашего конфига и та часть, которую якобы упрощает лекс, пишется за несколько часов.
но ты же понимаешь, что все от задачи идет. Кто-то тут недавно калькулятор писал. С одной стороны было бы проще. А с другой стороны, там какая-то запара произошла и результат был не тот, что нужно
PG
Ну. На эликсире лексер вроде бы свой, а не leex. Если ничего не путаю.
nimble_parsec это библиотека от кор тимы, чем эликсир разбирается я не в курсе
AB
nimble_parsec это библиотека от кор тимы, чем эликсир разбирается я не в курсе
мне показалось, кто-то писал что-то вообще свое
VS
nimble_parsec - это большой привет аппликативным парсерам, для малого удобен, для чего то очень серьезного не применим
в силу того, что кунг-фу на
аплликативных функторах
требует их поддержки, а
имитация быстро усложняет
реализацию
в силу того, что кунг-фу на
аплликативных функторах
требует их поддержки, а
имитация быстро усложняет
реализацию
PG
Для чего-то сложного проще взять lex/yacc
ML
паттерн матчинг помогает офигительно удобно и легко делать заглядывающие вперед парсеры
D
Dmitry Ponyatov
как то странно гугл работает — перебираю слова, и нечего про разработку компиляторов/интерпретаторов на Erlang не вываливается
Github держись а не Гугла.
Trust sources, Luke ))
Я Datalog там вчера-позавчера нашел.
В работе его пока правда не пробовал, но собирается легко
Реализации Prolog, Lisp видел на ерланге там, то что с ходу вспоминается
Trust sources, Luke ))
Я Datalog там вчера-позавчера нашел.
В работе его пока правда не пробовал, но собирается легко
Реализации Prolog, Lisp видел на ерланге там, то что с ходу вспоминается
2020 October 11
ŹR
Как в эрланге получить +infinity float?
SP
Как в эрланге получить +infinity float?
Через математику никак
ŹR
А впринципе как?
ŹR
Бинарь какой-то сделать из всех единиц
ŹR
Я просто не шарю...