Модуль в Оберонах — это не только единица компиляции, загрузки и связывания, это ещё и механизм инкапсуляции. При обращении к сущностям подключенного( импортированного ) модуля, требуется обязательная квалификация этого модуля. Например, если модуль A импортирует модуль B, и использует его переменную v, то обращение к этой переменной должно иметь форму B.v, что снижает количество трудноотcлеживаемых ошибок использования совершенно других сущностей с тем же именем в немодульных языках, зависящих от последовательности подключения файлов и поведения компилятора.
Как я уже говорил, инкапсуляция в Оберонах также построена на концепции модуля — все типы, объявленные в модуле прозрачны друг для друга, а доступ внешних клиентов к сущностям модуля осуществляется посредством спецификаторов доступа. На текущий момент в Активном Обероне имеются следующие спецификаторы доступа:
* спецификатор «полный доступ» — идентификатор помечается знаком «звёздочка» (*);
* спецификатор «доступ только для чтения» — идентификатор помечается знаком минус (-);
Идентификаторы с отсутствующими спецификаторами недоступны внешним клиентам.
Например:
TYPE
Example* = RECORD a*, b-, c : LONGINT; END;Описывает тип записи Example1, экспортированный за пределы модуля. Поле a доступно для чтения и записи клиентам модуля, в котором объявлен тип, поле b доступно только для чтения и поле c скрыто от внешних клиентов.
Имя модуля( итогового объектного файла ), указываемое после ключевого слова MODULE, может не совпадать с именем файла, что используется, например, для разделения реализаций модуля. Данный механизм может использоваться вместо механизма директив условной компиляции — мы всегда подключаем модуль с известным и фиксированным именем, а средства сборки генерируют необходимый модуль в соответствии с условиями сборки — различные ОС, процессоры и т.п.
В Активном Обероне подключаемые( импортированные ) модули могут иметь псевдонимы, различные модули могут иметь один и тот же псевдоним, формируя некое подобие пространства имён или псевдомодуль, обращение к сущностям пространства имён осуществляется по его имени, реальные имена модулей не доступны. Имена сущностей, находящихся в таком пространстве имён не должны пересекаться.
Исторически сложилось, что обычно, операционная среда Оберон предоставляет интерфейс для динамической загрузки и выгрузки модулей, хотя, возможно и статическое связывание, как, например, в Pow! или OO2C. Сам язык предоставляет лишь секцию импорта модулей и секцию инициализации модуля. В некоторых реализациях есть также секция финализации модуля, но, в общем случае, среда времени выполнения предоставляет программисту интерфейс для регистрации процедур-финализаторов, которые автоматически вызываются при выгрузке модуля или завершении работы программы при статическом связывании.
Типичная структура модуля в Активном Обероне:
module Name;
import Modules, ....;
procedure Finalize*;
begin
...
end Finalize;
begin (* инициализация модуля *)
Modules.InstallTermHandler(Finalize); (* регистрация финализатора модуля *)
...
end Name.
(Да, в Активном Обероне ключевые слова могут быть в нижнем регистре, а не только КАПСом, выбор набора осуществляется по форме записи первого значимого идентификатора в модуле — ключевого слова MODULE. Если он записан в нижнем регистре, значит все ключевые слова модуля должны быть также в нижнем регистре, если — MODULE, то в верхнем.)
Если модуль загружен динамически, то выгрузить его можно только в том случае, если на него нет ссылок из секции импорта других модулей, т.е. выгрузка должна производиться в обратном порядке. Выгрузка модулей в ОС A2 производится командами SystemTools.Free принимающая список выгружаемых модулей и SystemTools.FreeDownTo, принимающая список модулей, которые должны быть выгружены после выгрузки всех ( рекурсивно ) ссылающихся на них.
Операционная среда старается не выгружать модули, предоставляя программисту выбирать время выгрузки( в том числе все зависящие от требуемого ), так как у динамической загрузки кроме плюсов есть существенные минусы — при неаккуратном подходе к выгрузке можно получить ситуацию, когда на модуль нет ссылок из секций импорта и он выгружен пользователем, а установленные им колбэки, например, остались, что вызовет исключительную ситуацию. Потому, что, как говорил Маленький Принц, «есть такое твёрдое правило — встал поутру, умылся, привёл себя в порядок — и сразу же приведи в порядок свою планету». Иными словами, если мы наставили колбеков, то нам их и убирать, что и производится в финализаторах модуля. Хорошим тоном считается создание для процедурных переменных реализаций по умолчанию — заглушек, которые и должны быть установлены при первоначальной инициализации модуля, в котором находится такая переменная и при финализации модуля, который установил эту переменную, присвоив свою реализацию.
Труднее обстоит дело с экземплярами ссылочных типов ибо ссылка может находится в модуле, который не подулючал модуль, в котором реализован тип, и формально на него нет ссылок в секциях импорта. Частично, с этим можно бороться применяя фабрики.
При выгрузке модуля, выгружаются код и данные, за исключением дескрипторов типов, так как в системе могут остаться экземпляры этих типов. Всем указателям в дескрипторах типа, включая указатели на методы в VMT присваивается значение NIL. При обращении к таким сущностям произойдёт исключительная ситуация.
Как видим, аскетичность реализации Оберон-Систем имеет как плюсы, так и минусы, которые следует учитывать в своих разработках. Никаких реальных проблем для устранения этих недостатков нет, кроме усложнения среды времени выполнения и компилятора.
Возможно, что с помощью сообщества эти проблемы получится решить, выведя Оберон на новую орбиту.
Комментарии (54)
grossws
28.05.2015 15:42Как я уже говорил, инкапсуляция в Оберонах также построена на концепции модуля — все типы, объявленные в модуле прозрачны друг для друга, а доступ внешних клиентов к сущностям модуля осуществляется посредством спецификаторов доступа.
По небольшому опыту с golang, где используется аналогичный подход, — довольно удобная вещь (там видимость определяется тем заглавная или прописная первая буква идентификатора).Kemet Автор
28.05.2015 15:53Ну разработчики Go много чего взяли из Оберонов, в чём сами признались.
valexey
28.05.2015 19:15Go is mostly in the C family (basic syntax), with significant
input from the Pascal/Modula/Oberon family (declarations, packages), (дальше про другие языки)
То есть они в основном посмотрели у оберона немного синтаксиса объявлений (переменных, типов), и по факту его модифицировали и применили, а также модульную систему.
Но тут конечно есть нюанс в том, что ни синтаксис объявлений ни модульная система в принципе не уникальны у Оберона. Есть языки которые были раньше с тем же, есть языки которые были позже. Оберон просто наиболее простой из них (скорее всего).
Кроме того, те же модули у Го и Оберона действительно сильно отличаются. У Оберона модуль это обычно единица компиляции и загрузки-выгрузки. У Го — нет (а динамической загрузки-выгрузки там нет вовсе, сейчас компоновка только статическая). В обероне один модуль == один файл исходника. В Го пакет — это множество исходников в одном каталоге.
При этом вот лично мне и в Го и в Обероне не нравится как сделан экспорт сущностей из модуля/пакета. Там просто инлайн мелкая пометка (в Го — заглавная-строчкая буква идентификатора сущности, в Обероне — * ). Соответственно если например смотришь где-то исходники, где нельзя использовать дополнительный инструментарий (на гитхабе например), то приходится прочесывать всю реализацию чтобы понять что именно оно там экспортирует. Мне больше нравится когда перечень экспорта оформлен отдельно. В идеале — как в Аде например. Писать дольше, но читать и разбираться в исходниках потом намного проще.
При этом автогенерация спецификаций модуля по исходнику мне тоже не нравится — либо там не будет коментариев (коментариев именно к спецификации относящейся) либо в реализацию модуля придется забивать комментариями которые нужны для спецификации, но не для реализации.
В данном случае мне нравится когда мухи отдельно, котлеты отдельно. И при этом чтобы компилятор проверял, что реализация модуля не противоречит его спецификации (иногда полезно разрабатывать отталкиваясь от спецификации на модуль, а не от реализации, то есть вначале пишем спеку, потом реализуем, причем по спеке можно также автоматически сгенерировать реализацию-заглушку).Kemet Автор
28.05.2015 19:35-1>>То есть они в основном посмотрели у оберона немного синтаксиса объявлений (переменных, типов), и по факту его модифицировали и применили, а также модульную систему.
Позаимствовать синтаксис описания типов, переменных, методов и концепцию модулей/пакетов- это, извини уж, очень много.valexey
28.05.2015 20:13+4Описание типов в обероне ничем не отличается от того, что было раньше его, в той же Аде например, или даже паскале, или в Mesa. При этом, у Го система типов другая, следовательно и объявления все же другие. Даже синтаксически.
Объявления переменных в Go откровенно другие — местами это похоже на Оберон или Аду, местами нет. Например в Go активно переменные объявляются по месту и без анотации типов.
А концепция модулей и пакетов, как я уже говорил, во-первых отличается, а во-вторых опять таки, в этом Обероне тоже не уникален. До него была Ада и Модула-2, а до Модулы-2 была Mesa.
Единственное что действительно у Go очень похоже на Оберон-2 (но не Оберон) — это синтаксис объявления методов (ака процедур связанных с типом). Но семантика там все же другая.
Ну и естественно на Го намного больше повлиял Limbo — это по сути прямой предшественник Го. Питон тоже повлиял, и еще пачка разных других языков.
Есть и свои, уникальные находки.
Это все в совокупности делает Go новым, самостоятельным языком. Не иеальным естественно, но и не клоном какого-либо сущствующего языка. И уж точно это не Оберон с сишным синтаксисом.
PS. Да, а синтаксис таки вторичен. Семантика языка всегда важнее.Kemet Автор
28.05.2015 20:57Нет, Алексей. Я думаю, что разработчикам Go виднее, заимствовали они из Оберона и Паскаля или нет. Они явно пишут, что заимствовали. Раньше там было даже указано более подробно, что заимствование шло из Оберона Оберона-2, Активного Оберона. Сейчас стоит просто Оберон и это правильно, ибо это всё Обероны, включая Компонентный Паскаль( о чём, опять же, явно пишут его создатели, приложившие руку и к созданию Оберона-2, тем более, что и компилятор там от Оберона-2). Создатели Limbo и Inferno также писали о том, что их вдохновил именно Оберон — и язык и операционная система.
Конечно, с самого начала, разработчики Go о своих заимствованиях из Оберона и Паскаля не упоминали, пока их не ткнули носом. Тогда было признано, и на сайте Го появилась такая информация официально.
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
Добавятся в Активный Оберон кортежи — синтаксис объявления не изменится.
Поэтому и в Го, как типы не назови, какие новые типы не вводи, синтаксис останется неизменным, иначе такая каша получится…
И да, никто не называет Go Обероном с сишным синтаксисом.valexey
28.05.2015 21:44Сейчас стоит просто Оберон и это правильно, ибо это всё Обероны, включая Компонентный Паскаль( о чём, опять же, явно пишут его создатели, приложившие руку и к созданию Оберона-2, тем более, что и компилятор там от Оберона-2).
…
Чтл касается некое различие типов — это совсем не важно, ведь когда в Активный Оберон были добавлены комплексные типы, перечисления, беззнаковые, адрес, синтаксис определения типов остался тем же самым и язык также остался языком семейства Оберон.
В Модуле-3 также есть объявление переменных по месту(почти по месту) и вывод типа переменной по типу результата первого присваивания. Но, при этом oна осталась языком семейства Модула и синтаксис не изменился.
С такой логикой можно очень далеко уйти :-)
Ну, например: С++ получился из Си после того как в него добавили немножко типов и изменили систему типов, так что это тот же самый язык! C взял очень многое у Алгола-68, так что это считай алгол, Алгол-68 базируется на Алголе 60. В это же время Паскаль вырос из Алгола 60, а модула выросла из паскаля, а из Модулы получился тот самый, первый Оберон, ну а Активный Оберон это ж тоже тот же самый Оберон. Таки образом что? Правильно, С++ и Активный Оберон — это языки одного и того же семейства Алгол, очень-очень близкие языки. Почти одно и то же :-)
Но на самом деле нет. Си от С++ отличается очень и очень сильно (и хороший программист на Си не факт что сможет хорошо программировать на С++, и наоборот — С++ программисту придется серьезно переучиваться чтобы вменяемо писать на Си большие проекты). А С++98 значительно отличается от С++17 и это таки разные языки, хотя и с обратной совместимостью.
В линейке оберонов же обратной совместимости часто нет вовсе (исключение (с оговорками) Оберон изначальный и Оберон-2). КП а АО не совместим. О2 не совместим с КП, а Оберон 1990 не совместим с Обероном 2015. Это действительно разные языки, с точки зрения прикладного программиста разные.
Я уверен что многим может понравиться Активный Оберон, он действительно довольно современен и удобен. Те же математические расширения его могт весьма порадовать тех, кому в программах часто приходится иметь дело с матрицами (аля матлаб). Но, одновременно с этим, настолько же многим скорее всего не понравится писать на Обероне 2015 который делает, между прочим, Вирт (а Активный Оберон это все же не его детище).Kemet Автор
28.05.2015 22:37Не нужно передёргивать — заимствовать концепции какого либо языка и быть основанным на нём — это совершенно разные вещи. Если ты этого не понимаешь — мне жаль, но не более того.
Что касается C++98, C++11, они остаются быть C++, сколько ты там цифр ни напиши и есть семейство языков C++, куда входят различные диалекты, равно как есть и семейство языков Оберон, куда входят разные Обероны.
И таки да, некоторые относят C++ к семейству Алгола, хотя синтаксис разный, но семантика ведь важнее, не правда ли?
Далее, про то, что модули есть только в Обероне и это придумка Вирта может говорить только человек далёкий от Оберона, к тому же очевидно же, что Оберон основан на модуле-2, это никто не скрывал, как раз наоборот. А так как он основан(а не заимствует) на модуле-2, то входит в семейство модулы, формируя, в тоже время, новое семейство языков Оберон и так далее. На сайте ETHZ есть официальная генеалогия языков Оберон, и заметь там написано Oberon Language Genealogy Tree
Слово семейство там нет, можно, конечно, сказать, что писали тупые, а Вирта обозвать эээ… неумным, но прежде этого стоит внести как минимум такой же вклад в развитие информационных технологий и научной школы, а учитывая, что в том числе его ученики и ученики его учеников и коллег, прошедшие школу Оберона и создают тот самый менстрим, то это выглядит как минимум глупо и смешно.valexey
28.05.2015 22:52Ну, если уж мы занялись генеалогией, то следует заметить, что у ЯП нет генеалогического древа. У ЯП это будет абсолютно сумасшедший граф :-)
Поэтому, вообще говоря, таксономия из биологии, или же из генеалогии людей тут совершенно не применима.
Единственный четкий критерий который можно использовать для эмпирического выявления близости ЯП — это существует ли такая программа на языке А, которая также соберется и компилятором языка Б и будет корректно работать, и если существует, то насколько велика эта программа (в плане использования возможностей языка А (но тут мы сейчас упремся в определение что такое «языковая возможность» и как их считать)) может быть.
Это покажет насколько человеку придется переучиваться в плане написания кода при переходе с языка А на язык Б.
И еще один критерий, уже не столь четкий, и более субъективный, но вполне явно проявляющийся: насколько хорошие практики программирования на языке А применимы как хорошие практики для языка Б. То есть это покажет насколько сильно человеку придется переучиваться при переходе с одного ЯП на другой в плане архитектуры.
Ну а затем наоборот. Если наблюдается симметрия — то языки скорее всего содержат в себе общего «предка», или не содержат общего вовсе. Если наблюдается ассиметрия, значит кто-то из них, возможно, предок другого.
Как-то так.
PS. А «генеалогия» языков Оберон похоже перестала обновляться примерно в 2000 году. Там нет многих языков. Даже Zonnon'a нет (наверно Active Oberon for .net это его предшественник). И естественно там нет современного Оберона от Вирта.valexey
28.05.2015 23:02Хотя нет, тест не очень. Если я получу язык Б из языка А простым изменением синтаксиса (то есть даже грамматику менять не буду, просто лексемы другие выберу, например заменю все {} на begin end и далее по списку), то первый тест покажет нулевое пересечение, второй же покажет 100 процентное пересечение (но этот тест сложно назвать формальным).
Таким образом в этом, первом, тесте предусловием его прохождения является совпадение синтаксисов, что скучно и не правильно.
Возможно тут стоит иметь два этапа теста:
1) текст as is
2) интерпретация ast после приведения всех лексем и простых правил к единому виду для обоих языков (тут требуется уточнение).
Просто потому, что довольно глупо считать два языка соврешенно разными, если у них из отличий {} vs begin/end и := VS =
Kemet Автор
28.05.2015 23:04Не стоит своё виденье мира выдавать за этот мир.
Генеалогическое дерево есть и у разговорных языков и у зыков программирования.valexey
28.05.2015 23:08+3Откуда там дерево то? Это граф. Направленный и ацикличный, если считать что каждая новая ревизия языка это новый язык. У каждого узла графа несколько родителей и несколько потомков.
Либо это направленный граф с циклами, если новую ревизию языка (или новый стандарт) считать тем же языком.
Разве нет?Kemet Автор
29.05.2015 07:26+1Нет. Я ведь тебе говорил, не стоит путать наследование с заимствованием.
В русском языке, есть заимствования, к примеру, из немецкого, французского, английского ..., но при этом он не стал ни немецким, ни французским, ни английским, ни каким то ещё, он остался русским.
В рамках семейства языков( тем более языков программирования ) чётко прослеживается дерево наследования, потому что, как ни крути, любой язык семейства основан на каком то языке этого же семейства. Именно это и отображает генеалогическое дерево в том числе генеалогическое дерево языков Оберон. Это не отменяет того факта, что заимствования могут быть даже в рамках языкового семейства, но не заимствования формируют дерево.
В рамках же взаимосвязей языковых семейств, действительно дерево может превратиться в граф, хотя и здесь можно выстроить именно дерево, зафиксировав соглашение, по каким признакам будет строиться дерево семейств языков.Kemet Автор
29.05.2015 07:31добавлю, что каждый язык генеалогического дерева (узел) может сформировать своё семейство, выступая в качестве основы, что, в принципе, и происходит
Yuuri
29.05.2015 10:10+1Не всегда наследование «одиночное». Креольские языки
При разработке ЯП вообще никто не мешает взять и смешать фичи двух родителей хоть поровну.Kemet Автор
29.05.2015 11:27Речь больше о языках одного семейства, про возможность множественного наследования семейств я упомянул.
Тем не менее и креольские языки имеют одного предка — пиджин, если не ошибаюсь. к тому же, креольские языки это языковая семья
Kemet Автор
29.05.2015 12:09Язык программирования также всегда наследует черты одного предка, разбавляя их внешними заимствованиями. Язык также может вообще быть новаторским, формируя новую семью и не имея предка, но имея заимствования — сейчас это случается редко, но случается.
Однако, когда некий человек создаёт язык, не имея достаточной базы знаний для этого и, по сути, не представляя свой создаваемый язык в целом, даже не представляя что он представляет, тогда в процессе вынужденной эволюции(язык плохо спроектирован), он может измениться до неузнаваемости, и будет казаться, что вот «отсуда» унаследован, тогда как первоначально был «оттуда», но это только значит, что только сейчас у разработчика сформировалось видение архитектуры и концепции языка (возможно, под действием чьих-то пинков)
Kemet Автор
29.05.2015 21:42Оберон-07 создовался Виртом под свой конкретный проект — RISC процессор на FPGA. Простой процессор — простоя язык программирования, только те типы, которые напрямую отображаются на машину. Всё вместе — процессор с кодом verilog(сейчас на Lola-2), Компилятор и операционная система — это пособие для студентов, которое и используют в ETHZ (в принципе в качестве учебной ОС там могут использовать другую свою разработку — MINOS, по крайней мере в других курсах её используют).
Это учебный проект и личный интерес Вирта к FPGA.
Ещё раз — Оберон-07 создавался под конкретный проект, под конкретный процессор, и в языке есть только то, что требуется для этого проекта. Студенты могут легко изучить все разделы — разработка процессора, разработка компилятора, разработка операционной системы.
Поэтому претензии типа как на нём написать LibreOffice несколько несостоятельны.
Как-то так.valexey
29.05.2015 22:03Ну, во-первых это полуправда. Хотя бы потому, что операционная система Оберон от 2013 года не написани ни на Обероне ревизии 2007 года ни на Обероне ревизии 2013 или 2015 года. Там свой диалект (и именно поэтому мне пришлось компилятор Виртовский таки портировать).
А во-вторых если говорить о том Обероне что в Project Oberon 2013, то цели создания его ничем в общем то не отличаются от целей создания Оберона (и системы и языка) что вышел в 1989 году. Конкретный язык оптимизированный под данный конкретный проект, под конкретное железо и нужды. Цели идентичные — изначально Оберон был также писан потому и для того, чтобы было по чему преподавать и на чем тренеровать студентов. Но была и разница — тогда рабочии станции Ceres с Обероном на борту, насколько я понимаю, использовались еще и для почты внутри университета например.
Попытка же из Оберона сделать ЯП общего назначения (то есть не под конкретный проект) неизбежно его раздувает. В оригинальном ЯП Оберон описание 16 страниц, в Оберон-2 (а это уже первые шаги к народному ЯП) уже 26 + 50 страниц из Oakwood Guidelines (там уже и стандартная библиотека какая-то появляется + уточнения семантики и синтаксиса языка). Насколько я понимаю, Компонентный Паскаль и Активный Оберон (со всеми расширениями) еще сложнее и больше.
Но мы с тобой конечно смотрим на Оберон под разными углами — ты с точки зрения практического применения, ибо ты его активно применяешь в работе, поэтому у тебя Active Oberon, а я с точки зрения исследователя и копателя концепций, поэтому меня больше занимают именно виртовские Обероны — изначальный и вот свежий.
В плане оптимизации проекта по размеру и обозримости (и ЯП и ОС) Вирт безусловно добился отличных успехов. Тут если ему и есть равные, то я их не знаю.
В плане применимости на практике (то есть не для DIY, а именно промышленно, когда нужен прежде всего результат, а не процесс), видимо следует смотреть на то, что там делали уже ученики Вирта — Active Oberon, КП и проч.Kemet Автор
30.05.2015 07:08Алексей, прекрати троллить.
В чём же я соврал то, что это правда только наполовину, если ты повторил мои слова?
Я ведь написал, что может быть Oberon System, а может быть MINOS. Для подтверждения этого заходим на сайт ETHZ в раздел Native Systems Group, находим там Jurg Gutknecht и Felix Friedrich, смотрим там учебные планы, темы и убеждаемся в сказанном мной.
Вот, кстати, пример (pdf) и т.п.
И видим там FPGA, A2, MINOS, Project Oberon и ссылки на Вирта и много чего, подтверждающее мои слова.
Ну а в плане использования, у на сне только A2 с Активным Оберонаом, но есть и Native Oberon с Обероном, для укправления производственной линией.
Так что да, интерес к Оберонам у меня не праздный.
А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.valexey
30.05.2015 14:14Сергей, читай пожалуйста внимательнее то, что пишу я. Про полуправду — это было про язык на котором писан Project Oberon и язык Oberon rev 2007.
valexey
30.05.2015 14:29А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
Любоптыно. А железка у вас с экраном/gui? А в важей железке тоже прерываний нет, или вы ими просто не пользуетесь? А если пользуетесь, то как реализовали их поддежрку в Project Oberon, ведь там их поддержки нет вовсе, да и язык тоже их не умеет.Kemet Автор
31.05.2015 12:25Оберон-07, как и Оберон изначальный, это основа, базмс, минимально необходимое ядро, на котором строится необходимый инструментарий. Если сравнивать с процессорами, то Оберон это risc, а C++, это cisc подход. И Там и там можно решить одну и туже задачу, причём любую.
Исходя из этого, к базису( Оберон-07 ) можно добавит надстройку, получив в итоге такое же ядро для конкретной предметной области, что и сделано, например, в реализации Оберон-07 для ОС Minos, написанной на варианте этого языка. И в этом варианте языка и компилятора есть поддержка прерываний. И привязка процедуры к конкретному адресу в ОЗУ тоже есть.
Об этом я сужу по примерам кода для Minos в презентациях и планах лекций.
В нашем порте Project Oberon также нет прерываний — это простой порт практически один в один. Архитектура процессора позволят использовать программный ввод/вывод, без использования прерываний
Но небольшая прослойка между железом и ОС всё-таки есть. На плате нет никаких разъемов для монитора, да и экран подключить нельзя — всё отображается на удалённом компьютере, связанном с железкой Ethernet, WF, BT. Для удалённой отрисовки используется некий вариант ReGIS.
valexey
30.05.2015 18:09А портирование(выполнено моим сотрудникам) нового Project Oberon на нашу железяку (VAX-11), было выполнено за два выходных, это довольно просто сделать для такого маленького и проработанного проекта.
А кстати, ты ведь опять тут вводишь хабрасообщество в заблуждение. За два выходных получилось его портировать (Project Oberon 2013) в основном не потому что он такой маленький простой и хорошо описанный, а потому, что у вас уже был порт на вашу железяку (VAX-11) прежнего Project Oberon, а новый Project Oberon от старого не слишком отличается. Соответственно требовалась лишь адаптация порта под новую версию Project Oberon.
Насколько я помню, Вирт писал, что портирование Project Oberon на новую платформу занимало примерно по полгода работы. Но никак не два выходных.Kemet Автор
31.05.2015 12:32Алексей, мы использовали Native Oberon(«использовали» — потому, что сейчас используем A2).
Естественно, что нигде использовать Project Oberon мы не будем — это было тестовое задание для нового сотрудника. И выполнил он его именно за два выходных дня.valexey
31.05.2015 22:36Ну вот оттуда видимо и перенесли те части в PO которые за VAX-11 отвечали. Без этого допил бекенда под VAX-11 и перенос системы занял бы как обычно — полгода. Как Вирт и писал.
Kemet Автор
01.06.2015 05:21Не стоит придумывать, я ведь всё написал
valexey
01.06.2015 17:12Ты не написал как именно порт Project Oberon 2013 осуществлялся, сказал лишь что за 2 выходных. Исходня из того, что у вас уже Native Oberon под VAX-11 уже был, я предположил что эти наработки как раз и использовались. Просто глупо не использовать эти наработки и этот опыт делая порт Project Oberon 2013 под VAX-11.
Разве нет?
Kemet Автор
01.06.2015 05:26Коллеги Вирта вполне могли тратить полгода — явно основная часть времени у них уходила на учебный процесс, исследовательскую работу и т.п., на портирование оставалось всего ничего.
valexey
01.06.2015 17:19Ну, наврятли это все же делались за пару выходных за все эти полгода. Полагаю это все же как минимум 2-3 недели фултайма. Кроме того, Вирт в таком вот режиме, когда основную часть времени уходит на учебный процесс и т.п., написал первую ревизию Проекта Оберон за 2 года. Таким образом выходит, что ваш коллега вполне мог бы осилить проект оберон (из рассчета что два его выходных это примерно полгода работы профессора из Цюриха в свободное от основных занятий время) за 8 выходных.
Ну, либо твои коллеги на порядок профессиональней учеников и коллег Вирта, а также самого Вирта, и лучше разбираются как в чужом железе, так и в Обероне :-)
В общем, по моему, что-то не сходится.
Kemet Автор
30.05.2015 07:26>>В плане применимости на практике (то есть не для DIY, а именно промышленно, когда нужен прежде всего результат, а не процесс), видимо следует смотреть на то, что там делали уже ученики Вирта — Active Oberon, КП и проч.
Алексей, ещё раз повторю даже то, что ты сам написал, Project Oberon -это учебный и исследовательский проект, то, что плоды этого труда вдохновляют других людей на собственные исследования и творчество, используют для реального применения, говорит, что труд Вирта и его коллег был не пустым времяпровождением и не попыткой попила бюджетного бабла, что тоже вызывает уважение.valexey
30.05.2015 14:15Я где-то писал что Project Oberon полное говно, провалился и никому не нужен? По моему, ты борешься с тем, чего нет :-)
roman_kashitsyn
28.05.2015 22:25+2В данном случае мне нравится когда мухи отдельно, котлеты отдельно. И при этом чтобы компилятор проверял, что реализация модуля не противоречит его спецификации (иногда полезно разрабатывать отталкиваясь от спецификации на модуль, а не от реализации, то есть вначале пишем спеку, потом реализуем, причем по спеке можно также автоматически сгенерировать реализацию-заглушку).
Именно так и сделано в Ocaml — файлы разделяются на .mli и .ml. Первые содержат интерфейс модуля и комментарии, вторые — реализацию. Причём .mli можно самому не писать, компилятор их сам может генерировать. Но хорошим тоном считается всё же писать их руками (при этом можно сгенерить хедер компилятором, а потом поправить руками).
Мне вообще импонирует модульная система Ocaml, отчасти позаимствованная из Standard ML.valexey
28.05.2015 22:37Да, в OCaml сделано хорошо. Единственное что мне в нем, пожалуй не нравится (в плане модульности) — это то, что чтобы использовать что-либо не нужно это самое что-либо ипортировать. То есть это как в java. Использовать можно сразу, только придется присать все префиксы.
Соответственно взглянув на реализацию модуля сразу нельзя сделать вывод от каких модулей он зависит. А видеть такое бывает полезно все же.
PS. На всякий случай: я за объявление переменных по месту использования, а не в единой могучей секции VAR :-)roman_kashitsyn
28.05.2015 23:32На всякий случай: я за объявление переменных по месту использования, а не в единой могучей секции VAR :-)
На самом деле, когда смотришь много кода в вебе (например, в тулах для код-ревью), где нет умных IDE, потребность в явных квантификаторах для импорта приходит довольно скоро. Сразу осознаёшь, почему жабийimport pkg.*;, плюсовоеusing namespace xxx;или хаскелевский неквалифицированныйimport Data.XXXдолжны использоваться как можно реже, желательно никогда. Обязательные явные квалификаторы (с возможными алиасами) — одна из моих любимых фич golang.
Сейчас набегут любители JetBrains и начнут тыкать меня в upsource и называть неосилятором IDE, но я по прежнему считаю, что код должен хорошо читаться без всяких IDE.valexey
28.05.2015 23:44Ну, моя позиция тут следующая: если ты просто пишешь import Foo, тогда ты обязан любую сущность из Foo дергать вместе с префиксом, типа Foo.bar, если же ты при импорте явным образом указываешь список сущностей которые ты импортируешь (и только их), то можешь не указывать префикс. Типа import Foo (bar, baz) затем просто используешь bar.
Но нельзя использовать Foo.bar без импорта вообще, как это можно в ocaml и java. И нельзя после import Foo спокойно себе использовать bar без префикса вообще как во всяких сях и java.
IMHO
Kemet Автор
29.05.2015 11:49Дак подобное было в Модуле-2, от которой произошел Оберон, Вирт специально это удалил в Обероне для упрощения языка и компилятора, чтобы любой студент мог разобраться, чтобы проще было портировать и компилятор и Обероне-Систему. И Оберон-Система была под все распространённые(и не очень) платформы, и как приложение хостовой ОС тоже.
Поэтому предъявлять по этому поводу претензии к Оберону не стоит, ибо это одна из главных концепций — простота и надёжность. Оберон никогда не претендовал на захват мира.valexey
29.05.2015 13:27+1В данном случае простота и надежность компилятора достигается за счет усложнения жизни всем тем, кто будет пользоваться языком. Ну, тоесть я мотивы Вирта вполне принимаю, и оно возможно было оправдано даже. Но это язык точно не сделало лучше для пользователей языка.
Kemet Автор
29.05.2015 13:36А что для программистов усложнилось? Для каких программистов?
Мы используем Оберон и Активный Оберон и как-то усложнения не ощущаем. Ты на Обероне не пишешь, ты тем более не можешь ощущать проблем и дискомфорта.valexey
29.05.2015 14:04+1Ты прекрасно знаешь, что периодически я на нем пишу. И еще чаще я читаю код на нем писанный.
Вообще, чтение кода штука значительно более частая чем написания кода, и вот с чтением у Оберона имеются определенные проблемы.
Если говорить о том сколько требуется усилий чтобы разобраться в коде написанного на разных языках в проекте более-менее осмысленного размера, то, по моему личному опыту получается примерно такой списочек (вначале идут ЯП в коде которых проще всего разобраться — где что лежит и как это поправить). Список не полный, и кроме этого, я сюда включил только императивные ЯП:
- Modula-2, Modula-3
- Ada (with generics too), ObjC, С, С++(without stl/boost-like code)
- Go, java, Oberon 1990/2015
- C++/templates (stl, boost, etc)
Напомню, что это список чисто субъективный, и основан на моем личном опыте.
С++(without stl/boost-like code) — это код С++ возможно с интенсивным использованием stl и boost, но не код этих библиотек сам по себе.
С++/templates (это как раз код stl или boost) на последнем месте не в последнюю очередь из за того, что там нет разделения на спецификацию и реализацию. Компилятор это не умеет.Kemet Автор
29.05.2015 16:04Нет, Алексей, периодически писать код на Обероне в пару десятков строк, и от этого тебя ломает, не даёт основания писать, вводя других в заблуждение, что Оберон осложняет всем жизнь.
Я ведь не пишу в паблике, что С осложняет мне жизнь, когда я эпизодически пишу те же самые пару десятков строк и постоянно читаю большое количество кода — в языках C, C++ вообще сложно найти где находится файл инклюда, по крайней мере мне. Не, понятно, что правильно настроенная IDE может решить этот вопрос, ноя смотрю исходники в простом npp.
Очень удобно это сделано в компиляторе Оберона-2 OO2C — по сигнатуре заголовка модуля видно где он находится и где находятся подключаемые модули. Вот заголовок первого попавшегося модуля:
MODULE OOC:SSA; IMPORT SYSTEM, Log, Object, Object:Boxed, Object:BigInt, ADT:Dictionary, Sym := OOC:SymbolTable, OOC:SymbolTable:Predef, OOC:IR, OOC:SSA:Opcode, ResultClass := OOC:SSA:Result, OpndClass := OOC:SSA:Opnd;
В Модуле-3, которая мне больше всего нравится, и которую мы активно используем, есть очень серьезная проблема с пониманием не только того, где находятся исходники модулей, но даже где находится реализация интерфейса, потому что реализация интерфейса может быть разбросана по разным модулям реализации. Да и сам интерфейс может состоять и нескольких интерфейсных модулей, предоставляя клиентам только необходимое(этим достигается и реализация механизма private и protected членов интерфейса). Только анализируя сборочный скрипт и используя поиск можно найти где что находится.
Тем не менее, это, пожалуй лучший язык семейства Модула и наследников.
Но ты так и не сказал, что же усложняет тебе жизнь в Обероне.valexey
29.05.2015 16:12Не-е, меня лично ломает писать на Matlab'e и js (больше всего кода я сейчас пишу как раз на матлабе). А вот ПИСАТЬ код на Обероне — от этого ломки нет (и Оберон я таки лучше знаю и легче на нем пишу, чем на Go, на котором я по работе пишу). А вот разбираться в Обероно-проектах, да, хуже чем в С++ или Аде и, тем более, на Модуле-3 (хотя на Аде я писал совсем-совсем мало, а на Модуле-3 не писал вовсе, но разбираться в исходниках на этих языках почему то проще. парадокс? ;-) )
А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
PS. И да, мне Модула-3 тоже очень нравится. Они же вроде сейчас затеяли сделать для нее llvm бекенд? Судя по активному шевелению в рассылке.Kemet Автор
29.05.2015 17:20>>А что именно осложняет разбираться в проектах на Обероне (а также Go, Java) я описал выше и довольно подробно. Не вижу смысла повторяться.
Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ? На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.valexey
29.05.2015 17:32Вот и получается, что никакого страдания нет, а если оно у тебя есть, то связано не только см Обероном, но и другими языками. Ведь не назовёшь же серьёзной проблемой ЯЗЫКА непонимание где что находится в ПРОЕКТЕ?
Я как раз назову это (а точнее то, сколько усилий требуется чтобы разобраться что где в проекте находится и что с чем как связано, и как это все использовать) проблемой языка, причем весьма серьзеной. В модуле этой проблемы почти нет. В С++ (если оно не в стиле stl писано) тоже проблемы в общем то нет. В Аде — нет. А вот в Обероне, Го, Яве и C++ в стиле boost/stl — есть.
На любом языке, открыв чужой проект в каком нибудь нотепаде ( ты же обероновские модули в неком подобии нотепада сиотришь, когда для С++ используешь наdороченную и настроенную IDE?) нужно потратить время на то чтобы разобраться что где лежит, настроить ту самую супер IDE и вперёд.
Ошибаешься. В основном когда я разбираюсь в чужом проекте (не важно на каком он языке) я использую либо просто веб-просмотрщик github'a (или что-то аналогичное), либо что-то типа FAR'а (если в винде) либо grep + cat | less в юниксах. Вне зависимости от языка.
Если бы я говорил с учетом IDE, то java могла бы (но это вовсе не обязательно) переместиться на самый верх списка (у java прекрасные IDE), но она там, где она есть — рядышком с Обероном. Просто потому, что я не люблю зависить от того, за каким компьютером я сейчас сижу и какое окружение у меня сейчас настроено. Частенько я код читаю, и в нем разбираюсь вообще с планшета, где IDE нет вовсе никакой.
Тем более что если я умею разбираться в коде без IDE, то в IDE я тем более смогу сориентироваться, а вот если я привыкну использовать IDE, то без нее (или в другой IDE) может быть уже больно.
Ну и вообще, у меня обычно получается найти то что нужно в чужом проекте (без IDE) часто быстрее чем у людей знакомых с этим прокетом и с IDE ;-)
Чукча таки опытный читатель ;-)Kemet Автор
30.05.2015 07:17Вот поэтому в постах и говори, что это ты от чего-то страдаешь, и уточняй от чего, а то ведь незнакомые с Оберон-технологией могут поверить в то, что ты пишешь и применить к языку Оберон, тогда как это нужно применять лишь к твоим собственным субъективным ощущениям, причём вообще с языком не связанным. А то, все, всем, для всех, у всех…
valexey
30.05.2015 14:19Понятно, что при использовании ЯП многие вещи субъективны. Ну, например кто-то будет в Обероне страдать от модульности (её наличия) и от статической типизации :-)
Ну а кто-то например, чисто субъетивно и по причинам вообще не связанным с языком, будет утверждать что С++ это боль и страдания :-)
valexey
29.05.2015 16:19Кстати, портирование Оберон-компилятора (виртовского) с переписыванием кусков Оберон-системы под другую платформу, это вот программированием и написанием кода на Обероне не считается, правда? ;-) Ведь компилятор — это очень маленькая и простая штучка, в которой разобраться легко, а кусочки операционки — это вообще фигня.
Так что да, действительно, не пишу и не писал на Обероне :-) Совсем. Никогда.
PS. Но таки да, по работе я оберон действительно не использую. Это хобби и отличная моделька для изучения.
encyclopedist
28.05.2015 18:14Заглавная и прописная это одно и то же :-) Вы очевидно имели ввиду «заглавная или строчная».
Yuuri
29.05.2015 00:11+1В хаскеле тоже так, а видимость определяется явными списками экспорта. Таким же макаром можно абстрактные типы делать.
ignat99
Очень интересный язык, я в 2010 году посвятил ему много времени и в частности A2 (ГолубаяБутылка). Но остаются вопросы по работе этой OS с различным новым железом. Хотя для специального проекта это идеальное решение так как есть исходники абсолютно всего и портирование на ARM то же есть.
Kemet Автор
Не только ARM, но и Cell, PPC, RISC-V, возможно ещё что-то.
Мы сами используем версию под dfhbfyn VAX-11 и PDP-11.
Но в официальном репозитории пока только x86-32/x86-64
ignat99
Вы правы, я это знаю. Но я про внешние устройства: USB 3.0, WiFI, Video, Audio, VGA, HDMI, TS etc. То есть, как минимум надо написать 4 драйвера и каждый год их переписывать под новое железо.