Oberon space
General Category => Общий раздел => Тема начата: valexey от Июль 25, 2012, 06:49:32 am
-
Тут говорят свежий Оберон-репорт вышел (см. вложение).
PS. Кстати, заметил что в Обероне-07 (в том числе и этой ревизии) TRUE/FALSE это таки ключевые слова, а вот встроенные типы - все еще предопределенные идентификаторы, таким образом их можно перекрыть локальным типом в данном модуле.
(а раньше, в первом обероне, можно было и TRUE/FALSE перекрыть, так что TRUE = FALSE могло стать истиной)
PPS. Судя по использованию doc-файлов, у Вирта таки венда :-)
-
В чем там отличия? Кто сравнивал?
-
В чем там отличия? Кто сравнивал?
Я пока не смотрел.
-
Неприлично выходит без ссылки на источник заимствования.
http://forum.oberoncore.ru/viewtopic.php?p=73566#p73566
-
Неприлично выходит без ссылки на источник заимствования.
http://forum.oberoncore.ru/viewtopic.php?p=73566#p73566
Да, это я упустил. Спасибо.
-
Кстати, из того же источника цитата Вирта о этой ревизии:
I have made an addition to Oberon-7:
I added the basic type BYTE.
It is fully compatible with INTEGER, of which it denotes the subrange 0 ...
255.
Overflow may occur upon assignment of an integer to a variable of type BYTE.
I have removed the type LONGREAL.
Which standard is used is left open to every implementation.
Furthermore, there are again only 2 kinds of parameters,
the CONST case is dropped.
However, I introduce the restriction that assignments to elements of a structured parameter are forbidden, unless it is a VAR parameter.
(As a result, structured parameter can always be passed by reference).
I append the updated Report.
По моему, это уже какая-то вкусовщина пошла. Можно особо не дергаясь выбирать ту ревизию Oberon-07, что больше подходит для конкретной задачи, не обязательно самую последнюю.
-
По моему, это уже какая-то вкусовщина пошла. Можно особо не дергаясь выбирать ту ревизию Oberon-07, что больше подходит для конкретной задачи, не обязательно самую последнюю.
Скорее придётся выбирать ту версию Оберона-07, для которой удастся найти компилятор, коих всего вроде два доступны для простых смертных...
-
По моему, это уже какая-то вкусовщина пошла. Можно особо не дергаясь выбирать ту ревизию Oberon-07, что больше подходит для конкретной задачи, не обязательно самую последнюю.
Скорее придётся выбирать ту версию Оберона-07, для которой удастся найти компилятор, коих всего вроде два доступны для простых смертных...
Я имел ввиду выбор ревизии для реализации.
-
Сомневаюсь я, что найдётся много желающих реализовать компилятор Оберона-07...
-
Сомневаюсь я, что найдётся много желающих реализовать компилятор Оберона-07...
Наоборот, желающих много. Написание компилятора Оберона это ж одна из дисциплин специальной олимпиады :-)
Желающих написать компилятор Оберона-07, и тем более желающих и могущих много больше чем желающих и могущих написать компилятор хаскеля, или там c++, или ады.
-
Сомневаюсь я, что найдётся много желающих реализовать компилятор Оберона-07...
Наоборот, желающих много. Написание компилятора Оберона это ж одна из дисциплин специальной олимпиады :-)
о_О Что это за олимпимада такая?
Желающих написать компилятор Оберона-07, и тем более желающих и могущих много больше чем желающих и могущих написать компилятор хаскеля, или там c++, или ады.
Ага, вот почему мы завалены сотнями реализаций Оберона-07, а я всё не удивлялся...
-
Ага, вот почему мы завалены сотнями реализаций Оберона-07, а я всё не удивлялся...
Да ладно, реализаций Оберона-07 примерно столько же (тот же порядок) что и реализаций современного хаскелля или С++. :-)
И раза в два больше, чем реализаций современной Ады например.
А если брать реализации Оберона вообще (и 2, и 1 и 07 и так далее), то их же вообще море!
-
Ага, вот почему мы завалены сотнями реализаций Оберона-07, а я всё не удивлялся...
Да ладно, реализаций Оберона-07 примерно столько же (тот же порядок) что и реализаций современного хаскелля или С++. :-)
И раза в два больше, чем реализаций современной Ады например.
А если брать реализации Оберона вообще (и 2, и 1 и 07 и так далее), то их же вообще море!
Хорошо, начнём считать.
Меня лично интересуют только те реализации, которые можно использовать для написания десктопных и серверных программ.
Смотрим:
годных компиляторов С++ имеется минимум 2 -- Visual C++ и gcc
Хаскелл -- 1 компилятор GHC + весьма полезный для работы интерпретатор HUGS
Ада -- GNAT
Из вышеперечисленных трансляторов все кроме Visual C++ -- многоплатформенные, то есть есть и под винду, и под линупсы/юнипсы.
А какие есть аналоги Оберона-07? Бета-версия виндового компилятора от Рифата? Ты всерьёз будешь использовать его в промышленной разработке???
Актуальных версий Оберона-2 на сегодня нет -- все заброшенные.
Компонентный паскаль так и вообще номинально не является обероном -- в его названии нет слова Оберон.
Ну так и де это море?????????
-
Хорошо, начнём считать.
Меня лично интересуют только те реализации, которые можно использовать для написания десктопных и серверных программ.
Ну, это лично твои трудности :-)
Смотрим:
годных компиляторов С++ имеется минимум 2 -- Visual C++ и gcc
Нет. Годных компиляторов современного С++ пожалуй только один - gcc 4.7 (или 4.8 ). И ровно та же ситуация с Си, даже если смотреть не на последнюю ревизию стандарта, а на предпоследнюю (от 99 года). MSVS до сих пор C99 не держит нормально.
Хаскелл -- 1 компилятор GHC + весьма полезный для работы интерпретатор HUGS
Итого ровно один компилятор/интерпретатор (ghc). Hugs современный хаскель не держит.
Ада -- GNAT
Угу
Из вышеперечисленных трансляторов все кроме Visual C++ -- многоплатформенные, то есть есть и под винду, и под линупсы/юнипсы.
Visual C++ вообще выпал из гнезда :-)
А gcc, если уж быть буквоедом, даже в тестовой 4.8 не держит полностью ни современный C++ (2011) ни C2012.
А какие есть аналоги Оберона-07? Бета-версия виндового компилятора от Рифата? Ты всерьёз будешь использовать его в промышленной разработке???
Зависит от этой самой промышленной разработки :-) Вообще это еще большой вопрос, стоит ли в серьезной промышленной разработке использовать всякие там винды и прочие писюки с интелями. Встроенка как бэ надежней и проще может выйти.
Вот какой-нибудь Astrobe - может и стал бы использовать. Why not?
Актуальных версий Оберона-2 на сегодня нет -- все заброшенные.
Дык они все актуальные, ибо Оберон-2 не менялся. :-) XDS, Pow! Опять таки оксфордский компилятор Оберона-2 не заброшен - он активно развивается и является как бэ кроссплатформенным.
Вообще, походи по sf.net и всяким там гитхабам, там этих компиляторов/трансляторов/парсеров оберона действительно много.
-
Занимался тут немного лексерами, заметил, что:
В Oberon report от 1990 года про charset (ака кодировка) сказано следующее:
The representation of symbols in terms of characters is defined using the ASCII set
То есть все в ASCII.
В Oberon report от 2008 года (то есть это уже 07) сказано следующее:
The representation of symbols in terms of characters is defined using the Latin-1 set.
То есть уже все в Latin-1.
А в Oberon report от 2011 и 2012 упоминания о charset уже нет вовсе - лепи что хочешь и на совместимость плевать :-)
Я вот не знаю даже что хуже - Latin-1 в "стандарте" или же отсутствие стандарта вообще.
-
Я вот не знаю даже что хуже - Latin-1 в "стандарте" или же отсутствие стандарта вообще.
Все просто :) Unicode - слишком сложно. Latin-1 - настолько древнее и отстойное, что упоминать стыдно. Поэтому Вирт просто умолчал неудобный момент.
-
Я вот не знаю даже что хуже - Latin-1 в "стандарте" или же отсутствие стандарта вообще.
Все просто :) Unicode - слишком сложно. Latin-1 - настолько древнее и отстойное, что упоминать стыдно. Поэтому Вирт просто умолчал неудобный момент.
Дык! Давеча вот думал а не прикрутить ли к лексеру utf8, и таки решил забить, ибо сложно и не читабельно получалось (если делать декларативно). Но потом, видимо, придется все же прикрутить, ибо язык без поддержки utf8 в строковых литералах это нонсенс в современном мире.
-
valexey занялся написанием компилятора?
-
valexey занялся написанием компилятора?
Да так.. Ковыряю зачем-то на досуге.
-
Занимался тут немного лексерами, заметил, что:
В Oberon report от 1990 года про charset (ака кодировка) сказано следующее:
The representation of symbols in terms of characters is defined using the ASCII set
То есть все в ASCII.
В Oberon report от 2008 года (то есть это уже 07) сказано следующее:
The representation of symbols in terms of characters is defined using the Latin-1 set.
То есть уже все в Latin-1.
А в Oberon report от 2011 и 2012 упоминания о charset уже нет вовсе - лепи что хочешь и на совместимость плевать :-)
Я вот не знаю даже что хуже - Latin-1 в "стандарте" или же отсутствие стандарта вообще.
А зачем ограничивать реализацию конкретными кодировками? Я думаю, что Вирт посчитал, что внутреннее представление символа не должно иметь значение для компилятора.
В зависимости от возможностей среды исполнения можно получить различные компиляторы, причем с точки зрения языка ничего не изменится.
-
А зачем ограничивать реализацию конкретными кодировками? Я думаю, что Вирт посчитал, что внутреннее представление символа не должно иметь значение для компилятора.
В зависимости от возможностей среды исполнения можно получить различные компиляторы, причем с точки зрения языка ничего не изменится.
Как минимум чтобы реализации были совместимы. Чтобы исходники писаные для одной реализации можно было собрать другой реализацией. А про внутреннее представление символа(внутри компилятора/лексера) речи тут не идет вообще.
-
Возможно, Вирт сосредоточился на компиляторах и оставил среду исполнения на второй план. Для нее требуется составлять отдельный список требований, включая совместимость с кодировками. Этого трудно достичь из-за больших различий сред, поэтому Вирт мог предпочесть не влезать в дебри.
-
Возможно, Вирт сосредоточился на компиляторах и оставил среду исполнения на второй план. Для нее требуется составлять отдельный список требований, включая совместимость с кодировками. Этого трудно достичь из-за больших различий сред, поэтому Вирт мог предпочесть не влезать в дебри.
Эмм... А среда исполнения тут вообще не при чем. Смотри:
MODULE Test;
IMPORT Out;
BEGIN
Out.WriteLn("Hello, 世界, Привет!")
END Test.
А теперь представим себе что у нас есть единая среда исполнения и два компилятора с единым парсером но разными лексерами. Один лексер ожидает множество символов Latin-1, а другой лексер ожидает UTF-8. И мы им скармливаем этот пример. Как думаешь, что будет? :-)
Мало того, что Latin-1 лексер не осилит эту программу as is, мы её даже не сможем автоматически сконвертировать в вид приемлемый для него (без потерь информации и без знания деталей реализации рантайма). А ведь это часть семантики.
Ну, а про то, что кроме строковых литералов существуют еще и, например, идентификаторы, я вообще молчу.
Вирт мог бы написать, что используемое множество символов (charset) - unicode. Без уточнения конкретной кодировки (utf-8, utf-16, utf-32, ucs-2 и так далее). Вот тогда было бы полное (в данном месте) определение семантики без уточнения конкретной реализации, и это позволило бы писать совместимые компиляторы (то есть код для одного компилятора после простейшей автоматической обработки/конвертации (банальное преобразование скажем из utf-32 -> utf-8) будет собираться другим компилятором). Кроме того была бы достигнута совместимость снизу вверх.
-
Возможно, он это неявно и предполагал. Исходи из предположения уникода и не просчитаешься.
-
идентификаторы в utf-8 это такая ж...
-
идентификаторы в utf-8 это такая ж...
Тебя смущают идентификаторы не на латинице, или же именно юникод?
PS. И да, я хочу использовать юникод только в строковых литералах и комментариях.
-
идентификаторы в utf-8 это такая ж...
Тебя смущают идентификаторы не на латинице, или же именно юникод?
меня напрягает именно utf-8
а, к примеру, русские идентификаторы меня более чем устраивают, как и ключевые слова. С русскими идентификаторами программа практически самодокументируется.
-
идентификаторы в utf-8 это такая ж...
Тебя смущают идентификаторы не на латинице, или же именно юникод?
меня напрягает именно utf-8
Почему?
а, к примеру, русские идентификаторы меня более чем устраивают, как и ключевые слова. С русскими идентификаторами программа практически самодокументируется.
А, к примеру китайские или там туркменские? Я предпочитаю чтобы я мог разобраться в чужой программе/модуле/либе. Ибо с подобными проблемами (правда пока лишь на уровне комментов) уже сталкивался.
-
Почему?
усложняют разбор, сравнение строк... и подобное
утф для транспорта хорош, ибо компактен, а для работы как-то не очень. по крайней мере для меня.
А, к примеру китайские или там туркменские? Я предпочитаю чтобы я мог разобраться в чужой программе/модуле/либе. Ибо с подобными проблемами (правда пока лишь на уровне комментов) уже сталкивался.
Давай не будем смешивать. Если код предназначен для определенной языковой группы, то там он и должен крутиться, а для глобального применения используются соответствующие, пусть негласные, стандарты.
Можно так же пытаться разобраться в коде, где идентификаторы заданы как lro, rro, ivlevn, baskor - это реальные имена из реального модуля, никакого китайского, и даже русского, всё как ты и хотел, но стало ли от этого понятнее?
-
Почему?
усложняют разбор, сравнение строк... и подобное
утф для транспорта хорош, ибо компактен, а для работы как-то не очень. по крайней мере для меня.
Так он и тут для транспорта только и используется :-) То есть это чисто проблемы лексера. Внутреннее представление в бинаре (это ведь строковый литерал) будет какое-нибудь UTF-32 (aka ucs-4).
-
Давай не будем смешивать. Если код предназначен для определенной языковой группы, то там он и должен крутиться, а для глобального применения используются соответствующие, пусть негласные, стандарты.
Можно так же пытаться разобраться в коде, где идентификаторы заданы как lro, rro, ivlevn, baskor - это реальные имена из реального модуля, никакого китайского, и даже русского, всё как ты и хотел, но стало ли от этого понятнее?
Да, это намного лучше чем 香港, потому что я это могу сказать словами (знаю как произносить), могу продиктовать, могу написать на доске и так далее. Причем меня поймет специалист из любой страны.
-
И да, лично я много хуже воспринимаю код где используется кириллица и, особенно, если там не просто кириллица, а целые слова что-то значащие на русском.
-
Пишем ненормативный лексер, для русского.
-
Кстати, я прощелкал еще одно важное изменение:
Если в Обероне-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.
-
Да, кстати, 32битный сет смотрится абсолютно не логично при плавающей битности INTEGER, поскольку в таком случае он не позволяет делать то ради чего задумался - манипулировать в машинном слове битами. Также я не очень понимаю как будет работать ORD(x) в случае если x это SET.
Напиши Вирту. Очевидно он забыл выпилить цифру 32 ;) Очевидно SET должен быть равен целому по битности.
-
Да, кстати, 32битный сет смотрится абсолютно не логично при плавающей битности INTEGER, поскольку в таком случае он не позволяет делать то ради чего задумался - манипулировать в машинном слове битами. Также я не очень понимаю как будет работать ORD(x) в случае если x это SET.
Напиши Вирту. Очевидно он забыл выпилить цифру 32 ;) Очевидно SET должен быть равен целому по битности.
Из чего следует такая очевидность? Почему множество должно ограничиваться 32 или 64 битами?
Я довольно часто использую множество, как набор флагов, означающих наличие/отсутствие какого-то признака. Самих признаков и под-признаков может быть довольно много. Часто не хватает и 64 бит-флагов. Использовать множество очень удобно для фильтрации, например, когда пользователь выбирает нужные ему признаки и видит, соответственно, то что имеет данные признаки (плюс некоторые агрегаты: суммы, средние и пр., элементов обладающих указанными признаками).
Это простой частный случай, наверное есть и другие ситуации, когда востребованы большие множества.
Было бы целесообразно вообще не ограничивать размер множеств. IMHO.
-
Более чем уверен, что неспроста изменения были сделаны именно таковыми. В том же Free Pascal тип Integer не имеет четкой битности.
-
Было бы целесообразно вообще не ограничивать размер множеств. IMHO.
Александр Сергеевич, Вы просите в прикладных интересах некую абстракцию прямо в языке, который позиционируется как язык "технологического" уровня (не употребляю при Вас всуе слово "системного уровня" :) ), но зачем, если такую абстракцию можно определить библиотечно. Или, если вся работа только и складывается на базе таких абстракций, взять язык прикладного уровня типа 1С :)
Хотя я бы и 1С делал библиотечно :)
-
По поводу битности - моё мнение, что в сегодняшних условиях битность должна быть зафиксирована для каждого типа. Было время, когда все понимали, что 16-бит-целое - это "тесно", и нужно только вот-вот дождаться нового оборудования...
Сейчас насыщение битности достигнуто. Для большинства применений int32 и int64, при это явно обозначенные в программе - самое то. Ну и 64-бит для адресации. Большая битность в большинстве случаев уже не нужна - пора фиксировать в языках.
В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.
-
Было бы целесообразно вообще не ограничивать размер множеств. IMHO.
Александр Сергеевич, Вы просите в прикладных интересах некую абстракцию прямо в языке, который позиционируется как язык "технологического" уровня (не употребляю при Вас всуе слово "системного уровня" :) ), но зачем, если такую абстракцию можно определить библиотечно. Или, если вся работа только и складывается на базе таких абстракций, взять язык прикладного уровня типа 1С :)
Хотя я бы и 1С делал библиотечно :)
Если SET определено в языке, то зачем то же самое делать в библиотеке?..
Мне, в общем, без разницы, но нелогично как-то. Я бы ещё понял, если бы множество произвольной длины было трудно реализовать, а то... совсем непонятно.
Для себя эту проблему я давно решил, даже где-то была методичка по фильтрации данных, через битовые флаги (посредством операторов not, and, or, xor) и посредством работы с множествами (+, -, *, in).
-
По поводу битности - моё мнение, что в сегодняшних условиях битность должна быть зафиксирована для каждого типа. Было время, когда все понимали, что 16-бит-целое - это "тесно", и нужно только вот-вот дождаться нового оборудования...
Сейчас насыщение битности достигнуто. Для большинства применений int32 и int64, при это явно обозначенные в программе - самое то. Ну и 64-бит для адресации. Большая битность в большинстве случаев уже не нужна - пора фиксировать в языках.
В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.
Странные рассуждения. А какой должна быть длина строки? Произвольной. А строка бит от строки символов чем отличается?
Когда-то мне приходилось много работать с битовыми строками произвольной длины, делать поиск комбинаций, вставлять подстроку в строку, вырезать и пр. Суть та же самая, что и при работе с символьными строками. Я понимаю, что для типовых программ этого не надо... сегодня... а что завтра будет?..
В общем, мне логика фиксирования множества не очень понятна. Хотя ещё раз повторю, что обойтись без произвольной длины множества можно... обходятся же без ложки, вилки и ножа... когда очень кушать хочется.
-
В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 8-16 бит? Которые из-за дешевизны для простых задач управления будут ещё долго, возможно, применяться.
У меня тоже туда же взгляд. Поэтому меня 32битный SET категорически не устраивает (ибо он не отображается на железку ну никак). А плавающий (не определенный в языке) INTEGER меня не устраивает потому, что он не позволяет переносить реализованные алгоритмы с одного мк на другой и с персоналки на мк. Безопасно переносить. (замечу, что прибитый гвоздями к 32битам INTEGER меня тоже не устроит)
А INTEGER там (в мк) вполне может быть например 20ти битным.
-
В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 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 - внутренние типы. При необходимости можно сделать присвоение внутреннему типу другого предопределённого типа и перекомпилировать программу. Будет гарантия того, что тип "не уедет" со следующей версией компилятора.
-
В случае Вирта, может быть, это наоборот взгляд вниз, к "дохлым" микроконтроллерам 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 :-)
-
То есть программист может наклепать своих уже прикладных целочисленных типов явно указывая их диапазон. Что позволяет компилятору понять может он вообще это скомпилировать под данную платформу или нет. А другому программисту позволяет прикинуть что же хранится в этом типе, какое множество допустимых значений там. (программа читается легче).
Наклепать типов не проблема, проблема в том, кто арифметику для произвольных типов писать будет... в командах целевого процессора?
Мне кажется, что иметь набор предопределённых целочисленных типов от 8 бит до 256 вполне достаточно для большинства задач. А если настраивать компилятор под специфическую платформу, то надо иметь возможность добавлять соответствующую арифметику с целыми и вещественными числами.
PS. У меня ощущение, что по мере натягивания Оберона на реальный мир (по крайней мере микроконтроллеров с условием безопасной переносимости) постепенно получится AdaLite :-)
Вполне может быть.
-
В Обероне побитовые логические операции с целыми числами запрещены. Когда они необходимы, предлагается делать явное приведение целого числа к SET, а затем обратно. Поэтому, каждому типу целого должен соответствовать его двойник: SET8, SET16, SET32, SET64.
-
В Обероне побитовые логические операции с целыми числами запрещены. Когда они необходимы, предлагается делать явное приведение целого числа к SET, а затем обратно. Поэтому, каждому типу целого должен соответствовать его двойник: SET8, SET16, SET32, SET64.
Ну, это уже... безобразие... Чур меня... от такой "опеки".
-
PS. У меня ощущение, что по мере натягивания Оберона на реальный мир (по крайней мере микроконтроллеров с условием безопасной переносимости) постепенно получится AdaLite :-)
Когда компиляторы Ады ещё только начинали появляться, фирма Tartan сделала компилятор для подобного AdaLite, однако потом всё же довела до стандарта Ады...
-
Я специально посмотрел исходники Виртовского компилятора старого Оберона. В определении языка был только INTEGER, а в компиляторе были реализованы и SHORTINT и LONGINT.
В общем нет проблемы.
-
Я специально посмотрел исходники Виртовского компилятора старого Оберона. В определении языка был только INTEGER, а в компиляторе были реализованы и SHORTINT и LONGINT.
В общем нет проблемы.
В Виртовском компиляторе старого Оберона было полно расширизмов :-)
Да, и проблемы действительно нет, если наплевать на сообщение о языке.
-
)
Да, и проблемы действительно нет, если наплевать на сообщение о языке.
Так если он сам плюнул ... )))
-
)
Да, и проблемы действительно нет, если наплевать на сообщение о языке.
Так если он сам плюнул ... )))
Предлагаю не уподобляться Вирту :-)
-
Я специально посмотрел исходники Виртовского компилятора старого Оберона. В определении языка был только INTEGER, а в компиляторе были реализованы и SHORTINT и LONGINT.
В общем нет проблемы.
Так, народ. Я беру свои слова обратно. У Вирта в компиляторе все верно и он на свой же репорт не плевал. Вот Oberon report тот самый, первый (89/90): http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon.Report.pdf
И там это все есть.
Такое ощущение, что в Обероне-07 и последующих Вирт пытается максимально сократить число типов (иногда откатываясь назад).
-
Так я и говорю
Oberon-07 := LONG ( Oberon-0 );
)))
-
MODULE Test;
IMPORT Out;
BEGIN
Out.WriteLn("Hello, 世界, Привет!")
END Test.
А теперь представим себе что у нас есть единая среда исполнения и два компилятора с единым парсером но разными лексерами. Один лексер ожидает множество символов Latin-1, а другой лексер ожидает UTF-8. И мы им скармливаем этот пример. Как думаешь, что будет? :-)
А что будет в данном случае? Лексеру в данном случае должно быть пофиг. Какая ему разница что этими байтами закодировано?