Re: Про параллелизм в Рефале

2019-12-01 Пенетрантность Boyko Bantchev boykobb_AT_gmail . com
On Sun, 1 Dec 2019 at 23:24, Andrei Klimov andrei_AT_klimov.net
 wrote:
>
> вс, 1 дек. 2019 г., 15:31 Александр Коновалов a.v.konovalov87_AT_mail.ru 
> :
>>
>> Кстати, вопрос к знатокам терминологии параллельного и/или функционального 
>> программирования. Вот есть понятие чистая функция — это детерминированная 
>> функция без побочного эффекта. У этого понятия есть антоним в русском языке, 
>> кроме словосочетания «грязная» функция? Я пишу «грязная» в кавычках, 
>> поскольку в литературе его не встречал.
>
>
> Александр, устно мы всегда говорили и говорим "грязная функция".
>
> В русском письменном языке более скованные традиции, чем в английском. Там 
> они легко тащат разговорный жаргон в профессиональную терминологию. А мы 
> что-то из себя изображаем.
>
> Я бы приветствовал использование "грязный" в текстах, но не знаю, сложилась 
> ли уже такая традиция.

Я бы предложил чистая/нечистая.  Мне кажется, это и лучше соответствует
английским словам pure/impure. По-английски не dirty function же, всё-таки :)


Re: Нужна ли "Ленинская простота" в Рефале?

2019-12-01 Пенетрантность Boyko Bantchev boykobb_AT_gmail . com
> Распространённая терминологическая ошибка 

Александр,

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

> Ликбез по типизациям: https://habr.com/ru/post/161205/

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

> А с тем, что Рефал — динамически типизированный, я не спорю.

Я и не утверждал то, с чем вы не спорите.
Кстати, оно и неоднозначно, динамический Рефал или нет.  Например,
если считать типами s., t. и e., то Рефал окажется статически
типизированным: тип каждой переменной определён в тексте программы,
т.е. статически.


Re: Про параллелизм в Рефале

2019-12-01 Пенетрантность Andrei Klimov andrei_AT_klimov . net
вс, 1 дек. 2019 г., 15:31 Александр Коновалов a.v.konovalov87_AT_mail.ru <
refal@botik.ru>:

> Кстати, вопрос к знатокам терминологии параллельного и/или функционального
> программирования. Вот есть понятие *чистая функция* — это
> детерминированная функция без побочного эффекта. У этого понятия есть
> антоним в русском языке, кроме словосочетания «грязная» функция? Я пишу
> «грязная» в кавычках, поскольку в литературе его не встречал.
>

Александр, устно мы всегда говорили и говорим "грязная функция".

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

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

Андрей

>


Re: Про параллелизм в Рефале

2019-12-01 Пенетрантность Eisymont Leonid verger-lk_AT_yandex . ru
Параллелить в Рефале можно гораздо больше, это описано в статье конца семидесятых в УСИМе.То, что описано в Вашем письме, нами пройдено в начале восьмидесятых, я об этих ловушках и говорил.Все описано в упомянутых публикациях и в моей диссертации, которую мне разрешили защитить перед работами по Бурану. Это май 1983 года.Л.Эйсымонт01.12.2019, 15:31, "Александр Коновалов a.v.konovalov87_AT_mail.ru" :Добрый день, Леонид, ещё раз!Выношу в отдельную тему обсуждение параллелизма. «С функциями с побочным эффектом надо быть осторожными. То, что Вы говорите, сводит на нет все распараллеливание по чистым конкретизациям.»Напишу подробнее, что же мы планируем со студентом получить (добавил его в копию).В Рефале можно параллелить три вещи: вызовы функций, сопоставления с образцами разных предложений и элементарные операции сопоставления в самом образце. Мы будем параллелить не зависящие по данным вызовы функций.Параллелизм предполагается неявный. Программист ничего не думает о потоках, синхронизации и прочих радостях бытия, он просто пишет программу на Рефале. А уже сам рантайм будет конкретизации раскидывать по потокам. Т.е. никаких функций вроде CreateThread, примитивов синхронизации, сообщений между потоками в API не будет в принципе.В основе параллельной реализации лежит базисный Рефал с полем зрения, которое изменяется по шагам. Функции делятся на две категории — функции, написанные на Рефале, и встроенные функции (написанные на Си). Функции, написанные на Рефале, за один шаг заменяют свой вызов в поле зрения на правую часть соответствующего предложения, в которой тоже могут быть новые термы конкретизации. Встроенные функции за один шаг заменяются на пассивное выражение.В такой модели можно параллельно вычислять, во-первых, любые функции на Рефале, во-вторых, чистые функции на Си. «Грязные» встроенные функции, вроде ввода-вывода и копилки, должны, тем не менее, вычисляться строго последовательно слева-направо.Новшество нашей со Станиславом работы в механизме, который позволяет параллелить вызовы, но при этом гарантирует правильный порядок «грязных» функций. Если кратко, идея в том, что все термы конкретизации в поле зрения провязаны двумя способами: древовидно, что отражает зависимости по данным, и линейно в том порядке, в каком они выполнялись бы последовательно. Термы конкретизации активируются (помещаются в очередь потока), когда их аргументы становятся пассивными. Но при выполнении «грязных» функций на Си, они «приостанавливаются». Повторно они активируются потоком, который бежит по линейному последовательному списку и тогда-то они выполняются.  Кстати, вопрос к знатокам терминологии параллельного и/или функционального программирования. Вот есть понятие чистая функция — это детерминированная функция без побочного эффекта. У этого понятия есть антоним в русском языке, кроме словосочетания «грязная» функция? Я пишу «грязная» в кавычках, поскольку в литературе его не встречал.  С уважением,Александр Коновалов From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru]Sent: Friday, November 29, 2019 5:25 PMTo: refal@botik.ruSubject: Re: Нужны ли вещественные числа в Рефале? С указателями на числа все неправильно. Именно надо работать с тем, на что ссылаемся, на 64-х разрядные числа. При реализации у нас даже мыслей таких не было, это не практично. Ссылки на ящики - совсем другое. Кстати, в реализации того рефала были введены ссылки на хеш-таблицы и даже на вектора. Это сильно помогло при оптимизации быстродействия.С функциями с побочным эффектом надо быть осторожными. То, что Вы говорите, сводит на нет все распараллеливание по чистым конкретизациям. Это мы проходили в начале 80-х годов. Хорошее распараллеливание в эксперименте удалось получить лишь при работе не просто с переменными и копилками, а, по-существу, с объектами типа мониторов Хоара и формируемых уникальных ID обращений к ним. Эти ID в таком объекте использовались для внутреннего упорядочивания действий с такими объектами. Есть препринт ИПМ  того времени по распараллеливанию модельного компилятора на имитационной модели параллельной рефал-машины. Я эту модель сделал на базе реализации Романенко-Климова для БЭСМ-6, просто по другому конкретизации запускал из дерева конкретизаций , используя предоставленный ими интерфейс.Про читаемость можно действительно  не обсуждать, но мне эти идентификаторы через точку при свободных переменных никогда не нравились, они "замыливают" видимость всей структуры области конкретизации, а это важно и для Рефала принципиально. Для информативности в смысле "что какая свободная переменная означает" использование идентификаторов явно недостаточно. У нас использовалась технология другая - была документация, хоть и рукописная, к наиболее важным функциям, где структура строки обращения подробно расписывалась.Еще требование - часть этой информации выносилась в  основной комментарий к функции типа структура входа и выхода. Более мелкие функции снабжались комментариями для каждого рефал-предложения.Это мы использовали в 

Re: Нужны ли вещественные числа в Рефале?

2019-12-01 Пенетрантность Eisymont Leonid verger-lk_AT_yandex . ru
Какое-то странное обсуждение. Кусок памяти с числом, на который имеется ссылка в звене списковой памяти, которое с точки зрения рефала - ссылка , это просто вещественное число. Можно по-другому назвать, тип добавить. Какая разница? Своего рода косвенная адресация. Что с ним можно делать - все в силе. В том числе и стандарт IEEE.Л.Эйсымонт 01.12.2019, 14:52, "Александр Коновалов a.v.konovalov87_AT_mail.ru" :Добрый день, Леонид!«С указателями на числа все неправильно. Именно надо работать с тем, на что ссылаемся, на 64-х разрядные числа.»Меня смутила фраза «символы-ссылки» в предыдущем письме. Во многих языках программирования различают типы-значения и типы-ссылки. Типы-значения сравниваются по значению, для типов-ссылок по умолчанию сравниваются адреса. Например, в Java примитивные типы (логические, числовые типы) — значения, для них == сравнивает значение, классы — ссылочные типы, == сравнивает указатели. Для сравнения ссылочных типов на равенство нужно вызывать метод x.equals(y).А сравнение вещественных чисел IEEE на равенство может преподнести сюрпризы. Во-первых, есть значения +0.0 и −0.0, которые имеют разное двоичное представление, но должны быть равны. Во-вторых, есть значение NaN (not-a-number, нечисло), которое не равно ничему, даже самому себе. Следующий код на Си выведет false:void f() {  double NaN = 0.0 / 0.0;  printf("%s\n", NaN == NaN ? "true" : "false");}В контексте Рефала это может привести к нарушению семантических инвариантов. Например,* Рефал-2Test SX = k/Eq/ k/Dup/ SX..Dup SX = SX SXEq SX SX = /Eq/   SX SY = /Neq/* Рефал-5Test { s.X = > }Dup { s.X = s.X s.X }Eq {  s.X s.X = Eq;  s.X s.Y = Neq;}По идее, функция Test всегда должна возвращать слово Eq. Но если вызвать функцию Test со значением «нечисло» и реализация будет использовать машинное сравнение на равенство для вещественных чисел, то функция вернёт Neq.Т.е. NaN нарушает неявный семантический инвариант Рефала — скопированные символы должны быть всегда равны. Это неявно предполагается в эквивалентных преобразованиях программ Турчина, на которых построена, в частности, суперкомпиляция Рефала. Про параллелизм и стиль программирования отвечу отдельными письмами. С уважением,Александр Коновалов From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru] Sent: Friday, November 29, 2019 5:25 PMTo: refal@botik.ruSubject: Re: Нужны ли вещественные числа в Рефале? С указателями на числа все неправильно. Именно надо работать с тем, на что ссылаемся, на 64-х разрядные числа. При реализации у нас даже мыслей таких не было, это не практично. Ссылки на ящики - совсем другое. Кстати, в реализации того рефала были введены ссылки на хеш-таблицы и даже на вектора. Это сильно помогло при оптимизации быстродействия.С функциями с побочным эффектом надо быть осторожными. То, что Вы говорите, сводит на нет все распараллеливание по чистым конкретизациям. Это мы проходили в начале 80-х годов. Хорошее распараллеливание в эксперименте удалось получить лишь при работе не просто с переменными и копилками, а, по-существу, с объектами типа мониторов Хоара и формируемых уникальных ID обращений к ним. Эти ID в таком объекте использовались для внутреннего упорядочивания действий с такими объектами. Есть препринт ИПМ  того времени по распараллеливанию модельного компилятора на имитационной модели параллельной рефал-машины. Я эту модель сделал на базе реализации Романенко-Климова для БЭСМ-6, просто по другому конкретизации запускал из дерева конкретизаций , используя предоставленный ими интерфейс.Про читаемость можно действительно  не обсуждать, но мне эти идентификаторы через точку при свободных переменных никогда не нравились, они "замыливают" видимость всей структуры области конкретизации, а это важно и для Рефала принципиально. Для информативности в смысле "что какая свободная переменная означает" использование идентификаторов явно недостаточно. У нас использовалась технология другая - была документация, хоть и рукописная, к наиболее важным функциям, где структура строки обращения подробно расписывалась.Еще требование - часть этой информации выносилась в  основной комментарий к функции типа структура входа и выхода. Более мелкие функции снабжались комментариями для каждого рефал-предложения.Это мы использовали в течение 30-40 лет при написании более 20 компиляторов и имитационных моделей. Потом настала перестройка и все обвалилось. Сейчас пытаемся эту практику восстановить. Очень хочется успеть самому и научить молодежь.Л.Эйсымонт  29.11.2019, 15:51, "Александр Коновалов a.v.konovalov87_AT_mail.ru" :Добрый день, Леонид!«Со символами ссылками не так. Там тупо в символе рефала ссылка на кусок памяти в 64 разряда, где хранится само число. Если сравнивать, то сравниваются содержимое двух кусков памяти, как это аппаратура может сделать.»Про символы-ссылки я имел ввиду следующее. Пусть имеются два символа-ссылки в переменных SA и SB. И мы вызываем функцию k/Eq/ SA SB.:Eq SX SX = /Eq/   SX SY = /Neq/Тогда для ссылок наиболее логичным будет 

Re: Рефал-2, Рефал-5 и стиль программирования

2019-12-01 Пенетрантность Eisymont Leonid verger-lk_AT_yandex . ru
Первая фраза спорная, даже неправильная. Я много повидал "героев", для которых лучшим документом по программе является сама программа. Конечно без документации на нее со структурами данных, описаниями алгоритмов. Даже обсуждать это бессмысленно. Все это плохо заканчивается.Еще надо учитывать то, что создание сложных программ - долгий процесс. Бывает, что подключаются новые исполнители. Тут также надо страховаться. Это обычная практика работы с коллективом даже в несколько человек.Еще одну вещь скажу, c определенного момента кроме программы с комментариями я прошу вести и журнал "ошибки-исправления", рукописный. Это по-старинке и даже при наличии систем отслеживания версий. Помогает, в настоящее время этим активно пользуюсь при комплексной отладке библиотеки параллельного программирования в Модуле.Л.Эйсымонт01.12.2019, 22:03, "Александр Коновалов a.v.konovalov87_AT_mail.ru" :Добрый вечер всем!Хочу дополнить предыдущее письмо. Я писал:«Так, что если программист пишет комментарий к каждой строчке, это одно из двух. Или язык недостаточно выразителен, что приходится его пересказывать на понятном языке. Или программист не умеет ясно выражать мысли на языке программирования.»Есть ещё третий случай — пишется ПО для ответственного применения. Например, компилятор для аэрокосмической отрасли, чем и занимался Леонид Эйсымонт. В таких случаях перестраховываться надо. С уважением,Александр Коновалов From: Александр Коновалов a.v.konovalov87_AT_mail.ru [mailto:refal@botik.ru]Sent: Sunday, December 1, 2019 4:17 PMTo: refal@botik.ruSubject: Рефал-2, Рефал-5 и стиль программирования Добрый день, Леонид!Добрый день всем остальным!Дабы не плодить офтопиков в теме про вещественную арифметику, начну новую тему. «Про читаемость можно действительно не обсуждать, но мне эти идентификаторы через точку при свободных переменных никогда не нравились, они „замыливают“ видимость всей структуры области конкретизации, а это важно и для Рефала принципиально.»Я воспринимаю их нормально. Надо попробовать попрограммировать на Рефале-2 или Рефале/2, и сравнить опыт.Только я не очень представляю себе, каким образом подбирать буквы для переменных. Мне и слов-то для длинных идентификаторов не всегда хватает.  «Для информативности в смысле „что какая свободная переменная означает“ использование идентификаторов явно недостаточно.»Недостаточно, но явно больше, чем одна буква или цифра. «У нас использовалась технология другая — была документация, хоть и рукописная, к наиболее важным функциям, где структура строки обращения подробно расписывалась.»Одно другому не мешает. У меня тоже есть такая документация, только она «машинописная»:https://github.com/bmstu-iu9/refal-5-lambda/blob/master/src/compiler/README.mdВпрочем, не у меня одного (из документации к Рефалу Плюс, но здесь только описания структур данных):http://skif.pereslavl.ru/skif/index.cgi?module=chap="">http://wiki.botik.ru/Refaldevel/AbstractImperativeLanguage Вообще, в идеале «структура строки обращения» должна проверяться некоторым специальным инструментом, как и типы, описанные по ссылкам выше. Т.е. нужна статическая типизация Рефала. Как-то я даже пытался написать такой инструмент совместно со студентом-двоечником. Ничего, кроме тройки за диплом (которая студента более чем удовлетворила), из этого не получилось:http://refal.botik.ru/events/IPSRAN-MGTU-seminar-05-06-2018/Staticheskaya_proverka_tipov_dlya_Refala_Alexandr-Romanov-05-06-2018.pdfhttps://github.com/bmstu-iu9/refal-type-verifier/tree/master/src/main/resources/docs «Ещё требование — часть этой информации выносилась в основной комментарий к функции типа структура входа и выхода.»Это хорошо, это правильно, я сам так делаю и всем рекомендую. Необходимый минимум — описание типов всех entry-функций (видимых из других модулей). Но ко всем функциям такое писать избыточно. «Более мелкие функции снабжались комментариями для каждого рефал-предложения.»А вот это плохо. Очень плохо. Если требуется записывать комментарии к каждому предложению функции, значит код сам себя не объясняет.Комментарии должны быть на уровень выше самого кода, должны объяснять то, что из кода не очевидно. Например, типы-грамматики. Если комментарий дублирует код — он избыточен. Если противоречит — он вреден. А противоречивым сделать комментарий легко — внесли изменение в код, отладили, а про комментарий забыли. Код должен объяснять себя сам. Плохой комментарий (дублирует код):++c; /* увеличиваем c на 1 */Комментарий лучше (объясняет цель):++c; /* увеличиваем счётчик связей */А теперь он снова плохой, потому что дублирует код:++refcounter; /* увеличиваем счётчик связей */Лучший комментарий — которого нет. Код объясняет сам себя:++refcounter; В моём коде на Рефале-5λ, где комментарии документируют только форматы функций, студенты разбирались самостоятельно и реализовывали всякие оптимизации. Позже в коде студентов, тоже написанном с минимумом комментариев, я разбирался и доводил его до ума (устранял мелкие ошибки, рефакторил).Так, что если программист пишет 

RE: Нужна ли "Ленинская простота" в Рефале?

2019-12-01 Пенетрантность Александр Коновалов a . v . konovalov87_AT_mail . ru
Добрый вечер, Бойко!

«Рефал ведь слабо типизированный язык…»

Распространённая терминологическая ошибка, перепутана слабая и динамическая 
типизация.

Сильно типизированный язык — язык, запрещающий неявные преобразования. Слабо 
типизированный язык — язык, разрешающий неявные преобразования. JavaScript — 
слабо типизированный язык, поскольку в нём можно сложить строку с числом. А 
Рефал — сильно типизированный язык, в нём нет неявных преобразований. Число 0 
может сопоставиться только с образцом 0, а не '0' (character) или "0" 
(составной символ).

А с тем, что Рефал — динамически типизированный, я не спорю.

Есть зачаток статической типизации в Рефале Плюс — форматы функций, но это 
только зачаток.

Ликбез по типизациям: https://habr.com/ru/post/161205/


Хорошая статическая типизация для Рефала даже первого порядка — интересная 
задача. Надеюсь, когда-нибудь решу.

Статическая типизация Рефала обсуждалась в этой рассылке в незапамятные времена 
(KOI8-R):

https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0005.html
https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0007.html
https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0222.html


«А избежание необходимости усложнений Рефала, на мой взгляд, можно постичь, 
если реализовать небольшое его подмножество в виде библиотеки на ANSI C.»

ИМХО тут надо брать пример с Lua.


С уважением,
Александр Коновалов


-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Sunday, December 1, 2019 12:52 PM
To: Александр Гусев ; refal@botik.ru
Subject: Re: Нужна ли "Ленинская простота" в Рефале?

> ... Если ещё немного усложнить язык - получится Хаскелл, зачем тогда Рефал?

Получить Haskell или вообще язык с системой типов Hindley–Milner из Рефала не 
то что с небольшими усложнениями, а вообще нереально ожидать.  Рефал ведь слабо 
типизированнъй язык, тогда как с Hindley–Milner-овскими языками как раз 
наоборот.  И механизмы сопоставления у Рефала и у Hindley–Milner-а совсем 
разные.
У каждого свои преимущества.

А избежание необходимости усложнений Рефала, на мой взгляд, можно постичь, если 
реализовать небольшое его подмножество в виде библиотеки на ANSI C.  Это даст, 
с одной стороны, компилятор, интерпретатор и REPL этого минимального и совсем 
простого Рефала для непосредственных применений, в том числе для изучения, 
обучения и всяких хобби занятий.
С другой стороны, через интерфейс к ANSI C будет обеспечена возможность 
сочетать программирование на Рефале с программированием на почти любом другом 
языке.  На этих других языках, а не в самом Рефале, и будут реализоваться все 
желательные языковые расширения.

И то, и другое увеличило бы, помимо прочего, практическую доступность Рефала.  
Зависимости от операционной системы, например, вообще не будет — одна 
реализация языка на все системы, где есть C.

Ещё одна возможность — реализовать тот самый небольшой Рефал в виде библиотеки 
на JavaScript, что обеспечило бы применимость и в вебприложениях, и (через 
Node) во многих других.

Может, я что-то упускаю из вида, но именно такой путь развития Рефала мне 
кажется очень перспективным.


Про параллелизм в Рефале

2019-12-01 Пенетрантность Александр Коновалов a . v . konovalov87_AT_mail . ru
Добрый день, Леонид, ещё раз!

Выношу в отдельную тему обсуждение параллелизма.

 

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

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

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

Параллелизм предполагается неявный. Программист ничего не думает о потоках, 
синхронизации и прочих радостях бытия, он просто пишет программу на Рефале. А 
уже сам рантайм будет конкретизации раскидывать по потокам. Т.е. никаких 
функций вроде CreateThread, примитивов синхронизации, сообщений между потоками 
в API не будет в принципе.

В основе параллельной реализации лежит базисный Рефал с полем зрения, которое 
изменяется по шагам. Функции делятся на две категории — функции, написанные на 
Рефале, и встроенные функции (написанные на Си). Функции, написанные на Рефале, 
за один шаг заменяют свой вызов в поле зрения на правую часть соответствующего 
предложения, в которой тоже могут быть новые термы конкретизации. Встроенные 
функции за один шаг заменяются на пассивное выражение.

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

Новшество нашей со Станиславом работы в механизме, который позволяет 
параллелить вызовы, но при этом гарантирует правильный порядок «грязных» 
функций. Если кратко, идея в том, что все термы конкретизации в поле зрения 
провязаны двумя способами: древовидно, что отражает зависимости по данным, и 
линейно в том порядке, в каком они выполнялись бы последовательно. Термы 
конкретизации активируются (помещаются в очередь потока), когда их аргументы 
становятся пассивными. Но при выполнении «грязных» функций на Си, они 
«приостанавливаются». Повторно они активируются потоком, который бежит по 
линейному последовательному списку и тогда-то они выполняются. 

 

Кстати, вопрос к знатокам терминологии параллельного и/или функционального 
программирования. Вот есть понятие чистая функция — это детерминированная 
функция без побочного эффекта. У этого понятия есть антоним в русском языке, 
кроме словосочетания «грязная» функция? Я пишу «грязная» в кавычках, поскольку 
в литературе его не встречал. 

 

С уважением,
Александр Коновалов

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru] 
Sent: Friday, November 29, 2019 5:25 PM
To: refal@botik.ru
Subject: Re: Нужны ли вещественные числа в Рефале?

 

С указателями на числа все неправильно. Именно надо работать с тем, на что 
ссылаемся, на 64-х разрядные числа. При реализации у нас даже мыслей таких не 
было, это не практично. Ссылки на ящики - совсем другое. Кстати, в реализации 
того рефала были введены ссылки на хеш-таблицы и даже на вектора. Это сильно 
помогло при оптимизации быстродействия.

С функциями с побочным эффектом надо быть осторожными. То, что Вы говорите, 
сводит на нет все распараллеливание по чистым конкретизациям. Это мы проходили 
в начале 80-х годов. Хорошее распараллеливание в эксперименте удалось получить 
лишь при работе не просто с переменными и копилками, а, по-существу, с 
объектами типа мониторов Хоара и формируемых уникальных ID обращений к ним. Эти 
ID в таком объекте использовались для внутреннего упорядочивания действий с 
такими объектами. Есть препринт ИПМ  того времени по распараллеливанию 
модельного компилятора на имитационной модели параллельной рефал-машины. Я эту 
модель сделал на базе реализации Романенко-Климова для БЭСМ-6, просто по 
другому конкретизации запускал из дерева конкретизаций , используя 
предоставленный ими интерфейс.

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

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

Это мы использовали в течение 30-40 лет при написании более 20 компиляторов и 
имитационных моделей. Потом настала перестройка и все обвалилось. Сейчас 
пытаемся эту практику восстановить. Очень хочется успеть самому и научить 
молодежь.

Л.Эйсымонт

 

 

29.11.2019, 15:51, "Александр Коновалов a.v.konovalov87_AT_mail.ru" 

RE: Нужны ли вещественные числа в Рефале?

2019-12-01 Пенетрантность Александр Коновалов a . v . konovalov87_AT_mail . ru
Добрый день, Леонид!

«С указателями на числа все неправильно. Именно надо работать с тем, на что 
ссылаемся, на 64-х разрядные числа.»

Меня смутила фраза «символы-ссылки» в предыдущем письме. Во многих языках 
программирования различают типы-значения и типы-ссылки. Типы-значения 
сравниваются по значению, для типов-ссылок по умолчанию сравниваются адреса. 
Например, в Java примитивные типы (логические, числовые типы) — значения, для 
них == сравнивает значение, классы — ссылочные типы, == сравнивает указатели. 
Для сравнения ссылочных типов на равенство нужно вызывать метод x.equals(y).

А сравнение вещественных чисел IEEE на равенство может преподнести сюрпризы. 
Во-первых, есть значения +0.0 и −0.0, которые имеют разное двоичное 
представление, но должны быть равны. Во-вторых, есть значение NaN 
(not-a-number, нечисло), которое не равно ничему, даже самому себе. Следующий 
код на Си выведет false:

void f() {
  double NaN = 0.0 / 0.0;
  printf("%s\n", NaN == NaN ? "true" : "false");
}

В контексте Рефала это может привести к нарушению семантических инвариантов. 
Например,

* Рефал-2
Test SX = k/Eq/ k/Dup/ SX..

Dup SX = SX SX

Eq SX SX = /Eq/
   SX SY = /Neq/

* Рефал-5
Test { s.X = > }

Dup { s.X = s.X s.X }

Eq {
  s.X s.X = Eq;
  s.X s.Y = Neq;
}

По идее, функция Test всегда должна возвращать слово Eq. Но если вызвать 
функцию Test со значением «нечисло» и реализация будет использовать машинное 
сравнение на равенство для вещественных чисел, то функция вернёт Neq.

Т.е. NaN нарушает неявный семантический инвариант Рефала — скопированные 
символы должны быть всегда равны. Это неявно предполагается в эквивалентных 
преобразованиях программ Турчина, на которых построена, в частности, 
суперкомпиляция Рефала.

 

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

 

С уважением,
Александр Коновалов

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru] 
Sent: Friday, November 29, 2019 5:25 PM
To: refal@botik.ru
Subject: Re: Нужны ли вещественные числа в Рефале?

 

С указателями на числа все неправильно. Именно надо работать с тем, на что 
ссылаемся, на 64-х разрядные числа. При реализации у нас даже мыслей таких не 
было, это не практично. Ссылки на ящики - совсем другое. Кстати, в реализации 
того рефала были введены ссылки на хеш-таблицы и даже на вектора. Это сильно 
помогло при оптимизации быстродействия.

С функциями с побочным эффектом надо быть осторожными. То, что Вы говорите, 
сводит на нет все распараллеливание по чистым конкретизациям. Это мы проходили 
в начале 80-х годов. Хорошее распараллеливание в эксперименте удалось получить 
лишь при работе не просто с переменными и копилками, а, по-существу, с 
объектами типа мониторов Хоара и формируемых уникальных ID обращений к ним. Эти 
ID в таком объекте использовались для внутреннего упорядочивания действий с 
такими объектами. Есть препринт ИПМ  того времени по распараллеливанию 
модельного компилятора на имитационной модели параллельной рефал-машины. Я эту 
модель сделал на базе реализации Романенко-Климова для БЭСМ-6, просто по 
другому конкретизации запускал из дерева конкретизаций , используя 
предоставленный ими интерфейс.

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

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

Это мы использовали в течение 30-40 лет при написании более 20 компиляторов и 
имитационных моделей. Потом настала перестройка и все обвалилось. Сейчас 
пытаемся эту практику восстановить. Очень хочется успеть самому и научить 
молодежь.

Л.Эйсымонт

 

 

29.11.2019, 15:51, "Александр Коновалов a.v.konovalov87_AT_mail.ru" 
mailto:refal@botik.ru> >:

Добрый день, Леонид!

«Со символами ссылками не так. Там тупо в символе рефала ссылка на кусок памяти 
в 64 разряда, где хранится само число. Если сравнивать, то сравниваются 
содержимое двух кусков памяти, как это аппаратура может сделать.»

Про символы-ссылки я имел ввиду следующее. Пусть имеются два символа-ссылки в 
переменных SA и SB. И мы вызываем функцию k/Eq/ SA SB.:

Eq SX SX = /Eq/
   SX SY = /Neq/

Тогда для ссылок наиболее логичным будет решение сравнить два указателя на 
равенство: если они ссылаются на один объект в памяти, то символы равны. А для 
сравнения вещественных чисел как чисел разумно ввести функцию вроде k/Compare/ 
SX SY., возвращающую '<', '=' или '>'.

На сколько я знаю Рефал-2, ссылки на 

Re: Нужна ли "Ленинская простота" в Рефале?

2019-12-01 Пенетрантность Boyko Bantchev boykobb_AT_gmail . com
> ... Если ещё немного усложнить язык - получится Хаскелл, зачем тогда Рефал?

Получить Haskell или вообще язык с системой типов Hindley–Milner
из Рефала не то что с небольшими усложнениями, а вообще нереально
ожидать.  Рефал ведь слабо типизированнъй язык, тогда как с
Hindley–Milner-овскими языками как раз наоборот.  И механизмы
сопоставления у Рефала и у Hindley–Milner-а совсем разные.
У каждого свои преимущества.

А избежание необходимости усложнений Рефала, на мой взгляд, можно
постичь, если реализовать небольшое его подмножество в виде библиотеки
на ANSI C.  Это даст, с одной стороны, компилятор, интерпретатор и
REPL этого минимального и совсем простого Рефала для непосредственных
применений, в том числе для изучения, обучения и всяких хобби занятий.
С другой стороны, через интерфейс к ANSI C будет обеспечена возможность
сочетать программирование на Рефале с программированием на почти любом
другом языке.  На этих других языках, а не в самом Рефале, и будут
реализоваться все желательные языковые расширения.

И то, и другое увеличило бы, помимо прочего, практическую доступность
Рефала.  Зависимости от операционной системы, например, вообще не
будет — одна реализация языка на все системы, где есть C.

Ещё одна возможность — реализовать тот самый небольшой Рефал в
виде библиотеки на JavaScript, что обеспечило бы применимость и в
вебприложениях, и (через Node) во многих других.

Может, я что-то упускаю из вида, но именно такой путь развития Рефала
мне кажется очень перспективным.