Oberon space

Теперь тестовые прогоны делаются на сервере. Результаты в абсолютных величинах могут измениться (и изменятся).

Цитата: valexey_u от Декабрь 03, 2016, 01:49:23 am

Сборщика мусора ведь нет?

С самого начала разработки компилятора, я решил максимально упростить задачу. Я не был уверен, что у меня на это хватит способностей. Поэтому, получилось то, что получилось. Однопоточный сборщик мусора не ахти какая сложная вещь, но он меня не интересует. Многопоточный, напротив слишком сложен, поэтому я от него отказался. Вообще, я решился опубликовать компилятор, только потому, что Rifat каким-то образом умудрился сделать кодогенерацию еще хуже. А раз так, думаю, то и я могу. Хотя сначала, делал только для себя и не собирался это никому показывать.

Не, я не к тому что реализация без GC это что-то плохое :-) Я просто уточнил. Есть туча оберонов без GC. И они без GC, полагаю, ровно по той же причине.

Сначала, надо уяснить, что Oberon-07, это язык, предназначенный для быстрой реализации с минимальными затратами и сравнительно эффективного применения в случае простейшей реализации. В связи с этим, все разговоры об умных компиляторах, современных средствах отладки, шаблонах, замыканиях и т. д. лишены смысла. Многие недостатки языка либо упрощают реализацию, либо упрощают отладку в условиях, когда есть только голый компилятор без каких-либо инструментов.

Полностью согласен. Ещё нюанс - до кучи оно еще оптимизировано под то, чтобы писать в одиночку и без IDE. Собственно как Вирт и работает над системой Оберон. В этом плане язык весьма неплохо продуман и довольно удобен.

- ран-тайм проверки (индексы, указатели). Замедляют и так небыстрые программы. Но оказывают неоценимую помощь, позволяют быстро выявить такие ошибки, которые бывает очень трудно найти без пошагового отладчика и прочих средств. Вряд ли я хоть что-нибудь написал бы на O7 без них. Конечно, люди разные, есть и такие, которые могут кодировать сразу без ошибок на любом языке, но я к таким не отношусь.

Это всё же не часть языка, в сообщении о языке про это ничего не сказано. Это часть Оберона как операционки. Ну и, бывает полезно иметь возможность их отключать.

- сильная типизация. Тоже отлавливает очень много ошибок. И да, упрощает реализацию ).

Согласен.

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

Идея визуализации потока управления через "отступы". Это работает не очень хорошо на таком уровне, мягко говоря.

- обязательная квалификация идентификаторов. На первый взгляд, избыточно. Раздувает и без того не очень компактный оберон-код. Но вот, как-то мне надо было просмотреть одну программу на паскале, так я задолбался искать процедуры по всем модулям. Конечно, эту проблему легко решает IDE, но ведь я говорю о простейшей реализации...

С одной стороны полезная штука, с другой стороны, можно было сделать более человечески - разрешить использовать идентификаторы без квалификации если они в импортах были явным образом перечислены. Т.е. что-то вроде IMPORT (function1, typeT, somthingElse) from MyModule, MyModule; -- тут можно без квалификации будет использовать function1, typeT, somethingElse а все остальное из модуля MyModule придется использовать с квалификатором: MyModule.something .

То есть можно было сделать лучше, можно но не обязательно, ибо ресурсы у реализатора ограничены - всё делаем в одно лицо.

- SET. Применяется нечасто, но бывает полезен, когда надо упаковать несколько булевских значений в одну переменную, чтобы не раздувать список параметров.

SET я использовал (при программировании микроконтроллеров) для работы с битиками. Весьма удобно. Железяки иногда требуют записи определенных битиков в определенные места - вот для этого оно вполне ничего себе.

- Беззнаковое целое. Я ни разу не пожалел о его отсутствии. Конечно, бывают случаи, когда этот тип был бы полезен, но для 32-битной реализации это бывает нечасто. Для 64-бит, ИМХО, вообще "не стОит выделки".

Стоит выделки. См. задачку например. Т.е. на моей практике регулярно попадается что-то такое, что требует именно беззнакового целого. И не из за того, что оно в два раза более емкое чем знаковое. Т.е. востребованность беззнаковых типов сильно зависит от множества задач решаемых человеком. Некоторым программистам наверняка беззнаковые и не потребуются, но если вдруг потребуются, будет неприятно.

Между тем, появилось решение использующее вот этот компилятор (компилирует в Си, насколько я понимаю): https://github.com/ComdivByZero/vostok

Цитата: valexey_u от Декабрь 02, 2016, 05:17:03 pm

Да, еще вопрос к akron1: где взять актуальную версию компилятора?

Вроде вот последняя версия: http://board.kolibrios.org/viewtopic.php?f=33&t=2443&sid=06ed798bbd09a775c48ce781636a1776&start=30#p66481

Хм. А собирать его чем? В архиве предположительно только исполняемый файл для калибри. А я эльфов хочу...

А вот какие типы там есть: http://nongnu.org/gm2/type_compatibility.html

GNU Modula-2 compiler собрался. Hello world тоже собрался.

MODULE hello ;

FROM StrIO IMPORT WriteString, WriteLn ;

BEGIN
   WriteString('hello world') ; WriteLn
END hello.

Таким образом, компилятор для модулы есть. С Modula-3 сложнее.

Цитата: valexey_u от Декабрь 02, 2016, 06:52:10 pm

Ну, WinAPI в *nix'ах нет :-) А что сейчас модно использовать вместо Files?

А Wine тогда что такое?

Костыль.