OberonCore
https://forum.oberoncore.ru/

Предложение о произвольном порядке секций в модуле КП
https://forum.oberoncore.ru/viewtopic.php?f=29&t=6315
Страница 1 из 1

Автор:  Илья Ермаков [ Среда, 21 Ноябрь, 2018 14:00 ]
Заголовок сообщения:  Предложение о произвольном порядке секций в модуле КП

Предлагаю к спокойному обсуждению на перспективу вот что.

КП, наследуя в этом Оберону, чётко определяет: сначала секция объявлений, потом процедуры, при этом принцип предобъявлений сигнатур. Всё сделано для однопроходной компиляции с прямой кодогенерацией - в классическом Обероне.
Ценность этого для мини-языка и тем более обучающего курса - огромна. Однопроходный компилятор, действительно, влезает на несколько страниц книги "Проект Оберон".

Реально в случае диалектов Оберона, из которых объективно лидирующий (особенно в общих применениях) - КП (или, как Дмитрий Дагаев предложил на прошедшей конференции, возвращать имена - Oberon-L, я его в этом бы поддержал, как минимум для индустриального названия: задалбывает всё время объяснять эти связи, кто от кого и почему называется, а "Паскаль" для индустрии всё равно красная тряпка) - так вот, в случае диалектов типа КП используются компиляторы с фронт-эндом и бэк-эндом. Задачи иметь однопроходных компилятор для КП, в общем, не стоит и не будет стоять.

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

Для прикладного кода, где есть смысловые группы (типы с соотв. константами) всё наоборот.
В моих задачах, где используется механизм токенов, ещё больше: рядом с типом есть и объявления переменных-токенов.

Вложение:
Снимок экрана от 2018-11-21 13.54.01.jpeg
Снимок экрана от 2018-11-21 13.54.01.jpeg [ 44.35 КБ | Просмотров: 1592 ]


Но процедурные объявления пока жёстко отделены в секцию процедур.

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

Т.е. просто разрешением чередования объявлений и процедур мы бы снимали "малой кровью", без изменения основной грамматики языка, то, что в Активном Обероне, Зонноне и др. вообще "решено" по мейнстримному: всовыванием методом между RECORD/OBJECT и END.

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

Мы много обсуждали на прошедшей конференции песпективы построения над КП/ББ предментно-ориентированных инструментов, с высокоуровневыми описаниями.

Соответственно, если часть модуля порождается из высокоуровневых описаний (в документах ББ, возможно, прямо внедрённых - или лежащих в смежных документах), то этот автогенерируемый код в большинстве случаев должен содержать и объявления, и процедуры.
И в текущем синтаксисе придётся метить две зоны подстановки такого кода, как минимум.
Вместо того, чтобы просто иметь секцию в модуле, которая целиком описана как-то инструментально.

Автор:  Дмитрий Дагаев [ Среда, 21 Ноябрь, 2018 19:34 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Возникает сильная проблема с совместимостью кода. Я в свое время пытался делать портабельное ПО для КП (Oberon-L), XDS и А2. Вот что получалось для Oberon-L:
Код:
   TYPE
      File* = POINTER TO ABSTRACT RECORD
         type-: Type;
         init: BOOLEAN;
      END;
   PROCEDURE (f: File) InitType* (type: Type), NEW;
   BEGIN
      ASSERT(~f.init, 20);
      f.type := type$; f.init := TRUE
   END InitType;

Вот что получалось для A2:
Код:
   File* = OBJECT (* ========== *)
      VAR type-: Type;
         init: BOOLEAN;
   PROCEDURE InitType* (type: Type);
   BEGIN
      ASSERT(~SELF.init, 20);
      SELF.type := type; SELF.init := TRUE
   END InitType;
   END File;

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

Мне нравится и Oberon-L (CONST,TYPE,VAR,PROC) и Active Oberon OBJECT(CONST,VAR,PROC), OBJECT(CONST,VAR,PROC), кроме слова "OBJECT". Но для компилятора нужно выбирать что-то одно, "всякая политика хороша, кроме политики колебаний".

Автор:  Info21 [ Среда, 21 Ноябрь, 2018 23:09 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

ИЕ, а какие будут abuses?

Автор:  Илья Ермаков [ Среда, 21 Ноябрь, 2018 23:51 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Злоупотребления, т.е.?

Предлагаю подумать вместе.

Начнут перемешивать местами?

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

Глобальных переменных обычно мало - и растыкивать их повсюду никто в здравом уме не будет.

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

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

Автор:  Rifat [ Четверг, 22 Ноябрь, 2018 00:30 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

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

Т.е. просто разрешением чередования объявлений и процедур мы бы снимали "малой кровью", без изменения основной грамматики языка, то, что в Активном Обероне, Зонноне и др. вообще "решено" по мейнстримному: всовыванием методом между RECORD/OBJECT и END.

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

Мы много обсуждали на прошедшей конференции песпективы построения над КП/ББ предментно-ориентированных инструментов, с высокоуровневыми описаниями.

Соответственно, если часть модуля порождается из высокоуровневых описаний (в документах ББ, возможно, прямо внедрённых - или лежащих в смежных документах), то этот автогенерируемый код в большинстве случаев должен содержать и объявления, и процедуры.
И в текущем синтаксисе придётся метить две зоны подстановки такого кода, как минимум.
Вместо того, чтобы просто иметь секцию в модуле, которая целиком описана как-то инструментально.

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

Если разрешить описывать процедуры до VAR, то нужно определить как будет вести себя следующий код:
Код:
VAR A: INTEGER;

PROCEDURE P(): INTEGER;
BEGIN
  RETURN A+ B
END P;

VAR B: INTEGER;

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

Автор:  Илья Ермаков [ Четверг, 22 Ноябрь, 2018 01:06 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Я думаю, что при разрешении чередовать секции можно и, скорее всего, и нужно оставить в силе все ограничения на "сущность должна быть объявлена до её использования", вводимые ранее.

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

Касательно "можно в несколько мест" - если мы хотим реального развития в сторону каких-то высокоуровневых описаний, то такое дробление - сильный тормоз.

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

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

Но стоит представить, что каждая из таких вьюшек даёт продукт-код в 2 точки, которые надо как-то явно указать и поддержать... Как это уже превращается в какую-то вермишель.

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

Автор:  Валерий Лаптев [ Четверг, 22 Ноябрь, 2018 05:14 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Илья Ермаков писал(а):
Я думаю, что при разрешении чередовать секции можно и, скорее всего, и нужно оставить в силе все ограничения на "сущность должна быть объявлена до её использования", вводимые ранее.

Это безусловно и обязательно.
Но хотелось бы константы объявлять с типом.
Код:
const integer a = 1, b = 3;
const real d = 1.45e14;

это гораздо более читабельно.

Автор:  Info21 [ Четверг, 22 Ноябрь, 2018 06:30 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Илья Ермаков писал(а):
никто в здравом уме не будет.
Чётто это мне напоминает...

Автор:  Валерий Лаптев [ Четверг, 22 Ноябрь, 2018 06:39 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Илья Ермаков писал(а):
Злоупотребления, т.е.?
Глобальных переменных обычно мало - и растыкивать их повсюду никто в здравом уме не будет.

Будет. :)
Надо исходить из того, что все плохое, что может случиться - ОБЯЗАТЕЛЬНО случится.

Автор:  Trurl [ Четверг, 22 Ноябрь, 2018 08:56 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Илья Ермаков писал(а):
Теперь разберём минусы зафиксированного порядка.

Достаточно раз посмотреть на WinApi.

Автор:  adva [ Четверг, 22 Ноябрь, 2018 09:05 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

А если просто сделать невидимую вьюшку типа (номер по порядку), и позволять по ней сортировать код?

Сортировку наверное, как и подсветку, можно сделать либо хранимой, либо отдельную вьюшку для просмотра?

А так согласен, удобнее видеть в одном месте. Но тут же Иван вроде предлагал и вариант открытия двух окон. Это тоже допустимо, хотя менее удобно

Автор:  Kemet [ Четверг, 22 Ноябрь, 2018 09:11 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Валерий Лаптев писал(а):
Илья Ермаков писал(а):
Злоупотребления, т.е.?
Глобальных переменных обычно мало - и растыкивать их повсюду никто в здравом уме не будет.

Будет. :)
Надо исходить из того, что все плохое, что может случиться - ОБЯЗАТЕЛЬНО случится.

Самое плохое - это гвозди в крышку гроба. Всё остальное, это, всего лишь, всё остальное.

Автор:  Илья Ермаков [ Четверг, 22 Ноябрь, 2018 16:24 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Валерий Лаптев писал(а):
Илья Ермаков писал(а):
Злоупотребления, т.е.?
Глобальных переменных обычно мало - и растыкивать их повсюду никто в здравом уме не будет.

Будет. :)
Надо исходить из того, что все плохое, что может случиться - ОБЯЗАТЕЛЬНО случится.


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

Автор:  Иван Денисов [ Понедельник, 26 Ноябрь, 2018 06:13 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

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

Автор:  Илья Ермаков [ Вторник, 27 Ноябрь, 2018 06:05 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Иван, отнюдь нет.

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

Автор:  Comdiv [ Вторник, 27 Ноябрь, 2018 14:33 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Илья Ермаков писал(а):
Т.е. просто разрешением чередования объявлений и процедур мы бы снимали "малой кровью", без изменения основной грамматики языка, то, что в Активном Обероне, Зонноне и др. вообще "решено" по мейнстримному: всовыванием методом между RECORD/OBJECT и END.

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

Если уж делать, так сразу по большому - по мейнстримному.

Автор:  Илья Ермаков [ Вторник, 27 Ноябрь, 2018 21:13 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Вот, хорошее замечание о возможной проблеме.

Будем фиксировать - а потом покумекаем и взвесим всё.

Сейчас что-то голова уже не варит.

С другой стороны, а как порядок объявлений на грамматику-то влияет? В грамматике нет понятия "эквивалентное имя/ранее объявленное". Связывание имён - это уже семантический уровень.
И при промежуточном разборе в синт. дерево проблем, вроде, вообще нет.

Автор:  Kemet [ Четверг, 06 Декабрь, 2018 09:18 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Валерий Лаптев писал(а):
Илья Ермаков писал(а):
Злоупотребления, т.е.?
Глобальных переменных обычно мало - и растыкивать их повсюду никто в здравом уме не будет.

Будет. :)
Надо исходить из того, что все плохое, что может случиться - ОБЯЗАТЕЛЬНО случится.

Не может такого быть, ведь (с):
Валерий Лаптев писал(а):
так грамотные программеры не пишут. Поэтому это - мелочи.

Автор:  Валерий Лаптев [ Четверг, 06 Декабрь, 2018 09:56 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Ну дык это грамотные. Вы много таких видели в мэйнстриме? :))))

Автор:  Trurl [ Вторник, 22 Январь, 2019 11:39 ]
Заголовок сообщения:  Re: Предложение о произвольном порядке секций в модуле КП

Илья Ермаков писал(а):
КП, наследуя в этом Оберону, чётко определяет: сначала секция объявлений, потом процедуры, при этом принцип предобъявлений сигнатур. Всё сделано для однопроходной компиляции с прямой кодогенерацией - в классическом Обероне.

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

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/