OberonCore

p.s.: вы, кстати, не слушайте Клиффа, когда он чешет про дизайн языков и подобную дребедень: он там не понимает вообще ничего. мы его любим совсем не за это. когда он рассказывает про технологии компиляции — он бог. а когда он начинает задвигать чушь про то, что у си хороший синтаксис и потому, де, его в жабку взяли — это триплфэйспалм. когда он придумывает свой язык — то почти всё, что может быть там придумано плохо, он придумывает плохо. отвратительно просто.

код он, кстати, тоже пишет ужасный. не уровня «невыносимо отвратительно», но уровня «вымойте это с мылом!»

Да, меня тоже это немного задело. Ведь все знают, что java позаимствовала идеи из Oberon. А си - ну, скажу не самый приятный язык лично для меня. И писать кода больше, чем команда из 7 человек. Ещё не смотрел, но вот теперь догадываюсь что там . . . Спасибо, что предупредили. У меня есть склонность идеализировать, иногда в упор не замечая недостатков. И в другую сторону, только наоборот ))).

Вопрос. Почему сборку мусора не сделать в виде внешнего подключаемого модуля. А не как обязательный стандарт языка. Например, как это прописано для ввода/вывода. Не надо придерживаться строгих “дубовых правил”. Каждый сможет выбрать из нескольких бэкендов, подходящий к конкретной задаче. В таком случае для GC можно реализовать несколько вариантов с различными стратегиями. Для трапов ведь получается вынести во внешний подключаемый модуль. Почему не сделать также для GC, разгрузив модуль Kernel. Или это из серии глупых вопросов ???.

И ещё тема автоматически не появляется в списке ‘Активных тем’. Случайность или так и задумано ???.

Kernel — совершенно обычный модуль, который никто не запрещает менять. так что переписать реализации GC, memory allocator и прочее — совершенно не запрещено. ;-) ну, кроме того факта, что компилятор должен уметь в то, что нужно GC (write barriers, например, если у нас GC инкрементальный).

это не отменяет того, что Kernel должен быть «предзагружен», потому что он нужен системе. чтобы что-то загрузить — надо иметь уже загруженый GC и реализацию файлового I/O. в BBCB это линкуется в бинарь; в O/Ur используется хак (загрузка исходников модулей и последующая компиляция делаются на стороне крестов).

в остальном, как я сказал, никто не мешает заменить реализацию — лишь бы с точки зрения программиста такая замена не меняла семантику.

если зачем-то хочется сделать вместо встроеного в Kernel аллокатора и GC интерфейс с хуками — да на здоровье. только зачем? всё равно это надо влинковывать в начальный бинарь, а при таких раскладах не проще ли тупо указать линкеру какой Kernel брать?

и опять повторюсь: реализация GC жёстко связана с реализацией компилятора. компилятор должен знать про внутренние процедуры ядра, вызов которых он вставляет вместо тех же NEW, ASSERT, HALT и прочего, например. ядро должно знать формат модулей, как там расположена информация о типах, секции, фиксапы. это не то, что можно легко отвязать друг от друга.

а вот запрос памяти у ОС в том же BBCB сделан как раз как интерфейс. в O/Ur я вообще поленился возиться со страницами, и выделяю чанки через `malloc()`.

в O/Ur на самом деле есть хак для полноценной условной компиляции, потому что оберон-системы, собственно, нет, и линкования бинарей нет. по этой же причине есть INCLUDE — мне удобней разбивать модули на кучку маленьких файлов. в оберон-системе я могу для такого финта сделать спецредактор и спецчиталку исходников, которую передать компилятору.

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

p.s.: в той же Pow!, например, есть возможность оторвать GC и вручную любиться с освобождением памяти. по какой-то причине они решили интегрированый текстовый редактор сделать именно так. я нифига не понял, зачем.

malloc - это нормально. Особенно учитывая экспериментальный характер проекта. Не факт, что быстро слепленный страничный менеджер окажется сильно лучше стандартного, предоставляемого Linux. У себя вообще не заморачивался. Взял malloc посчитав, что лучше мне все равно не сделать. Исключение только для jit модулей. Но там по другому никак. Требуется атрибут execute. У Вас скорее также ???.

Условная компиляция. Компиляция на лету из исходников. Include. Сильно. Может когда-нибудь и дорасту до таких высот. А сейчас наоборот стараюсь запихнуть в один файл как можно больше, чтобы сократить количество этих файлов. Но это наверное связано с особенностями восприятия (охвата) информации. У каждого своя !!!

В остальном. Да, похоже вопрос из разряда не умных. Вдруг показалось, что можно сделать фиксированный простой Kernel с единственным dispose. А уже к нему динамически подключить GC. Причем и dispose и GC могут работать совместно в параллели. Ладно, в мусорку, так мусорку (((.

`malloc()` у меня используется точно так же, как и `mmap()` — чтобы взять большой чанк. менеджер памяти дальше свой. просто мне лень было для шынды отдельно делать `VirtualAlloc()`, вот и всё. ;-)

житер, конечно, дёргает страницы системными вызовами, тут иначе никак.

компиляция на лету из исходников сделана потому, что мне лень добавлять в Nanojit код для генерации фиксапов, гыг. намного проще тупо пнуть компилятор, пусть из исходников всё делает. и формат модулей на диске изобретать не надо. это не достижение, это на самом деле деградация. ;-)

куча мелких файлов просто потому, что мне так удобно в редакторе. зачем я буду добавлять в редактор лишний код для навигации по частям файла, если я могу просто всё поделить на кучу мелких файлов и спокойно между ними переключаться уже существующим механизмом?

всё исключительно от лени: делаем как можно проще, по возможности избегая лишнего кода.

а DISPOSE быть не должно вообще: это нарушает базовую гарантию безопасности. тогда уже проще спокойно брать сишечку и не заморачиваться. впрочем, у меня в BBCB есть хак: statistics AA tree, память под ноды я там выделяю как раз в страницах, полученых от операционки, в которые GC не смотрит. чисто для скорости: нод много, живут они долго, внутри них ничего интересного нет, а GC постоянно их сканирует. может быть в новом компиляторе сподоблюсь на incremental generational GC, чтобы не приходилось такими глупостями заниматься больше. это и для SoN пригодится потом: SoN плодит ноды как от ураганной диареи, примерно треть из них почти сразу и выкидывает.

уже не могу вспомнить, почему я не разрешил нормальное определение типов внутри процедуры. то есть, наследника записи можно, а методы ему — нельзя. чёрт его знает что такое. разрешил и методы: это очень удобно для всяких `Walk`, которым передаётся контекст с абстрактным методом `Do`. если что — проблемы доступа к апвалуям (то бишь, переменным внешней процедуры) отсутствуют, потому что такой доступ отсутствует у всех. оно несложно, но вот не хочу. когда надо — делается явная запись-контекст и явно же передаётся.

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

вложеный модуль — это, по сути, просто отдельное пространство имён, но с гиммиком: вложеный модуль имеет полный доступ ко всему из внешнего (то бишь, к непублиным переменным, процедурам, etc.), а внешний из внутреннего может дёргать только то, что public. на диске, естественно, внутреннего модуля как отдельной сущности не существует.

rationale: у меня есть привычка разбивать код на совсем маленькие независимые части. иногда для этого можно использовать процедуру, в которую прячутся все потроха, но иногда процедуры мало. а городить некий абстрактый интерфейс, который нужен только вот здесь внутри, но бесстыдно торчит наружу просто от отсутствия способа сделать его ограничено видимым… не нравится. что наружу высунуто — то, сталбыть, для всех, обязательно будет использовано. к тому же обычно добавляются лишние тормоза за счёт виртуальных вызовов. и даже если их нет, то компилятор вынужден инлайнить через границы модулей. фи.

ну, например, хэш-табличка: обычно реализация настолько одинаковая, что её можно скопипастить (как я часто и делаю). но мусорить в модуль внутренними именами из неё — зачем? делать её отдельным модулем — значит, высовывать наружу интерфейс, нужный только для реализации этой хэш-таблички (по сути, интимные детали, которые в любой момент могут поменяться — типа методов `Hash()` и `Equals()`), или заворачивать каждый элемент в отдельную запись с `ANYPTR`, передавать внешнюю реализацию `Hash()` и `Equals()`… короче, сплошная морока без какой-либо реальной необходимости — тупо сражение с компилятором.

с внутренним модулем же ничего лишнего наружу высовывать не надо, и во внешний модуль ничем не мусорим (кроме — увы — неизбежных интрузивных деклараций тех же `Hash()` и `Equals()`). как по мне — стало чище и лучше. реализация несложная (можно обойтись простым name mangling, тупо складывая всё с изуродоваными именами в самый верхний модуль — тогда в компиляторе меняется почти ничего).

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

в схеме и форте я вложеными модулями активно пользуюсь — не вижу, почему в обероне надо этого лишаться.

Локальные модули. Очень правильное расширение. Странно, что ни в одной из существующих реализаций этого не сделали. Причем это не только удобный копи/паст и сокрытие деталей. Локальные модули можно наделить кучей дополнительных свойств. Например монитор. Для автоматической синхронизации потоков или процессов, если в реалиях Линукс. Обеспечивая безопасный доступ к общим переменным и взаимоисключающий вызов процедур, объявленным внутри монитора ))).

Что касается объявления типов, внутри процедуры. Мне казалось, что в этом отношении в оф.спецификации нет никаких ограничений. Считал, что и у Вас нет. За исключением объявления объектов и методов. Считаю, что такие объявления должны быть исключительно глобальными. Вообще стараюсь объекты использовать по минимуму. Там где процедурное программирование будет явным анахронизмом. И даже там часто избегаю объектов. Но это целиком и полностью мое предвзятое мнение !!!.

Вот, ещё. Очень непривычно выглядит Ваш вариант именования модулей - имя : имя : … имя. Может все таки двоеточие ‘:’ заменить на привычный слеж ‘/‘ ???.