Добрый день!
 
Возникло сразу несколько разноплановых ответов/вопросов.
 
*  По поводу интерфейсов: всё-таки нужно разделиться на два лагеря по-моему. 
Есть приверженцы как компиляции, так и интерпретации. Кроме того, связывание 
бывает динамическим (как .dll в Windows или пуще того, как объектная модель COM 
и подобные). Эти отличия сильно влияют на производительность. Как выяснилось на 
практике, регулярки не настолько быстры, как хотелось бы. Поэтому если 
рассматривать не чистый компилятор и не статическое связывание, то тормоза 
могут получиться критические.
Поскольку меня интересует интерпретация, желательно иметь сильные (быстрые, 
эффективные) базовые объекты языка, а из них строить что-то большее не 
полагаясь на возможности других языков.
*  Никто не мешает сделать встроенную функцию, эквивалентную традиционному 
regex-разбору строки, которая вызывает аналогичную функцию языка, на котором 
работает сам движок компилятора (у меня — Go). Однако, в реальности «просто 
функцией» тут не отделаться, поскольку используется совсем другой формат 
хранения строки и частая перекачка представления строки туда-сюда будет заметно 
тормозить.
Возможна оптимизация преобразования представлений внутри «движка», но это не 
панацея и сильно усложняет устройство компилятора.
*  Как было подмечено, Рефал — язык очень гибкий по синтаксическому своему 
выражению. Для интерпретатора реальным является обработать «красиво 
оформленное» описание типа регулярки или даже Lex/Yacc, отконвертировав его в 
Рефал, и, затем выполнить его стандартным образом как вызов функции. Мне эта 
идея ближе, чем использование «чужеродных» средств.
*  Несмотря на занятость ниш, где место Рефалу, другими языками, меня не 
покидает оптимизм по поводу того, «не всё ещё карты открыты» — пока сохраняется 
ряд стратегических преимуществ, которые способны поднять рейтинг языка до 
достойного уровня.
  
>Воскресенье, 28 марта 2021, 23:43 +03:00 от nikolai.kondratiev_AT_gmail.com 
><[email protected]>:
> 
>Николай Кондратьев высказал следующий тезис (возможно прочитанный в каком-то 
>труде, а может сам красиво сформулировал – помнит ли он сейчас?):
>Надо тщательно различать логику и дизайн языка программирования. Плохо, когда 
>они путаются и решения принимаются то в пользу одного, то другого (типичная 
>ситуация в комитетах по стандартизации языков). 
>Андрей, спасибо, что вспомнил. Я этого не помню, хотя это утверждение мне 
>близко.
>Когда я писал компилятор в язык сборки, то обнаружил, что непрозрачность 
>блоков для неуспехов неудобна для реализации. А кроме того, мне пришла в 
>голову мысль, что после результата замены можно поставить двоеточие и 
>продолжить цепочку. В общем что-то похожее на то, что реализовал Аркадий в 
>РЕФАЛЕ 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 : refal @ botik . ru
>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  editor 'е).  
>*  Цель разработки логики языка   – чтобы она была композиционна и полна (по 
>отношению   к как можно большему числу разных деятельностей   над языком).
>*  Цель дизайна   – чтобы было удобно человеку: в данных исторических 
>условиях, с данными инструментами создания и чтения программ, которые могут 
>меняться, да и, вообще говоря, разным человекам   нужен разный синтаксис 
>(плохо, что обычно создаются разные языки для разных профессий типа  COBOL для 
>«бухгалтеров», а  PL / I для «профессиональных програмистов», а не один язык с 
>разными «лицами»).  
>*  Подход к разработке языка должен такой: сначала разрабатываем логику, а 
>потом, не нарушая ее, отрабатываем дизайн, а лучше   – много дизайнов. Здесь 
>слова «сначало» и   «потом» относятся не ко времени, а к приоритетам. 
>Разработка чего угодно всегда циклична: делаем версию, недовольны, 
>возвращаемся к началу. Если язык оказался для чего-то плох, подумайте, к чему 
>относится вопрос: только ли к дизайну? или к логике, а потом и к переработке 
>дизайна под улучшенную логику?
>С этой колокольни я и смотрю на все давние и постоянно возрождающиеся споры о 
>том, кому какой Рефал нравится. То есть равнодушно с точки зрения дизайна (это 
>вкусовщина). И с интересом с точки зрения логики. Идеальный метаязык с его 
>идеальной реализацией должен иметь совершенную логику и возможность задавать 
>различные дизайны: разные синтаксисы, выделять подмножества для различных 
>целей и аудиторий, каждое подмножество может иметь свой вид, и т.п. Всё это 
>многообразие должно описываться на самом Рефале. (Самоприменение, 
>метасистемный   переход.) Напомню, что идею такой системы еще с 90-х 
>пропагандирует Сергей Абрамов и инициировал такой рефал-проект, который, к 
>сожалению, пребывает в замороженном состоянии (его участники, напомните  web 
>-ссылку)). Его можно было бы возродить, но уже обязательно на современном 
>уровне, пользуясь современными инструментами,  IDE , современной мощностью 
>компьютеров (не оптимизируя решения «ради эффективности») и т.п.
> 
>Рефал вроде бы   «умер». А что могло бы не дать ему умереть в свое время, а 
>может и теперь возродиться? Когда-то мы фантазировали   о том, что хорошо бы 
>найти и занять какие-нибудь успешные прикладные ниши для Рефала, которые 
>существовали в годы его расцвета, когда конкурентов ему практически не было, 
>но потом были заняты другими языками. (Например, до сих пор думаю, что 
>упущенная возможность   – Рефал как скриптовый язык; это непросто, но идеи 
>были, причем мы об этом думали еще тогда, когда не начался мировой  buzz по их 
>поводу). Но каждая ниша   – это частный вопрос, частный успех или неуспех. А 
>быть метаязыком – конструктором языков   – это принципиальное свойство, до сих 
>пор не достигнутое ни в одном живом языке в желаемом виде.
> 
>Кстати, о сравнении   Рефала Плюс Сергея Романенко с Рутеном   Гуриным и 
>Рефала-6 в версии Аркадия. Рефал Плюс   – это была первая попытка создать 
>ортогонализированный   Рефал. Но Сергей (как он сам тогда говорил) был скован 
>дополнительным требованием, сильным желанием, чтобы быть как можно ближе к 
>Рефалу-5 по синтаксису. Отсюда возникали решения, чтобы, когда семантика 
>одинакова, то синтаксис был бы тот же или понятно, как соотносился. Помню наши 
>эмоциональные обсуждения, когда Рефал Плюс был «выдан на гора», и мы 
>приставали к Сергею: а вот тут бы еще   «подвигать», тут бы еще   
>«подкуртить». А Сергей отвечал: отстаньте, и так уже синтаксис слишком тонко 
>подогнан, тронешь   – замучаешься   грамматику для  Yacc ' a перерабатывать. 
>То есть он максимально продвинулся по логике, но под давлением совместимости с 
>Рефалом-5 и использованных инструментов реализации не стал дальше 
>«оптимизировать» язык.
> 
>А Аркадий превращал Рефал-6 b Николая Кондратьева в свой Рефал-6 позже, уже 
>опираясь на положительный   и отрицательный опыт Рефала Плюс. Неудивительно, 
>что со второй попытки он добился (на мой взгляд) бóльшей регулярности и 
>логики, и дизайна, то есть синтаксиса, отражающего логику языка. Базовые 
>«кирпичи» Рефала-6 чуть помельче, чем у Рефала Плюс. Пользователю   это почти  
> не видно, но сделало проще также и формальную грамматику языка.
> 
>Такие дела...
> 
>Андрей Климов
> 
>>С уважением,
>>Александр Коновалов 
>> 
>> 
>>От:  Andrei Klimov andrei_AT_klimov.net
>>Отправлено:  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 и его логику?
>> 
>>Андрей
>>  
 
 
С уважением,
Александр Гусев
[email protected]
 
  • Re:... Andrei Klimov andrei_AT_klimov . net
    • ... Александр Коновалов a . v . konovalov87_AT_mail . ru
      • ... Andrei Klimov andrei_AT_klimov . net
  • Re:... Arkady Klimov arkady . klimov_AT_gmail . com
    • ... Александр Гусев gusev_aleksandr_AT_mail . ru
      • ... Александр Коновалов a . v . konovalov87_AT_mail . ru
        • ... Andrei Klimov andrei_AT_klimov . net
          • ... Александр Коновалов a . v . konovalov87_AT_mail . ru
          • ... Andrei Klimov andrei_AT_klimov . net
          • ... nikolai . kondratiev_AT_gmail . com
          • ... Александр Гусев gusev_aleksandr_AT_mail . ru
          • ... Александр Коновалов a . v . konovalov87_AT_mail . ru
          • ... nikolai . kondratiev_AT_gmail . com
          • ... nikolai . kondratiev_AT_gmail . com
          • ... Arkady Klimov arkady . klimov_AT_gmail . com
          • ... Александр Коновалов a . v . konovalov87_AT_mail . ru
          • ... Александр Гусев gusev_aleksandr_AT_mail . ru
    • ... nikolai . kondratiev_AT_gmail . com
      • ... Александр Коновалов a . v . konovalov87_AT_mail . ru
        • ... nikolai . kondratiev_AT_gmail . com
    • ... Александр Коновалов a . v . konovalov87_AT_mail . ru

Ответить