august upd.

compilers.md

@@ -38,6 +38,12 @@
     - [Какой вы маклиспер?](#какой-вы-маклиспер)
     - [Достаточно смертельная ловушка](#достаточно-смертельная-ловушка)
     - [Мэри Поппинс, до свидания](#мэри-поппинс-до-свидания)
+    - [True == False](#true--false)
+    - [Туда и обратно](#туда-и-обратно)
+      - [FEL](#fel)
+      - [ALFL](#alfl)
+      - [Компиляция ALFL](#компиляция-alfl)
+    - [Этого имени я не слышал уже давно](#этого-имени-я-не-слышал-уже-давно)
 - [Литература](#литература)
 
 
@@ -1167,6 +1173,260 @@ NIL для S-1, будучи Лиспом для экзотической маш
 Да, к середине восьмидесятых готов ситуация с функциональным Лиспом принципиально не отличалась от ситуации в конце семидесятых. Что-то еще не доделано, что-то уже не будет доделано, что-то работает, только не на тех машинах.   
 Но подход к таким проблемам у имплементаторов ФЯ в 80-е, наоборот, принципиально отличался от 70-х. Они хотели использовать для имплементации функциональных языков все что можно. Нашли что использовать и в этом случае.   
 
+### True == False
+
+Весной 81-го Йельский университет, как и многие другие в то время, переходил с PDP-10 на новые машины. Но, в отличие от многих других совершающих этот переход, перескочил через поколение и заменял этот мэйнфрейм не на миникомпьютер VAX-11, а сразу на рабочие станции Apollo с процессором Motorola MC68K. Автору этой идеи Джону О'Доннелу очень нужно было сэкономить деньги. (Это не тот О'Доннел из первой части, который разрабатывал язык с уравнениями, это тот, который в середине 80-х пытался коммерциализировать Йельские наработки по VLIW.)   
+Но есть проблема, с которой уже сталкивались герои нашей истории в прошлой главе. В это время не было Лиспа, который бы работал на тех рабочих станциях, которые купил О'Доннел. И особых надежд на то, что он скоро появится не было. Так что, как и в Inria в это же время, в Йеле решили разрабатывать подходящий Лисп самостоятельно.   
+Но в Йеле и в Inria посчитали подходящими совсем разные Лиспы. В Йеле Лисп для рабочих станций стал писать приятель О'Доннела Джонатан Рис, который решил имплементировать "Схему". И Рису было не сложно уговорить О'Доннела, для которого не было таким уж важным, какой Лисп будет имплементирован, важным было то, что можно будет сменить мэйнфрейм на рабочие станции.   
+Нужно отметить, что желание имплементировать Схему в 81-ом году не было распространенным желанием. Даже знание об этом языке и серии статей Сассмана и Стила все еще не было особенно распространено [Rees2004] [Shiv2001]. В Йеле со всем этим были знакомы человека четыре. Одним из них был Дрю МакДермотт (Drew McDermott), который в 70-е был, как и Стил, студентом Сассмана в МТИ, а в 80-е преподавал в Йеле. Он и научил Риса Лиспу и идеям Стила и Сассмана.   
+Джонатан Рис (Jonathan A. Rees) уходил в академический отпуск и работал в МТИ над имплементацией NIL. Да, над NIL работал студент из Йеля. Потому, что все кто мог стать Лисп-машинистом в МТИ становились Лисп-машинистами. Желающих писать Лиспы для унылых обычных машин не было.   
+Заканчивая свое обучение в Йеле весной 81-го года, Рис прослушал курс Перлиса по функциональному программированию. Один из вспоминающих [Shiv2001] в наши дни об этом курсе утверждает, что Перлис сам узнал о функциональном программировании не так давно. Что сомнительно. Как мы помним, Перлис был одним из тех, кто понимал борьбу функциональной партии авторов ALGOL 60. Но, может быть, имеется функциональное программирование в узком "эдинбургском" смысле. Из его курса можно было узнать о HOPE и, видимо, о каком-то языке Тернера. Вспоминающий вспомнил язык, который Тернер к тому времени еще не создал.   
+Рис получил диплом в 81-ом. И летом того же года был готов имплементировать функциональный Лисп для О'Доннела. Работа началась в июне 1981, помимо Риса в проекте участвовали еще два человека: Норман Адамс (Norman I. Adams) и Кент Питман (Kent Pitman), один из имплементаторов Macsyma и компилятора MacLisp для PDP-10.   
+Питман вместе с Рисом занимались дизайном языка. Мы писали "Схема" в кавычках не просто так. Рис и другие писали имплементацию не одного из Схема-репортов, а нового диалекта Схемы. Рис работал над NIL и совершенно точно не хотел работать над еще одним. И результат отрицания `NIL` (`False`) в Лиспе будет `T` (`True`). Так новую схему и её имплементацию и назвали, тем более что программы, которые писали в Йеле традиционно получали однобуквенные названия вроде `e`, `c`, `z` и `u`. Название T иногда писали Tau, а в подготовленных для печати документов использовали заглавную букву тау Τ.   
+Питман написал на MacLisp для PDP-10 экспериментальный интерпретатор T1, на котором они с Рисом испытывали свои идеи. Этот исследовательский этап проекта закончился в сентябре 81-го с уходом Питмана, который вскоре после этого начал работать над Common Lisp. C сентября 81-го и, по крайней мере до лета 82-го разработка T становится проектом более привычного для разработки ФЯ размера в одну с четвертью ставки. Летом 82-го он, возможно, увеличился до двух, когда к проекту присоединился Джеймс Филбин (James Philbin).   
+Это не единственное сходство T с первыми ФЯ. T, как и Схема, это функциональный Лисп, о функциональности которого заявляется открыто и смело. Никто не прячет её за "консистентностью", как в NIL и Common Lisp. Первая публикация [Rees82] с описанием T повторяет доводы из статей Сассмана и Стила и даже называется по тому же шаблону "LAMBDA: The ultimate software tool". И эффективная имплементация функционального языка на обычных машинах (например, оптимизация хвостовых вызовов) имеет первостепенную важность. Можно даже сказать, что она важнее чем в Схеме. Главное отличие T от Схемы в том, что в T отказались от "антипрологовости" Схемы. Выразительность продолжений в T ограничена по сравнению со Схемой так, чтобы упростить имплементацию языка с использованием обычного стека.   
+Авторы T в принципе не против продолжений и даже предполагали, что в будущем улучшат их поддержку добавлением еще одного специального стека. Вероятно, что главное отличие T от Схемы продиктовано деталями имплементации компилятора. И первый компилятор T, не смотря на все отсылки к Стилу, это вовсе не RABBIT 2. Может быть T и был отрицанием NIL с точки зрения истории идей. Но, с точки зрения истории имплементаций, T это буквально NIL. Рис взял за основу и модифицировал код компилятора NIL для S-1, написанного Стилом на MacLisp. Генераторы кода для более полезных чем S-1 систем написал Адамс, позднее дописывал еще и Филбин.   
+Интерпретатор Питмана не использовался для бутстрапа. Компилятор, над которым работал Рис, был написан на общем подмножестве МакЛиспа и T так, чтоб его можно было с помощью слоя совместимости скомпилировать компилятором MacLisp на PDP-10 как кросс-компилятор, генерирующий код для VAX-11 и MC68K. Этот кросс-компилятор заработал в начале мая 82-го и скомпилировал интерпретатор языка T, написанного на T - T 2 и компилятор T, бывший компилятор NIL, переписанный на подмножество T - TC 1. И компилировал какое-то время, пока код не вышел за пределы поддерживаемого Маклиспом подмножества. T 2.3 была последней версией, которая еще компилировалась кросс-компилятором [TMail].   
+Так что первым из всех наработок функциональных лисперов использовали самый заброшенный проект. Не ожидали? Но, может быть, из-за ненужности и заброшенности компилятора NIL для S-1 его код и можно было брать и использовать. Никто не попытался превратить его в коммерческий продукт. Рис работал над NIL для VAX и использовал некоторые техники имплементации, с которыми познакомился во время этой работы, но, видимо, возможности использовать код NIL для VAX не было.   
+И заброшенность Лиспового проекта, конечно, относительна. Даже в NIL для S-1, по видимому, вложено больше труда, чем в типичный для нашей истории ранний компилятор ФЯ.   
+Правда, Рис использовал код NIL для S-1 далеко не самой последней версии. Так что значительная часть вложенных в него трудов все равно была напрасной. NIL для S-1 был достаточно недоделанным для того, чтоб Рису пришлось то ли имплементировать полностью, то ли просто доделывать имплементацию лексических замыканий. Так что даже от функциональных идей авторов NIL для S-1 особой пользы могло и не быть.   
+T, как это не удивительно, применили для системного программирования, да еще и собирались использовать как промежуточный язык и бэкенд для имплементации обычных императивных языков, так что разрешать мутабельность только как ссылки на изменяемые объекты в куче было неприемлемо. Поэтому замыкания нельзя представлять одним массивом. Но и списки как в RABBIT - не практичный подход, так что в T замыкания - списки массивов.   
+Разумеется, код не использующий ФВП обходится аллокациями только на стеке. Возможно, что даже код, который только принимает функции, как в RABBIT. По крайней мере весной 82-го это планировали сделать.   
+Но почему T не использовал RABBIT? Может быть просто потому, что Рис мог достать код компилятора NIL, но не мог достать код RABBIT. Может быть это еще один довод в пользу того, что RABBIT не особенно подходил для практического использования. По крайней мере, авторы, зная про RABBIT, утверждают, что пригодных для практического использования компиляторов схемы в 1982 году нет [Rees82]. Но, скорее всего, амбициозный CPS-трансформирующий RABBIT был слишком большим для ранних рабочих станций.   
+Как мы выяснили в предыдущей части, для того, чтоб скомпилировать себя RABBIT потребовалось бы на машине с 32бит указателями 2-3Мб памяти. И микрокомпьютерам - рабочим станциям в 81-ом году было еще далеко до очень специальной конфигурации мэйнфрейма, на котором работал RABBIT. Даже рабочие станции на которых компилятор T работал в 83-ем году - Apollo DN300 - имели только 0.5-1.5Мб памяти в зависимости от комплектации [Data83]. Эти рабочие станции поддерживали страничную память и RABBIT бы в ней кое-как уместился, частью на жестком диске. Но понятно, почему такая идея могла выглядеть не особенно хорошо.    
+По крайней мере, у компилятора NIL для S-1 настоящий аллокатор регистров, написанный на основе опыта мейнстримного компилятора Bliss-11. И проект разработки и имплементации T в 81-83гг. скорее напоминает разработку обычного компилятор ФЯ из этой части истории, а не обычный лисповый проект того времени. И получить от лиспового проекта хоть и недоделанный, но компилятор было очень важно для разработчиков T. Тем более, что сами они называют компилятор важнейшей частью имплементации, подчеркивая сходство с "обычными" языками и отличие от обычного Лиспа, главная часть имплементации которого - интерпретатор. 
+Но Рис не считает, что T компилирует так же хорошо, как Bliss-11 [TMail]. Достаточно хорошо, чтоб написать большую часть имплементации T на T, включая и сборщик мусора. Но написать такой сборщик мусора, скорость которого хорошей не считают.   
+И по готовности сборщика мусора мы попробуем оценить готовность имплементации для использования. То, что сборщик мусора какое-то время не был имплементирован - это уже довольно привычно. Но у T был и необычный этап имплементации сборщика. В апреле 82-го, в версии 0.53 была добавлена функция `GC`, но автоматически сборщик не вызывался, только вручную, если нужно [TMail]. Сборщик какое-то время работал не очень хорошо. Например, в первом релизе рантайм падал в случае повторного вызова этой функции.   
+Сборщик стал запускаться автоматически только в мае 83-го года, в версии T 2.6 (TC 1.3). Размер кучи увеличивался тоже автоматически, и был ограничен на UNIX и Aegis (клоне UNIX, написанном в Apollo на Паскале) 3-4Мб. Сборщик был копирующим, но не сборщик Чейни, обходил дерево объектов в глубину.   
+После выхода этой, по видимому, первой практически полезной версии, было еще два релиза T2. В декабре 83-его вышел T 2.7 и в мае 84 T 2.8 (TC 1.4). Последняя версия T2 - 2.9 не была доступна для пользователей, её использовали только для написания T3. Уже в 84-ом году разработчикам T стали доступны гораздо более мощные рабочие станции и у них появились гораздо более амбициозные планы. Но это уже другая история.   
+Насколько быстро работал скомпилированный T2 код? Мы нашли один микробенчмарк [TMail], который позволяет сравнить T 2.7 с некоторыми другими компиляторами, работающими на VAX-11/780
+
+|              | tak 18 12 6 |
+| :----------- | :---------: |
+| Franz(local) |  **0.66**   |
+| T2(local)    |    0.74     |
+| C            |    0.79     |
+| T2(unsafe)   |    1.00     |
+| C(lml)       |    1.06     |
+| Franz        |    1.25     |
+| NIL          |    1.59     |
+| Franz(lml)   |    1.76     |
+| T2           |    2.00     |
+| LML          |    5.88     |
+| VAX ML       |    9.41     |
+
+```
+Franz(local)
+░░░░░░░
+T2(local)
+░░░░░░░░
+C
+░░░░░░░░
+T2(unsafe)
+░░░░░░░░░░░
+C(lml)
+░░░░░░░░░░░
+Franz
+░░░░░░░░░░░░░
+NIL
+░░░░░░░░░░░░░░░░░
+Franz(lml)
+░░░░░░░░░░░░░░░░░░░
+T2
+░░░░░░░░░░░░░░░░░░░░░
+LML
+░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
+VAX ML
+░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
+```
+
+Обратите внимание, что замеры, сделанные разработчиками T 2 и LML (отмечены `(lml)`), отличаются даже для одних и тех же компиляторов. Хотя и сделаны на одной и той же модели компьютера. Но все равно видно, что производительность T2 выглядит неплохо. Наконец-то, через два десятка лет после появления первого компилятора Лиспа, появился компилятор функционального Лиспа, который работает на распространенной машине и который можно использовать как бэкенд для функционального не-лиспа. И его использовали.   
+
+### Туда и обратно
+
+Пол Худак (Paul Raymond Hudak) защитил магистерскую диссертацию по "моделированию понимания музыки" в МТИ в 74-ом. Там он познакомился с антипрологами Planner и Conniver, но предпочитал использовать Лисп, в котором антипролог мог быть EDSL.  
+После получения степени магистра, Худак поработал в Watkins-Johnson Company. В академию он вернулся пять лет спустя в 79-ом.   
+
+#### FEL
+
+С 79-го по 82-ой год Худак писал диссертацию в Университете Юты [Huda2012] [Hugh15] под руководством Роберта Келлера. Там, где разрабатывали Standard Lisp и PSL. Но не только. Университет был также одним из тех немногих, в которых разрабатывали ленивый ФЯ. Для нашей истории довольно важно, что Худак оказался в таком особом месте, но это, по видимому, произошло случайно. По крайней мере Питерсон утверждает [Hugh15], что Худак выбрал Университет Юты из-за увлечения горнолыжным спортом.   
+Научрук Худака Келлер (Robert M. Keller) с 79-го года разрабатывал FGL (Function-Graph Language), который первоначально был нетекстовым языком графов. Но в ходе работы Келлер обнаружил, что писать текст удобнее. Так что появился "текстовый FGL". Раз уж Келлер работал в Университете Юты, где Хирн использовал Лисп с алголоподобным синтаксисом для реализации Reduce 2, то и текстовый FGL получил похожий синтаксис, который несколько адоптировали для ФП [Kell80]. Получился язык в котором функции выглядят так:
+
+```js
+FUNCTION foo(a, b)
+IMPORT bar
+LET x BE baz(a),
+    y BE baz(b)
+RESULT bar(x,y)
+WHERE 
+FUNCTION baz(x) RESULT x 
+```
+
+Тела этих `LET` вычисляются, когда потребуются.   
+Но пока шла работа над FGL закончились 70-е в которые авторы ФЯ, в основном, переизобретали все сами, и наступили 80-е, когда автор ФЯ знает про книгу Берджа, ISWIM, SASL и HOPE. Вот и Келлер узнал про все это и обнаружил, что по собственным же словам "переизобретает ISWIM" и разрабатывает язык родственный SASL [Kell82]. Так что текстовый FGL далее эволюционировал в предсказуемом направлении, но сохранил некоторую самобытность.   
+Келлер заменил `LET` и `WHERE` конструкции одной `{decls, RESULT expr, decls}` в которой декларации могут быть до и/или после выражения, в котором они используются [Lind85].   
+
+```js
+FUNCTION foo([a, b]) = 
+{ x = baz(a),
+  y = baz(b),
+  RESULT bar(x,y),
+  FUNCTION baz(x) = x }
+```
+
+Этот язык получил название FEL (Function-Equation Language) [Kell82]. На `RESULT`-конструкции идеи Келлера о том, как улучшить ISWIM не закончились. Он добавил в FEL три типа применения функций:
+
+```
+f:g:h:x === f(g(h x))
+f|g|h|x === ((f g)h)x
+x;h;g;f === f(g(h x))
+```
+
+и сделал синтаксис еще полегче:
+
+```js
+foo|a:b = 
+{ x = baz:a
+  y = baz:b
+  RESULT bar|x:y
+  baz:x = x }
+```
+
+Наш обычный пример выглядит на FEL так:
+
+```JS
+{ map|f:l =
+    if l = [] then []
+              else { [h,t] = l
+                     RESULT f:h ^ map|f:t }
+  RESULT map|(x => x + y):(1 ^ 2 ^ 3 ^ []) 
+  y = 2 }
+```
+
+Также как и большинство авторов ФЯ этого времени, Келлер собирался типизировать FEL. Причем с выводом типов как в ML и сделать язык более похожим на HOPE, но пока не собрался. Мы вернемся к работе Келлера в следующей главе.   
+
+#### ALFL
+
+Пол Худак ознакомился с FGL/FEL, защитил диссертацию по сборке мусора в 82-ом году и отправился работать в Йель. Там он создал ALFL - ФЯ, который имел пару значительных отличий от FEL. И, как обычно в то время, множество незначительных, которые потребовали бы исправить каждую строку кода при переписывании с одного языка на другой. Если бы было что переписывать, конечно.   
+ALFL в большей чем FEL степени SASL и потому выглядит привычнее и более похожим на современный ФЯ. В применении и декларации каррированных функций больше нет самобытности. Но `result`-конструкция никуда не делась:   
+
+```js
+foo a b == 
+{ x == baz a;
+  y == baz b;
+  result bar x y;
+  baz x == x }
+```
+
+Применение функций все же не в точности как в SASL или, скажем, в Haskell. Применение обладает не самым высоким приоритетом. И оператор `(:)` который используется в ALFL для замены FEL-применения отличается от современного `($)` использованием этой возможности: `twice f x == f f:x`. ALFL также один из первых ФЯ с Хаскельным оператором композиции `(.)`.   
+Более существенные отличия ALFL от FEL тоже из SASL. В ALFL есть не только паттерн-матчинг для вложенных кортежей как в LCF/ML, но и уравнения:
+
+```
+{ map f [] == [];
+  map f (x^L) == f x ^ map f L; 
+  result map (@ x == x + y) [1, 2, 3]; 
+  y == 2 }
+```
+
+Да, Худака, как и Келлера, в ненужности лямбд Ландин с Тернером не убедили.   
+Худак пишет, что паттерн матчинг похож на SASL, HOPE, Prolog и придает коду "логический стиль". Сходство с HOPE преувеличено, но утверждение про SASL и Prolog соответствуют действительности. Как и в SASL и как в Prolog, порядок уравнений имеет значение, а паттерны нелинейные, одинаковые имена в паттернах означают проверку на равенство:
+
+```
+member x (x^L) == true;
+``` 
+
+В ALFL можно не повторять имена функций в группах уравнений и писать
+
+```
+map f [] == [];
+ '  f (x^L) == f x ^ map f L;
+```
+
+и есть отсутствующие в SASL (да и в прочих ФЯ) паттерн-выражения (pattern expressions):
+
+```
+{ k == 5;
+  foo x #(x+k) == true;
+   '  x y      == false;
+  foo 5 10 } % true
+```
+
+Это не n+k паттерны, паттерн-выражения не вводят имена а используют их. Это скорее более компактные, но менее выразительные гарды:
+
+```haskell
+k = 5
+foo x y | y == x+k  = True
+        | otherwise = False
+foo 5 10 -- True
+```
+
+ALFL не позаимствовал из SASL строки как ленивые списки символов. В SASL это специальный объект кучи. Не позаимствовал из SASL и стандартную библиотеку. Функции работы со списками в ALFL как в FEL. Оператор свертки `[f,init]//list`, zip-n оператор `f\\listOflists`. Оператор map `f||list`, который обрабатывает и вложенные списки. Оператор `::`, работающий как `sequence` для `[]`-аппликатива.   
+Не смотря на паттерн-матчинг, в библиотеке ALFL есть аналоги лисповых составных селекторов, вроде `hhd` и `httl`.   
+Не позднее 84-го года в ALFL добавили нотацию для построения списков с удалением дубликатов, "упорядоченные множества" `{* ... *}` и без, "упорядоченные мультимножества" `[* ... *]`. Как в языках Тернера, но не совсем:
+
+```
+[* [a,b] ! ["left", a] <- as ; ["right", b] <- bs ! a <> b *]
+```
+
+Отличие от современной такой нотации в том, что "генераторы" и "фильтры" не могут чередоваться: `[* результат ! генератор ... ; генератор ! фильтр ; фильтр ... *]`. Сходство с современной нотацией и отличие от первых и опубликованных к этому времени экспериментов Тернера в том, что слева от `<-` паттерн, а не только имя. Это нововведение может быть независимым изобретением, но может и не быть.   
+
+#### Компиляция ALFL
+
+ALFL "вырос" из "игрушечного" языка Mini-FPL для курса по разработке компиляторов [Huda84]. Нам не известно, в чем было отличие между ними. Можно предположить, что в основном в "игрушечности". Имплементацию ALFL делали более практичной.   
+Простота комбинаторного интерпретатора Тернера привлекательна для имплементатора ленивого ФЯ. И многие оптимизации свертывания констант и вынесения вычисления из "цикла" просто работают по мере выполнения кода. Тривиальна и межпроцедурная оптимизация, границы процедур просто исчезают в получающемся комбинаторном супе. Но что толку от всех этих оптимизаций, если размер комбинаторов слишком мал и накладные расходы интерпретации доминируют? Комбинаторный интерпретатор работает, как пишет Худак, "невыносимо" медленно. Получается не очень практично.   
+Но Худак не попытался изменить соотношение между полезной работой и накладными расходами на интерпретацию как Хьюз, Йонссон и другие. Худак узнал о не особенно хороших результатах Хьюза, но, по видимому уже после того, как у него самого появилась другая идея.   
+Что если отказаться от интерпретации во время исполнения вовсе? Пусть комбинаторный интерпретатор работает во время компиляции, оптимизируя код частичным его вычислением, пока не останется то, что можно вычислить только во время выполнения, пока не исчерпает свою полезность. Получившиеся в результате комбинаторы конвертируются обратно в лямбды и компилируются. Ленивость реализуется самомодифицирующимися санками. И анализ строгости позволяет использовать эти санки только там, где без них не обойтись. И Худак считает, что чаще всего без них можно будет обходиться. Анализ разделения также позволяет сохранять как граф в куче только разделяемые значения, а не все промежуточные результаты.   
+Тернер не убедил Худака, что имплементация лямбд с помощью окружений такая уж серьезная проблема. Худак прочитал у Стила, что проблема решена. Так что Худак начинает компиляцию с лямбды и заканчивает ей. Комбинаторы - только промежуточное представление для оптимизатора.   
+Но не все составные части уже готовы, так что их остается только собрать в компилятор ФЯ. Алгоритм Тернера по преобразованию лямбд в комбинаторы дает плохой комбинаторный код для частичного выполнения. Так Тернер смело вставляет `Y` для всех групп объявлений, даже если нет рекурсии и он не нужен. И частичный вычислитель Худака не производит редукцию `Y`. Так что Худак изменил алгоритм.   
+Разумеется, подход Худака сохраняет не все плюсы комбинаторного интерпретатора. Интерпретатор оптимизирует только код, который выполняется. В отличие от него, компилятор ALFL оптимизирует даже неиспользуемое и генерирует много кода.   
+Худак обсуждает то, что частично выполняющий компилятор может зациклится во время компиляции. Да, он не редуцирует `Y`, но ALFL - бестиповый язык и отсутствующий тайпчекер не остановит зацикливающийся код вроде такого:
+
+```
+{ f x == x x;
+  result f f }
+```
+
+Но Худак не особенно опасается этого, не считает, что программист часто такое будет писать.   
+Первый компилятор ALFL написан Худаком и Дэвидом Кранцом (David Kranz) на T в 83-ем году. По крайней мере его описание [Huda83] сделано в 83-ем и опубликовано в январе 84-го.   
+Парсинг, преобразование из лямбд в комбинаторы и их частичная редукция, а также исключение повторяющихся выражений объединены в один проход. Не совсем понятно почему. Может это осталось от более "игрушечной" имплементации, которая могла быть просто комбинаторным интерпретатором и должна была работать используя меньше памяти. Может быть это сделано потому, что дерево комбинаторов до оптимизации часто больше соответствующего дерева лямбд и имплементаторам не хотелось держать его в памяти целиком. Может быть комбинаторная часть компилятора написана так потому, что ее смогли так написать из-за достаточной для этого простоты комбинаторного подхода.   
+Остальная часть компилятора написана совсем не так. Полученные в результате первого прохода комбинаторы транслируются в машкод еще в четыре прохода.   
+Второй проход это трансляция в некаррированные лямбды со многими параметрами - "макро-комбинаторы". Трансляция в макро-комбинаторы это независимо переизобретенная Худаком неполная трансляция в супер-комбинаторы Хьюза.   
+На третьем проходе - анализ строгости и разделения. Первоначально анализ строгости и разделения узлов производился над тернеровскими комбинаторами, но позднее решили, что делать его для лямбд удобнее.   
+На четвертом проходе эскейп-анализ определяет какие окружения для лямбд можно размещать на стеке, а какие придется размещать в куче. Как это делают RABBIT и TC.   
+На пятом проходе генерируется код, ленивые аргументы и ленивые разделяемые узлы имплементируются как самомодифицирующиеся санки. Самомодифицирующийся санк не создает дополнительной косвенности ссылок, как это часто бывает в таких имплементациях ленивости, ссылка на санк переписывается ссылкой на результат. Компилятор генерирует код для PDP-10.   
+Насколько быстрый код? Судя по всему, не особенно быстрый. Худак с Кранцом не приводят измерений, но называют результаты "вдохновляющими". Утверждают, что намного быстрее, чем комбинаторный интерпретатор. И в это легко поверить. Но вот сравнивать производительность с Лиспом "сложно". Первый компилятор - это только демонстрация идеи, оправдывается Худак. Анализы, которые делает компилятор ALFL пока что слишком консервативны. Но это, утверждает Худак, может быть исправлено.   
+К тому же, в компиляторе ALFL не используются "обычные оптимизации" вроде аллокации регистров и оптимизации хвостового вызова. Ну, не все первые компиляторы ФЯ сносно аллоцируют регистры. Но можно только порадоваться тому, что в 83-ем году оптимизация хвостового вызова уже считается обычной.   
+Ну а какой компилятор делает эти "обычные" оптимизации? Правильно, TC. И следующий логичный шаг, который делает Худак - отказаться от собственного кодогенератора и использовать TC в качестве бэкенда для компилятора ALFL. Этот второй компилятор ALFL назывался Alfa-Tau заработал не позднее октября 84-го [Huda84]. Над компилятором помимо Худака работали Фред Дуглис (Fred Douglis) и сменившая его в 84-ом Эдриенн Блосс (Adrienne G. Bloss), работали Джонатан Янг (Jonathan Young) и Лорен Смит (Lauren Smith). Смит имплементировала нотацию для построения списков, которой в первом компиляторе ALFL еще не было.   
+Правда, сравнений производительности так пока и не появилось.   
+
+### Этого имени я не слышал уже давно
+
+Итак, в начале 80-х лисперы сделали движение в сторону общего Маклиспа, и даже общего Лиспа. И, к тому же, Лиспа функционального. И это усилие, конечно, оказало влияние на те языки, на которые Лисп обычно оказывал влияние. На Лиспы для тех, кто недолюбливает Лисп, такие как POP.   
+После конца бывшей группы экспериментального программирования в Эдинбурге, там уже не находили сил или даже интереса для спасения POP-2 с PDP-10. Но POP-2 - не последняя версия POP.   
+Аарон Сломан (Aaron Sloman) ознакомился [Slom89] с POP-2 в начале 70-х, когда работал над распознаванием образов в Эдинбурге и хотел использовать язык для преподавания в Университете Сассекса (University of Sussex). Для этого, правда, существовало серьезное препятствие. Университет был слишком бедным для того, чтоб позволить себе мэйнфрейм, на котором бы работала какая-нибудь из имплементаций POP-2.   
+Какое-то время в Сассексе использовали WPOP на Эдинбургском PDP-10 дистанционно, но такое использование оставляло желать лучшего. В Сассексе могли себе позволить _миникомпьютер_ и в 75-ом году Стив Харди (Steve Hardy) выбрал для университета компьютер PDP-11/40, популярный миникомпьютер DEC. За полгода, к январю 76-го, Харди написал на ассемблере байткод-интерпретатор урезанного POP-2, который назвал POP-11. Для неурезанного POP у PDP-11 было слишком мало памяти. Но это ограничение было временным. В DEC не собирались закрывать успешную линейку машин, к которой принадлежал PDP-11 и продолжили её, выпустив компьютер с большим адресным пространством.   
+Первые VAX11/780, сначала с 2.5Мб памяти, появились в Университете Сассекса в 81-ом году. Летом Сломан принял на работу своего бывшего студента Джона Гибсона (John Gibson), одного из дистанционных пользователей POP, и тот написал компилятор POP-11 на POP-11 для VAX-11. Для бутстрапа использовали интерпретатор Харди и получили первую работающую версию за несколько часов до первого занятия курса Сломана, на котором тот хотел использовать POP.   
+Увеличение памяти позволило вернуть урезанные в свое время фичи POP-2, вроде динамических списков и рекордов. POP-11 прошел через игольное ушко PDP-11 сначала потеряв многие фичи POP-2, а потом вернув их на более подходящей машине, так что существенно отличался от POP-2. И, в добавок к этим исторически обусловленным отличиям, были, конечно же, сделаны множество мелких изменений. Например, ключевые слова для объявлений и лямбд.   
+
+```
+define map(list, proc);
+    if null(list) then []
+    else
+        proc(hd(list)) :: map(tl(list), proc)
+    endif
+enddefine;
+
+z = 2;
+map([1 2 3], procedure(x,y); x + y endprocedure(%z%))
+```
+
+Некоторый синтаксис из POP-2 пока что оставался для совместимости, но едва ли можно было легко использовать POP-11 для спасения с PDP-10 имплементации HOPE на POP-2. Даже если бы у кого-то и было желание это сделать.   
+Как вы поняли, имплементаторы POP-11 - из той разновидности имплементаторов ФЯ, которые имплементируют бодро, весело и много. И POP-11 для VAX - имплементация, которая оптимизирована для этого. В POP-11 были макросы, которые раскрываются не только в синтаксически правильный POP-11, но и в инструкции виртуальной машины. Это должно было позволить легко писать фронтенды для других языков.   
+И в начале 80-х все больше и больше имплементаторов ФЯ хотели имплементировать не древний и неудобный язык вроде POP, а современный, с уравнениями и паттерн-матчингом. Вот и разработчики и пользователи POP-11 решили использовать его для имплементации такого языка. Для имплементации Пролога.   
+В 82-ом году Крис Меллиш (Chris Mellish) и Стив Харди придумали как имплементировать Prolog с помощью инструментария для расширения POP-11. Меллишу удалось это сделать, только скорость исполнения кода получилась не такая хорошая, как у передовых имплементаций Пролога. Одна из причин - то, что можно было аллоцировать на стеке в специализированной имплементации Пролога, приходилось размещать в куче в виде объектов POP-11. Использование таких объектов было необходимо для прозрачного интеропа между языками. Пользователи POP-11 хотели писать программы на нескольких языках и приоритизировали такой интероп. Другая причина - виртуальная машина просто не имела нужных для эффективной имплементации фич.   
+Так что Гибсон добавил в виртуальную машину стек продолжений и прочие нужные для имплементации Пролога вещи. Новый компилятор назвали POPLOG. Название больше не менялось но языки продолжили добавлять. Сначала новые языки имплементировались с помощью макросистемы. Затем некоторые из них получали более качественную поддержку компилятора и ВМ и попадали в базовый комплект поставки.   
+Следующим после Пролога языком, который имплементировал POPLOG, стал Лисп. Джон Каннингем (Jon Cunningham) имплементировал подмножество MacLisp. Но эпоха MacLisp подходила к концу, начиналась эра Common Lisp. И в 83-ем году, не дожидаясь окончания работы над описанием Common Lisp, имплементаторы POPLOG начали работу над имплементацией Common Lisp. И, что более важно для нашей истории, добавлением в виртуальную машину поддержки лексической видимости, которую требовал функциональный Лисп. Но это уже другая история.   
+
 ПРОДОЛЖЕНИЕ СЛЕДУЕТ
 
 Литература
@@ -1203,6 +1463,7 @@ NIL для S-1, будучи Лиспом для экзотической маш
 [Clac85]: Clack, C., Peyton Jones, S.L. (1985). Strictness analysis — a practical approach. In: Jouannaud, JP. (eds) Functional Programming Languages and Computer Architecture. FPCA 1985. Lecture Notes in Computer Science, vol 201. Springer, Berlin, Heidelberg. doi:10.1007/3-540-15975-4_28   
 [Cousot]: Cousot, Patrick. “The Contributions of Alan Mycroft to Abstract Interpretation.”   
 [Dama84]: Luís Damas. “Type assignment in programming languages.” (1984).   
+[Data83]: Datapro report M11-075-10 8311 http://bitsavers.informatik.uni-stuttgart.de/pdf/datapro/datapro_reports_70s-90s/Apollo/M11-075-10_8311_Apollo_Domain.pdf   
 [Deme78]: Alan Demers, James Donahue, and Glenn Skinner. 1978. Data types as values: polymorphism, type-checking, encapsulation. In Proceedings of the 5th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '78). Association for Computing Machinery, New York, NY, USA, 23–30. doi:10.1145/512760.512764   
 [Deme80]: Alan J. Demers and James E. Donahue. 1980. The Russell Semantics: An Exercise in Abstract Data Types. Technical Report. Cornell University, USA.   
 [Demers]: Alan J. Demers https://www.cs.cornell.edu/annual_report/99-00/Demers.htm   
@@ -1223,6 +1484,9 @@ NIL для S-1, будучи Лиспом для экзотической маш
 [Hear2005]: Hearn, Anthony C.. “REDUCE: The First Forty Years.” Algorithmic Algebra and Logic (2005).   
 [HOL88]: HOL88 https://github.com/theoremprover-museum/HOL88   
 [Holm98]: Holmevik, Jan Rune. "Compiling Simula: A historical study of technological genesis." (1998) https://staff.um.edu.mt/jskl1/simula.html   
+[Huda83]: Paul Hudak and David Kranz. 1984. A combinator-based compiler for a functional language. In Proceedings of the 11th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '84). Association for Computing Machinery, New York, NY, USA, 122–132. doi:10.1145/800017.800523   
+[Huda84]: Hudak, Paul. ALFL Reference Manual and Programmer's Guide. Yale University, Department of Computer Science, 1984.   
+[Huda2012]: Paul R. Hudak, CV https://www.cs.yale.edu/homes/hudak/Resumes/vita.pdf   
 [Huet]: Gérard Huet, biography https://gallium.inria.fr/~huet/biography.html   
 [Huet86]: Huet, G. (1986). Theorem proving systems of the Formel project. In: Siekmann, J.H. (eds) 8th International Conference on Automated Deduction. CADE 1986. Lecture Notes in Computer Science, vol 230. Springer, Berlin, Heidelberg. doi:10.1007/3-540-16780-3_138   
 [Huet15]: Gérard Huet, Thierry Coquand and Christine Paulin. Early history of Coq, September 2015 https://coq.inria.fr/refman/history.html   
@@ -1230,16 +1494,20 @@ NIL для S-1, будучи Лиспом для экзотической маш
 [Hugh82b]: R. J. M. Hughes. 1982. Super-combinators a new implementation method for applicative languages. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 1–10. DOI:10.1145/800068.802129   
 [Hugh83]: Hughes, Robert John Muir. "The design and implementation of programming languages." Ph. D. Thesis, Oxford University (July 1983) (published as Technical Monograph PRG-40 September 1984).   
 [Hugh2005]: John Hughes, My Most Influential Work https://www.cse.chalmers.se/~rjmh/citations/my_most_influential_papers.htm   
+[Hugh15]: John Hughes, John Peterson. Tribute to Paul Hudak, ICFP 2015 https://www.youtube.com/watch?v=Hivzs-LUmU0   
 [Hugh23]: The Haskell Interlude #36 – John Hughes, Recorded 2023-09-21. Published 2023-10-31 https://haskell.foundation/podcast/36/   
 [John84]: Efficient Compilation of Lazy Evaluation. Thomas Johnsson
 SIGPLAN '84: Proceedings of the 1984 SIGPLAN symposium on Compiler construction June 1984 Pages 58–69 doi:10.1145/502874.502880   
 [John85]: Johnsson, T. (1985). Lambda lifting: Transforming programs to recursive equations. In: Jouannaud, JP. (eds) Functional Programming Languages and Computer Architecture. FPCA 1985. Lecture Notes in Computer Science, vol 201. Springer, Berlin, Heidelberg. doi:10.1007/3-540-15975-4_37   
 [John95]: Thomas Johnsson. Graph reduction, and how to avoid it. In Electronic Notes in Theoretical Computer Science Volume 2, 1995, Pages 139-152 DOI:10.1016/S1571-0661(05)80191-4   
 [Joy86]: Joy, William N., Susan L. Graham, Charles B. Haley, Marshall Kirk McKusick, and Peter B. Kessler. "Berkeley Pascal User’s Manual Version 3.1− April 1986.   
+[Kell80]: Robert M. Keller. 1980. Divide and concer: Data structuring in applicative multiprocessing systems. In Proceedings of the 1980 ACM conference on LISP and functional programming (LFP '80). Association for Computing Machinery, New York, NY, USA, 196–202. doi:10.1145/800087.802806   
+[Kell82]: Keller, RobertM. "FEL: An Experimental Applicative Language." 情報処理学会研究報告プログラミング (PRO) 1982, no. 49 (1982-PRO-003) (1982): 73-79.   
 [Krei2002]: Kreitz, Christoph. "The Nuprl Proof Development System, Version 5: Reference Manual and User’s Guide." Department of Computer Science, Cornell University (2002)   
 [LCF77]: Code for LCF Version 5, Oct 1977 https://github.com/theoremprover-museum/LCF77   
 [LCF92]: cambridge lcf 1.5 (25-AUG-92) https://github.com/kohlhase/CambridgeLCF   
 [Lieb81]: Lieberman, Henry, and Carl Hewitt. "A Real Time Garbage Collector Based on the Lifetimes of Objects" AI Memo No. 569A October, 1981.   
+[Lind85]: Gary Lindstrom. 1985. Functional programing and the logical variable. In Proceedings of the 12th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '85). Association for Computing Machinery, New York, NY, USA, 266–280. doi:10.1145/318593.318657   
 [MacQ82]: D. B. MacQueen and Ravi Sethi. 1982. A semantic model of types for applicative languages. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 243–252. doi:10.1145/800068.802156   
 [MacQ14]: Luca Cardelli and the Early Evolution of ML, by David MacQueen. A paper presented at the Luca Cardelli Fest at Microsoft Research Cambridge on Sept. 8, 2014.   
 [MacQ15]: MacQueen, David B. The History of Standard ML: Ideas, Principles, Culture https://www.youtube.com/watch?v=NVEgyJCTee4   
@@ -1262,14 +1530,19 @@ SIGPLAN '84: Proceedings of the 1984 SIGPLAN symposium on Compiler construction
 [Paul22b]: Lawrence Paulson. Memories: Edinburgh ML to Standard ML https://lawrencecpaulson.github.io/2022/10/05/Standard_ML.html   
 [Paul23]: Lawrence Paulson. Curriculum Vitae https://www.cl.cam.ac.uk/~lp15/Pages/vita.pdf   
 [Phil99]: Phillips, Eve Marie. "If it works, it's not AI: a commercial look at artificial intelligence startups." PhD diss., Massachusetts Institute of Technology, 1999.   
+[Rees82]: Jonathan A. Rees and Norman I. Adams IV. 1982. T: a dialect of Lisp or LAMBDA: The ultimate software tool. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 114–122. doi:10.1145/800068.802142   
+[Rees2004]: Jonathan Rees, The T Project http://mumble.net/~jar/tproject/   
 [Sain84]: Emmanuel Saint-James. 1984. Recursion is more efficient than iteration. In Proceedings of the 1984 ACM Symposium on LISP and functional programming (LFP '84). Association for Computing Machinery, New York, NY, USA, 228–234. doi:10.1145/800055.802039   
 [Sait82]: N. Saito. ML System on Vax Unix. README for Saito’s Unix port of VAX ML, March 1982.   
 [SERC83]: DISTRIBUTED INTERACTIVE COMPUTING NOTE 781 https://www.chilton-computing.org.uk/acd/pdfs/dic/dic781.pdf   
+[Shiv2001]: Olin Shivers, History of T https://paulgraham.com/thist.html   
+[Slom89]: Sloman, Aaron. "The Evolution of Poplog and Pop-11 at Sussex University." POP-11 Comes of Age: The Advancement of an AI Programming Language (1989): 30-54.   
 [Stal2002]: Richard Stallman. My Lisp Experiences and the Development of GNU Emacs. https://www.gnu.org/gnu/rms-lisp.html   
 [Stee82]: Guy L. Steele. 1982. An overview of COMMON LISP. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 98–107. doi:10.1145/800068.802140   
 [Stee96]: Guy L. Steele and Richard P. Gabriel. 1996. The evolution of Lisp. Uncut draft.   
 [Stee96b]: Guy L. Steele and Richard P. Gabriel. 1996. The evolution of Lisp. History of programming languages---II. Association for Computing Machinery, New York, NY, USA, 233–330. doi:10.1145/234286.1057818   
 [Thom76]: Christopher Mark Thomson. The Run-Time structure of an ALGOL 68 Student Checkout Compiler. Master's thesis, Department of Computing Science, University of Alberta, 1976.   
 [Thom78]: C. Thomson. ALGOL 68 Compiler for IBM S/370. Announcement. SIGPLAN Notices, Volume 13, Number 11 (November 1978), page 11.   
+[TMail]: T mailing list archive. http://people.csail.mit.edu/riastradh/t/tmail.tar.bz2   
 [Turn79]: Turner, D. A. (1979). A new implementation technique for applicative languages. Software: Practice and Experience, 9(1), 31–49. doi:10.1002/spe.4380090105   
 [Wray86]: Wray, Stuart Charles. Implementation and programming techniques for functional languages. No. UCAM-CL-TR-92. University of Cambridge, Computer Laboratory, 1986. DOI: 10.48456/tr-92   

index.md

@@ -12,6 +12,8 @@
 
 ---------------------------
 
+[Обновление 2024-08-31](compilers.md#true--false)
+
 [Обновление 2024-08-08](compilers.md#лисп-который-покончит-с-лиспами)
 
 [Обновление 2024-06-30](compilers.md#живые-ископаемые)