Срач борщехлебов - это сильно.

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

например, гипотетическим lisp-N.

возьмём пример с вики:

($define! $and?
   ($vau x e
      ($cond ((null? x)         #t)
             ((null? (cdr x))   (eval (car x) e))
             ((eval (car x) e)  (apply (wrap $and?) (cdr x) e))
             (#t                #f))))

здесь e — единое окружение «lisp-0».

перепишем эквивалентно

($define! $and?
   ($vau x (bool-e e-other)
      ($cond ((null? x)         #t)
             ((null? (cdr x))   (eval-1 (car x) (bool-e e-other)))
             ((eval-1 (car x) (bool-e e-other))  (apply (wrap $and?) (cdr x) (bool-e e-other)))
             (#t                #f))))

то есть:

1. разобьём окружение («пространство имён lisp-0») на два непересекающихся класса.
2. eval'ы для разных семантик могут быть разные, но по каким-то общим интерфейсам (cм. Interface Passing Style в CL). лишь бы результат был composable в рамках «виртуального пространства имён lisp-0»
3. в дальнейшем упрощая, может быть можно ввести какие-то «аспекты», «субъекты», «контексты». В рамках которых эти повторяющиеся (car x) (cdr x) можно ввести переменной времени компиляции (ну или макросом), в каком-то отдельном пространстве имён lisp-X. То есть, получаем : «макрос имеет смысл, значение только в определённом контексте».

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

в естественном языке это постоянно происходит. например, «косил косой косой косой». в лисп-1 — неоднозначность, которую как-то надо разрешать. как? руками вычисляя кодировку Чёрча в лисп-алеф0, или, скорее (более полезна) кодировку Могенсен-Скотта

речь идёт о идее мемоизовать эти общеупотребимые номера из алеф0, кэшировать.

тогда «косил косой косой косой» =

 ( (что-делал? косил :глагол :1-лица :прошедшее-время)
   (кто? косой :синоним заяц :род-вид-класс ушастый)
   (чем? косой :синоним scythe :род-вид-класс сельхозинструмент)
   (какой? косой :синоним кривой)   )

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

что-то вроде:

eval «общий в лисп-0» задаёт наиболее общую абстракцию, метамодель вычислений.
а eval «конкретный в лисп-Х» — определённую конкретную абстракцию, в контексте, аспектах и «определённой парадигмы из 'кластера метапарадигм' » :-)))
 — которая является моделью, построенной как реализация, воплощение этой метамодели (воплощение метамодели порождает модель, модели — конкретный код или значение). эта трансляция метамодель-модель выполняется во время компиляции, CTFE, то есть — чем-то похожа на прогонку, суперкомпиляцию, только ИМХО, можно ограничиться какими-то частными случаями, если строить снизу вверх (из конкретных моделей в мета), а не наоборот.

потом, apply-и тоже могут быть разные.

ну и т.п.

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

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

При этом с одной стороны никаких пересечений - с другой стороны, никакой нетривиальной неоднозначности.

о, значит если критику про «текущую абстракцию» уточнить — чем плоха — отсутствием общих правил, композиции, сложностью анализа для компилятора (за что собственно Kент Питман критиковал Fexprs в MacLisp, InterLisp).

критика Питмана относится к тому что в лиспах тех времён с а) динамическим, а не лексическим окружением б) достаточно глупом компиляторе анализ было сделать сложно.

ИМХО, нужно преобразовать проблему так, чтобы не искать сложное решение сложной задачи — а «out of the box» искать простую композицию сложных решений простых задач.

то есть, ввести фичи в язык, позволяющие сделать этот анализ проще.

язык — это инструмент управления сложностью. сложностью управляем посредством выбора более удобных моделей, абстракций, парадигм.

вопрос в том, как выполняется композиция этих абстракций. они не должны стыковаться слишком сложным способом.

то вот над этим и надо поработать: чтобы правила разрешения пересечений («отображения lisp-0 в lisp-Х») были просты, прозрачны, однозначны, тривиальны (не в смысле тривиальности теории, как [Wand98] про альфа-конгруэнтность — потому что дальнейшая критика Fexpr-ов пишет, что нельзя иметь все 3 сразу: нетривиальную теорию, мощную (сложную?) модель и полезную, нетривиальную семантику. Что-то про это пишет John Shutt, ЕМНИП — в рассуждениях про implicit и explicit evaluation.

то есть, чтобы заткнуть «текущую абстракцию», надо а) устранить неоднозначность б) сделать её возникновение тривиальной.

например, внедрить что-то типа движка правил как в Interactive Fiction. там Плоткин пытается ввести какую-то общую систему правил для реализации концепции объекта, свойства, диспетчеризации (одиночной, множественной) — вводя метаправила, по которым выполняется CTFE композиция. потом он вводит какие-то булевы предикаты в правилах, которые подозрительно напоминают predicate dispatch и кодировку Могенсен-Скотта.

в общем, есть ощущение что копать надо где-то вот там, и если допилить эту гирю — она будет золотой ;^))

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

но, как минимум — ты должен знать, что это: это макрос, или специальная форма или функция. потому что у них разные модели вычислений.

зачем вообще это знать?

значит, абстракция, требующая знать как именно реализовано это foo — течёт :-))

вопрос в том, где и как она течёт. если в отсеке с переборками — ну и хрен с ней, возможной протечкой, если далеко за пределы «виртуального пространствая имён lisp-XXX на стыке других двух» прорвать всё равно не сможет. будет какая-то борьба за живучесть плавучесть.

например, гипотетическим lisp-N.

почему гипотетическим? общелисп - это и есть лисп-н, вполне себе негипотетический.

возьмём пример с вики:

Зойчем опять фекспры и кернел? Оно же невыразительно. На макросах можно сделать кернел, но на кернеле - нельзя сделать макросы.

в естественном языке это постоянно происходит

Вообще, это хороший критерий - если что-то постоянно происходит в естественном языке, то это совершенно недопустимо в ЯП.

например, «косил косой косой косой»

Неправильный пример. Это обычная типизация, а не лисп-н.

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

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

критика Питмана относится к тому что в лиспах тех времён с а) динамическим, а не лексическим окружением б) достаточно глупом компиляторе анализ было сделать сложно.

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

то есть, ввести фичи в язык, позволяющие сделать этот анализ проще.

А зачем, собственно? Ну то есть зачем нам нужны фекспры, если они ничего не дают, вводят фундаментальные ограничения и при этом еще нам надо делать специальные костыли для их анализа? куча минусов и _ни одного_ (!) плюса. Нахуя такая фича?

но, как минимум — ты должен знать

Вообще - не должен. Но я должен знать, что форма вообще _делает_ - и это знание, в общем, необходимо будет включать является ли форма макросом/ф-ей/спецформой. А вот знание того, во что она раскрывается - включать не будет.

На макросах можно сделать кернел, но на кернеле - нельзя сделать макросы.

на фекспрах можно сделать макросы. другое дело, что в текущей реализации фекспров это банка с червями, поэтому их как-то нужно ограничивать, чтобы обеспечить нормальную оптимизацию, анализ. который в общем случае (те же MacLisp/InterLisp) — мутное и непрозрачное дело.

поэтому нужны не софсем фекспры, а что-то похожее, но попроще для анализа.

Оно же невыразительно.

да ладно тебе. из примера про реализацию eval (ссылку не помню, но суть такова): в обычном лиспе требуется «питушение списков» (tm) и cond по символам, как в интерпретаторе, в другом — организация такого окружения / «пространства имён», будучи раскрытым в котором те, что нужно  — транслируются в то, что нужно, а те, что не нужно — не транслируются ни во что. пруфлинк посеял, увы.

потом, можно же «Environment Passing Style» организовать. по аналогии с IPS для всех этих «частичных lisp-N».

Вообще, это хороший критерий - если что-то постоянно происходит в естественном языке, то это совершенно недопустимо в ЯП.

почему? ЕЯ кратче, ёмче для нетривиальных примеров. смотри, например, программирование на Inform7 (книжка) ( пример  — смотреть после «And now for something completely different; this version for Inform 7 written by Emily Short and Graham Nelson in March 2007:»

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

Неправильный пример. Это обычная типизация, а не лисп-н.

ну да, не совсем хороший — потому что порядок слов можно менять. а если взять какой-нибудь язык с Verb-Subject-Object, где от порядка слов смысл может кардинально поменяться? то есть, типизированы будут по-разному.

Но я должен знать, что форма вообще _делает_ - и это знание, в общем, необходимо будет включать является ли форма макросом/ф-ей/спецформой.

ок, а зачем разделять макросы это или спецформы? в kernel всё является first class object. ну представь что эту башню можно наращивать сверху макросами или снизу спец. формами, то есть, определять свои спец. формы и правила их вычисления.

можно «ортогонализировать» лишние сущности. спрятать их под капот различных eval-ов и apply-ев, при этом общий принцип для метаязыка лисп-0 останется единый, прозрачный, универсальный.

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

ой ли? зачем три механизма для макросистемы вместо одной (define-macro, syntax-case и syntax-rule)? зачем мутить такие вот «синтаксические объекты» и можно ли сделать их проще?

почему макросы не first class object и какая польза возможна, если это сделать ?

куча минусов и _ни одного_ (!) плюса. Нахуя такая фича?

плюс: универсальнее, ортогональнее, компактнее система понятий и реализации. потом, есть работа про nanopass framework для компилятора Chez Scheme.

там описаны: определение разных DSL для реализации компилятора в виде многих проходов и одного универсального движка; форма записи в виде «катаморфизмов»; выводы про результативность метода со схемами, графиками, цифрами.

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

сдаётся, эти две фичи: катаморфизмы в смысле того nanopass framework и «полезные» fexpr-ы как-то связаны.

Ну то есть зачем нам нужны фекспры, если они ничего не дают, вводят фундаментальные ограничения и при этом еще нам надо делать специальные костыли для их анализа?

дают — некоторую универсализацию, ортогонализацию. более простой способ композиции.

то есть, вместо одной модели с универсальным eval/apply имеем несколько разных в «частных» lisp-N и одну универсальную в «общем» метаязыке lisp-0, который их объединяет.

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

то есть, стыковать метаязыком другие чёрные ящики eval/apply, а не делать один белый ящик для всех.

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

в случае универсальных фекспров. а вот если как-то грамотно их ограничить...

А зачем, собственно?

ну вот спросят ловсанчега, а что такое этот ваш кластер метапарадим. а так есть чо ответить: это такой вот ортогональный сферический конь в вакууме, метатеория всего.

:-)))

из примера про реализацию eval (ссылку не помню, но суть такова): в обычном лиспе требуется «питушение списков» (tm) и cond по символам, как в интерпретаторе, в другом — организация такого окружения / «пространства имён», будучи раскрытым в котором те, что нужно — транслируются в то, что нужно, а те, что не нужно — не транслируются ни во что. пруфлинк посеял, увы.

пруфлинк :

McCarthy's Eval Function (transformed from the original M-expressions into more familiar s-expressions)

(define (eval e a)
  (cond
   ((atom e) (assoc e a))
   ((atom (car e))
    (cond
     ((eq (car e) 'quote) (cadr e))
     ((eq (car e) 'atom)  (atom   (eval (cadr e) a)))
     ((eq (car e) 'eq)    (eq     (eval (cadr e) a)
                                  (eval (caddr e) a)))
     ((eq (car e) 'car)   (car    (eval (cadr e) a)))
     ((eq (car e) 'cdr)   (cdr    (eval (cadr e) a)))
     ((eq (car e) 'cons)  (cons   (eval (cadr e) a)
                                  (eval (caddr e) a)))
     ((eq (car e) 'cond)  (evcon. (cdr e) a))
     ('t (eval (cons (assoc (car e) a)
                      (cdr e))
                a))))
   ((eq (caar e) 'label)
    (eval. (cons (caddar e) (cdr e))
           (cons (list (cadar e) (car e)) a)))
   ((eq (caar e) 'lambda)
    (eval (caddar e)
           (append (pair (cadar e) (evlis (cdr e) a))
                   a)))))

Vau Eval Function

(define (eval e a)
  (cond
   ((atom e) (assoc e a))
   ((atom (car e))
    (eval (cons (assoc (car e) a)
                       (cdr e))
                 a))
   ((eq (caar e) 'vau)
    (eval (caddar e)
           (cons (cons (cadar e) 'env)
                 (append (pair (cadar e) (cdr e))
                          a))))))

на фекспрах можно сделать макросы.

Конечно же нет. Просто по определению.

да ладно тебе. из примера про реализацию eval (ссылку не помню, но суть такова): в обычном лиспе требуется «питушение списков» (tm) и cond по символам, как в интерпретаторе, в другом — организация такого окружения / «пространства имён», будучи раскрытым в котором те, что нужно — транслируются в то, что нужно, а те, что не нужно — не транслируются ни во что. пруфлинк посеял, увы.

Смотри в чем дело - наличие макросов очевидным образом повышает выразительность языка. Наличие фекспров - не повышает. То есть язык с ф-ями и фекспрами не отличается от языка с функциями. Ведь фекспр - это ни что иное, как обычная ф-я.

ЕЯ кратче, ёмче для нетривиальных примеров.

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

ок, а зачем разделять макросы это или спецформы?

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

что эту башню можно наращивать сверху макросами

В том и дело, что нельзя. Ни макросами, ни спецформами.

ой ли? зачем три механизма для макросистемы вместо одной (define-macro, syntax-case и syntax-rule)? зачем мутить такие вот «синтаксические объекты» и можно ли сделать их проще?

Какие три? Одна единственная макросистема.

почему макросы не first class object

Для выразительности.

и какая польза возможна, если это сделать ?

Никакой. Только вред (снижение выразительности).

плюс: универсальнее, ортогональнее, компактнее система понятий и реализации.

наоборот. Менее универсально, громоздко, куча пересекающихся фич, которые в языке с макрами отвязаны друг от друга (как и должно быть).

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

Кода значительно больше, компиляции вообще НЕТ И БЫТЬ НЕ МОЖЕТ. Как только ты добавляешь в язык фекспры - ты запрещаешь его компилировать.

А нанопасс, конечно, к фекспрам не относится - там как раз чистой воды макросы, собсно, идеи нанопаса как раз в ракетке и применяются - она же позиционируется именно как фреймворк для разработки своих языков. и нанопас достаточно просто делается на ракетке.

в случае универсальных фекспров. а вот если как-то грамотно их ограничить...

Ну вот давным-давно встал вопрос о том, как грамотно ограничить фекспры и получить что-то содержательное. Был дан ответ - ограничить до макросов. А некоторые дебилы до сих пор живут 50 лет назад.

А у меня есть еще более хорошее решение:

(define eval vau-eval)

смотри как коротко, компактно, универсально и ортогонально!

на фекспрах можно сделать макросы.

Конечно же нет. Просто по определению.

Ведь фекспр - это ни что иное, как обычная ф-я.

?? в понимании недо общелиспа (MacLisp/Interlisp) — да. вообще нет.

из описания kernel: есть два вида комбинаторов, applicatives и operatives. applicatives примерно соответствуют функциям — вычисляются все аргументы перед выполнением. operatives (фекспры в kernel) — наоборот, не вычисляется ни одного, и явно требуют вычислять вручную через eval.

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

то есть, далее он фактически фигачит комбинаторами с двумя моделями вычисления: с eager (функции, applicatives) и lazy (фекспры, operatives) вычислениями, оборачивая их обёртками vau и wrap. в ленивом — нужно eval делать руками, хотя можно написать и синтаксис для implicit вычислений.

Смотри в чем дело - наличие макросов очевидным образом повышает выразительность языка. Наличие фекспров - не повышает. То есть язык с ф-ями и фекспрами не отличается от языка с функциями. Ведь фекспр - это ни что иное, как обычная ф-я.

повышает и отличается, т.к. у функций разная семантика вычислений, жадная или ленивая.

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

давай примеров. вот если взять Interactive Fiction вот отсюда с конца

ЕЯ это код

вербозность это хорошо, когда концепции более сложные чем однострочники

выразительность это хорошо.

Cloak of Darkness"

The story headline is "A basic IF demonstration."

The maximum score is 2.

[Whatever room we define first becomes the starting room of the game,
in the absence of other instructions:]

Foyer of the Opera House is a room.  "You are standing in a spacious hall,
splendidly decorated in red and gold, with glittering chandeliers overhead.
The entrance from the street is to the north, and there are doorways south and west."

Instead of going north in the Foyer, say "You've only just arrived, and besides,
the weather outside seems to be getting worse."

[We can add more rooms by specifying their relation to the first room.
Unless we say otherwise, the connection will automatically be bidirectional,
so "The Cloakroom is west of the Foyer" will also mean "The Foyer is east of the Cloakroom":]

The Cloakroom is west of the Foyer.
"The walls of this small room were clearly once lined with hooks, though now only one remains.
The exit is a door to the east."

In the Cloakroom is a supporter called the small brass hook.
The hook is scenery. Understand "peg" as the hook.

[Inform will automatically understand any words in the object definition
("small", "brass", and "hook", in this case), but we can add extra synonyms
with this sort of Understand command.]

The description of the hook is "It's just a small brass hook,
[if something is on the hook]with [a list of things on the hook]
hanging on it[otherwise]screwed to the wall[end if]."

1. ... is west of the ... определения комнат со ссылками в обе стороны (проставили для одной, автоматически проставились для другой).

2. типы объектов: room, supporter, scenery. можно комбинировать, так что это больше напоминает типы классов.

The player wears a velvet cloak. The cloak can be hung or unhung.
Understand "dark" or "black" or "satin" as the cloak.
The description of the cloak is  ...
<и далее правила, применимые к объекту>

Neatness is a kind of value. The neatnesses are neat, scuffed, and trampled.
The message has a neatness. The message is neat.

типы, traits, свойства, предикат свойства.

3.

 Understand "peg" as the hook.
...
Understand "hang [something preferably held] on [something]" as putting it on.

определили методы. в дальнейшем эти методы больше напоминают правила (применимы к определённым типам и свойствам):

Instead of dropping or putting the cloak on when the player is not in the cloakroom:
    say "This isn't the best place to leave a smart cloak lying around."

Instead of doing something other than going in the bar when in darkness:
    if the message is not trampled, change the neatness of the message
    to the neatness after the neatness of the message;
    say "In the dark? You could easily disturb something."

движки правил: Planner

Эразмотрон

Уже предпринимались радикальные попытки поднять отношения игрока и NPC на новую высоту. Я говорю о так называемом Эразматроне (Erasmatron). Детище Криса Кроуфорда, автора нескольких IF-игр для Macintosh, Эразматрон — это программа, представляющая базирующееся на атрибутах общество.

Кроуфорд наделил всех своих NPC различными атрибутами, которые были призваны отражать их текущее состояние. Это Кроткость, Исполнительность, Великодушие, Доверчивость, Верность, Завистливость, Гордость, Любвеобильность, Голод, Ненадежность, Честность, Привлекательность, Влияние, Дееспособность, Болтливость, Предприимчивость, Жадность, Либидо, Озабоченность, Заботливость, Настроение и Жизнерадостность. Каждый из этих атрибутов динамично изменяется у каждого из персонажей в зависимости от того, что в данный момент этот персонаж видит или делает, с кем он говорит и о чем. В свою очередь, значение каждого из этих показателей влияет на то, что он сделает или скажет, и если хотите, о чем подумает.

Что ж, идея не нова, но она наконец-то реализована. Была выпущена игра «Shattertown Sky», использовавшая эту систему, но, к сожалению, она не особо блистала идеальными NPC из-за обилия недоделок и малого уровня интерактивности непосредственно интерфейса игры (зачастую игроку можно было выбирать лишь один из двух или один из одного (!) вариантов поведения своего персонажа). К тому же, игра, состоящая из сплошных разговоров, не особо развлекает. Однако, главного эта игра достигла — она сделала первый шаг к по-настоящему интерактивным персонажам.

Интерактивность NPC заключается в создании иллюзии, что игрок опять же может «внести» в игровой мир некую информацию, «не заложенную» автором в уста NPC (создать «второй поток»). Грубо говоря, игрок должен быть способен «рассказать» NPC о себе, своих проблемах, сподвигнуть его на какие-то действия, при этом должна сохраняться иллюзия того, что NPC сам решает, что ему сделать, что сказать, а что — нет. Интерактивность может выразиться в том, что NPC сможет действовать самостоятельно, причем в зависимости от обстоятельств, первую попытку предпринять это сделала система Эразматрон, а вторую сможете сделать вы. :-)

Хаскель - игрушка для борщехлебов.

А борщелисп - нет? 8)

Lists and Lists

интерпретатор схемы как Interactive Fiction

интересные исходники + обучалка в текстовой адвентюре.

история Interactive Fiction

вообще, в разрезе лиспов — на мой вгляд, незаслуженно забыта такая штука как Interactive Ficton.

первая текстовая адвентюра, «Collossal Cave Adventure» была написана на Фортране. Код превратился в лапшу из IF-ов и вычисляемых GOTO раннего фортрана.

вторая текстовая адвентюра, Dungeon была написана на лиспе в лаборатории динамического моделирования. использовался свой лисп MDL (Muddle). затем половина лаборатории отправилась на вольные хлеба в стартап — писать Zork.

моделировать текстовую псевдожизнь стало интереснее, чем физические процессы :))

Zork появлялся в виде хака для миникомпьютеров, и требовал громоздкого Lisp-интерпретатора. тем не менее, появилось ощущение, что можно написать «более лучшую реализацию лиспа», для 8-битных домашних компьютеров.

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

затем, после Zork-а и 50 хитовых текстовых адвентюр, фирма Infocom была скуплена Activision на корню и загублена.

возможно, подточил финансовую устойчивость невыстреливший проект для СУБД Cornerstone, выпущенной для IBM PC, в которой аналогично Interactive Fiction можно было общаться со своими данными, задавать правила обработки и т.п.

или просто Sierra On-Line сбила мазу в «графические квесты». или мода прошла на текстовые игори. пипл начал хавать графон заместо тёплых ламповых текстов.

но движок не сдох, и формат Z-code был отреверсен и затем выпущена открытая (ну или полуоткрытая) реализация среды разработки Infrom, которая в версии Infrom7 2006 года напоминает программирование на ЕЯ.

были конечно и другие реализации — как интерпретаторов Z-code (например, на Elisp в емаксе), так и сред для разработки IF.

при этом, сред таких было выпущено порядка 20-30 с 80-х по текущее время.

из них интересны такие как AdvSys, GINAS  — на лиспе, даже в журнале Byte писали какие-то примеры на лиспе. на CL есть например lifp, с примерами

здесь несмотря на много сред, рулят основные 2: TADS с языком как будто язык программирования, и Inform7 с программированием на ЕЯ (в Inform6 был более ЯП)

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

концептуально целостнее, особенно если совместить с Literate Programming.

когда эти самые правила становятся более-менее нетривиальными (например, тот же Эразмотрон).

хотя дьявол, конечно в деталях — в библиотеках правил, rulebook (которые здеь заменяют API).

Чем IF среды интересны сейчас? да это просто более прямой, чуть ли не самый очевидный способ программирования роботов.

просто движок игры должен выдавать несколько выхлопов — не только текстовый для читателя-человека, но и какую-то реализацию в Sexprs, JSON, ... текущего обновлённого дерева мира, и действия, и реакций мира/NPC.

писать два текста вместо одного, второй — исполняемый для REPL.

например, допилить Glulx для standalone клиента такого рода несложно.

или, для хисптеров — допилить JS интерпретатор до поддержки WebGL и 3д движка интерактивного мира в браузере.

Как только ты добавляешь в язык фекспры - ты запрещаешь его компилировать.

неа. это же комбинаторы, которые надо суперкомпилировать другими комбинаторами.

конкретная играчка на виртуальной Z-машине  — это прогонка (см. суперкомпиляция) реализации большого лиспа для миникомпьютеров, специализированная Zork-ом.

Z-машина — результат суперкомпиляции «большого лиспа».

Facade

википедия викия

оффсайт

видео

ещё такая вот мысль:

вот это

...
 ((eq (caar e) 'vau)
    (eval (caddar e)
         (cons (cons (cadar e) 'env)
                 (append (pair (cadar e) (cdr e))
                          a))))))

фактически и есть Environment passing style (во втором параметре eval — окружения, которые могут быть разными).

автор LoperOS, долгостроя LispOS в интервью проводит идею своего продукта: реконфигурируемый вычислитель FPGA, организованный как ‘dataflow CPU’

то есть, такой вот eval «в железе».

вообще нет.

Вообще - да.

applicatives примерно соответствуют функциям — вычисляются все аргументы перед выполнением. operatives (фекспры в kernel) — наоборот, не вычисляется ни одного, и явно требуют вычислять вручную через eval.

Совершенно очевидно, что operatives ничем не отличаются от applicatives. Фишка в том, что не важно когда и как вычисляются аргументы - это не дают ровно никакого увеличения выразительности.

то есть, далее он фактически фигачит комбинаторами с двумя моделями вычисления: с eager (функции, applicatives) и lazy (фекспры, operatives) вычислениями

Ну да. Только они и так эквивалентны. Если у тебя етсь eager язык, то добавление lazy не повышает выразительности. И наоборот. По-этому язык с фекспрами совершенно никак не отличается по выразительности от обычного ЯП.

И, конечно, это знает любой, кто знает, что такое фекспры.

повышает и отличается, т.к. у функций разная семантика вычислений, жадная или ленивая.

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

давай примеров. вот если взять Interactive Fiction вот отсюда с конца

примеров чего? Да, по твоей ссылке нету никакого ЕЯ, даже близко. Но ты ведь об этом знаешь, так?

ЕЯ это код

ЕЯ - это переусложненный код в котором дочерта лишнего. Ты даже факториал на ЕЯ не сможешь написать.

выразительность это хорошо.

Так в том и дело, что ЕЯ очень невыразительны по сравнению с ЯП.

неа.

Да. Язык с фекспрами не может быть скомпилирован. Это алгоритмически неразрешимая задача. И соклько ты не скрещивай суперкомпилированные кластеры метакомбинаторов - она останется алгоритмически неразрешимой.

но таки стандарт устарел

А не укажешь в каких местах? Я вот смотрю, например, на стандартную библиотеку питона и вижу бессистемный набор API без дизайна, это не говоря уже о самом языке, который сам по себе не ортогональный, кривой, с адскими фундаментальными косяками. Вот это «современность». В сравнении с такой «современностью» CL — сверх продуманный и сверх современный язык.

он просто слишком громоздок по сравнению с другими вариантами.

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

Но ИРЛ у нас имена из макроса будут перекрываться с именами переменных (гораздо чаще, чем с именами ф-й)

Нет, идиот. Гораздо реже, практически никогда. Ибо функций (а также generic-ов, классов, структур) в глобальной области видимости традиционно больше, чем глобальных переменных (которые, к тому же в CL принято *bla-bla*). А лексический контекст виден по месту использования макроса, следовательно сразу видно где и что перекрывается. В связи с этим в «ИРЛ»-то как раз lisp-n в контексте мной показанном крайне удобен и изящен :) Чего бы там какой питушок не кукарекал.

но превращается в жуткое говно при хоть сколько-нибудь менее тривиальном паттерне

А если у тебя с десяток паттернов... ко-ко-ко, кудах-тах-тах

Я чётко поставил задачу и привёл пример реализации, ты же, как какой-то обоссаный софист, начал двигать ворота. Ты должен понимать, что в реальном мире все решаемые проблемы заданы чёткими границами и требованием. Но я готов с тобой поиграть в игру «подвигай ворота», но при условии что ты чётко будешь ставить задачи. Т.е. «А если у тебя с десяток паттернов...» придумай макрос, где так будет и приведи реализацию на ракете.

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

Как только появляется такое подозрение, берётся, например, optima. И приведи пример где появится эта печальная «попытка».

О чем и речь - где-то что как-то непонятно распидорасило.

Да ну. Не понятно только тем, кто CL и slime впервые видит (ну или просто идиот). Откроется отладчик, slime перенесёт, подсветит и покажет. Не нужен никакой номер строки и столбца — в интерактивной разработке это бред.

Хотелось бы нормальное сообщение об ошибке.

В приведенном пример, более чем нормальное сообщение об ошибке. Что там не ясно тебе?

Указать позицию некорректного терма я уж не прошу.

И правильно не просишь, дебил. Ведь у тебя в сообщении об ошибке её и в помине нету.

В общелишпике нету гигиены

И это замечательно.

при использовании сложных паттернов и macro-generated macro все пойдет по пизде, это во-первых.

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

Я вот смотрю, например, на стандартную библиотеку питона и вижу бессистемный набор API без дизайна, это не говоря уже о самом языке, который сам по себе не ортогональный, кривой, с адскими фундаментальными косяками.

И в CL все эти недостатки также присутствуют.

Стандарт CL весьма краток и, более того, совершенно без батареек.

Ага, именно - он без батареек но даже при этом нихуя не краток и умудряется быть переусложненным bloated говном.

Нет

Да.

бо функций (а также generic-ов, классов, структур) в глобальной области видимости

Именно! Функции-то почти всегда глобальные, у них обычно адекватные имена с которыми трудно устроить конфликт. А вот переменные - обычно локальные, с простенькими краткими именами, конфликт с которыми устроить элементарно.

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

Так и глобальный видно так же.

Я чётко поставил задачу и привёл пример реализации

Ты привел пример факториала и даже на нем прососал вдвое по простоте и выразительности. А чем сложнее будет задача (понятно же, что факториал - это тривиальщина, не?) тем большая будет у тебя степень отсоса. Ну и практика это подтверждает - я же не выдумываю.

Т.е. «А если у тебя с десяток паттернов...» придумай макрос, где так будет

loop

И приведи пример где появится эта печальная «попытка».

-seq или ~optional паттерны, например.

В приведенном пример, более чем нормальное сообщение об ошибке. Что там не ясно тебе?

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

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

Да легко. Та же задача, тот же (твой) макрос, делаешь jib,re:

(do-select ((id
             foo-bar
             0
             list)
            :table)
  (do-something id foo-bar baz list))

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

А, погоди, тут же речь не про то. Сделай anaphoric if, только который будет работать правильно. Ну то есть:

(let ((it 'huy))
  (aif 2 (print it)))

->
huy

Совсем наркоман штоле? Каким боком он anaphoric и каким боком он нормальный(чем он отличается от if ?) ?

схемач хуже наркомана же.

Да легко. Та же задача, тот же (твой) макрос, делаешь jib,re:

теперь успехах в поиске, из-за какого же это нуля тебе распидорасило пукан.

Ох, ну ты и дебил. Такие вещи всегда отлаживались тривиально. И только самые упёртые питушки продолжают гипнотизировать себя. http://devio.us/~deadlock/slime-dubugger.png

А, погоди, тут же речь не про то. Сделай anaphoric if, только который будет работать правильно. Ну то есть:

То, что ты привёл — поведение обычного if, никак не анафорического, идиот. Хочешь не перекрывать it для дальнейшего использования в теле анафорических макросов, используй: if-let, when-let, when-let* — http://common-lisp.net/project/alexandria/draft/alexandria.html#Data-and-Cont....

loop

Да что ты до loop-а-то доебался? У тебя есть на ракетке писаный loop с той же семантикой и функциональностью как в CL? Ну так выкладывай. Я бы на твоём месте поспешил с этим, не разводя кукаретики.

Ох, ну ты и дебил. Такие вещи всегда отлаживались тривиально.

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

То, что ты привёл — поведение обычного if, никак не анафорического, идиот

(aif 1 (print it))
->
1

чего-то я не припомню, что обычный иф такое умеет. Ну так что, сделаешь?

он anaphoric тем, что определяет it внутри себя.

Да что ты до loop-а-то доебался?

Ну ты же просил пример? Я тебе привел пример. А теперь вот внезапно оказывается, что я «доебался».

У тебя есть на ракетке писаный loop с той же семантикой и функциональностью как в CL?

Зачем?

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

Какая разница сколько строк, дебил? Лёгкость отладки таких простых вещей не зависит от количества строк — http://devio.us/~deadlock/slime-debugger-2.png

Emacs Lisp.

а если у меня макрос раскрывается в этот неправильный do-select?

а если у меня макрос раскрывается в этот неправильный do-select?

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