Ответ на »сообщение 3754« (pepper)
___________________________

Ответ на »сообщение 3746« (Илья Ермаков)
___________________________
если просто запретить менять входные параметры, а результат возвращать как результат. Что мы и имеем в чистых функциональных языках.
А у нас - не чистый функциональный язык с иными подходами.
Если бы да кабы..
Возвращая результат "как результат" будем иметь либо а) оверхед на копирование, если возвращаем структуру данных статически б) либо оверхед на динамику, если будем использовать только динамические структуры.
Запрещая менять входные параметры, теряем возможность полиморфной передачи на изменение расширяемых типов данных. В частности, станет невозможной Generic Bus.

Если на минутку представить, что оберон не идеален,
Идеальность бывает разной. Можно говорить об идеальности как об абсолютном превосходстве - такие разговоры бессмысленны, и, как можно заметить, мы их никогда не вели.
А можно говорить об "идеальности в себе" как доведенности некоторого инструмента до той "вылизанности", когда особо нечего ни прибавить, ни убавить... Как идеально отлаженный хронометр, в который нечего лезть с молотком и зубилом... И добавлять в хронометр шестерни от типовых "будильников" мейнстрима тоже вряд ли стоит.

А сарказм Ваш неуместен. Как показывают многие примеры, Оберон очень хорош для системного программирования. Заглядывая в будущее, рискну сказать, что из на сегодня существующих подходов к системному программированию высокоуровневый подход Оберона - самый перспективный (время покажет, прав я или нет). И неспроста Керниган свой Лимбо произвел от Модулы и Оберона, а не от потомков своего раннего детища...

Ответ на »сообщение 3747« (AVC)
___________________________
>>>И операторы можно перегружать, и запись возвращать в качестве результата.
>>>Это все еще Оберон?
Обычный ETH Oberon тоже такие фокусы умеет. И  OBJECT понимает.

Ответ на »сообщение 3747« (AVC)
___________________________

Я прошу прощения.
Разбираясь с письмом читателя GeniePro, я ускакал за зайцами в красных шапочках. :)
Покрутился в WinAos, зашел в IDE, быстро набросал некий код и откомпилировал.
MODULE AlexTest;

....

END AlexTest.

AlexTest.Test

Это "работает", но вызывает столько вопросов...
И операторы можно перегружать, и запись возвращать в качестве результата.
Это все еще Оберон?
Как вы полагаете?
(Нет, я догадываюсь, что это влияние "научного" Оберона X, но речь о принципах. :) )

Перегрузки операторов нет в определении Активного Оберона. Похоже, компилятор поддерживает по умолчанию и расширение XSC. IDE ведёт некоторый предварительный анализ исходников, возможно и определяет автоматом какой компилятор вызвать. Но это предположения, нужно смотреть...

Ответ на »сообщение 3751« (Geniepro)
___________________________

Ответ на »сообщение 3746« (Илья Ермаков)
___________________________

Процедуры же возвращают результат через VAR(OUT) параметры. И не надо кричать об их "нечистоте" - их смысл кардинально отличается от смысла функциий.

Логично было бы различать процедуры и функции, как в Паскале или Ada.
Тонкий момент. Возможно, что было бы и логично...
В Паскале, однако, дальше слова FUNCTION дело не шло - компилятор не запретит заиметь побочные эффекты и VAR-параметры...

Ответ на »сообщение 3746« (Илья Ермаков)
___________________________

Процедуры же возвращают результат через VAR(OUT) параметры. И не надо кричать об их "нечистоте" - их смысл кардинально отличается от смысла функциий.

Логично было бы различать процедуры и функции, как в Паскале или Ada.

Ответ на »сообщение 3747« (AVC)
___________________________

Это "работает", но вызывает столько вопросов...
И операторы можно перегружать, и запись возвращать в качестве результата.
Это все еще Оберон?
Как вы полагаете?
(Нет, я догадываюсь, что это влияние "научного" Оберона X, но речь о принципах. :) )
Мне кажется, многие вещи из Active Oberon надо было оставлять на уровне библиотек...
Такая штука, как перегрузка операторов - это мелочь, ничего не портящая, как ничего и принципиально не добавляющая.
А вот введение в язык понятия OBJECT лично меня сильно раздражает - ломает идеологию.
Явно как и привязка активности к ООП. Привязка эксклюзивности к объекту - это понятно. Но активность/параллельность выполнения не должна быть концептуально завязана на ООП. Активный объект - это всего лишь частный случай активности.
А в более общем случае может быть как активная процедура, так и объект с несколькими активностями...
(Я вот до сих пор не знаю, что делать с Active BlackBox - сделать там модуль Ao псевдомодулем компилятора, или так и оставить в библиотеке... Буду благодарен мнениям).

Вообще говоря, Component Pascal остается гораздо более цельным и "обероновским", чем Active Oberon. Но и в нем кое-что хотелось бы видеть по-другому. В частности, наследование реализации, ООП - это можно было сделать несколько по-другому. Зачем было вводить средства, которые потом приходится рекомендовать не использовать... Зато можно было более явно поддержать конструкции межмодульной коммутации...
Из Active Oberon хотелось бы видеть DEFINITIONs - интерфейсы - и возможность их множественного имплементирования - вместо ABSTRACT RECORDs КП. Короче, получился fork, в каждом ответвлении которого введены и хорошие вещи, и не очень. Пора думать о сведении воедино? :-) С вырезанием нехорошего и объединением хорошего...

Ответ на »сообщение 3748« (Geniepro)
___________________________

Ответ на »сообщение 3744« (AVC)
___________________________

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

Мда, забавная эта WinAOS. Я пока не понял, чем она отличается от AOS, которая грузится с диска. Вроде файлы можно сохранять на диск?
Интересно, её можно использовать для создания реальных приложений?
Отличается в первую очередь тем, что это разные проекты, над которыми работают разные люди. AOS - модель выполнения языка Active Oberon. Она легла в основу OS Bluebottle (той самой, что "грузится с диска", и не только с диска).
Параллельно другие авторы (точно не помню) развивают AOS поверх Windows и других OS. Поскольку верхушка BlueBottle абстрагирована от железа, то она легко ложится и на WinAOS, и на любой другой AOS.
Однако WinAOS гораздо менее доведена до ума, чем native-вариант. Если BlueBottle можно рассматривать как экспериментальную, но рабочую вещь, пригодную для использования (если нужна "замкнутая" в себе система, например, серверная), то WinAOS пока, ИМХО, только как игрушку, полезную для проб и отработки AO-приложений.
В частности - параллельность в WinAOS во много десятков раз менее эффективна, чем в BlueBottle, поскольку эмулировать модель активных объектов поверх менеджера потоков Винды (который сам по себе весьма посредственен) - ну, сами понимаете... Более того, как я смотрел в предыдущих версиях, для синхронизации используются стандартные семафоры Винды - а это тормоз по определению (семафоры WinAPI предназначены для межпроцессной, а не межпоточной синхронизации)! В Active BlackBox я писал свою реализацию семафоров пользовательского режима, которые при тестировании в некоторых режимах показали параметры, в сотни раз лучшие, чем стандартные.
С графикой та же история - ведь не по голому железу...
Кстати, BlueBottle работает на VESA, не используя никаких современных возможностей видеокарт - при этом рисует прозрачность и эффекты пооперативнее Винды & оболочек Linux-а...

Ответ на »сообщение 3744« (AVC)
___________________________

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

Мда, забавная эта WinAOS. Я пока не понял, чем она отличается от AOS, которая грузится с диска. Вроде файлы можно сохранять на диск?
Гоняясь за этими зайцами и скелетами заметил, что нужно немедленно убирать wallpaper, иначе весь интерфейс, все кнопки уменьшаются и ничего не понятно...
Интересно, её можно использовать для создания реальных приложений?

Я прошу прощения.
Разбираясь с письмом читателя GeniePro, я ускакал за зайцами в красных шапочках. :)
Покрутился в WinAos, зашел в IDE, быстро набросал некий код и откомпилировал.

MODULE AlexTest;

IMPORT Out;

TYPE
Point* = RECORD x, y: REAL END;

PROCEDURE NewPoint(x, y: REAL): Point;
VAR pt: Point;
BEGIN
pt.x := x;
pt.y := y;
RETURN pt
END NewPoint;

PROCEDURE "+" (a, b: Point): Point;
VAR pt: Point;
BEGIN
pt.x := a.x + b.x;
pt.y := a.y + b.y;
RETURN pt
END "+";

PROCEDURE Test* ;
VAR a, b, c: Point;
BEGIN
Out.String("Hello, world!"); Out.Ln;
a := NewPoint(2, 3);
b := NewPoint(5, 7);
c := a + b;
Out.Real(c.x, 0); Out.Real(c.y, 10); Out.Ln
END Test;

END AlexTest.

AlexTest.Test

Это "работает", но вызывает столько вопросов...
И операторы можно перегружать, и запись возвращать в качестве результата.
Это все еще Оберон?
Как вы полагаете?
(Нет, я догадываюсь, что это влияние "научного" Оберона X, но речь о принципах. :) )