Re: Refal+ abstract syntax


Subject: Re: Refal+ abstract syntax
From: Arkady Klimov (klark@bagirra.rinet.ru)
Date: Thu Dec 23 1999 - 17:44:59 MSK


Андрей,

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

> Есть выбор из следующих вариантов:
>
> A) Парсер использует как вход только один файл, выдает АС-модуль
> с неразрешенными именами.
>
> B) Парсер использует данный файл и все его окружение и выдает
> АС-модуль, в котором все имена разрешены и имеется вся информация
> об их определениях, достаточная для (любого?) компилятора.
>
> C) Реализуются оба варианта, то есть реализуется вариант A), который затем
> дополняется до B) написанием отдельной фазы (StaticElaboration), которая
> соберет всю информацию, достаточную для дальнейшей компиляции.

2.
> > > > > 6) NOT и ITER сохранены как есть. С моей точки зрения их раскрытие
> > > > > слишком далеко двигает нас в сторону виртуального кода и может
> > > > > привести к менее удобному представлению при компиляции в
> > > > > императивные языки.
> > > > Это нормально. Но не отменяет возможности на ранней стадии компиляции
> > > > устранить NOT и ITER путем их раскрытия в АС же. Я не вижу почему эти
> > > > раскрытия специфичны для какого-то одного типа реализации. Полагаю,
> > > > они универсальны.
> > >
> > > Я не против возможных расширений, но мне существенно не нравится
> > > использование
> > > LABEL в раскрытии ITER. Я бы еще согласился на
> > >
> > > t.Label ::= (LABEL s.LabelName e.Sentence)
> > >
> > > чтобы получились помеченные предложения, но не LABEL как
> > > абстрактная метка.
> > Арк:
> > Какая, собственно, разница?
>
> Такая, что, скажем, в Java нельзя просто сказать goto на метку,
> а метка используется только в break и continue; для этого метка
> привязана к соответствующему блоку. В моем варианте помеченное
> предложение будет переходить в помеченный блок - компиляция будет
> проще. А метка сама по себе - ну что с ней делать?
В моей модели на метку тоже можно переходить не отовсюду, а только
из хвоста, идущего за меткой. Но если честно, я снимаю свои возражения
в этом месте, поскольку мне даже нравится идея, что вводятся конструкции
"помеченный блок", "блок TRY" и "блок ITER". По-видимому, предполагается,
что это результатные блоки, то есть нормальный выход из них сопровождается
выдачей объектного выражения в качестве результата, который потребляется
следующим "действием" (блоком, образцом и т.п.). Причем выдачей этого
результата эффект этих блоков исчерпывается: никаких других последствий
нет.
>
> > А правильно ли я понимаю, что в твоем варианте
> > после t.Label не должно быть продолжения предложения? (То есть t.Label
> > тогда
> > должен относиться к так называемым терминирующим операторам, таким как
> > FAIL.)
>
> Если вопрос о о том, можно ли в этом случае снять с LABEL скобки -
> то ответ отрицательный.
Нет, не о том, но я уже понял, ответ- "нет, за t.Label может идти
непустое продолжение, находящееся вне области действия метки".
>
> > И тот же вопрос относительно Try и Iter (в последнем варианте).
>
> Ответ тот же самый. Конечно можно написать, скажем,
> TRY e.TrySentence CATCH e.CatchSentence ENDTRY но зачем??? А потом
> руками считать уровни вложенности? Другой вопрос, что можно написать
> (TRY e.TrySentence CATCH e.CatchSentence) или
> TRY t.TrySentence t.CatchSentence - это вопрос вкуса. Мне больше
> нравится
> выделять сложные операторы скобками и не использовать лишних тегов,
> но если есть принципиальные возражения - я не буду слишком сильно
> настаивать.
Аналогично.
>
> > Замечу, что в своем (предыдущем) варианте я старался минимизировать
> > количество таких операторов. Поэтому и у Error нет явного аргумента, его
> > аргумент - все окончание предложения.
>
> Ммм... Насколько я помню, в Рефале+ аргумент у ERROR - это объектное
> выражение,
> и если мы его только этим ограничим, то для ERROR надо бы ввести
> отдельный
> синтаксис. Если же мы допустим, что аргументом у ERROR может быть
> значение
> любого предложения, то тогда можно оставить все как есть (вопрос: что
> будет,
> если при вычислении аргумента ERROR возникнет новый ERROR? ;-) )
В Рефале Плюс после $ERROR идет произвольная тропа, значение которой
(объектное выражение) и становится фактическим аргументом $Error.
Но синтаксически это тропа, с переменными, вызовами, блоками и т.п.
Действительно, при вычислении этого аргумента может возникнуть новый
$Error (который и будет "значением" всей конструкции).
Не спорю, возможно для ясности вместо ERROR e.Sentence следует
писать (ERROR e.sentence), имея при этом в виду, что этот терм
завершает предложение в котором он написан (поскольку продолжение
недостижимо и потому бессмысленно).
>
> > >
3. Константы - обсудить на семинаре.
Вопросы:
     раскрывать или не раскрывать?
     допускать только термы или любые выражения.?

4.
> > > > 1. Для объектов типов BOX, STRING, VECTOR и, возможно, TABLE - вести
> > > > понятие начального значения:
> > > >
> > > > t.Object ::= (s.Linkage s.ObjectType s.ObjectName
> > e.InitialValue)
> > > >
> > > > e.InitialValue ::= e.ResultExpression
> > > >
> > > > (ограничения - те же, что и для initializer'а.
> > >
> > > Я уже думал над этим. Только непонятно, кто будет проверять, что
> > > начальное значение, скажем для VECTOR имеет корректный формат?
> > Арк:
> > В момент засылки, то есть при загрузке.
>
> Ну, если ни у кого возражений нет - я e.InitialValue введу.
> Вопрос: а не делает ли это t.Initializer слегка obsolete?
Нет, например в Яве есть и Static Initializer и Initial Values,
и хотя одно можно заменить другим, понятно, что это криво.
>
Успехов,
Аркадий.



This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:58 MSD