OberonCore

Предлагаю такое исправление.

Код компилируется МультиОбероном, к сожалению, в связи со сменой компа компилятора C нет. Поэтому проверить до конца не могу. В процедуре DefineType у меня есть код.
Насколько могу судить, Вы предлагаете аналогичное решение извне DefineType. Возражений против такого не имею.

Заинтересованы ли Вы в улучшении совместимости бэк-энда в Си с BlackBox? Я тут заметил, что у нас сломалась (или не работала) компиляция некоторых модулей с рекурсивным определением типов.

Прикладываю эти модули, которые компилируются в BlackBox, но в Мульти-Обероне (бэк-энд в Си) их стоит проверить. Хорошо бы также проверить их компилируемость сишкой.

Когда Вы зайдёте в тупик при определении типа, который ссылается сам на себя, вроде:


То я предлагаю в случае определения такого типа подменять тип указателя на самого себя (что не соберётся сишкой) на void*, а потом при разыменовании приводить к нужному типу (для чего детектить тип на присутствие тега RecursiveType):

OPV.design

Если рекурсивное определение не слишком дикое (тип массив имеет элементы типа запись, где поля являются массивами этого же типа), то в рекурсивном определении в кольце обязательно есть указатель. И если его нельзя описать в Си через самого себя, то тут сам просится void*. Мне это решение кажется даже в чём-то изящным. Хотя может я что-то упустил.

Дмитрий Викторович, только Вы можете навести в этом порядок. Я конечно пробую, но у меня получается пока не очень — неуклюже и корявенько. Буду пробовать ещё.

Понятно, буду смотреть ещё.

Докладываю. Собираются с успешной компиляцией Ex, Ex3, Ex4, Ex7. Не собираются Ex2, Ex5, Ex6, Ex8. Я в один код все объединил.

Тесты хорошие. Надо думать над устранением.

Устранено Ex6. Процедура OmfOPC.DefineType. Старый код закомментирован с пометкой [Ex6].

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

(этот модуль отличается от предыдущего ошибочного модуля только тем, что процедура Rec0.Ex экспортируется)



Транслируется в си, но затем не компилируется.

Хорошая правка, устраняет зацикливание. Внёс в Ofront+.

Сейчас пытаюсь разобраться с Ex5 и вклинить определение рекурсивного типа в OPC.DefineType, пока не очень понятно как там всё устроено.

Торжественно сообщаю, что Ofront+ опять перешёл в статус "все критичные проблемы исправлены". На сей раз серьёзно поправлена обработка определений циклических типов, которая потребовала немало времени, чтобы с этим разобраться.

Дмитрий Викторович, мы с Вами называли такие определения рекурсивными, но по терминологии разработчиков ETH Oberon и BlackBox они называются циклическими. А рекурсивными называются определения вида:

Получается, что рекурсивные определения типов не имеют смысла, а циклические согласно описания языка Компонентный Паскаль допустимы:
Здесь прямо не говорится о циклических определениях, но они и не запрещены.

В связи с чем я изменил константу OPC.RecursiveType на CyclicType.

Итак, сейчас Ofront+ успешно транслирует все примеры, о которых были посты выше, плюс даже такой:


А вот если результатом процедуры типа Proc будет Proc, то на таком коде Ofront+ просто выдаст ошибку "not yet implemented":
Вопрос дискуссионный, но я не знаю как это транслировать в Си. Мы обсудили это в группе по Ofront+ в Telegram и единодушно решили, что польза от этих циклических определений весьма сомнительна.

Да, циклические определения разрешены в Ofront+ только для Компонентного Паскаля.

P.S. Могу посодействовать исправлению этих моментов в МультиОбероне. Напрямую брать моё решение в лоб вряд ли нужно — в Ofront+ работа с массивами устроена несколько иначе, чем в CPfront. Но пока в моей голове свежи все эти моменты, можем заняться, если конечно есть интерес.

Да, Вы правы, RecursiveType оказалось неудачным определением. Очень хорошо, что в Ofront+ эти вопросы закрыты. Циклические определения типов точно нужны, а процедуры через процедуры - экзотика.
Надо внимательно все посмотреть.

Реализовал поддержку типов ANYPTR и ANYREC:

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

Пробую собирать модуль Services из BlackBox, в котором есть такой код:


Может ли кто-нибудь объяснить этот модификатор Do- ?

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

Ни в каком другом модуле нельзя написать "VAR a: Services.Action; BEGIN a.Do();", будет ошибка компиляции.

Коллеги, я вынужден сделать пост уже в "своей" теме. Не в продолжение срачика, а в защиту своего кода. Может arisu и запудрил кое-кому мозги, кто не в теме, но в BlackBox нет AST анализатора. Так что моё решение вполне корректно. Оно корректно не "в общем", не в "идеальной рабочей среде, где может быть всё", а в конкретно взятом OP2, где много кода, работающего с mnolev и vis подобным образом. Сделайте поиск в Dev по "mnolev := -128".

Переменную r/o для цикла FOR я внедрил в диалект О3. Там есть ещё одно решение, предложенное Олегом Комлевым, до которого не додумался arisu. Это требование для переменной цикла быть как можно наиболее локальной. Это нужно, чтобы предотвратить использование в качестве счётчика цикла глобальной переменной. Т.е.:

Вполне разумное решение. К тому же ясно сформировано: для чего сделано, что сделано и как.

Ещё одна ошибка при трансляции данного модуля в си:
Ex.cp translating Ex
6:28 err 200 not yet implemented

Давненько Вы ошибок не постили
Данная ошибка присутствует в оригинальном Ofront, но исправлена в CPfront.
Есть фикс.

P. S. А вообще для Оберона-2 это даже и не ошибка, потому что такое объявление параметра не будет совместимо ни с чем, поэтому ничего удивительного нет в том, что Йозеф Темпл не реализовал такое. Это один из спорных моментов КП, где строгость проверки совместимости массивов ослаблена. Непонятно зачем. Структурное совпадение массивов не обязательно обозначает необходимость их совместимости. Меня лично не напрягает объявить их для совместимости вместе под одним алиасом.

GameHunter, а в чём высокий смысл? Всё равно ведь использовать это некак.
(разве что через SYSTEM.THISARRAY)

В нижеприведённом модуле намеренно сделана ошибка: индекс массива выходит за его пределы. По умолчанию включена проверка индексов. Однако, программа завершается, ничего не выводя на экран. А если отключить проверку индексов параметром -x, то, как и ожидалось, выводится 'Finish'.
Вопрос: это проверка индекса глючит, или она работает втихую? В последнем случае надо бы как-нибудь сообщать об этом...

Проверка индекса не глючит. Втихую - было решено, чтобы простая программа не тянула за собой сам принцип консольного вывода, поэтому по умолчанию программа только возвращает в ОС код ошибки. Чтобы получить консольное сообщение, сделайте хотя бы из одного модуля IMPORT Kernel