Comments 21
"Church numerals" обычно переводят как «числительные Черча».
Могу предложить оптимизацию:
вместо fib = cycle cycle 1 0
можно написать fib = w cycle 1 0
Реализация w займет всяко меньше места, чем вторая копия cycle.
вместо fib = cycle cycle 1 0
можно написать fib = w cycle 1 0
Реализация w займет всяко меньше места, чем вторая копия cycle.
Круто! На хабре комбинаторная логика.
Unlambda — штука интересная, но это все же не то — не очень она уж и чистая, совсем даже не чистая.
я вам советую Lazy K — это по настоящему (в самом-пресамом прямом смысле слова) чистый язык — для истинных ценителей.
*(У меня есть враперы на Хаскеле, чтоб удобно было, если заинтересует)
Unlambda — штука интересная, но это все же не то — не очень она уж и чистая, совсем даже не чистая.
я вам советую Lazy K — это по настоящему (в самом-пресамом прямом смысле слова) чистый язык — для истинных ценителей.
*(У меня есть враперы на Хаскеле, чтоб удобно было, если заинтересует)
Ну, Lazy K, по сути, урезанный Unlambda. Под чистотой unlambda я подразумевал только концепцию, пожалуй. Если использовать только ski, то он будет чистым.
Вот по-настоящему для ценителей, в нем только один комбинатор.
Вот по-настоящему для ценителей, в нем только один комбинатор.
Если только ski — то как же осуществляется IO?
*(Кстати Lazy K — поддерживает Iota и Jot, и синтаксис Unlambda)
*(Кстати Lazy K — поддерживает Iota и Jot, и синтаксис Unlambda)
В чистоту не входит требование возможности ввода/вывода, насколько я знаю
Не в этом дело — может и не входит, но если возможность ввода/вывода есть и при этом язык полностью чист — это же лучше (ну меня это очень впечатлило) чем чистый, но ничего (видимого) не делающий.
Lazy K, к тому же, еще и ленивый.
Lazy K, к тому же, еще и ленивый.
Согласен, с вводом-выводом лучше.
Было бы неплохо совместить удобство самого лямбда-исчисления и интересный механизм ввода-вывода из Lazy K.
Было бы неплохо совместить удобство самого лямбда-исчисления и интересный механизм ввода-вывода из Lazy K.
Я не понял ваше замечание. Lazy-K же совмещает лямбда-исчесление и свой IO.
Я имел в виду лишь синтаксис лямбда-исчисления, по-моему, более удобный, по сравнению с комбинаторной логикой.
Понял, кстати те Хаскель-враперы (и еще есть оригинальные на Схеме), о которых я выше писал, позволяют писать код используя синтаксис безтипового лямбда-исчисления, который дальше преобразовывается в комбинатор (типа компилируется) и исполняется интерпретатором Lazy-K.
У меня была даже идея написать библиотеку для эмуляции более сложного синтаксиса, но все закончилось комбинаторами для списка
где "[" — комбинатор, который принимал свои аргументы до тех пор пока не встретит комбинатор "]" (индикатор конца), результатом был список.
А потом я столкнулся с проблемами, вызванными безтиповостю, которые сильно усложняли жизнь, и перешел на типизированное.
У меня была даже идея написать библиотеку для эмуляции более сложного синтаксиса, но все закончилось комбинаторами для списка
[A B C D]
где "[" — комбинатор, который принимал свои аргументы до тех пор пока не встретит комбинатор "]" (индикатор конца), результатом был список.
А потом я столкнулся с проблемами, вызванными безтиповостю, которые сильно усложняли жизнь, и перешел на типизированное.
А почему бы сразу не сделать интерпретатор лямбда-синтаксиса?
Так ведь есть много, на любой вкус и цвет:) Хаскель, Лисп, Схема, СМЛ — все функциональное. А насчет ІО, если есть интерпретатор, то оно как бы и не нужно.
*плюс много самодельных в интернете часто попадается
*плюс много самодельных в интернете часто попадается
Немногие из них могут похвастаться скоростью. Я вот подумываю свой велосипедик написать.
Конечно же напишите:) Мне бы интересно было бы почитать, как вы редукцию реализуете (это я с намеком, что вы тут опишете что и как).
Часто на глаза попадалась редукция на графах, но никак не мог разобраться.
Могу даже в долю, поскольку сейчас на досуге тоже пишу интерпретатор лямбда-выражений, но уперся в редукцию — руки не доходят погуглить.
Часто на глаза попадалась редукция на графах, но никак не мог разобраться.
Могу даже в долю, поскольку сейчас на досуге тоже пишу интерпретатор лямбда-выражений, но уперся в редукцию — руки не доходят погуглить.
Да, помню, когда в послелний раз пытался реализовать, самая большая сложность была в редукции. Есть некоторые идеи, додумаю — поделюсь)
Прочитал, что задача определения того, сведется ли выражение к нормальной форме или бета-редукцию можно будет применять бесконечно, алгоритмически неразрешима. Видимо, на такие вещи придется просто забить)
Представление выражения в виде дерева будет весьма удобно. Если еще добавить copy-on-write оптимизацию (счетчик ссылок на объект, как в boost shared_ptr), то должно быть сравнительно быстро.
Представление выражения в виде дерева будет весьма удобно. Если еще добавить copy-on-write оптимизацию (счетчик ссылок на объект, как в boost shared_ptr), то должно быть сравнительно быстро.
Кстати, поскольку Lazy-K ленивый, то и редукция там интересная: редуцируется только то, что должно выводиться на экран, то есть если что-то может преобразовываться бесконечно, то оно или вообще не будет преобразовываться, или результат будет виден на экране (так например работает Lazy-K программа, каторая печатает все простые числа). То есть программа не уйдет в себя.
Sign up to leave a comment.
Бестиповое лямбда-исчисление, комбинаторы, Unlambda и числа Фибоначчи