OberonCore

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

НЕ СТЫКУЕТСЯ с приведенными синтаксическми диаграммами
Вопрос: чего я не прочитал еще

P.S. Вот еще... Про "почти прямое" отражение синтаксических конструкций в код - слышал (в смысле, читал) неоднократно.
Я тоже хочу знать это отражение. Где прочитать
Или хотя бы, как дизасм-то делать

Это описание интерфейса модуля; в приложении D есть оговорка, что интерфейс не определяется языком.

И строится текст интерфейса автоматически.

Чего-то я не пойму, о чем Вы говорите.
На "первом" этапе мне пофиг, кто там чего формирует, в каком формате, и с какой степенью автоматизации.

Я просто читаю раздел <Синтаксис>, и начинаю принимать (в уме) текстовый входной поток как Автомат, в соответствии с прочитаными формальными правилами.
Так вот, мой внутренний "автомат" выдает Syntax error

Прошу прощения, но причем здесь тогда за рыбу деньги
Тут: либо я совсем тупой (против чего буду категорически возражать), либо не там прочитал синтаксис, либо там не все написано.
Либо я еще каким-ни-то макаром ошибаюсь. Но по любому, "syntax error" - полностью отключает понимание происходящего
Тут хорошо бы просто пальцем взять, и указать бы на ошибку...

А вот уже потом (после исправления "синтаксического анализатора") возникнет вопрос - что сия запись означает.
Опять же, прошу прощения, но слово "интерфейс" - есть слабое утешение. Меня интересует бинарное представление того, что получится после алокации памяти под наследника записи, в которой содержатся, пока совершенно непонятные, иероглифы: (X:TypeName)MethodName(ArgList):ResultType - в качестве поля этой записи.
Просто "интерфейс" - расплывчатое понятие в бинарном представлении, по разному его строить можно... Какие-то способы мне даже и известны
А вот после прочтения документации на ББ, у меня пока только какие-то догадки, не более.
Типа как изучение иностранного методом "погружения": никто тебе ничего не переводит, сам догадываешься по смыслу...
Неправильно это.

Вы привели в качестве примера часть интерфейса модуля TextModels. Этот интерфейс создаётся автоматически и является элементом документирования модуля. Соглашения по документированию описаны в разделе "Документирование".

Разделение исходников на текст модуля и интерфейс модуля исторически появилось в Модуле, а в Оберонах интерфейсы генерируются автоматически.

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

Вот цитата с первой же страницы документа "Соглашения по документированию", всё явно указано:

Я имел в виду упомянуть тут, на форуме.

Но цитата еще лучше, конечно.
Надёжней всегда цитата

Вообще всё не правильно. Я имею в виду ответы. О чём спрашивали-то?Что конкретно не стыкуется с какими конкретно диаграммами? А то с таким же успехом можно было дать ссылку на документацию и сказать, что там что-то "не стыкуется" : ).

Хм... Понял так, что ключевым словом здесь является "...не является текстом на языке Компонентный Паскаль, хотя и похож"

Это трудно понять, читая нечто. Ну, скажем, в DesignIdeas.pdf вижу такое:
Ну спрашивается, каким таким третьим глазом я должен понять, что это НЕ КОМПОНЕНТНЫЙ ПАСКАЛЬ, хотя и очень похож


Абсолютно конкретно, смотрю в среде BlackBox "Приложение B: Синтаксис Компонентного Паскаля" документа "Сообщение о языке Компонентный Паскаль"
И вижу, что res: INTEGER; - является нетерминалом FieldList, importing, imported, object: ARRAY 256 OF CHAR; - тоже таковым является.
А следующее (h: LoaderHook) ThisMod(и т.д.) - я и назвал словом НЕ СТЫКУЕТСЯ. Нет, блин, такой буквы в этом слове
А у Вас, стыкуется

Видимо, как говорится, "вкралась досадная опечатка" Вместо "MODULE Kernel" должно быть "DEFINITION Kernel".

Ни в одном описании не нашел рекомендаций по использованию атрибута LIMITED у записей. Что он означает – понятно. Но может ли кто-нибудь четко сформулировать, в каких случаях разработчик модуля должен использовать этот атрибут?

В процессе поиска еще раз прошелся по ссылкам на сайты с Обероном. Ужас. Почти все мертвое. Все бурные обсуждения в прошлом. Разгром полный, прямо Сталинград какой-то. То, что еще живо, покрывается паутиной от старости.
Печально все это.
На сайте разработчиков BlackBox http://www.oberon.ch основной тезис:
Microsoft .NET ist die Basis

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

А че тут обсуждать.
Обсуждать нужно решения. Типо школьное обучение и т.п.
Блэкбокс на линуксе.
Так и обсуждаем, очень даже активно

Альтернативные Обероны действительно теряют нишу -- так что ж тут удивительного. Нормальная консолидация с конкуренцией.

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

У записи могут быть поля, которые недоступны извне модуля, но сам тип при этом экспортируется. Классический Оберон позволяет в данной точке программы объявлять переменные любого типа, который здесь доступен. А также, в классическом Обероне, если тип данных предполагает размещение переменной в куче, и доступен в данной точке программы, то имеется возможность воспользоваться оператором NEW(). При этом, если тип был экспортирован из другого модуля, возникает проблема с недоступными полями записи: с одной стороны, для правильного использования объекта необходимы правильные значения скрытых переменных, с другой - в силу следствия модульности задать их не получится, и рано или поздно произойдёт ошибка времени выполнения. Чтобы ошибка не происходила, необходимо переменную указанного типа размещать не самому, а пользоваться для этого процедурами модуля, откуда экспортируется тип. Поскольку процедура и тип находятся в одном модуле, то все поля записи открыты для чтения и записи и проблема не возникает.

В большинстве случаев дисциплинированный программист обошёлся бы и без LIMITED, но последний избавляет от редких ошибок и не даёт ошибиться новичкам.

Примерно то же самое сказал и Сергей Губанов, но я посчитал, что стоит развить идею и не дать понять неправильно : ).

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

И правильно. Вопрос важный, а дважды по-разному понятней.

Ну с понятностью, тут точно - проблемы будут
Вот читаю в соседнем топике про "курс программирования для старшеклассников на основе Блэкбокса"
Мне кажется, что если школьник прочитает "Учебник по BlackBox" (Tut-Tot.odc), то ему не только ББ, а и вообще программирование противно будет.

Так, на вскидку:

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

Нельзя же так.
Если конечно иметь в виду общеупотребимость хоть в каком-то смысле.
Простые вещи должны и объясняться просто, а не "экспорт ABSTRACT-типа с сокрытием конкретной реализации"

Тут проблема в том, что вакуум сейчас в плане нормального курса ООП. На базе КП.

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

Не к чему отправить человека, незнакомого с ООП, или знакомого с ним через... (как в школе в учебниках - "как круты объекты, а ещё есть классы, кликните мышкой по кнопке и пишите обработчик..."); или знакомого чисто в стиле Буча (ООП С++-ового типа, не-компонентное, с упором на наследование вместо композиции).

Впрочем, тех из последней категории, у кого с английским проблем нет, можно теперь отправлять вот сюда, к дисеру Шиперского:
viewtopic.php?f=60&t=1966

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

Да, писать просто - это ТРУДНО. Особенно, для людей на самом деле постоянно использующих профессиональный слэнг.
Но, НАДО (с поправкой на конечную цель). А в этом плане, еще и конь не валялся, как мне кажется

Наконец, твои знания только тогда являются настоящими, когда ты это можешь изложить просто
И не надо мне рассказывать, что ООП с его виртуальными методами и таким же наследованием (к примеру) - это что-то сложное на самом деле. Слов умных и непонятных много вокруг, а в исполнении - так элементарно все...