LINUX.ORG.RU

Алан Keй: deep flows in Lisp's logical foundations

 


1

5

I could hardly believe how beautiful and wonderful the idea of LISP was. I say it this way because LISP had not only been around enough to get some honest barnacles, but worse, there were deep flaws in its logical foundations. By this, I mean that the pure language was supposed to be based on functions, but its most important components — such as lambda expressions, quotes, and conds — were not functions at all, and instead were called special forms ... My next questions was, why on Earth call it a functional language? Why not just base everything on FEXPRs and force evaluation on the receiving side when needed? I could never get a good answer

Далее Кей пишет о том, что эти размышления привели его к идее создания модели Ъ-ООП

А, все же интересно, кто-нибудь, таки, дал ответ на вопрос Алана Кея?

Why not just base everything on FEXPRs and force evaluation on the receiving side when needed?

В реболе именно так. Насколько я понимаю для этого придется пожертвовать компилируемостью.

loz ★★★★★
()
Ответ на: комментарий от loz

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

anonymous
()
Ответ на: На, почитай, когда протрезвеешь от x4DA

Ты сам понял про что мне скинул ссылку, и как это вообще относится к тому что я написал? По-моему - нет, впрочем это типично для схемеров не осиливших CL.

lovesan ★★★
()
Ответ на: комментарий от komputikisto

не совсем для этого, и таки не решают именно описанную проблему.

они отделяют блок с продолжением, но не решают проблему взаимодействия.

lovesan ★★★
()
Ответ на: комментарий от lovesan

я тебе предлагаю не заниматься словоблудием, а поставить конкретную задачу, реализовать ее на CL и предложить реализовать на scheme.

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

x4DA ★★★★★
()

deep flows

глубокие потоки, болезный?

anonymous
()
Ответ на: комментарий от lovesan

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

anonymous
()
Ответ на: комментарий от komputikisto

Могло бы быть больше. Например, тут предлагается другой интерфейс к продолжениям (нефункциональный)

В Racket есть всё, что по той ссылке. Вызываешь (continuation-marks cont) и читаешь место вызова, контекст и прочее, что там сложено (стектрейс тоже на них целиком сделан). http://docs.racket-lang.org/reference/contmarks.html

monk ★★★★★
()
Ответ на: комментарий от lovesan

Вот опять же те два пункта - как исключения должны с корутинами взаимодействовать? Прерывать и закрывать их все? Или убивать только текущую корутину? Или что?

Что значит «закрывать»? Исключение возвращает управление из текущего контекста (например, корутины) наверх. Снаружи ни одну из корутин продолжить нельзя — в лексическом контексте их нет. Но если есть сохранённое продолжение из любой из корутин, то их все можно продолжить.

Таким образом, ответ: прерывать все, убивать (их контексты) только если сборщик мусора видит, что ссылок на них нет.

monk ★★★★★
()
Ответ на: комментарий от Cheater

Тем, кто пытается ответить аргументированно: просмотрите список тем ТС. Это уже n+1 -ая тема с троллингом лиспа/FP.

при этом сам ТС ни строчки на ФП не написал. да и не на ФП под тоже.

И да, вообще-то «flaws», а то получается «глубокие потоки в логических основах Lisp».

тсссс... это хитрый план. owls are not what they seem...

anonymous
()
Ответ на: комментарий от monk

Но если есть сохранённое продолжение из любой из корутин, то ...

А почему ты сопрограммы называешь корутинами, а продолжения не называешь континуациями?

Это я к тому, что ты, вроде, и смысл понимаешь, и на пидараса не похож, а туда же - тупое калькирование с английского. :(

anonymous
()
Ответ на: комментарий от anonymous

А почему ты сопрограммы называешь корутинами

Потому что такая терминология была в вопросе: "...как исключения должны с корутинами взаимодействовать...".

тупое калькирование с английского

Иногда приходится калькировать: если такая терминология указана окружающим контекстом (вопроса; предыдущих статей в документации, написанных другими людьми...) или если без калькирования возможна неоднозначность: переведи на русский без калькирования «инстанциирование класса, биндящего сокет сервера».

monk ★★★★★
()
Ответ на: комментарий от monk

Иногда приходится ...

В таком случае уместней правильный термин, а в скобочках уточнение - «то, что ты назвал #$%».

или если без калькирования возможна неоднозначность ...

или устоявшегося термина. Но слова «инстанциирование» и «биндящего» лучше заменить, если контекст позволяет.

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.