OberonCore
https://forum.oberoncore.ru/

Оберон-07: вопросы реализации
https://forum.oberoncore.ru/viewtopic.php?f=115&t=6352
Страница 5 из 5

Автор:  Oleg N. Cher [ Среда, 06 Март, 2019 19:33 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Kemet, тему с флагами предлагаю закончить. Операции типа SYSTEM.ADC добавлены по очень простой причине — для эмуляции отсутствующей в Обероне-07 длинной арифметики.

Официально заявляю, что код ROR спроектирован только для работы в BlackBox, а там никаких подобных операций для проверок флагов в SYSTEM нет. В коде, сгенерированном Ofront+ и компилятором Си, отлавливать поведение флагов таким образом — крайне неприемлемо, особенно со включённой оптимизацией. Кстати, также Ofront не поддерживает операций типа SYSTEM.PUTREG.

Comdiv писал(а):
"Достаточно" запретить VAR-параметры, то есть, описание языка как раз только упростится. Но без добавления других возможностей это усложнит написание программ и понизит их эффективность.
А какими другими возможностями можно заменить VAR-параметры? Это достаточно простой и естественный способ избавиться от указателей. Если лишить программиста возможности работать с записями и массивами по ссылке, а также возвращать несколько результирующих значений, то искусственность выражения мыслей на таком языке только возрастёт.

SovietPony писал(а):
ASSERT(SYSTEM.ADR(a) # SYSTEM.ADR(b))
Бомба! :-)

Автор:  SovietPony [ Четверг, 07 Март, 2019 07:11 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Rifat писал(а):
SovietPony писал(а):
SYSTEM.ADR(a) # SYSTEM.ADR(b).

А если будет 10 параметров и практически все различаются, только два каких то параметра могут совпадать, то уже сотни вариантов кода будут. ...
Если 10 var-параметров, то с кодом явно что-то не так и его следует переделать.
В любом случае запрет уже не для чистого оберона.

Автор:  Rifat [ Четверг, 07 Март, 2019 16:56 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Я как-то делал "аналог STL" на Обероне. Там были некоторые функции, которые принимали примерно 10 параметров. Так что такое встречается. И без этого там никак нельзя было обойтись.

А если взять промышленный код, то по работе мне встречалась функция на Си с 80 параметрами. Это не шутка.

Автор:  Artyemov [ Суббота, 09 Март, 2019 17:02 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Цитата:
Oleg N. Cher писал(а):
Код точно рабочий? Я проверил. Он даёт для ROR(1, 1) результат F333333333333334
А вот это, оказывается, было вызвано багом в калькуляторе Windows 7. Попробуйте вставить число -9223372036854775808 и сконвертить в Hex 8 байт. Он выдаёт: F333333333333334. Если вбить в Hex вручную 8000000000000000 и сконвертить обратно в Dec, будет -9223372036854775808. Мда уж.

Микрософт открыла исходники "виндового" калькулятора.https://habr.com/ru/post/443018/
Цитата:
Компания открыла код для того, чтобы любой желающий мог ознакомиться с такими технологиями Microsoft как Fluent, Universal Windows Platform, Azure Pipelines и другими. Благодаря этому проекту разработчики могут больше узнать о том, как выполняется работа по созданию тех либо иных проектов в Microsoft.

Дикое количество хитровы...думанных технологий в лажающем калькуляторе (калькуляторе!!! на основе проца запредельной вычислительной "мощИ"), а несчастные обероновцы копья ломают про компилятор ;-)
Оказывается не всё так грустно, господа-товарищи.

Автор:  Info21 [ Суббота, 09 Март, 2019 19:08 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Действительно, мда уж.

Автор:  kekc_leader [ Понедельник, 11 Март, 2019 04:53 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Из кода Виндоуского калькулятора:
Код:
Windows::UI::Xaml::Data::ICustomProperty^ BindableBase::GetIndexedProperty(Platform::String^ name, Windows::UI::Xaml::Interop::TypeName type)
{
    return nullptr;
}

Офигенная функция... :lol:
https://github.com/Microsoft/calculator/blob/master/src/Calculator/Common/BindableBase.cpp

Автор:  Info21 [ Понедельник, 11 Март, 2019 13:51 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Rifat писал(а):
Я как-то делал "аналог STL" на Обероне. Там были некоторые функции, которые принимали примерно 10 параметров. Так что такое встречается. И без этого там никак нельзя было обойтись.
Не следует ли отсюда, что на Обероне надо обойтись без "аналога STL".

Автор:  Info21 [ Понедельник, 11 Март, 2019 14:09 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Всем спасибо за "калькулятор".

Хочется сказать, "давно ничему не удивляюсь" -- но всё-таки удивляюсь.

Автор:  Rifat [ Понедельник, 11 Март, 2019 14:56 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Info21 писал(а):
Не следует ли отсюда, что на Обероне надо обойтись без "аналога STL".

Я уже когда-то писал, что STL хорош своими контейнерами set и map, у которых временная сложность O(log(n)) для поиска, вставки и удаления. Для реализации этих структур данных используются сбалансированные деревья. Чтобы реализовать, например, операции поиска, вставки и удаления в АВЛ-дереве надо написать примерно 300 строк кода. Под каждую структуру данных переписывать 300 строк кода не очень удобно. К тому же, если совершить ошибку в реализации сбалансированного дерева, то её бывает сложно обнаружить, поэтому лучше один раз реализовать алгоритм, проверить, что он правильный, и его использовать.
Реализовать обобщенность можно разными способами. На форуме люди писали об этом. Кто-то модифицирует язык под обобщенность, кто-то использует активно модуль SYSTEM и мета-программированием. В моём же методе используются только стандартные средства языка, без использования SYSTEM. А то, что надо передать чуть больше параметров, чем обычно, я считаю не очень большой платой за обобщенность без использования SYSTEM или модификации языка.

Автор:  Info21 [ Понедельник, 11 Март, 2019 21:20 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Спасибо за труд длинного ответа.

Автор:  prospero78 [ Вторник, 26 Март, 2019 08:54 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Rifat писал(а):
А если взять промышленный код, то по работе мне встречалась функция на Си с 80 параметрами. Это не шутка.

Это не промышленный код. Его невозможно нормально контролировать.

Автор:  Comdiv [ Вторник, 26 Март, 2019 14:41 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Для Си это нормально. Например, так многие воплощают ПОЯ. То есть, там аргументы в вызове функции с переменным количеством параметров могут играть другую роль.

Автор:  Info21 [ Вторник, 26 Март, 2019 15:14 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Если всех программеров мира утопить в Байкале, то окрестные жители повышения уровня воды не заметят.

Может быть, в этом выход.

Автор:  Artyemov [ Вторник, 26 Март, 2019 20:30 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Info21 писал(а):
Если всех программеров мира утопить в Байкале, то окрестные жители повышения уровня воды не заметят.

Может быть, в этом выход.

Это чтоб китайцы воду бутилировать не смогли? Она ж злее синильной кислоты будет ;-)

Автор:  Info21 [ Вторник, 26 Март, 2019 21:27 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Artyemov писал(а):
Info21 писал(а):
Если всех программеров мира утопить в Байкале, то окрестные жители повышения уровня воды не заметят.

Может быть, в этом выход.

Это чтоб китайцы воду бутилировать не смогли? Она ж злее синильной кислоты будет ;-)
С чего это?

Если уровень поднимется на 1 мм, то при средней глубине в 300 м это концентрация 3.0E-8 мм. При том, что продукты распада будут выделяться медленно (там вода холодная), плюс какая-никакая биожизнь там есть, она будет эти продукты метаболировать, etc.

Пару-тройку лет будут рекордные уловы омуля. Байкальская нерпа размножится.

Топить однозначно.

Автор:  Валерий Лаптев [ Четверг, 28 Март, 2019 12:07 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Info21 писал(а):
Топить однозначно.

Экий вы, батенька, кровожадный... :lol: :lol: :lol: :lol: :mrgreen:

Автор:  Info21 [ Четверг, 28 Март, 2019 14:34 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Валерий Лаптев писал(а):
Info21 писал(а):
Топить однозначно.
Экий вы, батенька, кровожадный... :lol: :lol: :lol: :lol: :mrgreen:
Потомки будут изумляться взрыву мракобесия в начале аритмоцена.

Автор:  Artyemov [ Четверг, 28 Март, 2019 20:07 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Info21 писал(а):
Топить однозначно.

Мне казалось, что они сродни тёще из анекдота, ..."укусившая её королевская кобра скончалась в страшных мучениях". ;-)

Автор:  Rifat [ Четверг, 21 Май, 2020 12:46 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Речь заходила про aliasing.
Нашел мнение Дейкстры по данному поводу EWD662:
Цитата:
In retrospect I am puzzled by the difference in weight they have given to different fundamental requirements. Concerning the absence of side-effects they have gone further than Ironman —I believe (p.D-33)— but have thrown away the child with the bathwater. On the prevention of aliasing they don't seem to be very keen. They suggest that it is "only an academic nicety" (p.D-29) and state —without source or other forms of support— "it appears that aliasing errors, while troublesome in theory, are extremely rare in practice." (p.D-29). (I think no one is worried by their frequency, but everyone should be worried by the havoc they may create when they do occur: the mere possibility of an aliasing error could easily lead to the development of extremely expensive debugging aids!) But they don't seem to care: on p.D-30 they refer to they "untested benefits" and the "untested practical benefits" of alias checking. This "easy" attitude towards alias checking is in strong contrast to the vigour with which they have made their language "strongly typed". I am puzzled. Did they do so in the belief that the latter requirement was easier to meet in a meaningful way than the prevention of aliasing? I hardly dare to suppose such touching innocence....


Он там ссылается на Ironman, нашел эти требования Ironman:
Цитата:
7I. RESTRICTIONS TO PREVENT ALIASING

Aliasing (i.e., multiple access paths to the same variable from a given scope) shall not be permitted. In particular, a variable may not be used as two output arguments in the same call to a procedure, and a nonlocal variable that is accessed or assigned within a procedure body may not be used as an output argument to that procedure.

Автор:  adimetrius [ Четверг, 11 Июнь, 2020 21:43 ]
Заголовок сообщения:  Re: Оберон-07: вопросы реализации

Rifat писал(а):
... to be or not to be aliasing? Например:
Цитата:
MODULE M;

VAR x: INTEGER;

PROCEDURE Proc(VAR a, b: INTEGER);
BEGIN
a := b + 1;
ASSERT(a # b);
END Proc;

BEGIN
x := 1;
Proc(x, x);
END M.


Рифат, из 10.1 Сообщения о КП:
Variable parameters correspond to actual parameters that are variables, and they stand for these variables.
А также:
The correspondence between formal and actual parameters is established when the procedure is called.

Получается, что построить доказательства (рассуждения) для Proc раз и навсегда невозможно, нужно доказывать каждый вызов. Типа, каждый вызов "порождает" новый "текст" процедуры Proc.
В случае Proc(x, x) Будем иметь x := x + 1 вместо a := b + 1.

А вот более приземленная идея:
TYPE R = POINTER TO RECORD a: INTEGER END;
PROCEDURE P (r: R; b: INTEGER);
BEGIN
ASSERT(~ALIAS(r.a, b), 20); (* реализация м.б. оч. простая, как показал SovietPony *)
r.a := b + 1;
ASSERT(r.a # b); (* теперь без сюрпризов *)
END P;

Или:

IF ALIAS(r.a, b) THEN ... ELSE ... END;

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

Страница 5 из 5 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/