OberonCore https://forum.oberoncore.ru/ |
|
Предложение о произвольном порядке секций в модуле КП https://forum.oberoncore.ru/viewtopic.php?f=29&t=6315 |
Страница 1 из 1 |
Автор: | Илья Ермаков [ Среда, 21 Ноябрь, 2018 14:00 ] |
Заголовок сообщения: | Предложение о произвольном порядке секций в модуле КП |
Предлагаю к спокойному обсуждению на перспективу вот что. КП, наследуя в этом Оберону, чётко определяет: сначала секция объявлений, потом процедуры, при этом принцип предобъявлений сигнатур. Всё сделано для однопроходной компиляции с прямой кодогенерацией - в классическом Обероне. Ценность этого для мини-языка и тем более обучающего курса - огромна. Однопроходный компилятор, действительно, влезает на несколько страниц книги "Проект Оберон". Реально в случае диалектов Оберона, из которых объективно лидирующий (особенно в общих применениях) - КП (или, как Дмитрий Дагаев предложил на прошедшей конференции, возвращать имена - Oberon-L, я его в этом бы поддержал, как минимум для индустриального названия: задалбывает всё время объяснять эти связи, кто от кого и почему называется, а "Паскаль" для индустрии всё равно красная тряпка) - так вот, в случае диалектов типа КП используются компиляторы с фронт-эндом и бэк-эндом. Задачи иметь однопроходных компилятор для КП, в общем, не стоит и не будет стоять. Теперь разберём минусы зафиксированного порядка. В рекомендациях по кодированию для КП вообще рекомендовано даже всегда сначала объявлять константы, потом типы, потом переменные. Это хорошо для системного кода и небольших модулей, действительно. Для прикладного кода, где есть смысловые группы (типы с соотв. константами) всё наоборот. В моих задачах, где используется механизм токенов, ещё больше: рядом с типом есть и объявления переменных-токенов. Вложение: Но процедурные объявления пока жёстко отделены в секцию процедур. Самый очевидный минус от этого связан с декларациями абстрактных интерфейсов. Возникает разрыв в определении целостной сущности. Да, у нас, типа, есть вьювер символьников, но зачем иметь лишний разрыв и в исходнике, это раз, приличная часть мыслепроцесса может идти ещё на этапе псевдокода, когда для компиляции ещё чего-то не хватает (а проектирование интерфейсов - это не то, что алгоритмизация, где принцип - компилируй на каждой итерации уточнения, действительно, рулит). Т.е. просто разрешением чередования объявлений и процедур мы бы снимали "малой кровью", без изменения основной грамматики языка, то, что в Активном Обероне, Зонноне и др. вообще "решено" по мейнстримному: всовыванием методом между 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/ |