Да тоже плохо помню, могу сказать только вообще, что непрозрачность это как
бы дополнительная фишка, о которой надо еще позаботиться, а без нее все
проходит через стек переходов (вроде бы), который и так уже есть для
образцов со многими е-переменными.
К слову, хотел бы заметить про неортогональность (непрозрачности блоков) с
позиций программиста. Когда мне надо уточнить предложение условием, я
просто вставляю условие через запятую, но если условий окажется несколько,
с разными последствиями для каждого (или одинаковыми, но условия не удается
просто совместить в одном), приходится вводить варианты в виде блока. Но
поскольку это просто сложное условие, то блок, конечно, должен быть
прозрачным, чтобы в оставшихся случаях пошел откат, как и для одиночного
условия. Иначе придется вводить вспомогательную функцию. Простейший пример:
..., s.N : { 0;1 } , ... . Тут, кстати, еще и продолжение после блока
подразумевается.
пн, 10 мая 2021 г. в 14:52, nikolai.kondratiev_AT_gmail.com <[email protected]
>:
> Уже точно не помню, может быть Аркадий что-нибудь сможет добавить
>
>
>
> *Von:* Александр Коновалов a.v.konovalov87_AT_mail.ru <[email protected]>
> *Gesendet:* Sonntag, 9. Mai 2021 12:50
> *An:* [email protected]
> *Betreff:* RE: О разделении логики и дизайна
>
>
>
> Добрый день, Николай!
>
> *«Когда я писал компилятор в язык сборки, то обнаружил, что непрозрачность
> блоков для неуспехов неудобна для реализации.»*
>
> А чем неудобна?
>
>
>
> С уважением,
> Александр Коновалов
>
>
>
> *From:* nikolai.kondratiev_AT_gmail.com <[email protected]>
> *Sent:* Sunday, March 28, 2021 11:42 PM
> *To:* [email protected]
> *Subject:* AW: О разделении логики и дизайна
>
>
>
> Николай Кондратьев высказал следующий тезис (возможно прочитанный в
> каком-то труде, а может сам красиво сформулировал – помнит ли он сейчас?):
>
> Надо тщательно различать логику и дизайн языка программирования. Плохо,
> когда они путаются и решения принимаются то в пользу одного, то другого
> (типичная ситуация в комитетах по стандартизации языков).
>
> Андрей, спасибо, что вспомнил. Я этого не помню, хотя это утверждение мне
> близко.
>
> Когда я писал компилятор в язык сборки, то обнаружил, что непрозрачность
> блоков для неуспехов неудобна для реализации. А кроме того, мне пришла в
> голову мысль, что после результата замены можно поставить двоеточие и
> продолжить цепочку. В общем что-то похожее на то, что реализовал Аркадий в
> РЕФАЛЕ 6.
>
> Я обсуждал это с Турчиным по телефону, но ему это не понравилось.
>
> После некоторых размышления я пришел к выводу, что Рефал-5 очень хорошо
> сбалансирован. В нем нет избыточных конструкций и осталось то, что делает
> Рефал рефалом.
>
> По поводу регулярных выражений в Рефале.
>
> Мне кажется нужно идти по другому пути, который начат Аркадием в Рефал-Ява
> и по-моему в Рефале+ - создавать интерфейсы с другими языками. Важно, чтобы
> они получались органичными.
>
>
>
> Например, когда мы используем Рефал для синтаксического анализа, то ясно,
> что это не очень эффективно, поскольку тратится два-три вызова функций, на
> одну литеру входного текста.
>
> По-видимому обогнать по скорости конечный автомат, а следовательно Lex/
> Yacc очень трудно.
>
>
>
> Интеграция Рефала с Явой могла бы сильно помочь.
>
> К сожалению я в свое время не нашел хорошую реализацию Lex/Yacc на Яве.
> Они есть, но похоже с ошибками.
>
>
>
> Но есть на C# - это пакет NuGet под названием YaccLexTools.
>
>
>
> У меня есть желание написать компилятор Рефал-C# так, чтобы можно было бы
> интегрировать вместе Рефал, C# и Lex/Yacc.
>
>
>
> Так можно объединить три технологии, каждая из которых возможно лучшая в
> своем классе.
>
>
>
> Вот так вот как-то.
>
>
>
> Николай
>
>
>
> *Von:* Andrei Klimov andrei_AT_klimov.net <[email protected]>
> *Gesendet:* Sonntag, 28. März 2021 21:12
> *An**:* [email protected]
> *Betreff**:* О разделении логики и дизайна
>
>
>
> [Сменил сабж, так как "Остапа понесло".]
>
>
>
> On Sun, Mar 28, 2021 at 8:31 PM Александр Коновалов
> a.v.konovalov87_AT_mail.ru <[email protected]> wrote:
>
> Добрый вечер, Андрей!
>
>
>
> В Рефале-5 запятая для откатов прозрачна. Не прозрачны для откатов только
> фигурные скобки — блоки после двоеточия и сами вызовы функций. Поэтому
> результатное выражение после запятой неуспеха породить не может
> (по определению), а образец после двоеточия — запросто.
>
>
>
> Синтаксис «, выражение : образец» в Рефале-5 есть и он называется
> «where-конструкция».
> Синтаксис «, выражение : {…}» называется with-конструкцией. Они
> упоминались не только в учебнике, но и в главах обнинской школы
> метавычислений — там вместо запятой используются ключевые слова *where* и
> *with* соответственно.
>
>
>
> Спасибо! Буду иметь в виду. Значит, в нашем разговоре Турчин имел в виду
> первое, а я не до конца ухватил и перенес на второе тоже. Значит, логика
> такая:
>
> - «{...}» – это подставленное тело функции,
> - «, выражение :» – это синтаксис для ее вызова,
> - «, выражение : образец ...» – это отдельная конструкция со своей
> семантикой, отличающейся от «, выражение : { образец ...}».
>
> В свое «оправдение» могу только сказать, что не люблю такой
> неортогональный синтаксис и такую тонкую семантику: откаты вроде бы и
> есть, а вроде бы их и нет. Скобки вроде бы лишь «объединитель» (как в
> школьной математике), а вроде бы и нет. Поэтому и подумал, что Турчин был
> просто против откатов.
>
>
>
> Александр, вы пишете, что понимаете устройство Рефала Плюс как языка, на
> котором выразима суперкомпиляция. Формально говоря, да, но как с общей
> целью я с этим не согласен. Только ради этого огород не стоило бы городить,
> создавая новый язык (хотя это интересно, и возможно, локальным стимулом
> для Сергея Романенко было просто естественное желание посмотреть, что
> получится). Для меня важен общий принцип «языкостроительства»:
>
> - Формальный язык (будь то язык математики, логики, или язык
> программирования) должен быть максимально «ортогонализован»: базовые
> семантические единицы явно выражены, а более высокие конструкции собираться
> из них. Это обычно называется композиционностью. Такое требование особенно
> применимо к *мета*языку, предназначенному для описания,
> конструирования других языков. (Если сам не композиционен, что можешь
> предложить другим?)
>
> Но вы (как многие) спросите: А как же быть с удобствами программирования?
> Мы же знаем по опыту разных языков, что, когда «всё торчит наружу», язык
> получается громоздким, так ведь? И да, и нет. Это уже другой вопрос.
> Вспоминаю, как когда-то в 80-е в перерыве рефал-семинара в ИПУ, стояли мы,
> курили (была такая вредная привычка и у меня), и тут Николай Кондратьев
> высказал следующий тезис (возможно прочитанный в каком-то труде, а может
> сам красиво сформулировал – помнит ли он сейчас?):
>
> - Надо тщательно *различать логику и дизайн языка* программирования.
> Плохо, когда они путаются и решения принимаются то в пользу одного, то
> другого (типичная ситуация в комитетах по стандартизации языков).
> - *Логика* – это устройство языка, его колесики, его базовые понятия,
> правила конструирования, композиция.
> - *Дизайн* – это как язык выражен во внешнем синтаксисе (и вообще,
> может и не в одномерном тексте, а, скажем, в projectional
> <https://martinfowler.com/bliki/ProjectionalEditing.html>editor
> <https://martinfowler.com/bliki/ProjectionalEditing.html>'е).
> - Цель разработки логики языка – чтобы она была композиционна и полна
> (по отношению к как можно большему числу разных деятельностей над
> языком).
> - Цель дизайна – чтобы было удобно человеку: в данных исторических
> условиях, с данными инструментами создания и чтения программ, которые могут
> меняться, да и, вообще говоря, разным человекам нужен разный синтаксис
> (плохо, что обычно создаются разные языки для разных профессий типа
> COBOL для «бухгалтеров», а PL/I для «профессиональных програмистов», а
> не один язык с разными «лицами»).
> - Подход к разработке языка должен такой: сначала разрабатываем
> логику, а потом, не нарушая ее, отрабатываем дизайн, а лучше – много
> дизайнов. Здесь слова «сначало» и «потом» относятся не ко времени, а к
> приоритетам. Разработка чего угодно всегда циклична: делаем версию,
> недовольны, возвращаемся к началу. Если язык оказался для чего-то плох,
> подумайте, к чему относится вопрос: только ли к дизайну? или к логике, а
> потом и к переработке дизайна под улучшенную логику?
>
> С этой колокольни я и смотрю на все давние и постоянно возрождающиеся
> споры о том, кому какой Рефал нравится. То есть равнодушно с точки зрения
> дизайна (это вкусовщина). И с интересом с точки зрения логики. Идеальный
> метаязык с его идеальной реализацией должен иметь совершенную логику и
> возможность задавать различные дизайны: разные синтаксисы, выделять
> подмножества для различных целей и аудиторий, каждое подмножество может
> иметь свой вид, и т.п. Всё это многообразие должно описываться на самом
> Рефале. (Самоприменение, метасистемный переход.) Напомню, что идею такой
> системы еще с 90-х пропагандирует Сергей Абрамов и инициировал такой
> рефал-проект, который, к сожалению, пребывает в замороженном состоянии (его
> участники, напомните web-ссылку)). Его можно было бы возродить, но уже
> обязательно на современном уровне, пользуясь современными инструментами,
> IDE, современной мощностью компьютеров (не оптимизируя решения «ради
> эффективности») и т.п.
>
>
>
> Рефал вроде бы «умер». А что могло бы не дать ему умереть в свое время, а
> может и теперь возродиться? Когда-то мы фантазировали о том, что хорошо
> бы найти и занять какие-нибудь успешные прикладные ниши для Рефала, которые
> существовали в годы его расцвета, когда конкурентов ему практически не
> было, но потом были заняты другими языками. (Например, до сих пор думаю,
> что упущенная возможность – Рефал как скриптовый язык; это непросто, но
> идеи были, причем мы об этом думали еще тогда, когда не начался мировой
> buzz по их поводу). Но каждая ниша – это частный вопрос, частный успех
> или неуспех. А быть метаязыком – конструктором языков – это
> принципиальное свойство, до сих пор не достигнутое ни в одном живом языке в
> желаемом виде.
>
>
>
> Кстати, о сравнении Рефала Плюс Сергея Романенко с Рутеном Гуриным и
> Рефала-6 в версии Аркадия. Рефал Плюс – это была первая попытка создать
> ортогонализированный Рефал. Но Сергей (как он сам тогда говорил) был
> скован дополнительным требованием, сильным желанием, чтобы быть как можно
> ближе к Рефалу-5 по синтаксису. Отсюда возникали решения, чтобы, когда
> семантика одинакова, то синтаксис был бы тот же или понятно, как
> соотносился. Помню наши эмоциональные обсуждения, когда Рефал Плюс был
> «выдан на гора», и мы приставали к Сергею: а вот тут бы еще «подвигать»,
> тут бы еще «подкуртить». А Сергей отвечал: отстаньте, и так уже синтаксис
> слишком тонко подогнан, тронешь – замучаешься грамматику для Yacc'a
> перерабатывать.
> То есть он максимально продвинулся по логике, но под давлением
> совместимости с Рефалом-5 и использованных инструментов реализации не стал
> дальше «оптимизировать» язык.
>
>
>
> А Аркадий превращал Рефал-6b Николая Кондратьева в свой Рефал-6 позже,
> уже опираясь на положительный и отрицательный опыт Рефала Плюс.
> Неудивительно, что со второй попытки он добился (на мой взгляд) бóльшей
> регулярности и логики, и дизайна, то есть синтаксиса, отражающего логику
> языка. Базовые «кирпичи» Рефала-6 чуть помельче, чем у Рефала Плюс.
> Пользователю это почти не видно, но сделало проще также и формальную
> грамматику языка.
>
>
>
> Такие дела...
>
>
>
> Андрей Климов
>
>
>
> С уважением,
>
> Александр Коновалов
>
>
>
>
>
> *От: *Andrei Klimov andrei_AT_klimov.net <[email protected]>
> *Отправлено: *28 марта 2021 г. в 16:47
> *Кому: *[email protected]
> *Тема: *Re: Регулярные выражения слева
>
>
>
> On Sat, Mar 27, 2021 at 11:47 PM Александр Коновалов
> a.v.konovalov87_AT_mail.ru <[email protected]> wrote:
>
> [...]
>
>
>
> Вариативность (но с ущербом для эффективности) можно реализовать и в
> Рефале-5. Код, эквивалентный коду Рефала-6, будет выглядеть так:
>
>
>
> F {
> e.Name 〈что-то ещё〉, <F-Name e.Name> : T = … ;
> … = …;
> }
>
> F-Name {
> 'Маша' = T;
> 'Саша' = T;
> e.Other = F;
> }
>
>
>
> А разве такое в Рефале-5 можно? С 90-х годов я рефал-плюсовый программист,
> мог и забыть. А сейчас лень заглядывать в руководство, да и, думаю, будет
> полезно обсудить здесь логики разных Рефалов, из которых вытекают различные
> решения по синтаксису. Помнится, подобные вопросы мы специально обсуждали в
> те годы, и у меня отложилось, что:
>
>
>
> 1. Запятая в Рефал-5 "непрозрачна для откатов", то есть "неотож" после
> запятой не вызывает возврат к следующему варианту в образце левее или
> следующему предложению. Помнится, "длинные" откаты вызывали отторжение у
> Турчина и у других апологетов Рефала-5.
>
>
>
> 2. Синтаксиса вида "выражение : образец" в Рефале-5 нет. Помнится, при
> обсуждении расширений Рефала Плюс по сравнению с Рефалом-5, Турчин говорил,
> что в Рефале-5 двоеточие означает вызов подставленного тела вспомогательной
> функции и только это. Поэтому, даже если в ней только одно предложение, всё
> равно надо ставить фигурные скобки, чтобы выглядело одинаково с
> определением функции. То есть данный код синтаксически правильно надо
> писать так (а семантика будет другая, чем хотелось):
>
>
>
> F {
> e.Name 〈что-то ещё〉, <F-Name e.Name> : { T = … };
> … = …;
> }
>
>
>
> И уж нечего и говорить, что фигурные скобки в Рефале-5 безоткатные.
>
>
>
> Правильно я помню Рефал-5 и его логику?
>
>
>
> Андрей
>
>
>
>
