OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 13 Декабрь, 2018 20:29

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 19 ] 
Автор Сообщение
СообщениеДобавлено: Среда, 21 Ноябрь, 2018 14:00 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9062
Откуда: Россия, Орёл
Предлагаю к спокойному обсуждению на перспективу вот что.

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

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

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

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

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


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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Ноябрь, 2018 19:34 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 289
Откуда: Москва
Возникает сильная проблема с совместимостью кода. Я в свое время пытался делать портабельное ПО для КП (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". Но для компилятора нужно выбирать что-то одно, "всякая политика хороша, кроме политики колебаний".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Ноябрь, 2018 23:09 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7932
Откуда: Троицк, Москва
ИЕ, а какие будут abuses?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 21 Ноябрь, 2018 23:51 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9062
Откуда: Россия, Орёл
Злоупотребления, т.е.?

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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 00:30 

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

Т.е. просто разрешением чередования объявлений и процедур мы бы снимали "малой кровью", без изменения основной грамматики языка, то, что в Активном Обероне, Зонноне и др. вообще "решено" по мейнстримному: всовыванием методом между 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 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9062
Откуда: Россия, Орёл
Я думаю, что при разрешении чередовать секции можно и, скорее всего, и нужно оставить в силе все ограничения на "сущность должна быть объявлена до её использования", вводимые ранее.

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

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 05:14 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2974
Откуда: Астрахань
Илья Ермаков писал(а):
Я думаю, что при разрешении чередовать секции можно и, скорее всего, и нужно оставить в силе все ограничения на "сущность должна быть объявлена до её использования", вводимые ранее.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 06:30 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7932
Откуда: Троицк, Москва
Илья Ермаков писал(а):
никто в здравом уме не будет.
Чётто это мне напоминает...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 06:39 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2974
Откуда: Астрахань
Илья Ермаков писал(а):
Злоупотребления, т.е.?
Глобальных переменных обычно мало - и растыкивать их повсюду никто в здравом уме не будет.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 08:56 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1098
Илья Ермаков писал(а):
Теперь разберём минусы зафиксированного порядка.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 09:05 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 333
Откуда: Россия, Стерлитамак
А если просто сделать невидимую вьюшку типа (номер по порядку), и позволять по ней сортировать код?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 09:11 

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 16:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9062
Откуда: Россия, Орёл
Валерий Лаптев писал(а):
Илья Ермаков писал(а):
Злоупотребления, т.е.?
Глобальных переменных обычно мало - и растыкивать их повсюду никто в здравом уме не будет.

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 26 Ноябрь, 2018 06:13 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2233
Илья, ты по сути хочешь несколько модулей запихать в один. Не вижу в этом смысла. Лучше для предметной области и сделать тогда несколько модулей. А не делать такие секции. Модуль предполагает высокую связанность процедур по использованию общих типов данных. И логично тогда, что все типы определены сверху. А у тебя получится что будет провоцироваться запихивать много модулей в один.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Ноябрь, 2018 06:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9062
Откуда: Россия, Орёл
Иван, отнюдь нет.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Ноябрь, 2018 14:33 

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 27 Ноябрь, 2018 21:13 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9062
Откуда: Россия, Орёл
Вот, хорошее замечание о возможной проблеме.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Декабрь, 2018 09:18 

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Декабрь, 2018 09:56 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2974
Откуда: Астрахань
Ну дык это грамотные. Вы много таких видели в мэйнстриме? :))))


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 19 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB