Oberon Revision 1.10.2013

[DddIzer]

Экспертная оценка от экспертов дноберспейца.

в каком месте? 

[valexey_u]

The type BYTE is compatible with the type INTEGER, and vice-versa.

Интересная формулировка. Т.е., различие только в размере. При этом можно писать как "int := byte" так и "byte := int". Ну и как тут не вспомнить Arian-5?

Если так подумать, то подобное непроверяемое и не безопасное присваивание не новость в Обероне.

Скажем в 07/11 всегда можно было char := CHR(100500); -- это вполне может дать непредсказуемый результат. Ну и INCL/EXCL тоже могли положить свинью, если учесть что INTEGER, в отличае от SET'a гвоздями к 32битам не прибит. То есть в нем могут быть значения которые не отображаются на SET.

Ну, кроме того BYTE тут беззнаковый, то есть модулярный тип, а для него переход через границы вполне нормальное, разрешенное действие даже в Аде (в отличие от знакового INTEGER'a, который может легко переполниться при умножении скажем).

Так что я тут не вижу особой проблемы.

[vlad]

Всё же я не понимаю, зачем в языке общего назначения, каковым Вирт позиционирует свой Оберон, нужны процедуры PACK|UNPK? В жизни никогда ими не пользовался.

Согласен. Можно быле ее смело в SYSTEM, даже если она сильно нужна была Вирту.

Впрочем, множествами тоже, их тоже бы выпилить из языка нужно...

Ну... множества это попытка поднять уровень битовых операций. Пока я для себя еще не определил - получилось у Вирта или нет.

[vlad]

А какие там интересы у коровцев к Оберону? Они же Компонентным Паскалем пользуются, а не Обероном. У них от Оберона только название сайта и больше ничего общего...

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

[vlad]

Отличия бы от предыдущей ревизии.

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

P.S. В том промежуточном черновике больше было всяких странных изменений.

[vlad]

наличие BYTE очень радует. Также радует отсутствие двух разных REAL'ов - это еще сильнее приближает Оберон к жабаскрипту.

Пока не очень представляю, что делать с BYTE в жабаскриптовой реализации компилятора. Прямого отображения в жабаскрипт нет, а эмуляция сведет на нет всю идею эффективного приближения к железу...

[Geniepro]

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

Ну и что же он им не пользуется ни в работе, ни в обучении?

[valexey_u]

наличие BYTE очень радует. Также радует отсутствие двух разных REAL'ов - это еще сильнее приближает Оберон к жабаскрипту.

Пока не очень представляю, что делать с BYTE в жабаскриптовой реализации компилятора. Прямого отображения в жабаскрипт нет, а эмуляция сведет на нет всю идею эффективного приближения к железу...

А вот как раз в современном жабаскрипте уже есть, и я голову ломал как это в обероне эффективно.

[Romiras]

наличие BYTE очень радует. Также радует отсутствие двух разных REAL'ов - это еще сильнее приближает Оберон к жабаскрипту.

Слово LONGREAL в тексте встречается. Также, в приложении в РБНФ есть косвенный признак его присутствия.

Мда, выпиливал Вирт LONGREAL из языка, выпиливал да не довыпилил:

A real number is of type REAL, unless it contains a scale factor with the letter D, in which case it is of type LONGREAL.

Интересно, каков смысл игнорировать присутствие различной точности у вещественных чисел?
Мне кажется, что создатели языка Ада подошли к этому вопросу более практично, чем Вирт.

[Kemet]

кстати, файл репорта называется Oberon07.Report.pdf
Т.е. название Oberon07 пошло от Вирта

[valexey_u]

кстати, файл репорта называется Oberon07.Report.pdf
Т.е. название Oberon07 пошло от Вирта

Я не уверен что это чисто Виртовское. Это мог pdf printer так назвать :-) Ну или выкладывальщики.

[ilovb]

Петруха, полнолуние давно прошло, ты чего тормозишь? о_О

Луна не виновата. Это осеннее обострение...

[valexey_u]

По поводу BYTE:

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

var array = new Uint8Array(100);
Это будет массив именно что байт. Это не массив динамически типизированных объектов js. То есть в каждую ячейку положить что-либо кроме числа от 0 до 255 невозможно.

И эта штука сейчас применяется все шире. И, по моему, прекрасно отображается на ARRAY 100 OF BYTE.

А вообще же, в js есть такие массивы:

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

Int8Array 1 8-bit twos complement signed integer signed char
Uint8Array 1 8-bit unsigned integer unsigned char
Int16Array 2 16-bit twos complement signed integer short
Uint16Array 2 16-bit unsigned integer unsigned short
Int32Array 4 32-bit twos complement signed integer int
Uint32Array 4 32-bit unsigned integer unsigned int
Float32Array 4 32-bit IEEE floating point number float
Float64Array 8 64-bit IEEE floating point number double

https://developer.mozilla.org/en-US/docs/Web/API/ArrayBufferView?redirectlocale=en-US&redirectslug=Web%2FJavaScript%2FTyped_arrays%2FArrayBufferView#Typed_array_subclasses

[valexey_u]

Петруха, полнолуние давно прошло, ты чего тормозишь? о_О

Луна не виновата. Это осеннее обострение...

На этот раз это виновата видеовстреча грядущая: http://forum.oberoncore.ru/viewtopic.php?p=83206#p83206

Ну и возможно геомагнитная обстановка (там опять возмущенное магнитное поле).

[vlad]

По поводу BYTE:

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

var array = new Uint8Array(100);


Да, про массивы я в курсе. Даже проверял как работает с одним элементом a[0] - все как надо. Только не уверен, что жабаскриптовые движки буду оптимизить такой случай. Можно попробовать сделать и прогнать еще раз ту задачку на blur. А заодно сделать целочисленные массивы через соответствующие типизированные жабаскриптовые аналоги.