RE: Актуальные реализации и текущее состояние.

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!
Коллега Михаила Потанина уже начал готовить сборку пакета для пакетного 
менеджера Nix:
https://github.com/bmstu-iu9/refal-5-lambda/pull/363
И выяснилась любопытная проблема — Рефал-5λ не совместим с утилитой strip:
https://github.com/bmstu-iu9/refal-5-lambda/issues/364
Утилита strip, я напомню, используется для удаления отладочной информации из 
исполнимых файлов, собранных компилятором GCC.
 
Дело в том, что Рефал-5λ создаёт довольно странные исполнимые файлы. Исполнимый 
файл состоит из интерпретатора байткода (RASL’а, как говорят рефальщики), в 
конец которого непосредственно приписан сам байткод. Интерпретатор после 
запуска открывает сам себя, находит там байткод (он начинается со специальной 
сигнатуры) и его выполняет.
Цели в этом случае достигаются следующие:
• Построенные файлы полностью автономны — это просто исполнимый файл ОС, 
запускаемый естественным образом. Никакой доустановки интерпретаторов или 
библиотек рантайма на машину не требуется.
• Компилятору Рефала для создания этих файлов не требуется компилятор C++ — в 
дистрибутиве уже лежит готовый интерпретатор, к которому нужно тупо прилепить 
байткод скомпилированной программы.
• Переносимость — работает на Windows, Linux и macOS.
 
Но оказалось, что утилита strip, когда применяется к исполнимому файлу, смотрит 
только на префикс-интерпретатор, его перестраивает и теряет весь приписанный в 
конец байткод.
Команда strip вызывается при сборке пакета для Nix. Сейчас в скрипте сборки 
пакета прописана команда, подавляющая вызов strip. Но это, понятное дело, не 
решение проблемы, а всего лишь обходной путь.
 
Можно ли достигнуть описанных выше целей и обеспечить совместимость со strip — 
не знаю.
 
С уважением,
Александр Коновалов
 
From: Mike Potanin mpotanin_AT_gmail.com  
Sent: Monday, October 11, 2021 1:30 PM
To: Александр Гусев 
Cc: refal@botik.ru
Subject: Re: Актуальные реализации и текущее состояние.
 
 
 
On Mon, Oct 11, 2021 at 12:52 PM Александр Гусев mailto:gusev_aleksa...@mail.ru> > wrote:
Добрый день!
 
У меня следующие вопросы
1.  Нужно вопрос поконкретнее, о чём речь: собранные исполняемые файлы, 
дистрибутив в исходниках или дистрибутив с открытой лицензией? Первое — 
несколько проще, второе и третье могут по сложности поспорить с самой 
разработкой компилятора, если такой способ распространения не был задуман и 
заложен с систему изначально;
 Nix (https://nixos.org/) старается делать воспроизводимые сборки, то есть их 
одних исходников с одними зависимостями должно получаться бинарно одно и тоже. 
Хотя он позволяет очень гибко кустомизировать сборку, для распространенных 
конфигураций обычно устанавливаются предкомпилированные пакеты 
(воспроизводимость сборки это позволяет). Nix умеет устанавливать и 
проприетарные пакеты, но лучше, чтобы исходники были легко доступны - доверие к 
таким пакетам выше.
1.  Интересен компилятор сам по себе или речь идёт о возможности 
встраивания его в другой софт для расширения возможностей софта?
Как минимум компилятор. Если есть еще что - можно сделать отдельные пакеты. 
1.  Как я понимаю, основные существующие компиляторы Рефала придерживаются 
«классической» схемы: исходник — программа-компилятор — исполняемый модуль — 
программа-интерпретатор (я имею право ошибаться!). И всё в текстовом режиме 
командной строки. Кто нашёл время, тот настроил умный редактор для выполнения 
функций IDE и более комфортной работы. Это то, что требуется?
Для меня лично поддержка в IDE не актуально (я ими так и не научился 
пользоваться), но если будет какой-нибудь плугин к vscode, будет хорошо - 
многие интересные технологии не получают распространения из-за IDE.
 
Вопрос об установке непосредственно с Github вызван, думаю, тем, что 
большинство современны программных продуктов используют множество внешних 
библиотек сторонних разработчиков, которые только так и можно собрать в 
актуальном комплекте. Для удовлетворения требования автономной работы должна 
быть возможность переноса собранного таким образом исполняемого кода на 
автономную (без сети) машину. Думаю, что в большинстве случаев это возможно, 
хотя и не обязано удовлетворяться автоматически для всех средств 
распространения пакетов.
 
Управление зависимостями - сильная сторона Nix. Он умеет связывать инсталяцию 
ровно с теми библиотеками, с которыми она собрана.
 
 
Я, в свою очередь, тоже некоторое время назад озадачился созданием Рефал-среды 
«с нуля», используя достаточно свежие технологии и средства. Поэтому всякие там 
Github и UTF-8 поддерживаются естественным образом. А собственно сам мой 
компилятор пока принципиально уступает по производительности существующим 
«монстрам» (в позитивном смысле!) с 30-летней историей развития. Есть много 
принципиально новых идей относительно как Рефала, так и среды его исполнения, 
на реализацию которых, даже эскизную, не хватает пока что ресурса.
 
Nix в таких задачах помогает. Установка пакета доступна непривелигированному 
пользователю, что очень удобно, если хочется что-то "

RE: Актуальные реализации и текущее состояние.

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Михаил!
В своём ответе также отвечу на несколько соседних писем.
 
По поводу установки онлайн и офлайн. Для разработки доступ в интернет 
требуется, т.к. сборочные скрипты bootstrap.bat и bootstrap.sh выкачивают 
подмодуль. Впрочем, разрабатывать без интернета не очень логично, т.к. 
исходники лежат в GitHub и новый код всё равно придётся туда коммитить.
Установка может проходить в нескольких вариантах:
https://github.com/bmstu-iu9/refal-5-lambda/releases/tag/3.3.1
На unix-подобных системах Linux и macOS можно использовать модный нынче способ 
установки curl -L … | bash. Но доступны и офлайн-варианты: распаковать архив и 
выполнить в нём ./bootstrap.sh (скрипт из скачанного архива соединения с 
интернетом не требует). Фактически, curl -L … | bash скачивает архив, 
распаковывает и вызывает в нём ./bootstrap.sh. На Windows используется 
классический setup.exe.
Под современными дистрибутивами Linux и в последних версиях macOS всё 
собирается без проблем. На старых дистрибутивах Linux, например, на Fedora 16, 
есть проблемы со сборкой, которые я пока не решил. Самая ранняя система 
Windows, на которой я регулярно собираю исходники — Windows 7. Однако, нет 
причин не собраться и на Windows XP, и возможно даже, Windows 2000, но там я не 
пробовал. На Windows 98 собрать не получится, т.к. батники написаны для 
cmd.exe, а на Win9x — command.com.
Вариант с curl -L … | bash ставит систему в домашний каталог 
(~/.local/share/refal-5-lambda), прописывает PATH в ~/.bashrc или в 
~/.bash_profile. Setup.exe на Windows тоже ставит в профиль пользователя 
(%APPDATA%). Если скачивать архив и собирать из исходников, то куда захотите, 
туда и ставьте.
Установку в классические каталоги Linux (/usr/bin и прочие) я пока не 
поддерживаю, т.к. в этом не очень разбираюсь. Если Nix требует установки туда, 
то открывайте заявку в GitHub 
(https://github.com/bmstu-iu9/refal-5-lambda/issues), будем разбираться вместе.
 
По поводу интеграции с IDE. Есть плагин 
  для IntelliJ IDEA, плагин 
умеет подсвечивать синтаксис, автодополнять имена и показывать на 
синтаксические ошибки. Есть поддержка 
  нескольких 
текстовых редакторов: Vim, Far Colorer и VSCode.
 
«Рефал-5λ можно ограничить (например, опцией командной строки), чтобы он 
поддерживал только то, что понимает суперкомпилятор?»
Ну, для начала, SCP4 (я так понял, о нём идёт речь) сам по себе не очень 
полностью поддерживает Рефал-5. Например, не поддерживаются программы из 
нескольких файлов ($EXTERN в одном файле, $ENTRY в другом). С суперкомпиляцией 
программ, которые вызывают функцию Mu, есть некоторые сложности. SCP4 знает не 
все имена встроенных функций. SCP4 — это экспериментальный суперкомпилятор, но 
не промышленный.
Есть опция командной строки, которая ограничивает компилятор тем, что понимает 
классический Рефал-5 (т.е. запрещаются вложенные функции и другие расширения 
синтаксиса). Называется эта опция --classic. Об опции, которая ограничивала бы 
исходники тем, что поддерживает SCP4, я даже не задумывался. И мне не очевидны 
сценарии работы, где эта опция была бы полезна.
SCP4 после некоторой его доработки напильником может быть собран Рефалом-5λ. В 
его сборочном скрипте зашиты команды запуска refc и refgo. Сам суперкомпилятор 
многопроходный, проходы выделены в отдельные процессы, запускаемые 
последовательно. Управляющий компонент запускает эти процессы посредством того 
же refgo. Всё это можно переделать, чтобы собиралось при помощи Рефала-5λ, я 
это делал когда-то. (Есть адаптированные исходники: 
https://mazdaywik.github.io/direct-link/scp4_000925-srefc.zip, только в них 
нужно заменить srefc → rlc, srmake → rlmake.)
 
«Научить суперкомпилятор функциям высших порядков будет не просто…»
Я об этом как-то делал доклад в ИПМ имени Келдыша РАН. Там возникают всякие 
сложности со ссылочной эквивалентностью замыканий, когда вложенные функции 
начинают специализироваться. Да, там всё непросто, если стремиться к 
действительно эквивалентным преобразованиям. Однако, если забить на нарушение 
инвариантов, которые в Рефале должны быть незыблемыми, то всё становится проще.
 
«а сделать ещё пакет для суперкомпилятора было бы полезно»
На эту тему лучше напрямую списаться с Андреем Петровичем Немытых: 
nemyt...@math.botik.ru  .
 
«Можно, конечно, и по Zoom или совместить offline и online, какое-то 
оборудование для видеоконференций там есть.»
Могу приехать и выступить. Так даже интереснее.
 
С уважением,
Александр Коновалов
 
From: Mike Potanin mpotanin_AT_gmail.com  
Sent: Monday, October 11, 2021 1:11 PM
To: refal@botik.ru
Subject: Re: Актуальные реализации и текущее состояние.
 
Спасибо!
Рефал-5λ можно ограничить (например, опцией командной строки), чтобы он 
поддерживал
только то, что понимает суперкомпилятор? Научить суперкомпилятор функциям 
высших порядков
будет не просто, а сделать еще пакет для суперкомпилятора 

RE: Актуальные реализации и текущее состояние.

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Михаил!

На данный момент в системе контроля версий, на сколько мне известно, живут 
интерпретатор Рефала-2:

https://github.com/cmc-msu-ai/refal

и мой Рефал-5λ:

https://github.com/bmstu-iu9/refal-5-lambda

Первый уже 6 лет не обновляется, второй активно развивается.

Остальные лежат в zip-архивах на своих сайта.

Какая версия наиболее актуальна? Позволю себе быть необъективным и скажу, что 
моя. 😉 Рефал-5λ собирается и работает под тремя основными операционными 
системами: Windows, Linux и macOS, на процессорах с разрядностью 32 и 64 бита.

А собраться рассказать — это приехать на Воронцово поле (см. адрес по Вашей 
ссылке) или можно дистанционно через Zoom?

 

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

 

From: Mike Potanin mpotanin_AT_gmail.com  
Sent: Sunday, October 10, 2021 3:31 PM
To: refal@botik.ru
Subject: Актуальные реализации и текущее состояние.

 

Добрый день!

Рефалом заинтересовался мой друг, мантейнер пакетов Nix и кофаундер хакспейса.

Он спрашивает какие версии наиболее актуальны, чтобы сделать для них пакеты в 
Nix

(желательно работающие под Linux и хранящиеся не в zip-архиве, а в системе 
контроля версий,

позволяющей сослаться на конкретный коммит ;-)) и предлагает как-нибудь 
собраться у него

в хакспейсе (https://t.me/undefspace), чтобы кто-нибудь рассказал про текущее 
состояние

Рефала и обсудить, куда двигаться.

 

С уважением,

Михаил Потанин

FW: Приглашение на онлайн семинар ruSTEP в пятницу 9 июля в 12:00 мск (=16:00 нск).

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

(Перенаправляю письмо в рассылки)

 

From: Shilov Nikolay  
Sent: Thursday, July 8, 2021 5:11 AM
To: n.shi...@innopolis.ru
Subject: Приглашение на онлайн семинар ruSTEP в пятницу 9 июля в 12:00 мск 
(=16:00 нск).

 

Уважаемые подписчики новостей о предстоящих заседаниях ru-STEP!

(ruSTEP=russian seminar on Software Engineering, Theory and Experimental 
Programming,   
https://persons.iis.nsk.su/ru/ruSTEP) 

 

Во-первых, извините за задержку с объявлением программы семинара на июль 2021 
г. — как и в июне, возникла некоторая неопределенность с доступностью 
докладчиков в летнее время. 

 

Во-вторых, очередное заседание состоится в пятницу 9 июля 2021 г. (с 12:00 до 
13:40 московского времени, 16:00-17:40 в Новосибирске).

Семинар пройдет в Zoom ( 
 
https://us02web.zoom.us/j/83462558349?pwd=azR1cWwrdWlZbXo2dm0rdzVtdFVmQT09, 
идентификатор 834 6255 8349, пароль 633666). — Уважаемые участники из 
Университета Иннополис! Обратите внимание, что в этот раз очного семинара не 
будет.

 

Выступает Антонина Николаевна Непейвода (Институт программных систем им. А.К. 
Айламазяна РАН, г. Переславль-Залеский, http://www.psi-ras.ru/) 

 

Тема: Опыты по суперкомпиляции языка Рефал

 

Аннотация: Это выступление продолжает доклад Александра Владимировича 
Коновалова по языку Рефал на семинаре ruSTEP 11 июня 2021 г. Будет кратко 
рассмотрен метод суперкомпиляции в применении к этому языку, и некоторые его 
приложения. С одной стороны, ассоциативность встроенных данных Рефала усложняет 
разработку алгоритмов анализа его программ, с другой -  даёт возможность 
доказывать свойства, естественно извлекаемые из программ, записанных на Рефале, 
и гибко описывать модели структур, обладающих ассоциативностью. В частности, мы 
покажем, как методами суперкомпиляции моделируются некоторые алгоритмы решения 
уравнений в словах.

 

Регламент семинара: 

*   12:00-12:05 — открытие заседания семинара
*   12:05-12:55 — основная часть доклада 
*   12:55-13:00 — перерыв
*   13:05-13:35 — продолжение (с вопросами и обсуждением)
*   13:35-13:40 — закрытие заседания семинара

Ведет заседание Николай В. Шилов (Университет Иннополис)

==

P.S. Пожалуйста, распространяйте информацию о нашем семинаре среди ваших 
коллег, приглашайте их регистрироваться в  
 https://forms.gle/earZy3hFJKmHQLoZ7. 

 

 

RE: IV совместное совещание ИПС РАН — МГТУ по Рефалу

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

Вывешены слайды с IV совместного совещания:

http://refal.botik.ru/events/events.htm
http://refal.botik.ru/events/IPSRAN-MGTU-seminar-08-06-2021.pdf

Дмитрий Иванович Костин читал доклад без слайдов (рассказывал и писал на 
доске), поэтому слайдов нет. Возможно, он со временем предоставит конспект 
своего доклада.

 

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

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru  
Sent: Sunday, June 6, 2021 4:26 PM
To: refal@botik.ru; metacomputation...@googlegroups.com
Subject: IV совместное совещание ИПС РАН — МГТУ по Рефалу

 

Добрый день всем!

Во вторник, 8 июня в МГТУ имени Н. Э. Баумана пройдёт традиционное

IV совместное рабочее совещание
ИПС имени А.К. Айламазяна РАН
и
МГТУ имени Н.Э. Баумана
по функциональному языку Рефал

С докладами выступят сотрудники ИПС и преподаватели и студенты МГТУ. Совещание 
посвящено языку программирования Рефал и метавычислениям над ним.

Адрес: ул. 2-я Бауманская, дом 5 (главный корпус). Время с 11:00 до 17:30, 
аудитория 330аю.

Если хотите посетить совещание — пришлите мне ФИО до понедельника 7 июня, чтобы 
я смог выписать разовые пропуска. Вход на проходной по паспорту.

 

Программа мероприятия

11:00–11:05 — открытие

Первая сессия, председатель Александр Коновалов

11:05–11:45 — Андрей Немытых «О языке описания свойств параметризованных 
конфигураций (уравнение Хмелевского в словах)»
11:45–11:50 — перерыв
11:50–12:15 — Александра Спиридонова «Построение решателя уравнений в словах 
методом развёртки/свёртки графа решений»
12:15–12:20 — перерыв
12:20–13:00 — Антонина Непейвода «Суперкомпиляция как основа для построения 
алгоритмов решения уравнений в словах»

13:00–13:30 — обед

Вторая сессия, председатель Антонина Непейвода

13:30–13:55 — Владислав Пичугин «Расширенный алгоритм обобщённого сопоставления 
в компиляторе Рефала-5λ»
13:55–14:00 — перерыв
14:00–14:25 — Михаил Апахов «Алгоритм прогонки вызовов рекурсивных функций, не 
приводящий к зацикливанию в компиляторе Рефала-5λ»
14:25–14:30 — перерыв
14:30–15:10 — Александр Коновалов «Декомпозиция вызовов функций во время 
суперкомпиляции путём построения выходных форматов»

15:10–15:30 — кофе

Третья сессия, председатель Андрей Немытых

15:30–15:55 — Дмитрий Сырбу «Типизация функций для Рефала-5»
15:55–16:00 — перерыв
16:00–16:25 — Евгений Шевляков «О переборных алгоритмах проверки вложения 
конечнозначных структур»
16:25–16:30 — перерыв
16:30–17:10 — Дмитрий Костин «Проект Aleph0 — постановка задачи для создания 
платформонезависимой системы управления знаниями на базе языка Refal»

17:10–17:25 — обсуждение
17:25–17:30 — закрытие

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

 

Аннотации докладов

1. Андрей Немытых «О языке описания свойств параметризованных конфигураций 
(уравнение Хмелевского в словах)»

В суперкомпиляторе MSCP-A реализован язык описания свойств параметризованных 
конфигураций L специализируемой программы, основанный на языке уравнений в 
свободном моноиде. Необходимость в использовании языка L следует из 
ассоциативности операции приписывания в языке Рефал. В докладе будут 
обсуждаться некоторые выразительные свойства языка L.

 

2. Александра Спиридонова «Построение решателя уравнений в словах методом 
развёртки/свёртки графа решений»

При суперкомпиляции программ возникает задача решения уравнений в словах.

A — алфавит констант; X — алфавит строковых переменных; T₁ = T₂ — уравнение в 
словах, где (T₁, T₂) ∊ (A ∪ X)*×(A ∪ X)*.

Основная трудность, возникающая при их решении — отсутствие эффективного и 
полного алгоритма, который бы находил все решения уравнения. Реализованный 
алгоритм Матиясевича определяет, имеет ли уравнение в словах решение. Он 
основан на свёртке и развёртке дерева всех возможных решений, которое 
порождается некоторым «шагом прогонки», т. е. способом преобразования уравнения 
в множество уравнений — частных случаев исходного. Алгоритм использует для 
построения графа развёртки преобразования Нильсена.

Построенный решатель усиливает алгоритм Матиясевича при помощи анализа 
структуры уравнения в словах, определения принадлежности уравнения одному из 
специальных классов и последующего использования простых преобразований 
(конечные подстановки, противоречие по длинам, разбиение, упрощение).

 

3. Антонина Непейвода «Суперкомпиляция как основа для построения алгоритмов 
решения уравнений в словах»

В докладе рассматривается способ использования суперкомпилятора в качестве 
каркаса для построения алгоритмов решения уравнений в словах. Для этого можно 
написать интерпретатор простого логического языка, проверяющего, приводит ли 
последовательность преобразований над уравнением к его решению, и затем 
проспециализировать такой интерпретатор конкретным уравнением, которое 
требуется решить. Если интерпретатор построен правильно, и специализация 
завершится, её результатом окажется описание всех решений уравнения. Ключевым 
свойством, обеспечивающим способность решать уравнения, 

RE: Приглашение на онлайн семинар ruSTEP в пятница 11 июня в 12:00 мск (=16:00 нск).

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!
Слайды к сегодняшнему докладу:
https://mazdaywik.github.io/direct-link/2021-06-11-Konovalov-Introduction-to-Refal.pdf
Исправил обнаруженные опечатки. На слайдах была написана функция объединения 
множеств, но называлась она Intersect, на что обратила внимание Антонина 
Николаевна. Исправил функцию Intersect (сделал пересечением) я ещё во время 
доклада. Сейчас я дополнительно в конец презентации добавил функцию Union, 
вычисляющую объединение множеств.
Надеюсь, доклад получился понятным и интересным.
 
Будем ждать, когда Антонина Николаевна раскроет нам некоторые тайны 
суперкомпиляции Рефала, которые я затронул во второй части доклада. 
Предварительно её доклад будет где-то в июле.
 
С уважением,
Александр Коновалов
 
From: ru-step-discussion-gr...@googlegroups.com 
 On Behalf Of Lidia Gorodnyaya
Sent: Friday, June 11, 2021 3:28 PM
To: Andrei Klimov 
Cc: ru-step-discussion-gr...@googlegroups.com; metacomputation-ru 
; refal@botik.ru
Subject: Re: Приглашение на онлайн семинар ruSTEP в пятница 11 июня в 12:00 мск 
(=16:00 нск).
 
К сожалению, прозевала время семинара.
Тем не менее, история Рефала заставляет подумать о многом. 
 
 
пт, 11 июн. 2021 г. в 18:41, Andrei Klimov mailto:and...@klimov.net> >:
Добрый день всем!

По итогам только что прошедшего семинара, в связи с возникшим обсуждением целей 
Рефала при его создании, хочу обратить внимание на предисловие В.Ф.Турчина к 
первому изданию в 1993 году на русском языке его книги "Феномен науки". Оно 
неявно содержит цели Рефала как метаалгоритмического языка, предназначенного 
для компьютерной обработки формально-языковых систем, математических и 
физических теорий, то есть как инструмент построения метанауки. Об этом Турчин 
явно говорил нам в 60-70-е годы. Приведу копипаст со страницы 
http://www.refal.net/turchin/phenomenon/preface.htm:
 
Предисловие
 
Русское издание этой книги выходит через двадцать с лишним лет после ее 
написания. За это время наука существенно продвинулась вперед. Достаточно 
вспомнить раскрытие генетического кода, открытия в астрофизике, новую теорию 
элементарных частиц. Персональные компьютеры вошли чуть ли не в каждый дом. 
Между тем книга выходит в том виде, в каком она была подготовлена к печати в 
1970 г. Если бы я стал что-то добавлять к ней, то это превратилось бы, в 
конечном счете, в написание новой книги, гораздо большей по объему, и она 
включала бы в себя старую практически целиком и без перемен. Ибо основная тема 
книги — Эволюция Вселенной как последовательность метасистемных переходов — не 
пострадала от времени. Напротив, появились новые указания на плодотворность 
этого подхода. В настоящее время мы с группой коллег начали работу над проектом 
PRINCIPIA CYBERNETICA, который включает дальнейшее развитие этих идей. 
Некоторое представление об этом проекте дает написанная мною совместно с 
Клиффом Джослиным статья “Кибернетический манифест”. Эта статья также включает 
краткое изложение основных идей книги и включена в качестве приложения 
  к 
настоящему изданию.
 
“Феномен науки” вышел в английском и японском переводах. Я очень рад, что он 
может, наконец, выйти и в русском оригинале.
 
Одно место в “Феномене науки” требует комментария в свете последних достижений 
физики. В разделе “Сумасшедшие теории и метанаука” я высказал мысль, что для 
того, чтобы разрешить трудности в современной теории элементарных частиц, надо 
разработать методы “метанауки”, т. е. теории о том, как строить теории. Причину 
я усматривал в том, что основные понятия физики на ранних стадиях ее развития 
брались из нашей интуиции макроскопического мира. Но для познания законов 
микромира (а точнее, для построения математических моделей этого мира) наша 
“макроскопическая” интуиция неадекватна. Если интуиция не дает нам впрямую тех 
“колесиков”, из которых можно строить модели микромира, то нам нужны какие-то 
теории о том, как эти колесики выбирать и как модели строить. Это и будет 
метанаука.
 
С тех пор как была написана моя книга, физика элементарных частиц сделала 
огромный шаг вперед — и без всякой метанауки, а лишь на основе старой идеи, что 
одни частицы могут как бы состоять из других, более элементарных частиц. Тем не 
менее я полагаю, что моя логика остается в силе, и если не на данной, то на 
какой-то последующей стадии развития точных наук метатеоретические методы 
докажут свою плодовитость.
 
В.Ф.Турчин
Обнинск, август 1990 г.
Небольшое пояснение о месте и дате подписи. Они умышленные. Это был второй 
визит Валентина Федоровича с Татьяной Ивановной на родину после 12 лет 
прерывания практически всех контактов между нами (и без веры на встречу). Тогда 
мы провели в Обнинске семинар по Рефалу и суперкомпиляции, на котором 
прокачивали накопившиеся к тому времени идеи суперкомпиляции и развития Рефала. 
Обнинск – это место начала научной карьеры Турчина, где еще жили друзья его 
молодости. Именно они помогли организовать семинар в самом респектабель

IV совместное совещание ИПС РАН — МГТУ по Рефалу

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

Во вторник, 8 июня в МГТУ имени Н. Э. Баумана пройдёт традиционное

IV совместное рабочее совещание
ИПС имени А.К. Айламазяна РАН
и
МГТУ имени Н.Э. Баумана
по функциональному языку Рефал

С докладами выступят сотрудники ИПС и преподаватели и студенты МГТУ. Совещание 
посвящено языку программирования Рефал и метавычислениям над ним.

Адрес: ул. 2-я Бауманская, дом 5 (главный корпус). Время с 11:00 до 17:30, 
аудитория 330аю.

Если хотите посетить совещание — пришлите мне ФИО до понедельника 7 июня, чтобы 
я смог выписать разовые пропуска. Вход на проходной по паспорту.

 

Программа мероприятия

11:00–11:05 — открытие

Первая сессия, председатель Александр Коновалов

11:05–11:45 — Андрей Немытых «О языке описания свойств параметризованных 
конфигураций (уравнение Хмелевского в словах)»
11:45–11:50 — перерыв
11:50–12:15 — Александра Спиридонова «Построение решателя уравнений в словах 
методом развёртки/свёртки графа решений»
12:15–12:20 — перерыв
12:20–13:00 — Антонина Непейвода «Суперкомпиляция как основа для построения 
алгоритмов решения уравнений в словах»

13:00–13:30 — обед

Вторая сессия, председатель Антонина Непейвода

13:30–13:55 — Владислав Пичугин «Расширенный алгоритм обобщённого сопоставления 
в компиляторе Рефала-5λ»
13:55–14:00 — перерыв
14:00–14:25 — Михаил Апахов «Алгоритм прогонки вызовов рекурсивных функций, не 
приводящий к зацикливанию в компиляторе Рефала-5λ»
14:25–14:30 — перерыв
14:30–15:10 — Александр Коновалов «Декомпозиция вызовов функций во время 
суперкомпиляции путём построения выходных форматов»

15:10–15:30 — кофе

Третья сессия, председатель Андрей Немытых

15:30–15:55 — Дмитрий Сырбу «Типизация функций для Рефала-5»
15:55–16:00 — перерыв
16:00–16:25 — Евгений Шевляков «О переборных алгоритмах проверки вложения 
конечнозначных структур»
16:25–16:30 — перерыв
16:30–17:10 — Дмитрий Костин «Проект Aleph0 — постановка задачи для создания 
платформонезависимой системы управления знаниями на базе языка Refal»

17:10–17:25 — обсуждение
17:25–17:30 — закрытие

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

 

Аннотации докладов

1. Андрей Немытых «О языке описания свойств параметризованных конфигураций 
(уравнение Хмелевского в словах)»

В суперкомпиляторе MSCP-A реализован язык описания свойств параметризованных 
конфигураций L специализируемой программы, основанный на языке уравнений в 
свободном моноиде. Необходимость в использовании языка L следует из 
ассоциативности операции приписывания в языке Рефал. В докладе будут 
обсуждаться некоторые выразительные свойства языка L.

 

2. Александра Спиридонова «Построение решателя уравнений в словах методом 
развёртки/свёртки графа решений»

При суперкомпиляции программ возникает задача решения уравнений в словах.

A — алфавит констант; X — алфавит строковых переменных; T₁ = T₂ — уравнение в 
словах, где (T₁, T₂) ∊ (A ∪ X)*×(A ∪ X)*.

Основная трудность, возникающая при их решении — отсутствие эффективного и 
полного алгоритма, который бы находил все решения уравнения. Реализованный 
алгоритм Матиясевича определяет, имеет ли уравнение в словах решение. Он 
основан на свёртке и развёртке дерева всех возможных решений, которое 
порождается некоторым «шагом прогонки», т. е. способом преобразования уравнения 
в множество уравнений — частных случаев исходного. Алгоритм использует для 
построения графа развёртки преобразования Нильсена.

Построенный решатель усиливает алгоритм Матиясевича при помощи анализа 
структуры уравнения в словах, определения принадлежности уравнения одному из 
специальных классов и последующего использования простых преобразований 
(конечные подстановки, противоречие по длинам, разбиение, упрощение).

 

3. Антонина Непейвода «Суперкомпиляция как основа для построения алгоритмов 
решения уравнений в словах»

В докладе рассматривается способ использования суперкомпилятора в качестве 
каркаса для построения алгоритмов решения уравнений в словах. Для этого можно 
написать интерпретатор простого логического языка, проверяющего, приводит ли 
последовательность преобразований над уравнением к его решению, и затем 
проспециализировать такой интерпретатор конкретным уравнением, которое 
требуется решить. Если интерпретатор построен правильно, и специализация 
завершится, её результатом окажется описание всех решений уравнения. Ключевым 
свойством, обеспечивающим способность решать уравнения, является оптимальность 
пары интерпретатор + суперкомпилятор — соответствие операций свёртки и 
развёртки при специализации таковым в алгоритмах решения уравнений. Мы покажем, 
какие особенности рассмотренных в докладе интерпретаторов позволили добиться 
оптимальности специализации.

 

4. Владислав Пичугин «Расширенный алгоритм обобщённого сопоставления в 
компиляторе Рефала-5λ»

Центральное место в языке программирования Рефал-5λ занимает механизм 
сопоставления с образцом, использующийся во время выполнения любой программы, а 
также в некоторых оптимизациях, происходящих на 

8 июня рефал-семинар ИПС РАН и МГТУ

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!

8 июня у нас в Бауманке пройдёт традиционное

IV совместное рабочее совещание
ИПС имени А.К. Айламазяна РАН и МГТУ имени Н.Э. Баумана
по функциональному языку Рефал

Как и прежде, тематика семинара - Рефал и метавычисления над ним. Как и
прежде, выступят сотрудники ИПС РАН и преподаватели и студенты МГТУ.

Список докладов с аннотациями будет готов в воскресенье, на данный момент
точные формулировки тем уточняются.

 

Мероприятие пройдёт очно 8 июня (вторник). Начало в 11:00. Окончание
примерно в 18 часов, пока точно не знаем, т.к. программу ещё составляем.

Чтобы пройти на территорию МГТУ, необходим пропуск. Заказывать пропуска я
буду в понедельник. Поэтому если хотите посетить семинар, нужно мне до
понедельника сообщить фамилию, имя и отчество, для прохода потребуется
паспорт.

Трансляции в интернет не предусмотрено, т.к. мы не умеем её делать и у нас
нет необходимого оборудования.

 

Ждём вас на совещании!

До встречи!
Александр Коновалов

 

 

RE: Генератор билетов по компиляторам

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Спасибо!

-Original Message-
From: Скоробогатов Сергей Юрьевич skorobogatov_AT_bmstu.ru  
Sent: Wednesday, May 26, 2021 12:17 PM
To: Александр Коновалов a.v.konovalov87_AT_mail.ru 
Subject: Генератор билетов по компиляторам

Кодировка -- KOI8 :-)

RE: Харитоновские Научные Чтения - 2021

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Андрей и Аркадий!

Спасибо за интересные доклады!

 

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

 

From: metacomputation...@googlegroups.com  
On Behalf Of Andrei Klimov
Sent: Tuesday, May 25, 2021 8:17 PM
To: metacomputation-ru 
Cc: refal@botik.ru
Subject: Re: Харитоновские Научные Чтения - 2021

 

Можно загрузить сборник трудов конференции Харитон-2021 и посмотреть 1-2 
страничные тезисы докладов, пойдя на страницу:

*   http://nimfa.vniief.ru/khariton2021/materialy-khariton-2021/

Сборник:

*   http://nimfa.vniief.ru/khariton2021-content/Сборник_тезисов.pdf
*   стр. 49-50:
Особенности реализации теста HPCG для ППВС «БУРАН»
Д. Н. Змеев, Арк. В. Климов, А. С. Окунев, Н. Н. Левченко
*   стр. 59-60:
Детерминированное параллельное программирование и распределенные вычисления: 
процесс конвергенции
Анд. В. Климов, А. И. Адамович

Программа здесь тоже есть (хоть и с мелкими отличиями, но на 26-27 мая 
совпадает):

*   
http://nimfa.vniief.ru/khariton2021-content/Программа_конференции_ХНЧ_2021.pdf

Андрей Климов

 

 

On Tue, 25 May 2021 at 19:13, Arkady Klimov mailto:arkady.kli...@gmail.com> > wrote:

Завтра, в среду, 26.5, мы с Андреем выступаем с докладами на XXII Международной 
конференции Харитоновские Тематические Научные Чтения "Суперкомпьютерное 
моделирование и искусственный интеллект", которая проходит в регулярно в 
Сарове. Секция 2:

 

9.10 – 9.30 ДЕТЕРМИНИРОВАННОЕ ПАРАЛЛЕЛЬНОЕ ПРОГРАММИРОВАНИЕ И РАСПРЕДЕЛЕННЫЕ 
ВЫЧИСЛЕНИЯ: ПРОЦЕСС КОНВЕРГЕНЦИИ 
Климов А.В.1 , Адамович А.И.2 

1 Институт прикладной математики им. М.В. Келдыша РАН, Москва
2 Институт программных систем им. А.К. Айламазяна РАН, Переславль-Залесский

 

9.50 – 10.10 ОСОБЕННОСТИ РЕАЛИЗАЦИИ ТЕСТА HPCG ДЛЯ ППВС «БУРАН» 

Змеев Д.Н., Климов А.В., Окунев А.С., Левченко Н.Н. 

Институт проблем проектирования в микроэлектронике РАН, Москва  

В качестве аннотации (в оправдание за как бы оффтопик) скажу, что для меня наш 
язык UPL, в котором выражается представляемый алгоритм - это как бы "рефал в 
области супервычислений". Почему - требует отдельного разговора.

 

Вот ссылка гостевая для подключения (для секции 2):

https://conf.rosatom.ru/#join:t93916cdc-2656-45c6-a7a5-ede35e7b06d0

Там надо представиться (фамилия имя, организация), в графе "о себе" можно 
написать "гость".  

Полную программу можно посмотреть по ссылке:

https://www.sphti.ru/wp-content/uploads/2021/05/%D0%9F%D0%A0%D0%9E%D0%93%D0%A0%D0%90%D0%9C%D0%9C%D0%90-%D0%A5%D0%9D%D0%A7-2021.pdf

Поскольку время может сбиваться (в любую сторону), лучше войти заранее и 
следить по докладам.

 

С уважением,

Аркадий Климов

 

 

 

-- 
Вы получили это сообщение, поскольку подписаны на группу "Метавычисления и 
специализация программ".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, 
отправьте письмо на электронный адрес 
metacomputation-ru+unsubscr...@googlegroups.com 
 .
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке 
https://groups.google.com/d/msgid/metacomputation-ru/CAMZpZXns%2B_HJnhRpzsE6340p9oFsfcZPob5kmNEjtBMvSCky1Q%40mail.gmail.com
 

 .

-- 
Вы получили это сообщение, поскольку подписаны на группу "Метавычисления и 
специализация программ".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, 
отправьте письмо на электронный адрес 
metacomputation-ru+unsubscr...@googlegroups.com 
 .
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке 
https://groups.google.com/d/msgid/metacomputation-ru/CAM7HiMnajZmw-7Pc2n3N9mj5hPEeAmP54ktCXfynyrJAS%2Bvm0w%40mail.gmail.com
 

 .

RE: Re[4]: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Александр!

«Моя логика такова: использование персоналок будет однозначно сокращаться, а 
код, на них ориентированный, плохо переносится в другие перспективные нынче 
среды, такие как интернет-серверы, интернет-клиенты и различные гаджеты.»

Вероятно, Вы правы, нужно думать о поддержке серверного ПО.

Но у меня компилятор самоприменимый и разрабатывается на персональной машине, 
поэтому основной пользователь работает на персоналке. Также компилятор может 
собрать и запустить два суперкомпилятора, написанные на Рефале-5: SCP4 и 
MSCP-A, они тоже предназначены для запуска на персоналках в первую очередь.

Так что имеет смысл в первую очередь сделать собственную работу комфортной: 
оптимизировать компилятор для сборки себя.

 

«Хотя я, при отсутствии тестировщика (или хотя бы „ночной сборки“)»

Для начала достаточно организовать набор самопроверяющихся тестов. Т.е. папку, 
в которой лежит батник и исходники-тесты. Батник перебирает все файлы, каждый 
исходник собирает и запускает — файл должен без ошибок откомпилироваться и не 
упасть. В самом исходнике может быть проверка вроде (пишу для примера на 
Рефале-5, т.к. не знаю ваш синтаксис):

$ENTRY Go { = > }

Check { 4 = }

Программа перемножает 2 на 2 и сверяет результат с 4. Если результат работы 
будет чем-то другим, то функция Check упадёт с ошибкой невозможности 
отождествления. Так исходник будет сам себя проверять.

После этого время от времени запускать батник и убеждаться, что ничего не 
сломалось. Можно запускать или перед каждым коммитом, или после каких-то 
серьёзных изменений в коде.

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

В дальнейшем можно набор тестов расширить тестами на синтаксические ошибки — на 
них компилятор/интерпретатор не вылетает, а корректно сообщает об ошибке (и 
дальше не компилирует/не интерпретирует), и на намеренное падение (такие у меня 
тоже есть).

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

Вот так они у меня выглядят: refal-5-lambda/autotests at master · 
bmstu-iu9/refal-5-lambda (github.com) 
 .

Вот более простые и обозримые тесты в других моих проектах:
• refal-5-framework/tests/parser at master · Mazdaywik/refal-5-framework 
(github.com) 
 
• Refal-05/autotests at master · Mazdaywik/Refal-05 (github.com) 
  

Тесты не надо специально сидеть и сочинять. Начальный набор тестов насочинять, 
конечно, нужно, так, чтобы он охватывал основные возможности системы. А дальше 
тесты пишутся в двух случаях: ошибки и новая функциональность.

Выявили какую-то ошибку. Воспроизводим её. Тест для воспроизведения уменьшаем. 
Уменьшаем. Уменьшаем. Получается маленький автотест. Исправляем ошибку — новый 
автотест стал проходить. Коммитим его одновременно с исправлением ошибки. 
Появился ещё один автотест.

Хотим добавить новую функцию. Скажем, новую встроенную функцию или новую 
синтаксическую конструкцию. Пишем автотест, её проверяющий (один или 
несколько). Реализуем функциональность, чтобы автотест проходил. Коммитим 
одновременно новую функцию и автотест к ней. Появился ещё один автотест.

 

«сломал систему так, что уже месяц, наверное, не могу восстановить 
работоспособность»

Если бы были автотесты, можно было бы при помощи git bisect быстро найти 
коммит, который всё ломает.

 

Не исключаю, что автотесты Вы и без меня хорошо знаете, и уже давно их 
используете. Я пишу в рассылку, а в ней не все подписчики могут быть знакомы с 
этой полезной практикой.

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Thursday, May 20, 2021 11:32 AM
To: refal@botik.ru
Subject: Re[4]: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

 


Добрый день, Александр!

 

Мы перед собой видим совсем разные задачи. Локальный суперэффективный 
компилятор для персонального использования и серверный «монстр», 
ориентированный на работу через интернет. Моя логика такова: использование 
персоналок будет однозначно сокращаться, а код, на них ориентированный, плохо 
переносится в другие перспективные нынче среды, такие как интернет-серверы, 
интернет-клиенты и различные гаджеты. Это же касается и точек сопряжения с 
различными сетевыми сервисами — я не могу ограничиться С рантайм библиотекой. 

 

Всегда можно откатиться на более ранний коммит. И при сравнении можно 
сравнивать старый коммит с актуальным.

У меня в этом году два дипломника развивают компилятор: один переделывает 
оптимизацию прогонки, другой — оптимизацию специализации. Сначала я думал 
добавить для них дополнительные режимы работы, но отказался от этой идеи. И так 
у меня есть грёбаная куча режим

RE: Re[2]: В защиту ссылок в Рефале – Was: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Александр!

Эквивалентность меня интересует одна — равенство значений одноимённых 
переменных в образце. Т.е. какими свойствами должна обладать эта встроенная в 
язык проверка на равенство, чтобы не было логических противоречий. Есть две 
границы, за которые выходить нельзя. С одной стороны, копии всегда равны. С 
другой стороны, функции с разным поведением должны быть не равны. Последнее я 
пытался формализовать в слайде про фазы луны и в предыдущем письме. Но, похоже, 
я больше всё запутал, чем объяснил.

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Wednesday, May 19, 2021 11:57 AM
To: refal@botik.ru
Subject: Re[2]: В защиту ссылок в Рефале – Was: Рефал-семинар 17 мая 2021 в 
10:30 в Zoom'e

 

Доброе!

 

Я подозреваю, что тут мы оказываемся в пограничной зоне с ООП. Функция 
эквивалентности может быть определена для класса функции или класса объекта. 
Тогда всё просто. Иначе обобщение может превысить порог сложности для 
восприятия.

 

К случаю, я призываю без крайней необходимости не поднимать порог вхождения в 
программирование на Рефале. Он и так достаточно усложнился, а изначально 
простота и доступность понимания были важными «фишками» языка. Или явно делить 
аудиторию: «Рефал для чайников»  и «Рефал для яйцеголовых».

 

Относительно «чистоты» функции и побочных эффектов в общем случае про функцию 
ничего нельзя сказать. Однако, можно проводить некоторый автоматический анализ 
и выявлять функции с устойчивыми этими свойствами на момент выполнения (то есть 
делить их на те, про которые можно такое утверждать и те, про которые нельзя 
ничего утверждать). Это касается как раз вычислений без остановки 
интерпретатора — одна из трудностей, что в течении активности программы функции 
могут меняться, причём кардинально. Таким образом, оптимизация должна 
освежаться на момент каждой конкретизации. У меня эта проблема висит нерешённая.
 

Среда, 19 мая 2021, 11:14 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:
 

 

Написать, что если s.F и s.G равны, то ) ()> будет 
равно True нельзя, т.к. в Рефале функции могут быть нечистыми (представьте, что 
s.F ≡ s.G ≡ &Get, функция чтения файла, тогда два последовательных вызова 
прочитают две разные строчки). Поэтому в докладе пришлось привлекать 
астрономическое явление, а здесь говорить о взаимозаменяемости исходников.

 

 

С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

RE: Re[2]: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Александр!

«1. Описать и обсудить с сообществом строгую математическую модель ссылки: что 
это, какие возможны с ней действия и т.п.;»

На самом деле, про математическую модель ссылки подробно рассказывал Андрей 
Климов на нескольких предыдущих семинарах. Анонсы этих семинаров в рассылку не 
публиковались. Если Андрей Валентинович сочтёт нужным, он может дать ссылку на 
слайды тех докладов.

То, о чём я рассказывал на семинаре (решение № 1), отчасти вдохновлено 
семинарами Андрея Валентиновича.

 

«2. В соответствии с моделью расширить промежуточный язык;»

Расширение промежуточного языка описано в решении № 1:

$NEW : s.R

{{ s.R := &Func e.Content }}

Но это расширение в псевдокоде, синтаксисе для документирования. Во внутреннем 
синтаксисе скорее всего будет что-то вроде

t.Closure ::= (ClosureBrackets t.RefId ":=" e.Expression)
e.Result ::= (New t.RefId*) e.Expression
t.RefId ::= t.Variable

И дальше потребуется все компоненты компилятора, работающие с внутренним 
языком, использовать новое представление правых частей.

 

«3. Оставить в компиляторе возможность обрабатывать ссылки по-прежнему — 
опционально;
4. Добавить в оптимизацию отключаемую опцию обработки ссылок;»

А вот это не надо. В компиляторе и так уже слишком много режимов компиляции, 
чтобы добавлять ещё один.

 

«Такой подход не испортит того, что есть, пока идёт проработка и исследование 
новой возможности. И всегда можно сравнить подходы.»

Всегда можно откатиться на более ранний коммит. И при сравнении можно 
сравнивать старый коммит с актуальным.

У меня в этом году два дипломника развивают компилятор: один переделывает 
оптимизацию прогонки, другой — оптимизацию специализации. Сначала я думал 
добавить для них дополнительные режимы работы, но отказался от этой идеи. И так 
у меня есть грёбаная куча режимов. Для тестирования нужно проверять почти 
декартово произведение, т.к. некоторые ошибки вылезали только при комбинации 
режимов. Добавлять ещё два — это значит, увеличивать время работы тестов на 
2×2=4 раза, ибо декартово произведение. Поэтому я не стал добавлять режимы, 
решил, что для тестов производительности достаточно сравнивать текущий код с 
коммитом, помеченным тегом. 

Новая возможность, по идее, ничего не должна ломать. Единственный побочный 
эффект — экземпляры будут получать дополнительный бесполезный параметр, но 
оверхед на него, скорее всего, будет едва заметен.

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Wednesday, May 19, 2021 11:16 AM
To: refal@botik.ru
Subject: Re[2]: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

 

Добрый день!

 

Мне видится, что проблема успешно разбивается на последовательные части:

1.  Описать и обсудить с сообществом строгую математическую модель ссылки: 
что это, какие возможны с ней действия и т.п.;
2.  В соответствии с моделью расширить промежуточный язык;
3.  Оставить в компиляторе возможность обрабатывать ссылки по-прежнему — 
опционально;
4.  Добавить в оптимизацию отключаемую опцию обработки ссылок;


Такой подход не испортит того, что есть, пока идёт проработка и исследование 
новой возможности. И всегда можно сравнить подходы. Это как кнопка «Турбо» на 
старых персоналках. Машина работает быстрее, но не гарантирует работу всех 
программ.

Стоит отметить, что п.1 здесь самый ответственный, наверное. Потом 2. А 
остальное — дело техники.

Среда, 19 мая 2021, 10:52 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:
 

Добрый день всем!

Публикую слайды прошедшего семинара:

https://mazdaywik.github.io/direct-link/2021-05-17-Konovalov-Closures-and-Optimizations-Refal-5-lambda.pdf

Краткое содержание: я рассказал про Рефал-5λ, про оптимизации, реализованные в 
нём, привёл примеры того, что оптимизации реализуют неэквивалентные 
преобразования программ, рассмотрел два способа решения этой проблемы.

Доклад не только занял весь семинар, но и растянул семинар примерно на три 
часа. Поэтому обсудить, какой из двух рассмотренных способов лучше, мы не 
успели.

 

Проблема связана с тем, что замыкания — ссылочные данные, а оптимизации 
(прогонка и специализация, включая специализацию замыканий) умеют работать 
только с данными-значениями. Более того, промежуточный язык, в котором 
выполняются преобразования, не отражает того факта, что замыкания — ссылочные 
данные. В неоптимизированной программе это сходит с рук, а в оптимизированной 
возможны проблемы (в презентации приведены 4 разных примера).

Было предложено два пути решения:

*   расширить промежуточный язык поддержкой ссылочных типов, 
соответственно, усложнить оптимизации и генерацию кода,
*   отказаться от ссылочных типов вовсе, сделав замыкания типами-значениями 
— равенство будет проверяться не по ссылке, а по содержимому.

Оба варианта имеют свои преимущества и недостатки, ни один из них существенно 
не превосходит другой. Поэтому, как исправить проблему, я не знаю. В разные 
моменты времени я склоняюсь т

Язык реализации рантайма (было: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e)

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Александр!

«Бьёрн Страутструп упорно доказывал, что эффективность ++ не ниже, а иногда и 
выше, чем С на то время.»

Знаем эти басни. Эффективность достигается объёмом кода и временем компиляции. 
Функция qsort() языка Си принимает указатель на функцию сравнения и для каждого 
сравнения осуществляется косвенный доступ. Функция std::sort() может быть 
проспециализирована компаратором во время выполнения — на каждый компаратор 
будет построен свой экземпляр функции std::sort().

Объём экзешника clang++.exe около 50 Мбайт. 50 миллионов байт. Интересно, 
сколько среди этого кода написано вручную, а сколько развернулось из 
инстанцирований всяких std::vector’ов? Для сравнения дистрибутив Windows 95 
занимал сравнимый объём. Дистрибутив неплохой для своего времени операционной 
системы.

 

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

Я решил проблему так: в самом компиляторе не используется ничего, кроме 
стандартной библиотеки языка и стандартных API операционной системы. Я 
поддерживаю Windows, Linux и macOS. Правда, есть некоторые проблемы на запуске 
Linux’а десятилетней давности. На Windows я по умолчанию собираю проект 
компилятором C++ 20-летней давности (быстро компилирует). 

 

«Зато разработчики обещают полную совместимость кода на целом ряде платформ.»

Включая Windows XP?

Вообще, мне бы хотелось, чтобы Рефал-5λ мог бы работать даже на Windows 98. Но, 
к сожалению, в актуальной версии дистрибутива используются bat’ники для cmd.exe 
и на Windows 98 они не запустятся. А переписывать на батники для command.com я 
считаю нецелесообразным.

 

«Насчёт golang: автоматизация работы с памятью касается прежде всего 
полбъектного malloc , для цепочек никто не мешает организовать выделение 
большими блоками и оптимизировать самому.»

Проблема не только в этом. Как на счёт union? Go я знаю довольно поверхностно, 
но объединений в нём вроде нет.

Возможно я не прав, но я слышал, что в Go очень высокий оверхед на вызов сишных 
функций. Что как минимум, обращение к системным вызовам в нём дороже, чем из Си.

 

«Для меня главным свойством при выборе была возможность лёгкого подключения к 
проекту всех современных технологий, даже ещё не существующих.»

У меня не было такой цели. У меня есть более близкая цель: Рефал с интерфейсом 
к языку Си. Чтобы можно было писать свои библиотеки на Си и загружать их из 
кода Рефала. Цель более-менее достигнута, но имеющийся интерфейс меня 
категорически не устраивает, его надо серьёзно перепроектировать. Ну и заодно 
переписывать рантайм.

 

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

Меня больше интересуют домашние машины, причём не самые свежие и 
производительные. Например, на стареньком нетбуке компилятор раскручивает себя 
за 2 минуты и это много. Одна из причин — неудачная система команд байткода, 
гораздо хуже байткода Романенко. Её надо перепроектировать. Ну и заодно 
переписывать рантайм.

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Tuesday, May 18, 2021 11:56 PM
To: Александр Коновалов ; refal 
Subject: Re: RE: RE: RE: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

 

Александр,

 

Конечно я признаю С очень ясным с точки зрения оптимизации и компактности кода. 
Опыт был около 10 лет программирования на нём весьма нагруженных систем.

 

Относительно С++ могу сказать, что его автор, Бьёрн Страутструп упорно 
доказывал, что эффективность ++ не ниже, а иногда и выше, чем С на то время. 
Беда в современных шаблонах и библиотеках. К слову, мне на этом языке не 
удалось сделать чего-нибудь значимого.

 

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

 

Насчёт golang: автоматизация работы с памятью касается прежде всего 
полбъектного malloc , для цепочек никто не мешает организовать выделение 
большими блоками и оптимизировать самому. Зато разработчики обещают полную 
совместимость кода на целом ряде платформ. Без «танцев с бубном».

 

При выборе базового языка я рассматривал также node.js. Который нынче тоже 
весьма шустрый и компилируемый. Для меня главным свойством при выборе была 
возможность лёгкого подключения к проекту всех современных технологий, даже ещё 
не существующих.

 

Производительность же современных серверных платформ весьма высока, что в 
большинстве случаев позволяет снизить критичность оптимизации и скорости 
выполнения задач. Но это моё мнение на данный момент.

 



Отправлено из мобильной Почты Mail.ru



вторник, 18 мая 2021 г., 17:53 +0300 от Александр Коновал

RE: В защиту ссылок в Рефале – Was: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Андрей и Александр!

Андрей описал «нижнюю границу» для отношения эквивалентности: копии одного 
значения должны быть равны между собой.

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

f == g  →  ∀x . f(x) == g(x)
∃x . f(x) ≠ g(x)  →  f ≠ g

 

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

Пусть у нас есть два исходника:

/* F1.ref */

$ENTRY F {
  s.F s.G e.Arg,  : True = ;
  s.F s.G e.Arg = "!=";
}

Eq {
  t.X t.X = True;
 t.Y t.Z = False;
}

/* F2.ref */

$ENTRY F {
  s.F s.G e.Arg,  : True = ;
  s.F s.G e.Arg = "!=";
}

Eq {
  t.X t.X = True;
 t.Y t.Z = False;
}

В первом исходнике F1.ref, если первые два символа аргумента равны, вызывается 
первый символ как функция. Во втором F2.ref — второй символ. Отличия между 
исходниками выделено красным цветом.

При правильной реализации равенства должен быть верен инвариант: в любой 
программе, которая использует исходник F1.ref, его можно заменить на F2.ref (и 
наоборот) и поведение программы не изменится. Т.е. если s.F и s.G равны (могут 
сопоставиться с одноимёнными переменными), то функции, реализуемые ими, должны 
быть идентичны: в одинаковой среде при одинаковых аргументах должны возвращать 
одинаковый результат и иметь одинаковый побочный эффект, либо обе 
зацикливаться, либо обе завершаться аварийно.

Написать, что если s.F и s.G равны, то ) ()> будет 
равно True нельзя, т.к. в Рефале функции могут быть нечистыми (представьте, что 
s.F ≡ s.G ≡ &Get, функция чтения файла, тогда два последовательных вызова 
прочитают две разные строчки). Поэтому в докладе пришлось привлекать 
астрономическое явление, а здесь говорить о взаимозаменяемости исходников.

 

Поэтому такие простые отношения «равенства», как все замыкания равны друг другу 
и все замыкания не равны друг другу, выходят за рамки этих граничных условий. 
Если все замыкания друг другу не равны, значит копии будут не равны друг другу. 
Если все замыкания друг другу равны, то равны окажутся различные функции.

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Tuesday, May 18, 2021 11:24 PM
To: refal 
Subject: Re: В защиту ссылок в Рефале – Was: Рефал-семинар 17 мая 2021 в 10:30 
в Zoom'e

 

Спасибо, Андрей!

Всё замечательно выражено. Действительно, если даны правильные определения, 
дискутировать становится подчас не о чем.

Я, конечно, подразумевал именно адресные ссылки, которые наблюдал в языках 
высокого уровня и остался ими недоволен. А вот математически описанные Вами 
ссылки - это отлично, проходит!

 



Отправлено из мобильной Почты Mail.ru



вторник, 18 мая 2021 г., 23:01 +0300 от refal mailto:refal@botik.ru> >:

После семинара между двумя Александрами (Гусевым и Коноваловым) возникла 
переписка с ограничеснной рассылкой только тем, кто был на семинаре. Я захотел 
встрять и посылаю письмо в refal@botik c надеждой, что это обсуждение будет 
интересно всем. Также я указал в BCC тех, кто был на семинаре, но на нашу 
рассылку не подписан, и еще некоторых коллег.

 

Оба Александра выразили свою нелюбовь к понятию ссылки как к кандидату к 
включению в область данных Рефала. А я выступлю в защиту этого понятия, в том 
числе с математической точки зрения. 

 

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

 

From: Александр Гусев mailto:gusev_aleksa...@mail.ru> 
> 
Sent: Monday, May 17, 2021 11:17 PM

Лично я - противник использования ссылок в Рефале. Оставьте их языкам близким к 
машинному уровню. Здесь же «ссылка» должна быть просто отсылкой к функции или 
объекту, но не адресом. Даже если в низкоуровневой основе это и адрес. Это как 
использование goto в императивных языках понижает качество кода. Goto - это для 
низкоуровневого кода, ассемблера и естественно присутствует в любой программе, 
но на машинном уровне.

On Tue, 18 May 2021 at 14:53, Александр Коновалов mailto:a.v.konovalo...@mail.ru> > wrote:

В общем-то я тоже. Поэтому в компиляторе до сих пор нет ссылочных типов данных 
вроде динамических ящиков. Единственные ссылочные данные, которые есть — это 
замыкания и они иммутабельны. В Рефале-2, Рефале Плюс и Рефале-6 мутабельные 
ссылочные данные есть.

Давайте сразу договоримся, что ни о каких адресах речи не идет. Рефал – язык 
высокого уровня, и его (достаточно простая) семантика должна быть 
сформулирована в терминах абстрактного вычислителя. Ссылки – это понятие 
высокого уровня.

 

Ссылки вызывают у нас протест, на мой взгляд, только потому, что они в

RE: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

Публикую слайды прошедшего семинара:

https://mazdaywik.github.io/direct-link/2021-05-17-Konovalov-Closures-and-Optimizations-Refal-5-lambda.pdf

Краткое содержание: я рассказал про Рефал-5λ, про оптимизации, реализованные в 
нём, привёл примеры того, что оптимизации реализуют неэквивалентные 
преобразования программ, рассмотрел два способа решения этой проблемы.

Доклад не только занял весь семинар, но и растянул семинар примерно на три 
часа. Поэтому обсудить, какой из двух рассмотренных способов лучше, мы не 
успели.

 

Проблема связана с тем, что замыкания — ссылочные данные, а оптимизации 
(прогонка и специализация, включая специализацию замыканий) умеют работать 
только с данными-значениями. Более того, промежуточный язык, в котором 
выполняются преобразования, не отражает того факта, что замыкания — ссылочные 
данные. В неоптимизированной программе это сходит с рук, а в оптимизированной 
возможны проблемы (в презентации приведены 4 разных примера).

Было предложено два пути решения:

*   расширить промежуточный язык поддержкой ссылочных типов, 
соответственно, усложнить оптимизации и генерацию кода,
*   отказаться от ссылочных типов вовсе, сделав замыкания типами-значениями 
— равенство будет проверяться не по ссылке, а по содержимому.

Оба варианта имеют свои преимущества и недостатки, ни один из них существенно 
не превосходит другой. Поэтому, как исправить проблему, я не знаю. В разные 
моменты времени я склоняюсь то к одному, то к другому решению.

 

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

 

From: Andrei Klimov andrei_AT_klimov.net  
Sent: Sunday, May 16, 2021 11:06 PM
To: refal@botik.ru
Subject: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

 

Добрый вечер!

В понедельник 17 мая 2020 в 10:30 часов соберемся на онлайн-семинар по Рефалу:

*  Александр Коновалов (МГТУ имени Н.Э. Баумана)
Проблемы ссылочной эквивалентности замыканий при эквивалентных преобразованиях 
программ в Рефале-5λ

Zoom-сеанс:

 

  
https://us02web.zoom.us/j/86888134690?pwd=ZTlnUWQvSUVPN3RVUk1UdU8rZjB6Zz09

Meeting ID: 868 8813 4690
Passcode: Yaq97A 

Аннотация:


Диалект Рефал-5λ является расширением Рефала-5 безымянными функциями. Внутри 
безымянных функций можно ссылаться на переменные, связанные вне её. Для 
безымянной функции во время выполнения программы создается объект замыкания, 
содержащий указатель на код данной функции и значения захваченных переменных. 
Эти объекты с точки зрения языка являются символами (сопоставляются с 
s-переменными) и сравниваются на равенство по ссылке.

Пример программы с замыканиями:

 

Map {
  s.Func t.Next e.Rest =  ;
  s.Func /* пусто */  = /* пусто */;
}

$ENTRY CartProd {
  (e.Xs) (e.Ys)
=  } e.Xs>
}

Переменные, захваченные замыканиями, подчеркнуты.

Компилятор Рефала-5λ поддерживает две оптимизации: специализации и прогонки 
функций. Оптимизация специализации для специально помеченных функций создает 
специализированные экземпляры функций, учитывающие информацию о вызове, 
известную во время компиляции. В частности, для обоих вызовов Map в функции 
CartProd будут строиться экземпляры, учитывающие тот факт, что аргументами 
являются конкретные замыкания:

 

$ENTRY CartProd {
  (e.Xs) (e.Ys) = mailto:Map@1%20(e.Ys) e.Xs> @1 (e.Ys) e.Xs>;
}

Map@1 {
 (e.Ys) t.Next e.Rest = <{ t.X = mailto:Map@2 t.X e.Ys> @2 t.X e.Ys> } 
t.Next> mailto:Map@1%20(e.Ys) e.Rest> @1 (e.Ys) e.Rest>;
  (e.Ys) /* пусто */ = /* пусто */;
}

Map@2 {
  t.X t.Next e.Rest = <{ t.Y = (t.X t.Y) } t.Next> mailto:Map@2 t.X 
e.Rest> @2 t.X e.Rest>;
  t.X /* пусто */ = /* пусто */;
}

Оптимизация прогонки встраивает функции в точки их вызова. Это преобразование 
программ было описано Турчиным (для подмножества Рефала) в 1972 (тезисы 
конференции Киев-Алушта) и в 1974 (сборник ЦНИПИАС) годах. В рассмотренном 
примере оптимизация прогонки встроит вызовы вложенных функций:

 

$ENTRY CartProd {
  (e.Xs) (e.Ys) = mailto:Map@1%20(e.Ys) e.Xs> @1 (e.Ys) e.Xs>;
}

Map@1 {
 (e.Ys) t.Next e.Rest = mailto:Map@2 t.Next e.Ys> @2 t.Next e.Ys> mailto:Map@1%20(e.Ys) e.Rest> @1 (e.Ys) e.Rest>;
  (e.Ys) /* пусто */ = /* пусто */;
}

Map@2 {
  t.X t.Next e.Rest = (t.X t.Next) mailto:Map@2 t.X e.Rest> @2 t.X 
e.Rest>;
  t.X /* пусто */ = /* пусто */;
}

В текущей реализации эти две оптимизации хорошо работают только с 
данными-значениями — преобразования программы остаются эквивалентными. 
Замыкания являются ссылочными данными и можно написать пример программы, где 
эквивалентность преобразований нарушается.

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

 

До Zoom-встречи!

 

Андрей Климов

RE: О разделении логики и дизайна

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Николай!

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

А чем неудобна?

 

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

 

From: nikolai.kondratiev_AT_gmail.com  
Sent: Sunday, March 28, 2021 11:42 PM
To: refal@botik.ru
Subject: AW: О разделении логики и дизайна

 

Николай Кондратьев высказал следующий тезис (возможно прочитанный в каком-то 
труде, а может сам красиво сформулировал – помнит ли он сейчас?):

Надо тщательно различать логику и дизайн языка программирования. Плохо, когда 
они путаются и решения принимаются то в пользу одного, то другого (типичная 
ситуация в комитетах по стандартизации языков). 

Андрей, спасибо, что вспомнил. Я этого не помню, хотя это утверждение мне 
близко.

Когда я писал компилятор в язык сборки, то обнаружил, что непрозрачность блоков 
для неуспехов неудобна для реализации. А кроме того, мне пришла в голову мысль, 
что после результата замены можно поставить двоеточие и продолжить цепочку. В 
общем что-то похожее на то, что реализовал Аркадий в РЕФАЛЕ 6.

Я обсуждал это с Турчиным по телефону, но ему это не понравилось.

После некоторых размышления я пришел к выводу, что Рефал-5 очень хорошо 
сбалансирован. В нем нет избыточных конструкций и осталось то, что делает Рефал 
рефалом.

По поводу регулярных выражений в Рефале.

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

 

Например, когда мы используем Рефал для синтаксического анализа, то ясно, что 
это не очень эффективно, поскольку тратится два-три вызова функций, на одну 
литеру входного текста.

По-видимому обогнать по скорости конечный автомат, а следовательно Lex/Yacc 
очень трудно.

 

Интеграция Рефала с Явой могла бы сильно помочь.

К сожалению я в свое время не нашел хорошую реализацию Lex/Yacc на Яве. Они 
есть, но похоже с ошибками.

 

Но есть на C# - это пакет NuGet под названием YaccLexTools.

 

У меня есть желание написать компилятор Рефал-C# так, чтобы можно было бы 
интегрировать вместе Рефал, C# и Lex/Yacc.

 

Так можно объединить три технологии, каждая из которых возможно лучшая в своем 
классе.

 

Вот так вот как-то.

 

Николай

 

Von: Andrei Klimov andrei_AT_klimov.net mailto:refal@botik.ru> 
> 
Gesendet: Sonntag, 28. März 2021 21:12
An: refal  @botik.ru
Betreff: О разделении логики и дизайна

 

[Сменил сабж, так как "Остапа понесло".]

 

On Sun, Mar 28, 2021 at 8:31 PM Александр Коновалов  
 a.v.konovalov87_AT_mail.ru < 
 refal@botik.ru> wrote:

Добрый вечер, Андрей!

 

В Рефале-5 запятая для откатов прозрачна. Не прозрачны для откатов только 
фигурные скобки — блоки после двоеточия и сами вызовы функций. Поэтому 
результатное выражение после запятой неуспеха породить не может (по 
определению), а образец после двоеточия — запросто.

 

Синтаксис «, выражение : образец» в Рефале-5 есть и он называется 
«where-конструкция». Синтаксис «, выражение : {…}» называется 
with-конструкцией. Они упоминались не только в учебнике, но и в главах 
обнинской школы метавычислений — там вместо запятой используются ключевые слова 
where и with соответственно.

 

Спасибо! Буду иметь в виду. Значит, в нашем разговоре Турчин имел в виду 
первое, а я не до конца ухватил и перенес на второе тоже. Значит, логика такая: 

*   «{...}» – это подставленное тело функции, 
*   «, выражение :» – это синтаксис для ее вызова, 
*   «, выражение : образец ...» – это отдельная конструкция со своей 
семантикой, отличающейся от  «, выражение : { образец ...}». 

В свое «оправдение» могу только сказать, что не люблю такой неортогональный 
синтаксис и такую тонкую семантику: откаты вроде бы и есть, а вроде бы их и 
нет. Скобки вроде бы лишь «объединитель» (как в школьной математике), а вроде 
бы и нет. Поэтому и подумал, что Турчин был просто против откатов.

 

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

*   Формальный язык (будь то язык математики, логики, или язык 
программирования) должен быть максимально «ортогонализован»: базовые 
семантические единицы явно выражены, а более высокие конструкции собираться из 
них. Это обычно называется композиционностью. Такое требование особенно 
применимо к метаязыку, предназначенному для описания, конструирования других 
языков. (Если сам не композиционен, что можешь предложить другим?)

Но вы (как многие) спросите: А как же быть с удобствами программирования? Мы же 
знаем по опыту разных языков, ч

RE: О разделении логики и дизайна

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

«В свое „оправдание“ могу только сказать, что не люблю такой неортогональный 
синтаксис и такую тонкую семантику: откаты вроде бы и есть, а вроде бы их и 
нет.»

Я бы не назвал такой синтаксис неортогональным. Здесь важно понять логику языка.

Рефал-5 является относительно консервативным расширением базисного Рефала. 
Семантика определяется через понятие поля зрения, в котором активный вызов по 
очереди заменяется на некоторое выражение. И эту семантику Турчин 
последовательно блюдёт. 

В Рефале-5 предложения состоят из левой и правой части: если сопоставление с 
левой частью успешно, то управление безальтернативно передаётся на правую 
часть. Левая часть состоит из образца и нуля и более условий. Правая часть 
может быть либо выражением, либо вызовом безымянной функции. Если сопоставление 
с такой расширенной левой частью успешно, то активный вызов заменяется на 
результат вычисления правой части. Таким образом, предложение в общем виде 
выглядит так:

P where R1 : P1 where R2 : P2 = R;
P where R1 : P1 where R2 : P2 with R : { … };

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

ИМХО, недостаток дизайна языка в том, что Турчин для where- и with-конструкций 
выбрал один и тот же знак — запятую. Это и усложняет синтаксический разбор 
(прочитав «, выражение», не знаешь — это продолжается левая часть или уже 
началась правая). Этот недостаток дизайна был исправлен в некоторых потомках: в 
Рефале-7 Скоробогатова   
используются знаки «−>» и «=>» (хотя, на самом деле Рефал-7 построен на основе 
Рефала-6, а не Рефала-5), в Рефале-5λ рекомендуется вместо запятой использовать 
знак равенства, хотя запятая из соображений совместимости тоже поддерживается.

Впрочем, у Турчина равенство в роли with-знака использоваться не может исходя 
именно из логики. Равенство означает факт замены вызова функции в поле зрения 
на результат вычислений, но эта замена выполняется не когда вызывается 
вложенная функция, а когда она завершается. Для реализации вызовов вложенных 
функций у Турчина опять привлекается вспомогательное поле зрения, но это уже, 
ИМХО, артефакт реализации.

 

Разделение логики и дизайна у меня вызвало ассоциации с реализацией Рефала-5λ. 
Компилятор сначала переводит 

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

На сколько я знаю, примерно также официально определяется семантика ML.

 

«Напомню, что идею такой системы еще с 90-х пропагандирует Сергей Абрамов и 
инициировал такой рефал-проект, который, к сожалению, пребывает в замороженном 
состоянии (его участники, напомните web-ссылку)).»

Если речь идёт об универсальном абстрактном синтаксическом дереве, в которое 
нужно компилировать разные диалекты Рефалов, то web-ссылка умерла. Описание 
этого синтаксиса было на wiki, которую админы botik.ru отключили.

 

«Кстати, о сравнении Рефала Плюс Сергея Романенко с Рутеном Гуриным и Рефала-6 
в версии Аркадия.»

Всё же я склоняюсь к тому, что замкнутость относительно суперкомпиляции была 
одной из целей разработки Рефала Плюс. Важным понятием при трансформациях 
являются присваивания (S :: He R) и перестройки (S : Snt), поэтому звенья вида 
«выражение+образец» должны быть базовыми понятиями языка. Образцы в начале 
предложений и последние источники в них тоже в некотором смысле являются 
звеньями «выражение+образец»: для образцов в начале неявной левой частью звена 
оказывается аргумент функции [ARG] : Pat, для последних источников неявной 
правой частью — результат функции S :: [RES].

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

Рефал Плюс можно транслировать в Рефал-6, Рефал-6 можно транслировать в Рефал 
Плюс. Если транслировать Рефал Плюс в Рефал-6, то звенья «выражение+образец» 
будут парой отдельных действий — результатного и образцового. Если 
транслировать Рефал-6 в Рефал Плюс, то наоборот действия нужно будет неявно 
переводить в такие звенья.

 

С Днём Победы всех! Мирного неба над головой!

 

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

 

From: Andrei Klimov andrei_AT_klimov.net  
Sent: Sunday, March 28, 2021 10:12 PM
To: 

RE: Регулярные выражения слева

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Андрей!

В Рефале-5 запятая для откатов прозрачна. Не прозрачны для откатов только 
фигурные скобки — блоки после двоеточия и сами вызовы функций. Поэтому 
результатное выражение после запятой неуспеха породить не может (по 
определению), а образец после двоеточия — запросто.

Синтаксис «, выражение : образец» в Рефале-5 есть и он называется 
«where-конструкция». Синтаксис «, выражение : {…}» называется 
with-конструкцией. Они упоминались не только в учебнике, но и в главах 
обнинской школы метавычислений — там вместо запятой используются ключевые слова 
where и with соответственно.


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



От: Andrei Klimov andrei_AT_klimov.net
Отправлено: 28 марта 2021 г. в 16:47
Кому: refal@botik.ru
Тема: Re: Регулярные выражения слева

On Sat, Mar 27, 2021 at 11:47 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
 wrote:
[...]
 
Вариативность (но с ущербом для эффективности) можно реализовать и в Рефале-5. 
Код, эквивалентный коду Рефала-6, будет выглядеть так:
 
F {
  e.Name 〈что-то ещё〉,  : T = … ;
  … = …;
}

F-Name {
'Маша' = T;
'Саша' = T;
e.Other = F;
}

А разве такое в Рефале-5 можно? С 90-х годов я рефал-плюсовый программист, мог 
и забыть. А сейчас лень заглядывать в руководство, да и, думаю, будет полезно 
обсудить здесь логики разных Рефалов, из которых вытекают различные решения по 
синтаксису. Помнится, подобные вопросы мы специально обсуждали в те годы, и у 
меня отложилось, что:

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

2. Синтаксиса вида "выражение : образец" в Рефале-5 нет. Помнится, при 
обсуждении расширений Рефала Плюс по сравнению с Рефалом-5, Турчин говорил, что 
в Рефале-5 двоеточие означает вызов подставленного тела вспомогательной функции 
и только это. Поэтому, даже если в ней только одно предложение, всё равно надо 
ставить фигурные скобки, чтобы выглядело одинаково с определением функции. То 
есть данный код синтаксически правильно надо писать так (а семантика будет 
другая, чем хотелось):

F {
  e.Name 〈что-то ещё〉,  : { T = … };
  … = …;
}  

И уж нечего и говорить, что фигурные скобки в Рефале-5 безоткатные.

Правильно я помню Рефал-5 и его логику?

Андрей

Re: Refal6-basic

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Аркадий!

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

С размещением исходников на GitHub готов помочь и Аркадию, и Николаю, если 
интересно. Пишите в личку, чтобы не засорять рассылку частными вопросами.


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



From: Arkady Klimov arkady.klimov_AT_gmail.com 
Sent: Saturday, March 27, 2021 9:10 PM
To: refal@botik.ru 
Subject: Re: Refal6-basic

  "Данный суперкомпилятор умел повышать местность функций и распознавал 
«параметры-призраки» — параметры, при передаче значений в которые не нужно 
инкрементировать счётчики ссылок."


Хочу уточнить, чтобы не было недоразумений, что "полусуперкомпилятор" из Рефала 
в С состоял из двух отдельных частей: собственно (полу)суперкомпилятор, 
написанный Н.Кондратьевым, вырабатывающий граф конфигураций, и отображение 
графа в С, mapping, как назвал его Турчин еще в 70х гг., которое было 
"поручено" сделать мне. Повышение местности производил первый компонент, а 
"призраки", actual/ghost variables (это термин Турчина) возникали уже при 
отображении, на уровне графа они еще не имеют смысла. На самом деле, и в 
mapping-е это работа была недоделана: этот аспект еще как-то проработан в 
пределах одной C-функции (образа одной конфигурации), при том, что все входные 
параметры-выражения конфигураций считались actual. Хотелось иметь глобальную 
оптимизацию этой разметки, было понятно как, и я даже статью про это написал, 
когда был у Турчина (в 1990м), и под его "пинками", но ее тогда не приняли, там 
куда я ее послал, и на этом все закончилось.
Ох, сейчас хотелось бы все это реанимировать, но нужно время, силы... К 
большому сожалению сопроводительные отчеты по маппингу утрачены (они делались в 
CHI-writer, бумажные копии передавались через посредника в ИПС, который за эту 
работу платил, мои же копии потерялись). Сохранились только коды на рефале, 
надеюсь работоспособные. Там был введен и использовался некий промежуточный 
символьный язык - РАМАЛ (как бы "Refal Assembler Mapping Language").
Аналог языка сборки, но бесстековый, для прямой трансляции в С.


Что касается кода самого рефала, то да, рефал-6 это модификация рефала-6b, 
кодов общих много, даже названия файлов старые. Небольшие модификации поначалу 
были мотивированы тем, чтобы сделать более удобным включение новых отображенных 
функций. А потом, видимо, я вошел во вкус, и меня "понесло".
Кстати и рефал6 хотелось бы выложить в github с исходниками, но опять недосуг, 
а как сделать быстро и правильно, я пока не разбираюсь.
Надо, конечно, найти время, и еще хотя бы на такое же "описание реализации".
Коля, а что это за файл такой большой там на 150 МБ, по ссылке под "Studio 
Community 2019 solution", файл refal6.zip. У меня после загрузки он выглядит 
пустым. Судя по названию и размеру, это, вероятно, сборка проекта (-ов) под MS 
Visual Studio со всеми исходниками и (промежуточными) результатами.


Аркадий

сб, 27 мар. 2021 г. в 01:38, nikolai.kondratiev_AT_gmail.com :

  Спасибо за замечания!



  OPEN исправлю.

  Имена в system.ref не остаются в таблице имен, насколько я помню, поэтому 
чистить не обязательно, правда память не освобождается.

  В dinload.ref может быть было опасно оставлять определения функций кроме LOAD 
и DELETE.



  Должен заметить, что эти тексты программ были написаны в 1988 году и я не все 
помню.

  Я не писал диссертации, связанной с Рефалом и не работал в ИПМ.



  >Стало быть, когда-то была реализация Рефала-6, гораздо более близкая к 
Рефалу-5, чем нынешняя реализация Аркадия Климова

  > (которая приобрела ряд черт Рефала Плюс и некоторых своих, уникальных черт).

  >Ваши исходники позволяют получить представление о том, как эта реализация 
могла выглядеть.

  Это, собственно, она и есть. Изменения с тех пор незначительны.



  Я не использовал исходных текстов предыдущих реализаций, но использовал язык 
сборки Романенко-Турчина и теоремы об удлинениях Сергея Романенко (не все). 
Тогдашняя реализация Рефала-5 не использовала теоремы об удлинениях. На 
каких-то примерах Рефал-6 сильно выигрывал.



  Von: Александр Коновалов  
  Gesendet: Freitag, 26. März 2021 22:41
  An: nikolai.kondrat...@gmail.com
  Betreff: Re: Refal6-basic



  Добрый вечер, Николай Викторович!



  «Все замечания приветствуются»



  В функции OPEN не поддерживается режим 'a'. В функции rb_open() допускаются 
только «r» и «w» в обоих регистрах.



  В файле dinload.ref не чистится функция Resort в Null. В system.ref вообще 
ничего не чистится.





  Андрей Валентинович рассказывал, что в ИПМ кто-то писал диссертацию про 
проверку типов Рефала с использованием регулярных выражений, а потом уехал в 
Германию. Это не Вы были?





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





  From: nikolai.kondratiev_AT_gmail.com 

  Sent: Friday, March 26, 2021 3:22 PM

  To: refal@botik.ru 

  Cc: 'Andrei Klimov' 

  Subject: Refal6-basic



  Уважаемые коллеги!



  После того, к

Re: Refal6-basic

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Андрей!

А Рутен подписан на эту рассылку? Просто у меня есть свои идеи на этот счёт, 
интересно было бы с ним обсудить.

Идея в том, каким должно быть подмножество КС-грамматик, на котором описываются 
типы в программах на Рефале. Это подмножество замкнуто относительно операции 
над множествами и конкатенации и может сопоставляться с образцами Рефала. 
Реализацию (хотя бы частично) дал на диплом студенту, посмотрим, что получится.

А Рутен этим занимался 30 лет назад, и наверняка продвинулся дальше, чем я. 
Проблема изобретения велосипедов не только в том, что повторно тратишь время на 
то, что уже есть, а ещё и в том, что велосипеды получаются с квадратными 
колёсами.


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



From: Andrei Klimov andrei_AT_klimov.net 
Sent: Saturday, March 27, 2021 8:59 PM
To: refal@botik.ru 
Subject: Re: Refal6-basic

  Von: Александр Коновалов  
  Gesendet: Freitag, 26. März 2021 22:41
  An: nikolai.kondrat...@gmail.com
  Betreff: Re: Refal6-basic

  [...] 

  Андрей Валентинович рассказывал, что в ИПМ кто-то писал диссертацию про 
проверку типов Рефала с использованием регулярных выражений, а потом уехал в 
Германию. Это не Вы были?


Это был Рутен Гурин. Сейчас он в Италии. В 1980е годы он был аспирант ВМиК и у 
него была уже написана диссертация  на эту тему, когда начались бурные процессы 
в обществе и наших душах, и как-то получилось, что работа не была доведена до 
защиты. Возможная причина помимо внешних обстоятельств, как я чувствую теперь 
(а Рутен может не согласиться), – в том, что это была весьма пионерская работа. 
Мода на soft typing и gradual typing появилась намного позже. А пионерам трудно 
психологически: нет реакции общества, не понятна актуальность, может казаться, 
что это "ерунда", коль этим никто не занимается, а может оценить лишь узкий 
круг друзей. Когда делаешь улучшение в решении уже хорошо поставленной задачи, 
намного легче и самому двигаться вперед, и диссовету проголосовать за. А тогда 
многое в CS только начиналось. Время от времени в памяти всплывают примеры, 
когда мы что-то изобретали в мире ФП на Рефале, обсуждали в своем узком кругу, 
радовались как красивому трюку, а потом, лет через 10-20, читали в зарубежных 
статьях как о ключевых идеях. Подозреваю (но пусть Рутен меня опровергнет), что 
с этой работой получилось что-то то похожее: изобрел, отпрототипировал, написал 
кирпич, но сам не оценил настолько, чтобы хватило энергии заниматься 
оставшимися бюрократическими делами по проводке через дисс-совет на фоне 
соблазнов другой работы с хорошими условиями для себя и семьи. А времена были 
такие, что будущее было в тумане...

Такая жизнь...

Андрей Климов

Re: AW: Refal6-basic

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Николай!

Архив нужно создавать с исключением файлов *.ipch и *.db. Они пересоздаются 
Visual Studio автоматически и занимают очень много места. Команда для архивации 
тогда будет такой:-

Gnuwin32\zip -r ..\..\Refal6b.zip ..\..\Refal6b -x *.ipch -x *.db

Архив будет иметь разумный объём.


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



From: nikolai.kondratiev_AT_gmail.com 
Sent: Saturday, March 27, 2021 10:58 PM
To: refal@botik.ru 
Subject: AW: Refal6-basic

„Коля, а что это за файл такой большой там на 150 МБ, по ссылке под "Studio 
Community 2019 solution", файл refal6.zip. У меня после загрузки он выглядит 
пустым. Судя по названию и размеру, это, вероятно, сборка проекта (-ов) под MS 
Visual Studio со всеми исходниками и (промежуточными) результатами.“

 

Да, именно. Но я его создавал Gnuwin32\zip -r ..\..\Refal6b.zip ..\..\Refal6b и 
zip прописал два раза путь "..", там все должно быть.

Сейчас исправил.

 

Von: Arkady Klimov arkady.klimov_AT_gmail.com  
Gesendet: Samstag, 27. März 2021 19:11
An: refal@botik.ru
Betreff: Re: Refal6-basic

 

  "Данный суперкомпилятор умел повышать местность функций и распознавал 
«параметры-призраки» — параметры, при передаче значений в которые не нужно 
инкрементировать счётчики ссылок."

 

Хочу уточнить, чтобы не было недоразумений, что "полусуперкомпилятор" из Рефала 
в С состоял из двух отдельных частей: собственно (полу)суперкомпилятор, 
написанный Н.Кондратьевым, вырабатывающий граф конфигураций, и отображение 
графа в С, mapping, как назвал его Турчин еще в 70х гг., которое было 
"поручено" сделать мне. Повышение местности производил первый компонент, а 
"призраки", actual/ghost variables (это термин Турчина) возникали уже при 
отображении, на уровне графа они еще не имеют смысла. На самом деле, и в 
mapping-е это работа была недоделана: этот аспект еще как-то проработан в 
пределах одной C-функции (образа одной конфигурации), при том, что все входные 
параметры-выражения конфигураций считались actual. Хотелось иметь глобальную 
оптимизацию этой разметки, было понятно как, и я даже статью про это написал, 
когда был у Турчина (в 1990м), и под его "пинками", но ее тогда не приняли, там 
куда я ее послал, и на этом все закончилось.

Ох, сейчас хотелось бы все это реанимировать, но нужно время, силы... К 
большому сожалению сопроводительные отчеты по маппингу утрачены (они делались в 
CHI-writer, бумажные копии передавались через посредника в ИПС, который за эту 
работу платил, мои же копии потерялись). Сохранились только коды на рефале, 
надеюсь работоспособные. Там был введен и использовался некий промежуточный 
символьный язык - РАМАЛ (как бы "Refal Assembler Mapping Language").

Аналог языка сборки, но бесстековый, для прямой трансляции в С.

 

Что касается кода самого рефала, то да, рефал-6 это модификация рефала-6b, 
кодов общих много, даже названия файлов старые. Небольшие модификации поначалу 
были мотивированы тем, чтобы сделать более удобным включение новых отображенных 
функций. А потом, видимо, я вошел во вкус, и меня "понесло".

Кстати и рефал6 хотелось бы выложить в github с исходниками, но опять недосуг, 
а как сделать быстро и правильно, я пока не разбираюсь.

Надо, конечно, найти время, и еще хотя бы на такое же "описание реализации".

Коля, а что это за файл такой большой там на 150 МБ, по ссылке под "Studio 
Community 2019 solution", файл refal6.zip. У меня после загрузки он выглядит 
пустым. Судя по названию и размеру, это, вероятно, сборка проекта (-ов) под MS 
Visual Studio со всеми исходниками и (промежуточными) результатами.

 

Аркадий

 

сб, 27 мар. 2021 г. в 01:38, nikolai.kondratiev_AT_gmail.com :

  Спасибо за замечания!

   

  OPEN исправлю.

  Имена в system.ref не остаются в таблице имен, насколько я помню, поэтому 
чистить не обязательно, правда память не освобождается.

  В dinload.ref может быть было опасно оставлять определения функций кроме LOAD 
и DELETE.

   

  Должен заметить, что эти тексты программ были написаны в 1988 году и я не все 
помню.

  Я не писал диссертации, связанной с Рефалом и не работал в ИПМ.

   

  >Стало быть, когда-то была реализация Рефала-6, гораздо более близкая к 
Рефалу-5, чем нынешняя реализация Аркадия Климова

  > (которая приобрела ряд черт Рефала Плюс и некоторых своих, уникальных черт).

  >Ваши исходники позволяют получить представление о том, как эта реализация 
могла выглядеть.

  Это, собственно, она и есть. Изменения с тех пор незначительны.

   

  Я не использовал исходных текстов предыдущих реализаций, но использовал язык 
сборки Романенко-Турчина и теоремы об удлинениях Сергея Романенко (не все). 
Тогдашняя реализация Рефала-5 не использовала теоремы об удлинениях. На 
каких-то примерах Рефал-6 сильно выигрывал.

   

  Von: Александр Коновалов  
  Gesendet: Freitag, 26. März 2021 22:41
  An: nikolai.kondrat...@gmail.com
  Betreff: Re: Refal6-basic

   

  Добрый вечер, Николай Викторович!

   

  «Все замечания приветствуются»

   

  В функции OPEN не поддерживается режим

Re: Регулярные выражения слева

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Александр!

«Возможным решением вижу использование функций без побочных эффектов в левой 
части. Помню упоминание о такой возможности где-то в препринтах Турчина.»

Да, это было у Турчина в «пятитомнике» препринтов о языке Рефал. Переменные, 
сопоставление с которыми приводит к вызову функции, там назывались 
«рекурсивными». Они ни разу не были реализованы, на сколько мне известно.

Одной из наиболее распространённых потребностей в рекурсивных переменных была 
потребность в ограничении множества значений термов, сопоставимых с переменной. 
Например, «эта s-переменная может сопоставиться только с буквой», «эта 
e-переменная может сопоставиться только с последовательностью цифр», «эта 
s-переменная не может быть равна символу 'ERR'», «эта v-переменная (непустая 
e-переменная) состоит только из макроцифр» и т.д. Данную задачу успешно решали 
спецификаторы, появившиеся в Рефале-2.

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

Рефал-6 (не Рефал-6b, о котором недавно писал Николай, а тот, который развил и 
поддерживает Аркадий Климов) содержит понятия «действия» и «неуспехи». В письме 
я рассказывать про них не буду, отошлю к документации, которая достаточно 
прозрачна. В Рефале-6 есть возможность выразить и связку «или» (как блок с 
несколькими предложениями), и связку «и» (как несколько условий), и связку «не» 
(есть отрицания действий), и скобки (усиления и ослабления неуспехов).

Вариативность в левой части образца в Рефале-6 можно выразить следующим образом:

F {
  e.Name 〈что-то ещё〉, e.Name { 'Маша' = ; 'Саша' = } = … ;
  … = …;
};

Если в синтаксисе что-то напутал, Аркадий Валентинович может поправить.

Аналогичная функциональность есть и в Рефале Плюс, но только там синтаксис и 
семантика сложнее. Одной из целей Рефала Плюс было написание языка, который был 
бы замкнут относительно суперкомпиляции полного Рефала (возможно даже, это была 
основная цель). Но результат суперкомпиляции выражается не в виде программы на 
Рефале, а в виде графа суперкомпиляции, существенно более низкоуровневой 
конструкции. Поэтому диалект Рефал Плюс обладает рядом низкоуровневых средств 
вроде функций с несколькими аргументами и результатами (полные покрывающие 
функции в это прокрустово ложе не ложатся) с ограничениями на их использование 
(несоответствие формату вызывает ошибку компиляции), тонкими средствами 
управления потоком выполнения — заборами, отсечениями, прозрачными и 
непрозрачными блоками и прочим. В общем, то, что оптимизирующий компилятор в 
идеале должен делать неявно, программист в Рефале Плюс может прописать явно. 
Рефал-6 гораздо более высокоуровневый язык, он допускает программирование как в 
низкоуровневом стиле Рефала Плюс, так и в высокоуровневом стиле Рефала-5. И его 
понять гораздо проще. Я сам сначала разобрался в Рефале-6, а потом в Рефале 
Плюс.

Вариативность (но с ущербом для эффективности) можно реализовать и в Рефале-5. 
Код, эквивалентный коду Рефала-6, будет выглядеть так:

F {
  e.Name 〈что-то ещё〉,  : T = … ;
  … = …;
}

F-Name {
'Маша' = T;
'Саша' = T;
e.Other = F;
}

В Рефале-5λ тоже самое можно записать компактнее за счёт синтаксического сахара:

F {
  e.Name 〈что-то ещё〉
, e.Name
: {
'Маша' = T;
'Саша' = T;
e._ = F;
  }
: T
= … ;

  … = …;
}


Теперь возвращаюсь к тому «одному диалекту». Это диалект Refal-D, предложенный 
Маратом Шамильевичем Исламовым. Он отчасти наследует от Рефала-5 (условия 
остались, блоки выкинуты), однако в языке был существенно расширен синтаксис 
правых частей. Множества значений переменных в нём можно задавать фактически 
при помощи грамматик, заданных в БНФ. В частности, пример с Машей-Сашей на нём 
можно записать так:

F {
  { 'Маша' | 'Саша' }.Name 〈что-то ещё〉 = … ;
  … = …;
}

Доступна презентация об этом языке:

http://freeschool.altlinux.ru/wp-content/uploads/2010/02/islamov_presentation.pdf

Есть описание диалекта в рефал-сборнике:

http://refal.botik.ru/library/refal2015_issue-II.pdf

Есть репозиторий исходных текстов:

https://github.com/mislamov/refal51

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


А вообще, для данной конкретной задачи можно написать так:

F {
  e.Name 〈что-то ещё〉, ('Маша') ('Саша') : e.1 (e.Name) e.2 = … ;
  … = …;
}

Если писать в базисном Рефале, без условий, то так:

F {
  e.Name 〈что-то ещё〉 =  ;
  … = …;
}

F1 {
  e.1 (e.Name) e.2 (e.Name 〈что-то ещё〉) = …;
  … = …;
}

Имя для функции F1, на мой вкус, плохое, но в зависимости от задачи можно 
подобрать и более подходящее имя.


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


From: Александр Гусевgusev_ale

Re: Refal6-basic

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Николай Викторович!

Вот и всплыл в интернете ещё один фрагмент мозаики в истории Рефала.

На сайте refal.ru есть такие слова Аркадия Климова:
В середине 80-х В. Турчиным предложен язык Рефал-5, который содержит Базисный 
рефал в качестве подмножества. Расширения языка Рефал-5 качественно меняют 
стиль программирования, поэтому можно говорить о нем как о новом поколении 
языка. В настоящее время существует две реализации языка Рефал-5: одна 
выполнена Д. Турчиным, другая - Н. Кондратьевым и Арк. Климовым. Обе имеют 
практически один и тот же входной язык, но отличаются рядом особенностей 
реализации. Вторая известна также под названием Рефал-6, однако следует 
помнить, что это название не языка, а его реализации.

Параллельно, С. Романенко разработал язык Рефал Плюс, основанный в принципе на 
тех же расширениях, что и Рефал-5, но доведенный до концептуальной полноты. В 
нем основным можно назвать расширение рефала средствами обработки неуспехов. 
Впоследствии ряд нововведений Рефала Плюс в несколько пересмотренном виде был 
перенесен Арк.Климовым в реализацию Рефала-6. В настоящее время (1999) 
продолжается работа по унификации входных языков Рефал Плюс и Рефал-6.

Отсюда: http://refal.ru/intro-ref.htm. Выделение моё.

Стало быть, когда-то была реализация Рефала-6, гораздо более близкая к 
Рефалу-5, чем нынешняя реализация Аркадия Климова (которая приобрела ряд черт 
Рефала Плюс и некоторых своих, уникальных черт). Ваши исходники позволяют 
получить представление о том, как эта реализация могла выглядеть.

Судя по исходникам, в ней ещё не было «действий» Рефала-6, опирающихся на 
понятие неуспеха, а были классические условия и блоки — в исходных текстах 
компилятора используются только они. Хотя файл tsyn.ref уже демонстрирует 
поддержку «результатных блоков». Однако, точно сказать, какие расширения 
синтаксиса поддерживаются в Refal-6b, я сказать не могу, т.к. не разбирал 
исходники на столько подробно.

В документации к Рефалу-6 Аркадий писал, что вся поддержка модульности 
(загрузки и выгрузки модулей) реализована кодом на Рефале, поддержки со стороны 
рантайма нет. Изучая загрузчики Рефала-6b, (refal.dynldr и refal.sys), я понял, 
в чём там хитрость.


Аркадий Валентинович мне как-то рассказывал, что в 90-е годы был написан 
суперкомпилятор Рефала-6 в Си (он называл его «полусуперкомпилятором», на 
сколько я помню), и у Аркадия Валентиновича есть его исходники. Данный 
суперкомпилятор умел повышать местность функций и распознавал 
«параметры-призраки» — параметры, при передаче значений в которые не нужно 
инкрементировать счётчики ссылок. Сейчас это называется «заимствованием» 
(borrowing) и применяется в таких языках как Rust и Lobster (memory management 
in Lobster). Интересно было бы проверить этот суперкомпилятор на Рефале-6b и 
для Рефала-6b.


Интересно сравнить исходные тексты Рефалов-6(b), Рефала-5 PZ и FLAC. Есть ли 
между какими-то из них точные заимствования фрагментов? А также сравнить 
Рефал-6 и Refal-6b, сколько кода там наоборот различается и сколько сохранилось 
общего. Как-нибудь сравню и напишу в рассылку.


Спасибо!
Александр Коновалов


From: nikolai.kondratiev_AT_gmail.com 
Sent: Friday, March 26, 2021 3:22 PM
To: refal@botik.ru 
Cc: 'Andrei Klimov' 
Subject: Refal6-basic

Уважаемые коллеги!

 

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

 

Поскольку на мой взгляд реализация достаточно устойчива, я решил сделать ее 
доступной для Рефал-сообщества.

 

Вся документация на русском языке.

 

Тексты программ должны быть в ASCII.

 

Рефал-6b находится на моем домашнем компьютере, который доступен по ссылке:

http://nkon04.ddns.net/refal6b/

 

Реализация состоит из файлов:

refal (refal.exe для Windows)

refal.sys

refal.comp

refal.dynldr

refal.tracer

 

Все они должны находиться в одном каталоге файловой системы.

Это либо каталог Windows,

Либо /usr/local/bin/ под Linux

 

Все замечания приветствуются.

 

Успехов.

 

Николай Кондратьев

Re: Изобретение велосипеда

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Андрей Валентинович!

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


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


From: Andrei Klimov andrei_AT_klimov.net 
Sent: Friday, March 12, 2021 1:05 PM
To: refal@botik.ru 
Subject: Re: Изобретение велосипеда

On Fri, Mar 12, 2021 at 12:25 PM Sergei M. Abramov abram_AT_botik.ru 
 wrote:

  > Знаки < и > Турчин стал использовать уже в Америке, там их ему на
  > конференции предложил МакКарти.

  Что-то мне запомнилось, что это был Бэкус.  И понятно почему именно
  Бэкус.  Есть связь между граматиками и Рефалом


Да, мне тоже запомнилось, что Турчин говорил про Бэкуса. И помнится, что 
зафиксировал в памяти по такому же мнемоническому правилу, как сказал Сергей 
Михайлович. Хотя я сам слышал из уст ВФ, но память может и изменить, и, может, 
то, что вам, Александр, сказал Андрей Петрович и правда. Про то, что это было 
на какой-то конференции, в разговоре со мной не звучало, и я тогда подумал, что 
это было в частном обсуждении. Но вполне возможно, что это было на какой-то 
конференции, воркшопе или семинаре.

С МакКарти у Турчина тоже были контакты. Помню его рассказ о другой истории. 
МакКарти как-то рекомендовал Турчина в какой-то авторитетный комитет и очень 
удивился, когда ВФ отказался (не хотелось отвлекаться от работы). ВФ привел мне 
этот сюжет из его жизни в США как пример того, как он не понимал, что принимать 
такие приглашения нужно для его "адаптации", вхождения в американскую научную 
среду. Тамошние профессора заседают в таких органах, чтобы "тусоваться" и 
наводить связи (это мой пересказ по смыслу, а не цитата Турчина); американцы 
такой возможности никогда не упустят. МакКарти считал, что оказывает Турчину 
большую услугу, "проталкивая" его в этот орган, и специально звонил Турчину, 
уточняя, правда ли, что он отказывается и понял ли, о чем речь. 

Всего наилучшего,
Андрей Климов


  С уважением,

  Абрамов С.М.
  ab...@botik.ru
  мобильный: +7(903)2928308

Re: Изобретение велосипеда

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Сергей Михайлович!

Про знаки < и > мне рассказал Андрей Петрович Немытых и он упоминал 
МакКарти. Цитирую переписку:


Я: «Рефал-4 был предложен Романенко в 1987 году, когда Турчин уже 
обосновался в Америке и даже написал «The Concept of a Supercompiler». 
Кстати, в этой статье он уже использует угловые скобки (вместо k и .).»


А.П.: «Угловые скобки появились в Рефале после разговора Турчина с Маккарти 
(автором Лиспа) на одной из конференций. Собственно Маккрати и предложил 
Турчину использовать угловые скобки в качестве конструктора вызова функций.»



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


-Исходное сообщение- 
From: Sergei M. Abramovabram_AT_botik.ru

Sent: Friday, March 12, 2021 12:25 PM
To: Александр Коновалов a.v.konovalov87_AT_mail.ru
Subject: Re: Изобретение велосипеда


Знаки < и > Турчин стал использовать уже в Америке, там их ему на
конференции предложил МакКарти.


Что-то мне запомнилось, что это был Бэкус.  И понятно почему именно
Бэкус.  Есть связь между граматиками и Рефалом

С уважением,

Абрамов С.М.
ab...@botik.ru
мобильный: +7(903)2928308

Re: Re[2]: Изобретение велосипеда

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Александр!

«Что касается блоков и, соответственно, области видимости переменных, то блоки 
я как раз пока что не принял. Мне кажется, что они сильно усложняют чтение и 
понимание чужих программ.»

Многое зависит от форматирования кода. Я встречал программы с блоками и 
условиями, которые из-за форматирования разбирать трудно — приходится буквально 
распутывать структуру кода. И встречал программы, где, напротив, код читается 
легко, т.к. структура из-за форматирования очевидна.

Синтаксис Рефала-2 в этом смысле лучше — её сложнее запутать кривым 
форматированием. Синтаксис языка ограничивает возможности запутать. Первое 
предложение функции должно начинаться с имени функции, остальные — с пробела. 
Длинные предложения разбиваются явным знаком переноса «+» в конце строки. Так 
что всё равно поймёшь, где предложение начинается, а где кончается. К тому же 
из-за коротких имён переменных сами предложения зачастую оказываются короткими.


«Вообще синтаксической выделение авторекурсии возникло при копировании функций. 
Если функция сложная, требуются некоторые дополнительные усилия, чтобы 
„вытравить“ из неё использование своего же имени во избежание 
трудновылавливаемых ошибок.»

Я подумывал о ключевом слове $REC в связи с необходимостью переименования 
функции при рефакторинге. Но потом освоил Vim, в котором удобно аккуратно 
переименовывать все вхождения имени (последовательность нажатий клавиш: 
*cwНовоеИмяn.n.n.n). К тому же Vim умеет автодополнять имена в исходном 
файле на любом языке программирования, в том числе и на Рефале. Благодаря 
автодополнению вводить одно и то же имя в нескольких рекурсивных вызовах 
становится довольно просто.

Теперь я начинаю понимать потребность и смысл кавер-функций и авторекурсии. 
Предметная область Вашего диалекта Рефала подразумевает написание шаблонного 
кода — когда новый код часто строится путём копирования стандартного шаблона и 
внесения в него изменений, характерных для задачи. Реализация не поддерживает 
средства, позволяющие вынести общую логику в библиотеку/фреймворк, либо хотя бы 
разнести функции по разным пространствам имён (в противном случае можно было 
скопировать файл, локальные функции переименовывать не потребовалось бы, 
достаточно переименовать entry-функции). И тогда роль группировки различных 
функций в одну сущность берёт на себя сама функция — отдельные функции 
отображаются в группы предложений-клозы, а для вызова самой себя используется 
синтаксический сахар.

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

Я предпочитаю избегать копирование кода. Если нужно напечатать две похожие 
строчки, то я лучше напечатаю вторую строчку вручную, чем скопирую и поправлю. 
По своему опыту, когда я копирую кусок кода, то позже обнаруживаю ошибку, 
которая оказывается в обеих копиях и обе приходится править.


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



From: Александр Гусевgusev_aleksandr_AT_mail.ru 
Sent: Friday, March 12, 2021 10:52 AM
To: refal@botik.ru 
Subject: Re[2]: Изобретение велосипеда

Добрый день, Александр!

Спасибо за реакцию.

По моему мнению важным аспектом развития языка является лёгкость вхождения и 
достаточная лёгкость чтения чужих программ. Поэтому я активно интересуюсь 
такими вроде незначительными деталями реализации как внешний вид программы и 
форматирование её текста.

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

Я понимаю под вложенными функциями то же самое.
Что касается блоков и, соответственно, области видимости переменных, то блоки я 
как раз пока что не принял. Мне кажется, что они сильно усложняют чтение и 
понимание чужих программ. Мой прежний практический опыт использования Рефала 
был основан на Рефале-2 на БЭСМ-6 как раз со старой нотацией скобок и 
отсутствием блоков. Эти программы легко читались несмотря на несколько 
архаичный по теперешним меркам ситаксис. Это прямо как по старо-славянски 
читать. Но понятно притом. ))

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

Предлагаемая реализация (т.е. клозы внутри нормальной кавер-функции) позволяет 
выполнить ещё одну оптимизацию поиска вариантов при выполнении функции. И при 
этом не производится никаких дополнительных изменений (усложнений) в синтаксисе.

Что касается формата скобок при авторекурсии, то я рассматривал разные 
варианты, начиная со специального имени $SELF и, конечно, с разными символами. 
И смотрел, наскольк

Re: Изобретение велосипеда

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Александр!

«Читая как-то информацию о Рефале в сети, наткнулся на упоминание отсутствия 
вложенных функций как недостатка языка.»

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

Вариант с клозами реализует только первые два свойства. Классический Рефал-5 
содержит блоки — конструкции вида

, Res
: {
Sent;
Sent;
Sent;
  }

Их вполне можно считать вложенными функциями, хоть они и вызываются только один 
раз. Они действительно синтаксически находятся внутри другой функции, 
недоступны извне и, главное, в них доступны связанные снаружи переменные.

Max {
  s.X s.Y
, 
: {
'−' s.d = s.Y;
s.d = s.X;
  };
}

Вложенные функции как функции высших порядков предложены Сергеем Скоробогатовым 
в Рефале-7:

Скоробогатов С. Ю., Чеповский А. М. Разработка нового диалекта языка Refal // 
Информационные технологии. 2006. 9. C. 31-38.
https://bmstu-iu9.github.io/Skorobogatov-Refal-7.pdf

Ограниченная поддержка вложенных функций высшего порядка есть в Рефале-5λ — 
доступны только безымянные вложенные функции.


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

На самом деле всё наоборот. Если почитать первый препринт Турчина о Рефале:

Программирование на языке рефал. I. Неформальное введение в программирование на 
языке рефал. (keldysh.ru)

то можно узнать следующее. Изначально, программа на Рефале была просто набором 
предложений, а функциональные скобки (скобки конкретизации) были «безымянными». 
Левая обозначалась к, правая — . (точка). (Знаки < и > Турчин стал использовать 
уже в Америке, там их ему на конференции предложил МакКарти.)

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

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


«„Авторекурсия“ — это вызов функцией самой себя, синтаксически выделяемой как 
„<<“ вместо „<имя_функции“. Никаких других „вольностей“ в синтаксисе тут нет.»

На мой вкус, знак «<< …>» неудачный. Глаз привыкает, что знаки < и > являются 
парными скобками и всегда должны быть сбалансированы, их число должно быть 
одинаково. Я бы предпочёл какой-нибудь другой, выделяющийся знак для этой цели, 
например «<@ …>». Сам я когда-то подумывал о слове $REC для аналогичной цели, 
но сначала поленился, а потом забил — будет потерян один удобный приём отладки 
(см. здесь пример отладки DoFib).


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



From: Александр Гусевgusev_aleksandr_AT_mail.ru 
Sent: Thursday, March 11, 2021 1:52 PM
To: refal@botik.ru 
Subject: Изобретение велосипеда

Добрый день, коллеги!

Поделюсь мыслью, показавшейся мне интересной.

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

Позволил себе поупражняться в изобретении наименований, если что-то уже было 
сделано на этот счёт до меня, но я не знаю об этом.
«Авторекурсия» — это вызов функцией самой себя, синтаксически выделяемой как 
«<<» вместо «<имя_функции». Никаких других «вольностей» в синтаксисе тут нет.

Отрывок:
При комбинации авторекурсии и идентификаторов добавляется удобное качество: 
локальные подфункции внутри одной функции, именуемые клозами.

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

RE: 90-летие Валентина Федоровича Турчина (14.2.1931–7.4.2010)

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро всем!

«Такую сессию можно организовать совместно с ежегодным Рефал-семинаром (если 
Александр Коновалов и другие организаторы семинара не будут возражать).»

Совместные семинары я ни разу не организовывал, не знаю как это делается. 

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

Семинар PSSV международный, это значит, что студентам пришлось бы и слайды 
делать на английском, и быть готовым перейти на английский, если к конференции 
подключится иностранец. Боюсь, не все студенты достаточно хорошо владеют 
английским, и поэтому не хочется студентов лишний раз отвлекать от подготовки 
диплома.

Так что, наверное, не стоит совмещать бауманский-ИПСовский неформальный семинар 
и PSSV.

Соорганизатором семинара по Рефалу являются Андрей Петрович Немытых и Антонина 
Николаевна Непейвода. Так что нужно и их мнение тоже.

 

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

 

From: 'Shilov Nikolay' via Метавычисления и специализация программ 
[mailto:metacomputation...@googlegroups.com] 
Sent: Tuesday, February 16, 2021 11:24 AM
To: Andrei Klimov 
Cc: metacomputation-ru ; refal@botik.ru
Subject: Re: 90-летие Валентина Федоровича Турчина (14.2.1931–7.4.2010)

 

Андрей Валентинович,

 

В этом году — много памятных дат. Вот, например, группа учеников (и учеников 
учеников Б.А. Трахтенброта) в предстоящую субботу 20 февраля (в День Рождения 
Бориса Абрамовича) проводи однодневный онлайн семинар, посвященный его 
100-летию, в следующую субботу 27 февраля Владимир Анатольевич Захаров проводит 
семинар, посвященный 90-летию Риммы Ивановны Подловченко, 19 апреля в 
Новосибирске пройдут две Ершовские лекции, посвященные 90-летию Андрея 
Петровича…

 

У меня вопрос-предложение: может быть, Вы (как член Программного Комитета 
предстоящей PSSV-2021) организуете специальную сессию на PSSV-2021 по 
метавычислениям, суперкомпиляции и т.д. с одним приглашенным докладом, 2-3 
отобранными докладами (из поданных на PSSV-2021) и мемориальным докладом о 
Валентине Федоровиче? — Такую сессию можно организовать совместно с ежегодным 
Рефал-семинаром (если Александр Коновалов и другие организаторы семинара не 
будут возражать).

 

PSSV-2021 пока не объявлена, но, по-видимому, она пройдет в Москве (в ИСП, ВШЭ 
или ВМК МГУ) в 10-ых числах июня (между между школой и конференцией Logic 
Perspective http://lp2020.mi-ras.ru/ перенесенной на 2021), но предварительно 
на PSSV02021 предварительно запланирована одна специальная сессия, посвященная 
работам Отдела технологий программирования ИСП РАН (приглашенный докладчик — 
А.К. Петренко).

 

Николай Вячеславович Шилов

 

Понедельник, 15 февраля 2021, 2:37 +03:00 от Andrei Klimov mailto:and...@klimov.net> >:
 

Дорогие друзья!

Исполнилось 90 лет со дня рождения Валентина Федоровича Турчина.

Он мог бы дожить до этого возраста с сохранением ясности ума, как бывает у 
творческих людей. Но и за свои годы он сделал так много и с таким заглядыванием 
в будущее, что нам еще осваивать и осваивать его наследие. Надо издавать и 
переиздавать его труды. Это еще за нами, его учениками.

Только представить, что к 40 годам он уже успел покинуть теорфизику, защитив 
докторскую, создать язык Рефал и собрать группу молодых рефальщиков, развить 
новую эволюционную концепцию метасистемного перехода и написать о ней книгу 
"Феномен науки"! Верность представленным в ней философским взглядам и своему 
мировоззрению привела его к общественной и правозащитной деятельности.

А дальше было создание и развитие суперкомпиляции, как крупномасштабного 
метасистемного перехода над алгоритмами и программами, причем не только ее 
базового уровня, который к нынешним временам уже "обсосан" в работах 
последователей, а и предложил по крайней мере два круга идей, как совершить 
второй метасистемный переход от вычислений к метавычислениям (для спецов 
отмечу, что имею в виду окрестностный анализ и исчисление грамматик путей). 
Концепция МСП показывает, что метасистемные переходы не являются чудом и "не 
ходят по одному", и совершив один, сразу ищи, как сделать следующий. Вот такую 
установку он нам дал своим примером!

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

И следующим таким результатом стали новые конструктивные основания математики, 
названные им Cybernetic Foundation of Mathematics. Эта революционная работа еще 
совсем не освоена научным сообществом (в отличие от суперкомпиляции). А она 
должна быть удивительна для того большинства математиков, кто из теорем о 
неразрешимости вывел (на основе работ 1950-60-х годов), что конструктивное 
понятие математических объектов, мно

RE: Конференция МЭС - 2020

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Аркадий!

Недостаток этой схемы генерации идентификаторов: они всё равно будут 
относительно длинными, чем при использовании обычной сквозной нумерации.

Но есть и преимущества. Во-первых, функции будут чистыми, а значит, будут 
максимально распараллеливаться. Во-вторых, назначение идентификаторов будет 
детерминированным — на одних и тех же входных данных будет один и тот же 
результат. В-третьих, зная схему генерации идентификаторов, можно при чтении 
вывода понять, каким блоком кода тот или иной идентификатор сгенерён, это ценно 
при отладке.

Можно придумать и другие чистые схемы генерации идентификаторов, например, 
строки-идентификаторы при выводе сжимать алгоритмом вроде RLE: последовательные 
одинаковые буквы (например, ZZ) заменять на указание буквы и числа 
повторений (Zx6). Тогда, если исходный алгоритм порождал длинные цепочки 
одинаковых букв, в результате идентификаторы станут не такими длинными.

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Thursday, February 4, 2021 3:31 PM
To: refal@botik.ru
Subject: Re: Конференция МЭС - 2020

 

Александр, добрый день!

Очень интересная идея, спасибо! 

Мне она не приходила в голову.

Аркадий

 

чт, 4 февр. 2021 г. в 11:23, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Доброе утро, Аркадий!

«Есть и другой вариант — использовать модель стека в форме слова в некотором 
алфавите. Мощность алфавита должна быть не меньше наибольшего числа 
„параллельных“ (рекурсивных) вызовов в рамках одной функции. Слово-стек легко 
кодировать целым числом, только длина его в битах будет расти линейно с 
глубиной рекурсии. Как-то так.»

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

Вы тогда заметили, что на практике широко распространены «почти чистые» функции 
— функции, которые могли быть чистыми, но используют единственную 
недетерминированную функцию — генератор «свежих» имён/индексов. Например, если 
программа является компилятором и ей нужно порождать в ассемблерном листинге 
имена для меток.

Такую программу можно сделать чистой следующим образом. Функции, которым нужны 
свежие индексы, должны будут принимать число, номер очередного индекса, и 
возвращать число. Но тогда между по смыслу независимыми вызовами возникнет 
зависимость по данным и эти вызовы перестанут быть «параллельными».

Я об этом думал, и тоже пришёл к предложенной Вами схеме: индексом сделать 
строку в некотором алфавите и наращивать её разными символами при передаче в 
разные дочерние вызовы:

F {
  …
  … (e.ID) … = …  …  …;
  …
}

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

F {
  …
  … (e.ID) … = …  … ) …> …;
  …
}

Inc {
  e.Str '0' = e.Str '1';
 e.Str '1' =  '0';
  e.Str = e.Str '0';
}

Для нескольких рекурсивных вызовов в правой части циклический можно назначить 
либо произвольно, либо с учётом алгоритма — тот, по которому рекурсия ожидается 
глубже. В качестве эвристики можно различать хвостовые и нехвостовые вызовы.

 

«…вся память „ассоциативная“, или „content-addressаble“.»

Вопрос только в производительности этой памяти и скорости обмена с ней.

 

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

 

 

From: Arkady Klimov arkady.klimov_AT_gmail.com 
  [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, February 2, 2021 8:32 PM
To: refal@botik.  ru
Subject: Re: Конференция МЭС - 2020

 

Александр, добрый день!

Тоже извиняюсь за задержку, затерялось Ваше письмо.

Вопрос хороший, я постоянно (время от времени) подумываю насчет реализации 
Рефала в этой модели. Да, видимо тут нельзя предложить какой-то общей 
интерпретации индексов. В обычных задачах у нас индексы имеют содержательный 
прикладной смысл. Здесь же, видимо, это будет, как в обычных реализациях рефала 
и функц. языков, некий "свежий указатель", разница лишь в том, что тут не нужна 
какая-то память, с ним связанная, просто в силу того, что вся память 
"ассоциативная", или "content-addressаble". И если в обычных системах для 
порождения "свежего указателя" мы используем реальный пул свободных ячеек с 
адресами, то здесь нужны только сами "адреса". А для их порождения (и 
освобождения) можно вполне использовать такой же реальный пул ячеек (звеньев), 
размер которых должен быть достат

RE: «Problems’ Day» Wed 30.12.2020 9:00 in Zoom - New Year's Eve meeting of the CS&SE Interlaboratory Seminar Novosibirsk + Innopolis + ...

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Андрей!

По-моему, можно с теми же слайдами рассказывать то же самое без спешки как 
минимум 20-30 минут. Вы, по-моему, один или два слайда не успели тогда 
рассказать.

 

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

 

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru] 
Sent: Thursday, February 4, 2021 1:05 PM
To: metacomputation-ru 
Cc: refal@botik.ru
Subject: Re: «Problems’ Day» Wed 30.12.2020 9:00 in Zoom - New Year's Eve 
meeting of the CS&SE Interlaboratory Seminar Novosibirsk + Innopolis + ...

 

Александр, спасибо! 

 

Хорошая идея. Но такой расширенный доклад надо ещё подготовить. Спасибо, ваше 
предложение подталкивает меня...

 

Всего наилучшего, 

Андрей Климов 

 

чт, 4 февр. 2021 г., 12:58 'Александр Коновалов' via Метавычисления и 
специализация программ mailto:metacomputation...@googlegroups.com> >:

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

Ваш доклад оказался очень интересным, но по времени втиснуть его с трудом 
удалось. Планируете ли Вы когда-нибудь прочитать расширенную версию этого 
доклада, т.е. длиннее 15 минут? Я думаю, он был бы интересен не только мне 
одному.

 

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

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru 
 ] 
Sent: Wednesday, December 30, 2020 8:54 AM
To: metacomputation-ru mailto:metacomputation...@googlegroups.com> >; refal@botik.ru 
 
Subject: Re: «Problems’ Day» Wed 30.12.2020 9:00 in Zoom - New Year's Eve 
meeting of the CS&SE Interlaboratory Seminar Novosibirsk + Innopolis + ...

 

Доброе утро!

 

За 10 мин до доклада pdf-файл презентации был обновлен по тому же адресу:

*   https://drive.google.com/file/d/169tJh6oMxIaZPMTpv-wMJuUNVRWbrFUt/

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

 

Андрей Климов

 

 

On Wed, Dec 30, 2020 at 12:24 AM Andrei Klimov mailto:and...@klimov.net> > wrote:

Добрый вечер всем!

 

Я делаю доклад на этом семинаре (информация внизу) с такой темой (приведу 
по-русски и по-английски):

*   Андрей Климов, Институт прикладной математики им. М.В. Келдыша РАН, 
Москва
*   Фундаментальные не(до)решенные проблемы Computer Science & Software 
Engineering (субъективный взгляд)
*   Проблема осознается лишь после того, как найдены первые решения и... 
понято, что это не есть решения. С этой точки зрения глянем на каждую из 
следующих давно стоящих фундаментальных проблем CS&SE. Отбор проблем 
субъективен, а порядок лишь для удобства презентации: 

1.  детерминированные параллельные вычисления; 
2.  семантика имен, ссылок; 
3.  метавычисления; 
4.  верификация программ; 
5.  математические основания вычислений и языков; 6) слияние функциональных 
и объектно-ориентированных языков программирования. 

*   Andrei Klimov, Keldysh Institute of Applied Mathematics of Russian 
Academy of Sciences, Moscow
*   Fundamental Un(der)resolved Problems of CS&SE (a subjective view)
*   A problem is recognized only after the first solutions have been found 
and... it is understood that these are non-solutions. From this point of view, 
let's take a quick look at each of the following long standing fundamental 
problems of CS&SE. The selection of the problems is subjective, and the order 
is only for the convenience of presentation:

1.  deterministic parallel computation; 
2.  semantics of names and references; 
3.  metacomputation; 
4.  program verification; 
5.  mathematical foundations of computation and languages; 
6.  merging functional and object-oriented programming languages. 

По условиям организаторов презентация должна быть на английском, а говорить 
можно по-русски (что я и сделаю). Презентация лежит здесь:

*   https://drive.google.com/file/d/169tJh6oMxIaZPMTpv-wMJuUNVRWbrFUt/

Презентация получилась длинная – 10 емких слайдов. Если по минуте на слайд, то 
теоретически за 10 мин можно успеть. Но боюсь, это вряд ли получится, и 
придется что-то пропускать или обозначать скороговоркой. 

 

Enjoy!

 

Всего наилучшего,

Андрей Климов

 

 

On Tue, Dec 29, 2020 at 9:51 PM Andrei Klimov mailto:and...@klimov.net> > wrote:

Добрый вечер!

Форвардирую письмо организатора семинаров CS&SE Николая Шилова с программой 
мероприятия в среду 30 декабря в 9:00 мск в Zoom'е.

 

До виртуальной встречи!

 

Андрей Климов

 

 

-- Forwarded message -
From: Nikolay Shilov mailto:n.shi...@innopolis.ru> >
Date: Tue, Dec 29, 2020 at 7:14 PM
Subject: Reminder: «Problems’ Day» - New Year's Eve meeting of the CS&SE 
Interlaboratory Seminar Novosibirsk + Innopolis + ...: Wednesday December 30, 
2020 at 9:00 am (Moscow time)
To: shilov...@mail.ru   mailto:shilov...@mail.ru> >

 

Итак, завтра в среду 30 декабря (с 9:00 до 11:00) у нас последняя в 2020 году 
встреча межлабораторного семинара по фундаментальным вопросам программной 
инженерии и теории программирования. Это встреча 7 по счету, но особенная - это 
День Проблем.

Объявление о встрече б

RE: «Problems’ Day» Wed 30.12.2020 9:00 in Zoom - New Year's Eve meeting of the CS&SE Interlaboratory Seminar Novosibirsk + Innopolis + ...

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

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

Ваш доклад оказался очень интересным, но по времени втиснуть его с трудом 
удалось. Планируете ли Вы когда-нибудь прочитать расширенную версию этого 
доклада, т.е. длиннее 15 минут? Я думаю, он был бы интересен не только мне 
одному.

 

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

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru] 
Sent: Wednesday, December 30, 2020 8:54 AM
To: metacomputation-ru ; refal@botik.ru
Subject: Re: «Problems’ Day» Wed 30.12.2020 9:00 in Zoom - New Year's Eve 
meeting of the CS&SE Interlaboratory Seminar Novosibirsk + Innopolis + ...

 

Доброе утро!

 

За 10 мин до доклада pdf-файл презентации был обновлен по тому же адресу:

*   https://drive.google.com/file/d/169tJh6oMxIaZPMTpv-wMJuUNVRWbrFUt/

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

 

Андрей Климов

 

 

On Wed, Dec 30, 2020 at 12:24 AM Andrei Klimov mailto:and...@klimov.net> > wrote:

Добрый вечер всем!

 

Я делаю доклад на этом семинаре (информация внизу) с такой темой (приведу 
по-русски и по-английски):

*   Андрей Климов, Институт прикладной математики им. М.В. Келдыша РАН, 
Москва
*   Фундаментальные не(до)решенные проблемы Computer Science & Software 
Engineering (субъективный взгляд)
*   Проблема осознается лишь после того, как найдены первые решения и... 
понято, что это не есть решения. С этой точки зрения глянем на каждую из 
следующих давно стоящих фундаментальных проблем CS&SE. Отбор проблем 
субъективен, а порядок лишь для удобства презентации: 

1.  детерминированные параллельные вычисления; 
2.  семантика имен, ссылок; 
3.  метавычисления; 
4.  верификация программ; 
5.  математические основания вычислений и языков; 6) слияние функциональных 
и объектно-ориентированных языков программирования. 

*   Andrei Klimov, Keldysh Institute of Applied Mathematics of Russian 
Academy of Sciences, Moscow
*   Fundamental Un(der)resolved Problems of CS&SE (a subjective view)
*   A problem is recognized only after the first solutions have been found 
and... it is understood that these are non-solutions. From this point of view, 
let's take a quick look at each of the following long standing fundamental 
problems of CS&SE. The selection of the problems is subjective, and the order 
is only for the convenience of presentation:

1.  deterministic parallel computation; 
2.  semantics of names and references; 
3.  metacomputation; 
4.  program verification; 
5.  mathematical foundations of computation and languages; 
6.  merging functional and object-oriented programming languages. 

По условиям организаторов презентация должна быть на английском, а говорить 
можно по-русски (что я и сделаю). Презентация лежит здесь:

*   https://drive.google.com/file/d/169tJh6oMxIaZPMTpv-wMJuUNVRWbrFUt/

Презентация получилась длинная – 10 емких слайдов. Если по минуте на слайд, то 
теоретически за 10 мин можно успеть. Но боюсь, это вряд ли получится, и 
придется что-то пропускать или обозначать скороговоркой. 

 

Enjoy!

 

Всего наилучшего,

Андрей Климов

 

 

On Tue, Dec 29, 2020 at 9:51 PM Andrei Klimov mailto:and...@klimov.net> > wrote:

Добрый вечер!

Форвардирую письмо организатора семинаров CS&SE Николая Шилова с программой 
мероприятия в среду 30 декабря в 9:00 мск в Zoom'е.

 

До виртуальной встречи!

 

Андрей Климов

 

 

-- Forwarded message -
From: Nikolay Shilov mailto:n.shi...@innopolis.ru> >
Date: Tue, Dec 29, 2020 at 7:14 PM
Subject: Reminder: «Problems’ Day» - New Year's Eve meeting of the CS&SE 
Interlaboratory Seminar Novosibirsk + Innopolis + ...: Wednesday December 30, 
2020 at 9:00 am (Moscow time)
To: shilov...@mail.ru   mailto:shilov...@mail.ru> >

 

Итак, завтра в среду 30 декабря (с 9:00 до 11:00) у нас последняя в 2020 году 
встреча межлабораторного семинара по фундаментальным вопросам программной 
инженерии и теории программирования. Это встреча 7 по счету, но особенная - это 
День Проблем.

Объявление о встрече было разослано 25 декабря 2020 (см. в конце письма).

 

В результате откликнулись 6 добровольцев, пожелавших поделиться проблемами в 
SE/CS/CE/IT/Math/Sci, волновавшие их в 2020 г. (список в порядке поступления 
заявок на выступление):

(1) Дмитрий А. Кондратьев (Институт систем информатики СО РАН, Новосибирск)

(2) Александр В. Наумчев (Университет Иннополис)

(3) Лидия В. Городняя (Институт систем информатики СО РАН, Новосибирск)

(4) Андрей В. Климов (Институт прикладной математики им. М.В. Келдыша РАН, 
Москва)

(5) Аркадий В. Климов (Институт проблем проектирования в микроэлектронике РАН, 
Москва)

(6) Николай В. Шилов (Университет Иннополис)

 

Поэтому я предлагаю организовать выступления в этом же порядке и буду следить 
за регламентом: каждому докладчику 10 минут на выступление и 5 минут на 
короткие вопросы ответы. 

 

Кроме того, я прошу 10 минут в перед первым выступлением (с 9:00 до 9:10), что 
бы почтить пам

RE: Конференция МЭС - 2020

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Аркадий!

«Есть и другой вариант — использовать модель стека в форме слова в некотором 
алфавите. Мощность алфавита должна быть не меньше наибольшего числа 
„параллельных“ (рекурсивных) вызовов в рамках одной функции. Слово-стек легко 
кодировать целым числом, только длина его в битах будет расти линейно с 
глубиной рекурсии. Как-то так.»

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

Вы тогда заметили, что на практике широко распространены «почти чистые» функции 
— функции, которые могли быть чистыми, но используют единственную 
недетерминированную функцию — генератор «свежих» имён/индексов. Например, если 
программа является компилятором и ей нужно порождать в ассемблерном листинге 
имена для меток.

Такую программу можно сделать чистой следующим образом. Функции, которым нужны 
свежие индексы, должны будут принимать число, номер очередного индекса, и 
возвращать число. Но тогда между по смыслу независимыми вызовами возникнет 
зависимость по данным и эти вызовы перестанут быть «параллельными».

Я об этом думал, и тоже пришёл к предложенной Вами схеме: индексом сделать 
строку в некотором алфавите и наращивать её разными символами при передаче в 
разные дочерние вызовы:

F {
  …
  … (e.ID) … = …  …  …;
  …
}

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

F {
  …
  … (e.ID) … = …  … ) …> …;
  …
}

Inc {
  e.Str '0' = e.Str '1';
 e.Str '1' =  '0';
  e.Str = e.Str '0';
}

Для нескольких рекурсивных вызовов в правой части циклический можно назначить 
либо произвольно, либо с учётом алгоритма — тот, по которому рекурсия ожидается 
глубже. В качестве эвристики можно различать хвостовые и нехвостовые вызовы.

 

«…вся память „ассоциативная“, или „content-addressаble“.»

Вопрос только в производительности этой памяти и скорости обмена с ней.

 

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

 

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Tuesday, February 2, 2021 8:32 PM
To: refal@botik.ru
Subject: Re: Конференция МЭС - 2020

 

Александр, добрый день!

Тоже извиняюсь за задержку, затерялось Ваше письмо.

Вопрос хороший, я постоянно (время от времени) подумываю насчет реализации 
Рефала в этой модели. Да, видимо тут нельзя предложить какой-то общей 
интерпретации индексов. В обычных задачах у нас индексы имеют содержательный 
прикладной смысл. Здесь же, видимо, это будет, как в обычных реализациях рефала 
и функц. языков, некий "свежий указатель", разница лишь в том, что тут не нужна 
какая-то память, с ним связанная, просто в силу того, что вся память 
"ассоциативная", или "content-addressаble". И если в обычных системах для 
порождения "свежего указателя" мы используем реальный пул свободных ячеек с 
адресами, то здесь нужны только сами "адреса". А для их порождения (и 
освобождения) можно вполне использовать такой же реальный пул ячеек (звеньев), 
размер которых должен быть достаточен лишь для размещения ссылок для 
организации списка свободных ячеек (адресов).

Есть и другой вариант - использовать модель стека в форме слова в некотором 
алфавите. Мощность алфавита должна быть не меньше наибольшего числа 
"параллельных" (рекурсивных) вызовов в рамках одной функции. Слово-стек легко 
кодировать целым числом, только длина его в битах будет расти линейно с 
глубиной рекурсии. Как-то так.

Аркадий

 

чт, 21 янв. 2021 г. в 12:25, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Добрый день, Аркадий!

Прошу прощения за поздний ответ, только сейчас я наконец добрался до этого 
письма.

Вы написали в рассылку refal  @botik.ru, и поэтому у 
меня к Вам вопрос: а можно ли применить этот подход к распараллеливанию 
программ на Рефале? Или он применим только к массивам однородных вычислений 
вроде рассмотренного перемножения матриц?

Если брать Рефал Плюс, то у конкретизаций есть несколько входных и выходных 
аргументов, которые тоже можно представлять токенами в этой модели. Но проблема 
будет в том, что множество конкретизаций во время выполнения не известно 
заранее и назначить им индекс статически невозможно. Или всё-таки можно что-то 
придумать?

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com 
  [mailto:refal@botik.ru 
 ] 
Sent: Wednesday, September 16

RE: Re[2]: Сравнение веток Рефала

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Александр!

Я правильно предполагаю, что планируется что-то вроде AWS Lambda, но на Рефале? 
Или же это что-то другое?

И присоединяюсь к вопросу Аркадия: нельзя ли чуть побольше конкретики, какие 
задачи предполагается решать с помощью этого сервера?

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Tuesday, January 19, 2021 12:33 PM
To: refal@botik.ru
Subject: Re[2]: Сравнение веток Рефала

 

Добрый день, коллеги!

 

Высылаю обещанную аннотацию моей разработки по Рефалу.

По требованию — дополню.

С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

RE: Конференция МЭС - 2020

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Аркадий!

Прошу прощения за поздний ответ, только сейчас я наконец добрался до этого 
письма.

Вы написали в рассылку refal  @botik.ru, и поэтому у 
меня к Вам вопрос: а можно ли применить этот подход к распараллеливанию 
программ на Рефале? Или он применим только к массивам однородных вычислений 
вроде рассмотренного перемножения матриц?

Если брать Рефал Плюс, то у конкретизаций есть несколько входных и выходных 
аргументов, которые тоже можно представлять токенами в этой модели. Но проблема 
будет в том, что множество конкретизаций во время выполнения не известно 
заранее и назначить им индекс статически невозможно. Или всё-таки можно что-то 
придумать?

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Wednesday, September 16, 2020 11:44 PM
To: refal@botik.ru; metacomputation...@googlegroups.com
Subject: Re: Конференция МЭС - 2020

 

Сообщаю интересующимся, что наконец залил презентацию своего доклада (в формате 
pptx).

Надеюсь теперь будет понятнее, а то статья получилась сумбурная и потому трудно 
читаемая.

Ее, как и статью, можно найти среди докладов (скажем, по фамилии автора) в 
разделе Доклады сайта конференции

http://www.mes-conference.ru/ 

Туда же можно попасть по прямой ссылке

  
http://www.mes-conference.ru/index.php?page=reportsV3

 

Название моего доклада: 


  
Средства верификации распределения вычислений в потоковой архитектуре ППВС 
«Буран»

Хотя вопрос довольно частный, но кажется получилось интересно. И относится он 
скорее не к конкретной архитектуре, а к ее абстрактной модели вычислений.

Надеюсь скоро озвучку выставить. (В принципе текст озвучки уже введен в виде 
комментариев к слайдам).

С уважением,

Аркадий

 

PS. Просматривать вроде можно и без регистрации (кроме обсуждения), а для 
комментирования (обсуждения) надо зарегистрироваться.

Буду рад комментариям.

 

 

чт, 16 июл. 2020 г. в 10:14, Arkady Klimov mailto:arkady.kli...@gmail.com> >:

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

 

Всероссийская с международным участием научно-техническая конференция
"Проблемы разработки перспективных микро- и наноэлектронных систем"

МЭС-2020

 

Зарегистрировавшись на портале 

http://www.mes-conference.ru/  ,

можно читать выставленные статьи (в разделе Доклады) и участвовать в их 
обсуждении.

Спасибо за участие!

-- 

___

 

RE: Рефал-5, Рефал Плюс и форматы

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Аркадий! Добрый вечер всем остальным!

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

 

«Александр, Вы же сами пишете, что частью языка Рефал Плюс являются форматы, — 
это и есть то решение, которое и предполагалось, и осуществлено в Рефале Плюс.»

Я пишу о том, что есть конфликт:
• (а) форматы являются частью языка Рефал Плюс, частью его промежуточного 
представления и жизненно необходимы его массивному генератору кода,
• (б) у системы Рефал Плюс есть поддержка входных файлов на Рефале-5, где этих 
форматов нет,
• (в) предполагается, что система Рефал Плюс со фронтендом Рефала-5 будет 
применима для программ, написанных для Рефала-5 (например, SCP4), иначе зачем 
её добавлять,
• (г) в исходных файлах программ для Рефала-5 форматов нет, более того, для 
функций не всегда формат может быть записан.

Конфликт в том, что системе Рефал Плюс форматы нужны для построения 
эффективного кода, но в некоторых режимах компиляции во входных файлах этих 
форматов нет. А значит, или форматы должны рождаться в системе, или должны быть 
всё-таки как-то указаны пользователем. Иначе программы для Рефала-5 будут 
выполняться неприемлемо медленно.

(Внимательные читатели обратили внимание на предлог. Я пишу не «на Рефале-5», а 
«для Рефала-5», подразумевая, что программист пишет код для конкретной 
реализации. Этот код будет эффективен на данной реализации, однако может быть 
медленен на альтернативных реализациях.)

 

От Андрея Петровича в частной переписке я узнал, что реализованный фронтэнд 
Рефала-5 в Рефале Плюс просто приписывает всем функциям формат e = e. Т.е. 
описанная мною задача решена не была.

 

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

А я вообще не представлял, как изначально предполагалось, поэтому и спросил. 
Вообще существует два варианта решения, а вернее три. Нулевое решение — сунуть 
голову в песок и приписывать всем функциям формат e = e, оно и было 
реализовано. Два других: выводить форматы автоматически или требовать от 
пользователя псевдокомментариев с корректными форматами. Впрочем, возможна 
комбинация этих подходов.

 

«А разве не вы с дипломниками эту проблему уже рассматривали и вроде даже как 
бы решили в прошлом году? Или там было что-то другое? Тогда уточните.»

Это другое, как модно сейчас писать в интернете. Вернее, этот вывод форматов 
решает другую задачу.

 

«В принципе, аналогичная работа производилась в рамках полусуперкомпилятора 
Рефала-6 Н.Кондратьевым. А при отображении в С эти форматы использовались (к 
сожалению, уже четверть века это лежит без употребления).»

Любопытно узнать детали.

 

 

А теперь про то, что я сам об этом думаю. А думаю вот что:

* Для entry- и extern-функций формат задаёт сам пользователь, 
используя, например, псевдокомментарии. Или пишет отдельный файл с форматами 
всех entry-функций, который скармливается компилятору. Здесь важно обеспечить 
консистентность для случаев раздельной трансляции, чтобы форматы, указанные для 
entry-функции в одном файле и extern-функции с тем же именем в другом 
совпадали. Но это технический вопрос.

* Форматы не-entry-функций выводятся компилятором. А это уже вопрос 
принципиальный.

 

Дальше про вывод форматов. Для простоты я буду рассматривать базисный Рефал.

Но нужно сначала уточнить требования к форматам в Рефале Плюс, вернее те, 
которые существенны для дальнейшего обсуждения. Требования следующие:

1.Аргумент каждого вызова функции должен соответствовать формату. Т.е. если 
ARG — аргумент, а INFMT — входной формат вызываемой функции, то сопоставление 
ARG : INFMT должно быть успешным и без сужений (ограничений на переменные в 
ARG).

2.Правые части предложений каждой функции должны соответствовать выходному 
формату. Т.е. если RES — выражение в правой части предложения, а OUTFMT — 
выходной формат функции, то RES : OUTFMT должно быть успешным и без сужений.

3.Левые части предложений каждой функции должны соответствовать входному 
формату функции. Т.е. если PAT — выражение в левой части, а INFMT — входной 
формат, то PAT : INFMT успешно и без сужений.

Известно два алгоритма вывода форматов функций:

* Алгоритм, разработанный Сергеем Анатольевичем Романенко для повышения 
местности в самоприменимом «московском специализаторе» в 1987 году.
http://dx.doi.org/10.1007/3-540-52592-0_73

* Алгоритм, предложенный автором письма и реализованный вместе со 
студентом Георгием Ивановым в рамках выпускной квалификационной работы в 2019 
году.
  
https://github.com/bmstu-iu9/refal-5-arity-raiser-and-verifier
https 

 
://github.com/bmstu-iu9/refal-5-arity-raiser-and-verifier/blob/master/repo

RE: Рефал-5, Рефал Плюс и форматы

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброй ночи всем!

В принципе, я разобрался, как надо повышать местность и коместность при 
компиляции Рефала-5 в массивное представление. Могу изложить, как бы я это 
сделал (а может, когда-нибудь и сделаю, через год, через два). Но сначала я 
хотел бы узнать, как это предполагалось в Рефале Плюс.

 

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

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Wednesday, December 16, 2020 12:07 AM
To: refal@botik.ru
Subject: Рефал-5, Рефал Плюс и форматы

 

Добрый вечер всем!

На сколько я знаю, когда-то были планы реализации front-end’а Рефала-5 в 
компиляторе Рефала Плюс. Т.е. предполагалось использовать компилятор Рефала 
Плюс для компиляции исходных текстов Рефала-5.

(Дальше пишу подробно, поскольку не все подписчики знакомы с рассматриваемой 
проблемой. Те, кто знакомы, могут сразу промотать письмо до конца.)

Но есть один нюанс. Рефал Плюс использует массивное представление данных с 
дорогой конкатенацией. А это значит, что традиционный способ передавать 
параметры в функцию, используя N−1 скобок для N e-параметров будет приводить к 
избыточной конкатенации, а значит, и увеличению порядка сложности.

Пример, замена символов A на B:

Fab { e.X =  }

Loop {
  (e.Acc) 'A' e.Rest = ;
  (e.Acc) s.X e.Rest = ;
  (e.Acc) /* пусто */ = e.Acc;
}

Здесь есть две конкатенации, с которыми столкнётся Рефал Плюс.

Первая — конкатенация символа с аккумулятором e.Acc 'B' и e.Acc s.X. Если длина 
аккумулятора N, то потребуется создать новый массив длины N+1, скопировать в 
него содержимое e.Acc и дописать туда символ ('B' или s.X). На каждом шаге 
аккумулятор вырастает на единицу, а значит, затраты времени на копирования 
элементов будут N×(N+1)/2 = O(N²), где N — исходная длина строки.

Вторая — конкатенация скобочного терма с остатком строки (…) e.Rest. В ней 
затраты те же: нужно создать массив длины N+1 (где N — длина e.Rest), 
скопировать туда e.Rest и скобочный терм. Тоже сложность будет O(N²).

Первая проблема, проблема роста аккумулятора, решается пустым местом вокруг 
формируемого массива. На большинстве итераций новый символ будет дописан в 
пустое место, а сам массив копировать не потребуется. Затраты времени на 
формирование выражения в аккумуляторе будут амортизированными линейными. Детали 
пересказывать не буду (когда-то их уже обсуждали в рассылке). В общем, решение 
элегантное.

А вот вторую конкатенацию дыры не спасут, т.к. их там нет. В массиве-аргументе 
слева от e.Rest уже находится символ, вписать на его место круглую скобку 
нельзя, т.к. участком массива 'A' e.Rest может пользоваться другая часть 
программы.

Эту проблему создатели языка решили жёстко: форматы функций (которые, 
вообще-то, идиома, рекомендация) сделали частью языка.

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

Для функций выше в программе должны быть написаны следующие строчки:

$func Fab e.X = e.X;
$func Loop (e.Acc) e.X = e.Acc;

Для каждого вызова Loop компилятор проверит, что фактический аргумент 
вкладывается в формат, после чего аккумулятор и остаток строки передаст в виде 
двух отдельных параметров. Конкатенации не будет. Сложность функции будет 
амортизированно линейной.

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

 

Так вот, к чему я пишу. На Рефале-5 конкатенация дешёвая, форматов на уровне 
синтаксиса нет, встречаются функции с несколькими форматами. Как быть с такими 
программами? Если функциям неявно приписывать формат e.X = e.X, то программы 
для Рефала-5, скомпилированные Рефалом Плюс, будут работать заведомо медленно. 
Причём медленнее не на константу, а на порядок алгоритма.

А что же тогда предполагалось делать, чтобы программы для Рефала-5 были 
приемлемо эффективны, будучи скомпилированы Рефалом Плюс? 

 

В соседней ветке мы обсуждаем плохие приёмы программирования, и одна из мыслей 
была — борьба с недостатком представления данных протекает в стиль 
программирования. Так вот, в Рефале Плюс борьба с недостатком представления 
данных протекла аж в дизайн языка.

 

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

 

Рефал-5, Рефал Плюс и форматы

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!

На сколько я знаю, когда-то были планы реализации front-end’а Рефала-5 в 
компиляторе Рефала Плюс. Т.е. предполагалось использовать компилятор Рефала 
Плюс для компиляции исходных текстов Рефала-5.

(Дальше пишу подробно, поскольку не все подписчики знакомы с рассматриваемой 
проблемой. Те, кто знакомы, могут сразу промотать письмо до конца.)

Но есть один нюанс. Рефал Плюс использует массивное представление данных с 
дорогой конкатенацией. А это значит, что традиционный способ передавать 
параметры в функцию, используя N−1 скобок для N e-параметров будет приводить к 
избыточной конкатенации, а значит, и увеличению порядка сложности.

Пример, замена символов A на B:

Fab { e.X =  }

Loop {
  (e.Acc) 'A' e.Rest = ;
  (e.Acc) s.X e.Rest = ;
  (e.Acc) /* пусто */ = e.Acc;
}

Здесь есть две конкатенации, с которыми столкнётся Рефал Плюс.

Первая — конкатенация символа с аккумулятором e.Acc 'B' и e.Acc s.X. Если длина 
аккумулятора N, то потребуется создать новый массив длины N+1, скопировать в 
него содержимое e.Acc и дописать туда символ ('B' или s.X). На каждом шаге 
аккумулятор вырастает на единицу, а значит, затраты времени на копирования 
элементов будут N×(N+1)/2 = O(N²), где N — исходная длина строки.

Вторая — конкатенация скобочного терма с остатком строки (…) e.Rest. В ней 
затраты те же: нужно создать массив длины N+1 (где N — длина e.Rest), 
скопировать туда e.Rest и скобочный терм. Тоже сложность будет O(N²).

Первая проблема, проблема роста аккумулятора, решается пустым местом вокруг 
формируемого массива. На большинстве итераций новый символ будет дописан в 
пустое место, а сам массив копировать не потребуется. Затраты времени на 
формирование выражения в аккумуляторе будут амортизированными линейными. Детали 
пересказывать не буду (когда-то их уже обсуждали в рассылке). В общем, решение 
элегантное.

А вот вторую конкатенацию дыры не спасут, т.к. их там нет. В массиве-аргументе 
слева от e.Rest уже находится символ, вписать на его место круглую скобку 
нельзя, т.к. участком массива 'A' e.Rest может пользоваться другая часть 
программы.

Эту проблему создатели языка решили жёстко: форматы функций (которые, 
вообще-то, идиома, рекомендация) сделали частью языка.

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

Для функций выше в программе должны быть написаны следующие строчки:

$func Fab e.X = e.X;
$func Loop (e.Acc) e.X = e.Acc;

Для каждого вызова Loop компилятор проверит, что фактический аргумент 
вкладывается в формат, после чего аккумулятор и остаток строки передаст в виде 
двух отдельных параметров. Конкатенации не будет. Сложность функции будет 
амортизированно линейной.

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

 

Так вот, к чему я пишу. На Рефале-5 конкатенация дешёвая, форматов на уровне 
синтаксиса нет, встречаются функции с несколькими форматами. Как быть с такими 
программами? Если функциям неявно приписывать формат e.X = e.X, то программы 
для Рефала-5, скомпилированные Рефалом Плюс, будут работать заведомо медленно. 
Причём медленнее не на константу, а на порядок алгоритма.

А что же тогда предполагалось делать, чтобы программы для Рефала-5 были 
приемлемо эффективны, будучи скомпилированы Рефалом Плюс? 

 

В соседней ветке мы обсуждаем плохие приёмы программирования, и одна из мыслей 
была — борьба с недостатком представления данных протекает в стиль 
программирования. Так вот, в Рефале Плюс борьба с недостатком представления 
данных протекла аж в дизайн языка.

 

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

 

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброй ночи, Николай!

Сквозной просмотр был у Турчина в учебнике по Рефалу-5:

Глава 3. 

Основные приемы программирования (koi8-r) (refal.ru)

Да, и одним из примеров является спаривание скобок.

Ещё этот приём используется в суперкомпиляторах SCP3 и SCP4. Можно исходники 
скачать и убедиться.

 

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

 

From: nikolai.kondratiev_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Monday, December 14, 2020 10:35 PM
To: refal@botik.ru
Subject: AW: Запахи кода и антипаттерны в Рефале

 

Я вспоминаю, что Турчин был очень доволен тем, что нашел алгоритм СПАРИВАНИЯ 
СКОБОК, работающий линейное время, а сквозной просмотр появился как вариация на 
ту же тему.

Мне кажется, что сам сквозной просмотр он не слишком пропагандировал. 

 

Von: Arkady Klimov arkady.klimov_AT_gmail.com mailto:refal@botik.ru> > 
Gesendet: Montag, 14. Dezember 2020 17:49
An: refal@botik.ru  
Betreff: Re: Запахи кода и антипаттерны в Рефале

 

Я тоже начал было писать про "настоящее выворачивание", но Александр меня 
опередил.

Да, это оно самое. Мне такой стиль не нравится, и сам я так не пишу. Возможно, 
потому, что Рефал-6 позволяет не экономить на копированиях, и я предпочитаю 
рекурсивный стиль. Но хочу высказаться в защиту этой формы, которую использовал 
Турчин. Думаю, тут дело не в экономии копирований, а в стиле мышления. Как ни 
странно, Турчин рассматривал работу рефал-программы как пошаговый процесс с 
изменяющимся состоянием. Отсюда и понятие поля зрения. Да, оно моделирует стек, 
неявно возникающий при рекурсии. Но при мета-деятельности Турчин предпочитал 
поле зрения объектной программы держать как бы целиком перед глазами. В центре 
- активная конкретизация, а по краям - окружение. Отсюда и возник такой стиль. 
Он в каком-то смысле сближает рефал с машиной Тьюринга, только вместо линейной 
ленты - дерево.

Когда-то около 90 года я попытался с ним на эту тему заговорить, как бы 
предлагая перейти на рекурсивный стиль, но он как-то это сходу отверг, мол так 
ему удобнее. Разговора по существу не получилось. Поэтому сейчас я его так и 
понимаю, как написал выше.

 

С уважением, 

Аркадий

 

пн, 14 дек. 2020 г. в 16:08, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Василий, не надо пошаговую прокрутку. Я неправильно посчитал скобки. Во входной 
строке их не 4, а 3, поэтому всё сходится: 3+1=4.

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> > 
Sent: Monday, December 14, 2020 4:58 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Александр.
Действительно.
Еще раз, Большое спасибо.
PS Если хотите, могу прислать пошаговую прокрутку обоих вариантов...

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru

 

 

 

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

Василий!

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

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.
Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..
DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ (k/DoEnum/ e1 sN.) e2.
  sN = sN
DoEnum-Wrap (e1 sN) e2 = (e1) k/DoEnum/ e2 sN.
EndEnum e1 sN = e1

И нету оборачивания скобки в рекурсивном решении.

Один шаг сэкономился на EndEnum, т.к. в последнем предложении мы и стеки 
отбрасываем, и счётчик. Ещё шаги экономятся на обработке скобок. Открывающая 
скобка в обоих вариантах требует одного шага. Закрывающая скобка — двух шагов: 
последнее предложение DoEnum, где она видит аргумент с пустой строкой и 
счётчиком и DoEnum-Wrap, которая выбрасывает вон скобку и продолжает цикл 
DoEnum. Но закрывающих скобок 4, должно сэкономиться 4 шага. И один на EndEnum. 
4+1≠4, где-то что-то я не учёл.

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> >
Sent: Monday, December 14, 2020 4:05 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Александр!
Большое спасибо за подробный рассказ!
Но, то что в примере применили Вы - тоже самое: Справа стек.
Только просмотренную часть Вы не собирали в левой скоб

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброй ночи, Аркадий!

Спасибо за пояснение про намерения Турчина! Это действительно интересно.

На самом деле, решение

Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..
DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ (k/DoEnum/ e1 sN.) e2.
  sN = sN
DoEnum-Wrap (e1 sN) e2 = (e1) k/DoEnum/ e2 sN.
EndEnum e1 sN = e1

тоже в рекурсивном стиле. Ведь при этом накапливаются вложенные конкретизации в 
поле зрения. А выворачивание — итеративное, на каждом шаге в поле зрения 
конкретизация одна.

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Monday, December 14, 2020 7:49 PM
To: refal@botik.ru
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Я тоже начал было писать про "настоящее выворачивание", но Александр меня 
опередил.

Да, это оно самое. Мне такой стиль не нравится, и сам я так не пишу. Возможно, 
потому, что Рефал-6 позволяет не экономить на копированиях, и я предпочитаю 
рекурсивный стиль. Но хочу высказаться в защиту этой формы, которую использовал 
Турчин. Думаю, тут дело не в экономии копирований, а в стиле мышления. Как ни 
странно, Турчин рассматривал работу рефал-программы как пошаговый процесс с 
изменяющимся состоянием. Отсюда и понятие поля зрения. Да, оно моделирует стек, 
неявно возникающий при рекурсии. Но при мета-деятельности Турчин предпочитал 
поле зрения объектной программы держать как бы целиком перед глазами. В центре 
- активная конкретизация, а по краям - окружение. Отсюда и возник такой стиль. 
Он в каком-то смысле сближает рефал с машиной Тьюринга, только вместо линейной 
ленты - дерево.

Когда-то около 90 года я попытался с ним на эту тему заговорить, как бы 
предлагая перейти на рекурсивный стиль, но он как-то это сходу отверг, мол так 
ему удобнее. Разговора по существу не получилось. Поэтому сейчас я его так и 
понимаю, как написал выше.

 

С уважением, 

Аркадий

 

пн, 14 дек. 2020 г. в 16:08, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Василий, не надо пошаговую прокрутку. Я неправильно посчитал скобки. Во входной 
строке их не 4, а 3, поэтому всё сходится: 3+1=4.

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> > 
Sent: Monday, December 14, 2020 4:58 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Александр.
Действительно.
Еще раз, Большое спасибо.
PS Если хотите, могу прислать пошаговую прокрутку обоих вариантов...

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru

 

 

 

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

Василий!

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

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.
Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..
DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ (k/DoEnum/ e1 sN.) e2.
  sN = sN
DoEnum-Wrap (e1 sN) e2 = (e1) k/DoEnum/ e2 sN.
EndEnum e1 sN = e1

И нету оборачивания скобки в рекурсивном решении.

Один шаг сэкономился на EndEnum, т.к. в последнем предложении мы и стеки 
отбрасываем, и счётчик. Ещё шаги экономятся на обработке скобок. Открывающая 
скобка в обоих вариантах требует одного шага. Закрывающая скобка — двух шагов: 
последнее предложение DoEnum, где она видит аргумент с пустой строкой и 
счётчиком и DoEnum-Wrap, которая выбрасывает вон скобку и продолжает цикл 
DoEnum. Но закрывающих скобок 4, должно сэкономиться 4 шага. И один на EndEnum. 
4+1≠4, где-то что-то я не учёл.

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> >
Sent: Monday, December 14, 2020 4:05 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Александр!
Большое спасибо за подробный рассказ!
Но, то что в примере применили Вы - тоже самое: Справа стек.
Только просмотренную часть Вы не собирали в левой скобке, а сразу выводили за 
пределы функции...
Точнее стек получался из вызовов DoEnum-Wrap и скобок наизнанку ...
Еще раз, Большое спасибо!
P.S. А в этом варианте получился 31 шаг.
4 шага где-то сэкономили ;)

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru  

 

 

 

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

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Василий, не надо пошаговую прокрутку. Я неправильно посчитал скобки. Во входной 
строке их не 4, а 3, поэтому всё сходится: 3+1=4.

 

From: Василий Стеллецкий swi_AT_cnshb.ru  
Sent: Monday, December 14, 2020 4:58 PM
To: refal@botik.ru
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Александр.
Действительно.
Еще раз, Большое спасибо.
PS Если хотите, могу прислать пошаговую прокрутку обоих вариантов...

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru

 

 

 

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

Василий!

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

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.
Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..
DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ (k/DoEnum/ e1 sN.) e2.
  sN = sN
DoEnum-Wrap (e1 sN) e2 = (e1) k/DoEnum/ e2 sN.
EndEnum e1 sN = e1

И нету оборачивания скобки в рекурсивном решении.

Один шаг сэкономился на EndEnum, т.к. в последнем предложении мы и стеки 
отбрасываем, и счётчик. Ещё шаги экономятся на обработке скобок. Открывающая 
скобка в обоих вариантах требует одного шага. Закрывающая скобка — двух шагов: 
последнее предложение DoEnum, где она видит аргумент с пустой строкой и 
счётчиком и DoEnum-Wrap, которая выбрасывает вон скобку и продолжает цикл 
DoEnum. Но закрывающих скобок 4, должно сэкономиться 4 шага. И один на EndEnum. 
4+1≠4, где-то что-то я не учёл.

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> >
Sent: Monday, December 14, 2020 4:05 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Александр!
Большое спасибо за подробный рассказ!
Но, то что в примере применили Вы - тоже самое: Справа стек.
Только просмотренную часть Вы не собирали в левой скобке, а сразу выводили за 
пределы функции...
Точнее стек получался из вызовов DoEnum-Wrap и скобок наизнанку ...
Еще раз, Большое спасибо!
P.S. А в этом варианте получился 31 шаг.
4 шага где-то сэкономили ;)

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru  

 

 

 

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

Василий!

Выворачивание скобок, оно же сквозной просмотр, — это другое. Это использование 
стека для представления незакрытых скобок. Например, так:

Enum e1 = k/DoEnum/ /0/ ('$') e1 '$'.

* Формат: k/DoEnum/ sN (tL eS) eU tR
*   eS — просканированная часть
*   eU — непросканированная часть
*   tL — стек просканированных частей слева
*   tR — стек непросканированных частей справа

* символ просто переносим
DoEnum sN (tL eS) s1 eU tR = k/DoEnum/ k/P1/sN. (tL eS sN) eU tR.
* в скобочный терм спускаемся
   sN (tL eS) (e1) eU tR = k/DoEnum/ sN ((tL eS)) e1 (eU tR).
* термы кончились, но стек не пустой
   sN ((tL eS) e1) (eU tR) = k/DoEnum/ sN (tL eS (e1)) eU tR.
* термы кончились и стек тоже пустой — выход из цикла
   sN ('$' eS) '$' = eS

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

e1 (e2 (e3 ^ e4) e5) e6

где знак ^ означает позицию, вызов функции DoEnum будет иметь вид

k/DoEnum/ ((('$' e1) e2) e3) e4 (e5 (e6 '$')).

Т.е. незакрытые скобки перед ^ оказываются закрывающими, а неоткрытые после ^ — 
открывающими. А скобка между e3 и e4 служит указателем ^.

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

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

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> >
Sent: Monday, December 14, 2020 1:52 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Добрый день, Александр!
Да, шагов поменьше!

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.

Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..

DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..

  (e1)e2 sN = k/DoEnum-Wrap/ k/DoEnum/ e1 sN. (e2).

  sN = sN

DoEnum-Wrap e1 sN (e2) = (e1) k/DoEnum/ e2 sN.

EndEnum e1 sN = e1

 

S:35 cc=0 M=1024

ПЗ: /0/ /1/ /2/ /3/ ( ( /4/ /5/ ) /6/ ( /7/ /8/ )

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Василий!

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

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.
Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..
DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ (k/DoEnum/ e1 sN.) e2.
  sN = sN
DoEnum-Wrap (e1 sN) e2 = (e1) k/DoEnum/ e2 sN.
EndEnum e1 sN = e1

И нету оборачивания скобки в рекурсивном решении.

Один шаг сэкономился на EndEnum, т.к. в последнем предложении мы и стеки 
отбрасываем, и счётчик. Ещё шаги экономятся на обработке скобок. Открывающая 
скобка в обоих вариантах требует одного шага. Закрывающая скобка — двух шагов: 
последнее предложение DoEnum, где она видит аргумент с пустой строкой и 
счётчиком и DoEnum-Wrap, которая выбрасывает вон скобку и продолжает цикл 
DoEnum. Но закрывающих скобок 4, должно сэкономиться 4 шага. И один на EndEnum. 
4+1≠4, где-то что-то я не учёл.

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru  
Sent: Monday, December 14, 2020 4:05 PM
To: refal@botik.ru
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Александр!
Большое спасибо за подробный рассказ!
Но, то что в примере применили Вы - тоже самое: Справа стек.
Только просмотренную часть Вы не собирали в левой скобке, а сразу выводили за 
пределы функции...
Точнее стек получался из вызовов DoEnum-Wrap и скобок наизнанку ...
Еще раз, Большое спасибо!
P.S. А в этом варианте получился 31 шаг.
4 шага где-то сэкономили ;)

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru  

 

 

 

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

Василий!

Выворачивание скобок, оно же сквозной просмотр, — это другое. Это использование 
стека для представления незакрытых скобок. Например, так:

Enum e1 = k/DoEnum/ /0/ ('$') e1 '$'.

* Формат: k/DoEnum/ sN (tL eS) eU tR
*   eS — просканированная часть
*   eU — непросканированная часть
*   tL — стек просканированных частей слева
*   tR — стек непросканированных частей справа

* символ просто переносим
DoEnum sN (tL eS) s1 eU tR = k/DoEnum/ k/P1/sN. (tL eS sN) eU tR.
* в скобочный терм спускаемся
   sN (tL eS) (e1) eU tR = k/DoEnum/ sN ((tL eS)) e1 (eU tR).
* термы кончились, но стек не пустой
   sN ((tL eS) e1) (eU tR) = k/DoEnum/ sN (tL eS (e1)) eU tR.
* термы кончились и стек тоже пустой — выход из цикла
   sN ('$' eS) '$' = eS

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

e1 (e2 (e3 ^ e4) e5) e6

где знак ^ означает позицию, вызов функции DoEnum будет иметь вид

k/DoEnum/ ((('$' e1) e2) e3) e4 (e5 (e6 '$')).

Т.е. незакрытые скобки перед ^ оказываются закрывающими, а неоткрытые после ^ — 
открывающими. А скобка между e3 и e4 служит указателем ^.

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

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

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> >
Sent: Monday, December 14, 2020 1:52 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Добрый день, Александр!
Да, шагов поменьше!

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.

Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..

DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..

  (e1)e2 sN = k/DoEnum-Wrap/ k/DoEnum/ e1 sN. (e2).

  sN = sN

DoEnum-Wrap e1 sN (e2) = (e1) k/DoEnum/ e2 sN.

EndEnum e1 sN = e1

 

S:35 cc=0 M=1024

ПЗ: /0/ /1/ /2/ /3/ ( ( /4/ /5/ ) /6/ ( /7/ /8/ ) /9/ /10/ ) /11/

КОП:

 

Спасибо, понял что такое "выворачивание скобок" :)

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru  

 

 

 

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

Добрый день, Василий!

А если мы пишем для многопоточного Рефала, то статический ящик или копилка не 
подойдёт. Нужно использовать или динамический ящик, или передавать номер через 
параметр. Получится как-то так:

Enum e1 = k/DoEnum/e1 /0/.

DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ k/DoEnum/ e1 sN. (e2).

DoEnum-Wrap e1 sN (e2) = (e1) k/DoE

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Василий!

Выворачивание скобок, оно же сквозной просмотр, — это другое. Это использование 
стека для представления незакрытых скобок. Например, так:

Enum e1 = k/DoEnum/ /0/ ('$') e1 '$'.

* Формат: k/DoEnum/ sN (tL eS) eU tR
*   eS — просканированная часть
*   eU — непросканированная часть
*   tL — стек просканированных частей слева
*   tR — стек непросканированных частей справа

* символ просто переносим
DoEnum sN (tL eS) s1 eU tR = k/DoEnum/ k/P1/sN. (tL eS sN) eU tR.
* в скобочный терм спускаемся
   sN (tL eS) (e1) eU tR = k/DoEnum/ sN ((tL eS)) e1 (eU tR).
* термы кончились, но стек не пустой
   sN ((tL eS) e1) (eU tR) = k/DoEnum/ sN (tL eS (e1)) eU tR.
* термы кончились и стек тоже пустой — выход из цикла
   sN ('$' eS) '$' = eS

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

e1 (e2 (e3 ^ e4) e5) e6

где знак ^ означает позицию, вызов функции DoEnum будет иметь вид

k/DoEnum/ ((('$' e1) e2) e3) e4 (e5 (e6 '$')).

Т.е. незакрытые скобки перед ^ оказываются закрывающими, а неоткрытые после ^ — 
открывающими. А скобка между e3 и e4 служит указателем ^.

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

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

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru  
Sent: Monday, December 14, 2020 1:52 PM
To: refal@botik.ru
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Добрый день, Александр!
Да, шагов поменьше!

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.

Enum e1 = k/EndEnum/k/DoEnum/e1 /1/..

DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..

  (e1)e2 sN = k/DoEnum-Wrap/ k/DoEnum/ e1 sN. (e2).

  sN = sN

DoEnum-Wrap e1 sN (e2) = (e1) k/DoEnum/ e2 sN.

EndEnum e1 sN = e1

 

S:35 cc=0 M=1024

ПЗ: /0/ /1/ /2/ /3/ ( ( /4/ /5/ ) /6/ ( /7/ /8/ ) /9/ /10/ ) /11/

КОП:

 

Спасибо, понял что такое "выворачивание скобок" :)

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru  

 

 

 

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

Добрый день, Василий!

А если мы пишем для многопоточного Рефала, то статический ящик или копилка не 
подойдёт. Нужно использовать или динамический ящик, или передавать номер через 
параметр. Получится как-то так:

Enum e1 = k/DoEnum/e1 /0/.

DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ k/DoEnum/ e1 sN. (e2).

DoEnum-Wrap e1 sN (e2) = (e1) k/DoEnum/ e2 sN.

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

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru mailto:refal@botik.ru> >
Sent: Monday, December 14, 2020 12:47 PM
To: refal@botik.ru  
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Добрый день всем!

Я про задачку...
Ну, на мой взгляд не просто для понимания...
На других диалектах Рефала - да пожалуйста!
В этой задаче удобно использовать Ящики или Копилку.
Например с копилкой:

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.

Enum s1e2=k/Enum1/k/ВК/'n'..k/Enum/e2.

 (e1)e2=(k/Enum/e1.)k/Enum/e2.

 =

Enum1 =/1/k/ЗК/'n='/2/.

  sn=snk/ЗК/'n='k/P1/sn..

Результат:

S:62 cc=0 M=1024

ПЗ: /0/ /1/ /2/ /3/ ( ( /4/ /5/ ) /6/ ( /7/ /8/ ) /9/ /10/ ) /11/

КОП: ( 'n' '=' /12/ )

(первый /0/ в поле зрения не имеет отношения к задаче, это мой интерфейс)


 

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru

 

 

 

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

Доброе утро всем!
 

 1. Выворачивание скобок наизнанку, для организации прохода по выражению.


К представлению объектных выражений этот приём (антиприём) не имеет отношение. 
Он, скорее, характерен для базисного Рефала (Рефала-2), в котором нет ничего 
подобного let-конструкциям (условия, перестройки, действия). И благодаря этому 
сквозному обходу исчезает нужда во вспомогательных функциях, можно обойтись 
одной.

Но, вообще этот приём уродлив, хоть и пропагандировался Турчиным.

 

 2. Боязнь копирования кусков выражений в разные «дочерние» функции.


А в Рефале-5 ещё и в условия.

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

А нет ли в Рефале Плюс другой боязни — боязни конкатенации?


Задача. Заменить в выражении все символы последовательными натуральными числами:

 → 1 2 3 ((4 5) 6 (7 8) 9 10) 11

Решение на Рефале-5λ, эффективное (O(n)) 

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Василий!

А если мы пишем для многопоточного Рефала, то статический ящик или копилка не 
подойдёт. Нужно использовать или динамический ящик, или передавать номер через 
параметр. Получится как-то так:

Enum e1 = k/DoEnum/e1 /0/.

DoEnum s1 e2 sN = sN k/DoEnum/ e2 k/P1/sN..
  (e1)e2 sN = k/DoEnum-Wrap/ k/DoEnum/ e1 sN. (e2).

DoEnum-Wrap e1 sN (e2) = (e1) k/DoEnum/ e2 sN.

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

 

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

 

From: Василий Стеллецкий swi_AT_cnshb.ru  
Sent: Monday, December 14, 2020 12:47 PM
To: refal@botik.ru
Subject: Re: Запахи кода и антипаттерны в Рефале

 

Добрый день всем!

Я про задачку...
Ну, на мой взгляд не просто для понимания...
На других диалектах Рефала - да пожалуйста!
В этой задаче удобно использовать Ящики или Копилку.
Например с копилкой:

a =/0/k/Enum/ 'abc' (('de') 'f' ('gh') 'ij') 'k'.

Enum s1e2=k/Enum1/k/ВК/'n'..k/Enum/e2.

 (e1)e2=(k/Enum/e1.)k/Enum/e2.

 =

Enum1 =/1/k/ЗК/'n='/2/.

  sn=snk/ЗК/'n='k/P1/sn..

Результат:

S:62 cc=0 M=1024

ПЗ: /0/ /1/ /2/ /3/ ( ( /4/ /5/ ) /6/ ( /7/ /8/ ) /9/ /10/ ) /11/

КОП: ( 'n' '=' /12/ )

(первый /0/ в поле зрения не имеет отношения к задаче, это мой интерфейс)


 

 

-- 
С уважением,

-- 

Василий Стеллецкий

mailto:s...@cnshb.ru    mailto:sw...@narod.ru

 

 

 

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

Доброе утро всем!
 

 1. Выворачивание скобок наизнанку, для организации прохода по выражению.


К представлению объектных выражений этот приём (антиприём) не имеет отношение. 
Он, скорее, характерен для базисного Рефала (Рефала-2), в котором нет ничего 
подобного let-конструкциям (условия, перестройки, действия). И благодаря этому 
сквозному обходу исчезает нужда во вспомогательных функциях, можно обойтись 
одной.

Но, вообще этот приём уродлив, хоть и пропагандировался Турчиным.

 

 2. Боязнь копирования кусков выражений в разные «дочерние» функции.


А в Рефале-5 ещё и в условия.

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

А нет ли в Рефале Плюс другой боязни — боязни конкатенации?


Задача. Заменить в выражении все символы последовательными натуральными числами:

 → 1 2 3 ((4 5) 6 (7 8) 9 10) 11

Решение на Рефале-5λ, эффективное (O(n)) и простое для понимания (на мой 
взгляд):

Enum {
  e.Expr
=  : e.Expr^ s.Num
= e.Expr;
}

DoEnum {
  /* пусто */ s.Num = s.Num;

  s.X e.Expr s.Num = s.Num >;

  (e.Nested) e.Expr s.Num
=  : e.Nested^ s.Num^
= (e.Nested) ;
}

Конструкции = … : … в Enum и в последнем предложении DoEnum неявно 
транслируются в вызов вспомогательной функции. Знак ^ после имени переменной в 
образце означает, что она не повторная. Представление данных — плоское 
списковое, то самое с дорогим копированием и копеечной конкатенацией.

Как будет выглядеть O(n) решение в других диалектах Рефала?


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



-Original Message-
From: Sergei M. Abramov abram_AT_botik.ru mailto:refal@botik.ru> >
Sent: Monday, December 14, 2020 4:27 AM
To: Александр Коновалов a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >
Subject: Re: Запахи кода и антипаттерны в Рефале

День добрый, всем!
 

 А какие вы можете назвать запахи кода и антипаттерны, характерные для
 Рефала?


Все, что вскрывает (или скрывает?) недостатки используемого представления 
объектных выражений и приводит к чудовищному (для
пониманию) кода:

1. Выворачивание скобок наизнанку, для организации прохода по выражению.

2. Боязнь копирования кусков выражений в разные "дочерние" функции.

Этим страдают многия языки. Например, в Эрланге целый культ на тему "стремись к 
хвостовой рекурсии!" и "пиши с аккумулятором, а потом выдай результат, навесив 
на него reverse (Который, видимо, у них написан на не Erlang-е)".

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

С уважением,

Абрамов С.М.
ab...@botik.ru  
мобильный: +7(903)2928308
 

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

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

«Не согласен! Ещё как имеет. Нельзя не думать об эффективности, выбирая шаблоны 
программирования, особенно когда речь не о коэффициенте, а об уменьшении 
сложности, скажем с квадратичной до линейной.»

А где возникает квадратичная сложность при сквозном обходе выражений (т.е. 
выворачивании скобок)? Или где она возникает в других шаблонах решения данной 
задачи (обход выражения в глубину)? На каких представлениях?

 

«Заниматься переписыванием читабельной программы на нечитабельную — это, 
по-моему, как раз пример „антипаттерна“»

Согласен. Но если руководствоваться профилировщиком, корячить приходится не всю 
программу, а только условно 3 %.

 

«IMHO, это есть пример антипаттерна: повторное использование имени для нового 
значения. Я бы здесь обязательно написал е.Expr1. А то легко не понять при 
чтении и ошибиться при рефакторинге.»

Я занимаю прямо противоположную позицию. Когда мы используем знак ^, мы 
говорим, что подменяем старую сущность новой, обновлённой. А городить кучу 
разных пронумерованных переменных для семантически одного и того же — это на 
мой взгляд костыль.

Если пронумерованных переменных несколько, то можно в них запутаться и 
ошибиться при сопровождении программы.

Допустим, у нас есть некоторая сущность, которую нужно как-то обновить два раза 
и использовать:

F {
  … e.Entity …
=  : e.Entity^
=  : e.Entity^
= 
}

Допустим, нам теперь надо упростить структуру после обновлений. Добавляем одну 
строчку:

F {
  … e.Entity …
=  : e.Entity^
=  : e.Entity^
=  : e.Entity^
= 
}

А теперь нам нужно между обновлениями привести её к канонической форме:

F {
  … e.Entity …
=  : e.Entity^
=  : e.Entity^
=  : e.Entity^
=  : e.Entity^
= 
}

А с нумерацией возни будет больше. Исходный вариант:

F {
  … e.Entity …
=  : e.Entity1
=  : e.Entity2
= 
}

Теперь добавляем упрощение:

F {
  … e.Entity …
=  : e.Entity1
=  : e.Entity2
   =  : e.Entity3
= 
}

Нужно не только вставить строчку, но и перенумеровать переменную в последней 
строке. А теперь канонизация:

F {
  … e.Entity …
=  : e.Entity1
=  : e.Entity4
=  : e.Entity2
   =  : e.Entity3
= 
}

Нумерация у меня получилась не по порядку. Но можно придумать и какой-то другой 
номер, например, e.Entity15, типа полтора, или e.Entity1a. Какие-нибудь зануды 
могут перенумеровать все вхождения переменной.

Но проблема не только в выборе номера — проблема в том, что нужно не забыть 
перенумеровать вхождение переменной и в следующей строке тоже. 

Зачем нумеровать вручную, когда это может сделать сам компилятор?

Эта цепочка присваиваний компилятором переписывается во вспомогательные 
функции. Если бы программист вручную писал вспомогательные функции, то никаких 
номеров бы не было:

F {
  … e.Entity … = >;
}

F-FirstUpdated {
  … e.Entity = >;
}

F-Canonized {
  … e.Entity = >;
}

F-SecondUpdated {
  … e.Entity = >;
}

F-Simplified {
  … e.Entity = ;
}

Поэтому номера — отстой!

Если уж не хочется переопределять имена, или язык не позволяет, то лучше давать 
понятные имена разным версиям:

F {
  … e.Entity …
=  : e.Entity-FirstUpdated
=  : e.Entity-Canonized
=  : e.Entity-SecondUpdated
   =  : e.Entity-Simplified
= 
}

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

 

««А нет ли в Рефале Плюс другой боязни — боязни конкатенации?»»
«Нет.»

Ну а как тогда Enum будет записан на Рефале Плюс? Если его дословно переписать 
на Рефале Плюс, не будет ли там квадратичной сложности?

Хвостовой рекурсии там уже точно не будет, глубина вложенности будет 
пропорциональна не вложенности скобок, а длине выражения.

 

«В общие правила, что хорошо, а что плохо, не верю. Надо руководствоваться 
целевым критерием — изменяемостью, сопровождаемость программы. Хорошая 
программа та, которую легко менять, не ошибаясь. И всё.»

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

Но, как я описал в первом письме, эти правила в целом не зависят от языка 
(длинные функции, сложный код, требующий комментариев и т.д.). Интересно 
выделить специфичные для Рефала эвристики.

 

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

 

From: Andrei Klimov andrei_AT_klimov.net  
Sent: Monday, December 14, 2020 11:50 AM
To: refal@botik.ru
Subject: Re: Запахи кода и антипаттерны в Рефале

 

пн, 14 дек. 2020 г., 10:46 Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Доброе утро всем!

> 1.  Выворачивание скобок наизнанку, для организации прохода по выражению.

К представлению объектных выражений этот приём (антиприём) не имеет отношение.

 

Не согласен!

RE: Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро всем!

> 1.  Выворачивание скобок наизнанку, для организации прохода по выражению.

К представлению объектных выражений этот приём (антиприём) не имеет отношение. 
Он, скорее, характерен для базисного Рефала (Рефала-2), в котором нет ничего 
подобного let-конструкциям (условия, перестройки, действия). И благодаря этому 
сквозному обходу исчезает нужда во вспомогательных функциях, можно обойтись 
одной.

Но, вообще этот приём уродлив, хоть и пропагандировался Турчиным.


> 2.  Боязнь копирования кусков выражений в разные «дочерние» функции.

А в Рефале-5 ещё и в условия.

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

А нет ли в Рефале Плюс другой боязни — боязни конкатенации?


Задача. Заменить в выражении все символы последовательными натуральными числами:

 → 1 2 3 ((4 5) 6 (7 8) 9 10) 11

Решение на Рефале-5λ, эффективное (O(n)) и простое для понимания (на мой 
взгляд):

Enum {
  e.Expr
=  : e.Expr^ s.Num
= e.Expr;
}

DoEnum {
  /* пусто */ s.Num = s.Num;

  s.X e.Expr s.Num = s.Num >;

  (e.Nested) e.Expr s.Num
=  : e.Nested^ s.Num^
= (e.Nested) ;
}

Конструкции = … : … в Enum и в последнем предложении DoEnum неявно 
транслируются в вызов вспомогательной функции. Знак ^ после имени переменной в 
образце означает, что она не повторная. Представление данных — плоское 
списковое, то самое с дорогим копированием и копеечной конкатенацией.

Как будет выглядеть O(n) решение в других диалектах Рефала?


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



-Original Message-
From: Sergei M. Abramov abram_AT_botik.ru  
Sent: Monday, December 14, 2020 4:27 AM
To: Александр Коновалов a.v.konovalov87_AT_mail.ru 
Subject: Re: Запахи кода и антипаттерны в Рефале

День добрый, всем!

> А какие вы можете назвать запахи кода и антипаттерны, характерные для 
> Рефала?

Все, что вскрывает (или скрывает?) недостатки используемого представления 
объектных выражений и приводит к чудовищному (для
пониманию) кода:

1.  Выворачивание скобок наизнанку, для организации прохода по выражению.

2.  Боязнь копирования кусков выражений в разные "дочерние" функции.

Этим страдают многия языки.  Например, в Эрланге целый культ на тему "стремись 
к хвостовой рекурсии!" и "пиши с аккумулятором, а потом выдай результат, 
навесив на него reverse (Который, видимо, у них написан на не Erlang-е)".

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

С уважением,

Абрамов С.М.
ab...@botik.ru
мобильный: +7(903)2928308

Запахи кода и антипаттерны в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброй ночи всем!

Давайте обсудим, какие есть запахи кода и антипаттерны в Рефале. Но сначала 
приведу определения, т.к. с терминами в рассылке могут быть знакомы не все. 
Если термины знаете, можете промотать кусок письма.

 

Определения

Есть два близких, но разных понятия: запахи кода и антипаттерны.

Запах кода — эвристический признак того, что в программе есть какие-то 
проблемы. Например, какие-то участки программы сложны для восприятия, или более 
подвержены ошибкам. Борьба с запахом кода — рефакторинг, т.е. улучшение 
внутренней структуры программы без изменения видимого поведения.

Примеры запахов в ООП: дублирование кода, длинный класс, длинный метод, длинные 
списки параметров, параллельные иерархии наследования, мёртвый код…

Подробнее:

https  
://ru.wikipedia.org/wiki/Код_с_запашком
https://refactoring.guru/ru/refactoring/smells

Код с запахом плох тем, что в нём повышается вероятность ошибок. Если класс 
слишком большой или метод слишком длинный, то понять его сложнее, а значит, 
проще допустить ошибку. Если в программе код повторяется, то при внесении 
изменений в него нужно согласованно поправить все копии, но по ошибке некоторые 
можно пропустить. 

Антипаттерн — это распространённый подход к решению класса часто встречающихся 
проблем, являющийся неэффективным, рискованным или непродуктивным (определение 
из Википедии). Т.е. распространённая, но плохая «идиома» программирования.

Примеры антипаттернов: программирование методом копипаста, магические 
константы, спагетти-код (слишком запутанная логика), лазанья-код (слишком много 
слоёв абстракции), зависимости по побочному эффекту, жёсткое кодирование (hard 
code) — зашивание в код того, что должно быть вынесено в конфигурацию, мягкое 
кодирование (soft code) — в конфигурацию вынесено слишком много, 
конфигурирование само по себе превращается в программирование.

Подробнее:

https  
://ru.wikipedia.org/wiki/Антипаттерн

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

 

Запахи и антипаттерны в Рефале

Из запахов кода в Рефале я могу перечислить только платформенно-независимые. 
Т.е. взяв уже упомянутый список 
  с refactoring.guru и 
вычеркнув из него вещи, характерные для ООП:

* Длинная функция. Менее актуально для Рефала-2, более актуально для 
других диалектов. В Рефале-2 функция может быть длинной или из-за обилия 
предложений, или из-за длины самих выражений в левой и правой части. В других 
диалектах Рефала функция может расти в длину из-за обилия управляющих 
конструкций, таких как условия, блоки, присваивания, действия… В Рефале-5λ 
вообще можно писать вложенные функции, например, внутри Map, и их тоже можно 
написать длинными.

* Большой класс. В Рефале нет классов. Но можно сказать, что если файл 
с исходным текстом длинный, значит в нём намешано много всего и его, возможно, 
стоит разделить на несколько с разными подмножествами функций.

* Длинный список параметров. Если в формате функции много полей, 
значит, она сложна или имеется невыявленная абстракция (см. следующий пункт).

* Группы данных. Можно передавать какие-то значения в виде отдельных 
кусков, а не сгруппировав их в некоторую абстракцию. Например, компилятор 
отслеживает номер строки, номер символа в строке и имя файла для указания 
точного места в сообщениях об ошибке. Можно их передавать как s.Line s.Col 
e.FileName, а можно передавать как t.Pos, внутри которого лежат искомые 
значения.

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

* Комментарии. Имеются ввиду комментарии, которые объясняют, как 
работает сложный участок кода. Нужно переписать код так, чтобы он стал понятен 
без комментариев — дать переменным и функциям более понятные имена, разнести 
логику по отдельным функциям с ясными именами и т.д.

* Дублирование кода — тут всё понятно.

* Мёртвый код — в результате развития в программе появился код, который 
никогда не выполняется. Его надо удалить.

* Теоретическая общность. Задача была решена с запасом на будущее, хотя 
решение для частного случая было бы проще и компактнее. Время показало, что 
этот запас оказался избыточен.

Остальные пункты относятся только к ООП.

Каких-то запахов кода, характерных именно для Рефала, я назвать не могу.

 

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

https  
://ru.wikipedia.org/wiki/Антипаттерн#Антипаттерны_в_кодировании

к Рефалу применима где-то п

RE: Сравнение веток Рефала

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Не, лучше весной, поскольку практика летняя. Сейчас пока рано.

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru] 
Sent: Friday, December 11, 2020 12:51 PM
To: refal@botik.ru
Cc: fro...@nicevt.ru
Subject: Re: Сравнение веток Рефала

 

Отлично, можем и пораньше, как восстановлюсь.

 

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

Замечательно! Ближе к лету обсудим тогда.

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru]
Sent: Friday, December 11, 2020 12:37 PM
To: refal@botik.ru  ; 'Александр Гусев' 
mailto:gusev_aleksa...@mail.ru> >
Cc: fro...@nicevt.ru  
Subject: Re: Сравнение веток Рефала

 

А вот это здорово, могли бы их подключить к работам в первую очередь Модуля. 
Они сейчас сложную микросхему разрабатывают, должны получить заказ на 7.6 млрд 
рублей. Там для программистов также много работы. Я отдел системного 
программирования консультирую, ввел туда своих бывших сотрудников очень 
квалифицированные. Модуль их даже обычно берет по договорам, т.е. оплачивает 
работу. Тематику они определят.

 

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

Леонид!

Если понадобится, наша кафедра может обеспечить Вам студентов на летнюю 
практику. Студенты у нас умеют программировать на нескольких языках и быстро 
осваивать новые. У нас вообще способные ребята. Сам порой думаю: кто кого здесь 
учить должен, я их или они меня.

 

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

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru]
Sent: Friday, December 11, 2020 11:08 AM
To: Александр Гусев mailto:gusev_aleksa...@mail.ru> 
>; refal@botik.ru  
Cc: fro...@nicevt.ru  
Subject: Re: Сравнение веток Рефала

 

Про эту реализацию что-то не знаю. Упустил. Интересно, вкратце, понять. Что 
почитать?

Все одиночки и одиночки... Мы в Модуле и Кванте начали процесс самоорганизации 
по экспериментальным работам в области СКТ и ИИ (это в соответствии с тем, что 
было опубликовано в прошлом году в журнале "Вопросы кибербезопасности", N4, 
статья в соавторстве с Генеральным директором Модуля А.А.Адамовым и зам.по 
микроэлектронике Д.В.Фоминым). Пока идея организовать на базе уже ведущихся 
работ Межведомственную Высшую Школу по экспериментальным СКТ. Что за  словом 
"организовать" сам пока приблизительно представляю, но работы уже идут в тех 
организационных рамках, что есть. Что будет нового в организационном плане - 
раздумываю, есть варианты. Пока лишь знаю, что надо искать неравнодушных людей, 
энтузиастов. Брать либо в тематику, что идет, либо расширяться. Помогать хотя 
бы с публикациями.

Л.Эйсымонт

 

11.12.2020, 10:47, "Александр Гусев gusev_aleksandr_AT_mail.ru" mailto:refal@botik.ru> >:

Доброй пятницы, коллеги!

 

Я свои разработки не забросил продолжаю заниматься. Информацию не выкладывал 
никуда кроме конференции 2019 года, хотелось сначала запустить и предоставить 
интерфейс в сети. Но события 2020 года несколько смешали планы.

Тем не менее сервер вполне уже «дышит», сейчас делаю для него локальный 
пользовательский интерфейс, пару дней осталось делать. Далее сетевой добавить и 
уже хорошо должно быть.

Есть особенности в реализации языка и сама идея как всё работает для Рефала 
нетрадиционная. Я готов предоставить информацию, только не знаю, в какой форме 
это лучше сделать. Основная проблема в том, что я занимаюсь этим по-прежнему 
один. Всё сразу успеть не получается.
 

Пятница, 11 декабря 2020, 10:04 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:
 

Леонид!

Наверное, стоит эту статью полностью с нуля переписать и опубликовать в более 
серьёзном журнале (почитайте статью, которая следует сразу за моей 😁🤦♂️).

……

 

пт, 8 февр. 2019 г. в 23:43, Александр Гусев gusev_aleksandr_AT_mail.ru 
mailto:refal@botik.ru> >:

Аркадий, Спасибо за ответ!

Да, я читал переписку, не до самых глубин, конечно.

Пока прошу актуальную ссылку на Рефал-6 - почитать и хоть что-то попробовать, 
если возможно. Вроде Hello, world на трёх языках.

То, что я имел ввиду о музыке, это тоже формульные вычисления, конечно.

Возможно, но наверно уже на "символьном уровне", до которого еще надо входной 
сигнал поднять. 


С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 
 

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 
 

 

 

С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 

RE: Сравнение веток Рефала

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Замечательно! Ближе к лету обсудим тогда.

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru] 
Sent: Friday, December 11, 2020 12:37 PM
To: refal@botik.ru; 'Александр Гусев' 
Cc: fro...@nicevt.ru
Subject: Re: Сравнение веток Рефала

 

А вот это здорово, могли бы их подключить к работам в первую очередь Модуля. 
Они сейчас сложную микросхему разрабатывают, должны получить заказ на 7.6 млрд 
рублей. Там для программистов также много работы. Я отдел системного 
программирования консультирую, ввел туда своих бывших сотрудников очень 
квалифицированные. Модуль их даже обычно берет по договорам, т.е. оплачивает 
работу. Тематику они определят.

 

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

Леонид!

Если понадобится, наша кафедра может обеспечить Вам студентов на летнюю 
практику. Студенты у нас умеют программировать на нескольких языках и быстро 
осваивать новые. У нас вообще способные ребята. Сам порой думаю: кто кого здесь 
учить должен, я их или они меня.

 

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

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru]
Sent: Friday, December 11, 2020 11:08 AM
To: Александр Гусев mailto:gusev_aleksa...@mail.ru> 
>; refal@botik.ru  
Cc: fro...@nicevt.ru  
Subject: Re: Сравнение веток Рефала

 

Про эту реализацию что-то не знаю. Упустил. Интересно, вкратце, понять. Что 
почитать?

Все одиночки и одиночки... Мы в Модуле и Кванте начали процесс самоорганизации 
по экспериментальным работам в области СКТ и ИИ (это в соответствии с тем, что 
было опубликовано в прошлом году в журнале "Вопросы кибербезопасности", N4, 
статья в соавторстве с Генеральным директором Модуля А.А.Адамовым и зам.по 
микроэлектронике Д.В.Фоминым). Пока идея организовать на базе уже ведущихся 
работ Межведомственную Высшую Школу по экспериментальным СКТ. Что за  словом 
"организовать" сам пока приблизительно представляю, но работы уже идут в тех 
организационных рамках, что есть. Что будет нового в организационном плане - 
раздумываю, есть варианты. Пока лишь знаю, что надо искать неравнодушных людей, 
энтузиастов. Брать либо в тематику, что идет, либо расширяться. Помогать хотя 
бы с публикациями.

Л.Эйсымонт

 

11.12.2020, 10:47, "Александр Гусев gusev_aleksandr_AT_mail.ru" mailto:refal@botik.ru> >:

Доброй пятницы, коллеги!

 

Я свои разработки не забросил продолжаю заниматься. Информацию не выкладывал 
никуда кроме конференции 2019 года, хотелось сначала запустить и предоставить 
интерфейс в сети. Но события 2020 года несколько смешали планы.

Тем не менее сервер вполне уже «дышит», сейчас делаю для него локальный 
пользовательский интерфейс, пару дней осталось делать. Далее сетевой добавить и 
уже хорошо должно быть.

Есть особенности в реализации языка и сама идея как всё работает для Рефала 
нетрадиционная. Я готов предоставить информацию, только не знаю, в какой форме 
это лучше сделать. Основная проблема в том, что я занимаюсь этим по-прежнему 
один. Всё сразу успеть не получается.
 

Пятница, 11 декабря 2020, 10:04 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:
 

Леонид!

Наверное, стоит эту статью полностью с нуля переписать и опубликовать в более 
серьёзном журнале (почитайте статью, которая следует сразу за моей 😁🤦♂️).

……

 

пт, 8 февр. 2019 г. в 23:43, Александр Гусев gusev_aleksandr_AT_mail.ru 
mailto:refal@botik.ru> >:

Аркадий, Спасибо за ответ!

Да, я читал переписку, не до самых глубин, конечно.

Пока прошу актуальную ссылку на Рефал-6 - почитать и хоть что-то попробовать, 
если возможно. Вроде Hello, world на трёх языках.

То, что я имел ввиду о музыке, это тоже формульные вычисления, конечно.

Возможно, но наверно уже на "символьном уровне", до которого еще надо входной 
сигнал поднять. 


С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 
 

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 
 

 

 

С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

RE: Сравнение веток Рефала

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Леонид!

Если понадобится, наша кафедра может обеспечить Вам студентов на летнюю 
практику. Студенты у нас умеют программировать на нескольких языках и быстро 
осваивать новые. У нас вообще способные ребята. Сам порой думаю: кто кого здесь 
учить должен, я их или они меня.

 

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

 

From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru] 
Sent: Friday, December 11, 2020 11:08 AM
To: Александр Гусев ; refal@botik.ru
Cc: fro...@nicevt.ru
Subject: Re: Сравнение веток Рефала

 

Про эту реализацию что-то не знаю. Упустил. Интересно, вкратце, понять. Что 
почитать?

Все одиночки и одиночки... Мы в Модуле и Кванте начали процесс самоорганизации 
по экспериментальным работам в области СКТ и ИИ (это в соответствии с тем, что 
было опубликовано в прошлом году в журнале "Вопросы кибербезопасности", N4, 
статья в соавторстве с Генеральным директором Модуля А.А.Адамовым и зам.по 
микроэлектронике Д.В.Фоминым). Пока идея организовать на базе уже ведущихся 
работ Межведомственную Высшую Школу по экспериментальным СКТ. Что за  словом 
"организовать" сам пока приблизительно представляю, но работы уже идут в тех 
организационных рамках, что есть. Что будет нового в организационном плане - 
раздумываю, есть варианты. Пока лишь знаю, что надо искать неравнодушных людей, 
энтузиастов. Брать либо в тематику, что идет, либо расширяться. Помогать хотя 
бы с публикациями.

Л.Эйсымонт

 

11.12.2020, 10:47, "Александр Гусев gusev_aleksandr_AT_mail.ru" mailto:refal@botik.ru> >:

Доброй пятницы, коллеги!

 

Я свои разработки не забросил продолжаю заниматься. Информацию не выкладывал 
никуда кроме конференции 2019 года, хотелось сначала запустить и предоставить 
интерфейс в сети. Но события 2020 года несколько смешали планы.

Тем не менее сервер вполне уже «дышит», сейчас делаю для него локальный 
пользовательский интерфейс, пару дней осталось делать. Далее сетевой добавить и 
уже хорошо должно быть.

Есть особенности в реализации языка и сама идея как всё работает для Рефала 
нетрадиционная. Я готов предоставить информацию, только не знаю, в какой форме 
это лучше сделать. Основная проблема в том, что я занимаюсь этим по-прежнему 
один. Всё сразу успеть не получается.
 

Пятница, 11 декабря 2020, 10:04 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:
 

Леонид!

Наверное, стоит эту статью полностью с нуля переписать и опубликовать в более 
серьёзном журнале (почитайте статью, которая следует сразу за моей 😁🤦♂️).

……

 

пт, 8 февр. 2019 г. в 23:43, Александр Гусев gusev_aleksandr_AT_mail.ru 
mailto:refal@botik.ru> >:

Аркадий, Спасибо за ответ!

Да, я читал переписку, не до самых глубин, конечно.

Пока прошу актуальную ссылку на Рефал-6 - почитать и хоть что-то попробовать, 
если возможно. Вроде Hello, world на трёх языках.

То, что я имел ввиду о музыке, это тоже формульные вычисления, конечно.

Возможно, но наверно уже на "символьном уровне", до которого еще надо входной 
сигнал поднять. 


С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 
 

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 
 

 

 

С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

RE: Re[2]: Сравнение веток Рефала

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Александр!

«Я готов предоставить информацию, только не знаю, в какой форме это лучше 
сделать.»

Выложите на GitHub с длиннющим README.md, или напишите длинное письмо сюда.

«Основная проблема в том, что я занимаюсь этим по-прежнему один.»

Аналогичная проблема. У меня, правда, есть возможность привлекать студентов в 
добровольно-принудительном порядке. Студенты нехотя, но идут. Иногда за 
студентами приходится переписывать, т.к. у них мало опыта в программировании на 
Рефале и код получается неоптимальным.

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Friday, December 11, 2020 10:47 AM
To: refal@botik.ru
Cc: fro...@nicevt.ru
Subject: Re[2]: Сравнение веток Рефала

 

Доброй пятницы, коллеги!

 

Я свои разработки не забросил продолжаю заниматься. Информацию не выкладывал 
никуда кроме конференции 2019 года, хотелось сначала запустить и предоставить 
интерфейс в сети. Но события 2020 года несколько смешали планы.

Тем не менее сервер вполне уже «дышит», сейчас делаю для него локальный 
пользовательский интерфейс, пару дней осталось делать. Далее сетевой добавить и 
уже хорошо должно быть.

Есть особенности в реализации языка и сама идея как всё работает для Рефала 
нетрадиционная. Я готов предоставить информацию, только не знаю, в какой форме 
это лучше сделать. Основная проблема в том, что я занимаюсь этим по-прежнему 
один. Всё сразу успеть не получается.
 

Пятница, 11 декабря 2020, 10:04 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:
 

Леонид!

Наверное, стоит эту статью полностью с нуля переписать и опубликовать в более 
серьёзном журнале (почитайте статью, которая следует сразу за моей 😁🤦♂️).

……

 

пт, 8 февр. 2019 г. в 23:43, Александр Гусев gusev_aleksandr_AT_mail.ru 
mailto:refal@botik.ru> >:

Аркадий, Спасибо за ответ!

Да, я читал переписку, не до самых глубин, конечно.

Пока прошу актуальную ссылку на Рефал-6 - почитать и хоть что-то попробовать, 
если возможно. Вроде Hello, world на трёх языках.

То, что я имел ввиду о музыке, это тоже формульные вычисления, конечно.

Возможно, но наверно уже на "символьном уровне", до которого еще надо входной 
сигнал поднять. 


С уважением,
Александр Гусев
gusev_aleksa...@mail.ru 
 

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

 

--

___

С уважением, 

Аркадий Климов,
с.н.с. ИППМ РАН,
+7(499)135-32-95
+7(916)072-81-48



С уважением,
Александр Гусев
gusev_aleksa...@mail.ru

 

 

С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

 

RE: Поздравляем Андрея Петровича Немытых с юбилеем!

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Дорогой Андрей Петрович!

Я присоединяюсь к поздравлениям Вашего коллеги. Хочу пожелать счастья, 
здоровья, творческих успехов и условий для творческих успехов! Ведь «служенье 
муз не терпит суеты».

 

Всего самого лучшего!
Александр Коновалов

 

From: Andrei Klimov andrei_AT_klimov.net  
Sent: Friday, October 9, 2020 5:39 PM
To: refal@botik.ru
Subject: Поздравляем Андрея Петровича Немытых с юбилеем!

 

Дорогой Андрей Петрович,

 

От имени всего рефал-сообщества позвольте поздравить Вас со знаменательной 
датой, которая символизирует Вашу зрелость, мудрость и большую историю успехов!

 

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

 

С уважением,

Андрей Климов

Третье рабочее совещание ИПС РАН и МГТУ по Рефалу (онлайн!)

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

Завтра, в пятницу, 12 июня 2020 года в 12:00 в МГТУ имени Н.Э. Баумана пройдёт

Третье совместное рабочее совещание
ИПС имени А.К. Айламазяна РАН
и
МГТУ имени Н.Э. Баумана
по функциональному языку программирования Рефал

С докладами выступит сотрудники ИПС и преподаватели и студенты МГТУ. Совещание 
посвящено языку программирования Рефал и метавычислениям над ним.

Программа мероприятия доступна по ссылке:

https://bmstu-iu9.github.io/IPSRAN-MGTU-seminar-12-06-2020.pdf

Подробные аннотации докладов продублированы в конце письма.

Мероприятие в этом году проходит в онлайн-формате — в виде вебинара. Но, 
традиционно в МГТУ, в данном случае — на сервере вебинаров университета:

http://webinar.bmstu.ru/b/7wk-623-eqj

Продолжительность совещания с 12:00 до 16:00.

Вебинар работает прямо из браузера, дополнительное ПО устанавливать не нужно. 
Регистрация не обязательна, достаточно пройти по ссылке. 

 

До встречи!
Александр Коновалов

 

Аннотации докладов:

Первая сессия (председатель Антонина Непейвода), посвящена древесным 
оптимизациям в компиляторе Рефала-5λ.

1.Александр Коновалов «Древесные оптимизации в компиляторе Рефала-5λ: итоги 
и перспективы»

Компилятор Рефала-5λ поддерживает две оптимизации, работающие на уровне 
синтаксического дерева: специализация и прогонка. Оба механизма оптимизируют 
вызовы помеченных функций.

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

Компилятор позволяет выводить в файл журнала синтаксическое дерево программы до 
и после оптимизации в виде псевдокода на Рефале. Благодаря этому древесные 
оптимизации позволяют использовать Рефал-5λ для простых экспериментов по 
трансформации программ.

В докладе рассказывается о том, на что способны эти оптимизации, а также про 
перспективы их дальнейшего развития. 

2.Андрей Кошелев «Использование отношения Хигмана-Крускала для прерывания 
рекурсивной специализации функций»

В ряде случаев применение специализации функций может привести к зацикливанию 
компилятора.

В работе рассматривается решение проблемы зацикливания рекурсивной 
специализации. Для этого предлагается использовать отношение Хигмана-Крускала, 
применяемое при решении похожей проблемы в суперкомпиляции. 

3.Елена Калинина «Автоматическая разметка оптимизируемых функций»

Высокоуровневые языки программирования, в том числе и Рефал-5λ, содержат в себе 
много абстрактных программистских конструкций — они делают процесс написания 
кода для человека максимально удобным, но снижают скорость работы программы. 
Поэтому компиляторы стараются автоматически оптимизировать код. Есть множество 
разных видов оптимизаций, но мы сосредоточимся на двух из них: прогонке и 
специализации. Они уже реализованы в компиляторе Рефала-5λ, однако маркировка 
функций, которые нужно оптимизировать по-прежнему остаётся задачей 
программиста. Автоматическая разметка сняла бы эту ответственность и позволила 
бы больше фокусироваться на написании поддерживаемого кода, чем заниматься 
ручными оптимизациями. По сути программист сможет сосредоточиться на решении 
конкретных задач, оставив монотонный однотипный труд компьютеру.

Темой данного доклада и будет являться добавление в компилятор Рефала-5λ 
корректной и безопасной автоматической разметки прогоняемых и 
специализированных функций.

 

Вторая сессия (председатель Александр Коновалов), больше посвящена языкам 
образцов и их использованию для диагностики ошибок в программе. Но один доклад 
про древесную оптимизацию в неё тоже затесался.

4.Антонина Непейвода «Языки образцов в анализе Рефал-программ»

Языки образцов (pattern languages) исследуются в computer science с 1980-х 
годов, в первую очередь в контексте поиска наиболее точного образца, язык 
которого включает заданное множество строк. Доклад представляет собой обзор 
некоторых из этих исследований — они оказываются применимы для анализа 
рефал-программ. В частности, будет рассмотрено, какие свойства левых частей 
рефал-программы могут указывать на хорошую применимость к ней стандартных 
методов суперкомпиляции, а какие — на возможность плодотворного использования 
альтернативного подхода, использующего современные наработки в области языков 
образцов. 

5.Александр Барлука «Распознавание экранируемых предложений в программе на 
Рефале-5λ»

Предложение в программе может не выполняться, если его левая часть 
(образец+условия) описывает множество аргументов, являющихся подмножеством 
другого предложения, записанного выше. В таких случаях мы будем говорить, что 
одно предложение экранирует другое. Экранирующие предложения такого вида в 
исходных текстах программ могут быть написаны только по ошибке.

Предлагается добавить в компилятор Рефала-5λ проверку предупреждений об 
экранировании для упрощения отладки и написания программ. 

6.Ханага Аг

RE: Об ИЛИ-параллелизме (Re: Re[2]: Семинар по метавычислениям ...)

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Аркадий!

А ведь ключевым новшеством параллельного Рефала-05 является распараллеливание с 
сохранением порядка нечистых функций. Решилось практически ТРИЗовское 
противоречие: функции должны выполняться параллельно для производительности, 
функции должны выполняться последовательно из-за побочного эффекта.

Причём распараллеливание сугубо динамическое — до вызова функции неизвестно, 
чистая она или нет.

PutLog {
  NoLog e.Message = /* ничего не делаем */;
  s.Log e.Message =  ': ' e.Message>;
}

F {
  … s.Log … = …  …
}

В зависимости от значения s.Log, которое может передаваться откуда-то извне, 
функция PutLog является либо чистой, либо нечистой. И, если программа работает 
с отключённым логом (в функции передаётся NoLog) вычисления распараллеливаться 
будут. Если лог включить (будет передаваться номер открытого файла), то 
параллелизм сразу же просядет, т.к. в лог будет писаться последовательно.

 

ИЛИ-параллелизм ставит новое противоречие (тоже в духе ТРИЗ): отменённые 
вычисления не должны выполняться ради производительности, отменённые вычисления 
должны выполняться ради побочного эффекта. Как разрешить противоречие — пока не 
понятно. ТРИЗ учит нас, что если задачу решить не получается, можно попробовать 
подняться на ступеньку выше. Действительно, «отменённая» задача — это деталь 
реализации.

Попробую сформулировать постановку задачи для Рефала-05. Формулировка Аркадия 
не очень хорошо подходит, т.к. в Рефале-05 нет неуспехов (и не планируется). 
Можно описать такой примитив:


  == /* пусто */
  == t.Res


  == /* пусто */
  == t.Res

Функция OR принимает два указателя на функции с их аргументами. Каждая из этих 
функций может или вернуть пустоту, или терм. Если обе функции вернули пустоту, 
то OR возвращает пустоту. Если хотя бы одна из функций вернула терм, то 
возвращается терм. Если обе функции вернули по терму, то возвращается какой-то 
из двух. Псевдокод:

OR {
  (s.Func1 e.Arg1) (s.Func2 e.Arg2)
=  >;
}

OR-Select {
  /* пусто */ = /* пусто */;
 t.OneTerm = t.OneTerm;
  t.Term1 t.Term2 = ; 
}

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

 

Иногда различают параллельное и конкурентное программирование. Параллельность — 
задачи выполняются одновременно, независимо и не взаимодействуют между собой. 
Пример: вычисление на GPU, векторные машинные инструкции. Конкурентность — 
имеем несколько потоков управления, которые могут выполняться 
поочерёдно/одновременно, побочные эффекты их перемежаются. Чуть подробнее 
почитать можно, например, здесь  .

То, что реализовано в Рефале-05, это параллельное программирование. Если 
добавить в язык примитив для запуска нового потока, примитивы синхронизации 
вроде мьютексов, каналов, мониторов и т.д., то это уже средства конкурентного 
программирования.

В рамках конкурентного программирования ИЛИ-параллелизм вполне осуществим. Для 
этого нужен канал, глобальный флаг и вспомогательный поток. Вспомогательный 
поток сидит на канале и ждёт, когда в нём что-то появится. Как только 
появилось, он устанавливает глобальный флаг. Рабочие потоки периодически 
проверяют глобальный флаг, если он выставлен, то себя завершают, если нет, 
продолжают работать. Когда рабочий поток вычислил значение, он его кладёт в 
канал. Таким образом, из канала будет прочитано значение, положенное в него тем 
потоком, который завершился раньше. Глобальный флаг нужен для оптимизации, 
чтобы досрочно завершить другие рабочие потоки. Но это слишком низкоуровнево.

 

Хотелось бы иметь высокоуровневый примитив вроде OR, записанного выше. 
Противоречие на ступеньку выше — при вызове OR должна вычисляться только одна 
из двух функций (т.к. требуется только один результат), и должны вычисляться 
обе функции, т.к. у них обоих могут быть побочные эффекты. Не знаю, разрешима 
ли эта задача.

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Tuesday, May 26, 2020 6:59 PM
To: refal@botik.ru
Subject: Об ИЛИ-параллелизме (Re: Re[2]: Семинар по метавычислениям ...)

 

Да, конечно, это непросто. Я обычно предполагал, что при порождении ИЛИ-группы 
будет создаваться некий общий объект типа Bool, который сбрасывается, когда 
кто-то закончит, и он всем по ссылке передается, чтобы поглядывали, и если он 
сброшен, то пора отменяться. Насчет вложенности особо не думал пока.

Аркадий

 

вт, 26 мая 2020 г. в 00:07, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Доброй ночи, Аркадий!

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

RE: Справочник по Рефалу-5λ

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро всем!

По совету Бойко я добавил содержание в справочник:

https://bmstu-iu9.github.io/refal-5-lambda/B-reference.html

Стало гораздо лучше! Самому нравится!

Но добавил я оглавление не только в справочник, но и в другие страницы 
руководства:

https://bmstu-iu9.github.io/refal-5-lambda/

А также в документацию к другим своим проектам:

https://mazdaywik.github.io/Refal-05/
https://mazdaywik.github.io/refal-5-framework/

(да, это небольшая реклама)

 

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

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Tuesday, April 21, 2020 11:49 AM
To: refal@botik.ru
Subject: RE: Справочник по Рефалу-5λ

 

Добрый день, Бойко!

Спасибо за отзыв! Согласен, оглавления не хватает.

Страница сделана на GitHub Pages — в репозитории в папке docs создаётся файл в 
разметке Markdown и по нему автоматически создаётся web-страница. Но 
стандартной функциональности для создания оглавлений в GH Pages нет.

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

 

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

 

From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Tuesday, April 21, 2020 10:48 AM
To: refal@botik.ru  
Subject: Re: Справочник по Рефалу-5λ

 

Поздравляю Вас, Александр!

Появление документации – важная веха в развитии любой программы,
тем более такой непростой как в Вашем случае.

Вероятно, стоит снабдить текст содержанием (оглавлением),

и тем лучше, если с гиперссылками.

Бойко

 

 

On Mon, 20 Apr 2020 at 17:36, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Добрый день всем!

В рассылке я часто упоминал Рефал-5λ, иногда публиковал ссылку на репозиторий с 
исходниками. Но вот нормальной документации к нему пока не было.

И вот она появилась:

https://bmstu-iu9.github.io/refal-5-lambda/B-reference.html

В справочнике есть почти полное описание языка (не раскрыты только $DRIVE и 
$SPEC), инструкция по использованию компилятора и описание отладочных средств. 
Библиотека встроенных функций там не описана, поскольку она та же самая, что и 
у классического Рефала-5.

Ну, в общем, теперь на Рефале-5λ может программировать не только автор 😀.

 

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

 

RE: Справочник по Рефалу-5λ

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Бойко!

Спасибо за отзыв! Согласен, оглавления не хватает.

Страница сделана на GitHub Pages — в репозитории в папке docs создаётся файл в 
разметке Markdown и по нему автоматически создаётся web-страница. Но 
стандартной функциональности для создания оглавлений в GH Pages нет.

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

 

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

 

From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Tuesday, April 21, 2020 10:48 AM
To: refal@botik.ru
Subject: Re: Справочник по Рефалу-5λ

 

Поздравляю Вас, Александр!

Появление документации – важная веха в развитии любой программы,
тем более такой непростой как в Вашем случае.

Вероятно, стоит снабдить текст содержанием (оглавлением),

и тем лучше, если с гиперссылками.

Бойко

 

 

On Mon, 20 Apr 2020 at 17:36, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Добрый день всем!

В рассылке я часто упоминал Рефал-5λ, иногда публиковал ссылку на репозиторий с 
исходниками. Но вот нормальной документации к нему пока не было.

И вот она появилась:

https://bmstu-iu9.github.io/refal-5-lambda/B-reference.html

В справочнике есть почти полное описание языка (не раскрыты только $DRIVE и 
$SPEC), инструкция по использованию компилятора и описание отладочных средств. 
Библиотека встроенных функций там не описана, поскольку она та же самая, что и 
у классического Рефала-5.

Ну, в общем, теперь на Рефале-5λ может программировать не только автор 😀.

 

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

 

Справочник по Рефалу-5λ

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

В рассылке я часто упоминал Рефал-5λ, иногда публиковал ссылку на репозиторий с 
исходниками. Но вот нормальной документации к нему пока не было.

И вот она появилась:

https://bmstu-iu9.github.io/refal-5-lambda/B-reference.html

В справочнике есть почти полное описание языка (не раскрыты только $DRIVE и 
$SPEC), инструкция по использованию компилятора и описание отладочных средств. 
Библиотека встроенных функций там не описана, поскольку она та же самая, что и 
у классического Рефала-5.

Ну, в общем, теперь на Рефале-5λ может программировать не только автор 😀.

 

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

 

RE: Сортировка в Рефале-5

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро!

«Так точно. Нулевое время при повторной проверке на равенство (мемоизация) и 
освобождение пямяти. И это реализуемо во всех представлениях выражений с 
„подвешенными“ скобками.»

Если две пары скобок равны по содержимому, то какой какому присваивать? Можно, 
например, использовать лес непересекающихся множеств:

https://ru.wikipedia.org/wiki/Лес_непересекающихся_множеств

Либо использовать более простую эвристику: выбирать тот, у которого указатель 
численно меньше — это может быть удобнее для тех реализаций, которые границы 
хранят непосредственно в узле.


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

RE: Сортировка в Рефале-5

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Сергей Михайлович!

«то оба терма-скобок делаются „такими же“  — в смысле указывают на одно место и 
имеют равную длину.»

И таким образом ещё и может экономиться память: вторая ссылка на равный 
скобочный терм может оказаться ненужной и удалиться как мусор.


Ещё можно показать, что эти две функции реверса списка эквивалентны:

nrev [] = []
nrev x:xs = (nrev xs) ++ [x]


arev xs = arevLoop xs []
arevLoop [] acc = acc
arevLoop x:xs acc = arevLoop xs (x:acc)

Первая имеет квадратичную сложность, вторая — линейную.

Не уверен, можно ли одну привести к другой эквивалентными преобразованиями 
Бёрстола и Дарлингтона, но (а) можно их эквивалентность доказать на Идрисе 
(https://habr.com/ru/post/463957/), (б) Гамильтон каким-то образом выводил 
второе из первого при помощи своей туманной «дистилляции».


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

-Original Message-
From: Sergei M. Abramov abram_AT_botik.ru [mailto:refal@botik.ru] 
Sent: Friday, April 10, 2020 12:31 PM
To: Василий Стеллецкий swi_AT_cnshb.ru 
Subject: Re: Сортировка в Рефале-5

День добрый, всем!

> Вряд ли такое возможно, Александр!
> Интуиция подсказывает, что при "элементарных" преобразованиях порядок 
> сложности алгоритма не должен измениться... --

Колапсирующие джунгли порядок меняют, и понятно почему.

Ну, и ручками, мемоизация (а именно ее колапс поднимает) позволяет изменить 
порядок.


PS.  К слову, в рефале плюс встроены колапсирующие джунгли над
данными: если понадобилось сравнить два терма-скобок (а скобки у нас
подвешенны) и они оказались равными, то оба терма-скобок делаются "такими же" 
-- в смысле указывают на одно место и имеют равную длину.

То есть, термы становятся не просто "равный", а "тот же ссамый".

С уважением,

Абрамов С.М.
ab...@botik.ru
мобильный: +7(903)2928308

Сортировка в Рефале-5

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

Подумалось тут, что можно на Рефале-5 легко написать короткую, но очень 
неэффективную функцию сортировки:

/*
   == e.Items
  e.Items ::= (s.Key e.Value)*
  s.Key ::= s.NUMBER
*/
Sort {
  e.L (s.KeyBig e.ValBig) (s.KeySmall e.ValSmall) e.R
,  : '+'
= ;

  e.Sorted = e.Sorted;
}

Пояснение по Рефалу-5. Функция Compare принимает два числа и возвращает знак их 
разности. Таким образом, условие  : '+' 
утверждает, что разность s.KeyBig и s.KeySmall положительна, т.е. первое больше 
второго.

Сортировка стабильная — она не меняет порядок пар с равными ключами. Сложность 
алгоритма O(n³), где n — длина аргумента.

Рассмотрим следующий алгоритм сортировки вставками:

InsertSort {
  e.Items = ;
}

DoInsertSort {
  (e.Sorted) t.Next e.Rest
= ) e.Rest>;

  (e.Sorted) /* пусто */ = e.Sorted;
}

Insert {
  e.Sorted (s.KeyLast e.ValLast) (s.KeyNew e.ValNew)
,  : '+'
=  (s.KeyLast e.ValLast);

  e.Sorted = e.Sorted;
}

Его сложность O(n²), он тоже стабильный.

Интересно вот что. Запустим первый алгоритм на некоторых входных данных и 
построим трассировку поля зрения на каждом шаге (за исключением шагов на 
проверку условий). Сотрём в трассировке все скобки конкретизации. Запустим 
второй алгоритм на тех же данных. Также сотрём в трассировке все скобки 
конкретизации и форматные структурные скобки. Получится та же самая 
последовательность (без учёта повторяющихся строк). Так что в некотором смысле 
оба алгоритма эквивалентны.

Интересно, можно ли вывести второй алгоритм из первого какой-нибудь цепочкой 
элементарных преобразований?

 

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

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Сергей!

Схема неплохая, реализовать в базовом варианте её просто. Но есть два 
недостатка: сложность и имя.

Чтобы откомпилировать программу в текущей реализации, никаких ключей компиляции 
учить не надо. Для сборки с ключами по умолчанию достаточно написать

srefc исходник1.ref … исходникN.ref

В результате в текущей папке появится один новый файл: исходник1.exe (на 
Windows, без расширения на unix-like). Если программист пользуется 
комментариями *$FROM, то можно вызвать

srmake исходник1.ref

с тем же результатом. Интерфейс даже проще, чем refc/refgo у Рефала-5.

Интерфейс srefc повторяет интерфейс компиляторов Си. Можно написать gcc файл1.c 
… файлN.c и получить в текущей папке a.exe/a.out без лишнего мусора. 
Компиляторы C++ для Windows в подобной ситуации создадут файл1.exe и насыпят в 
текущую папку кучу объектников, файлов символов для отладки и т.д.

Интерфейс вроде go или cargo (утилита сборки для Rust) не так очевиден — нужно 
запоминать не только имя самой утилиты, но и первый аргумент командной строки. 
Подход идеален для «мультитулов» вроде систем управления версиями, где разных 
режимов много и осваивать по любому надо все. Например, для той же системы 
управления версиями нужно и делать коммиты, и получать правки с сервера, и 
смотреть диффы… Вместо десятка взаимосвязанных утилит создаётся одна команда 
типа svn или git с первым аргументом — режимом работы.

В моём случае для компилятора такого большого количества режимов не требуется 
(да я и не осилю столько). Режимов всего два: srefc и srmake, основным является 
первый. Технически от srmake можно вообще отказаться, переместив поиск 
зависимостей в сам компилятор и добавив для этого ключ командной строки 
(например, --scan-deps). Но я этого делать не хочу по идеологическим 
соображениям.


Второй вопрос — это имя. Имя refal не подходит. Во-первых, длинное (ведь надо 
набирать ещё первый параметр). Во-вторых, а если другой разработчик Рефала тоже 
назовёт свою утилиту «refal»? Как разрешать такой конфликт?

Я у себя на компьютере обнаружил
• refal2.exe — Рефал-2 Белоуса, ещё посмотрел, проект 
https://github.com/cmc-msu-ai/refal тоже компилируется в refal2.exe,
• refalb.exe — Рефал/2 Стеллецкого,
• refalc.exe — Рефал-7 Скоробогатова: и ранняя версия, и версия дипломника 
Фаткуллина,
• refald.exe — тоже Рефал/2 Стеллецкого, другая версия, поддерживает больший 
объём памяти,
• refalx.exe — нашёл исходники некоего RefalX, судя по Makefile он собирается в 
исполнимый файл refalx из refalx.c, диалект некоего Антона Владимирова.
• И, наконец, refal.exe — его можно собрать из архива, прикреплённого к старому 
письму в рассылку 
https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0712-utf8


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


-Original Message-
From: Скоробогатов Сергей Юрьевич skorobogatov_AT_bmstu.ru 
[mailto:refal@botik.ru] 
Sent: Wednesday, April 1, 2020 8:42 AM
To: refal@botik.ru
Subject: Re: Как мне назвать компилятор?

А можно воспользоваться схемой, которая применяется, например, в языке Go. 
Существует утилита под названием "go", которая делает вообще всё. При вызове 
утилиты требуемое действие указывается первым аргументом командной строки:
go build -- откомпилировать;
go test -- запустить unit-тесты;
go fmt -- отформатировать исходные тексты; и т.п.

Соответственно для Рефала-лямбда такая утилита будет называться
просто: refal. И будут у неё команды:
refal build -- откомпилировать в байт-код; refal deploy -- откомпилировать в 
байт-код и присобачить интерпретатор байт-кода; refal run -- откомпилировать в 
байт-код и запустить; refal trace -- откомпилировать в байт-код и запустить в 
режиме отладки; refal spec -- запустить суперкомпилятор; и т.п.

On Tue, 31 Mar 2020 19:07:27 +0300
  Александр Коновалов a.v.konovalov87_AT_mail.ru   wrote:
> А вот называть интерпретатор rlint явно не стоит. Во-первых, оно 
>занято (аж два раза: раз  , два 
> ). А во-вторых напоминает 
>линтер, которого для Рефала-5 пока нет. Но зачаток линтера будет — один 
>из моих дипломников будет добавлять два предупреждения в компилятор. 
>Одно тривиальное (но для него потребуется добавить в компилятор 
>поддержку предупреждений). А второе сложное, ему и посвящена 
>содержательная часть диплома.
> 
> Александр Коновалов
> 
> 
>From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru]
> Sent: Tuesday, March 31, 2020 6:56 PM
> To: refal@botik.ru
> Subject: Re: Как мне назвать компилятор?
> 
> 
> On Tue, Mar 31, 2020 at 6:35 PM Александр Коновалов 
>a.v.konovalov87_AT_mail.ru 
> mailto:refal@botik.ru> > wrote:
> 
> Андрей!
> 
> Понял мысль, спасибо. Менять местами 5 и l я бы не стал. И так иногда 
>их путают (здесь 
>9F%D0%97_%D0%A1%D0%B8%D1%82%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2_%D0%9F%D1%80%
>D0%BE%D0%B3%D0%BE%D0%BD%D0%BA%D0%B0_2019.pdf>
> на титульном листе,

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

А вот называть интерпретатор rlint явно не стоит. Во-первых, оно занято (аж два 
раза: раз  , два 
 ). А во-вторых напоминает линтер, 
которого для Рефала-5 пока нет. Но зачаток линтера будет — один из моих 
дипломников будет добавлять два предупреждения в компилятор. Одно тривиальное 
(но для него потребуется добавить в компилятор поддержку предупреждений). А 
второе сложное, ему и посвящена содержательная часть диплома.

Александр Коновалов

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 6:56 PM
To: refal@botik.ru
Subject: Re: Как мне назвать компилятор?

 

On Tue, Mar 31, 2020 at 6:35 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Андрей!

Понял мысль, спасибо. Менять местами 5 и l я бы не стал. И так иногда их путают 
(здесь 

  на титульном листе, здесь 

  на первом слайде). К тому же запись rl5c сильно похожа на 15.

Это я привел лишь для демонстрации идеи, как читаются буквы рядом с цифрой, а 
не как предложение назвать.

Можно вообще 5 выкинуть: rlc, rlmake, rlgo. Когда рядом с l нет цифры, она не 
напоминает 1. А поскольку названия утилит как правило пишутся в нижнем 
регистре, то не перепутаешь l с I. И l как длинная палка отделяет разновидность 
утилиты.

Да, мМне тоже кажется, что 5 можно убрать.

 

Андрей  

Удачно получилось у Рефала-05: компилятор refal05c.exe (даже 8.3!), префиксы 
типов и функций рантайма r05_. Напомню, Рефал-05 — этот тот, который 
распараллеливал Станислав. (Про дискуссию о распараллеливании я не забыл — 
дочитаю старую статью Эйсымонта и отвечу.) 

Александр Коновалов

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 6:06 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

 

On Tue, Mar 31, 2020 at 5:57 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Андрей!

«Цифра 5 в середине наименования Рефала мне не нравится: буква после неё 
сливается с именем утилиты.»

Не понял мысль.

Рассмотрим первый вариант: r5lc, r5lmake

Здесь глаз воспринимает 5 как разделитель, после которого слитно читаются 
идентификаторы lc, make.

Если, скажем, 5 и l поменять местами, получится: rl5c, rl5make. Тогда имена "c" 
и "make" легко выделяются глазом. 

То же самое в hor5c, hor5make.

 

Андрей

 

From: Andrei Klimov andrei.klimov_AT_gmail.com 
  [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 5:52 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

 

Вообще-то цифры в названиях утилит я не люблю (пальцы надо приподнимать к 
верхнему ряду), но в данном случае хотя бы есть плюс, что цифра выделяет имя 
утилиты, которое быстро опознается глазом: ...c, ...make, ...int. 

Цифра 5 в середине наименования Рефала мне не нравится: буква после нее 
сливается с именем утилиты.

 

Андрей

 

On Tue, Mar 31, 2020 at 5:39 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Спасибо, Андрей!

Вариант неплохой. Только я бы добавил циферку 5: hor5c, hor5make, hor5go или 
hor5int для интерпретатора (вернее, загрузчика), который я сейчас пишу.

На всякий случай дополню: сам язык я не планирую переименовывать, он так и 
остаётся Рефалом-5λ.

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 5:30 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

 

Может так? --

Higher Order Refal – hor, horef:

horc, horefc, hormake

 

Гуглом и словарями проверяем, что у этого слова нет нехороших смыслов. Не 
обнаружено.

По словарю: hor = horizon = горизонт.

Ассоциация неплохая: рефал на горизонте; рефал, к которому стремимся; рефал 
мечты. ;-)

(Правда, горизонт мы не достигаем. Но это уж можно замять.:-))

 

Андрей

 

On Tue, Mar 31, 2020 at 5:20 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Спасибо за интересное предложение!

Выглядит неплохо, хотя и натянуто. Связь между Рефалом-5λ и r5ac (или ref5ac) 
не очевидна. Но столь же неочевидна связь и между Рефалом-5λ и srefc.


Александр Коновалов

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 3:09

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Андрей!

Понял мысль, спасибо. Менять местами 5 и l я бы не стал. И так иногда их путают 
(здесь 

  на титульном листе, здесь 

  на первом слайде). К тому же запись rl5c сильно похожа на 15.

Можно вообще 5 выкинуть: rlc, rlmake, rlgo. Когда рядом с l нет цифры, она не 
напоминает 1. А поскольку названия утилит как правило пишутся в нижнем 
регистре, то не перепутаешь l с I. И l как длинная палка отделяет разновидность 
утилиты.

Удачно получилось у Рефала-05: компилятор refal05c.exe (даже 8.3!), префиксы 
типов и функций рантайма r05_. Напомню, Рефал-05 — этот тот, который 
распараллеливал Станислав. (Про дискуссию о распараллеливании я не забыл — 
дочитаю старую статью Эйсымонта и отвечу.)

 

Александр Коновалов

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 6:06 PM
To: refal@botik.ru
Subject: Re: Как мне назвать компилятор?

 

On Tue, Mar 31, 2020 at 5:57 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Андрей!

«Цифра 5 в середине наименования Рефала мне не нравится: буква после неё 
сливается с именем утилиты.»

Не понял мысль.

Рассмотрим первый вариант: r5lc, r5lmake

Здесь глаз воспринимает 5 как разделитель, после которого слитно читаются 
идентификаторы lc, make.

Если, скажем, 5 и l поменять местами, получится: rl5c, rl5make. Тогда имена "c" 
и "make" легко выделяются глазом. 

То же самое в hor5c, hor5make.

 

Андрей

 

From: Andrei Klimov andrei.klimov_AT_gmail.com 
  [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 5:52 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

 

Вообще-то цифры в названиях утилит я не люблю (пальцы надо приподнимать к 
верхнему ряду), но в данном случае хотя бы есть плюс, что цифра выделяет имя 
утилиты, которое быстро опознается глазом: ...c, ...make, ...int. 

Цифра 5 в середине наименования Рефала мне не нравится: буква после нее 
сливается с именем утилиты.

 

Андрей

 

On Tue, Mar 31, 2020 at 5:39 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Спасибо, Андрей!

Вариант неплохой. Только я бы добавил циферку 5: hor5c, hor5make, hor5go или 
hor5int для интерпретатора (вернее, загрузчика), который я сейчас пишу.

На всякий случай дополню: сам язык я не планирую переименовывать, он так и 
остаётся Рефалом-5λ.

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 5:30 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

 

Может так? --

Higher Order Refal – hor, horef:

horc, horefc, hormake

 

Гуглом и словарями проверяем, что у этого слова нет нехороших смыслов. Не 
обнаружено.

По словарю: hor = horizon = горизонт.

Ассоциация неплохая: рефал на горизонте; рефал, к которому стремимся; рефал 
мечты. ;-)

(Правда, горизонт мы не достигаем. Но это уж можно замять.:-))

 

Андрей

 

On Tue, Mar 31, 2020 at 5:20 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Спасибо за интересное предложение!

Выглядит неплохо, хотя и натянуто. Связь между Рефалом-5λ и r5ac (или ref5ac) 
не очевидна. Но столь же неочевидна связь и между Рефалом-5λ и srefc.


Александр Коновалов

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 3:09 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

Имя музыкального тона «ля» созвучно со словом «лямбда», а обозначается он через 
букву A. Тогда вместо префикса «r5l» можно «r5a». К тому же, «a» — одна из 
обычных добавок к имени (подобно «плюс» и «прим»), чтобы оно и было подобно, и 
отличалось от существующего. И, наконец, A не сильно отличается от греческого Λ 
:)

Конечно, всё это очень натянуто, но вряд ли в большей степени, чем графическая 
имитация буквы Λ знаком \ (Haskell) или λ — знаком -> (Ruby).

Просто моите две стотинки :)

On Tue, 31 Mar 2020 at 14:26, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:
>
> Добрый день всем!
>
> У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет 
> — нет нормального названия для утилиты командной строки.
>
>
>
> Исторический контекст (можно не читать).
>
> Когда-то я разрабатывал так называемый Простой Рефал — диалект, 
> синтаксически похожий на Рефал-5 (но не 

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Андрей!

«Цифра 5 в середине наименования Рефала мне не нравится: буква после неё 
сливается с именем утилиты.»

Не понял мысль.

 

From: Andrei Klimov andrei.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 5:52 PM
To: refal@botik.ru
Subject: Re: Как мне назвать компилятор?

 

Вообще-то цифры в названиях утилит я не люблю (пальцы надо приподнимать к 
верхнему ряду), но в данном случае хотя бы есть плюс, что цифра выделяет имя 
утилиты, которое быстро опознается глазом: ...c, ...make, ...int. 

Цифра 5 в середине наименования Рефала мне не нравится: буква после нее 
сливается с именем утилиты.

 

Андрей

 

On Tue, Mar 31, 2020 at 5:39 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Спасибо, Андрей!

Вариант неплохой. Только я бы добавил циферку 5: hor5c, hor5make, hor5go или 
hor5int для интерпретатора (вернее, загрузчика), который я сейчас пишу.

На всякий случай дополню: сам язык я не планирую переименовывать, он так и 
остаётся Рефалом-5λ.

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 5:30 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

 

Может так? --

Higher Order Refal – hor, horef:

horc, horefc, hormake

 

Гуглом и словарями проверяем, что у этого слова нет нехороших смыслов. Не 
обнаружено.

По словарю: hor = horizon = горизонт.

Ассоциация неплохая: рефал на горизонте; рефал, к которому стремимся; рефал 
мечты. ;-)

(Правда, горизонт мы не достигаем. Но это уж можно замять.:-))

 

Андрей

 

On Tue, Mar 31, 2020 at 5:20 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Спасибо за интересное предложение!

Выглядит неплохо, хотя и натянуто. Связь между Рефалом-5λ и r5ac (или ref5ac) 
не очевидна. Но столь же неочевидна связь и между Рефалом-5λ и srefc.


Александр Коновалов

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 3:09 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

Имя музыкального тона «ля» созвучно со словом «лямбда», а обозначается он через 
букву A. Тогда вместо префикса «r5l» можно «r5a». К тому же, «a» — одна из 
обычных добавок к имени (подобно «плюс» и «прим»), чтобы оно и было подобно, и 
отличалось от существующего. И, наконец, A не сильно отличается от греческого Λ 
:)

Конечно, всё это очень натянуто, но вряд ли в большей степени, чем графическая 
имитация буквы Λ знаком \ (Haskell) или λ — знаком -> (Ruby).

Просто моите две стотинки :)

On Tue, 31 Mar 2020 at 14:26, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:
>
> Добрый день всем!
>
> У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет 
> — нет нормального названия для утилиты командной строки.
>
>
>
> Исторический контекст (можно не читать).
>
> Когда-то я разрабатывал так называемый Простой Рефал — диалект, 
> синтаксически похожий на Рефал-5 (но не совместимый с ним), 
> семантически — на Рефал-2 (пустые функции вместо слов), поддерживающий 
> только базисное подмножество. Позже я в него добавил безымянные 
> вложенные функции (замыкания, «лямбды»). Исполнимый файл естественным 
> образом назывался srefc (Simple Refal Compiler). Для компилятора была 
> также утилита srmake, которая принимала на входе имя одного исходника, 
> находила остальные по зависимостям и вызывала для них srefc. 
> Зависимости вычислялись по комментариям вида
>
> //FROM имя-файла
>
> которые по соглашеню предваряли списки $EXTERN для функций из соответствующих 
> файлов.
>
> Потом я понял, что несовместимый диалект не нужен даже мне и переделал 
> компилятор в совместимый с Рефалом-5. Так появился язык Рефал-5λ, который 
> является надмножеством Рефала-5 и включает в себя вложенные функции (что 
> символизирует буква «λ» в названии). Но имя программы так и осталось srefc, а 
> имя утилиты поиска зависимостей — srmake (которая теперь ищет комментарии 
> *$FROM имя-файла).
>
> Исходники компилятора уже давно переписаны с Простого Рефала на Рефал-5λ 
> (кроме фронт-энда Простого Рефала, который остался самоприменим), фронт-энд 
> Простого Рефала я уже подумываю удалить, поэтому имена srefc и srmake 
> становятся анахронизмом.
>
>
>
> Поэтому я прошу помощи у подписчиков: как мне назвать программу компилятора 
> (вместо srefc) и программу поиска зависимостей (вместо srmake)?
>
> Можно сократить название refal-5-lambda до r5l и использовать его как 
> префикс: r5lc, r5lmake. Но префикс r5l похож на r51 и r5I и этим неудачен — 
> легко перепутать. Использовать имена r5c и r5make не хочу, т.к. это не 
> Рефал-5, а Рефал-5λ. Имя вроде refal-5-lambda-compiler слишком длинное.
>
> По умолчанию компилятор создаёт исполнимые файл

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Юрий, извините. Я Вас по ошибке назвал Аркадием.

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 5:42 PM
To: refal@botik.ru
Subject: RE: Как мне назвать компилятор?

 

Спасибо, Аркадий!

r5lam — компилятор, r5lam-make для поиска зависимостей, r5lam-int или r5lam-go 
для интерпретатора. Имя r5l можно разглядеть как r5I или r51, а имя r5lam 
ошибочно разглядеть (если известно, что язык называется Рефал-5λ) будет сложнее.

 

Александр Коновалов

 

From: Yuri Klimov yuri_AT_klimov.net [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 5:33 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

 

Добрый день!

 

Я бы предложил назвать r5lam.

 

С уважением,

 Юрий Климов

 

вт, 31 мар. 2020 г., 17:20 Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Спасибо за интересное предложение!

Выглядит неплохо, хотя и натянуто. Связь между Рефалом-5λ и r5ac (или ref5ac) 
не очевидна. Но столь же неочевидна связь и между Рефалом-5λ и srefc.


Александр Коновалов

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 3:09 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

Имя музыкального тона «ля» созвучно со словом «лямбда», а обозначается он через 
букву A. Тогда вместо префикса «r5l» можно «r5a». К тому же, «a» — одна из 
обычных добавок к имени (подобно «плюс» и «прим»), чтобы оно и было подобно, и 
отличалось от существующего. И, наконец, A не сильно отличается от греческого Λ 
:)

Конечно, всё это очень натянуто, но вряд ли в большей степени, чем графическая 
имитация буквы Λ знаком \ (Haskell) или λ — знаком -> (Ruby).

Просто моите две стотинки :)

On Tue, 31 Mar 2020 at 14:26, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:
>
> Добрый день всем!
>
> У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет 
> — нет нормального названия для утилиты командной строки.
>
>
>
> Исторический контекст (можно не читать).
>
> Когда-то я разрабатывал так называемый Простой Рефал — диалект, 
> синтаксически похожий на Рефал-5 (но не совместимый с ним), 
> семантически — на Рефал-2 (пустые функции вместо слов), поддерживающий 
> только базисное подмножество. Позже я в него добавил безымянные 
> вложенные функции (замыкания, «лямбды»). Исполнимый файл естественным 
> образом назывался srefc (Simple Refal Compiler). Для компилятора была 
> также утилита srmake, которая принимала на входе имя одного исходника, 
> находила остальные по зависимостям и вызывала для них srefc. 
> Зависимости вычислялись по комментариям вида
>
> //FROM имя-файла
>
> которые по соглашеню предваряли списки $EXTERN для функций из соответствующих 
> файлов.
>
> Потом я понял, что несовместимый диалект не нужен даже мне и переделал 
> компилятор в совместимый с Рефалом-5. Так появился язык Рефал-5λ, который 
> является надмножеством Рефала-5 и включает в себя вложенные функции (что 
> символизирует буква «λ» в названии). Но имя программы так и осталось srefc, а 
> имя утилиты поиска зависимостей — srmake (которая теперь ищет комментарии 
> *$FROM имя-файла).
>
> Исходники компилятора уже давно переписаны с Простого Рефала на Рефал-5λ 
> (кроме фронт-энда Простого Рефала, который остался самоприменим), фронт-энд 
> Простого Рефала я уже подумываю удалить, поэтому имена srefc и srmake 
> становятся анахронизмом.
>
>
>
> Поэтому я прошу помощи у подписчиков: как мне назвать программу компилятора 
> (вместо srefc) и программу поиска зависимостей (вместо srmake)?
>
> Можно сократить название refal-5-lambda до r5l и использовать его как 
> префикс: r5lc, r5lmake. Но префикс r5l похож на r51 и r5I и этим неудачен — 
> легко перепутать. Использовать имена r5c и r5make не хочу, т.к. это не 
> Рефал-5, а Рефал-5λ. Имя вроде refal-5-lambda-compiler слишком длинное.
>
> По умолчанию компилятор создаёт исполнимые файлы, состоящие из 
> интерпретатора, к которому «приклеен» байткод. Но можно создавать файлы и из 
> голого байткода. Для запуска последних как программ я планирую написать 
> интерпретатор вроде refgo из классического Рефала-5. Возникает вопрос: а 
> какое ему дать имя?
>
>
>
> С уважением,
> Александр Коновалов

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Спасибо, Аркадий!

r5lam — компилятор, r5lam-make для поиска зависимостей, r5lam-int или r5lam-go 
для интерпретатора. Имя r5l можно разглядеть как r5I или r51, а имя r5lam 
ошибочно разглядеть (если известно, что язык называется Рефал-5λ) будет сложнее.

 

Александр Коновалов

 

From: Yuri Klimov yuri_AT_klimov.net [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 5:33 PM
To: refal@botik.ru
Subject: Re: Как мне назвать компилятор?

 

Добрый день!

 

Я бы предложил назвать r5lam.

 

С уважением,

 Юрий Климов

 

вт, 31 мар. 2020 г., 17:20 Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Спасибо за интересное предложение!

Выглядит неплохо, хотя и натянуто. Связь между Рефалом-5λ и r5ac (или ref5ac) 
не очевидна. Но столь же неочевидна связь и между Рефалом-5λ и srefc.


Александр Коновалов

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 3:09 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

Имя музыкального тона «ля» созвучно со словом «лямбда», а обозначается он через 
букву A. Тогда вместо префикса «r5l» можно «r5a». К тому же, «a» — одна из 
обычных добавок к имени (подобно «плюс» и «прим»), чтобы оно и было подобно, и 
отличалось от существующего. И, наконец, A не сильно отличается от греческого Λ 
:)

Конечно, всё это очень натянуто, но вряд ли в большей степени, чем графическая 
имитация буквы Λ знаком \ (Haskell) или λ — знаком -> (Ruby).

Просто моите две стотинки :)

On Tue, 31 Mar 2020 at 14:26, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:
>
> Добрый день всем!
>
> У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет 
> — нет нормального названия для утилиты командной строки.
>
>
>
> Исторический контекст (можно не читать).
>
> Когда-то я разрабатывал так называемый Простой Рефал — диалект, 
> синтаксически похожий на Рефал-5 (но не совместимый с ним), 
> семантически — на Рефал-2 (пустые функции вместо слов), поддерживающий 
> только базисное подмножество. Позже я в него добавил безымянные 
> вложенные функции (замыкания, «лямбды»). Исполнимый файл естественным 
> образом назывался srefc (Simple Refal Compiler). Для компилятора была 
> также утилита srmake, которая принимала на входе имя одного исходника, 
> находила остальные по зависимостям и вызывала для них srefc. 
> Зависимости вычислялись по комментариям вида
>
> //FROM имя-файла
>
> которые по соглашеню предваряли списки $EXTERN для функций из соответствующих 
> файлов.
>
> Потом я понял, что несовместимый диалект не нужен даже мне и переделал 
> компилятор в совместимый с Рефалом-5. Так появился язык Рефал-5λ, который 
> является надмножеством Рефала-5 и включает в себя вложенные функции (что 
> символизирует буква «λ» в названии). Но имя программы так и осталось srefc, а 
> имя утилиты поиска зависимостей — srmake (которая теперь ищет комментарии 
> *$FROM имя-файла).
>
> Исходники компилятора уже давно переписаны с Простого Рефала на Рефал-5λ 
> (кроме фронт-энда Простого Рефала, который остался самоприменим), фронт-энд 
> Простого Рефала я уже подумываю удалить, поэтому имена srefc и srmake 
> становятся анахронизмом.
>
>
>
> Поэтому я прошу помощи у подписчиков: как мне назвать программу компилятора 
> (вместо srefc) и программу поиска зависимостей (вместо srmake)?
>
> Можно сократить название refal-5-lambda до r5l и использовать его как 
> префикс: r5lc, r5lmake. Но префикс r5l похож на r51 и r5I и этим неудачен — 
> легко перепутать. Использовать имена r5c и r5make не хочу, т.к. это не 
> Рефал-5, а Рефал-5λ. Имя вроде refal-5-lambda-compiler слишком длинное.
>
> По умолчанию компилятор создаёт исполнимые файлы, состоящие из 
> интерпретатора, к которому «приклеен» байткод. Но можно создавать файлы и из 
> голого байткода. Для запуска последних как программ я планирую написать 
> интерпретатор вроде refgo из классического Рефала-5. Возникает вопрос: а 
> какое ему дать имя?
>
>
>
> С уважением,
> Александр Коновалов

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Спасибо, Андрей!

Вариант неплохой. Только я бы добавил циферку 5: hor5c, hor5make, hor5go или 
hor5int для интерпретатора (вернее, загрузчика), который я сейчас пишу.

На всякий случай дополню: сам язык я не планирую переименовывать, он так и 
остаётся Рефалом-5λ.

 

From: Andrei Klimov andrei_AT_klimov.net [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 5:30 PM
To: refal@botik.ru
Subject: Re: Как мне назвать компилятор?

 

Может так? --

Higher Order Refal – hor, horef:

horc, horefc, hormake

 

Гуглом и словарями проверяем, что у этого слова нет нехороших смыслов. Не 
обнаружено.

По словарю: hor = horizon = горизонт.

Ассоциация неплохая: рефал на горизонте; рефал, к которому стремимся; рефал 
мечты. ;-)

(Правда, горизонт мы не достигаем. Но это уж можно замять.:-))

 

Андрей

 

On Tue, Mar 31, 2020 at 5:20 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:

Спасибо за интересное предложение!

Выглядит неплохо, хотя и натянуто. Связь между Рефалом-5λ и r5ac (или ref5ac) 
не очевидна. Но столь же неочевидна связь и между Рефалом-5λ и srefc.


Александр Коновалов

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru 
 ] 
Sent: Tuesday, March 31, 2020 3:09 PM
To: refal@botik.ru  
Subject: Re: Как мне назвать компилятор?

Имя музыкального тона «ля» созвучно со словом «лямбда», а обозначается он через 
букву A. Тогда вместо префикса «r5l» можно «r5a». К тому же, «a» — одна из 
обычных добавок к имени (подобно «плюс» и «прим»), чтобы оно и было подобно, и 
отличалось от существующего. И, наконец, A не сильно отличается от греческого Λ 
:)

Конечно, всё это очень натянуто, но вряд ли в большей степени, чем графическая 
имитация буквы Λ знаком \ (Haskell) или λ — знаком -> (Ruby).

Просто моите две стотинки :)

On Tue, 31 Mar 2020 at 14:26, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> > 
wrote:
>
> Добрый день всем!
>
> У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет 
> — нет нормального названия для утилиты командной строки.
>
>
>
> Исторический контекст (можно не читать).
>
> Когда-то я разрабатывал так называемый Простой Рефал — диалект, 
> синтаксически похожий на Рефал-5 (но не совместимый с ним), 
> семантически — на Рефал-2 (пустые функции вместо слов), поддерживающий 
> только базисное подмножество. Позже я в него добавил безымянные 
> вложенные функции (замыкания, «лямбды»). Исполнимый файл естественным 
> образом назывался srefc (Simple Refal Compiler). Для компилятора была 
> также утилита srmake, которая принимала на входе имя одного исходника, 
> находила остальные по зависимостям и вызывала для них srefc. 
> Зависимости вычислялись по комментариям вида
>
> //FROM имя-файла
>
> которые по соглашеню предваряли списки $EXTERN для функций из соответствующих 
> файлов.
>
> Потом я понял, что несовместимый диалект не нужен даже мне и переделал 
> компилятор в совместимый с Рефалом-5. Так появился язык Рефал-5λ, который 
> является надмножеством Рефала-5 и включает в себя вложенные функции (что 
> символизирует буква «λ» в названии). Но имя программы так и осталось srefc, а 
> имя утилиты поиска зависимостей — srmake (которая теперь ищет комментарии 
> *$FROM имя-файла).
>
> Исходники компилятора уже давно переписаны с Простого Рефала на Рефал-5λ 
> (кроме фронт-энда Простого Рефала, который остался самоприменим), фронт-энд 
> Простого Рефала я уже подумываю удалить, поэтому имена srefc и srmake 
> становятся анахронизмом.
>
>
>
> Поэтому я прошу помощи у подписчиков: как мне назвать программу компилятора 
> (вместо srefc) и программу поиска зависимостей (вместо srmake)?
>
> Можно сократить название refal-5-lambda до r5l и использовать его как 
> префикс: r5lc, r5lmake. Но префикс r5l похож на r51 и r5I и этим неудачен — 
> легко перепутать. Использовать имена r5c и r5make не хочу, т.к. это не 
> Рефал-5, а Рефал-5λ. Имя вроде refal-5-lambda-compiler слишком длинное.
>
> По умолчанию компилятор создаёт исполнимые файлы, состоящие из 
> интерпретатора, к которому «приклеен» байткод. Но можно создавать файлы и из 
> голого байткода. Для запуска последних как программ я планирую написать 
> интерпретатор вроде refgo из классического Рефала-5. Возникает вопрос: а 
> какое ему дать имя?
>
>
>
> С уважением,
> Александр Коновалов

RE: Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Спасибо за интересное предложение!

Выглядит неплохо, хотя и натянуто. Связь между Рефалом-5λ и r5ac (или ref5ac) 
не очевидна. Но столь же неочевидна связь и между Рефалом-5λ и srefc.


Александр Коновалов

-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Tuesday, March 31, 2020 3:09 PM
To: refal@botik.ru
Subject: Re: Как мне назвать компилятор?

Имя музыкального тона «ля» созвучно со словом «лямбда», а обозначается он через 
букву A. Тогда вместо префикса «r5l» можно «r5a». К тому же, «a» — одна из 
обычных добавок к имени (подобно «плюс» и «прим»), чтобы оно и было подобно, и 
отличалось от существующего. И, наконец, A не сильно отличается от греческого Λ 
:)

Конечно, всё это очень натянуто, но вряд ли в большей степени, чем графическая 
имитация буквы Λ знаком \ (Haskell) или λ — знаком -> (Ruby).

Просто моите две стотинки :)

On Tue, 31 Mar 2020 at 14:26, Александр Коновалов a.v.konovalov87_AT_mail.ru 
 wrote:
>
> Добрый день всем!
>
> У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет 
> — нет нормального названия для утилиты командной строки.
>
>
>
> Исторический контекст (можно не читать).
>
> Когда-то я разрабатывал так называемый Простой Рефал — диалект, 
> синтаксически похожий на Рефал-5 (но не совместимый с ним), 
> семантически — на Рефал-2 (пустые функции вместо слов), поддерживающий 
> только базисное подмножество. Позже я в него добавил безымянные 
> вложенные функции (замыкания, «лямбды»). Исполнимый файл естественным 
> образом назывался srefc (Simple Refal Compiler). Для компилятора была 
> также утилита srmake, которая принимала на входе имя одного исходника, 
> находила остальные по зависимостям и вызывала для них srefc. 
> Зависимости вычислялись по комментариям вида
>
> //FROM имя-файла
>
> которые по соглашеню предваряли списки $EXTERN для функций из соответствующих 
> файлов.
>
> Потом я понял, что несовместимый диалект не нужен даже мне и переделал 
> компилятор в совместимый с Рефалом-5. Так появился язык Рефал-5λ, который 
> является надмножеством Рефала-5 и включает в себя вложенные функции (что 
> символизирует буква «λ» в названии). Но имя программы так и осталось srefc, а 
> имя утилиты поиска зависимостей — srmake (которая теперь ищет комментарии 
> *$FROM имя-файла).
>
> Исходники компилятора уже давно переписаны с Простого Рефала на Рефал-5λ 
> (кроме фронт-энда Простого Рефала, который остался самоприменим), фронт-энд 
> Простого Рефала я уже подумываю удалить, поэтому имена srefc и srmake 
> становятся анахронизмом.
>
>
>
> Поэтому я прошу помощи у подписчиков: как мне назвать программу компилятора 
> (вместо srefc) и программу поиска зависимостей (вместо srmake)?
>
> Можно сократить название refal-5-lambda до r5l и использовать его как 
> префикс: r5lc, r5lmake. Но префикс r5l похож на r51 и r5I и этим неудачен — 
> легко перепутать. Использовать имена r5c и r5make не хочу, т.к. это не 
> Рефал-5, а Рефал-5λ. Имя вроде refal-5-lambda-compiler слишком длинное.
>
> По умолчанию компилятор создаёт исполнимые файлы, состоящие из 
> интерпретатора, к которому «приклеен» байткод. Но можно создавать файлы и из 
> голого байткода. Для запуска последних как программ я планирую написать 
> интерпретатор вроде refgo из классического Рефала-5. Возникает вопрос: а 
> какое ему дать имя?
>
>
>
> С уважением,
> Александр Коновалов

Как мне назвать компилятор?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

У компилятора название есть, такое же как у языка — Рефал-5λ. Но вот чего нет — 
нет нормального названия для утилиты командной строки.

 

Исторический контекст (можно не читать). 

Когда-то я разрабатывал так называемый Простой Рефал — диалект, синтаксически 
похожий на Рефал-5 (но не совместимый с ним), семантически — на Рефал-2 (пустые 
функции вместо слов), поддерживающий только базисное подмножество. Позже я в 
него добавил безымянные вложенные функции (замыкания, «лямбды»). Исполнимый 
файл естественным образом назывался srefc (Simple Refal Compiler). Для 
компилятора была также утилита srmake, которая принимала на входе имя одного 
исходника, находила остальные по зависимостям и вызывала для них srefc. 
Зависимости вычислялись по комментариям вида

//FROM имя-файла

которые по соглашеню предваряли списки $EXTERN для функций из соответствующих 
файлов.

Потом я понял, что несовместимый диалект не нужен даже мне и переделал 
компилятор в совместимый с Рефалом-5. Так появился язык Рефал-5λ, который 
является надмножеством Рефала-5 и включает в себя вложенные функции (что 
символизирует буква «λ» в названии). Но имя программы так и осталось srefc, а 
имя утилиты поиска зависимостей — srmake (которая теперь ищет комментарии 
*$FROM имя-файла).

Исходники компилятора уже давно переписаны с Простого Рефала на Рефал-5λ (кроме 
фронт-энда Простого Рефала, который остался самоприменим), фронт-энд Простого 
Рефала я уже подумываю удалить, поэтому имена srefc и srmake становятся 
анахронизмом.

 

Поэтому я прошу помощи у подписчиков: как мне назвать программу компилятора 
(вместо srefc) и программу поиска зависимостей (вместо srmake)?

Можно сократить название refal-5-lambda до r5l и использовать его как префикс: 
r5lc, r5lmake. Но префикс r5l похож на r51 и r5I и этим неудачен — легко 
перепутать. Использовать имена r5c и r5make не хочу, т.к. это не Рефал-5, а 
Рефал-5λ. Имя вроде refal-5-lambda-compiler слишком длинное.

По умолчанию компилятор создаёт исполнимые файлы, состоящие из интерпретатора, 
к которому «приклеен» байткод. Но можно создавать файлы и из голого байткода. 
Для запуска последних как программ я планирую написать интерпретатор вроде 
refgo из классического Рефала-5. Возникает вопрос: а какое ему дать имя?

 

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

RE: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!
Я, прежде чем ответить, ждал презентацию от Станислава (мы договаривались, что 
он скинет её в рассылку), но он что-то не отсылал и я ответить на письмо забыл. 
Извините, что так долго.
 
Прозвучало два доклада. Первым был доклад Станислава про распараллеливание 
Рефала, вторым был доклад Максима Кривчикова про промежуточное представление 
Рефала и его использование для верификации.
 
Про первый доклад. Станислав рассказывал про свою курсовую работу по курсу 
«Операционные системы» на тему распараллеливания Рефала (научный руководитель — 
я). Про распараллеливание.
Из плюсов: предложен подход к параллельному вычислению функций в «грязном» 
языке программирования. Когда все функции чистые, проще — есть зависимости 
только по данным. А Рефал — «грязный» язык, в нём есть недетерминированные 
функции или функции с побочным эффектом (ввод, вывод, копилка). И нужен 
механизм, который (а) обеспечивал бы параллельные вычисления для чистых функций 
и (б) обеспечивал правильный порядок выполнения «грязных» функций.
Такой механизм предложен, ждём, когда Станислав скинет его в рассылку.
Из минусов: не распараллеливается. Красивого прироста производительности от 
большего числа потоков получить не удалось. Нам во время доклада подсказали, 
что надо было использовать work stealing для балансировки задач между потоками.
 
Про второй доклад. Максим разработал новый диалект Рефала и планирует его 
использовать для верификации типов в динамически типизированных языках при 
помощи прогонки (суперкомпиляции). Эту идею верификации я понял не до конца, 
другие идеи автора мне показались интересными. Доклад был незапланированным, 
поэтому прошёл без слайдов — в рассылку скидывать нечего. 
Андрей Валентинович, второго докладчика Вы добавляли в рассылку?
 
С уважением,
Александр Коновалов
 
From: Eisymont Leonid verger-lk_AT_yandex.ru  
Sent: Monday, March 2, 2020 2:33 PM
To: refal@botik.ru
Subject: Re: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ
 
Андрей, очень хотел попасть на семинар, но сижу дома со статьей по ЭКБ для ИИ. 
Очень тяжело идет, а завтра надо бы отдать коллегам на анализ. Жду презентацию, 
вопросов у меня уже сейчас много, ведь мы этим занимались 15 лет назад, еще в 
НИЦЭВТ-е, тогда не пошло, а потом не до этого было. Сейчас интерес есть, даже 
Рреализацию на односвязных списках Рефала-2 на сервере Модуля установили, она с 
машинными операциями под MPI, да и вообще испытанная и самая практически 
продвинутая. Вручную распараллеливать можно, даже пробовали еще в НИЦЭВТ-е. Это 
в НИР Вектор с Квантом - 2004 год.
Успехов, завидую вашему участию в работе такого семинара.
Л.Эйсымонт
 
02.03.2020, 08:03, "Andrei Klimov andrei_AT_klimov.net" mailto:refal@botik.ru> >:
Александр, доброе утро!
 
Жаль, но что ж делать...
Если параллелизм нас так не затянет, что первый доклад с обсуждением займет 
намного больше времени, чем думали, то есть такие соображения для полезных 
рефал-обсуждений после него:
*   Новый участник семинара Максим Кривчиков может дать у доски аннотацию 
его статьи, а мы обсудим:
*   Vasenin, V.A., Krivchikov, M.A. Intermediate Representation of Programs 
with Type Specification Based on Pattern Matching. Program Comput Soft 46, 
57–66 (2020). https://doi.org/10.1134/S0361768820010077
*   Это журнал "Программирование", но файл статьи на русском дают только за 
деньги (или у автора), а у Шпрингера можно взять бесплатно из академических 
институтов и, наверно, из части университетов. (А есть способы и не только из 
институтов.:-))
*   У меня есть затравочные вопросы по (отсутствующему, но потенциальному) 
месту Рефала в мире и его (гипотетическому) развитию в соответствующем 
направлении, которых на доклад недостаточно, но дискуссию могу разжечь. Вот 
этот доклад и статья доклад Сергея Романенко в ту же сторону, но есть что 
добавить:
*   С.А. Романенко. Рефал и Агда как воплощения идеи “метаалгоритмического 
языка” // Научный сервис в сети Интернет: труды XIX Всероссийской научной 
конференции (18-23 сентября 2017 г., г. Новороссийск). — М.: ИПМ им. 
М.В.Келдыша, 2017. — С. 417-424 . — http://doi.org/10.20948/abrau-2017-63
*   Файл статьи доступен по этой ссылке.
До встречи!
 
Всего наилучшего,
Андрей Климов
 
 
On Sun, Mar 1, 2020 at 6:13 PM 'Александр Коновалов' via Метавычисления и 
специализация программ mailto:metacomputation...@googlegroups.com> > wrote:
Добрый вечер всем!
Я не успеваю подготовить доклад к завтрашнему семинару, поэтому снимаю 
завтрашнее выступление.
Поэтому слушать завтра будем только доклад Станислава.
Но я думаю, что мы найдём достаточно тем для обсуждения и без моего выступления.
Простите, что так выходит.
 
С уважением,
Александр Коновалов
 
 
From: Andrei Klimov [mailto:and...@klimov.net  ]
Sent: Friday, February 28, 2020 2:04 PM
To: metacomputation-ru mailto:metacomputation...@googlegroups.com> >; refal@botik.ru 
 
Subject: Семинар по метавычислениям в понедельник 2 марта 

RE: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!

Я не успеваю подготовить доклад к завтрашнему семинару, поэтому снимаю 
завтрашнее выступление.

Поэтому слушать завтра будем только доклад Станислава.

Но я думаю, что мы найдём достаточно тем для обсуждения и без моего выступления.

Простите, что так выходит.

 

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

 

 

From: Andrei Klimov [mailto:and...@klimov.net] 
Sent: Friday, February 28, 2020 2:04 PM
To: metacomputation-ru ; refal@botik.ru
Subject: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ

 

Добрый день всем!

В понедельник 2 марта 2020 в 15 часов соберемся в 416 комнате ИПМ им. М.В. 
Келдыша РАН на семинар, чтобы послушать два доклада, связанных с языком Рефал:

*   Станислав Санталов (МГТУ им. Н.Э. Баумана)
Параллельное выполнение функций в Рефале-05

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

*   Александр Коновалов (МГТУ им. Н.Э. Баумана)
Алгоритм вывода свёрточной формы для функций обработки строк

Под свёрточной формой мы будем подразумевать представление функции, 
потребляющей некоторую структуру данных с помощью операции, знакомой 
функциональным программистам под именем foldr для лисповских списков, а в общем 
случае для типизированных языков типа ML и Haskell как катаморфизм 
  этой структуры данных — термин из теории 
категорий. Для функций обработки строк (и выражений Рефала), где есть 
ассоциативная операция конкатенации, это будет катаморфизм для свободного 
моноида, который также можно рассматривать как гомоморфизм моноида конкатенации 
в некоторый другой моноид.

Под строками в докладе будут пониматься однородные последовательности 
произвольных значений, которые могут быть пустыми и для которых определены 
конкатенация и итерация с обеих сторон. Для сравнения: в лисповских списках 
определено добавление одного элемента в начало (cons) и итерация только 
слева-направо.

Представление функций, потребляющих строки, в свёрточной форме даёт некоторые 
преимущества:

*   Появляется возможность выполнять слияние (fusion) с функциями, 
порождающими строки — в результирующей функции промежуточная строка даже не 
будет создаваться. Это вообще верно для любого катаморфизма и является основой 
сокращённой дефорестации (shortcut deforestation).
*   Появляется возможность распараллеливать вычисление функции — строку 
можно разделить на части, свернуть независимо и результаты их свёрток 
скомбинировать в искомое значение. Это свойство верно только для свёрточной 
формы строковых функций.
*   Можно менять направление обработки строк — из свёрточной формы можно 
получить функцию, читающую строку как слева-направо, так и справа-налево. 
Например, это позволяет преобразовать наивную функцию, вычисляющую значение 
многочлена, в схему Горнера.

На семинаре 29 октября 2019 года рассматривалась сокращённая дефорестация и 
способ её реализации для языка Рефал. На нём было введено понятие свёрточной 
формы для строковых функций в терминах Рефала и были рассмотрены некоторые 
примеры функций в этой форме. Способ построения свёрточной формы на том 
семинаре не давался.

В докладе 2 марта 2020 года мы определим свёрточную форму уже без использования 
терминологии Рефала, а также рассмотрим алгоритм перевода функций в свёрточную 
форму. Входом алгоритма будет функция, анализирующая строку по одному элементу 
слева-направо (или справа-налево), выходом будет свёрточная форма либо 
сообщение о том, что алгоритм не может её вывести.

Алгоритм применим для ограниченного класса функций, т.е. не для любой функции, 
представимой в свёрточной форме, эту форму можно вывести. Однако, этот класс 
достаточно широк, что будет продемонстрировано на нескольких примерах.

Вывод свёрточной формы использует ограниченную суперкомпиляцию на некоторых 
этапах своей работы. Ограниченность выражается в допустимых вариантах обобщения 
похожих конфигураций. Если в процессе требуется выполнить недопустимое 
обобщение, то или преобразуемая функция не представима в свёрточной форме, или 
она слишком сложна для этого алгоритма.

В отличие от доклада 29.10.2019 для понимания этого доклада знания Рефала не 
требуется.

  _  

Гости ИПМ, которым нужен разовый пропуск, напишите мне по email или пошлите 
смс-ку с ФИО и НОМЕРОМ ПАСПОРТА на моб. +7 985 364 3536 до 12 час в день 
семинара. Пропуск получите либо в бюро пропусков в окошке слева от вахтера в 
главной проходной ("стеклянной", со стороны Ми

RE: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Александр!
Мы скинем слайды в рассылку. Видеозапись на этих семинарах, как правило, не 
организуют (во всяком случае, я такого не помню).
 
Успехов!
Александр Коновалов
 
From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Friday, February 28, 2020 2:37 PM
To: refal 
Cc: metacomputation-ru 
Subject: Re: Семинар по метавычислениям в понедельник 2 марта 2020 в ИПМ
 
Спасибо!
А удалённо можно будет ознакомиться с докладами? Не обязательно синхронно с 
проведением мероприятия.
 


Отправлено из мобильной Почты Mail.ru


пятница, 28 февраля 2020 г., 14:06 +0300 от refal mailto:refal@botik.ru> >:
Добрый день всем!
В понедельник 2 марта 2020 в 15 часов соберемся в 416 комнате ИПМ им. М.В. 
Келдыша РАН на семинар, чтобы послушать два доклада, связанных с языком Рефал:
*   Станислав Санталов (МГТУ им. Н.Э. Баумана)
Параллельное выполнение функций в Рефале-05
Основная идея — рассмотреть возможность вычисления функций в Рефале-05 
независимо, в различных потоках. Предлагается способ распределения нагрузки 
между потоками, сохранения порядка вычисления функций и доступа к глобальному 
полю зрения. Для реализации поставленных задач вводится новая сущность — 
а-терм, экземпляры которой организуются в дерево с атомарными счетчиками и 
специальный глобальный потокобезопасный безблокировочный список. Также 
создается несколько очередей а-термов: общая глобальная и по одной локальной 
для каждого потока. В конце приводятся результаты тестирования и анализ 
полученной схемы.
*   Александр Коновалов (МГТУ им. Н.Э. Баумана)
Алгоритм вывода свёрточной формы для функций обработки строк
Под свёрточной формой мы будем подразумевать представление функции, 
потребляющей некоторую структуру данных с помощью операции, знакомой 
функциональным программистам под именем foldr для лисповских списков, а в общем 
случае для типизированных языков типа ML и Haskell как катаморфизм 

  этой структуры данных — термин из теории категорий. Для функций обработки 
строк (и выражений Рефала), где есть ассоциативная операция конкатенации, это 
будет катаморфизм для свободного моноида, который также можно рассматривать как 
гомоморфизм моноида конкатенации в некоторый другой моноид.
Под строками в докладе будут пониматься однородные последовательности 
произвольных значений, которые могут быть пустыми и для которых определены 
конкатенация и итерация с обеих сторон. Для сравнения: в лисповских списках 
определено добавление одного элемента в начало (cons) и итерация только 
слева-направо.
Представление функций, потребляющих строки, в свёрточной форме даёт некоторые 
преимущества:
*   Появляется возможность выполнять слияние (fusion) с функциями, 
порождающими строки — в результирующей функции промежуточная строка даже не 
будет создаваться. Это вообще верно для любого катаморфизма и является основой 
сокращённой дефорестации (shortcut deforestation).
*   Появляется возможность распараллеливать вычисление функции — строку 
можно разделить на части, свернуть независимо и результаты их свёрток 
скомбинировать в искомое значение. Это свойство верно только для свёрточной 
формы строковых функций.
*   Можно менять направление обработки строк — из свёрточной формы можно 
получить функцию, читающую строку как слева-направо, так и справа-налево. 
Например, это позволяет преобразовать наивную функцию, вычисляющую значение 
многочлена, в схему Горнера.
На семинаре 29 октября 2019 года рассматривалась сокращённая дефорестация и 
способ её реализации для языка Рефал. На нём было введено понятие свёрточной 
формы для строковых функций в терминах Рефала и были рассмотрены некоторые 
примеры функций в этой форме. Способ построения свёрточной формы на том 
семинаре не давался.
В докладе 2 марта 2020 года мы определим свёрточную форму уже без использования 
терминологии Рефала, а также рассмотрим алгоритм перевода функций в свёрточную 
форму. Входом алгоритма будет функция, анализирующая строку по одному элементу 
слева-направо (или справа-налево), выходом будет свёрточная форма либо 
сообщение о том, что алгоритм не может её вывести.
Алгоритм применим для ограниченного класса функций, т.е. не для любой функции, 
представимой в свёрточной форме, эту форму можно вывести. Однако, этот класс 
достаточно широк, что будет продемонстрировано на нескольких примерах.
Вывод свёрточной формы использует ограниченную суперкомпиляцию на некоторых 
этапах своей работы. Ограниченность выражается в допустимых вариантах обобщения 
похожих конфигураций. Если в процессе требуется выполнить недопустимое 
обобщение, то или преобразуемая функция не представима в свёрточной форме, или 
она слишком сложна для этого алгоритма.
В отличие от доклада 29.10.2019 для понимания этого доклада знания Рефала не 
требуется.

  _  

Гости ИПМ, которым нужен разовый пропуск, напишите мне по email или пошлите 
смс-ку с ФИО и НОМЕРОМ ПАСПОРТА на моб. +7 985 364 3536 до 12 час в

RE: День Валентина Турчина

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

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

В первой части статьи http://7i.7iskusstv.com/y2019/nomer9/turchin/ Турчин 
объясняет основы философии, беря в качестве отправной точки эпистемологию. 
Осилить мне её не удалось, поскольку такие философствования сложны для меня.

Вторая часть http://7i.7iskusstv.com/y2019/nomer10/turchin/ представляет просто 
конспект книги Феномен науки  .

Третья часть http://7i.7iskusstv.com/y2019/nomer11/turchin/ содержит раскрытие 
идей «Кибернетического манифеста» 
 . Если в 
манифесте идеи скорее перечислены, то здесь они подробно разбираются.

 

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

 

From: Andrei Klimov [mailto:and...@klimov.net] 
Sent: Friday, February 14, 2020 10:51 PM
To: metacomputation-ru ; refal@botik.ru
Subject: День Валентина Турчина

 

Добрый день всем!

 

Сегодня 14 февраля день не только Святого Валентина, но и нами более любимого и 
ценимого Валентина Федоровича Турчина – его день рождения (1931).

 

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

 

Образ Валентина Федоровича и его цельное эволюционное мировоззрение живет в нас 
и помогает нам не растеряться в нынешнем бурном потоке событий и новых явлений 
– от научных и социальных до философских вопросов – смысла жизни, этики, добра, 
отношения к смерти и бессмертию, нашего места в мире и принятия решений о наших 
личных поступках.

 

В качестве подарка нашему сообществу рад сообщить, что в прошлом году была 
опубликована на популярном сайте – в двух выпусках интернет-журнала "Семь 
искусств" – одна из последних статей Валентина Турчина в переводе на русский:

*   Диалог о метасистемном переходе

*   http://7i.7iskusstv.com/y2019/nomer9/turchin/
*   http://7i.7iskusstv.com/y2019/nomer11/turchin/

Прекрасный перевод с английского сделал Владимир Балтер. Вот ссылки на оригинал:

*   A dialogue on Metasystem transition, World Futures, 45:1-4, 5-57, 1995. 
DOI: 10.1080/02604027.1995.9972553 
 

*   https://www.tandfonline.com/doi/abs/10.1080/02604027.1995.9972553 – 
официальная страница статьи, куда ведет и указанный DOI. Официально PDF-файл 
бесплатно не дают, но... сами знаете.
*   http://pespmc1.vub.ac.be/Papers/Turchin/dialog.pdf – файл "препринта" 
на сайте ""Principia Cybernetica".
*   
https://pat.keldysh.ru/~roman/doc/Turchin/1999-Turchin--A_Dialogue_on_Metasystem_Transition.pdf
 – этот же файл, но с обрезанными краями (для удобства чтения на экране и 
печати буклетом) на сайте Сергея Романенко, куда он поместил часть работ 
Турчина.

Всего наилучшего,

Андрей Климов

 

PS. Это письмо послано в Гугл-группу Metacomputation-Ru 
  и в рассылку 
refal@botik.ru  , где сосредоточены большинство 
ценителей научного наследия Турчина по computer science. Кроме того, в "скрытую 
копию" поставлены адреса коллег и друзей, которые отсутствуют в этих рассылках.

 

Публикация "Диалога" на русском – хороший повод обменяться впечатлениями и об 
этой статье, и о всех вопросах связанных с концепцией метасистемного перехода 
Турчина.

 

Гугл-группа Metacomputation-Ru 
 , на мой взгляд, вполне 
подходящее место для обсуждения как этой, так и других работ Турчина. Пишите в 
нее на адрес metacomputation...@googlegroups.com 
 , даже если вы в нее еще не 
подписаны, она открыта и для неподписанных. А мы вас тут же включим для 
получения ответов и всей переписки.

-- 
Вы получили это сообщение, поскольку подписаны на группу "Метавычисления и 
специализация программ".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, 
отправьте письмо на электронный адрес 
metacomputation-ru+unsubscr...@googlegroups.com 
 .
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке 
https://groups.google.com/d/msgid/metacomputation-ru/CAM7HiM%3Da6chjQXk0VQBCx5DgXBKR9ProdNzXg_oyozMyGv_8BQ%40mail.gmail.com
 

 .

RE: День Валентина Турчина

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

Я не сразу это заметил, но Андрей Валентинович прислал ссылки только на первую 
и третью части статьи, а есть ещё и вторая:

* http://7i.7iskusstv.com/y2019/nomer10/turchin/

 

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

 

From: Andrei Klimov [mailto:and...@klimov.net] 
Sent: Friday, February 14, 2020 10:51 PM
To: metacomputation-ru ; refal@botik.ru
Subject: День Валентина Турчина

 

Добрый день всем!

 

Сегодня 14 февраля день не только Святого Валентина, но и нами более любимого и 
ценимого Валентина Федоровича Турчина – его день рождения (1931).

 

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

 

Образ Валентина Федоровича и его цельное эволюционное мировоззрение живет в нас 
и помогает нам не растеряться в нынешнем бурном потоке событий и новых явлений 
– от научных и социальных до философских вопросов – смысла жизни, этики, добра, 
отношения к смерти и бессмертию, нашего места в мире и принятия решений о наших 
личных поступках.

 

В качестве подарка нашему сообществу рад сообщить, что в прошлом году была 
опубликована на популярном сайте – в двух выпусках интернет-журнала "Семь 
искусств" – одна из последних статей Валентина Турчина в переводе на русский:

*   Диалог о метасистемном переходе

*   http://7i.7iskusstv.com/y2019/nomer9/turchin/
*   http://7i.7iskusstv.com/y2019/nomer11/turchin/

Прекрасный перевод с английского сделал Владимир Балтер. Вот ссылки на оригинал:

*   A dialogue on Metasystem transition, World Futures, 45:1-4, 5-57, 1995. 
DOI: 10.1080/02604027.1995.9972553 
 

*   https://www.tandfonline.com/doi/abs/10.1080/02604027.1995.9972553 – 
официальная страница статьи, куда ведет и указанный DOI. Официально PDF-файл 
бесплатно не дают, но... сами знаете.
*   http://pespmc1.vub.ac.be/Papers/Turchin/dialog.pdf – файл "препринта" 
на сайте ""Principia Cybernetica".
*   
https://pat.keldysh.ru/~roman/doc/Turchin/1999-Turchin--A_Dialogue_on_Metasystem_Transition.pdf
 – этот же файл, но с обрезанными краями (для удобства чтения на экране и 
печати буклетом) на сайте Сергея Романенко, куда он поместил часть работ 
Турчина.

Всего наилучшего,

Андрей Климов

 

PS. Это письмо послано в Гугл-группу Metacomputation-Ru 
  и в рассылку 
refal@botik.ru  , где сосредоточены большинство 
ценителей научного наследия Турчина по computer science. Кроме того, в "скрытую 
копию" поставлены адреса коллег и друзей, которые отсутствуют в этих рассылках.

 

Публикация "Диалога" на русском – хороший повод обменяться впечатлениями и об 
этой статье, и о всех вопросах связанных с концепцией метасистемного перехода 
Турчина.

 

Гугл-группа Metacomputation-Ru 
 , на мой взгляд, вполне 
подходящее место для обсуждения как этой, так и других работ Турчина. Пишите в 
нее на адрес metacomputation...@googlegroups.com 
 , даже если вы в нее еще не 
подписаны, она открыта и для неподписанных. А мы вас тут же включим для 
получения ответов и всей переписки.

-- 
Вы получили это сообщение, поскольку подписаны на группу "Метавычисления и 
специализация программ".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, 
отправьте письмо на электронный адрес 
metacomputation-ru+unsubscr...@googlegroups.com 
 .
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке 
https://groups.google.com/d/msgid/metacomputation-ru/CAM7HiM%3Da6chjQXk0VQBCx5DgXBKR9ProdNzXg_oyozMyGv_8BQ%40mail.gmail.com
 

 .

RE: Re[2]: семинар ИПС

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!
«Тема интересная. А нельзя ли послушать дистанционно? Я не в Москве.»
Ну так и семинар не в Москве! J
 
А если серьёзно, когда будет известна дата семинара? Я бы съездил.
 
С уважением,
Александр Коновалов
 
From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Tuesday, February 11, 2020 4:40 PM
To: refal@botik.ru
Cc: Andrei P. Nemytykh ; Belyshev D. 
; Evgeny P.Kurshev ; Guliev Y.O. 
; Komarov S. ; Malych V. L. 
; Sergej. V. Znamenskij ; Valeriy 
Yumaguzhin ; Анатолий Цирлин ; 
Вячеслав Хачумов ; Ирина Расина ; Николай 
Непейвода ; Сергей Амелькин ; 
Тищенко И.П. ; Хаткевич Марк Иванович 
; Виноградов Андрей Николаевич ; Yuri 
Sachkov ; Ponomareva S.M. 
Subject: Re[2]: семинар ИПС
 
Добрый день, коллеги!
 
Тема интересная. А нельзя ли послушать дистанционно? Я не в Москве.
 
Вторник, 11 февраля 2020, 16:31 +03:00 от Sergei M. Abramov abram_AT_botik.ru 
mailto:refal@botik.ru> >:
 
> Я получил предложение о докладе на семинаре ИПС, прилагаю ниже.

Это я направил Vladislav Protasov 

> Прошу вас написать мне --- кому-нибудь в ИПС интересна эта тема?

Насколько он мне говорил, автор опирается на MST-теорию В.Ф.Турчина.

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

Ожидаю такой же реакции от рефал-компании.

С уважением,

Абрамов С.М.
ab...@botik.ru
мобильный: +7(903)2928308


> Соответственно найдутся ли желающие прослушать и квалифицированно
> оценить доклад?

> С уважением,
> Ю.Л.Сачков

> 
> Прошу включить в программу Вашего
> семинара доклад "Основы теории и
> практика применения систем
> коллективного интеллекта".
> Краткая аннотация.
> Акторами систем КИ могут быть эксперты,
> компьютерные программы, нейронные
> сети. Введена абсолютная шкала, система
> сертификации и единица измерения
> интеллектуальной силы акторов - 1 ИНТ.
> Доказаны базовые теоремы, получены и
> обоснованы эффекты усиления
> интеллекта в системах КИ и снижения до
> малых величин вероятностей принятия
> ошибочных решений.

> Доцент МАИ, к.ф.-м.н. Протасов Владислав
> Иванович
> ***
 
 
 
С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  
 

Наше дело — РЕФАЛ!

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

«Да здравствует Рефал!»

Александр мне напомнил песню:

 

ШИТРОК
(Оргия праведников)

Корни, кровавые корни!
Лебеди клином летят на восток,
ППШ в моём сердце стрекочет проворно,
Выдавая отчизне отменный шитрок.

Я скитался по странам, мирам и эпохам,
А теперь вот вернулся на отчий порог:
Может быть, ваш Майк Паттон поёт и неплохо,
Только мне это по   , я играю шитрок.

Изучай, если хочешь, Клопштока и Брамса,
Двигай в массы культуру, восторгом горя.
Только помни, что всё это, как ни старайся,
Просто лишняя блажь на пути говнаря.

Так что лучше бросай над собой измываться —
Не один здесь такой обломался пророк.
Есть гитара, есть струны, есть крепкие пальцы —
Ну и всё! Подключайся! Наше дело — шитрок!

Корни, кровавые корни!
Захлебнувшийся степью несётся табун.
Никуда нам не деться от этих аккордов!
Никуда нам не деться от этих шитструн!

(Послушать: https://music.yandex.ru/album/644952/track/5885646)

 

Так что наше дело — Рефал, и никуда нам от него не деться.

Изучай, если хочешь, и Агду, и Хаскель,
Двигай в массы type checking восторгом горя…

 

Удачи всем!
Александр Коновалов

 

P.S.: письмо выражает исключительно моё настроение.

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Wednesday, January 1, 2020 12:31 AM
To: refal 
Subject: Re: С Новым 2020 годом и скорым Рождеством Христовым!

 

С новым, 2020 годом! 

Да здравствует Рефал!

 



Отправлено из мобильной Почты Mail.ru

RE: Прогонка по Турчину и неуспехи

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!
Мне в личке справедливо пожаловались на «многабукаф — ниасилил», поэтому даю 
конспект письма про прогонку и неуспехи.
В первой части письма я кратко написал что такое прогонка, как её определил 
Турчин, и разобрал прогонку на примере. На этом примере было показано, что 
прогонка по Турчину для ограниченного Рефала (подмножество базисного Рефала) 
может расширять область определения программы.
Во второй части письма я предложил другое подмножество Рефала — ограниченный 
Рефал-6, в котором прогонка по Турчину уже не расширяет область определения 
программы. Ограниченный Рефал-6 является базисным подмножеством Рефала-6, в 
котором разрешены только L-образцы и, что главное, вместо равенства части 
предложения разделяются запятой.
В третьей части письма я спекулирую на тему того, что суперкомпилятор 
ограниченного Рефала расширяет область определения программы и предлагаю 
несколько способов это расширение обуздать.
 
С уважением,
Александр Коновалов 
 
From: Александр Коновалов a.v.konovalov87_AT_mail.ru  
Sent: Wednesday, December 18, 2019 1:13 AM
To: refal@botik.ru
Subject: Прогонка по Турчину и неуспехи
 
Доброй ночи всем!
Пришло в голову одно интересное соображение. Но сначала контекст.
В 1974 году Турчин описал прогонку как эквивалентное преобразование программы 
на Рефале (Москва: ЦНИПИАСС, 1974 ( 

 pdf)). На самом деле прогонка была описана на два года раньше (Киев-Алушта, 
1972 ( 

 pdf)), но там термина «прогонка» ещё не было.
В этих работах описывается подмножество базисного Рефала — ограниченный Рефал, 
в котором в образцах запрещены любые t-переменные и открытые и повторные 
e-переменные. Для этого подмножества определена прогонка — замена одного из 
предложений функции F, содержащей вызов функции G на эквивалентный набор 
предложений (в том числе и пустой), в которых вызов G отсутствует. При этом 
семантика функции F на исходной области определения не меняется. Однако, 
область определения функции F при этом может расшириться — если ранее программа 
вылетала с ошибкой невозможности отождествления, то после прогонки одного из 
вызовов функции программа может перестать падать (вместо чего выдавать какой-то 
результат или зацикливаться).
Алгоритм прогонки я здесь описывать не буду, поскольку он есть в статьях по 
гиперссылкам выше. Лучше читать работу Киев-Алушта, 1972 ( 

 pdf), поскольку она короче. Прогонка в ней — правило EF1.
Покажу на примере, как прогонка расширяет область определения. Пример простой, 
но расписан подробно, читать рекомендуется по диагонали.
Буду использовать синтаксис Рефала-5, поскольку мне он более привычен.
F {
  A e.Z = 1 e.Z;
  s.X e.Z =  e.Z;
  t.X e.Z = 100 e.Z;
}

G {
  P = 10;
  Q = 20;
}
При прогонке мы комбинируем левые части предложений прогоняемой функции G с 
левой частью предложения, содержащего вызов прогоняемой функции. Сам вызов 
прогоняемой функции заменяем на соответствующие правые части. В результате 
получится такая функция F:
F {
  A e.Z = 1 e.Z;
  P e.Z = 10 e.Z;
  Q e.Z = 20 e.Z;
  t.X e.Z = 100 e.Z;
}
Но, можно заметить, что область определения расширилась. Если ранее вызов  падал:
 →  Y Z → ошибка
то теперь он выдаёт ответ:
 → 100 Y Z
Почему так происходит?
Рассмотрим сначала корректный случай, например, .
До прогонки:
 →  R S → 20 R S
В исходной функции F аргумент сопоставится с левой частью второго предложения. 
Вызов заменится на правую часть, где уже будет располагаться вызов . Для 
этого вызова применится второе предложение G, поскольку первое будет 
неприменимо. Т.е. сначала второе предложение F, а затем второе предложение G.
После прогонки:
 → 20 R S
После прогонки сразу активируется третье предложение новой функции F, которое 
является комбинацией исходного второго предложения F и исходного второго 
предложения G. Второе предложение новой функции F здесь тоже будет неприменимо, 
поскольку оно является комбинацией исходного второго предложения и первого 
предложения функции G.
Теперь вернёмся к примеру . До прогонки активировалось второе 
предложение F, после чего вызов G падал, поскольку ни одно из его предложений 
не применимо. После прогонки становятся неприменимыми второе и третье 
предложения новой функции F (т.к. неприменимы их прообразы в G) и управление 
передаётся на четвёртое предложение.
Т.е. область определения может расширяться на те случаи, где прогоняемый вызов 
должен был падать. (А может и не расширяться, если, к примеру, прогоняемый 
вызов никогда не падает или предложение с этим вызовом самое последнее.)
 
Теперь перехожу к сути письма.
Условимся, что прогонять мы будем только самый первый вызов с пас

Перехват ошибок в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Александр!

А что Вы подразумеваете под неуспехами?

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Wednesday, December 18, 2019 11:28 AM
To: Stelletsky V 
Cc: refal@botik.ru
Subject: Re[2]: Прогонка по Турчину и неуспехи

 

Добрый день, Василий!

Такая технология мне понятна, но речь идет о простоте в использовании для 
"рядового" программирования. Кроме того в больших проектах не навставляешься 
таких строк. Их как раз может добавлять суперкомпилятор при подготовке 
программы к исполнению.



Среда, 18 декабря 2019, 10:36 +03:00 от Stelletsky V mailto:s...@cnshb.ru> >:

Добрый день!
Александр! Есть 3-й самый простой вариант: добавляете в проблемную функцию еще 
одно (или больше) предложение – вот Вам и обработка неуспеха! Если они что-то 
выводят – можете проанализировать «листинг»…
Я, например, после «сложных» программ, которые могут «свалиться» делаю проверку 
на наличие «дампа» и в этом случае останавливаю выполнение bat-файла, а то и 
шлю себе на почту сообщение об аварии…

 

С уважением,
Василий Стеллецкий
--
Vasily Stelletsky  mailto:s...@cnshb.ru   mailto:sw...@ya.ru
  http://www.cnshb.ru/vniitei/sw/
 http://sw710.narod.ru

  _  

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Wednesday, December 18, 2019 9:44 AM
To: refal@botik.ru  
Subject: Re: Прогонка по Турчину и неуспехи

 

Доброго утра!

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

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

Напрашиваются два решения: 
1. либо расширять язык обработкой неуспехов, что приведёт, скорее всего, к 
возрастанию сложности понимания языка;
2. либо пытаться решить проблему средствами суперкомпиляции, либо исправляя 
"сомнительные" места, либо на них указывая. Это сильно сложнее, но зато скрыто 
от пользователя - вполне заурядного программиста и ему сильно легче.

Сейчас ни тот ни другой путь ещё не пройден до конца, как я думаю.

Интересно, есть ли ещё варианты?

Да, мне кажется, что базисный Рефал - это минимум, ниже которого опускаться не 
следует. Это сильно сужает гибкость языка и может служить только чисто 
теоретическим целям.

Среда, 18 декабря 2019, 1:16 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:

Доброй ночи всем!

Пришло в голову одно интересное соображение. Но сначала контекст.

В 1974 году Турчин описал прогонку как эквивалентное преобразование программы 
на Рефале (Москва: ЦНИПИАСС, 1974 ( 

 pdf)). На самом деле прогонка была описана на два года раньше (Киев-Алушта, 
1972 ( 

 pdf)), но там термина «прогонка» ещё не было.

В этих работах описывается подмножество базисного Рефала — ограниченный Рефал, 
в котором в образцах запрещены любые t-переменные и открытые и повторные 
e-переменные. Для этого подмножества определена прогонка — замена одного из 
предложений функции F, содержащей вызов функции G на эквивалентный набор 
предложений (в том числе и пустой), в которых вызов G отсутствует. При этом 
семантика функции F на исходной области определения не меняется. Однако, 
область определения функции F при этом может расшириться — если ранее программа 
вылетала с ошибкой невозможности отождествления, то после прогонки одного из 
вызовов функции программа может перестать падать (вместо чего выдавать какой-то 
результат или зацикливаться).

Алгоритм прогонки я здесь описывать не буду, поскольку он есть в статьях по 
гиперссылкам выше. Лучше читать работу Киев-Алушта, 1972 ( 

 pdf), поскольку она короче. Прогонка в ней — правило EF1.

Покажу на примере, как прогонка расширяет область определения. Пример простой, 
но расписан подробно, читать рекомендуется по диагонали.

Буду использовать синтаксис Рефала-5, поскольку мне он более привычен.

F {
  A e.Z = 1 e.Z;
  s.X e.Z =  e.Z;
  t.X e.Z = 100 e.Z;
}

G {
  P = 10;
  Q = 20;
}

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

RE: Прогонка по Турчину и неуспехи

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

А при ответе на это письмо давайте обсуждать только прогонку в Рефале с 
неуспехами.

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Wednesday, December 18, 2019 1:13 AM
To: refal@botik.ru
Subject: Прогонка по Турчину и неуспехи

 

Доброй ночи всем!

Пришло в голову одно интересное соображение. Но сначала контекст.

В 1974 году Турчин описал прогонку как эквивалентное преобразование программы 
на Рефале (Москва: ЦНИПИАСС, 1974 ( 

 pdf)). На самом деле прогонка была описана на два года раньше (Киев-Алушта, 
1972 ( 

 pdf)), но там термина «прогонка» ещё не было.

В этих работах описывается подмножество базисного Рефала — ограниченный Рефал, 
в котором в образцах запрещены любые t-переменные и открытые и повторные 
e-переменные. Для этого подмножества определена прогонка — замена одного из 
предложений функции F, содержащей вызов функции G на эквивалентный набор 
предложений (в том числе и пустой), в которых вызов G отсутствует. При этом 
семантика функции F на исходной области определения не меняется. Однако, 
область определения функции F при этом может расшириться — если ранее программа 
вылетала с ошибкой невозможности отождествления, то после прогонки одного из 
вызовов функции программа может перестать падать (вместо чего выдавать какой-то 
результат или зацикливаться).

Алгоритм прогонки я здесь описывать не буду, поскольку он есть в статьях по 
гиперссылкам выше. Лучше читать работу Киев-Алушта, 1972 ( 

 pdf), поскольку она короче. Прогонка в ней — правило EF1.

Покажу на примере, как прогонка расширяет область определения. Пример простой, 
но расписан подробно, читать рекомендуется по диагонали.

Буду использовать синтаксис Рефала-5, поскольку мне он более привычен.

F {
  A e.Z = 1 e.Z;
  s.X e.Z =  e.Z;
  t.X e.Z = 100 e.Z;
}

G {
  P = 10;
  Q = 20;
}

При прогонке мы комбинируем левые части предложений прогоняемой функции G с 
левой частью предложения, содержащего вызов прогоняемой функции. Сам вызов 
прогоняемой функции заменяем на соответствующие правые части. В результате 
получится такая функция F:

F {
  A e.Z = 1 e.Z;
  P e.Z = 10 e.Z;
  Q e.Z = 20 e.Z;
  t.X e.Z = 100 e.Z;
}

Но, можно заметить, что область определения расширилась. Если ранее вызов  падал:

 →  Y Z → ошибка

то теперь он выдаёт ответ:

 → 100 Y Z

Почему так происходит?

Рассмотрим сначала корректный случай, например, .

До прогонки:

 →  R S → 20 R S

В исходной функции F аргумент сопоставится с левой частью второго предложения. 
Вызов заменится на правую часть, где уже будет располагаться вызов . Для 
этого вызова применится второе предложение G, поскольку первое будет 
неприменимо. Т.е. сначала второе предложение F, а затем второе предложение G.

После прогонки:

 → 20 R S

После прогонки сразу активируется третье предложение новой функции F, которое 
является комбинацией исходного второго предложения F и исходного второго 
предложения G. Второе предложение новой функции F здесь тоже будет неприменимо, 
поскольку оно является комбинацией исходного второго предложения и первого 
предложения функции G.

Теперь вернёмся к примеру . До прогонки активировалось второе 
предложение F, после чего вызов G падал, поскольку ни одно из его предложений 
не применимо. После прогонки становятся неприменимыми второе и третье 
предложения новой функции F (т.к. неприменимы их прообразы в G) и управление 
передаётся на четвёртое предложение.

Т.е. область определения может расширяться на те случаи, где прогоняемый вызов 
должен был падать. (А может и не расширяться, если, к примеру, прогоняемый 
вызов никогда не падает или предложение с этим вызовом самое последнее.)

 

Теперь перехожу к сути письма.

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

Определим такой ограниченный Рефал-6 — подмножество Рефала-6, в котором 
предложения могут иметь вид «L-образец, результат». Т.е. в отличие от базисного 
Рефала, в ограниченном Рефале-6 правая часть отделена от левой не равенством, а 
запятой.

Что это даёт. Если в Рефале-6 ни одно из предложений функции оказалось 
неприменимо, то программа аварийно не завершается, вместо этого функция 
вырабатывает особое значение — «неуспех». Если функция возвратила неуспех в 
результатном выражении после знака «=», то программа уже падает с ошибкой 
«неперехваченный неуспех». Если неуспех возник в результатном выражении по

Перехват ошибок в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброе утро, Александр и Василий!

Исходное письмо было посвящено не обработке ошибок, а тонкостям семантики 
прогонки. И именно эту семантику мне хотелось обсудить (надеюсь, мне что-нибудь 
ответят).

Но тема обработки ошибок в Рефале тоже интересная, и её тоже стоит обсудить. 
Поэтому я отправляю это письмо с новой темой.

По перехвату ошибок у меня тоже есть соображения, но напишу их ближе к вечеру, 
когда у меня появится время. Также вечером содержательнее отвечу на ваши письма.

 

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

 

From: Stelletsky V swi_AT_cnshb.ru [mailto:refal@botik.ru] 
Sent: Wednesday, December 18, 2019 10:33 AM
To: 'Александр Гусев' ; refal@botik.ru
Subject: RE: Прогонка по Турчину и неуспехи

 

Добрый день!
Александр! Есть 3-й самый простой вариант: добавляете в проблемную функцию еще 
одно (или больше) предложение – вот Вам и обработка неуспеха! Если они что-то 
выводят – можете проанализировать «листинг»…
Я, например, после «сложных» программ, которые могут «свалиться» делаю проверку 
на наличие «дампа» и в этом случае останавливаю выполнение bat-файла, а то и 
шлю себе на почту сообщение об аварии…

 

С уважением,
Василий Стеллецкий
--
Vasily Stelletsky    mailto:s...@cnshb.ru
 mailto:sw...@ya.ru
  http://www.cnshb.ru/vniitei/sw/
 http://sw710.narod.ru

  _  

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Wednesday, December 18, 2019 9:44 AM
To: refal@botik.ru  
Subject: Re: Прогонка по Турчину и неуспехи

 

Доброго утра!

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

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

Напрашиваются два решения: 
1. либо расширять язык обработкой неуспехов, что приведёт, скорее всего, к 
возрастанию сложности понимания языка;
2. либо пытаться решить проблему средствами суперкомпиляции, либо исправляя 
"сомнительные" места, либо на них указывая. Это сильно сложнее, но зато скрыто 
от пользователя - вполне заурядного программиста и ему сильно легче.

Сейчас ни тот ни другой путь ещё не пройден до конца, как я думаю.

Интересно, есть ли ещё варианты?

Да, мне кажется, что базисный Рефал - это минимум, ниже которого опускаться не 
следует. Это сильно сужает гибкость языка и может служить только чисто 
теоретическим целям.

Среда, 18 декабря 2019, 1:16 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:

Доброй ночи всем!

Пришло в голову одно интересное соображение. Но сначала контекст.

В 1974 году Турчин описал прогонку как эквивалентное преобразование программы 
на Рефале (Москва: ЦНИПИАСС, 1974 ( 

 pdf)). На самом деле прогонка была описана на два года раньше (Киев-Алушта, 
1972 ( 

 pdf)), но там термина «прогонка» ещё не было.

В этих работах описывается подмножество базисного Рефала — ограниченный Рефал, 
в котором в образцах запрещены любые t-переменные и открытые и повторные 
e-переменные. Для этого подмножества определена прогонка — замена одного из 
предложений функции F, содержащей вызов функции G на эквивалентный набор 
предложений (в том числе и пустой), в которых вызов G отсутствует. При этом 
семантика функции F на исходной области определения не меняется. Однако, 
область определения функции F при этом может расшириться — если ранее программа 
вылетала с ошибкой невозможности отождествления, то после прогонки одного из 
вызовов функции программа может перестать падать (вместо чего выдавать какой-то 
результат или зацикливаться).

Алгоритм прогонки я здесь описывать не буду, поскольку он есть в статьях по 
гиперссылкам выше. Лучше читать работу Киев-Алушта, 1972 ( 

 pdf), поскольку она короче. Прогонка в ней — правило EF1.

Покажу на примере, как прогонка расширяет область определения. Пример простой, 
но расписан подробно, читать рекомендуется по диагонали.

Буду использовать синтаксис Рефала-5, поскольку мне он более привычен.

F {
  A e.Z = 1 e.Z;
  s.X e.Z =  e.Z;
  t.X e.Z = 100 e.Z;
}

G {
  P = 10;
  Q = 20;
}

При пр

Прогонка по Турчину и неуспехи

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброй ночи всем!

Пришло в голову одно интересное соображение. Но сначала контекст.

В 1974 году Турчин описал прогонку как эквивалентное преобразование программы 
на Рефале (Москва: ЦНИПИАСС, 1974 ( 

 pdf)). На самом деле прогонка была описана на два года раньше (Киев-Алушта, 
1972 ( 

 pdf)), но там термина «прогонка» ещё не было.

В этих работах описывается подмножество базисного Рефала — ограниченный Рефал, 
в котором в образцах запрещены любые t-переменные и открытые и повторные 
e-переменные. Для этого подмножества определена прогонка — замена одного из 
предложений функции F, содержащей вызов функции G на эквивалентный набор 
предложений (в том числе и пустой), в которых вызов G отсутствует. При этом 
семантика функции F на исходной области определения не меняется. Однако, 
область определения функции F при этом может расшириться — если ранее программа 
вылетала с ошибкой невозможности отождествления, то после прогонки одного из 
вызовов функции программа может перестать падать (вместо чего выдавать какой-то 
результат или зацикливаться).

Алгоритм прогонки я здесь описывать не буду, поскольку он есть в статьях по 
гиперссылкам выше. Лучше читать работу Киев-Алушта, 1972 ( 

 pdf), поскольку она короче. Прогонка в ней — правило EF1.

Покажу на примере, как прогонка расширяет область определения. Пример простой, 
но расписан подробно, читать рекомендуется по диагонали.

Буду использовать синтаксис Рефала-5, поскольку мне он более привычен.

F {
  A e.Z = 1 e.Z;
  s.X e.Z =  e.Z;
  t.X e.Z = 100 e.Z;
}

G {
  P = 10;
  Q = 20;
}

При прогонке мы комбинируем левые части предложений прогоняемой функции G с 
левой частью предложения, содержащего вызов прогоняемой функции. Сам вызов 
прогоняемой функции заменяем на соответствующие правые части. В результате 
получится такая функция F:

F {
  A e.Z = 1 e.Z;
  P e.Z = 10 e.Z;
  Q e.Z = 20 e.Z;
  t.X e.Z = 100 e.Z;
}

Но, можно заметить, что область определения расширилась. Если ранее вызов  падал:

 →  Y Z → ошибка

то теперь он выдаёт ответ:

 → 100 Y Z

Почему так происходит?

Рассмотрим сначала корректный случай, например, .

До прогонки:

 →  R S → 20 R S

В исходной функции F аргумент сопоставится с левой частью второго предложения. 
Вызов заменится на правую часть, где уже будет располагаться вызов . Для 
этого вызова применится второе предложение G, поскольку первое будет 
неприменимо. Т.е. сначала второе предложение F, а затем второе предложение G.

После прогонки:

 → 20 R S

После прогонки сразу активируется третье предложение новой функции F, которое 
является комбинацией исходного второго предложения F и исходного второго 
предложения G. Второе предложение новой функции F здесь тоже будет неприменимо, 
поскольку оно является комбинацией исходного второго предложения и первого 
предложения функции G.

Теперь вернёмся к примеру . До прогонки активировалось второе 
предложение F, после чего вызов G падал, поскольку ни одно из его предложений 
не применимо. После прогонки становятся неприменимыми второе и третье 
предложения новой функции F (т.к. неприменимы их прообразы в G) и управление 
передаётся на четвёртое предложение.

Т.е. область определения может расширяться на те случаи, где прогоняемый вызов 
должен был падать. (А может и не расширяться, если, к примеру, прогоняемый 
вызов никогда не падает или предложение с этим вызовом самое последнее.)

 

Теперь перехожу к сути письма.

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

Определим такой ограниченный Рефал-6 — подмножество Рефала-6, в котором 
предложения могут иметь вид «L-образец, результат». Т.е. в отличие от базисного 
Рефала, в ограниченном Рефале-6 правая часть отделена от левой не равенством, а 
запятой.

Что это даёт. Если в Рефале-6 ни одно из предложений функции оказалось 
неприменимо, то программа аварийно не завершается, вместо этого функция 
вырабатывает особое значение — «неуспех». Если функция возвратила неуспех в 
результатном выражении после знака «=», то программа уже падает с ошибкой 
«неперехваченный неуспех». Если неуспех возник в результатном выражении после 
знака «,», то он может быть перехвачен и обработан программой. Я здесь не буду 
подробно описывать семантику неуспехов, она есть в 
  руководстве к Рефалу-6. Отмечу 
лишь, что в программах ограниченного Рефала-6 управление 

RE: Статическая типизация в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Аркадий!

«В данном контексте „мощнее“ не значит „лучше“ — поскольку сложнее (или 
невозможно) будет проверять.»

Так и есть. В исходной постановке задачи (с рекурсивными e-типами) мы имеем 
контекстно-свободную грамматику, с ней всё сложно.

В постановке задачи Михаила — всё разрешимо, но может быть вычислительно 
сложно, поскольку нужно работать с конечными (древесными) автоматами: 
детерминизация, вложение, объединение, пересечение.

В постановке задачи с одним итератором — я точно пока не знаю. Например, как 
проверить вложение — я не знаю. 

 

«Честно говоря, я не могу сказать, что вполне и до конца понимаю систему 
Михаила, её возможности и ограничения. В самом письме многое неформально, от 
формализации автор уклонился.»

Автор, вероятно, предполагал, что подписчики знают, что такое древесные 
автоматы. А оказалось, что не все.

 

Древесный автомат — обобщение конечного автомата на деревья.

Можно сказать, что конечный автомат «разукрашивает» в состояния символы строки, 
последний символ строки должен принадлежать множеству финальных состояний. Для 
древесных автоматов ситуация похожая.

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

Нисходящий автомат раскрашивает корень в некоторое начальное состояние. Затем 
спускается вниз, раскрашивает узлы в зависимости от состояния («цвета») 
родителя и метки (конструктора) узла. Листья должны быть раскрашены в финальные 
состояния.

Восходящий автомат наоборот раскрашивает листья в начальные состояния в 
зависимости от их меток. Затем раскрашивает узлы в состояния в зависимости от 
меток узлов и цветов (состояний) потомков. Корень должен принадлежать множеству 
финальных состояний.

Нисходящие автоматы являются подмножеством восходящих. Это значит, что для 
любого нисходящего автомата можно построить эквивалентный восходящий, т.е. 
принимающий то же множество деревьев. Обратное неверно.

Можно в качестве примера рассмотреть бинарное дерево, у которого листья и 
внутренние узлы помечены числами «0» и «1». Нужно проверить, что сумма всех 
меток дерева чётная.

Раскрашиваем листья в чёт-нечет в зависимости от их меток, соответственно, «0» 
или «1». Соответственно, раскрашиваем снизу вверх внутренние узлы в зависимости 
от их меток и раскраски потомков (〈0,ч,ч〉→ч, 〈0,ч,н〉→н, …, 〈1,н,н〉→н). Если 
корень чётного цвета, то сумма меток чётная, автомат дерево принимает.

 

Как теперь это применить к Рефалу. Любое объектное выражение Рефала можно 
записать внутри круглых скобок и прочитать как S-выражение Лиспа. А S-выражение 
Лиспа — это двоичное дерево, узлы — cons-ячейки, листья — атомы. И его тип 
можно проверить древесным автоматом.

Вообще, есть на самом деле забористые автоматы (hedge automata, hedge (англ.) — 
забор, ограда), они используются для сильноветвящихся деревьев, где число 
потомков у вершин произвольное. Цвет вершины там определяется меткой вершины и 
регулярным выражением, описывающим цвета вершин потомков. Они эквивалентны 
древесным автоматам: для любого сильноветвящегося дерева можно построить 
эквивалентное двоичное дерево (например, объектное выражение → S-выражение) и, 
соответственно, для любого забористого автомата — эквивалентный древесный 
автомат.

По сути забористые автоматы применимы к Рефалу непосредственно, и, видимо, их 
имел ввиду Михаил.

 

Вообще, есть фундаментальная книжка по древесным автоматам — «Tree Automata: 
Techniques and Applications»:

https://mazdaywik.github.io/direct-link/4.pdf/tata.pdf

Восьмой раздел про забористые автоматы. Определение на странице 202.

 

Древесные автоматы, также как и конечные, замкнуты относительно 
теоретико-множественных операций (объединение, пересечение, разность, 
дополнение до универсума), для них можно определить пустоту, вложение (как 
пустота разности) и много чего ещё. От себя добавлю, древесные автоматы можно 
сопоставлять с L-образцами Рефала (без повторных переменных). Если в образце 
есть повторные переменные, то их тип можно определить как пересечение типов 
каждого из вхождений переменной. Про открытые переменные я пока ничего не знаю. 

 

«Боюсь, не все будет так просто.»

Не, пересечение вычислить просто (и довольно красиво). А вот вложение — я не 
знаю как.

Вернее, эта нотация вкладывается в нотацию для древесных (забористых) 
автоматов, а для них вложение проверяется. Но это не очень красиво — лучше 
сразу тогда рассматривать древесные автоматы. А как непосредственно для данной 
нотации проверять вложение — не очевидно. Например,

e.Small ::= s.AB Y*
s.AB ::= A | B

e.Great ::=
A s.XY*
  | B s.YZ*
s.XY ::= X | Y
s.YZ ::= Y | Z

Множество, описываемое типом e.Small, вкладывается во множество, описываемое 
e.Great. e.Small описывает строки, начинающиеся на A или B, за которыми следует 
произвольное количество игреков. e.Great описывает или строки, начинающиеся с 
A, за которыми следует произвольное количество иксов или игреков, или с B, за 
которыми произ

RE: Статическая типизация в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Аркадий!

«Александр, спасибо, что реанимировали старую дискуссию.»

Некропостинг эпический. Реанимируем дискуссию 20-летней давности. Когда Вы 
писали то письмо, мне было 12 лет. Как Вы там писали: «Хорошо бы кто-то из 
молодых за это взялся.».

 

«Поэтому я даже перенёс тексты писем моего и Михаила в docx-файлы, которые 
прилагаю.»

Спасибо!

 

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

Для начала надо разобраться с типами первого порядка (уровень условного 
«Паскаля»). Потом уже думать о параметрическом полиморфизме языка первого 
порядка (уровень «шаблонов Си++»), а уже потом замахиваться на высший порядок с 
функциями вроде Map. В Рефале Плюс, где есть форматы функций, косвенный вызов 
доступен только для функций формата e = e.

 

«И пожалуй, действительно, лучше ввести итератор, а тогда можно и отказаться от 
e-рекурсии на верхнем уровне типа.»

Если у Вашей системы типов убрать требование попарного непересечения, то 
благодаря e-рекурсии система становится даже более мощной, чем система Михаила 
Ковтуна.

Система Михаила описывает типы некоторыми регулярными выражениями. А их можно 
привести к эквивалентной грамматике, где правила имеют вид

e.Type ::= ε
  | e.Type1 (e.Type1′)
  | e.Type2 (e.Type2′)
  | …
  | e.Type1″ SYM1
  | e.Type2″ SYM2
  | …

t.Type ::= SYM1 | SYM2 | … | (e.Type)

Т.е. описывается при помощи L-образцов с e-рекурсией. Но проверить попарное 
непересечение в этой системе трудно (вернее, можно доказать «по построению»).

А почему более мощной? Потому что допускаются некоторые контекстно-свободные 
языки вроде

e.Rec ::= ε | L e.Rec R

Язык описывает цепочки вида Ln Rn, где n ≥ 0.

А вот система с итератором и без e-рекурсии как раз наоборот является 
подмножеством системы Михаила. 

 

«Возможно, моё ограничение на непересечение образцов из правых частей при 
игнорировании типовых атрибутов можно ослабить»

Оно вообще, как мне кажется, необязательно — можно проверять корректность 
программ и с типами, имеющими неортогональные альтернативы (далее 
«неортогональные типы» для краткости).

Вообще, система с одним итератором замкнута относительно пересечения, т.е. 
тип-пересечение тоже выражается при помощи той же нотации (могу доказать). 
Причём, если в исходных грамматиках альтернативы были ортогональными, то в 
грамматике типа-пересечения альтернативы тоже будут ортогональными (тоже могу 
доказать).

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

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

 

«…по моему опыту отладка в Рефале на >90% сводится к запускам тестов, 
натыканиям на „Отождествление невозможно“ и правкой ошибок, которые могли быть 
обнаружены на стадии компиляции хорошим типизатором вроде обсуждаемого.»

Статистику не вёл, но охотно верю.

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Thursday, December 5, 2019 6:55 PM
To: refal@botik.ru
Subject: Re: Статическая типизация в Рефале

 

Александр, спасибо, что реанимировали старую дискуссию.

Считаю, эта тема по прежнему трепещет и требует внимания.

Поэтому я даже перенес тексты писем моего и Михаила в docx-файлы, которые 
прилагаю. 

Правил только форматирование, содержание сохранил вплоть до стилистики. Тему 
вынес в имена файлов. Теперь их легко напечатать и читать с бумаги. 

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

И пожалуй, действительно, лучше ввести итератор, а тогда можно и отказаться от 
e-рекурсии на верхнем уровне типа.

Возможно, мое ограничение на непересечение образцов из правых частей при 
игнорировании типовых атрибутов можно ослабить, чтобы допускались примеры из 
диплома: например, таковое непересечение должно возникать после ряда 
подстановок (раскрытий) типов в правых частях на некоторую конечную глубину.

Будет время, я хочу прошерстить свои коды на рефале-6, чтоб понять, достаточно 
ли будет этого механизма.

Аппелируя к письмам Потанина и Абрамова, хочу вставить, что по моему опыту 
отладка в Рефале на >90% сводится к запускам тестов, натыканиям на 
"Отождествление не

Статическая типизация в Рефале

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!

Предлагаю продолжить дискуссию 20-летней давности, а именно, обсудить 
статическую типизацию в Рефале. Тема уже поднималась в рассылке как минимум 2 
раза.

Первый раз Аркадий Климов предложил определять типы вариантом L-выражений (11 
августа 1999):

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

Рекомендую прочитать это письмо, прежде чем читать дальше. В нём Аркадий описал 
типизацию как теоретическую проблему, предложил приемлемое на практике решение 
и перечислил задачи, которые требуется решить при реализации типизации. 

Второй раз Михаил Ковтун предложил использовать древесные автоматы (19 августа 
2001):

https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0222-utf8.html
https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0223-utf8.html
https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0224-utf8.html
https://mazdaywik.github.io/direct-link/refal-botik-ru/refal/0225-utf8.html

Здесь в первом письме Михаил описывает свой подход в типизации, во втором 
Аркадий комментирует его соображения, в третьем и четвёртом Михаил Потанин и 
Сергей Абрамов дают непринципиальные уточнения. В общем, из этой переписки 
достаточно внимательно прочитать только первые два.

(Эти письма конвертированы в UTF-8, поэтому должны открываться нормально.)

 

Я сам как-то пытался реализовать прототип статической типизации — давал задачу 
на ВКР бакалавра (диплом). Но, поскольку эту тему взял студент-двоечник, ничего 
толкового не получилась. Остался проект с путанным кодом на Java, в 
src/main/resources/docs можно найти записку к диплому:

https://github.com/bmstu-iu9/refal-type-verifier
https://github.com/bmstu-iu9/refal-type-verifier/tree/master/src/main/resources/docs

(записка довольно сумбурная)

Мой подход был близок к подходу Аркадия с тем отличием, что рекурсия для 
e-переменных на верхнем уровне запрещена, но допустим итератор (звёздочка) для 
одного терма.

Система типов для Рефала, на мой взгляд, обязательно должна включать 
параметрический полиморфизм. Допустим, есть такая функция:

Rev {
  t.First e.Mid t.Last = t.Last  t.First;
  t.One = t.One;
  /* пусто */ = /* пусто */;
}

Вот какой у неё тип?

 == t.x*

для любого t.x. Т.е. если функция вызывается со строкой символов — она должна 
возвращать строку. Если последовательность скобочных термов с какой-то хитрой 
структурой — на выходе должны быть они же.

Подход Аркадия, как мне кажется, проще расширить на обобщённые типы, нежели 
подход Михаила. Потому что в случае древесных автоматов нужно научиться решать 
регулярные неравенства, а как их решать, тем более эффективно — понятия не 
имею. 

 

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

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день всем!

Я, похоже, нашёл подходящий термин. Бойко назвал Рефал _слаботипизированным_ 
языком, имея в виду то, что базовых типов мало и пользователь не может 
создавать новые типы. Но термин _слабая типизация_ (weak typing, синоним: 
нестрогая типизация) уже занят, означает, что компилятор допускает неявные 
преобразования между типами (вроде Math.sin("3.14")).

Предлагаю применительно к Рефалу и вообще в подобном смысле использовать термин 
_бедная_ типизация. _Богатая типизация_ — типов много, пользователь может 
определять новые типы самыми разнообразными способами. _Бедная_ — ничего 
интересного с типами язык не даёт. Скажем, в древних Фортране-66 или Алголе-60 
система типов была бедная — целые, вещественные и их массивы различных 
размерностей. В Паскале система типов богаче. В Алголе-68 ещё богаче (во всяком 
случае, интереснее).


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


-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com 
Sent: Monday, December 2, 2019 1:13 AM
To: refal@botik.ru
Subject: Re: Нужна ли "Ленинская простота" в Рефале?

> Распространённая терминологическая ошибка 

Александр,

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

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

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

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

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

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброй ночи, Александр!

Я по мере сил развиваю Рефал-5λ, который лежит на GitHub, и чисто для себя 
пользуюсь тамошним багтрекером 
  для документации планов и 
задач. Ранее, когда я разрабатывал Модульный Рефал, у меня был (и остался) 
текстовый файлик 

 , который исполняет роль таск-трекера (см. там запись от 20.10.2007). Когда я 
его начал вести, о таск-трекерах ничего не знал.

Так что таск-трекеры могут быть полезны и для маленькой команды вплоть до 
одного программиста (но без фанатизма конечно).

 

По поводу IDE. Среда для Eclipse — она для Рефала Плюс. Писалась вроде лет 10 
назад, не уверен, что она пойдёт на современных версиях Eclipse. Я её не 
устанавливал, поскольку на Рефале Плюс я не программировал.

Для Рефала-5λ есть плагин для IntellJ IDEA:

https://github.com/bmstu-iu9/RefalFiveLambdaPlugin

Умеет подсвечивать синтаксис, выделять синтаксические ошибки и автодополнять 
имена функций и переменных. Впрочем, в основе этого плагина тоже лежит Java.

 

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

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Monday, December 2, 2019 11:17 PM
To: refal@botik.ru
Subject: Re[2]: Рефал-2, Рефал-5 и стиль программирования

 

Мне удалось поработать в разных программистских командах - от 5 до 5000 человек 
и в разных парадигмах управления процессом. 
Что я вынес:
1. Для большинства задач, которые стоит решать, оптимальным является "метод 
главного программиста", определённый по-моему Бруксом младшим. Максимум 
эффективности и минимум менеджмента. Команда - до 10 человек. Что творится 
внутри никто не знает, но на выходе замечательный работающий код.
2. Когда человек от 10 до пары сотен - хороши средства управления проектом. 
Только не очень заорганизованные, как теперешние. Когда-то я их сам писал. С 
задачами, группами и авторассылками. Теперешние вроде Jira имеют достаточный 
функционал, но требуют чисто технического мышления, как мне кажется. В них 
хорошо работать инженерам, но не учёным. Плюс пара единиц админов в штате.
3. В больших проектах - система управления проектом - это единственное 
средство, позволяющее менеджерам хоть как-то понимать, что происходит. Хотя на 
деле находятся умники, правящие код без учёта в системе, что сильно снижает 
эффективность. Кроме того, о "методе главного программиста", похоже забыли. Это 
превращает продукт в кошмарную кашу из заплат, которые ставят вчерашние 
студенты на коде вполне зрелых спецов. Спасает ситуацию производства реально 
хорошего программиста в высшие менеджеры - это спасает проект. А потом - снова 
неразбериха, стресс, переработки и недовольные пользователи продукта.
4. Контроль версий хорош всегда, даже если в него не заглядывать по пол-года. 
Когда-нибудь он поможет быстро решить багу.
5. Моё поколение выросло на статье "Настоящие программисты не используют 
Паскаль". Вернее, те, кто её приняли и поняли, до сих пор рулят процессом и 
вполне дружат со средствами его организации.

Да, про Рефал. 
Поскольку язык не линейный, разобраться в логике быстро несколько сложнее 
привычными методами если что-то сломалось или логика хромает. Поэтому 
дисциплина разработчиков должна быть на высоте (комментарии и читаемость кода). 
Возможно, лучше всего анализировать код средствами того же Рефала. Т.е. помимо 
компилятора нужен IDE с плагинами на Рефале. И сообществу Рефала выгодно его 
развивать. Я слышал про разработки на базе eclipse, но там Java (?) в основе и 
не слишком складная среда по моему мнению. И охочая до ресурсов памяти. У меня 
IDE в плане, но не в близком.

Понедельник, 2 декабря 2019, 18:04 +03:00 от Andrei Klimov andrei_AT_klimov.net 
mailto:refal@botik.ru> >:

On Mon, Dec 2, 2019 at 5:30 PM Александр Коновалов a.v.konovalov87_AT_mail.ru 
   wrote:

Как это ни парадоксально, но так и должно быть. Но только в сочетании с 
системой управления версиями и системой управления проектом (таск-трекером, 
баг-трекером: Bugzilla, Redmine, Jira, issues в GitHub…).

При этом должна соблюдаться определённая дисциплина (пересказываю статью 
Gaperton’а «Миф о документации, продолжение»).

1.Любой код пишется только в рамках заявки («тикета», «бага», «таска») в 
таск-трекере. Заявка — или ошибка (багрепорт), или задача, поставленная 
руководителем. Самодеятельность запрещена.

2.Обсуждение задачи должно вестись только в комментариях к заявке (не в 
чятиках, не в курилке, не в личной переписке). Таск-трекеры интегрируются с 
почтой, поэтому можно писать письма таск-трекеру с соответствующей темой, они 
сами подошьются к заявке (и разошлются другим, подписанным на заявку).

3.В сообщении коммита пишется понятный осмысленный комментарий и номер 
заявки, к которой код относится. Желательно в один коммит не валить правки 
разного назначения (стилевые, рефакторинг, содержательные, по разным задачам).

4.Коммит пе

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Аркадий!

Его можно читать. Открываете ссылку в Internet Explorer, щёлкаете правой 
кнопкой мыши, «Кодировка» → «Дополнительно» → «Кириллица (KOI8-R)».

В браузерах Edge и Edge Dev (новый на движке Chromium) меню выбора кодировки я 
не нашёл. Других браузеров у меня на компьютере не установлено, подсказать 
настройки кодировки не смогу.

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Monday, December 2, 2019 8:52 PM
To: refal@botik.ru
Subject: Re: Нужна ли "Ленинская простота" в Рефале?

 

 

вс, 1 дек. 2019 г. в 21:18, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:


Статическая типизация Рефала обсуждалась в этой рассылке в незапамятные времена 
(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

Я давно уже хотел найти это свое письмо (первое - 0005). Есть ли возможность 
его читать?

Если у кого получилось, поделитесь опытом плз.

Аркадий 

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Сергей!

«А это было не так. И первая (минимальная не пустая) „неподвижная точка“ — 
Рефал Плюс.»

Рефал-4 замкнут только относительно прогонки. А Рефал Плюс — ещё и относительно 
разрезания стека (ибо коместность).


«Рефал Плюс единственный из Рефалов с коарностью (если даже не единственный 
язык программирования с коарностью в мире).»

В Common Lisp’е функции могут возвращать несколько значений (и это не возврат 
списка):

http://lisper.ru/pcl/the-special-operators#Множественные значения

Механизм, конечно, извращённый, но тем не менее, функция возвращает несколько 
значений.


В языке Go функции тоже могут возвращать несколько значений:

https://ru.wikipedia.org/wiki/Go#Функции_могут_возвращать_несколько_значений

Языки, которые поддерживают кортежи, не считаются. Ну можно вернуть кортеж из 
нескольких значений, но это всё равно будет возврат одного значения — кортежа, 
а не нескольких. В Go нет кортежей, но множественный возврат есть.


Так что Рефал Плюс — не единственный язык с коарность, или слово «коарность» я 
понял не так.


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


-Original Message-
From: Sergei M. Abramov abram_AT_botik.ru  
Sent: Monday, December 2, 2019 5:34 PM
To: Александр Коновалов a.v.konovalov87_AT_mail.ru 
Subject: Re: Нужна ли "Ленинская простота" в Рефале?

День добрый, всем!

> «Постепенно, по мере усложнения задач, возникли желания по оптимизации 
> и оказалось, что проще вводить новые конструкции в язык, чем 
> интеллектуализировать исполнение программы изнутри.»

> Не понял мысль. Речь о каких новых конструкциях?

Ох, для меня важнее другая мотивация: я ее писал и она просто отслеживается в 
статьях С.А.Ромяненко:

1. Рефал задумывался как метаязык.

2. Результат метавычислений над Рефалом должен естественно изобрабаться на 
Рефале.

А это было не так.  И первая (минимальная не пустая) "неподвижная точка" -- 
Рефал Плюс.

PS. Конечно попросят примеров. Напомню один: суперкомпиляция с рассечением 
стеков пораждает функции с коарностью.  Рефал Плюс едиснтвенный из Рефалов с 
коарностью (если дабе не единственный язык программирования с коарностью в 
мире).

Всего доброго,

Сергей Абрамов

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер, Александр!
«А типизацию и в Рефал несложно ввести, только это от лукавого, думаю.»
Я бы поспорил, что несложно.
 
С уважением,
Александр Коновалов
 
From: Александр Гусев gusev_aleksandr_AT_mail.ru  
Sent: Monday, December 2, 2019 11:54 AM
To: refal@botik.ru
Subject: Re[2]: Нужна ли "Ленинская простота" в Рефале?
 
Я упомянул Хаскелл поскольку его возможности сопоставления хоть как-то "бьются" 
с Рефалом. А типизацию и в Рефал несложно ввести, только это от лукавого, думаю.


…


С уважением,
Александр Гусев
gusev_aleksa...@mail.ru  

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Бойко!

«Слабо типизированным я называю язык, в котором, грубо говоря, типы данных 
имеют небольшую роль.»

Теперь мы поняли друг друга!

Статья на Хабре описывает, как мне показалось, общепринятую терминологию по 
разновидностям типизации, в ней weak/strong typing переведены как слабая и 
сильная типизации, в скобках указаны синонимы «нестрогая» и «строгая». Поэтому 
я сначала недопонял Вашу мысль.

«Например, их мало и нельзя определять новые.»

Да, есть такое. Типы символов, как правило, фиксированы реализацией, и их 
немного. Как правило, типы в Рефале формулируются на уровне соглашений: 
структура объектных выражений описывается при помощи грамматики вроде БНФ или 
РБНФ, эта грамматика записывается в комментариях к программе.

Я когда-то разрабатывал мёртворождённый диалект Модульный Рефал, в нём у меня 
была ограниченная возможность определять новые типы. Метка типа описывалась при 
помощи ключевого слова $DATA, термы данного типа записывались в квадратных 
скобках, после открывающей скобки записывалась метка. Доступ к содержимому 
термов был доступен только из того модуля, где этот тип был описан — в других 
модулях такой терм можно было сопоставить только с t-переменной.

$MODULE SymTable;

$DATA Table;

/**
   == t.SymTable
*/
$ENTRY New { = [Table] }

/**
  
== Found e.Value
== NotFound
*/
$ENTRY Lookup {
  [Table e.Table-B (e.Name (e.Value)) e.Table-E] e.Name = Found e.Value;
  [Table e.Table] e.Name = NotFound;
}

…

$END SymTable;

Я даже подумывал на основе этих «абстрактных типов данных» сделать ограниченное 
ООП с виртуальными функциями.


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

Интересное соображение. Я, когда говорю о типизации Рефала, имею ввиду те типы, 
которые подразумевает программист, когда пишет в комментариях грамматику 
объектных выражений и формат функции. И на этом уровне Рефал динамически 
типизирован.


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


-Original Message-
From: Boyko Bantchev boykobb_AT_gmail.com  
Sent: Monday, December 2, 2019 1:13 AM
To: refal@botik.ru
Subject: Re: Нужна ли "Ленинская простота" в Рефале?

> Распространённая терминологическая ошибка 

Александр,

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

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

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

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

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

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

«Александр, Вы романтик в программировании»
Не возражаю.
 
From: Eisymont Leonid verger-lk_AT_yandex.ru  
Sent: Sunday, December 1, 2019 11:55 PM
To: refal@botik.ru
Subject: Re: Рефал-2, Рефал-5 и стиль программирования
 
Александр, Вы романтик в программировании и все слишком усложняете. В проектах 
с большой ответственностью это не проходит. То, о чем я говорил, как и воинские 
уставы, "написаны кровью". Иначе не получается, во всяком случае у меня.
Л.Эйсымонт
 
 
 

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый вечер всем!

Хочу дополнить предыдущее письмо. Я писал:

«Так, что если программист пишет комментарий к каждой строчке, это одно из 
двух. Или язык недостаточно выразителен, что приходится его пересказывать на 
понятном языке. Или программист не умеет ясно выражать мысли на языке 
программирования.»

Есть ещё третий случай — пишется ПО для ответственного применения. Например, 
компилятор для аэрокосмической отрасли, чем и занимался Леонид Эйсымонт. В 
таких случаях перестраховываться надо.

 

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

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Sunday, December 1, 2019 4:17 PM
To: refal@botik.ru
Subject: Рефал-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 

 &action=getpage&data=refal\as-syntax.html
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.pdf
https://github.com/bmstu-iu9/refal-type-verifier/tree/master/src/main/resources/docs

 

«Ещё требование — часть этой информации выносилась в основной комментарий к 
функции типа структура входа и выхода.»

Это хорошо, это правильно, я сам так делаю и всем рекомендую. Необходимый 
минимум — описание типов всех entry-функций (видимых из других модулей). Но ко 
всем функциям такое писать избыточно.

 

«Более мелкие функции снабжались комментариями для каждого рефал-предложения.»

А вот это плохо. Очень плохо. Если требуется записывать комментарии к каждому 
предложению функции, значит код сам себя не объясняет.

Комментарии должны быть на уровень выше самого кода, должны объяснять то, что 
из кода не очевидно. Например, типы-грамматики. Если комментарий дублирует код 
— он избыточен. Если противоречит — он вреден. А противоречивым сделать 
комментарий легко — внесли изменение в код, отладили, а про комментарий забыли. 
Код должен объяснять себя сам.

 

Плохой комментарий (дублирует код):

++c; /* увеличиваем c на 1 */

Комментарий лучше (объясняет цель):

++c; /* увеличиваем счётчик связей */

А теперь он снова плохой, потому что дублирует код:

++refcounter; /* увеличиваем счётчик связей */

Лучший комментарий — которого нет. Код объясняет сам себя:

++refcounter;

 

В моём коде на Рефале-5λ, где комментарии документируют только форматы функций, 
студенты разбирались самостоятельно и реализовывали всякие оптимизации. Позже в 
коде студентов, тоже написанном с минимумом комментариев, я разбирался и 
доводил его до ума (устранял мелкие ошибки, рефакторил).

Так, что если программист пишет комментарий к каждой строчке, это одно из двух. 
Или язык недостаточно выразителен, что приходится его пересказывать на понятном 
языке. Или программист не умеет ясно выражать мысли на языке программирования.

 

Вообще есть три уровня понимания языков программирования:

1.Новичок пытается подобрать конструкции языка так, чтобы программа 
скомпилировалась и выдала требуемый результат.

2.Программист описывает решение проблемы при помощи формального языка — 
языка программирования.

3.Программист выбирает/создаёт язык, на котором решение проблемы выражается 
лучше всего. Тут речь идёт об опыте работы с разными языка

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

[Александр Коновалов 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) во многих других.

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

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Леонид!
Добрый день всем остальным!

Дабы не плодить офтопиков в теме про вещественную арифметику, начну новую тему.

 

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

Я воспринимаю их нормально. Надо попробовать попрограммировать на Рефале-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 

 &action=getpage&data=refal\as-syntax.html
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.pdf
https://github.com/bmstu-iu9/refal-type-verifier/tree/master/src/main/resources/docs

 

«Ещё требование — часть этой информации выносилась в основной комментарий к 
функции типа структура входа и выхода.»

Это хорошо, это правильно, я сам так делаю и всем рекомендую. Необходимый 
минимум — описание типов всех entry-функций (видимых из других модулей). Но ко 
всем функциям такое писать избыточно.

 

«Более мелкие функции снабжались комментариями для каждого рефал-предложения.»

А вот это плохо. Очень плохо. Если требуется записывать комментарии к каждому 
предложению функции, значит код сам себя не объясняет.

Комментарии должны быть на уровень выше самого кода, должны объяснять то, что 
из кода не очевидно. Например, типы-грамматики. Если комментарий дублирует код 
— он избыточен. Если противоречит — он вреден. А противоречивым сделать 
комментарий легко — внесли изменение в код, отладили, а про комментарий забыли. 
Код должен объяснять себя сам.

 

Плохой комментарий (дублирует код):

++c; /* увеличиваем c на 1 */

Комментарий лучше (объясняет цель):

++c; /* увеличиваем счётчик связей */

А теперь он снова плохой, потому что дублирует код:

++refcounter; /* увеличиваем счётчик связей */

Лучший комментарий — которого нет. Код объясняет сам себя:

++refcounter;

 

В моём коде на Рефале-5λ, где комментарии документируют только форматы функций, 
студенты разбирались самостоятельно и реализовывали всякие оптимизации. Позже в 
коде студентов, тоже написанном с минимумом комментариев, я разбирался и 
доводил его до ума (устранял мелкие ошибки, рефакторил).

Так, что если программист пишет комментарий к каждой строчке, это одно из двух. 
Или язык недостаточно выразителен, что приходится его пересказывать на понятном 
языке. Или программист не умеет ясно выражать мысли на языке программирования.

 

Вообще есть три уровня понимания языков программирования:

1.Новичок пытается подобрать конструкции языка так, чтобы программа 
скомпилировалась и выдала требуемый результат.

2.Программист описывает решение проблемы при помощи формального языка — 
языка программирования.

3.Программист выбирает/создаёт язык, на котором решение проблемы выражается 
лучше всего. Тут речь идёт об опыте работы с разными языками или создании 
DSL’ей.

 

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

 

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

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

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

[Александр Коновалов 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" 
mailt

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

[Александр Коновалов 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: Нужна ли "Ленинская простота" в Рефале?

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Александр!

«Постепенно, по мере усложнения задач, возникли желания по оптимизации и 
оказалось, что проще вводить новые конструкции в язык, чем 
интеллектуализировать исполнение программы изнутри.»

Не понял мысль. Речь о каких новых конструкциях? Новые конструкции по сравнению 
с базисным Рефалом (спецификаторы Рефала-2, условия и блоки Рефала-5, 
конструкции с поэтичными названиями Рефала Плюс, действия Рефала-6 и т.д.) ИМХО 
призваны повысить ясность программ, нежели оптимизировать выполнение. Можно 
программировать и без них, только программы будут более многословными, придётся 
писать много однообразного (boilerplate) кода, за которым идея будет менее 
заметна.

 

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

Для начала, Хаскель-98 сравнительно простой язык. Это уже потом в расширениях 
языка наворотили всякие GADT’ы и прочее ботанство. А во-вторых, Хаскель не 
получится — о чём написал Бойко в отдельном письме.

 

«Что могут сказать разработчики версий компилятора по поводу внутренней 
простоты реализации?»

Внутренняя простота реализации — это классическая плоская списковая реализация 
+ байткод Романенко. Другие реализации будут сложнее.

 

«У меня интерпретатор не выходит пока что таким красивым, как хотелось бы. 
Сложнее, чем внешняя концепция языка. Интересно, это мои недоработки или 
действительно задача сложнее, чем кажется на первый взгляд?»

Сопоставление с образцом (открытые переменные) сложнее, чем кажется на первый 
взгляд. Если брать ограниченный (strict) Рефал, то там сопоставление с образцом 
простое. Но и выразительные возможности у таких образцов беднее.

 

«У меня интерпретатор не выходит пока что таким красивым, как хотелось бы.»

Рефал — это не язык, на котором программируют. Это язык, для которого пишут 
реализации 😀. Потому что это интересно. Рефал — это вызов «напиши для меня 
компилятор».

 

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

 

 

From: Александр Гусев gusev_aleksandr_AT_mail.ru [mailto:refal@botik.ru] 
Sent: Friday, November 29, 2019 4:57 PM
To: refal@botik.ru
Subject: Нужна ли "Ленинская простота" в Рефале?

 



Добрый день, коллеги!

Есть два вопроса по поводу простоты.

1. Я думаю, что сила Рефала - в изначальной краткости и логичности элементов 
языка. Оптимизация была спрятана в компилятор. Это позволяет знакомиться с 
языком и с первых же дней программировать без ограничений по сложности 
используемых конструкций. Постепенно, по мере усложнения задач, возникли 
желания по оптимизации и оказалось, что проще вводить новые конструкции в язык, 
чем интеллектуализировать исполнение программы изнутри. Это понятно, но не 
всегда это полезно. Если ещё немного усложнить язык - получится Хаскелл, зачем 
тогда Рефал?

2. Что могут сказать разработчики версий компилятора по поводу внутренней 
простоты реализации? У меня интерпретатор не выходит пока что таким красивым, 
как хотелось бы. Сложнее, чем внешняя концепция языка. Интересно, это мои 
недоработки или действительно задача сложнее, чем кажется на первый взгляд?


С уважением,
Александр Гусев
gusev_aleksa...@mail.ru   

Пятница, 29 ноября 2019, 15:51 +03:00 от Александр Коновалов 
a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> >:

 

вопрос читаемости — я считаю, что это вопрос привычки. Мне, например, трудно 
читать Рефал-2. Хотя я однажды читал исходник компилятора Василия Стеллецкого, 
уже к середине текст читался нормально. Так что вопрос привычки. Если прочтёте 
1000 строк кода Рефала-5, то тоже сможете некоторое время нормально его 
воспринимать.

А кто-то из коллег — это Василий Стеллецкий. Он тоже писал в рассылку, что 
текст на Рефале-5 он не читает, а расшифровывает.

 

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

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

 

 

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Добрый день, Леонид!
«Со символами ссылками не так. Там тупо в символе рефала ссылка на кусок памяти 
в 64 разряда, где хранится само число. Если сравнивать, то сравниваются 
содержимое двух кусков памяти, как это аппаратура может сделать.»
Про символы-ссылки я имел ввиду следующее. Пусть имеются два символа-ссылки в 
переменных SA и SB. И мы вызываем функцию k/Eq/ SA SB.:
Eq SX SX = /Eq/
   SX SY = /Neq/
Тогда для ссылок наиболее логичным будет решение сравнить два указателя на 
равенство: если они ссылаются на один объект в памяти, то символы равны. А для 
сравнения вещественных чисел как чисел разумно ввести функцию вроде k/Compare/ 
SX SY., возвращающую '<', '=' или '>'.
На сколько я знаю Рефал-2, ссылки на динамические ящики сравниваются по 
ссылкам, а не по содержимому.
 
«Про параллельность интересно, только нам запись типа Рефал-2 нужна, новые 
расширения явно неудачные, надуманные, в больших программах это „не прокатит“, 
даже по примерам в письмах вижу, что программы не читаются. Кто-то из коллег, 
по-моему, также высказал такое мнение.»
Предполагаемая параллельная реализация всё равно будет поддерживать только 
базисный Рефал: без условий, блоков и прочих наворотов. Параллелиться будут 
независимые по данным вызовы функций, но при этом вызовы примитивных «грязных» 
функций (ввод-вывод, копилка и т.д.) будут выполняться в правильном порядке. 
Подход к распараллеливанию может быть вполне применим и к Рефалу-2.
А вопрос читаемости — я считаю, что это вопрос привычки. Мне, например, трудно 
читать Рефал-2. Хотя я однажды читал исходник компилятора Василия Стеллецкого, 
уже к середине текст читался нормально. Так что вопрос привычки. Если прочтёте 
1000 строк кода Рефала-5, то тоже сможете некоторое время нормально его 
воспринимать.
А кто-то из коллег — это Василий Стеллецкий. Он тоже писал в рассылку, что 
текст на Рефале-5 он не читает, а расшифровывает.
 
С уважением,
Александр Коновалов 
 
From: Eisymont Leonid verger-lk_AT_yandex.ru  
Sent: Friday, November 29, 2019 1:20 PM
To: refal@botik.ru
Subject: Re: Нужны ли вещественные числа в Рефале?
 
Со символами ссылками не так. Там тупо в символе рефала ссылка на кусок памяти 
в 64 разряда, где хранится само число. Если сравнивать, то сравниваются 
содержимое двух кусков памяти, как это аппаратура может сделать.
Про параллельность интересно, только нам запись типа Рефал-2 нужна, новые 
расширения явно неудачные, надуманные, в больших программах это "не прокатит", 
даже по примерам в письмах вижу, что программы не читаются. Кто-то из коллег, 
по-моему, также высказал такое мнение.
Л.Эйсымонт
 
28.11.2019, 20:46, "Александр Коновалов a.v.konovalov87_AT_mail.ru" 
mailto:refal@botik.ru> >:
Добрый вечер, Леонид!
«Мы же сами только обеспечивали работу с такими числами через символы-ссылки.»
Если представлять вещественные числа символами-ссылками, то проблема равенства 
уходит на второй план: два символа равны, если ссылаются на общий контейнер.
«Так что хоть какое-то распараллеливание есть, это будет важно применить в 
комбинаторных алгоритмах компиляции. Сейчас со всем этим будем работать на 
сервере с 28 ядрами.»
А у меня сейчас студент работает над параллельной реализацией Рефала (курсовая 
работа). Если что-то получится, напишу подробнее. Пишется не для кластеров, а 
для простых многоядерных компьютеров. Но зато вся параллельность будет 
полностью прозрачна для программиста.
 
С уважением,
Александр Коновалов
 
From: Eisymont Leonid verger-lk_AT_yandex.ru [mailto:refal@botik.ru 
 ]
Sent: Thursday, November 28, 2019 5:41 PM
To: refal@botik.ru  
Subject: Re: Нужны ли вещественные числа в Рефале?
 
Конечно, не IEEE, у нас была та арифметика, что есть в ЕС ЭВМ (IBM 360). Мы же 
сами только обеспечивали работу с такими числами через символы-ссылки.
Для очень точных вычислений использовали дроби. Про работу с длинной мантиссой 
я не помню, кажется была. Надо посмотреть, реализация ведь есть и мы ее подняли 
сейчас в ЗАО"НТЦ"Модуль" для моделирования перспективных комбинаторных 
алгоритмов компиляции и непосредственно перспективных архитектур процессоров и 
систем. Нам надо просто быстро делать это в исследованиях (т.е. быстро ставить 
эксперименты), вот и выбрали Рефал, опыт его такого использования есть еще с 
времен ракетно-космической тематики в ИПМ. Рефал, вдобавок, у нас с введенными 
операциями типа MPI. Это в 2004 году в НИЦЭВТ-е добавили к М-рефалу. Так что 
хоть  какое-то распараллеливание есть, это будет важно применить в 
комбинаторных алгоритмах компиляции. Сейчас со всем этим будем работать на 
сервере с 28 ядрами.
Л.Эйсымонт
 
28.11.2019, 14:16, "Александр Коновалов a.v.konovalov87_AT_mail.ru" 
mailto:refal@botik.ru> >:
Добрый день, Леонид!
Я только что написал в рассылку про тонкости семантики вещественных чисел, 
включая сравнение на равенство. Как в М-Рефале решена проблема равенства 
вещественных чисел? Или во времена Бурана он писался для компьютеров со своей 
(не IEEE) реализацией вещественн

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

Доброй ночи, Андрей!

«Александр, как же так, вы же писали что в синтаксисе вещественных констант 
нет, как же это вы скомпилировали, и выполнили?»

На сайте refal.ru можно найти два компилятора Рефала-6. Один скачивается по 
ссылке download   со страницы 
http://refal.ru/dialects.html, второй входит в дистрибутив Refal-Java (я 
скачивал версию 0.1.2). В первом вещественные числа не поддерживаются, во 
втором — поддерживаются.

Я сначала скачал первый компилятор — парсер неправильно разбирает «1.0». Из 
любопытства скачал Рефал-Java — в нём тоже оказался компилятор Рефала-6 
(ri.exe, c.rex, i.rex и т.д.). Запустил его — там всё работает.

Кстати, при делении на вещественный ноль  ошибки не вылетает, а 
вычисляется «бесконечность», что противоречит документации. Это так специально 
задумано, хоть и не документировано? 

 

«Как видите, при сравнении целого и вещественного целое всегда меньше. А как 
надо?»

Я бы, наверное, сравнивал числовое значение, но речь не об этом.

Речь о том, что можно получить +0.0 и −0.0, которые функция COMPARE считает 
равными, а сопоставление с образцом — нет.

 

Завтра надо будет поэкспериментировать с Рефал-Java и посмотреть — не будет ли 
тонкостей при работе с NaN.

 

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

 

From: Arkady Klimov arkady.klimov_AT_gmail.com [mailto:refal@botik.ru] 
Sent: Thursday, November 28, 2019 11:41 PM
To: refal@botik.ru
Subject: Re: Нужны ли вещественные числа в Рефале?

 

Александр, как же так, вы же писали что в синтаксисе вещественных констант нет, 
как же это вы скомпилировали, и выполнили?

У меня это тоже не компилируется, точнее неправильно компилируется.

Но в самом рефале вещественные числа есть. Вопрос в том, как получить первое 
число. Если вещественное сложить с целым, будет уже вещественное. Но целое с 
целым всегда целое. Там есть разные функции типа SIN, LOG - можно через них 
получить вещ из цел. МОжно даже считать из файла через READ или DECODE. Типа 
все есть, кроме возможности писать в самом языке константы. Это недоделка.

Кстати, я сам тестирую функции в интерактивном режиме. Он вызывается через 
батник rfi.bat.

Или командой ri i+*ask .

Потом вводим (после приглашения #>):

#>mul 3 0.5

1.50e+000

#> mul 0 -1.0

-0.00e+000

#> compare 0.0 

'='

#>compare 1 0.0

'<'

 Без угловых скобок строчными (если надо все заглавные) можно (нужно) писать 
только самый внешний вызов. Остальные - как в файле *.ref 

Как видите, при сравнении целого и вещественного целое всегда меньше. А как 
надо?

Аркадий

 

 

чт, 28 нояб. 2019 г. в 14:11, Александр Коновалов a.v.konovalov87_AT_mail.ru 
  mailto:refal@botik.ru> >:

Аркадий!

В дистрибутиве Refal-Java лежит обычный Рефал-6 более свежей версии с 
вещественными числами. И у меня для Вас фокус.

Рассмотрим такую волшебную функцию:

Magic {
  s.X s.Y
,  : '='
, {
s.X : s.Y = ;
s.X :# s.Y = ;
  };

  s.X s.Y = ;
};

Функция сравнивает два символа при помощи COMPARE. Если они с точки зрения 
COMPARE не равны, печатается Ok2.

А вот если COMPARE вернула '=', то символы сравниваются при помощи рефальского 
отождествления. Логично было бы ожидать, что функция COMPARE возвращает '=' 
только для синтаксически отождествимых между собой символов (хотя документация 
об этом благоразумно ничего не говорит).

Но можно построить символы, которые не равны с точки зрения отождествления, но 
при этом считаются равными COMPARE:

$ENTRY GO {
  =  >
};

Умножение нуля на положительное число даёт вещественное значение +0, умножение 
на отрицательное — −0 (минус ноль). Битовые представления у этих чисел 
различны, но вещественное сравнение их считает равными (согласно стандарту IEEE 
на вещественные числа).

Функция COMPARE считает +0 и −0 равными значениями, но рефальское 
отождествление их различает. Выводятся на экран они, кстати, одинаково.

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

 

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

 

From: Александр Коновалов a.v.konovalov87_AT_mail.ru mailto:refal@botik.ru> @botik.ru> 
Sent: Thursday, November 28, 2019 1:25 PM
To: refal@botik.ru  
Subject: RE: Нужны ли вещественные числа в Рефале?

 

Добрый день, Аркадий!

Хотел посмотреть, как работают вещественные числа в Рефале-6. Скачал 
дистрибутив с сайта refal.ru, распаковал, поправил путь в ri.bat. Написал такую 
программу (zero.ref):

$ENTRY GO {
  = >;
};

Компилирую и запускаю — падает:

D:\…\Refal6>rfc zero.ref

D:\…\Refal6>ri i+c+*go zero.ref -W0 -B25000
Refal-6 Compiler. Copyright (C) 1993 by Ark. Klimov
zero.ref:
Parsing time = 0.00 seconds
No syntax errors
Compilation time = 0.00 seconds

D:\…\Refal6>ri i+zero.rex+*go
EVAL: *** Unexpected FAIL
EVAL: 

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

[Александр Коновалов a . v . konovalov87_AT_mail . ru]

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

«Мы же сами только обеспечивали работу с такими числами через символы-ссылки.»

Если представлять вещественные числа символами-ссылками, то проблема равенства 
уходит на второй план: два символа равны, если ссылаются на общий контейнер.

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

А у меня сейчас студент работает над параллельной реализацией Рефала (курсовая 
работа). Если что-то получится, напишу подробнее. Пишется не для кластеров, а 
для простых многоядерных компьютеров. Но зато вся параллельность будет 
полностью прозрачна для программиста.

 

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

 

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

 

Конечно, не IEEE, у нас была та арифметика, что есть в ЕС ЭВМ (IBM 360). Мы же 
сами только обеспечивали работу с такими числами через символы-ссылки.

Для очень точных вычислений использовали дроби. Про работу с длинной мантиссой 
я не помню, кажется была. Надо посмотреть, реализация ведь есть и мы ее подняли 
сейчас в ЗАО"НТЦ"Модуль" для моделирования перспективных комбинаторных 
алгоритмов компиляции и непосредственно перспективных архитектур процессоров и 
систем. Нам надо просто быстро делать это в исследованиях (т.е. быстро ставить 
эксперименты), вот и выбрали Рефал, опыт его такого использования есть еще с 
времен ракетно-космической тематики в ИПМ. Рефал, вдобавок, у нас с введенными 
операциями типа MPI. Это в 2004 году в НИЦЭВТ-е добавили к М-рефалу. Так что 
хоть  какое-то распараллеливание есть, это будет важно применить в 
комбинаторных алгоритмах компиляции. Сейчас со всем этим будем работать на 
сервере с 28 ядрами.

Л.Эйсымонт

 

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

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

Я только что написал в рассылку про тонкости семантики вещественных чисел, 
включая сравнение на равенство. Как в М-Рефале решена проблема равенства 
вещественных чисел? Или во времена Бурана он писался для компьютеров со своей 
(не IEEE) реализацией вещественной арифметики?

 

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

 

From: Eisymont Leonid verger-lk_AT_yandex.ru mailto:refal@botik.ru> >
Sent: Thursday, November 28, 2019 1:53 PM
To: refal@botik.ru  
Subject: Re: Нужны ли вещественные числа в Рефале?

 

Вещественные числа есть в М-Рефале (моя с Николаем Мансуровым разработка). Без 
них мы бы компилятор для Бурана не смогли бы сделать - нужны были вычисления 
для выбора масштабов. Это есть там с середины 80-х годов прошлого столетия.

Л.Эйсымонт

 

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

Добрый вечер всем!

Собственно, вопрос: нужны ли вещественные числа в Рефале? Из известных мне 
реализаций они есть только в Рефале-6. Также они упоминались в старом учебнике 
Рефала-5 Турчина, при этом описывались встроенные функции Trunc, Real и 
Realfun. В новом актуальном их нет.

Вопрос их отсутствия в большинстве реализаций — идеологический или технический?

У меня (Рефал-5λ) их нет, поскольку (а) мне они не требовались, (б) их нет в 
Рефале-5, с которым должен быть совместим Рефал-5λ. Добавлять или не добавлять 
— я думаю. Поэтому и спросил.

 

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