Это конечно здорово, но в Обероне нет типа LONGINT, единственный кандидат на эту роль - LONGREAL.
Ну здрасьте, как это нет. Вы какую реализацию Оберона имеете ввиду? Например,
смотрите это описание языка Оберон-2.
Удобный и простой набор базовых типов (символы и строки, короткие и длинные целые и вещественные, логический тип, множества, процедурный тип)
Простые и удобные правила совместимости числовых типов (SHORTINT<=INTEGER<=LONGINT<=REAL<=LONGREAL)
Как работать с памятью выше 2-х гигабайт, не имея беззнаковых целых? В А2 не смогли, поэтому решили таки эти беззнаковые там реализовать. Как обработать файл, размером больше 2-х гб, не вводя 64-х битное знаковое целое там, где оно совершенно не нужно?
Разрешите и мне добавить свои пять копеек.
Мы, воспитанные на ТурбоПаскале и Си привыкли к зоопарку знаковых и беззнаковых типов, поэтому в первом приближении Оберон кажется ущербным. Однако задумаемся вот о чём. Засилье беззнаковых типов разного размера, приравненных в возможностях к знаковым, естественно ведёт к их широкому использованию не только в системных задачах. Беззнаковыми делаются координаты, индексы и прочее. Это перетекает в API многих ОС и прикладных и системных библиотек. Появляется необходимость в приведении типов — знаковых к беззнаковым и наоборот (как правило без возбуждения исключения при неудаче), таким образом, зоопарк типов ведёт к концептуальной путанице прикладного кода и необходимости приводить типы в прикладных задачах, расставляя самому же себе мины на будущее и настоящее. Что ложится дополнительным бременем на бедные мозги программистов.
Раньше на старых процессорах (8 и 16-битных) беззнаковые вычисления были несколько более оптимальны, поэтому типы такие вводились без всякой альтернативы. Сейчас же я вижу их равноправное со знаковыми использование в прикладных задачах излишним. Особенно с учётом того, что программы всё сложнее, и количество вещей, которые необходимо держать в голове, всё больше. Здесь надо смещать акценты в сторону упора на числа вообще, а не их подмножества, которые когда-то эффективнее использовалось на 8 и 16 битных процессорах.
Оберон предлагает путь добровольного аскетизма, получения в уединении и молитве мистических способностей. Естественно этот путь не предлагается всем. Но что Оберон может предложить сейчас?
Если уж есть желание иметь массив размером > 2 Gb, но непременно меньше 4 Gb, и адресовать его обязательно 32-битной переменной, то индексы можно задавать так:
VAR i: INTEGER; (* Этот INTEGER 32 бит. *)
...
arr[LONG(i) MOD 100000000H]Никто не будет спорить с тем, что хороший компилятор может оптимизировать это выражение, даже не переходя в область 64 бит.
В системных задачах часто есть потребность адресовать что-либо. И хотя при такой адресации при очередном INC(addr) вполне может быть достигнут переход от MAX(INTEGER) к MIN(INTEGER) на практике это обычно всё равно работает, ибо отслеживание таких исключений как правило выключено. Вроде хорошо, пользоваться можно, но хочется идеологической правильности. Как же быть?
Прикладной уровень не требует зоопарка целых типов, особенно коротких. Вы не задумывались над тем как проблема с типами лихо решена в .NET и JVM? Эти платформы просто зафиксировали размер типов. А у Оберонов, видите ли, размер INTEGER плавает от реализации к реализации ещё с времён Lilith, с 16 и до 32 бит. Стандартом размер INTEGER не оговорен. Но недостаток ли это? Да, ещё остаются реализации Оберона с 16-битным INTEGER даже на архитектуре x86, но, по идее, этот тип должен быть базовой разрядностью платформы и предлагаться для максимального употребления в прикладной части, чтобы не было засилья LONGINT как в исходниках AOS. И необходимости привлекать для 64 бит новый тип HUGEINT. Использование 16-битного INTEGER на современных платформах не несёт никакого преимущества ни в размере кода, ни в его быстродействии, а тем паче в точности вычислений.
А вы рылись в сишном коде, в котором на каждом шагу знаковые и беззнаковые перемешаны и кастятся друг в друга (иногда неявно)? Про надёжность и высокую понимаемость такого кода говорить не приходится, поэтому чтобы оградить Оберон от такого и были хирургически убраны беззнаковые типы. Но потребность в них для системного программирования всё равно есть. И поэтому я вижу решение в том, чтобы просто ограничить их использование. Я за внесение беззнаковых типов в псевдомодуль SYSTEM. Так мы получим эффективную адресацию в системных задачах без риска поймать исключение при от MAX(INTEGER) к MIN(INTEGER). И так мы запретим огульное использование системы беззнаковых типов где попало и как попало. Такое расширение я реализовал в доработанном мною трансляторе Оберона-2 в Си Ofront. Но то, что находится внутри SYSTEM – это нестандартная языковая надстройка, решение как её реализовать ложится на разработчиков компилятора. Что к стандартам Оберон-языков отношения не имеет.
