OberonCore

Ну и в отношении ^ (разыменование указателя) уже есть пример от Вирта такой же необязательности.

Нет уж, не дикси. Подали мячик - принимайте теперь ответ. Я не понял, что Вы хотели сказать этими шпаргалками. Шпаргалки - для тех, кто уже знаком с темой. А для новичков это просто китайская грамота. Я единственное, что понял (если правильно) - это что точка смотрится чище, чем ; , поэтому и ставить её разделителем не так больно. Если так, то это здорово, но в тех языках, к которым относится оберон, точка отделяет член от организма, к которому этот член относится (гусары, молчать!). Но что такое


?

Предлагаю переместиться с этим обсуждением в тему про точки с запятой, потому что здесь тема про Ofront+, а необязательные точки с запятой, как выяснилось, сначала придумали в AO/A2, потом некий многомудрый швейцарец (забыл его имя) перенёс его в свой "oberon+", и только потом Олег это позаимствовал. Во всяком случае, мне так показалось по сумме того, что было сказано и найдено. Можно даже и правило в Го пытаться вывести из АО, но это больше похоже на натяжку пока что, тем более, что в Го правило другое.

Следующая ошибка.

Эта программа, по идее, должна выводить на экран число 2, но не выводит ничего - какой-то тихий крэш? Если закомментировать вызов процедуры IncProc, то, как и одидается, на экран выводится число 0.

Пардон, ошибся, по идее, программа должна выводить на экран число 1 (но не выводит).

Ещё одна ошибка.

Этот модуль успешно компилируется в BlackBox, а при компиляции oFront+'ом происходит ошибка со следующим сообщением: OfrontOPV 610:50 Terminated by Halt(-4). CASE statement: no matching label and no ELSE.

Подтверждаю: оба примера вызывают проблемы.

Первый пример вообще интересный. Вы пробовали компилировать его BlackBox'ом? Находит две ошибки, почему? Попробовал в самой свежей сборке Центра.



А вот Ofront+ такое компилит, но сишный код несколько подозрительный. Разбираюсь дальше.

GameHunter, вуаля: убираем EXTENSIBLE и - о чудо - пример начинает компилиться. Знаете почему? Потому что две расширяемых записи, находящиеся в родстве, в КП не могут считаться совместимыми. Вдруг одна из них расширена. Тогда присваивание не имеет смысла.

Я помню этот момент, когда ещё добавлял в Ofront+ атрибуты записей и процедур. Но я сделал как в Обероне-2: тут могут, тут все записи расширяемые. А в КП не могут. Так что это не ошибка.

Т.е. в Ofront'е+ сейчас совместимость расширяемых записей проверяется в рантайме. И если присваивание имеет смысл, то оно происходит, а если не имеет - тогда будет трап. Ну как и в Обероне-2. И для КП я сделал так же. Возможно, здесь стоило бы сделать как в BlackBox'е.

Комментарии приветствуются.

В сообщении о компонентном паскале написано, что расширяемые записи не совместимы для присваивания. По этому надо просто на этапе компиляции выводить сообщение об ошибке, как это сделано в BB.

Следующая ошибка. Этм два модуля успешно транслируются в си, но результат при компилировании выдаёт ошибки.

GameHunter, ого, Вы меня практически завалили. Буду разгребаться помаленьку.

Дело в том, что в Обероне и Обероне-2 (а заодно и в O7) все записи по умолчанию расширяемые. И они при этом совместимы для присваивания. Поэтому используются рантайм-проверки.

Кстати, в КП не решена проблема копирования расширяемых записей этим способом. Вы бы как предпочли копировать? Только поэлементно? Тут ведь приведение типа с охраной не сработает.

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

P.S. GameHunter, что-то Вы, видимо, мутите хитрое - судя по коду.

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

По этой ошибке выяснилось:
Программа аварийно завершается по защите типа:



Т.е. то, что BlackBox находит явно в процессе проверки синтаксиса, Ofront+ делает в рантайме.

Мне пришло в голову, что мы всё-таки можем сделать "как в BlackBox". Для чего я просто буду проверять текущий диалект, и если это КП, то генерить ошибку.

Правильно ли я понимаю, что для исправления этой проблемы достаточно сделать проверку на присваивание расширяемых записей в момент компиляции?

GameHunter, маленький хинт: если импортировать Kernel, то будет консольный вывод ошибок. А если нет, тогда только код возврата в ОС.

Проверил в онлайн-Обероне-07, такое присваивание тоже компилится:



Получается, что в диалектах, где все записи расширяемые без акцента на этом (потому что они могут быть и не расширены), такое присваивание проверяется в рантайме. А в КП специально ввели тег EXTENSIВLE, чтобы ограничить использование записей, в т.ч. и по присваиванию.

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



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

По второй проблеме (слева Online Oberon-07, справа Ofront 1.4 for BlackBox):



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

Влад Фольц утверждает, что описание языка Oberon-07/16 прямо запрещает такое использование вызова:

Тогда вопрос: разрешить только для КП, запретив для остальных диалектов?

По третьей проблеме советуюсь с Йозефом Темплом.

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

Тьфу, опечатался. Правильно - соответственно, проверка на присваивание во время компиляции.

Закрыл вторую проблему:

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/106

Сейчас разыменование результата процедуры разрешено в диалектах КП и O3.

Побочным эффектом добавил в O3 косвенный вызов процедуры вида:
Как у Влада реализовано в Eberon. Как оказалось, OP2 синтаксически поддерживает эту конструкцию, только надо было поправить один вызов (OPV.design на expr, кто в теме).

Для желающих поспорить подчеркну: такой вызов реализован только в экспериментальном диалекте O3.

По третьей проблеме: оказывается, она не решена и в CPfront. Йозеф сейчас поддерживает Ofront не шибко оперативно, это может затянуться. Так что, я думаю, нам есть смысл подключить Дмитрия Викторовича Дагаева, если у него есть интерес закрыть эту ошибку в МультиОбероне.

GameHunter, когда уже явите миру свой супер-проект на Обероне? Для которого нужен такой хитрый код с вложенными записями. В исходниках BlackBox, которые я пересобирал CPfront'ом полностью, такого кода нет. Иначе бы эта проблема вскрылась раньше.