Add update links to index.md

hopes.md

@@ -31,6 +31,14 @@
     - [Пираты Кремниевой Долины](#пираты-кремниевой-долины)
     - [Дети Дюны](#дети-дюны)
     - [Отец с атомным сердцем](#отец-с-атомным-сердцем)
+  - [Big in Japan](#big-in-japan)
+    - [Успели забыть о Прологе больше, чем японцы успели узнать](#успели-забыть-о-прологе-больше-чем-японцы-успели-узнать)
+    - [Новая надежда](#новая-надежда)
+    - [Граф 0](#граф-0)
+    - [Барендрегт против лямбды](#барендрегт-против-лямбды)
+    - [Самый известный птеродактиль на Панталасском театре](#самый-известный-птеродактиль-на-панталасском-театре)
+    - [Негативное пространство](#негативное-пространство)
+    - [День зависимости](#день-зависимости)
 - [Литература](#литература)
 
 
@@ -980,7 +988,7 @@ Le ML (CAML) [Maun86]
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
 SML/NJ 0.18 [Augu89]
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
-_C_ [Augu89]
+C [Augu89]
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
 ANU ML (VAX ML) [Augu84]
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
@@ -996,7 +1004,7 @@ Le LML [Maun86]
 ░░░░░░░░
 Edinburgh ML [Augu89]
 ░░░░░░░
-_LCF/ML_ [Augu84]
+LCF/ML [Augu84]
 ░
 ```
 
@@ -1062,11 +1070,478 @@ Franz существовала на совсем другом уровне. Дж
 И когда KCL перестал обновляться, пришлось Шелтеру разрабатывать набор патчей для него - Austin Kyoto Common Lisp. Пока CMUCL не начал поддерживать хоть какие-то актуальные для академии платформы, вся экосистема открытого кода на Common Lisp держалась на одном человеке.   
 Так что технически компиляция ФЯ через Common Lisp была возможна, но возможность эта была пока что не особенно привлекательна. Так что имплементаторы ФЯ желающие использовать Лисп рассматривали и другие варианты. Но это уже другая история.   
 
+Big in Japan
+------------
+
+> Срочный, захватывающий и грамотный репортаж о головокружительном будущем компьютерной революции.   
+> San Francisco Chronicle   
+
+> Это не просто вторая компьютерная революция, это важнейшая из двух.   
+> Эдвард Фейгенбаум [Feig83]   
+
+> УЛЕТ, ОТПАД!   
+> The New York Times   
+
+> Настоятельно рекомендуем... должно быть прочитано каждым, кого интересует экономическое и технологическое будущее.   
+> Library Journal   
+
+В прошлой части мы оставили создателей (симуляторов) специализированного железа в не самое лучшее для них время. Но перед тем, как дела у них пошли совсем уж плохо, ситуация ненадолго улучшились. Помощь пришла из Японии.   
+Еще в 79-ом году в Министерстве международной торговли и промышленности Японии (Ministry of International Trade and Industry) появилось желание начать амбициозный проект по созданию компьютера нового поколения [Shap83]. Следующее поколение выходило пятым, так этот проект впоследствии и стали называть. По видимому, это была реакция на обсуждения "кризиса программного обеспечения" и стартовавшие в 77-79-ом проекты, о которых мы уже рассказывали.   
+Министерство выяснило, что считает компьютером будущего индустрия. Оказалось, что в индустрии считают, что это графическая рабочая станция с большой памятью для микрокода вроде тех, что сделали в лабораториях Xerox. И сеть будущего - это Ethernet.   
+Тут они были правы, в 80-е многие делали рабочие станции и даже персональные компьютеры верхнего ценового диапазона вроде Макинтоша, на которые явно повлияли эти машины. Микрокодовый аспект, правда, не был важным. Но этот ответ не понравился министерству.   
+И дело не в том, что для успеха нужно пробовать что-то новое, а не пытаться сделать лучше то, что уже кто-то делает. Предыдущие программы министерства как раз направляли такое догоняющее развитие и были успешны. Может быть, слишком успешны. Потому, что сформировали стереотип, который министерство хотело сломать новой программой.   
+Для того чтоб продолжать заниматься тем, чем все компьютерные компании занимались и так, помощь министерства промышленности уже не требовалась. Весь смысл был в том, чтоб попробовать по-развивать что-то, что компьютерным компаниям обычно не так интересно. Но что именно? Как мы выяснили в предыдущих главах, придумано уже довольно много вещей, которые компьютерным компаниям не так уж интересны.   
+И работник NTT Мураками Кунио (Kunio Murakami) нашел для министерства промышленности обладателей виденья достаточно амбициозного будущего: это были знакомые его начальника Мото-Ока Тору (Moto-Oka Tohru) и Фути Кадзухиро (Fuchi Kazuhiro). Познакомились они за десятилетия до того в университете в США. И достаточно интересным виденьем будущего, которое они нашли для министерства промышленности, были параллельные компьютеры программируемые на Прологе. У японской промышленность не было никакого энтузиазма, там точно не стали бы заниматься этим, если б не министерство промышленности. У неяпонской промышленности энтузиазма тоже не было. То что надо!   
+Почему параллельные машины программируются именно на Прологе? Фути интересовался МТИ-антипрологом Planner и идеями Ковальского но не считал их особенно практичными. Но в 76-ом году Фурукава Коити (Furukawa Koichi) привез Фути из SRI ксерокопию ксерокопии ксерокопии распечатки FORTRAN-исходников Марсельского интерпретатора Пролога. Восстановленный Фути по распечаткам Марсельский интерпретатор работал быстрее, чем он ожидал и его мнение о практичности идей Ковальского изменилось в лучшую сторону. Мото-Ока решил, что Пролог - язык будущего не только потому, что был знаком с Фути, но и потому, что Пролог полюбили его студенты.   
+Помогло победить Прологу еще и то, что он соревновался не с такими же и даже более экзотическими языками, о которых мы писали в предыдущих главах, а с Лиспом. И Лисп в это время выглядел еще слишком нормальным для министерства промышленности, еще не откололся от унылого мейнстримного будущего рабочих станций.   
+Планы был обнародованы в октябре 81, а проект стартовал в апреле 82-го года. Для осуществления плана был сформирован исследовательский институт ICOT, Фути стал его директором, Мураками - руководителем лаборатории, занимающейся железом, а Фурукава - руководителем лаборатории, занимающейся ПО.   
+Бюджет на 83-ий финансовый год был 11 миллионов долларов ($36.8M в 2025) - полтора проекта MAC 63-его года. За десятилетие получилось 320 миллионов долларов (миллиард долларов 2025-го).   
+Насколько это много? Сотрудник министерства международной торговли и промышленности Накамура посчитал, что не особенно много [Odag97], он утверждает, что каждый год, пока проект продолжался, он никогда не превышал 1% от расходов на R&D японской коммерческой электроники и телекома. И в один только первый год японского проекта по созданию компьютера пятого поколения в IBM потратили на R&D в пять раз больше, чем японцы на весь проект компьютера пятого поколения.   
+Можно согласиться, что это мало для создания компьютера пятого поколения. Но похоже на то, что это существенная поддержка для Пролога. Разумеется, только часть этих средств были потрачены на важные для развития Пролога работы. Но это означает, что в течении десятилетия только в ICOT в лаборатории Фурукавы над программным инструментарием для Пролога постоянно работали 8-10 человек. Что по-видимому сравнимо с вкладом Mozilla в развитие Rust. Конечно, начало такого десятилетия для Пролога было во времена, когда программисты писали по тысяче строк в год, так что сравнимые ресурсы вряд ли давали сравнимый результат.   
+Но даже скромные результаты были нужны для Пролога, который к началу японской инициативы переживал не самые лучшие времена. В это время компилятор Уоррена гибнет вместе с PDP-10. И чтоб начать что-то писать на Прологе в ICOT приходится использовать доживающие последние годы машины DEC, на которых работает единственная серьезная имплементация Пролога.   
+Но мы не пишем историю Пролога. И для нашей истории важнее не японский проект по созданию "компьютера пятого поколения", а реакция на него. А реакция была существенной.   
+Дело в том, что в 80-е, после успехов предыдущих и до потерянных следующих десятилетий, к тому, что считают перспективным в Японии относились серьезно. Первые сообщения о японском проекте не были сфокусированы на Прологе и новости о том, что в Японии считают ИИ перспективным были использованы для того, чтоб вдохнуть новую жизнь во многие проекты. Или правильнее сказать - гальванизировать многие проекты.   
+Дело не ограничивалось Прологом или параллелизмом. Например, Эдвард "Отец экспертных систем" Фейгенбаум (Edward Feigenbaum) и Памела МакКордак (Pamela McCorduck) написали книгу под названием "Пятое поколение: искусственный интеллект и японский компьютерный вызов миру" [Feig83]. Книга вышла в 83-ем, а в 84-ом её переиздали в мягкой обложке, на которой изображена Статуя Свободы в гриме осирои, держащая факел в механической руке. Фейгенбаум "раздувал" японскую угрозу, считает пишущая историю ИИ-стартапов 80-х Филлипс, чтобы напугать своего читателя и подтолкнуть его к действию. Успешно. Что же читатель должен был делать? Разумеется, платить отцу экспертных систем деньги.   
+Он поучаствовал в основании двух компаний [Phil99]. Первая - называвшаяся сначала IntelliGenetics, а позднее IntelliCorp, пыталась коммерциализировать экспертную систему MYCIN, над которой  Фейгенбаум работал в 70-е годы в Стенфорде. Не данные, но саму программу на Лиспе, которую предполагалось наполнять данными пользователя. Этой компании противостояла вторая компания, основанная Фейгенбаумом - Teknowledge. Вторая компания должна была победить первую, продавая более дешевый инструментарий для создания экспертных систем, работающий на более дешевых компьютерах. Как этого можно было добиться? Использовав вместо Лиспа и Пролога новый, перспективный язык для разработки искусственного интеллекта - C. Teknowledge была открывателем и законодателем моды на этот язык среди разработчиков экспертных систем 80-х. Да, успехи по избавлению от ассоциации с ИИ у разных языков и "парадигм" программирования были очень разными.   
+К этой очередной победе лисперов над Лиспом и ее последствиям мы вернемся позднее, а сейчас настала очередь важнейшего для нашей истории ответа на японский вызов. И важнейшим для нашей истории был ответ британцев, которые уже 
+
+### Успели забыть о Прологе больше, чем японцы успели узнать
+
+Великобритания ответила на японскую программу пятого поколения в июне 83-го программой Алви (Alvey). Джон Алви (John Alvey) - это председатель комитета, который рекомендовал ответить. Ответ был размером в 350 миллионов фунтов (1 миллиард 830 миллионов долларов в 2025). Из них 200 были от государства и 150 от коммерческих компаний [Blac85] [Oakl90].   
+Да, это почти в два раза больше средств, потраченных за примерно вдвое меньшее время. Потраченных экономикой меньшего размера, чем японская. И не смотря на все это, история с пятым поколением ассоциируется в основном с Японией.   
+Ответ не предполагал создания специального института, хотя наш знакомый по нулевой части Мики и пытался это организовать.   
+Как обычно, новости из Японии были представлены всеми как убедительное подтверждение того, что им нужно и дальше продолжать делать то, что они и так делали. Правда, новостей о том, что искусственный интеллект объявили чем-то перспективным в Японии, по-видимому, было еще недостаточно для реабилитации его в Британии после отчета Лайтхилла, так что ИИ обычно фигурирует под псевдонимом "интеллектуальные базы знаний", IKBS (Intelligent Knowledge-Based Systems).   
+Кому из героев нашей истории лучше всего удалось убедить, что им нужно продолжать давать деньги на то же самое? Это были создатели (симулятора) HOPE-машины ALICE из Имперского Колледжа Лондона, группа Дарлингтона.   
+В рамках программы Алви разрабатывались четыре проекта, "большие демонстраторы". И компании -  основные исполнители двух из них посчитали (или, может быть отдельные элементы внутри этих компаний посчитали), что им понадобится параллельный компьютер вроде ALICE.  
+ICL занималась системой для министерства здравоохранения, а Plessey - самым амбициозным проектом программы Алви: распознаванием речи.   
+ICL (International Computers Limited) - компания, разрабатывавшая компьютеры на которых использовали POP-2 в Эдинбурге и KRC в Кенте. ICL в 60-е купила компьютерный отдел Ferranti, которая в свое время построила Atlas и Atlas 2, для которых пытались имплементировать CPL. И вот эта компания ICL решила построить для Дарлингтона с коллегами ALICE, которую те только симулировали. И похожий на ALICE, но новый параллельный компьютер, который разрабатывали уже для программы Алви.   
+И благодаря предполагаемой нужности для двух демонстраторов из четырех, проект создания этого компьютера стал самым большим проектом программы Алви. 3 декабря 85-го британский министр промышленности и информационных технологий обнародовал детали [Dett86]. И раз уж проект самый большой - его называли Flagship. Насколько большой? 15.5 миллионов фунтов (80 миллионов долларов в 2025). Новый проект объединял проект ALICE Имперского колледжа Лондона с проектом Университета Манчестера, построившего dataflow-машину MDF.  
+ICL построила три прототипа ALICE. Первый прототип ALICE заработал в феврале 86-го [SPJ87] [Fiel88]. Так ALICE стала реальностью, но реальность эта оказалась не слишком радужной. Реальная машина работала "разочаровывающе медленно" [Clac24].   
+Насколько медленно? nfib-число этой машины было 16000 [Harr87], что немного побыстрее, чем SKIM II, но в два раза медленнее, чем NORMA. И это производительность всей параллельной машины. Один переписыватель графов в ней, более точный аналог SKIM II и NORMA имел nfib-число в 1000.   
+У разочаровывающе медленной работы было несколько причин. Реальная ALICE, которую построили в ICL, существенно отличалась от ALICE, которую задумывали в Имперском Колледже. Предполагалось [Dett86], что сеть, соединяющая вычислительные элементы с памятью будет работать со скоростью 300Мбит/сек., реальный кастомный чип, который переключал соединения между вычислительными элементами мог переключать достаточно быстро, чтоб обеспечить скорость в 150Мбит/сек., а реальные вычислительные элементы, построенные на Transputer, британской компании INMOS могли установить соединение только в 10Мбит/сек. Но такой медленной сети хватало, чтоб продемонстрировать хорошую распараллеливаемость вычисления чисел Фибоначчи потому, что переписыватели графов были очень медленными - интерпретаторами промежуточного языка ALICE ISL (Implementation Specific Language), написанными на OCCAM [Harr87].   
+Эти проблемы можно было исправить, в 86-ом году уже умеют делать переписыватели графов намного быстрее. Но главная проблема ALICE не имела отношения к особенностям имплементации в ICL, она была архитектурной. Даже задуманная сеть в 300 Мбит/c не лучшее средство для соединения вычислительных элементов имеющих только 64Кб локальной памяти с блоками памяти в 2Мб, как это предполагали делать разработчики ALICE.   
+У новой машины Flagship, которую разрабатывали в университете Манчестера и собирались построить в ICL к 88-му году, другая архитектура. В Flagship нет разделения на блоки памяти и вычислительные. У каждого вычислительного блока мегабайты памяти, к которой он имеет более быстрый доступ, чем через сеть к памяти остальных вычислительных блоков. И эксперименты с симулятором показали, что можно добиться 90% обращений к памяти в том же вычислительном блоке вообще без создания нагрузки на сеть для соединения блоков. И вычислительные блоки делались на процессорах MC68020. Пусть не британских, зато быстро работающих.   
+Но для нашей истории, конечно, важнее не эти машины, а что машинистами было сделано полезного для имплементаций на обычном железе.   
+
+### Новая надежда
+
+Flagship был частью британского ответа на планы японцев по построению Пролог-машин. Но главным языком программирования этого проекта стал не Пролог, а HOPE.   
+Не единственным. Работали над имплементациями на Flagship-машине и других языков, в том числе и Пролога. Но главным - на котором должно был быть написано системное ПО - выбрали HOPE.   
+Причиной того, что выбрали HOPE, а не Пролог называют [Kean94] то, что в Имперском Колледже Лондона группа Дарлингтона уже занималась имплементацией HOPE и просто продолжила делать то, что уже делала. Что было вполне обычной реакцией на японский проект. Но Имперский Колледж был и важным центром по работе над Прологом. Ковальский из Эдинбурга отправился работать как раз туда.   
+Трудно сказать насколько на выбор языка повлияли технические аргументы, а не какие-то административные маневры, но аргументы были.
+Во-первых, Пролог из за красных катов и императивных "предикатов" - менее "декларативный" язык, чем чисто функциональный ФЯ. Программисту на Прологе поэтому нужно больше думать о процедурной семантике.   
+Проблема этого аргумента в том, что те же претензии можно предъявить и к реально существующим в это время функциональным языкам. Как мы помним, эдинбургский HOPE только называется чисто функциональным, в реальном коде используют функции с побочными эффектами, написанными на POP-2. Как решать практические проблемы вроде ввода-вывода не нарушая чистоту языка пока не придумали.   
+К истории того как эти проблемы решали в ФЯ и некоторых логических языках мы вернемся в следующей части.   
+Следующим преимуществом ФЯ называют то, что ФЯ с хорошей производительностью имплементировать легче, чем Пролог. Что звучит правдоподобно, но как мы выяснили в нулевой части нашей истории, имплементацию Пролога с хорошей производительностью удалось сделать раньше, чем такую имплементацию языка, похожего на HOPE.   
+С остальными аргументами поспорить значительно труднее: в HOPE есть типы и функции высшего порядка, а в Прологе их нет.   
+Уоррен, правда, убеждал, что конструкции высшего порядка в Прологе и не нужны. Но убеждал не очень успешно в описываемое время. Сегодня мы знаем, что он победил и Пролог остался Прологом. Но в 80-е появились планы по усовершенствованию Пролога примерно таким же образом, каким в это время усовершенствовали ФЯ.   
+Когда-то типов и ФВП не было и в NPL и Пролого-образные языки позднее расширят и типами и ФВП. Но, по видимому, слишком поздно. О HOPE-фикации Пролога мы расскажем подробнее в другой главе.   
+Роль основного языка принесла и новые вызовы. Эдинбургский HOPE, E-HOPE, как его называли в Лондоне - ФЯ не самый практичный. И его эдинбургский интерпретатор - тем более.   
+И решение этой проблемы нельзя откладывать до появления HOPE-машины. Нужна быстрая имплементация для обычных машин. Потому, что нужно писать код еще до того, как первый прототип специальной машины будет готов.   
+На судьбоносном совещании в лаборатории Резерфорда - Эплтона Лондонская группа сообщала, что собирается написать более быстрый интерпретатор промежуточного языка, чем симулятор параллельного компьютера.   
+И можно бы было ожидать, что более практическая имплементация HOPE для обычных машин будет просто еще одним бэкендом для компилятора в инструкции параллельной машины. Который транслирует из того же промежуточного языка. Со временем такой компилятор действительно появился. Но только со временем.   
+Сначала в Лондоне написали один за другим два компилятора HOPE для разработки на обычных машинах, которые имели мало общего с компиляторами для параллельных машин. В самом большом проекте британской программы по созданию компьютера пятого поколения такое могли себе позволить. Развитие событий практически неизбежное потому, что этот самый промежуточный язык для новой специальной машины разрабатывался не в Лондоне и даже не в рамках того же проекта. Даже сегодня разработчики могли бы выбрать что-то внутреннее, не отягощенное координацией с другим проектом. Что уж говорить о временах бумажной корреспонденции и посылок с магнитной лентой.   
+Нежелание использовать результаты этого параллельного проекта оправдалось, промежуточный язык не был готов к тому времени, когда Лондонской группе Дарлингтона уже нужно было начинать писать ПО на HOPE.       
+Первый компилятор - IC HOPE для VAX-11 написал Энтони Филд (Antony Field) [Fiel88] [Perr91], имплементировав виртуальную машину под названием FPM (Functional Programming Machine). Есть ссылки на недошедший до нас университетский отчет 85-го года о нем.   
+Имплементаторы HOPE противопоставляют FPM остальным функциональным виртуальным машинам и утверждают [Perr91], что с имплементациями обычных языков программирования вроде Algol 60 у FPM больше общего. Спорное утверждение. Может и справедливо в случае G-машины или CAM, но FPM довольно похожа на FAM Карделли или имплементацию Poly (ML).   
+FPM - это очередная практичная версия SECD с поддержкой замыканий и оптимизация хвостовых вызовов. С копирующим сборщиком с фиксированным размером кучи. Там типы данных - обычно объекты кучи с тегами, но есть пары без поля для тега. И целые числа не являются объектами в куче вовсе, отличаются от указателей с помощью двухбитных тегов. Все это гораздо ближе к FAM, чем даже к самым смелым мечтам о функциональном Алголе 68, что уж говорить об Алголе 60.   
+Существенное отличие от FAM только в том, что в FPM отсутствуют оптимизации для каррирования. Это  объяснимо, объявления функций в HOPE (пока что) не декларируют каррированные по умолчанию функции.   
+И IC-HOPE похож на компилятор Карделли. Операции ВМ разворачиваются макросами. И производительность генерируемого кода вычисления чисел Фибоначчи получилась побыстрее LML, но помедленнее, чем SML/NJ. Как и у компилятора Карделли.   
+Хорошо измерить производительность, правда, не успели. Первый компилятор быстро устарел, потеряв актуальность вместе с VAX-11. На смену этому компилятору для VAX вскоре пришел следующий компилятор, для MC68K.   
+Этот компилятор написали [Perr91] Найджел Перри (Nigel Perry) и Кейт Сефтон (Keith Sephton). Рантайм был доработан и куча теперь могла расти во время исполнения. Генерируемый код стал заметно быстрее.   
+Имперский Колледж Лондона распространял этот компилятор, анонс появился в рассылках в декабре 88-го года.   
+Переход на более перспективную платформу - не единственная причина для развития компилятора. Проблему практичности Эдинбургского HOPE не решить одной только быстрой имплементацией. Нужны изменения в самом языке.  
+Интересно, что с развитием HOPE сложилась ситуация, симметричная ситуации с развитием ML. Ядро разработчиков HOPE в Эдинбурге не особенно заботилось о похожести в деталях и забросило HOPE, начав проектирование Standard NPL. Извините, Standard ML. Периферийная группа разработчиков в Лондоне заботилась о сохранении детального сходства с HOPE гораздо сильнее, как и в случае с ML и INRIA.  
+Но в случае HOPE это более объяснимо, чем в случае ML. Эдинбургские разработчики NPL, HOPE и SML никогда особенно не заботились о деталях. И каждая версия, которых было множество, требовала бы править практически каждую строку кода. Если бы он был. Это кардинально отличается от LCF/ML, который не менялся долгие годы.   
+И стремление группы Дарлингтона изменять HOPE меньше не было полностью добровольным. У того, что HOPE стал основным языком флагманского проекта директората Алви, были не только полезные для его практичности последствия. Оказалось, что раз уж на заседаниях комитетов и комиссий договорились имплементировать HOPE, то нужно имплементировать HOPE а не какой-нибудь SML. Не совсем понятно какие отклонения от HOPE группа Дарлингтона могла себе позволить, но какие-то могла. Если и не HOPE 2, то по крайней мере HOPE+.
+ И второй компилятор имплементировал этот HOPE+.   
+Некоторые изменения в HOPE+ по сравнению с HOPE были сделаны для решения тех же проблем и решения были теми же, что в SML. В HOPE+, как и в SML, добавили [Darl89] [Robe89] целые числа со знаком и числа с плавающей точкой, массивы и стандартные 8-битные символы.   
+Судя по "категорному" коду, про который мы рассказывали в нулевой части, немногочисленные программисты на HOPE любили писать много локальных функций не требующих сигнатур с указанием типов. В отличие от тех, что на топлевеле. Так что в HOPE+ написание таких функций сделали удобнее, разрешив в `let` и `where` рекурсию.   
+Некоторые решения, хоть и были похожими - все же отличались. В HOPE планировали добавить исключения и их добавили и в SML и в HOPE+, но это были разные разновидности исключений. Чтоб не нарушить чистоту языка в HOPE+ сделали значения-ошибки, населяющие каждый ссылочный тип.   
+В новом HOPE (пока) не сделали функции каррированными по умолчанию, но в функциональном языке удобное частичное применение желательно, так что оно все равно было добавлено. Добавлено, как и в SML, но не такое как в SML. В новом HOPE можно было писать `f(?,x,?)` что соответствовало такой вот лямбде `lambda (a, b) => f(a, x, b)`.   
+Но некоторые выводы, которые сделали из опыта применения HOPE в Эдинбурге существенно отличались от выводов сделанных в Лондоне.   
+Опыт имплементации перегрузки в HOPE не считался особенно удачным, в основном из-за сложного и медленного алгоритма. В Эдинбурге не отказались от перегрузки полностью, как в свое время в LCF/ML. Но в SML она осталась для ограниченного набора операций. В новом HOPE перегрузка для пользовательских функций осталась, но имплементированная с помощью более быстрого алгоритма и несколько иначе. Старое поведение перегрузки не было определено ничем кроме эдинбургской POP-2 имплементации и не было воспроизведено полностью.   
+В SML отказались от паттерн-матчинга независящего от последовательности уравнений, который считали важным разработчики языков алгебраической спецификации. В Лондоне не порвали с этим алгебраическим прошлым и последовательность уравнений не стала важной как стала важной в SML, Прологе и языках Тернера. Но программисты хотели писать ПМ с пересекающимися паттернами, так что для HOPE+ нашли более-менее понятную систему определения того, какое сопоставление с образцом более точное [Perr91].   
+Сопоставление паттернов-констант - более точное, чем сопоставление с переменной. Так что при применении функции 
+
+```
+--- f(1, y) <= y; (a)
+--- f(x, 2) <= x; (b)
+--- f(a, b) <= a * b; (c)
+```
+
+так `f(1,3)` будет выбрано уравнение (a), в случае `f(5,2)` уравнение (b), в случае `f(3,4)` уравнение (c), а применение `f(1,2)` вызовет ошибку во время исполнения потому, что ни один из вариантов (a) и (b) не подходит лучше другого. Компилятор предупреждал о возможности такого исхода во время компиляции.   
+Эдинбургской группе разработчиков HOPE не пригодилась ленивость и в SML не попали ленивые списки из HOPE. Лондонская группа посчитала ленивость полезной, так что в HOPE+ все конструкторы стали ленивыми. Правда, функции все равно строгие, каждый параметр вычисляется до первого конструктора.   
+Это сочетание сегодня выглядит довольно необычно. И противоположно популярным рекомендациям писать на Haskell ленивые функции и типы данных со строгими полями.   
+В другом HOPE+ можно было добиться более привычного в наше время поведения. В другом HOPE+?   
+Между компиляторами HOPE для обычных машин и машин параллельных было мало общего. Разумеется, это привело к тому, что они имплементировали разные языки.   
+В параллельном HOPE+ были аннотации ленивости [Glyn90] и можно было форсировать "позвоночник" структуры данных без форсирования элементов:
+
+```
+dec length : !# ST SN #! list alpha -> num;
+```
+
+Или вычислить всю структуру:
+
+```
+dec sum : !# ST IN #! list num -> num;
+```
+
+А можно было и сделать функции ленивыми:
+
+```
+dec append : !# ST(WH,UN) #! (list alpha # list alpha) -> list alpha;
+```
+
+Здесь `WH` - аннотация поведения по умолчанию, вычисления до первого конструктора. А `UN` - означает ленивый аргумент. Так что параллельный HOPE+, пусть и с помощью аннотаций, но мог быть более обычным в наше время ленивым языком.   
+Практически до самого конца проекта в параллельном HOPE+ был [Robe89] и более привычный для нас сегодня паттерн-матчинг. Паттерны могли пересекаться и результат сопоставления зависел от последовательности уравнений. Прочие отличия были менее интересными недоработками. Взаимная рекурсия в `let` и `where` и числа с плавающей точкой не были имплементированы.   
+Отличий вариантов HOPE+ от HOPE не достаточно, чтоб наш обычный пример выглядел существенно иначе:
+
+```
+infixr :: : 5;
+data list alpha == nil ++ alpha :: list alpha;
+
+dec map : (alpha -> beta) # list alpha -> list beta;
+--- map(f, nil) <= nil;
+--- map(f, x::xs) <= f x::map(f, xs);
+
+map(lambda x => x+y,[1,2,3]) where y == 1 end;
+```
+
+Он мог бы быть полностью идентичным, но мы не ставили перед собой такой цели.   
+Для тех, кто не был убежден в ненужности Пролога Лондонские разработчики HOPE планировали логические расширения. И даже имплементировали, хоть и не в основном, рабочем компиляторе.   
+Возможно, делать "функции" со многими результатами по умолчанию - не самая хорошая идея. Но почему бы не добавить в язык специальную нотацию для этого? Такая нотация - ЦФ-выражения уже была в языках Тернера и в NPL. И планировалась для HOPE, но долгое время продолжала только планироваться.   
+
+```
+filter(p,xs) <= {x | x in xs : p x}
+```
+
+Правда, ЦФ-выражения, list comprehensions - не встроенный Пролог, а скорее какой-то из анти-Прологов Сассмана и Хьюита. Но что если встроить именно Пролог?   
+
+```
+{(l1, l2) with l1, l2 | l1 <> l2 = [1, 2]}
+{([], [1, 2]), ([1], [2]), ([1, 2], [])} : set(list num # list num)
+```
+
+Теперь функции можно применять слева от `=` как в более выразительных языках алгебраической спецификации. Но пока что только внутри новых "абсолютных абстракций множеств" [Darl87] [Darl89].   
+Существует ли список из двух элементов?
+
+```
+{l with l | length l = 2}
+```
+
+Да!
+
+```
+{u :: (v :: nil)} : set(list alpha)
+```
+
+В функциональных языках Эдинбургской исследовательской программы такие расширения не прижились. Они сыграли более заметную роль в HOPE-фикации Пролога. Но это уже другая история.   
+
+### Граф 0
+
+В апреле 84-го при поддержке директората Alvey состоялась встреча представителей академии и индустрии на которой обсуждали общую вычислительную модель для параллельных вычислений. Участники встречи разделились на два лагеря. Одни считали, что общий промежуточный язык будет иметь достаточно плюсов чтоб скомпенсировать возможные проблемы с производительностью. Другие считали, что  производительность слишком важна для таких компромиссов. Сторонники единого промежуточного языка победили. Победили в первой битве, но смогли ли они победить в войне? Давайте выясним.   
+Единый промежуточный язык назвали DACTL (Declarative Alvey Compiler Target Language). DACTL должен [Glau87] был подходить для трансляции в него таких языков как HOPE, Prolog и даже Lisp. Промежуточный язык также должен был подходить для исполнения на параллельных машинах программы Алви, и это не только Flagship-машина. О другой спецмашине программы мы еще расскажем позднее.   
+Язык должен был быть достаточно низкоуровневым чтоб описывать детали порядка вычисления и где происходит копирование, а где - переписывание для разделения результатов. Но не слишком низкоуровневым. Быть ФЯ, о свойствах кода на котором легко рассуждать и свойства которого легко доказывать.   
+Директорат Алви организовал команду по разработке DACTL в июле 84-го. Процесс создания DACTL пошел в Университете Восточной Англии (University of East Anglia) под руководством Ронана Слипа (Ronan Sleep) и Джона Глоерта (John Glauert).   
+Слип был соавтором героя прошлой части Келлера. Второй руководитель был связан с событиями предыдущих частей сильнее.   
+Глоерт [Glau1] [Glau2] получил степень бакалавра в Кембридже в 76-ом. Степень магистра он получал в Университете Манчестера, где в это время шли работы над Dataflow-машиной, которую мы упоминали в прошлой части. Магистерская диссертация была об имплементации ФЯ с рекурсией на Dataflow-машине.   
+Вернувшись после этого в Кембридж Глоерт защитил там докторскую диссертацию. Затем он вернулся в Манчестер и снова поработал там в Dataflow-проекте, над дизайном и имплементацией SISAL. После всего этого, в 84-ом году Глоерт начал работу в Университете Восточной Англии.   
+DACTL планировали создать за три итерации [Glau87]. Описание первой итерации Dactl0 было готово в мае 85-го. В сентябре 85-го состоялся первый релиз образцового интерпретатора [Glau91].   
+Финансирование от Alvey стало поступать в университет с мая 85-го. DACTL-проект был третьим по размеру спецмашинным проектом Алви. Выделенные на него средства [Blac85] - 360тыс. фунтов или 1.9 миллионов долларов в 2025 - были несопоставимы с первым по размеру проектом Flagship, но вполне сопоставимы со вторым.   
+DACTL - язык уравнений с паттерн-матчингом [Glau87]
+
+```
+PROGRAM test;
+IMPORTS lists;
+ATOM append;
+RULE
+<append nil $x> => !$x;
+<append <cons $h $t> $x> := <cons $h !<append $t $x>>;
+<append $a $b> := !<append !$a $b>;
+REWRITE !<append <cons 1 nil> <cons 2 nil>>;
+ENDPROGRAM test;
+```
+
+паттерны в Dactl лево-линейные (имена переменных не могут повторяться в паттерне для обозначения равенства).   
+Все вычисления явно обозначаются `!` и если восклицательного знака нет - это не вызов функции, а просто данные, конструкторы. Переписывание на месте `:=` и возвращение копии ссылки `=>` тоже явно указывается.  
+Вся эта получившаяся явность авторам быстро разонравилась и они решили сделать следующую версию менее явной или, по крайней мере сделать указания менее многословными и более высокоуровневыми.  
+И если не хватало проблем со взаимодействием между проектами от того, что промежуточный язык разрабатывается в отдельном проекте от имплементирующих его машин и компилирующих в него компиляторов, то теперь проект разработки промежуточного языка стал еще и международным.
+
+### Барендрегт против лямбды
+
+Университет Восточной Англии [Glau87] [Brus87] объединил усилия с голландским проектом по созданию параллельной машины редукции (Dutch Parallel Reduction Machine Project) под руководством более известного другими своими работами Хенка Барендрегта (Hendrik Pieter Barendregt).   
+Совместно они разработали язык LEAN (the Language of East Anglia and Nijmegen), который стал основой для Dactl1. Да, это означает, что у разработки Dactl было более трех итераций, но это, наверное, самое безобидное отклонение от первоначальных планов. Этот LEAN не имеет никакого отношения к современному языку Lean.   
+Как было принято в 80-х, Нидерланды тоже решили ответить на японский вызов [Bare87]. Так что в ноябре 1984 три исследовательских группы университетов Амстердама, Неймегена и Утрехта
+начали совместный проект, спонсируемый министерством науки и образования. 
+Первая фаза, продолжающаяся до конца 87-го должна была ответить на вопрос: возможно ли и реалистично ли построить эффективную машину параллельной редукции? Эта цель может показаться не очень амбициозной но голландский ответ на японский вызов был довольно серьезным. Разрабатывались как минимум две специальные машины. Philips Laboratories работали над Distributed Object Oriented Machine, а университеты над Experimental Parallel Reduction Machine.   
+Что более важно для нашей истории - разрабатывали семейство быстрых имплементаций функциональных языков для обычных машин, которое если и не живет в полном смысле этого слова, то по крайней мере влачит жалкое существование до сих пор.   
+Первая имплементация семейства имплементировала не язык LEAN, а его чисто-функциональное подмножество без операции переписывания `:=` - язык CLEAN.   
+Некоторые читатели, возможно, знают современный язык с таким названием - чисто-функциональный ленивый язык с классами типов, который известен приличной производительностью, которая достигается не без помощи "плоских" объектов и уникальных типов, использующихся для изменения массивов на месте. Это не тот язык о котором мы рассказываем сейчас. В нем нет массивов, классов типов, уникальных типов да и типов вообще.   
+Нельзя сказать, что CLEAN 87-го года не имеет никакого отношения к современному, как было в случае LEAN. У первого и современного CLEAN общие авторы Марко ван Ээкелен (Marko C.J.D. van Eekelen) и его научрук Маринус Плазмейер (Marinus J. Plasmeijer). Оба языка являются продуктами одной исследовательской программы. Но один не превратился в другой путем добавления тех фич, которые сегодня выделяют Clean из множества прочих ФЯ. Синтаксически они настолько различны, насколько возможно в обсуждаемую эпоху HOPE-фикации. Первый CLEAN как LML, HOPE и SML происходят от поздних версий NPL с характерными разделителями между уравнениями одной группы, а современный Clean как Haskell и языки Тернера от раннего NPL с более легковесным синтаксисом.
+Мелкие отличия от прочих поздних NPL-ей CLEAN 87 по видимому унаследовал от предыдущего ФЯ Барендрегта под названием TALE (Typed Applicative Language Experiment) [Bare86] на момент описания в 86-ом году Он не был имплементирован и не было конкретных планов имплементации.   
+
+```
+list $ t = rectype ls: (* |(t, ls)).
+
+Def:
+map f <>    -> <>;
+map f (a:b) -> (f a) : (map f b).
+
+map (`x -> x + y) <1, 2, 3> where y = 1 end
+```
+
+Так выглядит TALE, а (C)LEAN - намного проще [Brus87].
+
+```
+Map f Nil -> Nil |
+Map f (Cons a b) -> Cons (Ap f a) (Map f b);
+```
+
+Планы имплементации CLEAN были. И та их часть, которая касалась обычных компьютеров была осуществлена.  
+Разработчики CLEAN считают, что хорошую имплементацию ФЯ на обычном железе может сделать и не так просто, но сделать можно. В середине 80-х эта проблема решена. Имплементаторы ФЯ теперь знают как эффективно реализовать ленивость, возвращение функций из функций и рекурсию. Если оптимизировать хвостовые вызовы, использовать редукцию графов и избегать ее где это возможно, заменяя обычными вычислениями на стеке, то можно добиться производительности сравнимой с имплементациями обычных императивных языков.   
+Разработчики CLEAN считают, что не все еще хорошо со сборкой мусора и анализом строгости - было бы неплохо поработать на этих направлениях. И тут сложно с ними не согласиться.   
+Существенно позднее авторы языка напишут, что он разрабатывался с самого начала проекта в 84-ом году, проектирование первой версии закончилось в 85-ом, первый компилятор был написан в 86-ом [Plas95]. В 87-ом году вышла первая дошедшая до на статья, в которой описывается версия 4.0 компилятора и языка, который определен только своей имплементацией. Версия современного Clean меньше, но это потому, что следующей версией после 4.0 была 0.5. Этот компилятор был первым публичным релизом в том же 87-ом году [Plas01].
+Как и их лондонские коллеги, авторы CLEAN начали с компилятора для VAX-11, но более интересные результаты получили продолжив работу компиляторами для MC68K.   
+(C)LEAN был задуман как промежуточный язык, так что сначала в нем не было `let`, `where`, локальных функций и даже лямбд. Что может выглядеть неожиданно, принимая во внимание то, какими работами Барендрегт более известен.
+Как ни странно, Барендрегт и остальные авторы (C)LEAN считают, что промежуточным языком для имплементаций ФЯ должна быть не лямбда с расширениями, а язык уравнений.  
+Лямбда-исчисление часто представляется как сама собой разумеющаяся вычислительная модель для ФЯ, пишут [Brus87] они, вот только большинство имплементаций основаны не на лямбда-исчислении, а на комбинаторной логике (SKI-интерпретатор Тернера, G-машина, CAM), а для представления функциональных программ используются графы, лишние вычисления в которых предотвращаются разделением подграфов. ПМ очень важен в ФЯ, так что имеет смысл включить его в вычислительную модель.   
+Получается, что если мы хотим вычислительную модель для ФЯ близкую к имплементации, то лямбда-исчисление уже совсем не выглядит очевидным выбором.
+Это авторы (C)LEAN дискутируют с теми, кто имплементировал HOPE на обычном железе и с другим машинистом, будущим важным героем нашей истории. К этому мы еще вернемся.   
+Первоначально планировалось, что компилятор CLEAN станет компилятором LEAN поддержав мутабельность. И может быть даже логические переменные, приблизившись к DACTL.   
+Питер Копман (Pieter Koopman) и др. показали [Brus87], что в Clean можно компилировать SASL, TALE и OBJ2 - новую версию языка алгебраической спецификации OBJ0, о которой мы рассказывали в нулевой части. Главным же достижением должен был стать компилятор нового языка Тернера. Этим планам не суждено было сбыться и к причинам мы еще вернемся в следующей главе с новыми приключениями Тернера. Но и остальные перечисленные компиляторы не стали чем-то большим, чем эксперименты. CLEAN как промежуточный язык не состоялся.   
+Проблема в том, что CLEAN пока что не очень хороший промежуточный язык. Он не поддерживает локальные функции оставляя лямбда-лифтинг разработчикам транслятора в CLEAN. Не поддерживает CAF что важно для ленивых языков. Но хуже всего то, что CLEAN компилируется в медленный код. Код сгенерированный компилятором Lazy ML работает в 7-9 раз быстрее, в зависимости от микробенчмарка.  
+Но авторы компилятора CLEAN не унывают. Они считают, что смогут существенно улучшить производительность кода и собираются сконцентрировать свои усилия на этом. Больше использовать стек, лучше компилировать ПМ, умнее управлять памятью.   
+Важную роль в отставании от LML сыграло то, что первые версии CLEAN хоть и были языком уравнений с самого начала, еще не были полностью HOPE-фицированными.   
+Но CLEAN стал полностью HOPE-фицированным языком до конца 80-х годов. В это время еще не угасла надежда на то, что CLEAN будет промежуточным языком для какого-то компилятора кроме CLEAN, но появилось движение в сторону более-менее полноценного языка, хоть и все еще простого [Gron90]. И CLEAN оброс соответствующими фичами [Nock91].
+
+```
+MODULE Test;
+TYPE
+
+:: List x -> Cons x (List x) |
+   List x -> Nil ;
+
+RULE
+
+:: Map (=> x y) [x] -> [y] ;
+   Map f [] -> [] |
+   Map f [a | b] —> [f a | Map f b] ;
+```
+
+знакомые с современным Clean могут заметить тут пару знакомых синтаксических деталей, но это добавление деталей никогда не сложится в CLEAN похожий на современный. Современный будет сделан более-менее с нуля спустя годы, но это уже другая история.   
+
+### Самый известный птеродактиль на Панталасском театре   
+
+После совместной с голландцами "фундаментальной переработки вычислительной модели" в Университете Восточной Англии разработали новую версию DACTL основанную на LEAN.   
+Спецификация ядра Dactl была готова в марте 87, принята Flagship вскоре после того. Черновик описания новой версии Dactl появился в июне 87-го и готовое описание в декабре 87-го.
+Никаких фундаментальных переработок больше не было, так что последняя версия Dactl не особенно отличалась от второй и была готова в начале января 89-го. Образцовый интерпретатор - вскоре после этого [Glau91].   
+Теперь DACTL выглядел так:
+
+```
+MODULE Test;
+IMPORTS Lists;
+SYMBOL REWRITABLE Append;
+RULE
+    Append[Cons[h t] y] => #Cons[h ^*Append[t y]] |
+    Append[Nil y] => *ForceList[y] ;
+    Append[x y] => #Append[^*x y] ;
+ENDMODULE Test;
+```
+
+`|` - разделитель между уравнениями, порядок которых не важен. И `;` - разделитель между уравнениями, порядок которых важен.  
+Аннотации порядка вычисления теперь показывают зависимость одних промежуточных результатов от других, так что ленивый код требовал меньше аннотаций и даже меньше уравнений:
+
+```
+Append[Cons[h t] y] => *Cons[h Append[t y]] |
+Append[Nil y] => *y ;
+```
+
+Как видите, язык хоть и напоминает (C)LEAN, но не является просто им с дополнительными аннотациями.   
+Dactl разрабатывался итерационно для того, чтоб учитывать опыт его использования и для приобретения этого опыта использования Dactl0 и Dactl1 в Университете Восточной Англии и не только написали несколько трансляторов.
+Промежуточный язык должен был подходить и для трансляции логических языков, так что Джордж Пападопулос (George Papadopoulos) написал трансляторы Parlog [Papa89] и GHC [Glau88] в DACTL. GHC не имеет ничего общего с более известным и релевантным для нашей истории Glasgow Haskell Compiler и в данном случае расшифровывается Guarded Horn Clauses.  
+Компания Harlequin, которая уже упоминалась в нашей истории, ей Радиолокационная Лаборатория заказала компилятор SML, для проекта Flagship писала в 87-ом году Harlequin Flagship Common Lisp Compiler.   
+Более соответствующими теме нашей истории компиляторами были три транслирующих HOPE-фицированные ФЯ в DACTL.
+Один из авторов DACTL в университете Восточной Англии Ричард Кеннвей (Richard Kennaway) написал в 88-ом году транслятор CLEAN. Этот язык в описываемое время был довольно минималистичным и близким к DACTL, так что компилятор вышел не самым сложным. Второй восточно-английский компилятор был существенно сложнее.   
+Новый важный герой нашей истории Кевин Хаммонд (Kevin Hammond) написал транслятор языка PSML. Что означает Parallel Standard ML. Как обычно бывает в этой главе, стандартный ML был не совсем стандартным и относился к SML версии 2 (т.е. образца 88-го года) на основе которого был сделан, примерно так же как первоначальный Lazy ML относился к LCF/ML. PSML - декларативное подмножество Standard ML. Из этого языка убраны все императивные конструкции: циклы, изменяемые ссылки и большинство функций ввода-вывода. Исключения не убраны полностью, а заменены на ошибки-значения, похожие на те что в Hope+ [Hamm89b].   
+PSML компилировался сначала в DACTL0 [Glau87]
+, а потом в в DACTL1, Хаммонд экспериментировал и со строгой и с ленивой версией языка. Хаммонд писал компилятор в рамках работы над диссертацией и защитил её [Hamm91] в ноябре 88-го.   
+Третьим транслятором был уже упомянутый нами лондонский компилятор параллельного HOPE+. Правда, компилировал он не в DACTL, а в его подмножество, поддерживаемое Flagship-машиной. Подмножество называлось MONSTR.   
+Как и трансляторы в CLEAN, эти экспериментальные компиляторы не были важными для нашей истории. DACTL тоже был не особенно удачным промежуточным языком. Идея единого промежуточного языка восторжествовала на этапе планирования, но не выдержала испытаний на этапе имплементации. Вместо единого языка получилось множество. Больше, чем получилось бы, если бы каждый проект спецмашины имел собственный язык с самого начала.
+Существовали только две полных имплементации DACTL: университетский образцовый интерпретатор и транслятор в C под названием ICL IIS, который написали в ICL - компании, строившей прототипы Alice и Flagship.   
+Транслятор в C может для нашей истории быть важнее всех этих спецмашин вместе взятых. Но не этот. На новых рабочих станциях SUN, которые были в 2-3 раза быстрее VAX-11/780 он выдавал только 1000 nfib в секунду. Чуть более чем в два раза быстрее, чем образцовый интерпретатор. И на десятичные порядки медленнее, чем последнее слово техники функционального компиляторостроения.   
+Оба спецмашинных проекта директората Алви нашли способ не использовать DACTL. И если Flagship имплементировал подмножество, только то, что хотел, то другая Алви-машина отказалась от промежуточного языка уравнений с ПМ полностью, выбрав расширенную лямбду. Но это уже другая история.   
+
+### Негативное пространство.
+
+Саймон Пейтон-Джонс (Simon Loftus Peyton Jones) [SPJ18], как и его шведский коллега Августссон, относится к тому поколению имплементаторов ФЯ, которое познакомилась с компьютером еще в школе. В этой же школе учился функциональный машинист из прошлой части Томас Кларк. В результате этого опыта у Кларка и Пейтон-Джонса появилось желание разрабатывать компьютеры. И разработка компьютеров - это не те работы, которыми Пейтон-Джонс известен. Но всему свое время.  
+После школы, в Кембриджском университете Пейтон-Джонс повстречал ещё больше героев нашей истории: Хьюза и Фейрберна.   
+В Кембридже, как и в университете Чалмерса, пока что не было компьютерных наук как специальности. Так что Пейтон-Джонс сначала изучал математику. Но математика показалась ему слишком сложной, поэтому он стал изучать электротехнику. Компьютерные науки, впрочем, успели появится достаточно рано чтоб Пейтон-Джонс получил и такую специальность за один 79-80 год.  
+На то, что Пейтон-Джонс заинтересовался не просто разработкой компьютеров, а именно специальных ФП-машин, повлияли уже упоминавшиеся нами преподаватель Артур Норман от которого Пейтон-Джонс впервые узнал о функциональном программировании, Тьюринговская лекция Бэкуса и, разумеется, статья Тернера.  
+Как и на его шведских коллег, на Саймона Пейтон-Джонса произвела впечатление статья Тернера про комбинаторный интерпретатор. Дипломная работа Пейтон-Джонса была сравнением комбинаторного интерпретатора с SECD. Сам СПЖ считает ее не особенно полезной потому, что из сравнения наивных интерпретаторов не стоит делать далеко идущих выводов. На основе этого диплома была написана уже упомянутая нами в прошлых частях статья.   
+Пейтон-Джонс не хотел работать над докторской диссертацией, он хотел работать в индустрии. Об этом он вскоре пожалел - работа в индустрии ему не особенно понравилась, и через два года он вернулся в академию.   
+В 82-ом Пейтон-Джонс стал читать лекции в Университетском колледже Лондона (University College London). Но для того чтоб преподавать надо же защитить диссертацию? Не в те времена. Внезапно оказалось, что нужно учить компьютерным наукам много-много студентов, а преподавателей не хватает. Так что Пейтон-Джонс мог работать, а диссертацию защитить когда-нибудь потом.   
+Для того чтоб освоить исследовательскую работу, Пейтон-Джонс написал уже упомянутую нами статью про написание Yacc на SASL. Пока работал над ней, он общался с Тернером и даже называет Тернера своим неформальным научным руководителем.   
+В апреле 83-го Саймон Пейтон-Джонс организовал [SERC83] коллоквиум по декларативному программированию в Университетском колледже Лондона. Там Йонссон впервые выступил с докладом о G-машине, о том как быстро можно редуцировать графы, а избегать их редукции - еще быстрее.   
+И именно этим Пейтон Джон со своими коллегами Клеком (Christopher D. Clack), Салкилдом (Jon Salkild) и Харди (Mark S. Hardie) и стали заниматься, когда Университетский колледж Лондона начал второй по величине проект директората Алви по созданию ФП-машины. Проект назвали GRIP (Graph Reduction In Parallel). Индустриальными партнёрами были все та же ICL и High Level Hardware Limited.
+На второй по величине проект выделили в десятки раз меньше денег, чем на первый - всего 480 тыс. фунтов (два с половиной миллиона долларов в 2025) [Blac85], так что подходы исполнителей проектов просто обязаны были существенно отличаться.   
+Но GRIP-машина отвечала на проблемы ALICE с производительностью схожим с Flagship образом. Правда, хватало и различий [SPJ88a].   
+В GRIP осталось разделение на вычислительные элементы и элементы разделяемой памяти. Вычислительные элементы PE (Processing Element) - настолько обычные компьютеры, насколько это возможно. С новыми процессорами Motorola 68020 и большой локальной памятью, недоступной остальным процессорам компьютера. Сначала 128Кб но планировалось увеличение до 512Кб [SPJ87a] а затем и 1Мб [SPJ88a]. Обычные компьютеры умеют делать очень хорошо и дешево, и с каждым годом все лучше и дешевле, очень важно воспользоваться этими возможностями.   
+И что более важно для нашей истории, схожесть вычислительного элемента с обычной рабочей станцией означает, что участники проекта GRIP разрабатывали способы имплементации ФЯ применимые на обычной рабочей станции.   
+Но где же тогда специальное в этой спец-машине? Специальным микропрограммируемым железом являются только блоки разделяемой между процессорами памяти IMU (Intelligent Memory Unit). Эти микропрограммируемые компьютеры, оптимизированные для перемещения данных и операций с указателями, собирали мусор и предоставляли доступ к разделяемой памяти не как к массиву слов, а к операциям над графами и их элементами.   
+Авторы считают основным недостатком то, что работа с памятью и особенно кэшами в обычных компьютерах лучше и быстро совершенствуется. Специальный компьютер блока памяти не может полноценно использовать эти успехи. Авторам не очевидно, что специальность компьютера сможет компенсировать это отставание.   
+Эта организация памяти еще больше мотивирует минимизацию изменений графа. Переписыватель графа, чтоб быть эфективным переписывателем, переписывает только в том случае, если без переписывания будет потеряно разделение. Это мотивировало работу разработчиков GRIP над усовершенствованием способов компиляции ФЯ.  
+В блоке разделяемой памяти до 4 миллионов 40-битных слов.   
+Для соединения блоков используется уже существующая обычная шина, в отличии от прочих разработчиков спецмашин, разработчики GRIP не собирались связываться и с этим.   
+Но к существующим шинам не подключить много блоков, так что структура становится двухуровневой. 4 вычислительных блока и один блок разделяемой памяти объединяются на одной плате, которых может быть до 20. К блоку разделяемой памяти такой платы есть доступ и с других плат, но более медленный.  
+Так что на втором уровне блоки все-таки объединяются как во Flagship, но в каждом больше процессоров у каждого из которых больше собственной памяти.    
+Первый прототип с одной группой блоков планировали построить в середине 87-го, а с несколькими группами - в конце лета того же года [SPJ87a]. Не позднее 88-го первый прототип, смонтированный накруткой, был готов. Новый прототип с печатными платами ожидался в середине 88-го.   
+ФЯ имплементировались на этих вычислительных блоках с помощью суперкомбинаторов. Первоначальная имплементация была наивной, но не позднее 87-го года для этого использовали наработки Йонссона - G-машину [SPJ87a]. И это не последняя наработка Йонссона, которую использовали в GRIP.   
+До 87-го года разработчики GRIP собирались имплементировать DACTL. И использовать компиляторы в DACTL, написанные остальными Алви-проектами [SPJ87a].   
+Но оказалось, что DACTL не так легко имплементировать. Никто не сделал полноценной имплементации. Даже Flagship, и этот проект намного богаче GRIP. Нужно было что-то менее амбициозное. Этим неамбициозным чем-то стал FLIC (Functional Language Intermediate Code) [SPJ88b].  
+Над этим промежуточным языком работали еще и в Университете Уорика (University of Warwick), и FLIC - один из ранних примеров языка, который разрабатывали обсуждая в электронной почтовой рассылке. Но в университете Уорика наработали не много полезного.   
+Авторы пишут, что общий промежуточный язык может быть решением проблемы большого числа функциональных языков. Таким решением, которое не заставляет их унифицировать и позволяет им сохранить их сильные стороны.   
+Ирония в том, что средство спасения от необходимости заменять многообразие функциональных языков на один универсальный язык придумывал разработчик языков, более известный своей работой над универсальным языком для замены многообразия ФЯ.   
+Похоже, что авторы хотели подтолкнуть образование экосистемы вокруг FLIC. Вроде той, что тогда же пытались построить вокруг DACTL. По крайней мере для функциональных языков. В Лондоне не собирались поддерживать на GRIP ничего кроме функциональных языков, но другая группа исследователей в университете Эссекса работала над или-параллельным Прологом для этой машины.  
+Для них легкой жизни не обещали, но авторы пишут, что ФЯ транслировать во FLIC просто! Но никто не успел написать практичный транслятор ФЯ во FLIC за них.   
+И это было проблемой. Flagship мог себе позволить разработку двух компиляторов, но GRIP не может себе позволить даже одного. По крайней мере, пока не может.   
+Но если написание собственного компилятора требует слишком много усилий, то изменение существующего компилятора может быть вполне по силам.   
+Пейтон-Джонс и др. использовали язык и компилятор Lazy ML Августссона и Йонссона. Так что этот проект тоже получился международным. Но если в случае CLEAN/Dactl все закончилось международными согласованиями, после которых все делали что-то свое, то GRIP просто использовал то, что уже было сделано в Швеции. Согласования были позже, но это уже другая история.   
+Авторы пишут что использовали компилятор LML потому, что имели доступ к его коду. И выбор в это время был по видимому сильно ограничен. Особенно для тех кому нужен чисто функциональный язык и для ценителей работ Тернера.   
+Для компилятора LML написали бэкенд, транслирующий во FLIC. И легкость трансляции из промежуточного кода компилятора LML должна была сыграть важную роль в определении того, как FLIC выглядел. Функциональные языки - обычно лямбда с расширениями, пишут его авторы, так что все их можно компилировать в лямбду с несколько меньшим числом расширений.   
+Ну, допустим, что в это время ФЯ - уже обычно уравнения с паттерн матчингом, тут правы скорее авторы CLEAN. Но вот промежуточные языки у реально существующих и более-менее зрелых имплементаций все ещё лямбда с не особенно большим числом расширений. И FLIC - язык идейно родственный промежуточным языкам IF1 Манчестерской dataflow-машины и FP/M Лондонского компилятора HOPE+ для обычных машин. Но немного более универсальный и высокоуровневый.  
+Но главное то, что промежуточный язык компилятора Lazy ML - это сам Lazy ML. Но не Lazy ML второй половины 80-х, большой HOPE-фицированный язык уравнений с ПМ, а его минимальное подмножество - лямбда с расширениями.   
+Имплементации ПМ в компиляторах уже есть, разработчику спец-машины можно не имплементировать все возможные его версии, которых в то время было больше, чем сегодня.   
+Ирония в том, что это восстание против языков уравнений произошло потому, что разработчик компиляторов, который более известен имплементацией большого и сложного языка уравнений, не хотел имплементировать не такой большой и менее сложный язык уравнений.   
+Хотел или не хотел, правда, не так важно как то, что не мог. Альтернативное настоящее в котором роль Core в сегодняшнем GHC играет совсем не сегодняшний CLEAN было возможно, но такой исход не был особенно вероятным.   
+Важно, правда, отменить, что FLIC - это не Core. Да, FLIC - лямбда-исчисление с расширениями. Язык ленивый по умолчанию, но с помощью аннотаций можно писать энергичный код. Функции каррированы по умолчанию, способа объявлять некаррированные функции многих параметров нет. Но FLIC должен быть машиночитаемым. Хотя код на FLIC должен быть корректно типизирован, аннотация типов не требуется, а их проверка не производится. Компилирующий во FLIC компилятор может сохранить информацию о проверенных им типах только в аннотациях как метаданные.   
+Во FLIC нет АлгТД и даже одноуровневого ПМ. Есть только структуры с полями и тегом и функции для их разбора. Такой код на языке уравнений
+
+```
+f (LEAF x) = g x
+f (NODE t1 t2) = h t1 t2
+```
+
+нужно транслировать в такой FLIC
+
+```
+= (f) (\x CASE 2
+            (UNPACK 1 g x)
+            (UNPACK 2 h x) x)
+```
+
+Во FLIC есть развитая система аннотаций. Авторы GRIP - энтузиасты аннотаций, которые не изменяют результата исполнения кода, но помогают сделать его быстрее. Пионером такого подхода был Уоррен, но в ФЯ он не стал распространенным до спецмашинных Алви-проектов.   
+Существенное преимущество ФЯ в том, пишут авторы GRIP, что параллелизм в них неявный и аннотации вообще говоря не требуются. Разработчики GRIP написали для компилятора обнаружение таких возможностей для параллелизма с помощью анализа строгости. Но они все равно имплементировали такие аннотации и пользовались ими. Аннотации заметно влияли на производительность.   
+Но аннотации для LML, похоже, серьезно отставали от аннотаций для FLIC. Так один из пользователей модифицированного компилятора пишет [Trin89] как он транслировал LML во FLIC и расставлял аннотации строгости и параллелизма уже только в сгенерированном FLIC-коде.   
+На этом закончена история о том, как Саймон Пейтон-Джонс успешно избегал работы над тем, чем он как раз известен. Пока, наконец, не перестал избегать. Но это уже другая история.   
+
+### День зависимости
+
+Ответом правительства США на японский вызов была DARPA Strategic Computing Initiative [Stef85]. Десятилетий план, анонсированный осенью 83-го. 300 миллионов долларов ($976 миллионов 2025) на первые три года.
+Это был обычный ответ. Но был ещё и ответ необычный. Необычным американским ответом на японский вызов было создание MCC (Microelectronics and Computer Technology Corporation) [Peck86]. Этот, в отличие от японского проекта машины пятого поколения и Алви - полностью частный. Да, 21 коммерческая компании вроде Motorola и AMD и, почему-то, Локхид и Боинг, готовы были не получать деньги на ответы японцам, а даже тратить свои. От государства требовалось пока что только разрешить создавать такие консорциумы, запрещённые в то время антимонопольным законодательством. Что было сделано в 84-ом.   
+Японская инициатива была, правда, только одной из угроз. Другой была IBM. 21 компания хотели совместно создать что-то вроде Белл Лабс AT&T или Йорктаун Хайтс IBM, про которую мы не раз писали в нулевой части. На свой ответ они планировали тратить сопоставимые средства - 80 миллионов долларов (237 миллионов в 2025) в год к концу десятилетия.   
+Лаборатории MCC расположились в Остине, где как раз в это время закрыли ARC, про который мы писали в прошлой части. Готовность отвечать Японии ARC не помогла, но отдельные исследователи перебежали оттуда в MCC.   
+Масштабы ответа впечатляют, но они не конвертируются в серьёзный вклад в нашу историю. Ответ японцам, как обычно, означал - делать больше того, что и так уже делали. И мало кто делал что-то связанное с Эдинбургской программой. А те, кто делали - делали не особенно самобытные вещи. Которые ещё и потеряли самобытность в ходе HOPE-фикации.   
+Посмотрим, например, на организованную MCC конференцию по редукции графов, прошедшую осенью 86-го [Fase87].   
+Организаторами были наш старый знакомый по предыдущей части Келлер и новый герой нашей истории Джозеф Фазель (Joseph H. Fasel) из Лос-Аламосской национальной лаборатории (Los Alamos National Laboratory).    
+Доклады работавшего над Ponder Фейрберна, Йонссона про Lazy ML и Худака с коллегами - про имплементации ФЯ для обычных машин и не относятся к теме этой главы.   
+Доклад героя нулевой главы Гогена про очередную версию его языка алгебраической спецификации, глава про который и прочие родственные Эдинбургским ФЯ направления ещё впереди.  
+Среди докладчиков преобладают европейцы: разработчики ALICE и Манчестерской Dataflow машины. Французской специальной машины MaRS и представители Голландского проекта.   
+Американские докладчики релевантные для этой главы и нашей истории в целом это уже знакомые нам разработчики FEL Келлер с коллегами, разработчики Id Арвинд с коллегами и новый герой Кибурц (Richard B. Kieburtz).
+Кибурц работал в Орегоне над моделированием аппаратной G-машины [Kieb86] [Kieb87]. Кибурц, как и Пейтон-Джонс, использовал модифицированный компилятор Lazy ML Йонссона и Августссона.   
+Как и другие разработчики (стимуляторов) специального железа, Кибурц и др. использовали два симулятора - более детальный и медленный Microsim, пригодный только для исполнения программ в десятки команд и относительно быстрый инструментированный интерпретатор Macrosim. Macrosim написан Бориславом Агапиевым (Borislav Agapiev) на Modula-II и работал "примерно так же быстро, как интерпретатор Лиспа". Раман Теннети (Raman Tenneti) написал компилятор кодов виртуальной машины для VAX-11. Не позднее 86-го.  
+Как и разработчики транслятора PSML в DACTL, Кибурц экспериментировал с ленивостью и тестировал и строгие и ленивые версии. Мы уже видели ленивый "Standard" ML и вот, смотрите: энергичный "Lazy" ML. Обе имплементации, конечно, были не особенно серьёзными, даже по меркам этой истории.   
+Другие разработчики симуляторов машин Келлер с коллегами работали в 84-ом году над типизированной версией их языка FEL под названием TFEL [Mish85] [Mish84]. Конечная версия HOPE-фикации должна была стать, по видимому, самой буквальной HOPE-фикацией из всех, псевдокод в статье [Mish84] "похожий на TFEL" выглядел как HOPE без `<=` и с применениями функций как в FEL и FP:
+
+```
+data integer = zero + + succ[integer]
+
+dec even: integer -> bool
+--- even:zero = true
+--- even:succ[zero] = false
+--- even:succ[succ[x]] = even:x
+```
+
+К сожалению, для реконструкции нашего обычного примера недостаточно информации.
+HOPE-фикация FEL, правда, не состоялась. В 85-ом году вместо этого заменили FEL на его версию с Лисп-синтаксисом и безо всяких групп уравнений, ПМ и АлгТД под названием RediLisp [Kelle85] [Kelle87].   
+Но не все разработчики специальных ФП-машин остались разработчиками симуляторов. Группа Арвинда в МТИ занялась созданием реального компьютера Monsoon, первый прототип которого должен был быть готов в конце лета 88. Но немного задержался.   
+Прототип, смонтированный накруткой, заработал в сентябре 88-го. В декабре он уже исполнял скомпилированные программы на Id. В том же 88-ом Motorola стала индустриальным партнёром МТИ по разработке Monsoon [LCS89].   
+Тем временем Нихил HOPE-фицировал Id. Эта HOPE-фикация - одна из самых поздних. Описание [Nikh88] нового Id 88.0 было готово в марте 88-го.   
+Теперь функциональное подмножество Id, пишет Нихил, сравнимо с современными ФЯ. В Id теперь есть параметрический полиморфизм, определяемые пользователем алгебраические типы данных и паттерн-матчинг для их конструкторов, абстрактные типы данных и лист-компрехеншоны.   
+В LCF/ML было три основных способа и стиля именования параметров типов. Их можно было именовать например `*` и `**`, `*a` и `*b`, `*1` и `*2`. В последующих языках с параметрическим полиморфизмом обычно ограничивались каким-то одним. В Lazy ML, SML и CAML оставили второй способ (заменив позднее `*` на `'` в некоторых из них). В Id выбрали третий способ [Nikh88].   
+
+```
+type list *0 = nil | (:) *0 (list *0)
+
+typedef map = (*0 -> *1) -> (list *0) -> (list *1)
+
+def map f nil    = nil
+|   map f (x:xs) = f x : map f xs
+
+map = { fun f nil    = nil
+      |     f (x:xs) = f x : map f xs }
+
+def map f l = { case l of
+                  nil    = nil
+              |   (x:xs) = f x : map f xs }    
+
+def map f l = {: f x || x <- l }
+
+{ y = 1
+  In
+  map { fun x = x + y } (1: (2: (3: nil))) }
+```
+
+Как видите, авторы Id не стали себя ограничивать и позаимствовали большинство способов разбора АлгТД. Есть и группы уравнений и `case`-выражения и лямбды, которые одновременно поддерживают и несколько веток и карринг, как в CAML и новом GHC Haskell. `:` после открывающей скобки компрехеншона тут означает, что создается список, эта нотация работает и для массивов.   
+Поддержку Id 88 добавил в компилятор весной 88-го Джеймс Хикс (James Hicks) [Nikh88b]. ПМ компилировался методом, описанным Вадлером с некоторыми изменениями. Первоначально язык был имплементирован не полностью, не поддерживались проверка типов для всех нововведений и объявления констант на топлевеле, можно было писать только функции с параметрами. Полная имплементация ожидалась к концу лета 88-го.
+И по крайней мере проверка типов была имплементирована полностью к осени Шаилом Адитьей (Shail Aditya).   
+В 88-ом компилятор модифицировали чтоб генерировать код для Monsoon и решили, что неплохо было бы генерировать его и для обычных машин. Трауб работал над техниками имплементации нестрогих но не ленивых языков на обычных машинах. И в 89-ом году Лина Мурьянто (Lina Muryanto) и Питер Тан (Peter Tan) написали кодогенератор для MC68020, но пока только для подмножества языка [LCS89].   
+На этом очередная глава про специальные ФП-компьютеры подходит к концу. Возможно, вклад героев этой главы в историю функционального программирования пока что не выглядит впечатляющим. Но основной их вклад в дело HOPE-фикации еще впереди. Это, впрочем, уже другая история.   
+
 ПРОДОЛЖЕНИЕ СЛЕДУЕТ
 
 Литература
 ==========
 
+[Nikh88b]: R.S. Nikhil. Computation Structures Group Progress Report 1987-88. Memo-288, 1988, June   
+[Nikh88]: Nikhil, R.S. Id (Version 88.0) Reference Manual. Computation Structures Group Memo 284. MIT Laboratory for Computer Science, Cambridge, MA March 1988   
+[LCS89]: MIT Laboratory for Computer Science Progress Report 26, Jul 1988 - Jun 1989 https://apps.dtic.mil/sti/tr/pdf/ADA228606.pdf    
+[Kelle85]: Keller, Robert M. "Rediflow architecture prospectus." In TR UUCS-85-105. Dept of Computer Science, University of Utah USA, 1985 Aug.   
+[Kelle87]: Keller, R.M., Slater, J.W., Likes, K.T. (1987). Overview of Rediflow II development. In: Fasel, J.H., Keller, R.M. (eds) Graph Reduction. GR 1986. Lecture Notes in Computer Science, vol 279. Springer, Berlin, Heidelberg. doi:10.1007/3-540-18420-1_56   
+[Mish84]: Prateek Mishra and Robert M. Keller. 1984. Static inference of properties of applicative programs. In Proceedings of the 11th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '84). Association for Computing Machinery, New York, NY, USA, 235–244. doi:10.1145/800017.800535
+[Mish85]: Prateek Mishra and Uday S. Reddy. 1985. Declaration-free type checking. In Proceedings of the 12th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '85). Association for Computing Machinery, New York, NY, USA, 7–21. doi:10.1145/318593.318603   
+[Kieb86]: Richard B. Kieburtz. 1986. Performance measurement of a G-machine implementation. In Proceedings of the Workshop on Graph Reduction. Springer-Verlag, Berlin, Heidelberg, 275–296.   
+[Kieb87]: Rchard B. Kieburtz. 1987. A RISC architecture for symbolic computation. In Proceedings of the second international conference on Architectual support for programming languages and operating systems (ASPLOS II). Association for Computing Machinery, New York, NY, USA, 146–155. doi:10.1145/36206.36197   
+[Fase87]: Fasel, Joseph H. Graph Reduction: Proceedings of a Workshop Santa Fe, New Mexico, USA, September 29-October 1, 1986. Vol. 279. Springer Science & Business Media, 1987.   
+[Peck86]: Merton J. Peck, Joint R&D: The case of microelectronics and computer technology corporation, Research Policy, Volume 15, Issue 5, 1986, Pages 219-231, ISSN 0048-7333, doi:10.1016/0048-7333(86)90023-5.   
+[Stef85]: Mark Stefik. 1985. Strategic computing at DARPA: overview and assessment. Commun. ACM 28, 7 (July 1985), 690–704. doi:10.1145/3894.3896   
+[SPJ88a]: Peyton Jones, Clack, Salkild and Hardie, Functional Programming on the GRIP multiprocessor. in Proceedings IEE International Specialist Seminar on Design and Application of Parallel Digital Processors, pp 116-127. 1988   
+[SPJ18]: People of Programming Languages. An interview project in conjunction with POPL 2018. Interview with Simon Peyton-Jones http://www.cs.cmu.edu/~popl-interviews/peytonjones.html  
+[SPJ87a]: Peyton Jones, Clack, Salkild and Hardie, GRIP - a high performance architecture for parallel graph reduction, LNCS 274:98-112, ISSN 0302-9743, Springer 1987.  
+[SPJ88b]: S. L. Peyton Jones. 1988. FLIC—a functional language intermediate code. SIGPLAN Not. 23, 8 (August 1988), 30–48. doi:10.1145/47907.47910   
+[Trin89]: Phil Trinder, A FUNCTIONAL DATABASE, PRG82, 1989.   
+[Bare87]: Barendregt, H.P., M.C.J.D. van Eekelen, P.H. Hartel, L.O. Hertzberger, M.J. Plasmeijer and W.G. Vree. The Dutch Parallel Reduction Machine Project, In Future Generations Computer Systems 3, pp. 261-270. Proceedings of the International Conference on Frontiers of Computing (Amsterdam, December 1987).   
+[Brus87]: Brus, T., M.C.J.D. van Eekelen, M. van Leer, M.J. Plasmeijer and H.P. Barendregt. CLEAN - A Language for Functional Graph Rewriting, In Proc. of Conference on Functional Programming Languages and Computer Architecture (FPCA '87), Portland, Oregon, USA, Kahn Ed., Springer-Verlag, LNCS 274, pp. 364-384.   
+[Nock91]: Nöcker, E.G.J.M.H., J.E.W. Smetsers, M.C.J.D. van Eekelen and M.J. Plasmeijer. Concurrent CLEAN, In Proc. of Parallel Architectures and Languages Europe (PARLE '91), Eindhoven, the Netherlands, Aarts, Leeuwen and Rem Eds., Springer-Verlag, LNCS 505, pp. 202-219.   
+[Plas01]: Rinus Plasmeijer, Marko van Eekelen, CLEAN LANGUAGE REPORT version 1.3.1 September 2001   
+[Plas96]: Rinus Plasmeijer, Marko van Eekelen, Clean Language Report - Version 1.1 - March 1996   
+[Gron90]: Groningen J.H.G. van. (1990), ‘Implementing the ABC-machine on M680x0 based architectures'. Master Thesis, University of Nijmegen, November 1990.   
+[Hamm91]: Hammond, Kevin. "Parallel SML: a Functional Language and its Implementation in DACTL." (1991).   
+[Glau2]: John Glauert: Research Background https://web.archive.org/web/20041207045351/http://www2.cmp.uea.ac.uk/~jrwg/MultiPar/resbg.html   
+[Glau1]: John Glauert, Personal profile. https://research-portal.uea.ac.uk/en/persons/john-glauert   
+[Hamm89b]: Hammond, Kevin. "Exception handling in a parallel functional language: PSML." In Fourth IEEE Region 10 International Conference TENCON, pp. 169-173. IEEE, 1989.
+[Glau87]: Glauert, J. R. W., J. R. Kennaway, and M. R. Sleep. "DACTL: A computational model and compiler target language based on graph reduction." ICL Technical Journal 5, no. 3 (1987): 509-537.   
+[Papa89]: Papadopoulos, G.A. (1989). A fine grain parallel implementation of PARLOG. In: Díaz, J., Orejas, F. (eds) TAPSOFT '89. TAPSOFT 1989. Lecture Notes in Computer Science, vol 352. Springer, Berlin, Heidelberg. doi:10.1007/3-540-50940-2_44   
+[Glau88]: John R. W. Glauert, George A. Papadopoulos: A Parallel Implementation of GHC. FGCS 1988: 1051-1058   
+[Glau91]: Glauert, J.R.W., Kennaway, J.R., Sleep, M.R. (1991). Dactl: An experimental graph rewriting language. In: Ehrig, H., Kreowski, HJ., Rozenberg, G. (eds) Graph Grammars and Their Application to Computer Science. Graph Grammars 1990. Lecture Notes in Computer Science, vol 532. Springer, Berlin, Heidelberg. doi:10.1007/BFb0017401   
+[Bare86]: H P Barendregt and M van Leeuwen. 1986. Functional programming and the language TALE. Current trends in concurrency. Overviews and tutorials. Springer-Verlag, Berlin, Heidelberg, 122–207.   
+[Darl87]: Darlington, J. (1987) Software development using functional programming languages. ICL Technical J., 5 (3): 492-508   
+[Glyn90]: Kewley, John M., and Kevin Glynn. "Evaluation annotations for Hope+." In Functional Programming: Proceedings of the 1989 Glasgow Workshop 21–23 August 1989, Fraserburgh, Scotland, pp. 329-337. London: Springer London, 1990. doi:10.1007/978-1-4471-3166-3_22   
+[Robe89]: Robertson, I.B., Way, Wenlock. "Hope+ on Flagship." In Functional Programming: Proceedings of the 1989 Glasgow Workshop, 21-23 August 1989, Fraserburgh, Scotland, p. 296. Springer, 1990. doi:10.1007/978-1-4471-3166-3_20   
+[Darl89]: Darlington, J. et al. (1989). A Functional Programming environment supporting execution, partial execution and transformation. In: Odijk, E., Rem, M., Syre, JC. (eds) PARLE '89 Parallel Architectures and Languages Europe. PARLE 1989. Lecture Notes in Computer Science, vol 365. Springer, Berlin, Heidelberg. doi:10.1007/3540512845_46   
+[Perr91]: Perry, Nigel. "The implementation of practical functional programming languages." PhD diss., Department of Computing, Imperial College, 1991.   
+[Fiel88]: Field, Antony and Peter G. Harrison. “Functional Programming.” (1988).   
+[Kean94]: Keane, John A. "An overview of the Flagship system." Journal of Functional Programming 4, no. 1 (1994): 19-45.   
 [Acce86]: Accetta, Mike, Robert Baron, William Bolosky, David Golub, Richard Rashid, Avadis Tevanian, and Michael Young. "Mach: A new kernel foundation for UNIX development." (1986): 93-112.   
 [Alle78]: John Allen. 1978. Anatomy of LISP. McGraw-Hill, Inc., USA.   
 [Alle2005]: John Allen. History, Mystery, and Ballast https://international-lisp-conference.org/2005/media/allen-slides.pdf https://international-lisp-conference.org/2005/media/allen-audio.mp3   
@@ -1074,6 +1549,7 @@ Franz существовала на совсем другом уровне. Дж
 [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   
 [Augu85]: Augustsson, L. (1985). Compiling pattern matching. 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_48   
 [Berr90]: Dave Berry, COMP.LANG.ML Frequently Asked Questions and Answers 19 Apr 1990   
+[Blac85]: Blackburn,J. F. The Alvey Conference in Edinburgh: A Review of the United Kingdom's Research Program in Computer Science. 1985 Aug 22 https://apps.dtic.mil/sti/tr/pdf/ADA158963.pdf   
 [Boye92]: Robert S. Boyer. Frequently Asked Questions about KCL and AKCL. https://web.cecs.pdx.edu/~mperkows/=LISP/kcl   
 [Burs80]: R. M. Burstall, D. B. MacQueen, and D. T. Sannella. 1980. HOPE: An experimental applicative language. In Proceedings of the 1980 ACM conference on LISP and functional programming (LFP '80). Association for Computing Machinery, New York, NY, USA, 136–143. DOI:10.1145/800087.802799   
 [Caml261]: CAML V2-6.1   
@@ -1089,6 +1565,7 @@ Franz существовала на совсем другом уровне. Дж
 [Card85]: Antonio Albano, Luca Cardelli, and Renzo Orsini. Galileo: a strongly typed, interactive, conceptual language. ACM Transactions on Database Systems (TODS), 10(2):230-260, 1985.   
 [Card86]: Luca Cardelli. Amber. In Guy Cousineau, Pierre-Louis Curien, and Bernard Robinet, editors, Combinators and Functional Programming Languages, Lecture Notes in Computer Science, Vol. 242, pp 21-70. Springer-Verlag, 1986.   
 [Card86b]: Luca Cardelli. The amber machine. In Guy Cousineau, Pierre-Louis Curien, and Bernard Robinet, editors, Combinators and Functional Programming Languages, Lecture Notes in Computer Science, Vol. 242, pp 21-70. Springer-Verlag, 1986.   
+[Clac24]: Christopher D. Clack. Research https://christopherclack.com/research/research-topics   
 [Clar81]: Keith L. Clark and Steve Gregory. 1981. A relational language for parallel programming. In Proceedings of the 1981 conference on Functional programming languages and computer architecture (FPCA '81). Association for Computing Machinery, New York, NY, USA, 171–178. doi:10.1145/800223.806776   
 [CMUCL]: CMUCL: Project history & who's who (2020) https://cmucl.org/credits.html   
 [Cous87]: Cousineau, Guy, P-L. Curien, and Michel Mauny. "The categorical abstract machine." Science of computer programming 8, no. 2 (1987): 173-202.   
@@ -1097,17 +1574,21 @@ Franz существовала на совсем другом уровне. Дж
 [Darl76]: Darlington, J., & Burstall, R. M. (1976). A system which automatically improves programs. Acta Informatica, 6(1). doi:10.1007/bf00263742    
 [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   
 [Darl82]: Darlington J, Henderson P, Turner DA, editors. Functional programming and its applications: an advanced course. CUP Archive; 1982 Feb 18.   
+[Dett86]: Dettmer, Roger. “Flagship. A fifth-generation machine.” Electronics and Power 32 (1986): 203-208.   
 [Dijk81] Dijkstra, E. (1981). Trip report E.W. Dijkstra, Newcastle, 19-25
 July 1981. Dijkstra working note EWD798. https://www.cs.utexas.edu/~EWD/transcriptions/EWD07xx/EWD798.html   
 [Duce86]: D. A. Duce, Software Engineering Research at RAL, 13 February 1986 https://www.chilton-computing.org.uk/inf/pdfs/seg/seg101.pdf   
 [Fate2003]: Souza, Paulo Ney de, Richard J. Fateman, Joel Moses and Clifford W Yapp. “The Maxima Book.” (2003). https://maxima.sourceforge.io/docs/maximabook/maximabook-19-Sept-2004.pdf   
 [Faul84]: Faulkner, T. L., & Pavelin, C. J. (1984). Atlas 10 computer. ICL technical journal, 4, 13-32.   
+[Feig83]: Feigenbaum, Edward A.; McCorduck, Pamela (1983). The fifth generation: artificial intelligence and Japan's computer challenge to the world. Reading, Mass: Addison-Wesley. ISBN 978-0-201-11519-2.   
+[Fiel88]: Anthony J. Field, Peter Harrison - Functional Programming, 1988   
 [Franz]: History of Franz Inc. https://franz.com/about/company.history.lhtml   
 [GEC63]: GEC Series 63 https://www.chilton-computing.org.uk/inf/alvey/p003.htm   
 [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).   
 [Gutt81]: John Guttag, James Horning, and John Williams. 1981. FP with data abstraction and strong typing. In Proceedings of the 1981 conference on Functional programming languages and computer architecture (FPCA '81). Association for Computing Machinery, New York, NY, USA, 11–24. doi:10.1145/800223.806758   
 [Harp85]: Robert Harper, Report on the Standard ML Meeting, Edinburgh, May 23-25, 1985. https://smlfamily.github.io/history/Harper-SML-meeting-1985_05.pdf   
+[Harr87]: Harrison, P.G., Reeve, M.J. (1987). The parallel graph reduction machine, ALICE. In: Fasel, J.H., Keller, R.M. (eds) Graph Reduction. GR 1986. Lecture Notes in Computer Science, vol 279. Springer, Berlin, Heidelberg. doi:10.1007/3-540-18420-1_55   
 [Hend80]: Henderson, Peter B.. “Functional programming - application and implementation.” Prentice Hall International Series in Computer Science (1980).   
 [Hoar72]: Hoare, Charles Antony Richard. "Chapter II: Notes on data structuring." In Structured programming, pp. 83-174. 1972.   
 [Hoar75]: Hoare, C.A.R. Recursive data structures. International Journal of Computer and Information Sciences 4, 105–132 (1975). doi:10.1007/BF00976239   
@@ -1119,6 +1600,7 @@ July 1981. Dijkstra working note EWD798. https://www.cs.utexas.edu/~EWD/transcri
 [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   
 [John86]: Johnsson, T. (1987). Target code generation from G-machine code. In: Fasel, J.H., Keller, R.M. (eds) Graph Reduction. GR 1986. Lecture Notes in Computer Science, vol 279. Springer, Berlin, Heidelberg. doi:10.1007/3-540-18420-1_53   
 [John87]: Johnsson, Thomas. "Compiling Lazy Functional Language." PhD Thesis, Chalmers University of Technology (1987).   
+[Kean94]: Keane J. A. An overview of the Flagship system. Journal of Functional Programming. 1994;4(1):19-45. doi:10.1017/S0956796800000927   
 [Kess86]: R. R. Kessler, J. C. Peterson, H. Carr, G. P. Duggan, and J. Knell. 1986. EPIC - a retargetable, highly optimizing Lisp compiler. In Proceedings of the 1986 SIGPLAN symposium on Compiler construction (SIGPLAN '86). Association for Computing Machinery, New York, NY, USA, 118–130. doi:10.1145/12276.13323   
 [MacL15]: Rob MacLachlan, History of the CMUCL Project (2015) https://www.cons.org/cmucl/doc/cmucl-history.html   
 [MacQ85]: David MacQueen and Robin Milner. 1985. Record of the Standard ML Meeting, Edinburgh, 6–8 June 1984. Polymorphism: The ML/LCF/Hope Newsletter II, 1 (Jan.), 16. http://lucacardelli.name/Papers/Polymorphism%20Vol%20II,%20No%201.pdf   
@@ -1151,9 +1633,12 @@ July 1981. Dijkstra working note EWD798. https://www.cs.utexas.edu/~EWD/transcri
 [Muss81]: D. Kapur, D. R. Musser, and A. A. Stepanov. 1981. Operators and algebraic structures. In Proceedings of the 1981 conference on Functional programming languages and computer architecture (FPCA '81). Association for Computing Machinery, New York, NY, USA, 59–64. doi:10.1145/800223.806763   
 [Neum90]: Pierre-Louis Neumann, New Caml version in comp.lang.misc, 03/29/90   
 [Nuprl94]: Nuprl 3.2 (26-MAY-94) https://github.com/owo-lang/nuprl-3 https://web.archive.org/web/20220630143027/http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/reasonng/atp/systems/nuprl/0.html   
+[Odag97]: Odagiri, H., Nakamura, Y., & Shibuya, M. (1997). Research consortia as a vehicle for basic research: The case of a fifth generation computer project in Japan. Research Policy, 26(2), 191–207. doi:10.1016/s0048-7333(97)00008-5   
+[Oakl90]: Brian Oakley and Kenneth Owen. 1990. Alvey: Britain's strategic computing initiative. MIT Press, Cambridge, MA, USA.   
 [Paul96]: Paulson, Lawrence Charles. “ML for the working programmer (2. ed.).” (1996).   
 [Paul22b]: Lawrence Paulson. Memories: Edinburgh ML to Standard ML https://lawrencecpaulson.github.io/2022/10/05/Standard_ML.html   
 [PERQ1]: PERQ History, 1.3. EARLY DAYS http://www.chilton-computing.org.uk/acd/sus/perq_history/part_1/c3.htm   
+[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.   
 [POP19]: INFORMATION ABOUT POPLOG AND POP-11 2019 https://poplogarchive.getpoplog.org/poplog.info.html   
 [POPLOG]: Poplog https://github.com/poplog/poplog   
 [RAL83]: DISTRIBUTED INTERACTIVE COMPUTING NOTE 893, RUTHERFORD APPLETON LABORATORY, 3 October 1983 http://www.dataweb.clrc.ac.uk/acd/pdfs/dic/dic841.pdf   
@@ -1165,10 +1650,12 @@ October 1984 http://www.dataweb.stfc.ac.uk/inf/literature/reports/sti_report/p00
 [Rich85]: Richards, H. (1985). Applicative programming. Systems Research, 2(4), 299–306. doi:10.1002/sres.3850020409   
 [Ryde82]: Rydeheard, David Eric. "Applications of category theory to programming and program specification." (1982).   
 [Schmidt]: CV https://people.cs.ksu.edu/~schmidt/vita.html   
+[Shap83]: Ehud Y. Shapiro. 1983. The fifth generation project — a trip report. Commun. ACM 26, 9 (Sept. 1983), 637–641. doi:10.1145/358172.358179   
 [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.   
 [Sokolowski]: CV https://prabook.com/web/stefan_andrzej.sokolowski/90807   
 [SPJ82]: Simon L Peyton Jones. 1982. An investigation of the relative efficiencies of combinators and lambda expressions. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 150–158. doi:10.1145/800068.802145   
 [SPJ85]: Jones, S. L. P. (1985). Yacc in sasl — an exercise in functional programming. Software: Practice and Experience, 15(8), 807–820. doi:10.1002/spe.4380150807   
+[SPJ87]: Peyton Jones, Simon L. The implementation of functional programming languages (prentice-hall international series in computer science). Prentice-Hall, Inc., 1987.   
 [Stee82b]: Guy L. Steele. 1982. Report on the 1980 LiSP Conference Stanford University. August 25-27, 1980. SIGPLAN Not. 17, 3 (March 1982), 22–36. doi:10.1145/947912.1361218   
 [Stee84]: Steele, Guy L. "Common LISP. The language." Bedford: Digital Press (1984).   
 [Stee96]: Guy L. Steele and Richard P. Gabriel. 1996. The evolution of Lisp. Uncut draft.   

index.md

@@ -14,6 +14,16 @@
 
 ---------------------------
 
+[Обновление 2026-01-01](hopes.md#день-зависимости)   
+
+[Обновление 2025-12-13](hopes.md#негативное-пространство)  
+
+[Обновление 2025-11-16](hopes.md#граф-0)
+
+[Обновление 2025-10-30](hopes.md#новая-надежда)
+
+[Обновление 2025-09-06](hopes.md#big-in-japan)
+
 [Обновление 2025-08-09](hopes.md#le-ml)
 
 [Обновление 2025-06-30](hopes.md#fasadrenovering)