Короче, я придумал, что машина, которая будет исполнять LIFP-программы, работает только с ФУНКЦИЯМИ. Нет ничего, кроме функций. А функция - это такая штука, к которой применима операция apply... вернее, применима не к самой функции, а к кортежу функций. И возвращает эта операция еще одну функцию.

И, короче, синтаксис LIFP-а в итоге получается весьма и весьма моноиконичным.

>>11618
>>11615
Где-то я уже видел подобное. Кажется, ты изобретаешь велосипед.
крокодил-тред-читал-по-диагонали

>>11620
Наверно, в Хачкеле?

> > >>11618

> работает только с ФУНКЦИЯМИ.

Даже без примитивных типов? Правда-правда?

>>11627
Типы? Какие типы? Нет никаких типов. Все, что можно сделать в LIFP - это пропатчить операцию apply новыми сопоставлениями.

>>11628
А, ну и еще можно конструировать новые функции, да.

>>11615
Я не понял, ты изобретаешь обратно лямбда-исчисление?
Приготовил копипасту Лисперы - контрамоты.тхт

>>11637
Выходит, что так.

>>11639
Если будет цепочка
А меняем на B
B меняем на C
C меняем на A
то твоя apply будет работать вечно. Что с этим делать?
Я не троллю, идея мне нравится, надеюсь на конструктивный диалог.

И ещё, не мог бы ты описать то, что у тебя в png-пикчах на русском - я не очень can in english...
Если не трудно

>>11746
Ох, лол, а я уже дропнул эту затею.

С чего она будет работать вечно? Применяем apply к A, получаем B. Всё. Потом, если захотим, сделаем apply(apply(B)) и получим A. Всё.

>>11747
Ох, не дропай эту затею, ОП.
Как в реальной программе будет выполняться это apply? Почему тогда все языки типизированы, что в чистом лямбда-исчислении их создатели увидели плохого? Наконец, что тебя натолкнуло на изложенную идею?
читая такие треды, я вижу что от этого чана хоть какая-то польза

>>11749
... и главное, самое интересное: как этот язык реализовать? На чём? На уже типизированных lisp и scheme это можно сделать?

>>11747
"_"-ками буду помечать непечатаемые тут символы.

_F - множество функций.
__
Другими словами, F есть направленный граф, рёбра которого заданы apply-ем.

Некоторые базовые функции:
___
___
___

Синтаксис LIFP-а в нотации РВ-грамматик:
___
___
___

Семантика:
Symbol-ы интерпретируются как функции, и если два символа равны, то функции, которые соответствуют им, тоже равны. List-ы интерпретируются как apply(list, f_Expression1, ..., f_Expressionn), где Expression_i есть Expression из List-а, а f_Expressioni есть функция, соответствующая Expression_i. Конкретные действия, которые будут выполняться по результирующей функции (при вычислении результирующей функции, точнее - прим. авт.), зависят от интерпретатора.

Определения функций:
Рекомендуется интерпретировать следующие конструкции как определения функций:
(function ___
Здесь pattern - это List, содержащий специальные последовательности (например, "_ :a") для захвата аргументов. Замещать или нет аргументы их eval-уированными версиями, определяется самой функцией. Можно придумать специальную нотацию, чтобы это замещение можно было скрыть из тела [функции] (короче, чтобы не писать в теле явно: "(let f = (eval f))" - прим. авт.).

Лямбды:
__
Не существует никакой нотации, в которой можно получить лямбду по имени (анонимные функции же - прим. авт.). Ее можно получить через apply-ирование других функций. Имеется специальная конструкция (LAMBDA ...) для конструирования лямбд.

>>11749

> Как в реальной программе будет выполняться это apply?

Когда парсер будет читать программу (например, такую: "(ehal (spisok) cherez (spisok))"), он автоматически будет возвращать функцию, которая будет соответстовать за-list-енной этой программе (в нашем примере это будет: "f = apply(list, ehal, apply(list, spisok), cherez, apply(list, spisok))"). Потом интерпретатор сделает этой функции eval ("apply(eval(f))) = apply(ehal, ...)") и начнется магия.

> Почему тогда все языки типизированы, что в чистом лямбда-исчислении их создатели увидели плохого?

UPD: Твою мать! Не выражается apply графом на одних только функциях! Новый положняк: apply можно представить в виде направленного графа, вершинами которого являются функции и кортежи функций (см. рис.). Не множества, заметьте, а кортежи.

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

А вообще, я сам не знаю, типизированное или бестиповое у меня. Ну, смотри сам: оператор apply у меня полностью полиморфен (в бестиповом ЛИ его поведение определяется только первым аргументом - лямбдой; у меня же определяется всеми аргументами); плюс рёбра apply-графа определены не для всех вершин (далеко не для всех), а только для определённых. Наверно, это все-таки типизированное (и я поначалу ошибся), потому что далеко не для всех сочетаний лямбд и их аргументов определена лямбда-результат. Да, это, наверно, "лямбда-пэ-омега". Очень похоже. Короче, лямбда-самцы, классифицируйте мне мою систему. Не знаю я.

> Наконец, что тебя натолкнуло на изложенную идею?

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

>>11750

> как этот язык реализовать?

Очень просто же. Нужно реализовать мутабельный направленный граф на атомах и кортежах атомов. Понятно, что не в лоб; можно использовать свойства этого графа: 1) его ребра всегда соединяют либо атом с кортежом, либо кортеж с атомом; 2) кортежи всегда задаются семействами; 3) другие свойства, которые удастся обнаружить пытливому уму код реализатора. Ах да, граф должен быть клонируемым - контексты выполнения же.

Самая проблема, ИМХО, будет в кортежах атомов. Фактически, эти кортежи - это ограничения на аргументы функций. Но задавать-то ограничения можно по-разному, в том числе и в выражениях самого языка (как я и хочу), то есть, опять же, через apply-граф. В общем, возникает какая-то жуткая метациркулярность, об которую у меня ломается мозг. С другой стороны, можно же не усираться над реализацией "лямбда-пэ-омеги", а сделать поначалу "лямбда-2" или вообще "лямбда-стрелку". Лол, что за хуйню я пишу? Wait, тема треда, oh shi~

>>11754
А, еще. Для функций, полученных от apply-ирования с list-ом, нужно сохранять исходные аргументы (то бишь, компоненты списка). Так проще будет писать eval.

>>11756
Чтож, в лице меня у тебя есть один благодарный слушатель, но я нуб - я очень по чуть-чуть и в математику, и в инглиш (со словарём).

> Я просто хотел придумать моноиконичный LISP. Начал выбрасывать сущности одну за другой, в итоге осталась одна единственная операция.

А я около года тыкаюсь в в разные LISP-ы в поисках моноиконичного - а они все оказываются как-то черезчур конкретизированными и меня всё никак не покидает ощущение, что всё должно быть устрено проще.
Поэтому ни в какую конкретику я так пока и не вник. и ящитаю, правильно сделал
Так что ОП, развивай мысль @ доводи до реализации.
А я буду гуглить непонятное и поглядывать ITT

>>11754

> жуткая метациркулярность, об которую у меня ломается мозг

Ох лол, моя характеристика - на пикрелейтед-скриншоте ОПпоста соседнего треда, у меня о сами эти ваши LISPы ломается мозг - в некотором смысле я тебя понимаю.

> Так вот, языки все типизированы потому, что хрен ты реализуешь бестиповое лямбда-исчисление так, чтобы в итоге получилось без летающих дилд

Можно про дилды всё-таки подробнее?

>>11778
Я о тех самых дилдах, которые дает динамическая типизация или вообще отсутствие какой-либо. Ну, из-за которых еще статикобоги постоянно срутся с динамикопетушками.

>>11779

> Можно про дилды всё-таки подробнее?

Можно. Представим что весь наш язык - это единый организм лямбда-исчисление. Вот есть, булеаны Чёрча

tru = x.y. x
fls = x.y. y

и нумералы Чёрча

0 = x.y. y
1 = x.y. x y
2 = x.y. x x y
...

, которые мы используем для работы с числами и булевыми значениями.

Так вот встретилось у тебя в синтаксическом графе x.y. y и как ее понимать? fls? А может 0? А может это тупельная функция snd?

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

Тут кстати еще можно возразить, что это просто Чёрч плохо закодировал. В этом случае я не знаю, что и сказать, возможно да, в данном конкретном случае и можно кодировать булевы величины и числа так, чтобы они не пересекались, однако в общем случае, при большом количестве сущностей это может и не получиться. Непонятно, надо гуглить.

Кстати как оп собрался жить, если у него все есть функция, непонятно. Походу он как раз и хочет хитро закодировать сущности и распознавать их в своем apply. А ведь еще надо сделать так, чтобы все значения были нормальными формами, иначе Пирс рассердится.

>>11751

> Конкретные действия, которые будут выполняться по результирующей функции (при вычислении результирующей функции, точнее - прим. авт.), зависят от интерпретатора.

Так у тебя ещё и операционная семантика зависит от интерпретатора, или я чего-то не понел?

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

На операционную семантику я пока забил. Сначала б хоть с денотационной разобраться...

>>11783

> парашютисты

Нет.

> до того экстремальны

Нет-нет, я говорил только о бестиповом лямбда-исчислении.

>>11781
Да, с кодированием придется хорошо потрахаться. Особенно если учесть, что apply-граф у меня получается бесконечным. Есть мысль в код функции запихать ее класс, как это делается в ООП-средах, но над этим надо подумать, чтобы не получить какую-нибудь ПРИНЦИПИАЛЬНУЮ НЕВОЗМОЖНОСТЬ.

>>11783
Дооо, я настолько бэтмен, что никаких стандартных типов и операций вводить не собираюсь. Ну, разве что числовые и строковые литералы, но они будут конвертиться в соответствующие функции на уровне парсера.

И обязательно введу нативно задаваемые рёбра apply-графа. Это вообще надо сделать в первую очередь.

Мы об одних и тех же вещах говорим, да?