OberonCore

Очередной то ли диалект оберона, то ли язык основаный в основном на обероне (часть идей, сколь я понял, позаимствовано из Ады и Зоннона): http://sourceforge.net/projects/migoberon/
Судя по хронологии изменений, в данный момент автор активно причесывает "сообщение о языке".

Спеку языка см. во вложении.

Опять комбинаторика...

Ну почему сразу комбинаторика? Быть может решения автором выстраданы и практически обоснованы.

Или вы таки успели внимательно прочитать спеку?

Я вот лично -- не успел. Пробежался по вводной. Там написано что влияние Ады, Модулы и Оберона с Зонноном. Всё. Судя по спеки (и её объему), это очень близко к Оберону-2 или к КП. И далеко от Ады и Зоннона. Просто исходя из объема описания -- они туда просто не поместились бы.

Это никакой не Оберон, а типичный Зоннон. Больше всего угнетает цель этой затеи - компиляция из нормального языка программирования в Си и Си++

А чё - угнетает? У вас есть НОРМАЛЬНЫЙ компилятор с оберонов? Какого-либо из...
А так - вся прелесть ГЦЦ - в руках.

Какая прелесть в кросс-компиляции? Это, может быть, хорошо в исследовательских целях, но чтобы конкурировать с мейнстримом, нужна компиляция в машинный код и маленький рантайм.

Полно уже компиляторов оберонов во всякого рода промежуточные языки. Но всякий раз оказывается, что удобнее и надежнее программировать непосредственно на Си, Java и C#, а Оберон оказывается зажат ограничениями той или иной платформы.

После фраз "всё есть объект" и "перегрузка операторов" читать сильно расхотелось. Но я не закрыл, позже дочитаю.

Не компиляция, а трансляция. Кроме того, Си используется лишь как промежуточное представление. Человек его никогда не увидит. Так какая разница?

Долгое время ghc использовал эту же схему. Вполне хорошее промежуточное решение в условиях ограниченности ресурсов.

Например, для строковых операций у x86 процессора есть специальные инструкции и для проверки индекса массива тоже, а в языке Си их нет. Ещё едва ли можно будет проверку типа сделать за 2-3 такта. Опять же вызов процедур (передача скрытых параметров тега типа). В общем, по производительности ерунда получится.

На самом деле автор прав. Смысл большой!
Как это обяснить.... ну вобщем скажу так: Си - это кросс-платформенный ассемблер.
Т.е. сделав компилер в Си, вы сделали компиллер для всех(вернее для многих) платформ.

Дык я же говорю -- для первого этапа нормально. Зачем сразу по производительности рекорды ставить? Вначале сделать стабильным, предоставить возможность пощупать это максимальному числу людей (т.е. поддержать максимум host и target платформ), а уже потом уже ставить рекорды по производительности, если это вдруг станет критичным.

В условиях ограниченности ресурсов это оправдано.

Что-то я не заметил там идей, позаимствованных из Ады. Обработка исключений, что ли?

А чем вас XDS не устраивает?

Предлагаю перенести обсуждение о необходимости создания некого нормального компилятора обычного оберона/оберона-2 в уже существующую ветку: viewtopic.php?f=30&t=900

Тут всё же чуть другой язык.

1. Новая семантика оператора присваивания несколько озадачила. Правильно ли я понял, что соответствие каждой переменной и каждого выражения, значение которого присваивается переменной, устанавливается порядком их перечисления? Замучаешься запятые считать.

2. Список импорта внутри объявления объектов - это, по-моему, шаг назад.

3. Есть и хорошее. Константы TRUE и FALSE наконец-то стали ключевыми словами, а не предопределёнными идентификаторами.

Это первое, что бросилось мне в глаза, не считая модификаторов и спецификаторов.
Посмотрел пока по диагонали.

Это шаг к Eiffel. Это не шаг назад и не шаг вперед, это шаг в сторону.

Я про инкапсуляцию, которая должна (но, как видим, не обязана ) быть на уровне модуля.

Насколько я помню, в Зонноне объекты приравниваются к модулям, а в Эйфеле модулей и вовсе нет -- объекты вместо них.

Вероятно, предположили, что речь о заранее определенном ограничении в языке.