Oberon-07/2012

[valexey]

Давай не будем смешивать. Если код предназначен для определенной языковой группы, то там он и должен крутиться, а для глобального применения используются соответствующие, пусть негласные, стандарты.
Можно так же пытаться разобраться в коде, где идентификаторы заданы как lro, rro, ivlevn, baskor - это реальные имена из реального модуля, никакого китайского, и даже русского, всё как ты и хотел, но стало ли от этого понятнее?

Да, это намного лучше чем 香港, потому что я это могу сказать словами (знаю как произносить), могу продиктовать, могу написать на доске и так далее. Причем меня поймет специалист из любой страны.

[valexey]

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

[Romiras]

Пишем ненормативный лексер, для русского.

[valexey]

Кстати, я прощелкал еще одно важное изменение:
Если в Обероне-07/2008 были четко опеределены все типы (real'ы по ieee (но про это тут речь уже была), а INTEGER это однозначно от -2^31 .. 2^31-1), то тут уже нет (точнее уже в Oberon-07/2011 это уже выпилили). То есть INTEGER это просто целое (никто не знает какое, возможно это 8 бит, а может и 9).

Есть только два типа про битность которых хоть что-то известно: SET (всегда 32 бита) и новый тип BYTE (8 бит).

Так что с переносимостью приложений можно попрощаться.

Да, кстати, 32битный сет смотрится абсолютно не логично при плавающей битности INTEGER, поскольку в таком случае он не позволяет делать то ради чего задумался - манипулировать в машинном слове битами. Также я не очень понимаю как будет работать ORD(x) в случае если x это SET.

[vlad]

Да, кстати, 32битный сет смотрится абсолютно не логично при плавающей битности INTEGER, поскольку в таком случае он не позволяет делать то ради чего задумался - манипулировать в машинном слове битами. Также я не очень понимаю как будет работать ORD(x) в случае если x это SET.

Напиши Вирту. Очевидно он забыл выпилить цифру 32 Очевидно SET должен быть равен целому по битности.

[alexus]

Да, кстати, 32битный сет смотрится абсолютно не логично при плавающей битности INTEGER, поскольку в таком случае он не позволяет делать то ради чего задумался - манипулировать в машинном слове битами. Также я не очень понимаю как будет работать ORD(x) в случае если x это SET.

Напиши Вирту. Очевидно он забыл выпилить цифру 32 Очевидно SET должен быть равен целому по битности.

Из чего следует такая очевидность? Почему множество должно ограничиваться 32 или 64 битами?
Я довольно часто использую множество, как набор флагов, означающих наличие/отсутствие какого-то признака. Самих признаков и под-признаков может быть довольно много. Часто не хватает и 64 бит-флагов. Использовать множество очень удобно для фильтрации, например, когда пользователь выбирает нужные ему признаки и видит, соответственно, то что имеет данные признаки (плюс некоторые агрегаты: суммы, средние и пр., элементов обладающих указанными признаками).
Это простой частный случай, наверное есть и другие ситуации, когда востребованы большие множества.
Было бы целесообразно вообще не ограничивать размер множеств. IMHO.

[Romiras]

Более чем уверен, что неспроста изменения были сделаны именно таковыми. В том же Free Pascal тип Integer не имеет четкой битности.

[Илья Ермаков]

Было бы целесообразно вообще не ограничивать размер множеств. IMHO.

Александр Сергеевич, Вы просите в прикладных интересах некую абстракцию прямо в языке, который позиционируется как язык "технологического" уровня (не употребляю при Вас всуе слово "системного уровня" ), но зачем, если такую абстракцию можно определить библиотечно. Или, если вся работа только и складывается на базе таких абстракций, взять язык прикладного уровня типа 1С
Хотя я бы и 1С делал библиотечно

[Илья Ермаков]

По поводу битности - моё мнение, что в сегодняшних условиях битность должна быть зафиксирована для каждого типа. Было время, когда все понимали, что 16-бит-целое - это "тесно", и нужно только вот-вот дождаться нового оборудования...
Сейчас насыщение битности достигнуто. Для большинства применений int32 и int64, при это явно обозначенные в программе - самое то. Ну и 64-бит для адресации. Большая битность в большинстве случаев уже не нужна - пора фиксировать в языках.

В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.

[alexus]

Было бы целесообразно вообще не ограничивать размер множеств. IMHO.

Александр Сергеевич, Вы просите в прикладных интересах некую абстракцию прямо в языке, который позиционируется как язык "технологического" уровня (не употребляю при Вас всуе слово "системного уровня" ), но зачем, если такую абстракцию можно определить библиотечно. Или, если вся работа только и складывается на базе таких абстракций, взять язык прикладного уровня типа 1С
Хотя я бы и 1С делал библиотечно

Если SET определено в языке, то зачем то же самое делать в библиотеке?..
Мне, в общем, без разницы, но нелогично как-то. Я бы ещё понял, если бы множество произвольной длины было трудно реализовать, а то... совсем непонятно.
Для себя эту проблему я давно решил, даже где-то была методичка по фильтрации данных, через битовые флаги (посредством операторов not, and, or, xor) и посредством работы с множествами (+, -, *, in).

[alexus]

По поводу битности - моё мнение, что в сегодняшних условиях битность должна быть зафиксирована для каждого типа. Было время, когда все понимали, что 16-бит-целое - это "тесно", и нужно только вот-вот дождаться нового оборудования...
Сейчас насыщение битности достигнуто. Для большинства применений int32 и int64, при это явно обозначенные в программе - самое то. Ну и 64-бит для адресации. Большая битность в большинстве случаев уже не нужна - пора фиксировать в языках.

В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.

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

[valexey]

В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.

У меня тоже туда же взгляд. Поэтому меня 32битный SET категорически не устраивает (ибо он не отображается на железку ну никак). А плавающий (не определенный в языке) INTEGER меня не устраивает потому, что он не позволяет переносить реализованные алгоритмы с одного мк на другой и с персоналки на мк. Безопасно переносить. (замечу, что прибитый гвоздями к 32битам INTEGER меня тоже не устроит)

А INTEGER там (в мк) вполне может быть например 20ти битным.

[alexus]

В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.

У меня тоже туда же взгляд. Поэтому меня 32битный SET категорически не устраивает (ибо он не отображается на железку ну никак). А плавающий (не определенный в языке) INTEGER меня не устраивает потому, что он не позволяет переносить реализованные алгоритмы с одного мк на другой и с персоналки на мк. Безопасно переносить. (замечу, что прибитый гвоздями к 32битам INTEGER меня тоже не устроит)

А INTEGER там (в мк) вполне может быть например 20ти битным.

А может быть для типов данных фиксированной длины предусмотреть нечто вроде:

Код: [Выделить]

TYPE
        Integer = Int32;
        LongInteger = Int64;
        VeryLongInteger = Int128;
VAR
        i, j : Integer;
        k : LongInteger;
...
Где Int32, Int64, Int128 предопределённые типы, а Integer, LongInteger, VeryLongInteger - внутренние типы. При необходимости можно сделать присвоение внутреннему типу другого предопределённого типа и перекомпилировать программу. Будет гарантия того, что тип "не уедет" со следующей версией компилятора.

[valexey]

В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.

У меня тоже туда же взгляд. Поэтому меня 32битный SET категорически не устраивает (ибо он не отображается на железку ну никак). А плавающий (не определенный в языке) INTEGER меня не устраивает потому, что он не позволяет переносить реализованные алгоритмы с одного мк на другой и с персоналки на мк. Безопасно переносить. (замечу, что прибитый гвоздями к 32битам INTEGER меня тоже не устроит)

А INTEGER там (в мк) вполне может быть например 20ти битным.

А может быть для типов данных фиксированной длины предусмотреть нечто вроде:

Код: [Выделить]

TYPE
        Integer = Int32;
        LongInteger = Int64;
        VeryLongInteger = Int128;
VAR
        i, j : Integer;
        k : LongInteger;
...
Где Int32, Int64, Int128 предопределённые типы, а Integer, LongInteger, VeryLongInteger - внутренние типы. При необходимости можно сделать присвоение внутреннему типу другого предопределённого типа и перекомпилировать программу. Будет гарантия того, что тип "не уедет" со следующей версией компилятора.

Самый вменяемый подход (и пожалуй единственно рабочий из реализованных) я видел в Аде:

Код: [Выделить]

type   Short_Short_Integer is range -(2 ** 7) .. +(2 ** 7 - 1);
type   Short_Integer       is range -(2 ** 15) .. +(2 ** 15 - 1);
type   Long_Integer        is range -(2 ** 31) .. +(2 ** 31 - 1);
type   Long_Long_Integer   is range -(2 ** 63) .. +(2 ** 63 - 1);

type   Integer_8     is range   -2 **  7 .. 2 **  7 - 1;
type   Integer_16    is range   -2 ** 15 .. 2 ** 15 - 1;
type   Integer_32    is range   -2 ** 31 .. 2 ** 31 - 1;
type   Integer_64    is range   -2 ** 63 .. 2 ** 63 - 1;

type Y is range 0 .. 100;
То есть программист может наклепать своих уже прикладных целочисленных типов явно указывая их диапазон. Что позволяет компилятору понять может он вообще это скомпилировать под данную платформу или нет. А другому программисту позволяет прикинуть что же хранится в этом типе, какое множество допустимых значений там. (программа читается легче).

Этот подход, не идеален (из за того, что для полной уверенности нужно все же вставлять рантайм проверки на переполнение даже если работаем в рамках одного и того же типа, а это жрет место флеша и такты процессора, что может привести к повышенному энергопотреблению и логическую ошибку - можем не успеть сделать все дела в отведенный нам промежуток времени), но он (в сочетании с остальными Адскими фичами) вполне работоспособен.

PS. У меня ощущение, что по мере натягивания Оберона на реальный мир (по крайней мере микроконтроллеров с условием безопасной переносимости) постепенно получится AdaLite :-)

[alexus]

То есть программист может наклепать своих уже прикладных целочисленных типов явно указывая их диапазон. Что позволяет компилятору понять может он вообще это скомпилировать под данную платформу или нет. А другому программисту позволяет прикинуть что же хранится в этом типе, какое множество допустимых значений там. (программа читается легче).

Наклепать типов не проблема, проблема в том, кто арифметику для произвольных типов писать будет... в командах целевого процессора?
Мне кажется, что иметь набор предопределённых целочисленных типов от 8 бит до 256 вполне достаточно для большинства задач. А если настраивать компилятор под специфическую платформу, то надо иметь возможность добавлять соответствующую арифметику с целыми и вещественными числами.

PS. У меня ощущение, что по мере натягивания Оберона на реальный мир (по крайней мере микроконтроллеров с условием безопасной переносимости) постепенно получится AdaLite :-)

Вполне может быть.