OberonCore
https://forum.oberoncore.ru/

Оберон-07
https://forum.oberoncore.ru/viewtopic.php?f=115&t=615		 Страница 6 из 12
Автор:  AVC [ Суббота, 25 Октябрь, 2008 19:38 ]
Заголовок сообщения:  Re: Оберон-07
Другой пример не слишком удачного (IMHO) новшества в Оберон - параметр CONST.
Идея помечать аргумент процедуры как read-only (с помощью минуса, как и read-only переменные) обсуждалась ещё при принятии "дубовых требований". Она была отвергнута, т.к. была отнесена исключительно к области оптимизации.
(В качестве опции read-only аргументы поддерживаются некоторыми компиляторами, в т.ч. XDS. В КП аналогом является пометка ссылки как IN.)
И вот теперь Вирт вдруг принимает обратное решение, без нового обоснования (всё это обсуждалось и раньше). Причём выбранное слово CONST, IMHO, неудачно, т.к. константы и read-only переменные разные сущности.
Лично у меня сложилось впечатление, что Вирт просто не любит Оберон-2 и избавляется от сходных с ним черт в новом Обероне. В т.ч. от удачных. :(
Автор:  Valery Solovey [ Суббота, 25 Октябрь, 2008 19:44 ]
Заголовок сообщения:  Re: Оберон-07
AVC писал(а):
3. Привязка оператора RETURN к завершению процедуры-функции.
Возможно, то, что в конце процедуры-функции будет обязательный RETURN, имеет смысл.
Но то, что оператор RETURN нельзя будет использовать в другом месте, в некоторых случаях так же неудобно, как и отсутствие цикла LOOP. Это возвращает нас во времена Паскаля и потребует введения необязательных переменных для хранения результата или аналогичных искуственных приёмов.
Так же, как и в случае с исключением оператора LOOP, здесь просматривается борьба с т.н. "нелокальными переходами" (такими как EXIT, RETURN и исключения), которые якобы противоречат структурному программированию.
Но это миф. Каким образом RETURN в середине функции противоречит структурному программированию? Ведь, выйдя из функции, мы уже никак не сможем нарушить тех или иных инвариантов внутри неё.
Во-первых, результат, передаваемый функцией, всё равно должен где-то храниться. Поэтому, использование явной переменной не приносит дополнительных расходов. Компилятор должен суметь связать переменнную с местом, где у функции будет храниться результат после её отработки. В случае с множественными return-ами, подозреваю, комилятор не всегда сможет справиться с поставленной задачей.
Во-вторых, иногда требуется введение дополнительных переменных, которые не хранят конечный результат, но без которх не обойтись. Я ввёл в практику единичный return больше чем полтора года назад, однако часто встречаться в неизбежностями подобного рода не приходится. Возможно, это для меня не проблема из-за большого ОЗУ или специфики задачи.
Автор:  AVC [ Суббота, 25 Октябрь, 2008 20:48 ]
Заголовок сообщения:  Re: Оберон-07
Valery Solovey писал(а):
Во-первых, результат, передаваемый функцией, всё равно должен где-то храниться. Поэтому, использование явной переменной не приносит дополнительных расходов.
Как правило, функция возвращает результат в определённом регистре, так что дополнительной переменной не требуется.
Тем более в Обероне, где функции возвращают только значения скалярных типов.
Автор:  Info21 [ Суббота, 25 Октябрь, 2008 20:56 ]
Заголовок сообщения:  Оберон-07 for ARM
Armaide

An Integrated Development Environment for
LPC2000 ARM-based Microcontrollers

http://www.cfbsoftware.com/armaide/armaide.aspx
Автор:  AVC [ Суббота, 25 Октябрь, 2008 20:57 ]
Заголовок сообщения:  Re: Оберон-07
Info21 писал(а):
Разве в классическом Обероне разрешены открытые массивы кроме как в параметрах процедур?
Там не было, но уже в Обероне-2 была полноценная поддержка массивов.
Почему не взять хорошее из Оберона-2? (Можно не брать type-bound procedures, но не взять нормальную поддержку массивов... очень странно.)
Автор:  Info21 [ Суббота, 25 Октябрь, 2008 21:09 ]
Заголовок сообщения:  Re: Оберон-07
AVC писал(а):
... уже в Обероне-2 была полноценная поддержка массивов.
Почему не взять хорошее из Оберона-2?

Она там не совсем полноценная.
Массив -- чуть более низкоуровневая сущность, чем запись (объект).
И в О-07 это проявлено.
А с динамическими массивами возникает проблема экспорта элементов только для чтения.
В О и О-07 ее нет. А в Обероне-2 и КП она есть.

Я тоже считал, что динамические массивы нужны, но по размышлении схема в О-07 вызывает меньше возражений, чем в О, и имеет упомянутые плюсы, которых нет в О-2 и КП.
Плюс к тому еще один плюс -- увеличившуюся простоту :-)
Автор:  Wlad [ Суббота, 25 Октябрь, 2008 21:10 ]
Заголовок сообщения:  Re: Оберон-07 for ARM
Info21 писал(а):
Armaide

An Integrated Development Environment for
LPC2000 ARM-based Microcontrollers

http://www.cfbsoftware.com/armaide/armaide.aspx

Новости шикарные! Всё - классно! Но, кнопки "download free" не нашёл...
Автор:  bohdant [ Суббота, 25 Октябрь, 2008 21:21 ]
Заголовок сообщения:  Re: Оберон-07
Цитата:
Новости шикарные! Всё - классно! Но, кнопки "download free" не нашёл...

Ну новостью это нельзя назвать ;) напомню: http://www.ocp.inf.ethz.ch/forum/index. ... tml#msg560
Но всегда можно отправить сообщение Chris Burrows, а вдруг он подскажет где эта кнопочка :)
Автор:  AVC [ Суббота, 25 Октябрь, 2008 21:27 ]
Заголовок сообщения:  Re: Оберон-07
При исключении цикла LOOP и привязке RETURN к завершению процедуры Вирт использовал однотипную аргументацию: syntactically unconnected и syntactically disconnected.
Да, компилятор стал проще. (В целях упрощения компилятора еще и оператор CASE был испорчен, окончательно превратившись в массив меток.) А программировать стало менее удобно. И речь идёт отнюдь не о синтаксическом сахаре.
Не понимаю попыток info21 защищать цикл Дейкстры.
Даже в излюбленном (заведомо выигрышном) примере голландца - алгоритме Евклида - он проигрывает по ясности виртовскому варианту на Модуле-2.
Оберон-07:
Код:
WHILE m > n DO m := m - n
ELSIF n > m DO n := n - m
END
Модула-2:
Код:
WHILE m # n DO
   IF m > n THEN m := m - n ELSE n := n - m END
END
Во втором случае условие выхода из цикла очевиднее.
Автор:  Wlad [ Суббота, 25 Октябрь, 2008 21:32 ]
Заголовок сообщения:  Re: Оберон-07
bohdant писал(а):
Ну новостью это нельзя назвать ;)

Дык я - фигурально! Вне временной привязки.
Было бы не плохо его юзануть на "боевых" системах... А то с АВР32 возиться - ещё стока дерьма повсплывёт (и по собственным непоняткам и по их ошибкам и по дурости начальства, откровенно полагающего, что программисты информацией посредством астральной связи обмениваются, а не из книг и по Сети...)...
Автор:  Илья Ермаков [ Суббота, 25 Октябрь, 2008 21:41 ]
Заголовок сообщения:  Re: Оберон-07
По поводу динам. массивов: не могу говорить про мат. задачи, но в своей практике ни разу их не использовал (пытался, но оказывалось неудобно). В качестве контейнеров чего-нибудь они неудобны. Удобнее и техничнее оказываются списки (или блочные списки, где сцепляются RECORD с буферами фикс. длины). Хотя и написал процедуру SetLength для динам. массивов, которую используют, как сужу по форуму-открытым исходникам, многие, но сам ей не пользуюсь, не нравится.

В целом, просто объявить контейнер в КП не получается, нек. небольшое время приходится тратить на конструирование подходящей структуры данных и операций на ней. Иногда несколько надоедает, иногда наоборот помогает. Решить этот вопрос, не нарушая баланс языка (выскоуровневость в сочетании с машинной прозрачностью), имхо, нельзя. Поэтому принимаем как есть (но относительно того, как бы это могло быть "вообсче говоря", соображения копятся).
Автор:  AVC [ Суббота, 25 Октябрь, 2008 21:53 ]
Заголовок сообщения:  Re: Оберон-07
Info21 писал(а):
Она там не совсем полноценная.
То есть?
Info21 писал(а):
Массив -- чуть более низкоуровневая сущность, чем запись (объект).
И в О-07 это проявлено.
Проявлено таким образом, что я не могу создать массив нужной размерности (если она не известна на этапе компиляции).
Info21 писал(а):
А с динамическими массивами возникает проблема экспорта элементов только для чтения.
Можно не экспортировать, главное - было бы что. :)
Info21 писал(а):
Я тоже считал, что динамические массивы нужны, но по размышлении схема в О-07 вызывает меньше возражений, чем в О, и имеет упомянутые плюсы, которых нет в О-2 и КП.
Плюс к тому еще один плюс -- увеличившуюся простоту :-)
Как (каким-то боком) "компиляторо-писака" :) , я оценил упрощение компилятора и определённое изящество решения. Но язык стал менее удобным для программиста.
Вместе с тем, мне весьма любопытно, к каким выводам Вы пришли по размышлении (и почему).
Автор:  AVC [ Суббота, 25 Октябрь, 2008 21:59 ]
Заголовок сообщения:  Re: Оберон-07
Илья Ермаков писал(а):
По поводу динам. массивов: не могу говорить про мат. задачи, но в своей практике ни разу их не использовал (пытался, но оказывалось неудобно).
Основная выгода от динамических массивов достаётся конечно математикам :) , другое очевидное применение - строки.
Автор:  Илья Ермаков [ Суббота, 25 Октябрь, 2008 22:14 ]
Заголовок сообщения:  Re: Оберон-07
Ну, для меня строка - это LEN <= 256 :-)
Всё, что длиннее - это текст. И применяются, например, TextModels ББ или что-то подобное, библиотечное.
Автор:  Александр Ильин [ Суббота, 25 Октябрь, 2008 22:27 ]
Заголовок сообщения:  Re: Оберон-07
Илья Ермаков писал(а):
Ну, для меня строка - это LEN <= 256 :-)
Всё, что длиннее - это текст. И применяются, например, TextModels ББ или что-то подобное, библиотечное.

А для меня, однако, сразу вопрос, как этот текст (TextModels) передать параметром в WinApi?
Внутри микроконтроллерa - не спорю, можно выкинуть.
Автор:  bohdant [ Суббота, 25 Октябрь, 2008 22:54 ]
Заголовок сообщения:  Re: Оберон-07
Илья Ермаков писал(а):
Ну, для меня строка - это LEN <= 256 :-)
Всё, что длиннее - это текст. И применяются, например, TextModels ББ или что-то подобное, библиотечное.


Извиняюсь, но так и напрашивается: много букв, неасилю :P (не сочтите за оскорбление, просто шутка)
Автор:  Илья Ермаков [ Суббота, 25 Октябрь, 2008 22:56 ]
Заголовок сообщения:  Re: Оберон-07
:P

Нет, на самом деле: строка - это строка.
Текст - это текст. Если предполагается оперирование с многострочными последовательностями знаков - однозначно текст, в библиотечной реализации.
Автор:  Info21 [ Воскресенье, 26 Октябрь, 2008 00:23 ]
Заголовок сообщения:  Re: Оберон-07
AVC писал(а):
Info21 писал(а):
Массив -- чуть более низкоуровневая сущность, чем запись (объект).
И в О-07 это проявлено.
Проявлено таким образом, что я не могу создать массив нужной размерности (если она не известна на этапе компиляции).

Тут логика работы должна быть чуть другая.
В длину массивов закладывается некое ограничение сверху, а реальная длина хранится как отдельное поле. Это не годится, если размерность обрабатываемых массивов может сильно меняться, но и тут, подозреваю, можно извратиться, не меняя язык -- что-нибудь мета-образное.
Это в некотором смысле вынос NEW( a, N ) из языка в библиотеки.
Что-то в таком духе, но щас уж поздно..................
Автор:  Info21 [ Воскресенье, 26 Октябрь, 2008 17:42 ]
Заголовок сообщения:  Re: Оберон-07
Предлагаю завести раздел форума "Идеология Оберонов".
Сделать там ветки:
Структурное программирование
Секция VAR
Цикл Дейкстры
...
и перенести туда соотв. цепочки сообщений.

Так сказать, явим коллективный пример 2-го умотипа 8)
Автор:  Trurl [ Понедельник, 27 Октябрь, 2008 09:55 ]
Заголовок сообщения:  Re: Оберон-07
AVC писал(а):
4. Исключение типов SHORTINT, LONGINT и концепции поглощения типов в целом.
Удобство пользования единственным целочисленным типом понятно. В принципе, это правильно.
Но чтобы такое "учудить" в практическом ЯП, надо жить в башне из слоновой кости.
В реальном мире большое число форматов данных использует для экономии места "короткие" типы. Теперь, чтобы работать с ними в Обероне, придется использовать разные искусственные приёмы, вплоть до привлечения псевдомодуля SYSTEM.


Наличие SHORTINT и т.п. все равно не спасает от необходимости использовать искусственные приёмы.
Страница 6 из 12 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/