thegeneralist01/fphistoryru
1
Fork 0
mirror of https://github.com/thegeneralist01/fphistoryru synced 2026-01-09 13:50:24 +01:00
Code Issues Activity

part 1 complete

Browse source
This commit is contained in:
klapaucius 2025-01-09 01:18:51 +05:00
parent 8bc705eb79
commit a3233bae07
2 changed files with 320 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

320
compilers.md
View file

@ -2,7 +2,7 @@
=======
- [История применения и оценки функционального программирования.](#история-применения-и-оценки-функционального-программирования)
- [Часть 1: Первые компиляторы.](#часть-1-первые-компиляторы)
- [Часть 1: Каталог компиляторов.](#часть-1-каталог-компиляторов)
- [От Луки](#от-луки)
- [Лука Карделли](#лука-карделли)
- [Пари PASCAL](#пари-pascal)
@ -54,11 +54,19 @@
- [Скобочный потолок](#скобочный-потолок)
- [Персональный миникомпьютер](#персональный-миникомпьютер)
- [Персональный микрокомпьютер](#персональный-микрокомпьютер)
- [Сон Черного Короля](#сон-черного-короля)
- [Железное дерево](#железное-дерево)
- [The data must flow](#the-data-must-flow)
- [Группа функциональных языков](#группа-функциональных-языков)
- [Конец группы функциональных языков](#конец-группы-функциональных-языков)
- [Алиса в ржавом поясе](#алиса-в-ржавом-поясе)
- [Вообразите машины](#вообразите-машины)
- [Голатак](#голатак)
- [Литература](#литература)
Часть 1: Первые компиляторы.
============================
Часть 1: Каталог компиляторов.
==============================
Как мы выяснили в предыдущей - нулевой - части истории, к началу 80-х уже появился функциональный язык, похожий на современные - HOPE. Но имплементаторы ФЯ не все и не сразу захотели имплементировать языки, похожие на HOPE. Были желание и, главное, возможность имплементировать более необычные для нас функциональные языки.
Поэтому в первые годы десятилетия появилось несколько имплементаций ФЯ, которые только позднее стали имплементациями ФЯ, похожих на HOPE. Или были использованы как части таких имплементаций. Первая часть истории функционального программирования будет о них.
@ -1750,14 +1758,296 @@ Symbolics LM2
И, конечно же, MC68020 стал очень успешен и с максимальной частотой выдавал 10 MIPS. В 86-ом году за эти 40 тысяч еще без скидок можно было купить рабочую станцию с 16МГц MC68020 (4.8 MIPS) и 12Мб-16Мб памяти, а сравнимая с Лисп-машиной конфигурация обошлась бы тысяч в десять [Apol86]. Вот эти-то машины и покупали.
Но триумф микрокомпьютеров не единственная причина того, что желающих покупать Лисп-машины было мало. У тех, кто продавал Лиспы для микрокомпьютеров тоже начинались проблемы. И Лисп-машинисты придумали, со временем, как обратить триумф микрокомпьютеров себе на пользу. Что тоже им не особенно помогло. Но эти остальные причины упадка Лисп-машин в частности и Лиспа вообще - уже другая история.
ПРОДОЛЖЕНИЕ СЛЕДУЕТ
### Сон Черного Короля
Итак, события развивались не самым удачным образом для ФП-машин, похожих на Лисп-машины. Но не обязательно для идей Бэкуса. Да, разработчики SKI-машин вдохновлялись идеями Бэкуса, но не очень-то им следовали. И эти машины не были такими уж анти-фон-Неймановскими. Так что, разобравшись с ними, мы переходим к машинам, которые сами вдохновили Бэкуса и которые он сам называл как примеры машин анти-фон-Неймановских.
SKI-машины, как и Лисп-машины до (и немного после) них, требуют от пользователя разнообразных жертв и лишений ради того, чтоб функциональные языки и Лиспы работали быстро. И пользователи были не готовы к таким жертвам. Но что если подумать не о том, что вы можете сделать для функционального программирования, а о том, что функциональное программирование может сделать для вас? Что если такой подход понравится пользователям больше? Для чего вообще ФП нужно и для чего оно подходит лучше? У Бэкуса есть ранние версии ответа на этот вопрос: функциональные языки нужны и лучше подходят для программирования параллельных компьютеров. И, конечно же, нашлись желающие проверить правильность этого ответа.
И если размах проектов по созданию SKI-машин выглядит впечатляюще по сравнению с усилиями по написанию компиляторов ФЯ для обычных машин, то масштаб разработки параллельных ФП-машин затмевает уже SKI-машины.
#### Железное дерево
> Это самое далекое отступление от архитектуры фон Неймана, которое я когда-либо видел.
> Джон Бэкус, Может ли программирование быть освобождено от стиля Фон-Неймана? [Back78]
Настоящий Анти-Фон-Нейманизм предписывает бороться за локальность данных. Но разработанные к концу 70-х способы имплементировать высокоуровневые языки последовательно анти-локальны. Они сводятся к прыжкам по развесистыми деревьями ссылок на ссылки, с ударами о память при каждом прыжке. Но что если вернуться в "доисторические" времена, когда не было всех этих виртуальных машин, но на новом технологическом витке? И машина Маго (Gyula A. Magó) [Vegd84] исполняет код по большому счету так же, как человек, вооружённый ручкой и бумагой: переписывает строки. Не сам текст программы на FFP, Бэкусовском FP без синтаксического сахара, но строки байтов.
Вычислительные узлы соединяются как узлы бинарного дерева. Вычислительный узел применяет одну строку-лист к другой строке в своей локальной памяти. Результат этого применения становится одним из листов для другого вычислительного узла. На каждом уровне дерева вычислительные элементы могут работать параллельно и независимо. Все локально, никаких ссылок нет.
Понятно, что у отсутствия ссылок масса проблем. Не работает не только изобретение Вадсворта, избавляющее от необходимости перевычислять одно и то же снова и снова в ленивых языках. Появляется много работы там, где её уже давно никто не ждет. Передаете что-то в две разные функции? Копирование. Рекурсия? Копирование, копирование, копирование. Результат редукции не становится меньше по какой-то еще причине? Много, много копирования для перестраивания дерева.
И даже если машина, в отличие от Фон-Неймановской, оптимизирована для копирования, все равно копированию соревноваться с его отсутствием не так легко. Тем более всем этим копированиям соответствует очень мало полезной работы. Гранулярность распараллеливания очень "тонкая".
Поэтому вся история развития машины Маго сводится к уменьшению копирования [Mago81] [Mago82] и укрупнению "гранул".
И все это развитие происходит без построения реального железа. Разработчики компилятора Пролога в FFP называют [Kost84] главной проблемой машины Маго то, что никакой машины еще нет.
(F)FP не соответствует даже гораздо более широким определениям ФЯ чем наше и мы не пишем историю Пролога, но позднее бэкенд для машины Маго разрабатывали и для более релевантного для нашей истории компилятора. Так что к машине Маго мы еще ненадолго вернемся. Ненадолго потому, что разработка машины Маго и связанная с ней деятельность не оказали такого значительного влияния, какое оказали работы связанные со второй разновидностью упомянутых Бэкусом Анти-Фон-Неймановских машин.
#### The data must flow
> Языки, разработанные для поддержки таких машин, были по сути функциональными языками. Но имели некоторые отличительные особенности, обусловленные архитектурой этих машин (так же, как и особенности императивных языков обусловлены Фон-Неймановской архитектурой): они обычно языки первого порядка, строгие и в некоторых случаях не поддерживают даже рекурсию.
> Пол Худак, Зарождение, эволюция и применение функциональных языков программирования. [Huda89]
Другая упомянутая Бэкусом альтернатива машинам Фон-Неймана - это dataflow-машины. Dataflow - это направленные графы в которых вершины - это операции вроде копирования и двух видов переключателей и другие встроенные операции вроде арифметических, а ребра - неограниченные FIFO-очереди токенов (сообщений) между ними. Если для операции есть все необходимые токены во входящих очередях - она выполняется и помещает все результирующие токены в исходящие очереди. Идея развивалась с 60-х годов, но в таком виде её сформулировал в середине 70-х Жиль Кан (Gilles Kahn), работавший с такими героями нашей истории как Жерар Юэ и МакКвин, к чему мы еще вернемся.
Каждый узел делает очень немного работы и гранулярность параллелизма поэтому очень тонкая. Как и машине Маго, для работы каждого узла достаточно только локальных очередей, но, разумеется, на практике каждому из них не соответствует вычислительный элемент с очередями в локальной памяти. Вычислительные элементы ищут, для каких вершин графа уже есть все необходимые входящие токены в одной общей очереди в одной общей памяти и возвращают в эту общую очередь новые исходящие токены.
Мы не ставим себе целью написать историю dataflow-машин и языков. Она сопоставима по объему и продолжительности с историей тех ФЯ, что мы пишем, но не особенно тесно с ней связана. На некоторые dataflow-языки повлияли ранние ФЯ вроде ISWIM, но сами они как правило были языками первого порядка. Но, со временем, появились и исключения.
Пока мы рассказывали о взлете и падении ИИ-лаборатории МТИ, мы уже упоминали, что параллельно этим событиям в МТИ происходили и другие, вроде работы над MULTICS. И новый герой нашей истории Джек Деннис (Jack Bonnell Dennis) [Dennis], поработав над MULTICS, занялся другими вопросами и стал одним из основных и наиболее влиятельных dataflow-мыслителей и руководителем группы вычислительных структур, которая занималась преимущественно dataflow. С осени 73-го до января 74-го упомянутый уже нами язык CLU, от которого происходили абстрактные типы в LCF/ML, разрабатывался совместно с группой Денниса и должен был стать dataflow-языком [Lisk93]. Но проект этого единого языка вскоре разделился на два, и группа Денниса стала разрабатывать свой собственный язык VAL. Как и CLU, это был Алгол, идущий против функционального течения, определившего историю Алгола того времени. Анти-функциональность CLU, языка со сборщиком мусора, была обусловлена, в основном, неприязнью, которую Лисков испытывала к Algol 68. Но для VAL не так-то просто было быть ФЯ по техническим причинам. Статические dataflow Денниса не позволяли поддержать даже рекурсию.
Это ограничение было преодолено с изобретением динамического dataflow, которыми занимался более важный герой нашей истории - Арвинд.
Арвинд (Arvind Mithal, но практически всегда используется только мононим Arvind) с 74-го по 78-ой год работал в Калифорнийском университете в Ирвайне (University of California, Irvine) [Arvind] над динамическим dataflow и языком ID (Irvine Dataflow). Эту работу он продолжил в МТИ в группе Денниса, где язык стал просто Id, без расшифровки.
ID имел кое-какие функциональные фичи, вроде напоминающих POP-2 частичных применений [Arvi78]
```
g <- procedure (n,f) (if n=0 then 1 else n*f(n-1))
h <- compose(g,<<2,g>>)
```
Но до того, как Id стал одним из тех ФЯ, историю которых мы пишем, прошло немало времени.
Поработав три года с Деннисом, Арвинд стал руководителем собственной группы. И если бы мы решали о чем больше писать в этой истории не на основании полученных результатов, а на основании потраченных ресурсов, то история функционального программирования была бы историей группы Арвинда. Писать историю ФЯ как историю группы Арвинда было бы очень удобно потому, что отсканированы практически все их отчеты, в том числе ежегодные, в которых описано что сделано и что планируется сделать. И название у группы было как раз подходящее.
##### Группа функциональных языков
Новая группа функциональных языков и архитектуры (Functional Languages and Architecture, FLA) создана в МТИ в январе 81 [LCS81], а точнее выделена из группы вычислительных структур Дэнниса (Computation Structures Group). С первого же года Арвинд руководил десятком научных сотрудников, студентов и аспирантов и количество участников группы год от года росло.
В 81-ом ссылки победили очередную анти-Фон-Неймановскую локальность. Dataflow-машина "потребляет" пакеты, а значит построение на них долгоживущей структуры данных будет требовать постоянного её копирования. Так что в Id добавили I-структуры - ссылки на массивы, элементам которых можно присвоить значения один раз (отложить инициализацию), как логическим переменным в Прологе.
Тогда же Пингали (Keshav Pingali) изучал преимущества и недостатки вычисления по требованию по сравнению с вычислением, управляемым данными (data-driven) и решил, что вычисление по требованию хоть и предотвратит ненужные вычисления, но удвоит передачу пакетов между узлами. Так что Id не будет ленивым по умолчанию языком.
Тем временем он с Винодом Катаилом (Vinod Kathail) работают над двумя бэкендами компилятора Id: в dataflow-графы и в MacLisp.
В том же 81-ом году вместо dataflow-интерпретатора Арвинда с растущими (в циклах) тегами токенов, стали разрабатывать что-то более похожее на реальную машину с токенами фиксированного размера TTDA (Tagged Token Dataflow Architecture).
Каждый вычислительный элемент TTDA имеет 64К памяти для программы и 64К памяти для I-структур. Вычислительные элементы соединены сетью, пересылающей токены (пакеты фиксированного размера) между ними. Для выборки подходящих токенов из очереди, должно применяться специализированное железо для сопоставления тэгов этих пакетов. В группе Арвинда предполагают спроектировать со временем VLSI чип собственного дизайна, но для начала планируют по два MC68K процессора на каждый вычислительный узел. Прототип поможет определить для чего специальное железо действительно будет лучшим выбором, а что можно оставить обычным широкодоступным компонентом. Не нужно торопиться и вкладывать сразу много усилий в разработку специального железа. В прототипе до 256 вычислительных элементов, чтоб определить насколько хорошо все это масштабируется. Симулятор этой машины сначала написали на MacLisp.
В октябре 81-го [LCS82] группа функциональных языков и архитектуры совместно с группой вычислительных структур Денниса организовали конференцию по функциональным языкам программирования и компьютерной архитектуре (FPCA). По видимому, ту самую, на которой состоялся судьбоносный разговор Йонссона, Августссона и Тернера, который подтолкнул Йонссона к изобретению G-машины.
На конференции выступили с докладами представители основных обсуждаемых в этой главе разработчиков параллельных ФП-машин.
Языки, разрабатываемые группой функциональных языков, сначала были языками первого порядка, то есть функциональными только в соответствии с очень широким определением функциональности, но около 82-го года там заинтересовались ФЯ в более привычном смысле. Для начала, добавили ФВП в Бэкусовский FP [Arvi84].
Не позднее середины 82-го Катаил с Пингали закончили транслятор пока еще старого недофункционального Id в MacLisp, часть IdSys, компилятора/интерпретатора/отладчика Id, работающего на DEC-20 (поздняя модификация PDP-10). Компилятор в команды разрабатываемой параллельной машины пока еще не готов.
Теперь симулятор машины пишут на Паскале. Этот код на Паскале еще и называют исполняемой спецификацией машины.
Тем временем, количество вычислительных элементов в будущем прототипе понизили с 256 до 64. Первый вычислительный элемент планируется построить к концу 83-го года, но особого прогресса пока нет, использовать микропроцессоры Motorola передумали и решили собирать ЦПУ из нескольких АЛУ AMD как создатели SKIM. Но специальное железо для сопоставления тэгов спроектировано и даже заказано.
Прототип вычислительного элемента в 83-ем году так и не построили [LCS83], не смотря на то, что к середине 83-го года группа Арвинда уже удвоилась, в ней больше двадцати человек. Хотя построение железа осталось в долгосрочных планах, пока решили обойтись симуляцией.
К середине 83-го написана, как ожидают, половина симулятора TTDA, работающий на мэйнфрейме IBM. Этот мэйнфрейм IBM 4341 с 16Мб оперативной памяти и 2.4Гб диска арендован на два года специально для симуляции будущей параллельной машины.
Симулятор написан на Паскале Пингали, Дэвидом Куллером (David Culler) и Морисом Довеком (Moris Dovek) с некоторым участием на раннем этапе Арвинда и Роберта Томаса (Robert Thomas). Надеются, что можно будет использовать для моделирования машины до конца лета 83-го.
Группа Арвинда сотрудничает с уже поучаствовавшей в нашей предыстории ФЯ IBM Research в Йорктаун Хайтс, которые запускают симулятор на более мощной машине.
И более мощная машина нужна. Потому, что симуляция 20 миллионов dataflow-инструкций (несколько машинных секунд) требует 24 часа машинного времени на их мэйнфрейме.
Конечно, для запуска более-менее реальных программ такая детализированная симуляция не подходит, так что ведется работа над менее детальной, которую называют "эмуляцией". Эмулировать проектируемую параллельную машину будет MEF (Multiprocessor Emulation Facility). Эмулятор машины из 64-ех вычислительных элементов планируют построить как 64 Лисп-машины Symbolics 3600, соединенные сетью с 64-мя 8x8 свитчами собственной разработки. Размах впечатляет? Это вам не разработка компилятора ФЯ для обычных машин по ночам в выходные на университетском компьютере.
Эмулятор пишут на Лиспе Ричард Солей (Richard Soley) с помощью еще пары лисперов. В МТИ, конечно же, хотят писать на Лиспе, а не на Паскале. Предполагая, что на Лисп-машинах-то Лисп будет работать достаточно быстро. Ожидают, что код эмулятора будет готов в декабре 83-го года. И если закупка оборудования состоится, то в начале 84-го года заработает эмулятор из 4-8 Лисп-машин. Предполагается, что полномасштабный эмулятор из 64-х Лисп-машин заработает до конца 85-го. Ожидается, что MEF будет исполнять 64 - 640 тысяч dataflow-инструкций в секунду, на порядки больше чем симулятор.
Первые две Symbolics 3600 Лисп-машины группа функциональных языков и архитектуры получила в мае 83-го, до того разрабатывая эмулятор на старых университетских MIT CADR.
К середине 83-го кодогенератор для TTDA компилятора Id закончен. К этому же времени заинтересовались добавлением в Id системы типов как в ML.
К середине 84-го группа Арвинда удвоилась еще раз - в ней теперь почти пятьдесят человек [LCS84].
Эмулятор работает пока что на пяти Symbolics 3670 Лисп-машинах (по 6Мб памяти). И ожидается, что до конца 84-го года их будет 16. Лисп-машины пока что соединены 10Мбит Ethernet. Над быстрой сетью для соединения 64-х машин работают три инженера в IBM и один в Ericsson.
Правда, эмулятор на Лиспе эмулирует только 200 инструкций в секунду. Да, примерно столько же, сколько и симулятор. В группе Арвинда надеются, что 64 машины вытянут аж 13тыс. инструкций. Но желаемая производительность для эмулятора-то 64-640тыс. операций. Разработчики эмулятора еще надеются достигнуть этого результата оптимизациями и частичным переписыванием Лисп-кода на микрокод для Лисп-машин.
О трансляторах Id в Лисп и в команды для параллельной машины теперь последовательно пишут как о двух отдельных компиляторах, хотя раньше упоминали как минимум общий код парсера. Оба переписаны на общее подмножество MacLisp и Лиспа для Лисп-машин потому, что все еще используются на PDP-10. В Йорктаун Хайтс их тем временем переписывают на какой-нибудь Лисп, работающий на машинах IBM.
Ведутся работы над оптимизациями вроде CSE и слияния блоков.
Добавление ФВП в язык Бэкуса не привело ни каким важным для нашей истории последствиям. Но к середине 84-го Арвинд с разработчиками компилятора Id Катаилом и Пингали решили переделать Id для "элегантной" работы с ФВП. Планируют сделать это за два года.
Тем более, что их коллеги из группы Дэнниса, под влиянием посещавшего их Джо Стоя, соавтора Стрейчи из Оксфорда, пересмотрели анти-функциональность своего Алгола Val. Теперь этот язык из тех Алголов, которые как-то пытаются имплементировать рекурсию и ФВП. Но, как и у группы Денниса, у этого ФЯ нет будущего. А вот у Id оно пока есть.
И код на Id с его недо-функциональными фичами вроде `compose` производил на Арвинда и др. плохое впечатление. Особенно после знакомства с разработками Тернера и книгой Берджа. Языком, из которого нужно черпать идеи по улучшению Id, называют SASL. Ссылаются на статьи Тернера и его доклад на той самой конференции по ФЯ 81-го года.
Заинтересовались даже имплементацией параллельной редукции с помощью специальных машин, раз уж у редуцирующих функциональщиков такие успехи. Но пока как побочным проектом.
Функционализация Id набрала обороты только с появлением в группе Арвинда нового заметного героя нашей истории - Ришиюра Нихила (Rishiyur Sivaswami Nikhil) [LCS85]. Нихил до этого не имел никакого отношения к dataflow, но был знаком с функциональными языками и сам разрабатывал ФЯ как языки запросов к базам данных. О чем сделал доклад на организованной Арвиндом конференции в 81-ом. Свой вклад в модернизацию Id Нихил начал с работы над проверкой типов с поддержкой полиморфизма.
Хеллер (Steven Heller) и Троб (Kenneth R. Traub) закончили переписывание компилятора Id Винода Катаила (теперь называют Version 0) на Лисп для Лисп-машин и его отладку. Релиз Id Compiler (Version 1) состоялся в январе 85-го. О трансляторе Id в Лисп уже не вспоминают.
Этот компилятор, правда, не достаточно легко расширять и модифицировать, так что началось написание нового компилятора Version 2, который планируют закончить к июню 86-го.
Тем временем, МТИ заключил упоминавшуюся уже в этой главе сделку с TI и вместо Symbolics 3670 группа Арвинда стала получать более дешевые и медленные TI Explorer. К середине 85-го в MEF восемь 3670 и два Explorer. Платы расширения для прототипов собственной высокоскоростной сети не влезают в Explorer и их нужно перепроектировать.
Оптимизация же кода позволила пока ускорить эмуляцию на одной машине только в 5 раз перед тем как работа над ним была приостановлена весной 85-го. Пока не перешли полностью на серийные Эксплореры - нет смысла дальше оптимизировать или микрокод писать. Те две, что уже получены - прототипы.
Ну, зато машину на которой работает симулятор планируют заменить на более мощный мэйнфрейм IBM 4381.
##### Конец группы функциональных языков
До середины 86-го года группа функциональных языков уже не дожила [LCS86]. Но только потому, что поглотила свою родительскую группу вычислительных структур, все это время кое-как занимавшейся другой разновидностью dataflow, и помимо Денниса и нескольких его аспирантов получила и название. Теперь под началом Арвинда больше шестидесяти человек.
Ирония в том, что рассталась со своим "функциональным" названием группа Арвинда примерно тогда же, когда наконец-то серьезно занялась разработкой первого своего ФЯ. Не в широком смысле, а более-менее такого, историю которых мы пишем.
В июне и июле 85-го года Нихил и Арвинд полностью перепроектировали Id, создав Id/83s. 83 тут не год описания языка, а часть номера курса в МТИ, для которого язык разрабатывали - "6.83s: Functional Programming and Dataflow Architectures". По крайней мере к середине 86-го Id/83s имплементирован как фронтенд для компилятора старого Id, того компилятора, который Version 1 [Nikh86].
Система типов для Id "как в ML" уже упоминалась раньше, но только года с 85-го система типов для Id обсуждается серьезно. В 86-ом Арвинд и другие уже уверены, что система типов нужна. Им нравится, что система типов - это "мощный инструмент отладки". И нужно заметить, что это пишут не обычные функциональные программисты с их обычными отношениями с отладчиком, а чаще - его отсутствием. Это пишут лисперы, которые отладчиком пользуются регулярно. К тому же, они столкнулись с рядом проблем с производительностью. Помимо обычных арифметических, есть и более специфические проблемы. Или, по крайней мере, их формулировки. Например, для эффективности сборки мусора нужно знать какие ребра dataflow-графа передают I-структуры, т.е. ссылки на массивы ссылок.
Но в 86-ом году Арвинд и "имеющий большой опыт работы с системой типов Милнера" Нихил уже не уверены, что хотят систему типов как в ML. Или как в CLU, который тоже упоминается. Теперь им хочется чего-то вроде системы Жерара-Рейнольдса. Они понимают, что полного вывода типов не будет, но надеются обойтись небольшим количеством аннотаций.
Возможно, что это влияние новоприобретенных остатков группы Денниса, которые уже добавили вывод типов в свой dataflow-язык Val. Вывод отличающийся от Милнеровского поддержкой ad-hoc полиморфизма для арифметики рекурсивных типов.
Для такого вот кода на языке Денниса, который теперь назывался VimVal [Kusz84]
```
function Y(f)
function f1(x)
f(x(x))
endfun
f1(f1)
endfun
```
выводились вот такие типы:
```
Ytype = Functype(Ytype) returns(Ytype)
function Y(f:Ytype) returns(Ytype)
function f1(x:Ytype) returns(Ytype)
```
Так или иначе, но в Id/83s типов пока нет, но язык проектируется так, чтоб типы можно было проверять Хиндли-Милнером.
Если не считать некоторое сопротивление Милнеру, все прочее в новом Id делается так, как в языках эдинбургской программы. Нихил ссылается [Nikh85] на Тернера и Бурсталла, Августссона и Карделли, делая что-то вроде SASL с массивами (I-структурами). МТИ долго сопротивлялся эдинбургскому влиянию, но вот, в самом сердце альтернативной ФП-программы теперь делают очередной "эдинбургский" язык, просто с задержкой на годы.
Группа Арвинда теперь пишет на Common Lisp и Троб пишет вторую версию компилятора Id на Common Lisp. Это его магистерская диссертация. Ожидалось, что первую программу он скомпилирует в августе 86-го, но Троб справился раньше - в июле 86-го. Но имплементированы не все оптимизации, которые задуманы [Trau86]. Компилятор транслирует функции со свободными переменными в комбинаторы с помощью лямбда-лифтинга и есть ссылка на Йонссона.
Группа Арвинда получила 38 Лисп-машин TI Explorer, каждая с 8Мб памяти и 140Мб диском, и MEF использует 32 из них, 64-машинный эмулятор больше не планируется. Программа-эмулятор, которая теперь называется GITA (Graph Interpreter for the Tagged-Token Architecture) работает на одном Эксплорере со скоростью 1000 инструкций в секунду. На Symbolics 3600 - 2400 инструкций в секунду.
А сколько на 32-х Эксплорерах? По какой-то причине этой скоростью хвалиться не спешат. Вместо этого пишут, что делать выводы из результатов полученных на MEF нужно с осторожностью, на реальной машине ожидаются другие результаты.
Симулятор, который теперь называется SITA (Simulator for the Tagged-Token Architecture) теперь работает на IBM 4381, который в два с половиной раза быстрее предыдущего. 80 инструкций в секунду. Но подождите-ка, на первой машине было 230. Видимо, симулятор стал детальнее.
В 87-ом году новый функциональный Id/83s называется Id Nouveau [LCS87]. После интеграции чисто функционального ядра с I-структурами, синтаксис "заморожен" в январе 87-го. Работа над системой типов Id и проверкой типов в компиляторе Id все продолжается, но ничего пока что не готово. Релиз Id World, IDE для Id состоялся в апреле 87-го.
Как и в императивном ФЯ VAX ML, в Id Nouveau есть циклы и массивы. Но Id не является императивным языком, так что и те и другие отличаются от своих ML-ных аналогов [Nikh86].
```haskell
let
x,y = 1,1
in
for j from 1 to 20 do
new x, new y = y, x+y
return x
```
`x` и `y` тут не изменяемые значения, как в императивном ML, а константы и `new x` просто способ определить эквивалент параметра хвосторекурсивной функции.
Циклы в Id описываются как "удобный способ" записать функции с хвостовым вызовом, но компилятор не делает такой трансляции и специальным образом компилирует циклы, сохраняющееся в промежуточном представлении [Trau86].
Массивы (I-структуры) больше похожи на логические переменные, чем на ML-ные массивы. Они не изменяемые, но с отложенной инициализацией:
```haskell
let
a = array(1..3);
a[1] = 25;
a[2] = 6;
a[3] = 4
in a
```
Попытка прочесть неинициализированное значение из I-структуры откладывает это вычисление до тех пор, пока инициализация не будет сделана. Попытка инициализировать I-структуру второй раз прекращает исполнение программы.
Конструкций для управления распараллеливанием нет. Предполагается, что оно полностью автоматическое. Программист не должен ничего аннотировать.
Все прочее выглядит знакомо [Nikh86]:
```haskell
def map f l = if l = nil then nil
else let hd, tl = l
in f hd, map f tl ;
let
y = 1 ;
add x = x + y
in map add (1, (2, (3, nil)))
```
Короче говоря, Id Nouveau выглядит как ФЯ 77-го года, а не 87-го. Но таким анахронизмом он был недолго. В 88-ом году Id будет выглядеть как ФЯ 88-го года. Но это уже другая история.
#### Алиса в ржавом поясе
Поскольку в работах Денниса, Арвинда и других над dataflow-машинами уделялось достаточно много внимания общеполезным вопросом вроде тех, как лучше пересылать сообщения между вычислительными элементами, не только чему-то dataflow-специфическому, они оказали влияние на строителей машин, которые не были dataflow-машинами.
Производить новые пакеты в вычислительном элементе можно и другим способом, например вычислять по требованию, редуцируя графы. Тем более, что и Жиль Кан рекомендовал поступать так. Скомпенсировать увеличение числа передаваемых пакетов можно увеличив "зернистость" параллелизма.
Такие машины должны были имплементировать обычные функциональные языки, так что их создатели уже поучаствовали в нашей истории. Помните Роберта Келлера, научрука Худака в университете Юты, который разрабатывал FGL/FEL? Имплементировать эти языки он хотел с помощью параллельной машины AMPS (Applicative Multi-Processing System) [Kell79].
Вычислительные элементы AMPS соединялись в дерево, как у машины Маго, но на этом сходство и заканчивалось. Вычислительные элементы в узлах балансировали нагрузку для вычислительных элементов в листьях дерева. AMPS редуцировала не строки, а графы. Точнее не редуцировала, конечно, потому, что не была построена. В 79-ом году параллельная редукция эмулировалась программой на Паскале. И строить реальную машину в ближайшее время не собирались. Писали только еще один симулятор на Simula 67.
К 84-му году на смену этой симулируемой машине пришла другая симулируемая машина - Rediflow (REDuctIon, dataFLOW) [Kell85]. Машина должна была состоять из вычислительных элементов, соединенных быстрой сетью с коммутацией пакетов. Каждый элемент - Келлер называет его Xputer - состоит из соединенных шиной микропроцессора (рассматривается Motorola 68020), памяти (примерно мегабайт) и свитча.
Новая машина утратила древесное своеобразие своей предшественницы. Свитч соединяет Xputer с четырьмя соседями в прямоугольной сетке. С ближайшими, или, в случае конфигурации "бабочка" с соседями во все более удаленных "столбцах" с ростом номера "строки" сетки.
Гранулярность параллелизма более "грубая" по сравнению с AMPS. Вместо подсчета ссылок - сборщик мусора, придуманный Худаком.
Другой ФП-машинист, который уже поучаствовал в нашей истории работал над уже упоминавшимся в нашей истории проектом в Великобритании. В Имперском колледже Лондона, независимо от Келлера, но под влиянием идей таких разработчиков dataflow-машин как Арвинд и Деннис, наш старый знакомый Джон Дарлингтон со своими коллегами разрабатывал машину ALICE (Applicative Language Idealized Computing Engine) [Darl81].
В 70-е Дарлингтон разрабатывал NPL вместе с Бурсталлом в Эдинбурге. В разработке HOPE он принять участия, по всей видимости, не успел, но использовал эту новую версию NPL в своем проекте как имплементируемый язык и как язык для имплементации.
ФЯ, например HOPE и KRC, решают многие проблемы разработки программ, но не получили широкого распространения из-за неустранимой неэффективности на обычных, Фон-Неймановских машинах, утверждают Дарлингтон и его соавтор Рив (Mike Reeve).
Но не все потеряно: железо становится дешевле и многопроцессорные машины - осуществимее. И вот для них-то функциональные языки подходят "идеально". Они "свободны от побочных эффектов" и потому подвыражения можно вычислять независимо.
Дарлингтон и Рив знают о разработке параллельных машин для императивных языков, "взаимодействующих последовательных процессов", например, в Университете Карнеги — Меллона. И отмечают, что при программировании таких машин нужно программировать конкурентность и синхронизировать доступ к разделяемым данным вручную. При программировании ФП-компьютера на ФЯ ничего этого делать не придется, ожидают они.
Дарлингтон и Рив не позднее октября 81-го года пишут, что ожидают впечатляющие успехи VLSI, которые произведут массу дешевых блоков для строительства компьютеров. Дешевых благодаря своей массовости. И эти строительные блоки - микропроцессоры. Не ТТЛ микросхемы, из которых в это время строят SKI и Лисп-машины. Позднее лисперы будут писать, что в это время это было еще совсем не очевидно. Но, как видите, очевидно для Дарлингтона и Рива: не делайте сами центральные процессоры, стройте компьютер из готовых центральных процессоров на одном чипе, которые будут все лучше и дешевле. И цель строителя компьютера наладить передачу данных между этими микропроцессорами и памятью.
В 81-ом году предполагается, что ALICE будет состоять из блоков, соединенных быстрой сетью с коммутацией пакетов. Каждый из этих блоков состоит из нескольких микропроцессоров соединенных друг с другом и с памятью шиной.
Такой блок из 20 процессоров и памяти, рассуждают Дарлингтон и Рив, может быть настольной рабочей станцией. Похоже, что у них все же слишком оптимистичные ожидания успехов VLSI. Такая машина должна, по результатам моделирования, совершать 150 тыс. редукций. Редукций более крупных, чем 250 тыс. редукций, которые через несколько лет будет совершать (почти) однопроцессорная NORMA. И только на два десятичных порядка быстрее, чем интерпретатор HOPE на DEC-10, что выглядит не очень впечатляюще для двадцати процессоров. Другими словами, эта двадцатипроцессорная рабочая станция в мечтах Дарлингтона и Рива исполняла код на HOPE с примерно той же скоростью, с какой исполнялся реальный код на VAX-ML на реальном миникомпьютере в то время, когда Дарлингтон докладывал на конференции о своих мечтах.
"Крупномасштабная" машина, в свою очередь, может состоять из 4096 таких двадцатипроцессорных элементов и совершать 150 миллионов редукций. И если читатели не ожидают скорого воплощения такой грандиозной системы в жизнь, то правильно делают, что не ожидают.
Пока что, как и у прочих разработчиков параллельных машин, работает только симулятор. Симулятор написан еще в 81-ом. И в этом случае тоже на Паскале.
"Симулятором" в данном случае называется не то же самое, что в случае TTDA машины. Этот симулятор не только интерпретирует программы, скомпилированные компилятором HOPE, но и позволяет оценивать их производительность. Правда, симулятор все еще слишком абстрактный для хорошей оценки. Так что ведется работа над более низкоуровневым симулятором. Конечно же, опять на Паскале, но в этот раз на Path Pascal с расширениями для системного программирования и параллельности.
Какие-то из этих эмуляторов не позднее 82-го года работали на новом мэйнфрейме IBM 4331. Как видите, даже в Великобритании разработчики ФП-железа могли получить доступ к машинам, об использовании которых создатели компиляторов ФЯ для обычных машин могли только мечтать. Для того, чтоб разрабатывать и запускать код для будущего параллельного компьютера быстрее и на более слабых машинах, в 82-ом году планировали написать быстрый интерпретатор ФП-машинного целевого языка CTL (Compiler Target Language).
CTL описывает правила перезаписи, по которым вычислительный элемент переписывает одни пакеты в создание новых пакетов или их обновление. Пакетов, передаваемых между вычислительными элементами и памятью, как в dataflow-машинах. Но в ALICE пакеты крупнее чем таких машинах. Пакет описывает применение функции. Так что гранулярность распараллеливания больше, чем в dataflow-машинах, но меньше, чем во второй машине Келлера.
Этот процесс обработки пакетов соответствует редукции графов, пакеты можно переписать на месте. Это равномощно одиночному присваиванию и позволяет имплементировать еще и логические и dataflow-языки. В сочетании с копированием, императивный язык они тоже позволяют эмулировать, но неэффективно.
Применения конструкторов - обычные пакеты, не требуется строить структуры данных из I-массивов как в Id. Пока еще сборку мусора планируют делать подсчетом ссылок, но уже беспокоятся из-за того, что циклические графы при этом не поддерживаются.
Предполагается, что в воплощенной в железе ALICE идентификаторы пакетов - просто их адреса. Никакая машинерия для хеширования и прочего ускорения сопоставления тэгов в dataflow-машинах не нужна.
Именно в язык исполняемый этими симуляторами и эмуляторами транслирует код компилятор HOPE на HOPE [Moor82], о котором мы уже рассказывали в прошлой части. Этот компилятор в Имперском колледже Лондона начали разрабатывать не позднее октября 81-го.
В Лондоне не могут себе позволить ускорение эмуляции с помощью покупки множества Лисп-машин, например. Так что для того, чтоб разрабатывать нужные им программы на HOPE, разработчики ALICE сделают более ранний и существенный вклад в развитие имплементаций ФЯ для обычных машин, чем разработчики ФП-машин в МТИ. Но эта история уже больше подходит к теме следующей части.
#### Вообразите машины
Итак, в отличие от SKI-машин, которые удалось построить достаточно быстро, параллельные ФП-машины все продолжали оставаться только медленными интерпретаторами. "Главный недостаток" машины Маго совсем не уникален. Может у Пролог-машин все было иначе, сложно сказать, мы не пишем историю Пролога.
Но родственные обсуждаемым в этой главе проектам не-совсем-ФП-машины были имплементированы в начале 80-х.
Разновидность dataflow-машин, а которых у токенов есть теги (tagged-token dataflow) была независимо от Арвинда [Arvi86] изобретена в Университете Манчестера и там построили такую машину в октябре 81-го года [Gurd85]. Она имплементировала происходящий от до-функциональной версии языка VAL Денниса язык первого порядка с рекурсией SISAL.
Но даже "предварительную" оценку производительности опубликовали только в 83-ем. И даже в 85-ом оценка была вот такой:
| | RSIM/1 | RSIM/2 | RSIM/3 | RSIM/4 |
| :----------- | :------: | :------: | :------: | :------: |
| SISAL(1FU) | 34.0 | 82.6 | 76.5 | 31.0 |
| SISAL(12FU) | 4.00 | 8.90 | 8.50 | 3.14 |
| C(VAX11/780) | **1.00** | **1.00** | **1.00** | **1.00** |
```
SISAL(1FU)
░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░
SISAL(12FU)
░░░▒▒▒▓▓▓░░
C(VAX11/780)
░░
```
Авторы предлагают не спешить с выводами и подождать, когда появится компилятор SISAL для VAX11/780 и сравнивать с ним. Видимо, предполагается, что он будет компилировать хуже компилятора C и параллельная машина будет выглядеть лучше.
А пока выглядит довольно плохо. Так что Арвинд считает нужным упомянуть [Arvi86], что машина медленная из-за плохих АЛУ и микрокода вместо железа. А вовсе не потому, что dataflow - это плохая идея. Другими словами, манчестерская машина - это такая dataflow-SKIM.
Для сопоставления токенов она использовала хеширование, что также не способствовало быстрой работе, но на тот момент и Арвинду было нечего ответить на такую критику. Да, авторы ALICE отмечали отсутствие такой проблемы у их машины как плюс, по сравнению с машиной Арвинда.
Арвинду зато было что ответить на другой недостаток манчестерской машины - она не имела первоклассной поддержки структур, в отличие от машины Арвинда. Массивы в ней кодировались как циклы - каждый элемент был токеном (пакетом) и метка номера итерации в таких пакетах кодировала индекс. Да, авторы ALICE отмечали наличие такой проблемы и у их машины как плюс, по сравнению с машиной Арвинда.
Сумеют ли ФП-машинисты продемонстрировать, что проблема не в идее, а в имплементации? К этому мы еще вернемся.
## Голатак
На этом первая часть нашей истории окончена. Её итоги мы подведем с помощью популярного в описываемое время микро-бенчмарка - `nfib`. В 80-е годы имплементаторы ФЯ обычно используют его, и в ряде случаев только его, для того чтоб познакомить своих коллег с производительностью своих имплементаций. И если вдруг имплементатор еще не опубликовал результат сам - о нем спрашивают в рассылках. Лисперы используют в таком качестве варианты функции Такеучи. Но те из них, кто больше связаны с ФЯ Эдинбургской программы, например в INRIA (Le Lisp) или в Йеле (T), готовы запустить и `nfib`.
Вот код этой функции на LML:
```haskell
let rec nfib n = if n < 2 then 1 else nfib(n-1) + nfib(n-2) + 1
```
Вместо n-го числа Фибоначчи функция возвращает количество вызовов функций, которые потребовались для вычисления n-го числа Фибоначчи. В начале 80-х `n` обычно равен 20, но для того, чтоб легче было сравнивать с результатами, полученными при других `n`, число вызовов обычно делят на число секунд, понадобившихся для того, чтоб все эти вызовы сделать. Это число известно или может быть вычислено для большинства основных имплементаций, обсуждающихся в этой части и для пары важных имплементаций из предыдущей. Понятно, что чем больше число - тем лучше. Это не единственное отступление от обычного формата бенчмарков в нашей истории. Обычно результаты относительные, но тут мы воспользуемся случаем и покажем насколько небольшими были результаты абсолютные. Среди этих имплементаций есть те, на которых написали реальные программы. Давайте сравним их с самой медленной, но все еще пригодной для использования имплементацией ФЯ, с которой, мы надеемся, знакомы большинство читателей. Байткод-интерпретатор ghci на современном компьютере выдает `nfib` порядка миллиона. Первым компиляторам ФЯ на первых пригодных для их работы машинах до этого далеко:
| | nfib |
| :------------------------------------- | -----: |
| Le Lisp [Chai84] | 182425 |
| _ZetaLisp (3600)_ [Chai84] | 145940 |
| Algol68C ? [Fair85] [Gris82] | 60000 |
| C [Augu84] | 47589 |
| VAX ML [Augu84] | 43782 |
| T2 ? [TMail] [Chai84] | 33940 |
| _ARC SASL (NORMA)_ [Sche86] | 31271 |
| _LM Lisp (LM-2)_ [Chai83] | 28065 |
| LML [Augu84] | 26375 |
| Franz Lisp [Augu84] | 19901 |
| _Ponder (SKIM II)_ ? [Stoy85] [Sche86] | 15011 |
| ML V6.2 Franz Lisp [Maun86] | 15000 |
| Ponder ? [Fair85] [Gris82] | 14741 |
| Poly [Maun86] | 12300 |
| SASL [Augu84] | 706 |
| LCF/ML [Augu84] | 476 |
| _FEL (Rediflow)_ | 0 |
| _FFP (Mago)_ | 0 |
| _Id (TTDA)_ | 0 |
| _HOPE (ALICE)_ | 0 |
```
Le Lisp [Chai84]
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
_ZetaLisp (3600)_ [Chai84]
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
Algol68C ? [Fair85] [Gris82]
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
C [Augu84]
░░░░░░░░░░░░░░░░░░░░░░░░░░
VAX ML [Augu84]
░░░░░░░░░░░░░░░░░░░░░░░░
T2 ? [TMail] [Chai84]
░░░░░░░░░░░░░░░░░░░
_ARC SASL (NORMA)_ [Sche86]
░░░░░░░░░░░░░░░░░
_LM Lisp (LM-2)_ [Chai83]
░░░░░░░░░░░░░░░
LML [Augu84]
░░░░░░░░░░░░░░
Franz Lisp [Augu84]
░░░░░░░░░░░
_Ponder (SKIM II)_ ? [Stoy85] [Sche86]
░░░░░░░░
ML V6.2 Franz Lisp [Maun86]
░░░░░░░░
Ponder ? [Fair85] [Gris82]
░░░░░░░░
Poly [Maun86]
░░░░░░░
```
Большинство измерений сделаны на VAX-11/780, очевидное исключение составляют специальные машины, выделенные курсивом. `?` - обозначает другую категорию исключений - эти результаты или получены на Motorola 68000 и пересчитаны так, чтоб получить оценку результата на VAX-11/780. Или, в случае SKIM II, получены из результата на NORMA и соотношения в скоростях редукции. Все эти оценки оптимистические, реальные результаты могли быть заметно хуже. Но оптимистичны не только оценки. Для ряда имплементаций известны несколько результатов и мы всегда выбирали самый лучший из них.
Параллельные ФП-машины в описываемое время еще не существуют, так что применяют функции 0 раз. Имплементаторы ALFL по какой-то причине пожелали, чтоб производительность его ранних имплементаций осталась неизвестной.
Какие выводы можно сделать? Первые компиляторы 80-х уже по крайней мере на порядок или даже на порядки быстрее имплементаций 80-х. И все равно производительности большинства еще есть куда расти. Тем, кто не хочет имплементировать ФЯ с нуля, определенно есть смысл использовать Le Lisp или T (жаль, что для кембриджского компилятора Algol 68 так и не сделали рантайм со сборщиком мусора). Единственная быстрая специальная машина - это Symbolics 3600 (правда, в этом сравнении не видно, что на бенчмарках, проверяющих производительность кода с ФВП она совсем не так хороша). Остальные машины вроде Lambda и Explorer ближе к LM-2, а прочие еще хуже. Ну и в INRIA, похоже, уже выгудхартили весь и без того невеликий смысл из этого микро-бенчмарка.
Эти результаты, правда, не очень хорошо предсказывают судьбу как самих этих имплементаций, так и семейств имплементаций, которым они положили начало.
Так, не смотря на очевидное превосходство результатов, которых добились разработчики компиляторов для обычных машин, в середине 80-х у специальных ФП-машин откроется второе дыхание и они останутся важным и престижным направлением имплементации ФЯ. Да, произойдет это потому, что в 70-е годы посещавший SRI Фурукава Коити нашел там ксерокопию ксерокопии ксерокопии распечатки FORTRAN-исходников Марсельского интерпретатора Пролога. Но это уже другая история.
Литература
==========
[ALGOL80]: AB45.4.2 ALGOL 68 Implementations - ALGOL 68C - Release 1, Algol Bulletin No. 45, January 1980 http://archive.computerhistory.org/resources/text/algol/algol_bulletin/A45/P42.HTM
[Apol86]: http://bitsavers.informatik.uni-stuttgart.de/pdf/datapro/datapro_reports_70s-90s/Apollo/M11-075-11_8605_Apollo_Domain.pdf
[Arvind]: Arvind https://csg.csail.mit.edu/Users/arvind/
[Arvi78]: Arvind, Kim P. Gostelow and Wil Plouffe. “An asynchronous programming language and computing machine.” (1978). https://escholarship.org/uc/item/2bm0t173
[Arvi84]: Arvind, Brock, J. D. and Pingali, K. "FP1.5: Backus' FP with higher order functions", M.I.T. Lab. for Computer Science, (Unpublished 1984)
[Arvi86]: Arvind and David E. Culler. “Dataflow architectures.” (1986). https://dspace.mit.edu/handle/1721.1/149103
[Augu84]: Lennart Augustsson, A compiler for lazy ML. LFP '84: Proceedings of the 1984 ACM Symposium on LISP and functional programming August 1984 Pages 218–227 doi:10.1145/800055.802038
[Augu89]: L. Augustsson, T. Johnsson, The Chalmers Lazy-ML Compiler. In The Computer Journal, Volume 32, Issue 2, 1989, Pages 127–141 DOI:10.1093/comjnl/32.2.127
[Augu21]: The Haskell Interlude 02: Lennart Augustsson https://www.buzzsprout.com/1817535/9286902
@ -1793,10 +2083,12 @@ Symbolics LM2
[Clar80]: T. J. W. Clarke, P. J. S. Gladstone, C. D. MacLean, and A. C. Norman. 1980. SKIM - The S, K, I reduction machine. In Proceedings of the 1980 ACM conference on LISP and functional programming (LFP '80). Association for Computing Machinery, New York, NY, USA, 128–135. doi:10.1145/800087.802798
[Cousot]: Cousot, Patrick. “The Contributions of Alan Mycroft to Abstract Interpretation.”
[Dama84]: Luís Damas. “Type assignment in programming languages.” (1984).
[Darl81]: John Darlington and Mike Reeve. 1981. ALICE a multi-processor reduction machine for the parallel evaluation CF applicative languages. In Proceedings of the 1981 conference on Functional programming languages and computer architecture (FPCA '81). Association for Computing Machinery, New York, NY, USA, 65–76. doi:10.1145/800223.806764
[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
[Dennis]: Jack B. Dennis https://csg.csail.mit.edu/Users/dennis/index.htm
[Dijk78]: Dijkstra, Edsger Wybe. A review of the 1977 Turing Award Lecture by John Backus https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692.html
[Dybv06]: R. Kent Dybvig. 2006. The development of Chez Scheme. In Proceedings of the eleventh ACM SIGPLAN international conference on Functional programming (ICFP '06). Association for Computing Machinery, New York, NY, USA, 1–12. doi:10.1145/1159803.1159805
[Fair82]: Fairbairn, Jon. Ponder and its type system. Technical Report Number 31 University of Cambridge, Computer Laboratory UCAM-CL-TR-31 November 1982 DOI: 10.48456/tr-31 https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-31.pdf
@ -1814,6 +2106,7 @@ Symbolics LM2
[Gord80]: Michael Gordon, Locations as first class objects in ML. https://smlfamily.github.io/history/Gordon-ML-refs-1980.pdf
[Gord82]: Mike Gordon, Larry Paulson, 1982-11-03 in Polymorphism Vol 1 part 1 Jan 83
[Gord2000]: Gordon M. From LCF to HOL: a short history. In Proof, language, and interaction 2000 Jul 24 (pp. 169-186).
[Gurd85]: J. R Gurd, C. C Kirkham, and I. Watson. 1985. The Manchester prototype dataflow computer. Commun. ACM 28, 1 (Jan. 1985), 34–52. doi:10.1145/2465.2468
[Hear79]: J. Marti, A. C. Hearn, M. L. Griss, and C. Griss. 1979. Standard LISP report. SIGPLAN Not. 14, 10 (October 1979), 48–68. doi:10.1145/953997.953999
[Hear2005]: Hearn, Anthony C.. “REDUCE: The First Forty Years.” Algorithmic Algebra and Logic (2005).
[Hoar22]: Krzysztof R. Apt and Tony Hoare (Eds.). 2022. Edsger Wybe Dijkstra: His Life,Work, and Legacy (1st. ed.). ACM Books, Vol. 45. Association for Computing Machinery, New York, NY, USA. https://doi.org/10.1145/3544585
@ -1839,16 +2132,30 @@ SIGPLAN '84: Proceedings of the 1984 SIGPLAN symposium on Compiler construction
[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
[John2004]: Thomas Johnsson. 2004. Efficient compilation of lazy evaluation. SIGPLAN Not. 39, 4 (April 2004), 125–138. doi:10.1145/989393.989409
[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.
[Kell79]: KELLER, R. M., LINDSTROM, G., & PATIL, S. (1979). A loosely-coupled applicative multi-processing system. 1979 International Workshop on Managing Requirements Knowledge. doi:10.1109/mark.1979.8817294 
[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.
[Kell85]: Keller, Robert M. "Rediflow architecture prospectus." In TR UUCS-85-105. Dept of Computer Science, University of Utah USA, 1985.
[Kost84]: Alexis Koster. 1984. Compiling prolog programs for parallel execution on a cellular machine. In Proceedings of the 1984 annual conference of the ACM on The fifth generation challenge (ACM '84). Association for Computing Machinery, New York, NY, USA, 167–178. doi:10.1145/800171.809619
[Krei2002]: Kreitz, Christoph. "The Nuprl Proof Development System, Version 5: Reference Manual and User’s Guide." Department of Computer Science, Cornell University (2002)
[Kusz84]: Kuszmaul, Bradley C. "Type checking in vimval." (1984).
[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
[LCS81]: Laboratory for Computer Science Progress Report 18, July 1980-June 1981 https://apps.dtic.mil/sti/tr/pdf/ADA127586.pdf
[LCS82]: Laboratory for Computer Science Progress Report 19, 1 July 1981-30 June 1982 https://apps.dtic.mil/sti/pdfs/ADA143459.pdf
[LCS83]: Laboratory for Computer Science Progress Report 20, July 1982 - June 1983 https://apps.dtic.mil/sti/tr/pdf/ADA145134.pdf
[LCS84]: Laboratory for Computer Science Progress Report 21, July 1983-June 1984 https://apps.dtic.mil/sti/pdfs/ADA158299.pdf
[LCS85]: Laboratory for Computer Science Progress Report 22, July 1984-June 1985 https://apps.dtic.mil/sti/tr/pdf/ADA227278.pdf
[LCS86]: Laboratory for Computer Science Progress Report 23, July 1985-June 1986 https://apps.dtic.mil/sti/tr/pdf/ADA227277.pdf
[LCS87]: Laboratory for Computer Science Progress Report 24, July 1986-June 1987 https://apps.dtic.mil/sti/tr/pdf/ADA207705.pdf
[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
[Lisk93]: Liskov, B. (1993). A history of CLU. ACM SIGPLAN Notices, 28(3), 133–147. doi:10.1145/155360.155367
[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
[Mago81]: Gyula Magó. 1981. Copying operands versus copying results: A solution to the problem of large operands in FFP'S. In Proceedings of the 1981 conference on Functional programming languages and computer architecture (FPCA '81). Association for Computing Machinery, New York, NY, USA, 93–98. doi:10.1145/800223.806767
[Mago82]: Gyula Magó. 1982. Data sharing in an FFP machine. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 201–207. doi:10.1145/800068.802151
[Mash2006]: John Mashey, A Historical Look at the VAX: The Economics of
Microprocessors, 01-24-2006 http://www.bitsavers.org/pdf/dec/vax/VAX_Retrospective_20060124.pdf
[Matt83]: Matthews, David Charles James. Programming language design with polymorphism. No. UCAM-CL-TR-49. University of Cambridge, Computer Laboratory, 1983.
@ -1858,11 +2165,14 @@ Microprocessors, 01-24-2006 http://www.bitsavers.org/pdf/dec/vax/VAX_Retrospecti
[Miln93]: Frenkel, Karen A. and Robin Milner. “An interview with Robin Milner.” Commun. ACM 36 (1993): 90-97. DOI:10.1145/151233.151241
[Miln2003]: interview with Robin Milner, held in Cambridge on the 3. September 2003 http://users.sussex.ac.uk/~mfb21/interviews/milner/
[Modula3]: MODULA-3 authors https://www.cs.purdue.edu/homes/hosking/m3/reference/authors.html
[Moor82]: Ian W. Moor. 1982. An applicative compiler for a parallel machine. SIGPLAN Not. 17, 6 (June 1982), 284–293. DOI:10.1145/872726.807002
[Mose08]: Moses, J. (2012). Macsyma: A personal history. Journal of Symbolic Computation, 47(2), 123–130. doi:10.1016/j.jsc.2010.08.018 
[MULTICS1]: https://www.multicians.org/benchmarks.html#INRIA
[Mycr80]: Mycroft, A. (1980). The theory and practice of transforming call-by-need into call-by-value. In: Robinet, B. (eds) International Symposium on Programming. Programming 1980. Lecture Notes in Computer Science, vol 83. Springer, Berlin, Heidelberg. doi:10.1007/3-540-09981-6_19
[Mycr16]: Alan Mycroft, Mini CV https://www.cl.cam.ac.uk/~am21/minicv.txt
[Nebe83]: Nebel, B. (1983). Ist Lisp Eine ‘Langsame’ Sprache?. In: Neumann, B. (eds) GWAI-83. Informatik-Fachberichte, vol 76. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-69391-5_3
[Nikh85]: R. S. Nikhil, Practical Polymorphism, CSG-Memo-249 https://csg.csail.mit.edu/pubs/memos/Memo-249/Memo-249.pdf
[Nikh86]: Rishiyur S. Nikhil, Keshav Pingali, Arvind. Id Nouveau. Computation Structures Group - Memo No. 265, July 23, 1986
[NIL85]: Jon L White et al. VAX NIL source code, Release 0.286. Massachusetts Institute of Technology. Provided by Josh Dersch. https://www.softwarepreservation.org/projects/LISP/MIT/nil.zip
[Norm77]: Fitch, J. P., & Norman, A. C. (1977). Implementing LISP in a high-level language. Software: Practice and Experience, 7(6), 713–725. doi:10.1002/spe.4380070606 
[Norm79]: Norman, A.C., Moore, P.M.A. (1979). The initial design of a vector based algebra system. In: Ng, E.W. (eds) Symbolic and Algebraic Computation. EUROSAM 1979. Lecture Notes in Computer Science, vol 72. Springer, Berlin, Heidelberg. doi:10.1007/3-540-09519-5_78
@ -1897,10 +2207,12 @@ Microprocessors, 01-24-2006 http://www.bitsavers.org/pdf/dec/vax/VAX_Retrospecti
[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
[Trau86]: Traub, Kenneth R.. “A COMPILER FOR THE MIT TAGGED-TOKEN DATAFLOW ARCHITECTURE.” (1986).
[Trel87]: Treleaven, P.C., Refenes, A.N., Lees, K.J., McCabe, S.C. (1987). Computer architectures for artificial intelligence. In: Treleaven, P., Vanneschi, M. (eds) Future Parallel Computers. Lecture Notes in Computer Science, vol 272. Springer, Berlin, Heidelberg. doi:10.1007/3-540-18203-9_15
[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 
[Turn82]: Turner, D.A. (1982). Recursion Equations as a Programming Language. In: Darlington, John, David Turner and Peter B. Henderson. “Functional Programming and its Applications: An Advanced Course.”
[Turn12]: Turner DA. Some history of functional programming languages. In International Symposium on Trends in Functional Programming 2012 Jun 12 (pp. 1-20). Springer, Berlin, Heidelberg.
[VAX82]: VAX Product Sales Guide EG-21731-18, Apr. 82
[Vegd84]: Vegdahl. (1984). A Survey of Proposed Architectures for the Execution of Functional Languages. IEEE Transactions on Computers, C-33(12), 1050–1071. doi:10.1109/tc.1984.1676387 
[Will88]: J. H. Williams and E. L. Wimmers. 1988. Sacrificing simplicity for convenience: Where do you draw the line? In Proceedings of the 15th ACM SIGPLAN-SIGACT symposium on Principles of programming languages (POPL '88). Association for Computing Machinery, New York, NY, USA, 169–179. doi:10.1145/73560.73575
[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

6
index.md
View file

@ -2,7 +2,7 @@
=======
[Часть 0: Что было, когда функционального программирования не было.](prehist.md)
[Часть 1: Первые компиляторы.](compilers.md)
[Часть 1: Каталог компиляторов.](compilers.md)
---------------------------
@ -12,6 +12,8 @@
---------------------------
[Обновление 2025-01-08](compilers.md#сон-черного-короля)
[Обновление 2024-12-02](compilers.md#скобочный-потолок)
[Обновление 2024-11-01](compilers.md#норман-и-norma)
@ -30,7 +32,7 @@
[Обновление 2024-03-31](compilers.md#редукция-графов-и-как-её-избежать)
[Обновление 2024-02-29](compilers.md#часть-1-первые-компиляторы)
[Обновление 2024-02-29](compilers.md#часть-1-каталог-компиляторов)
[Обновление 2024-01-11](prehist.md#сколько-тысяч-слов--все-впустую)