Вот тут я уже
задавал вопросы. Вопросов и предложений с тех пор прибавилось, но я начну только с части. Я пришёл из вселенной лиспа. Оберон - маленький, Лисп - большой. У всего есть своя область применения, но я хочу язык размером больше Оберона. Часть того, что я хочу, лучше делать, внеся изменения в сам Оберон, для этого придётся делать форк. Пока я рассматриваю для этого BB, но вообще какой-нибудь консольный вариант может оказаться лучше.
Что я бы поменял? По ходу написания этого списка я понял, что не всё ещё продумано. Вот некоторые более-менее устоявшиеся вещи.
1. INTEGER - это целое число неограниченного размера, живёт в куче и является ссылочным типом. Также есть RANGE(MIN,MAX), частными случаями которого являются нынешние SHORTINT и т.п. Существующий INTEGER придётся переименовать.
2. Точная сборка мусора. Я остаюсь при своём мнении: консервативная сборка мусора - нанадёжный механизм. Точная сборка может привести к сокращению диапазона INTEGER на 1-2 бита, поскольку понадобится отличить указатель от числа.
3. Тип BOX или VARIANT - ему может быть присвоен объект любого типа. BOX знает runtime тип своего объекта, т.е. это - не void *, а поэтому он безопасен. Конструкция with соответствующим образом обобщается. Заметьте, что здесь вводится не больше динамической типизации, чем в случае расширения типов, просто она обобщается и на другие типы. Конкретную семантику нужно ещё уточнять.
ANYPTR в BB недостаточен, т.к. в нём (если я правильно понял) нельзя хранить произвольные массивы. Невозможность хранения примитивных типов можно было бы обойти, включив для каждого из них отдельное поле.
4. Ненулевые указатели - такие, которым нельзя присвоить NIL. Соответственно, добавляется конструкция IFNULL P P1 <Ветка если NIL> ELSE <Ветка если не NIL>, где P - нулевой указатель на T, а P1 - имя переменной . В ветке "если не NIL" указатель P1 имеет тип ненулевого указателя на T и равно значению P в момент проверки условия. В ветке "если NIL" P1 отсутствует.
5. Возможность перебрать все объекты в куче и сделать какое-то действие для каждого из них. Два действия, которые точно нужны - это подсчёт количества объектов, удовлетворяющих заданному условию, и создание списка указателей на такие объекты.
6. Иммутабельность. В простейшем случае это подразумевает добавление одной функции "заморозить", см.
Object.freeze. Но лучше добавить ещё и поддержку ключевого слова const. Для указателя, как и в Си, ввести два понятия - иммутабельность самого указателя, и иммутабельность указываемого объекта.
7. Ввести больше разновидностей char, чтобы поддерживать разные виды международной письменности. 16-разрядный CHAR в BB недостаточен, 8-разрядный из Оберона-2 - тем более. Хотя для европейских языков 16 разрядов хватит. Другое дело, что наличие тега типа может уменьшить количество доступных полезных разрядов на 2-4 бита.
8. API, позволяющее подменять функцию во всех точках вызова. Первое применение этого API - трассировка, но есть и другие.
Надо отметить, что лучше иметь указателем по умолчанию указатель не нулевой, иммутабельный и указывающий на иммутабельный объект. Это сегодня в моде - считается, что такие программы проще и надёжнее. Поскольку слово POINTER уже занято, можно взять для этой цели какой-нибудь PTR, тогда существующую ф-ю PTR придётся переименовать.
Примерно так. На самом деле, это часть планов по Яру, но теперь я переосмысливаю их в контексте Оберона и не всё получается так вот сразу. Яр построен на лиспе, там некоторые вещи проще (например, нет различия между непосредственными и ссылочными типами). Я знаю, что у Оберона есть консервативные приверженцы, которые считают, что в языке есть всё, что нужно. При всём уважении к этой точке зрения, я говорю не о внесении изменений в язык, а о создании другого языка на базе оберона-2. Соответственно, я ищу либо попутчиков, желающих поучаствовать в реализации хотя бы некоторых пунктов этого плана, или, возможно, ссылки на проекты, которые уже идут в том же направлении.