OberonCore • - Оберон-07: вопросы реализации

Сообщения без ответов | Активные темы

Список форумов » Оберон-технологии: языки, компиляторы, системы » Oberon-07 (Revised Oberon)

Часовой пояс: UTC + 3 часа

Оберон-07: вопросы реализации

Страница 5 из 5

[ Сообщений: 100 ]

На страницу Пред. 1, 2, 3, 4, 5

Версия для печати

Пред. тема | След. тема

Автор

Сообщение

Oleg N. Cher

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Среда, 06 Март, 2019 19:33

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 603
Откуда: Украина, Днепропетровская обл.

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

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

Comdiv писал(а):

"Достаточно" запретить VAR-параметры, то есть, описание языка как раз только упростится. Но без добавления других возможностей это усложнит написание программ и понизит их эффективность.

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

SovietPony писал(а):

ASSERT(SYSTEM.ADR(a) # SYSTEM.ADR(b))

Бомба!

Вернуться к началу

SovietPony

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Четверг, 07 Март, 2019 07:11

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 146
Откуда: Equestria

Rifat писал(а):

SovietPony писал(а):

SYSTEM.ADR(a) # SYSTEM.ADR(b).

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

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

Вернуться к началу

Rifat

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Четверг, 07 Март, 2019 16:56

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 989
Откуда: Казань

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

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

Вернуться к началу

Artyemov

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Суббота, 09 Март, 2019 17:02

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 640

Цитата:

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

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Суббота, 09 Март, 2019 19:08

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва

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

Вернуться к началу

kekc_leader

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Понедельник, 11 Март, 2019 04:53

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 249
Откуда: г. Рига, Латвийская ССР

Из кода Виндоуского калькулятора:

Код:

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

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Понедельник, 11 Март, 2019 13:51

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва

Rifat писал(а):

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

Вернуться к началу

Info21

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Понедельник, 11 Март, 2019 14:09

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва

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

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

Вернуться к началу

Rifat

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Понедельник, 11 Март, 2019 14:56

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 989
Откуда: Казань

Info21 писал(а):

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

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

Вернуться к началу

Info21

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Понедельник, 11 Март, 2019 21:20

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва

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

Вернуться к началу

prospero78

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Вторник, 26 Март, 2019 08:54

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1135
Откуда: СССР v2.0 rc 1

Rifat писал(а):

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

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

Вернуться к началу

Comdiv

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Вторник, 26 Март, 2019 14:41

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1475
Откуда: Киев

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

Вернуться к началу

Info21

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Вторник, 26 Март, 2019 15:14

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва

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

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

Вернуться к началу

Artyemov

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Вторник, 26 Март, 2019 20:30

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 640

Info21 писал(а):

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

Вернуться к началу

Info21

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Вторник, 26 Март, 2019 21:27

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва

Artyemov писал(а):

Info21 писал(а):

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

С чего это?

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

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

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

Вернуться к началу

Валерий Лаптев

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Четверг, 28 Март, 2019 12:07

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань

Info21 писал(а):

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

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

Вернуться к началу

Info21

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Четверг, 28 Март, 2019 14:34

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва

Валерий Лаптев писал(а):

Info21 писал(а):

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

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

Потомки будут изумляться взрыву мракобесия в начале аритмоцена.

Вернуться к началу

Artyemov

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Четверг, 28 Март, 2019 20:07

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 640

Info21 писал(а):

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

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

Вернуться к началу

Rifat

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Четверг, 21 Май, 2020 12:46

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 989
Откуда: Казань

Речь заходила про 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

Заголовок сообщения: Re: Оберон-07: вопросы реализации

Добавлено: Четверг, 11 Июнь, 2020 21:43

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660

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

[ Сообщений: 100 ]

На страницу Пред. 1, 2, 3, 4, 5

Список форумов » Оберон-технологии: языки, компиляторы, системы » Oberon-07 (Revised Oberon)

Часовой пояс: UTC + 3 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 27

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения