june upd.

hopes.md

@@ -18,6 +18,8 @@
   - [Столетняя война (40%)](#столетняя-война-40)
     - [Standard ML 84.7](#standard-ml-847)
     - [Façadisme](#façadisme)
+    - [Fasadrenovering](#fasadrenovering)
+    - [Standard ML 85.9](#standard-ml-859)
 - [Литература](#литература)
 
 
@@ -697,6 +699,139 @@ map (\x. x + y) [1; 2; 3] where y = 2;;
 Но в INRIA замену для него стали готовить уже в том же 84-ом году. У французских эмелистов было много идей и сами они объясняют раскол не привязанностью к синтаксису LCF/ML, а сомнениями в том, что им удастся добавить в SML нужные им новые фичи.   
 Привязанность к синтаксису LCF/ML явно сыграла свою роль, вид обновленного Cambridge ML это убедительно демонстрирует. Но современный вид OCaml, в свою очередь, демонстрирует уже то, что привязанность к синтаксису LCF/ML со временем ослабела, а новых фич, за добавление которых в SML пришлось бы бороться с сомнительными перспективами - было довольно много.    
 
+### Fasadrenovering
+
+Cambridge ML не был единственным LCF/ML, который подвергся HOPE-фикации. Скорее всего, не был и первым. Потеряв надежду на то, что смогут повлиять на решения SML-не-комитета, участники проекта Formel в INRIA оказались в том же положении, что и другая команда разработчиков компилятора ФЯ, которая не имела надежды на такое влияние с самого начала.   
+Речь идет о разработчиках Lazy ML и его компилятора - Леннарте Августссоне и Томасе Йонссоне. На очередной ФП-конференции LFP, состоявшейся в Августе 84-го в Остине, Техас, Августссон представил новую версию Lazy ML.   
+Августссон с Йонссоном, по видимому, не горели особым желанием изобретать собственный синтаксис, потому и взяли подмножество LCF/ML. Но теперь оказались в ситуации, в которой были вынуждены его изобретать.   
+Конечно, авторы и имплементаторы Lazy ML все равно могли основывать свою работу только на подмножестве SML, как до того - на подмножестве LCF/ML. Они не знали как совместить исключения и изменяемые ссылки с ленивым языком. Но подмножество какого именно SML им делать? Каждые несколько месяцев появляется новый SML.   
+Августссон с Йонссоном добавили фичи HOPE в свой ML довольно рано, в конце 83-го или начале 84-го года. И, как и их французские коллеги, рано начали использовать свой язык для написания кода. Так что можно предположить, что ни переписывание компилятора и компилируемого им кода раз в полгода из-за очередного полного переделывания синтаксиса SML, ни ожидание годами того момента, когда переделывание синтаксиса SML наконец закончится, не должно было выглядеть для них очень заманчиво.   
+Все что им оставалось - добавить в свое подмножество LCF/ML алгебраические типы и паттерн-матчинг своим способом.   
+В отличие от французов, они добавили в LCF/ML не многоветочную HOPE-лямбду, а функции, определяемые группами уравнений как в SML [Augu84]. Матчинг зависит от последовательности: слева - направо, сверху вниз как в языке Тернера и в Прологе. Неполное покрытие паттернов обнаруживается, но разрешено. В LML нет обработки исключений, если значение будет таким, которое неполный набор паттернов не сможет обработать - исполнение программы прекращается.   
+В отличие от авторов HOPE и подобно INRIA и авторам SML они добавили еще и Бурсталл-`case`-выражение из 60-х. И сделали именно `case`-выражение основной конструкцией через которую выражаются все производные. Что, полагаем, более привычный подход сегодня, чем определение всех ПМ-конструкций через лямбду с ПМ как в прото-SML.   
+
+```sml
+case x in 
+       C1 p1 : exp1
+    || C2 p2 : exp2
+end
+```
+  
+Еще один вариант `case`-выражения, не в точности как у Бурсталла, в SML или французском Cambridge ML, с новым видом разделителя между уравнений - `||`.   
+Лямбды с такими разделителями в LML нет, но та лямбда, что в LML есть, хотя и похожа на LCF/ML лямбду на первый взгляд, не поддерживает компактное объявление каррированных функций. Так что тут нет выбора между поддержкой каррирования или многоветочного паттерн-матчинга, лямбда в LML просто хуже, чем любая из двух обычных их разновидностей. Упрощенная декларация каррированных функций с помощью уравнений с ПМ, правда, поддерживается.   
+Августссон пишет [Augu85], что ПМ в LML развивался под влиянием HOPE и языков Тернера независимо от SML и "пока еще" отличается. Возможно, что это "пока еще" указывает на какие-то планы сделать LML более похожим на SML, которые так никогда и не материализовались. Но некоторые детали синтаксиса ПМ уже выглядят так, как будто позаимствованы у ранних версий SML, например `$`-уайлд-кард и `as`-паттерн. Со временем, правда, уайлд-кард в LML, как и в SML, сделают более привычного вида.   
+Есть и ПМ-фичи отсутствующие в SML, а именно гарды. Но гарды не такие как у Тернера в KRC 
+
+```
+f x = r1 , p
+    = r2 
+```
+
+и некоторых других языках уравнений, а более привычного вида, располагающиеся ближе к паттернам:
+
+```
+f x & p = r1
+f $     = r2 
+```
+
+но не совсем привычные, без возможности пропустить имя функции и паттерны-параметры, которая обычно есть в ФЯ сегодня:
+
+```haskell
+f x | p         = r1
+    | otherwise = r2 
+```
+
+Августссон пишет, что гарды могут быть средством имплементации нелинейных паттернов, но нелинейные паттерны в LML, по видимому, не добавил.   
+Уайлд-карды, `as`-паттерны и гарды, правда, появляются уже в более поздних статьях 85-го года, например в докладе [Augu85] на конференции FPCA 85, в котором Августссон более подробно рассказывает о компиляции паттерн-матчинга. Как компилировать паттерн-матчинг Августссон придумал может и не раньше МакКвина, но раньше опубликовал. Потому, что МакКвин не особенно торопился с публикацией. Изобретать самостоятельно компиляцию ПМ авторам LML пришлось не только потому, что наработки МакКвина были мало известны даже подписчикам самиздат-журнала "Полиморфизм", но и потому, что компилировать ПМ для ленивого языка с гардами нужно было другим способом.   
+Наш традиционный пример на обновленном LML.   
+
+```haskell
+nonfix "_[]";
+infixr "_.";
+type rec List *a = [] + *a . (List *a);
+
+rec map $ [] = [] 
+||  map f (x.l) = f x. map f l;
+
+map (\x. x + y) [1; 2; 3] where y = 2
+```
+
+Реальный библиотечный `map` отличается тем, что не использует `$`.   
+Как видите, синтаксис для декларации АлгТД в LML тоже оригинальный, не похожий в точности на тот, что в HOPE или ML-ях. Но больше похожий на тот, что в HOPE.   
+Но главное отличие АлгТД в LML от тех, что в SML, не в синтаксисе. В SML конструкторы могут либо не иметь параметра вовсе, либо иметь один параметр. Для конструирования объекта кучи со многими полями нужно использовать туплы. В LML конструкторы могут иметь более одного параметра-поля потому, что LML - ленивый язык и конструктор со многими полями вычисляется не так как конструктор с одним полем-туплом. Конструктор с несколькими полями, правда, не обязательно будет конструировать один объект в куче.   
+Представление списка чисел в памяти [John86] выглядит примерно настолько хуже VAX-ML-представления, насколько можно ожидать от ленивого языка.
+
+```
+                                               
+ ┌───┐   ┌───┬───┬───┐   ┌───┬───┬───┐   ┌───┐ 
+ │   ├──►│C12│   │   ├──►│C12│   │   ├──►│C00│ 
+ └───┘   └───┴─┬─┴───┘   └───┴─┬─┴───┘   └───┘ 
+               │               │               
+               │  ┌───┬───┐    │  ┌───┬───┐    
+               └─►│C01│ 1 │    └─►│C01│ 2 │    
+                  └───┴───┘       └───┴───┘    
+                                               
+```
+
+Лениво вычисляющиеся числа требуют своих объектов в куче и каждый объект требует указатель на функции, который работает и как тег. Но более сложные АлгТД могут иметь представление, которое намного хуже.   
+Дело в том, что первоначально Lazy ML был ленивым LCF/ML, в котором нет АлгТД и все типы данных нужно собирать из пар (троек в куче). Отсутствие необходимости в прочих конструкторах привело к выбору имплементирующего ленивость представления в памяти, которое отличается от, например, представления в GHC-Haskell, в котором АлгТД были с самого начала. В LML все ленивые конструкторы должны были помещаться на месте конструктора применения - тройки указателей - соответствующего конструктору АлгТД с двумя параметрами. Так что конструктор с тремя параметрами становился в куче тройкой со ссылкой на тройку, а конструкторы с большим числом - тройкой со ссылкой на массив ссылок, хранящий свою длину в одном из полей. Даже такое представление появилось не сразу, первоначально единственным решением был, по видимому, список троек.   
+Другое ограничение не было настолько же вынужденным и сложившимся исторически, но тоже происходящим от особенностей имплементации. Тегом конструктора является не число, которое можно сравнить с числом, а ссылка на набор функций. Авторы LML посчитали, что в АлгТД обычно не так много конструкторов и не нужно создавать слишком большой набор готовых конструкторов с разными тегами. Достаточно конструкторов для пяти значений тегов. Если у типа больше конструкторов - представление в памяти будет примерно как в раннем VAX ML: отдельный объект в куче хранит значение тега и ссылку на следующий объект кучи с полями конструктора.   
+Одна из общих фич LML и первых версий SML, из тех, что заметно повлияли на то, как ФП выглядит сегодня, не имела отношения к паттерн-матчингу и АлгТД. Как и в первых SML, раздельная компиляция в LML требовала от программиста декларировать используемые функции, конструкторы и типы. Например, для использования `map` нужно написать 
+
+```
+import map: ((*a->*b)->((List *a)->(List *b)));
+```
+
+Разумеется, такой подход придумали не авторы SML, но, наверное, они сыграли какую-то роль в нормализации такого в ФЯ середины 80-х. Конечно, писать такое вручную всякий раз программистам не очень хочется. Как мы уже выяснили в прошлой части, компилятор LML писали как инструмент UNIX-экосистемы и к решению проблемы подошли как там было принято. Компилятор генерировал для экспортов в `.m` файлах c LML-кодом заголовочные `.t` файлы с соответствующими импортами, после чего использующий их программист мог вставить их в свой файл с кодом с помощью C-препроцессора. И такое широкое использование C-препроцессора запустило последовательность событий, к результатам которой мы еще вернемся позднее.   
+После докладов на ФП-конференциях 84-го и 85-го годов о LML [Augu84] [Augu85] [John85] и VAX ML [Card84] то, как можно имплементировать практичные ФЯ или, по крайней мере, где искать информацию об этом, стало более-менее широко известно в узком кругу ФЯ-имплементаторов.   
+
+### Standard ML 85.9   
+
+Очередной большой съезд не-комитета SML состоялся в Эдинбурге в конце мая 1985 [Harp85]. Эдинбург на нем представляли Милнер, разработчики HOPE Бурсталл и Саннелла, работающие над Edinburgh ML (форком компилятора Карделли) Митчелл и Скотт, а также три новых героя нашей истории: имплементатор SML Дэвид Берри (David Berry) и два более важных деятеля, Роберт Харпер (Robert Harper) и Мадс Тофте (Mads Tofte), появление которых знаменует начало новой главы в истории ML.   
+Еще трое поработавших когда-то над ML и/или HOPE в Эдинбурге представляли уже другие группы разработчиков. Один из основных авторов HOPE и теперь SML МакКвин, работающий в Bell Labs вместе с Карделли, который кстати вернулся к обсуждению SML после перерыва чтоб потерять последние остатки интереса к SML. Майкрофт теперь представлял эмелистов Кембриджа вместе с Полсоном и автором Poly Мэттьюзом. К работе над ML после долгого перерыва вернулся и Вадсворт, работающий в лаборатории Резерфорда - Эплтона.   
+Во встрече не-комитета поучаствовал некий Ник Шарман (Nick Sharman) от Software Sciences. Не уверен, что мы еще о нем услышим после этого.   
+Не-комитет ознакомился еще и с письмом с комментариями от Дэвида Парка, того самого, который уже поучаствовал в нашей истории как не самый успешный имплементатор LISP и CPL. Харпер составил и описание этого заседания не-комитета.   
+Харпер, Мэттьюз и Парк поучаствовали в разработке языка достаточно, чтоб попасть в список авторов SML второго класса [Miln85].   
+Как обычно, значительная часть обсуждений была посвящена параметризованным модулям МакКвина, которым мы до сих пор не уделяли особого внимания потому, что пишем историю имплементаций и имплементаторы SML и родственных языков в это время активно работают над имплементацией ПМ и АлгТД, но история имплементации МакКвиновских модулей еще как следует не начиналась. Но это все скоро изменится. В 85-ом году Харпер начал работать над имплементацией модулей в Edinburgh ML и мы рассмотрим историю модулей подробно в следующей части.   
+Другая тема с большим будущим - перегрузка. На этой встрече Майкрофт выступает за более универсальный и доступный программисту механизм перегрузки, чем просто перегрузка арифметики для ограниченного числа типов и операций сравнения для менее ограниченного числа типов. У Майкрофта есть несколько сторонников, но голосование он проиграл.   
+В очередной раз обсудили полиморфные изменяемые ссылки и в очередной раз решили, что они не готовы. МакКвину не нравится подход Дамаша, считает его ограниченным.   
+Карделли предложил отказаться от локального объявлений типов. Прочие не-комитетчики признали, что никогда не использовали локальные типы сами, но решили оставить их в SML.   
+На этой же встрече МакКвин пересказал свое предложение по дизайну рекордов и Милнер предложил решить ряд вопросов:   
+
+1. Использовать ли именованные конструкторы рекордов как в Хаскеле и в рекордах Милнера. Они позволили бы меньше аннотировать типы, но достаточно единодушно решили, что их в SML не будет. 
+1. Функции-селекторы, как в Хаскеле и в рекордах Милнера. Вадсворт против селекторов и было решено, что селекторов не будет. Программист, которому понадобятся селекторы может их и сам написать.   
+1. Именованные поля в конструирующих выражениях и в паттернах. Рекорды будут скорее не как в предложении Милнера, а как у Карделли в VAX ML.   
+1. Перегрузка имен полей в рекордах. Милнер за перегрузку полей. И перегрузка полей будет.   
+1. Значимость порядка и приведение между рекордами с именованными полями и с безымянными (туплами). Порядок в выражениях имеет значение - определяет последовательность вычислений - но не в паттернах.   
+1. Ключевые слова для вызовов. Нет селекторов - нет проблем.   
+1. Специальные скобки и символы. Скобки решили делать `(| |)` как были сделаны у Карделли в VAX ML, а `#` в начале имен полей `#foo` не нужно.   
+1. Имена полей в типах. Будут.   
+1. Что будет основной формой, а что - производной. Туплы - производная форма. Это рекорды с полями, названными по их порядковому номеру.   
+1. Полиморфизм и подтипирование рекордов. Милнер против, считает что эти проблемы еще не решены. И потому такого в SML не будет. А значит, что перегрузка полей будет такой же ограниченной как и вся прояая перегрузка в SML в это время.   
+1. Можно ли писать `(| x |)` вместо `(| x=x |)` в паттернах? Карделли заявил, что это он изобрел такой синтаксис и он ему больше не нравится. Решили, что так делать нельзя.   
+
+Получилось так, что Карделлиевские рекорды из VAX ML попали таки в SML. Но, справедливости ради нужно отметить, что принятие не-полиморфных рекордов в SML с самого начала, скорее всего, не решило бы проблему потери Карделли интереса к имплементации SML. Принятие на этом этапе определенно не решило. С не-полиморфными рекордами он уже поэкспериментировал до того.   
+Кто-то предложил добавить и Карделлиевские не-полиморфные варианты, но не-комитет против, включая и самого Карделли.   
+У многих авторов и имплементаторов ФЯ, в числе прочих и SML, позднее будут другие мнения по всем этим рекордо-вопросам. Но пока что, судя по описанию заседания, все эти важные решения дались не-комитету относительно легко и похоже, что большинство не-комитетчиков не имело какого-то сформировавшегося и важного для них самих мнения по всем этим вопросам.   
+Что им дались значительно тяжелее? Разумеется очередное переделывание синтаксиса. По этим вопросам хорошо сформировавшееся мнение было у многих.   
+Карделли предложил сделать все, что называется буквами префиксным, а символами - инфиксным. Не-комитетчики оценили простоту предложения, но все равно единодушно отклонили.   
+Милнер хочет заменить `type rec` на `data`, а `val rec` на `fun` и, соответственно `fun` для обозначения лямбды на `fn`. Дальнейшее осуждение Харпер описывает фразами вроде "общее недовольство и несогласие", "в этот момент дискуссия стала непродуктивной".   
+Не-комитет дал решительный отпор Милнеру и постановил, что разобраться с тем, как будет выглядеть синтаксис должен под-не-комитет по синтаксису.   
+На встрече сформировали три под-не-комитета. По вводу-выводу, которым занимался когда-то Карделли, пока не перестал, в составе: Харпер, МакКвин, Мэттьюз, Митчелл. По раздельной компиляции: Харпер, МакКвин, Мэттьюз, Митчелл. По синтаксису: Харпер, МакКвин, Скотт.   
+Позднее в том же году под-не-комитет по синтаксису принял предложение Милнера. А Карделлиевские составные скобки рекордов `(| |)` заменили на скобки комментариев `{ }`, а скобки комментариев наоборот стали составными `(* *)`. Так что "ядро" SML в сентябрьской редакции описания [Miln85] наконец приняло вид, похожий на современный:   
+
+```sml
+infixr 5 ::
+datatype 'a list = nil | op :: of 'a * 'a list
+
+fun map _ nil    = nil
+  | map f (x::l) = f x :: map f l
+
+let val y = 2 in map (fn x => x + y) [1, 2, 3] end
+```
+
+На этом история адаптации изобретений 70-х закончилась и началась история формального описания Standard ML и решения проблем, которые были в 70-х в основном только сформулированы: разработка и имплементация параметризованных модулей, перегрузки и интеграции изменяемых ссылок в ФЯ. Но это уже другая история.   
+
 ПРОДОЛЖЕНИЕ СЛЕДУЕТ
 
 Литература
@@ -704,6 +839,8 @@ map (\x. x + y) [1; 2; 3] where y = 2;;
 
 [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   
+[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   
 [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   
 [Card82a]: EDINBURGH ML by Luca Cardelli, March, 1982. A README file accompanying the distribution of Cardelli's ML Compiler for VAX-VMS. https://smlfamily.github.io/history/Cardelli-Edinburgh-ML-README-1982_03.pdf   
 [Card83]: Luca Cardelli, Pre-Standard ML under Unix, August 14 1983. http://lucacardelli.name/Papers/MLUnix.pdf   
@@ -726,8 +863,11 @@ July 1981. Dijkstra working note EWD798. https://www.cs.utexas.edu/~EWD/transcri
 [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).   
 [Jenk80]: James H. Davenport and Richard D. Jenks. 1980. MODLISP. In Proceedings of the 1980 ACM conference on LISP and functional programming (LFP '80). Association for Computing Machinery, New York, NY, USA, 65–74. doi:10.1145/800087.802791   
+[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).   
 [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   
 [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   
@@ -750,6 +890,7 @@ July 1981. Dijkstra working note EWD798. https://www.cs.utexas.edu/~EWD/transcri
 [Miln84]: Robin Milner, The Standard ML Core Language, July 1984. https://smlfamily.github.io/history/SML-proposal-7-84.pdf   
 [Miln84b]: Robin Milner. 1984. A proposal for standard ML. In Proceedings of the 1984 ACM Symposium on LISP and functional programming (LFP '84). Association for Computing Machinery, New York, NY, USA, 184–197. doi:10.1145/800055.802035   
 [Miln84c]: Robin Milner, The Standard ML Core Language, October, 1984. The second draft of the "Core Language" design. https://smlfamily.github.io/history/SML-proposal-10-84.pdf   
+[Miln85]: Robin Milner, The Standard ML Core Language (Revised), September, 1985. The third draft of the "Core Language" design. https://smlfamily.github.io/history/SML-proposal-9-85.pdf   
 [Mitc84]: John C. Mitchell. 1984. Coercion and type inference. In Proceedings of the 11th ACM SIGACT-SIGPLAN symposium on Principles of programming languages (POPL '84). Association for Computing Machinery, New York, NY, USA, 175–185. https://doi.org/10.1145/800017.800529   
 [Mosses]: Peter Mosses, Affiliations https://pdmosses.github.io/affiliations/   
 [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   

index.md

@@ -14,6 +14,8 @@
 
 ---------------------------
 
+[Обновление 2025-06-30](hopes.md#fasadrenovering)
+
 [Обновление 2025-05-31](hopes.md#любой-принц-в-янтаре)   
 
 [Обновление 2025-04-30](hopes.md#карделли-против-карделли)