Comments 4
Спасибо за подробное описание. Принцип решения понятен.
А почему не сделали язык тотально-ленивым?
А почему не сделали язык тотально-ленивым?
Можно было бы попробовать и ленивую модель вычислений. В принципе, ничего не мешает поэкспериментировать даже с этими интерпретаторами. Просто строгая модель для первой реализации более интуитивно понятна и не приводит к разрастанию цепочек недовычисленных санок и вообще нормальный порядок редукции лямбда-термов (по крайней мере, его наивная реализация) приводит к дублированию вычисления одинаковых цепочек выражений по несколько раз, в отличие от аппликативного. Без дополнительной оптимизации будет медленнее и более затратно по памяти, хотя для пет-прожекта и проверки концепции, повторюсь, можно попробовать, идея интересная.
Тоже когда-то занимался подобным: https://github.com/PhantomYdn/jlll
Есть и макросы и closure и частичные квоуты и прочие радости lisp/schema
Есть и макросы и closure и частичные квоуты и прочие радости lisp/schema
Не могу плюсануть — оказывается не хватает кармы. Похоже, это вообще модная забава :)
И вдогонку, для полноты картины, если вдруг кто интересуется, но еще не видел: https://github.com/kanaka/mal
Almost everybody has their own lisp implementation. Some programmers' dogs and cats probably have their own lisp implementations as well.https://github.com/JeffBezanson/femtolisp
И вдогонку, для полноты картины, если вдруг кто интересуется, но еще не видел: https://github.com/kanaka/mal
Sign up to leave a comment.
Liscript — реализуем TCO