Subject: Re: Refal+ abstract syntax
From: Arkady Klimov (klark@bagirra.rinet.ru)
Date: Fri Nov 26 1999 - 14:30:24 MSK
Добрый день и спасибо всем учасникам дискуссии!
----- Original Message -----
From: Sergei M. Abramov <abram@botik.ru>
To: <refal@botik.ru>
Sent: Friday, November 26, 1999 11:39 AM
Subject: Re: Refal+ abstract syntax
> День добрый, всем!
>
> > 2. Путь последовательность операторов вытянут по-
> > горизонтали через конкатенацию, а не через cons .
>
> Не говоря "ЗА" или "ПРОТИВ" просто подчеркну разницу: разница такая
же, как
> между
>
> (x+y)*(z+w) и (* + z w + x y)
>
> С этой точки зрения с репликой:
>
> From: Andrey Slepuhin <pooh@msu.ru>
> >2) Предлагаемый синтаксис несколько ближе к виртуальному коду. По
> > крайней мере конструкций типа "Label s" в абстрактном синтаксисе
> > иметь не хотелось бы.
>
> я согласен.
Аркадий:
Я согласен в общем, что в новом АС код как бы более еlaborated, но это
все-таки чисто синтаксическое преобразование, и оно все же так же
далеко от виртуального кода, как высокогорное плато от околоземной
орбиты (по сравнению с уровнем равнины). Но с плато выходить на
орбиту, по-видимому, чуть легче.
Данное преобразование мотивировано прежде всего тем, что теперь мы
избавлены от проблем однозначности, которые приходилось решать в
конкретном синтаксисе.
А другой мотив состоит в том, что для нас ведь AS - это не просто
внутренний образ, синтаксическое дерево построенное парсером. Это еще
и исходная общая точка для нескольких платформ, и в ней, на мой
взгляд, следует исключить все, что может быть отнесено к специфичности
того или иного диалекта Рефала или его реализации, если, конечено, это
может быть исключено, например (как для Iter) путем отображения в
более общие и устойчивые понятия. Ксати, я сейчас склонен к тому,
чтобы то же сделать и с Not, как уже писал ранее, тем более, что для
этого не требуется никаких новых понятий.
>
> > 3. Все скобки, включая образующие термы, имеют впереди теги.
> >
> > 4. Я не стал здесь брать теги в кавычки.
>
> Вообще говоря--"Form" и Form--эквивалентны
>
> (* Сегодня и в Рефала+ я надеюсь они уже эквивалентны? Или еще
нет?
> Ну, по крайней мере, в длиннющей дискуссии про "кавычки" и
> "крики души"--около 80 писем с 30/08/1999 по
10/09/1999,--было
> это устаканено и ЭТО НАДО ДЕЛАТЬ В Рефале+.
> *)
>
> Однако (дело вкуса!!!) мне кажется, что чисто визуально в двух
эквивалентных
> текстах:
>
> >t.ProgramFile ::= (Program t.Source t.Import e.Program)
> >
> >t.Import ::= (Use e.Names)
> >
> >t.Source ::= (Source s.FileName)
>
> и
>
> >t.ProgramFile ::= ("Program" t.Source t.Import e.Program)
> >
> >t.Import ::= ("Use" e.Names)
> >
> >t.Source ::= ("Source" s.FileName)
>
> выигрывает по читабельности второй--лучше (контрастнее) отличаются
нетерминалы и
> терминалы...
> Еще раз--это дело вкуса.
Аркадий:
Действительно, это дело вкуса. На мой взгляд отличие между терминалом
и нетерминалом уже присутствует в форме точки после указателя типа. А
когда имеются два обозначения для выражения какого-то одного свойства
(здесь: быть терминалом или нетерминалом), то возникает сомнение: а
вдруг это неспроста? И начинаешь искать разгадку, которой нет.
>
> (* ------------------------------------------------------------
> Для справки и обмена Рефал+ опытом: а я в своих разработках делаю
еще и так:
>
> >t.ProgramFile ::= (&Program t.Source t.Import e.Program)
> >
> >t.Import ::= (&Use e.Names)
> >
> >t.Source ::= (&Source s.FileName)
>
> Обычно я завожу Рефал+ модуль tаgs.rfi:
>
> $const Program = "Program", Use = "Use", Source="Source";
>
> (замечу, что tаgs.rf при этом ПУСТОЙ, интересно, правда?) Во время
отладки
> важно, чтобы теги печатались читабельно--поэтому тег==слово
(звено+рюкзак для
> хранения тела слова...). При этом (в сегодняшнем рефале+) сравнение
слов не
> сводится к сравнению только звеньев--делается еще сравнение
рюкзаков... А после
> отладки я имею возможность переопределить:
>
> $const Program = 1, Use = 2, Source=3;
>
> что экономит память (тег==звено) и время сравнения тэгов
(сравниваются только
> звенья)...
>
> ------------------------------------------------------------ *)
>
> > 5. Сложные конструкции (перестройки, присваивания) разбиты на
> > составляющие действия.
> >
> > 6. Семантика действия состоит в пополнении среды и выработке
> > нового форматного значения (объектного выражения со
> > статическим форматом). Действия бывают простые (образцы,
> > результаты, форматы) и сложные (блоки).
> >
> > 7. Есть отдельный оператор NoFail, непроницаемый для $Fail, и
> > CUTALL, выражающий семантику равенства рефала +.
> > Непрозрачный блок выражается так: NoFail
> > (Block e.Branches).
> >
> > 8. $iter может быть разложен в более элементарные понятия
> > (Label sl) и (Loop sl) см.ниже. В операторе Loop метка
> > sl должна быть определенной (оператором Label) выше на
> > пути от начала функции к данному оператору Loop.
> > Ищется ближайшая точка Label с тем же символом-меткой.
> >
> > 9. Вместо трех понятий: Tail, Path, Source одно: e.Sentence.
>
> Пункты 5, 6, 7, 8 связаны все (являются следствием) с п. 2. См.
замечание на п.2
> (и реплику <pooh@msu.ru>).
>
> > 10. Констант нет: они уже подставлены.
>
> Вот! Я же говорил, что это требует дискуссии!
>
> Важное завоевание рефала+ (как и рефала-6) -- введение понятий
"разделяемое
> данное". Конструкции "$const X = ... " и "&X" позволяют выражать
эти понятия на
> уровне констант. Пример:
>
> $const X = '1234567890',
> X1 = (&X) (&X),
> X2 = (&X1) (&X1),
> X3 = (&X2) (&X2),
> .....
> X64 = (&X65) (&X65);
>
> F = &X64;
>
> Ну а теперь к экспертам--расскажите:
>
> -1- Как это выглядит сегодня в реализации Рефала+? Около 138
звеньев в
> сегменте данных, не правда ли?;
>
> -2- И как это будет выглядить в абстрактном синтаксисе, если
принять
> концепцию "Констант нет: они уже подставлены"?
>
> -3- Отдельное пожелание: хотелось бы, чтобы кто-нибудь выписал и
прислал на
> список рассылки файл с сегодняшним абстрактным синтаксисом функции F
в условии
> "Констант нет: они уже подставлены" ;-)
>
> (* только мне не присылайте--у меня маленький диск--по моим оценкам
будет:
> 10*2^64 байт == 160 миллионов Террабайт текста ;-)
> *)
Аркадий:
Да, забавно! Очень интересный контрпример. Кстати, в своем предыдущем
письме я тоже отметил вопрос о константах как спорный, а теперь вижу,
что даже очень. Что ж, склоняюсь к тому, чтобы константы не были
подставлены.
Правильно ли я понимаю, что скобки в определениях констант здесь
существенны? Если их убрать, то константы будут подставлены
компилятором по их прочтении, да?
>
> > Но вопрос: что такое
> > имя функции? И как выглядит внутри выражения ссылка на
> > функцию? Другие символы ссылки? Возможный ответ: как (Ref
> > s.Word). Определяющие вхождения задаются просто как s.Word.
В
> > вызове функции используется (Ref s.Word)
>
> Да! И это важное место для существенной дискуссии...
Аркадий:
Для меня она начинается открытым вопросом: если ввести в АС константы,
то использовать ли для обозначения ссылок имена констант, или все
равно нужно дать свое обозначение для "значений" ссылок?
>
> > 11. Определения символов-ссылок должна быть возможность
> > расширять список типов ссылок.
>
> Да! И это важное место для существенной дискуссии...
Аркадий:
А что, есть возражения против расширябельности?
Я под возможностью расширения понимал одно: мы просто
"договариваемся", что в этом месте могут быть расширения. Естественно,
что компилятор, который не понимает какого-то расширения вправе данную
программу отвергнуть. Но хотелось бы, чтобы синтаксический анализатор
тут не накладывал своих ограничений. То есть хотелось бы, чтобы на
входе допускалось бы произвольное
$ ПроизвольноеСлово Имя1, Имя2, ... ;
которое бы транслировалось в АС в форме:
(ПроизвольноеСлово Имя1) (ПроизвольноеСлово Имя2)...
Проверка допустимости ПроизвольногоСлова - на совести компилятора из
АС. В этом случае парсер не должен говорить, что какие-то имена не
определены. Они определены, но ошибочен их "определитель".
Кстати, общее замечание. Решая вопрос об АС мы сейчас также должны
решать, какие проверки должен делать парсер, а какие он должен
оставлять на последующий (семантический) анализ, который может
отличаться в разных реализациях.
12. Объектные символы (в отличие от символов-ссылок)
> > представляются сами собой, а не как (Symbol s)
>
> Это можно сделать если ВСЕ рефальские круглые скобки будут
представлены с тэгом
> ("Par" ....). Это сделано в определении "t.HardTerm", но пропущено
(я не
> ошибаюсь-ли?) в
>
> >t.PatternTerm ::= t.Symbol
> > | (e.PatternExpression)
> ^ Par?
> > | t.Variable
>
Аркадий:
Да, это осталось по недосмотру. Спасибо, что заметил.
> Ок...
>
> > 13. Операторы Error и Trap имеют неявный дополнительный
> > аргумент продолжение справа от оператора.
>
>
> Это опять про п.2.
>
> > 14. Остаток после операторов Fail и Loop игнорируется.
>
>
> Это опять про п.2.
>
> > 15. Конкретная реализация может не поддерживать какие-то
> > элементы (или сочетания элементов) абстрактного синтаксиса.
В
> > этом случае должно выдаваться внятное сообщение.
>
>
> Да.
>
>
>=====================================================================
=
> >
> >t.ProgramFile ::= (Program t.Source t.Import e.Program)
> >
> >t.Import ::= (Use e.Names)
> >
> >t.Source ::= (Source s.FileName)
>
> Алик!
> (1) Хотелось бы каких-то пояснений...
> (2) Модульность требует существенных дискуссий
> (3) Вижу "импорт", не вижу "экспорта"...
Аркадий:
Да, я сверялся со структурой файла .rf, и забыл, что есть еще .rfi.
Начнем дискуссию с вопроса: следует ли информацию из файла rfi
включать в этот же программный терм, или ее следует представлять в
отдельном терме?
Спасибо.
>
> >e.Program ::= t.ProgramItem
> > | e.Program t.ProgramItem
> > | t.Line
>
> (1) кажется тело программы может быть пустым;
> (2) не понял, что значит, что значит, что тело состоит только из
t.Line?
> Может быть имелось в виду, что есть алтернатива у "t.ProgramItem :==
..... |
> t.Line" ?
Аркадий:
Да, конечно, именно это я и хотел написать. Спасибо.
>
> >t.ProgramItem ::= t.FuncDef | t.ObjectDef | t.Initializer
>
> (1) Да, симпатично, понравился t.Initializer ;-) А зачем он?
Аркадий:
В рефале-6 он есть. Пишется
$EXEC FunName argument;
Результат вычисления игнорируется (отправляется в мусор).
Очень полезная вещь. С ним можно забыть про то, что еще надо указывать
какую-то там входную точку. При загрузке исполняется initializer,
который может делать всю работу.
Можно говорить: "исполнить такой-то модуль". С другой стороны, иногда
хочется заполнение переменных (ящиков и т.п.) выполнить как бы "при
загрузке".
Замечу, что существенно, где стоит initializer. В нем доступны для
исполнения только те функции, которые определены выше. А если это
другие модули, то они должны быть загружены ранее. Отсюда - запрет на
циклический import. Возражения будут?
> (2) Следует добавить альтернативу | t.Pragma
>
> Я бы сделал так:
>
> -а- в текущем тексте Алика заменил бы глобально t.Line --> t.Pragma,
а вместо
>
> >t.Line ::= (Line s.LineNumber s.PosNumber)
> > | (Line s.LineNumber)
>
> -б- и написал бы:
>
> t.Pragma ::= (Pragma e.Pragma)
>
> e.Pragma ::= t.Line
> | "Traseall"
> | "Trase" e.Fnames
> ......
> | e.OtherPragma
>
> t.Line ::= (Line s.LineNumber s.PosNumber)
> | (Line s.LineNumber)
>
Аркадий:
Согласен, это правильно. Скобки с (Line...) тогда можно убрать.
Естественно, должен соблюдаться принцип: если некая реализация не
понимает каких-то прагм, то она их молча (!) игнорирует.
> Ну, кажется и все (пока--при первом просмотре) замечания...
>
> Удачи!
>
> Сергей
>
Всего наилучшего!
Аркадий.
PS. По мере продвижения дискуссии я правлю свой rtf файл, поэтому могу
через какое-то время снова вбросить его плоскую копию.
>
>
This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:58 MSD