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