Re[26]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 18.02.05 16:00
Оценка: +2
AVC пишет:

> C>операции над таким составным множеством?

>
> Примерно так:
>
>DEFINITION BitSets;
>
>TYPE
> BitSet* = RECORD
> size-: INTEGER; (** число элементов в битовом множестве *)
> PROCEDURE (VAR set: BitSet) Init*(size: INTEGER);
> PROCEDURE (VAR set: BitSet) Incl*(bit: INTEGER);
> PROCEDURE (VAR set: BitSet) Excl*(bit: INTEGER);
> END;
>
>END BitSets.
>
И чем это отличается от std::set, кроме отсутствия поддержки стандартных
алгоритмов, итераторов, и удобного доступа?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[25]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 18.02.05 16:10
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Здравствуйте, Сергей Губанов, Вы писали:


СГ>>Ни что мешает сделать так:

СГ>>
СГ>>TYPE
СГ>>  BigSet = ARRAY 1000000 OF SET;
СГ>>

AVC>Только еще бы "завернуть" в класс.

Можно, но надо-ли?
PROCEDURE Incl(VAR s: ARRAY OF SET; Element: INTEGER);
PROCEDURE Excl(VAR s: ARRAY OF SET; Element: INTEGER);

PROCEDURE Included(VAR s: ARRAY OF SET; Element: INTEGER): BOOLEAN;

PROCEDURE Union(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
PROCEDURE Difference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
PROCEDURE Intersection(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
PROCEDURE SymmetricDifference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 18.02.05 16:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>И чем это отличается от std::set, кроме отсутствия поддержки стандартных

C>алгоритмов, итераторов, и удобного доступа?

Ну ты прямо хочешь, чтобы AVC тебе за полчаса нарожал весь объём библиотеки, эквивалентный STL?
Перекуём баги на фичи!
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 18.02.05 16:22
Оценка:
Кодт пишет:

> C>И чем это отличается от std::set, кроме отсутствия поддержки

> стандартных
> C>алгоритмов, итераторов, и удобного доступа?
> Ну ты прямо хочешь, чтобы AVC тебе за полчаса нарожал весь объём
> библиотеки, эквивалентный STL?

Я бы не отказался и от "пошел ты на http://www...."

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[29]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 18.02.05 16:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Я бы не отказался и от "пошел ты на http://www...."


Ну, уговорил...

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[26]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 18.02.05 16:31
Оценка: 1 (1) +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Можно, но надо-ли?


Я уже говорил, что операции над голыми типами — это возможность накосячить.
Пример с данным кодом:
TYPE LongSet = ARRAY OF SET;
PROCEDURE SetAdd(VAR dst: LongSet; x: INTEGER);
PROCEDURE SetUnion(a,b: LongSet; VAR dst: LongSet);
PROCEDURE SetCross(a,b: LongSet; VAR dst: LongSet);
PROCEDURE IsEmptySet(a: LongSet): BOOLEAN; (* проверяет, что вектор заполнен пустыми множествами *)
PROCEDURE CompactSet(VAR dst: LongSet); (* отбрасывает хвост массива, заполненный пустыми множествами *)
.....

TYPE StackOfSets = ARRAY OF SET; (* другой логический смысл такого же контейнера *)
PROCEDURE PushSetIntoStack(VAR stack: StackOfSets; item: SET);
PROCEDURE PopSetFromStack(VAR stack: StackOfSets; VAR item: SET);
PROCEDURE IsEmptyStack(stack: StackOfSets): BOOLEAN; (* проверяет, что размер равен нулю *)
.....

VAR x: LongSet;
    y: StackOfSets;
BEGIN
  ...
  PushSetIntoStack(x, {0,1,2} ); (* Перепутали x и y. Компилятор сожрал. *)
  ...
END;


В некоторых, критичных, местах бывает полезно даже числовые типы заворачивать в классы, чтоб с размерностями проблем не было.
(В С++ это проще, там есть перегрузка операторов; но это так, к слову).
Перекуём баги на фичи!
Re[26]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 18.02.05 16:41
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

AVC>>Только еще бы "завернуть" в класс.

СГ>Можно, но надо-ли?
СГ>
СГ>PROCEDURE Incl(VAR s: ARRAY OF SET; Element: INTEGER);
СГ>PROCEDURE Excl(VAR s: ARRAY OF SET; Element: INTEGER);

СГ>PROCEDURE Included(VAR s: ARRAY OF SET; Element: INTEGER): BOOLEAN;

СГ>PROCEDURE Union(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
СГ>PROCEDURE Difference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
СГ>PROCEDURE Intersection(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
СГ>PROCEDURE SymmetricDifference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
СГ>


Думаю, что надо (в общем случае).
Вот какая проблема приходит в голову первой.
Операции Union, Difference, Intersection и SymmetricDifference принимают в качестве аргументов открытые массивы.
Следовательно, размерности входных параметров s1 и s2 могут не совпадать.
Какой размерности должен быть выходной массив s3?
Здесь можно принять некое соглашение. Например, для операции Union размерность выходного массива совпадает с размерностью наибольшего входного, а для операции Intersection — наименьшего.
Но может оказаться так, что размерность s3 не совпадает с требуемой. Чтобы совсем все было плохо, пусть она будет меньше, чем надо. Здесь бы взять и удлинить выходной массив. Но для OUT s3: ARRAY OF SET это невозможно. Требуется как минимум указатель. А еще лучше — класс (= обероновская запись), позволяющий скрыть все детали и поступать гибко.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 18.02.05 16:48
Оценка: :)
Здравствуйте, Кодт, Вы писали:

К>Ну ты прямо хочешь, чтобы AVC тебе за полчаса нарожал весь объём библиотеки, эквивалентный STL?


Вот-вот, все они тут хотят моей смерти.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[33]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 18.02.05 17:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Это отдельный пункт — почему в таких важных супербиблиотеках нет

>> большой практической необходимости?
C>Speak for yourself... У меня практическая необходимость уже где для 40%
C>буста

Это уже зависимость.

C>А причем здесь буст? Тот же новый XDS будет ничуть ни хуже жрать место

C>на диске.

Обероновское ПО как раз очень компактно.
Так как исключается дублирование кода.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[34]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 18.02.05 17:31
Оценка:
AVC пишет:

> C>А причем здесь буст? Тот же новый XDS будет ничуть ни хуже жрать место

> C>на диске.
> Обероновское ПО как раз очень компактно.
> Так как исключается дублирование кода.

Ну так надо поступать по образу и подобию libxml — ядро на С с
биндингами во все возможные языки. И всего 1 dll'ка на диске.

Ну и COM-объекты еще есть...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 18.02.05 17:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>И чем это отличается от std::set, кроме отсутствия поддержки стандартных

C>алгоритмов, итераторов, и удобного доступа?

Нет, ну ей Богу, такое чувство, что Си++ у Вас — единственный язык.
На всякий случай, сообщаю, что во многих языках есть классы.
При этом языки различаются способами, как реализуются в них классы (и не только).
Что касается сочетаемости std::set с алгоритмами и итераторами, то она зависит от того, как спроектирована библиотека в целом.
Я же привел в качестве примера (как можно реализовать BitSet в виде класса) совсем простой класс. Этого вполне достаточно, чтобы проиллюстрировать ту мысль, но не более того.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 18.02.05 22:57
Оценка: 21 (1)
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Сергей Губанов, Вы писали:


СГ>>Можно, но надо-ли?


К>Я уже говорил, что операции над голыми типами — это возможность накосячить.

К>Пример с данным кодом:
К>
К>TYPE LongSet = ARRAY OF SET;
К>PROCEDURE SetAdd(VAR dst: LongSet; x: INTEGER);
К>PROCEDURE SetUnion(a,b: LongSet; VAR dst: LongSet);
К>PROCEDURE SetCross(a,b: LongSet; VAR dst: LongSet);
К>PROCEDURE IsEmptySet(a: LongSet): BOOLEAN; (* проверяет, что вектор заполнен пустыми множествами *)
К>PROCEDURE CompactSet(VAR dst: LongSet); (* отбрасывает хвост массива, заполненный пустыми множествами *)
К>.....

К>TYPE StackOfSets = ARRAY OF SET; (* другой логический смысл такого же контейнера *)
К>PROCEDURE PushSetIntoStack(VAR stack: StackOfSets; item: SET);
К>PROCEDURE PopSetFromStack(VAR stack: StackOfSets; VAR item: SET);
К>PROCEDURE IsEmptyStack(stack: StackOfSets): BOOLEAN; (* проверяет, что размер равен нулю *)
К>.....

К>VAR x: LongSet;
К>    y: StackOfSets;
К>BEGIN
К>  ...
К>  PushSetIntoStack(x, {0,1,2} ); (* Перепутали x и y. Компилятор сожрал. *)
К>  ...
К>END;
К>


Мысль понятна и бесспорно верна.
(Вообще, я замечаю, что как только от плюсов и минусов отдельных "фич" того или иного языка мы переходим к абстрактным типам, то согласны практически все. Это дает надежду, что существуют-таки общие для всех нас принципы.)
Кроме того, приятно отметить, что критический пример написан на самом что ни на есть Обероне и практически без помарок. (Самую малось его подпортил этот безымянный END; в конце. )

К>В некоторых, критичных, местах бывает полезно даже числовые типы заворачивать в классы, чтоб с размерностями проблем не было.

К>(В С++ это проще, там есть перегрузка операторов; но это так, к слову).

Вообще-то существуют реализации Оберона с перегрузкой операторов.
Я это и раньше говорил, но, чтобы не быть голословным, приведу пример.
Для этого мне не надо далеко ходить. Это современное состояние самого ETH Оберона.

B.3 Abstract Operators

Oberon supports the definition of abstract data types but lacks a corresponding support for the definition of abstract infix operators. This is unfortunate, because the ordinary procedural notation is clumsy in combination with nesting. Therefore, we allow the overloading of operators by redefinition. Syntactically, a redefinition is identical to a procedure declaration, where the procedure name is replaced by the operator symbol, for example by "*". It should be noted that the identification of operators in the context of an expression is done at compile time, that is, it does not depend on the dynamic types of the operands. The identification algorithm is: (a) identify all matching declarations, i.e. declarations whose formal parameter types are (direct or indirect) base types of the corresponding actual parameter types and (b) select the matching operator that lexicographically minimizes the "type-distance vector", where the components of this vector are the level differences of actual type and corresponding formal type from left to right. Typically, Oberon does not allow structured types for function return values. In the interest of nestable abstract operators, this restriction is removed in our extended compiler.

Syntax:

ProcDecl = PROCEDURE {ProcTags} (IdentDef | '"'OpDef'"' ["*"])
[FormalPars] ";" Scope (ident | '"'OpDef'"').
OpDef = Relation | AddOp | MulOp | "~".
Relation = "=" | "#" | "<" | "<=" | ">" | ">=" | IN.
AddOp = "+" | "-" | OR.
MulOp = " * " | "/" | DIV | MOD | "&".

Example:

TYPE
A = RECORD ... END;
B = RECORD ... END;
A1 = RECORD (A) ... END;
B1 = RECORD (B) ... END;

PROCEDURE "*" (a: A; b: B): A;
BEGIN ... (* implementation 1 *)
END "*";

PROCEDURE "*" (a: A1; b: B): B1;
BEGIN ... (* implementation 2 *)
END "*";

PROCEDURE "*" (a: A1; b: B1): B;
BEGIN ... (* implementation 3 *)
END "*";

VAR a: A; b: B; a1: A1; b1: B1;

a*b identifies implementation 1
a1*b identifies implementation 2
a*b1 identifies implementation 1
a1*b1 identifies implementation 3
(a*b)*b identifies implementation 1 twice
a1*(a1*b1) identifies implementations 3 and 2

В принципе, я почти на каждую интересную возможность Си++ мог бы отвечать: это есть и в Обероне.
Есть даже Обероны с шаблонами (как правило этакие "кросс-Обероны" с компиляцией в Си/Си++).
Но так как этих возможностей нет в стандарте Оберона (Oakwood guidelines), то я так не отвечаю, а пытаюсь понять, почему этого нет в стандарте.
Возможно, одна из причин в том, что оберонщики стремятся сохранить свой язык маленьким (минимализм).
(Для Си, например, священной коровой является свобода программиста.)
Особо меня интересует возможность использования шаблонов/дженериков в Обероне, чтобы, например, избежать ситуации безтиповых универсальных контейнеров (как в Java).
Объяснение отсутствию в Обероне шаблонов в духе Си++ (template) я нахожу в том, что они противоречат раздельной (separate) компиляции.
Дженерики, думается, в Обероне вполне возможны. Ведь именно в Обероне стали использовать промежуточный код для переноса модулей между разными системами. Так что в .NET Оберон несомненно впишется. Не зря, наверное, Microsoft финансирует проект Zonnon. (А Intel, к слову, участвует в образовательном проекте Информатика-21, о котором говорил Сергей.)
Но меня сейчас интересует "вырожденный" случай.
Предположим, я не хочу напрягаться с JIT-компиляцией, а только хочу обеспечить типобезопасность использования универсальных контейнеров. Для простоты будем полагать, что в контейнеры помещаются только указательные типы. (Во многих языках и выбора-то нет, в той же Java.)
В качестве примера рассмотрим список.
MODULE Lists;
TYPE
  List = POINTER TO ListNode;
  ListNode(T) = RECORD
    data: T;
    next, prev: List;
  END;
А где-то в прикладном модуле можно было бы написать так:
TYPE
  Foo = POINTER TO FooDesc;
  FooDesc = RECORD ... END;
VAR
  FooList: Lists.List(Foo);
Я, конечно, привожу только набросок, в нем могут быть какие-то несогласованности.
Каковы, ИМХО, существенные моменты?
1) Нет никакого противоречия с раздельной компиляцией.
Модуль Lists может спокойно пребывать в виде объектного кода.
Для него T — это всего лишь PTR (как в ETH Oberon) или ANYPTR (как в BlackBox).
Если требуется что-то иное (не PTR), можно было бы писать что-то вроде
ListNode(T: NeededType) = RECORD ... END;
чтобы обозначить, что элементом может быть только NeededType или его потомки.
2) Вся "нагрузка" ложится на компиляцию клиентского модуля.
Но сводится она только к статическому контролю типов типов и, возможно, автоматической вставке в отдельные места type guard.
3) Как мне кажется, к большому усложнению компилятора это не должно привести.
Так что он останется вполне в рамках минимализма.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 19.02.05 04:39
Оценка:
AVC пишет:

> C>И чем это отличается от std::set, кроме отсутствия поддержки

> стандартных
> C>алгоритмов, итераторов, и удобного доступа?
> Нет, ну ей Богу, такое чувство, что Си++ у Вас — единственный язык.

Нет, у меня еще есть Java, C# и даже VBA.

> На всякий случай, сообщаю, что *во многих* языках есть классы.

> При этом языки различаются способами, *как* реализуются в них классы
> (и не только).

Я не спорю, коллекции можно реализовать вполне нормально (java.util.* —
этому пример), но при этом потеряем статическую типизацию. И что самое
важное, все дополнительные возможности языка Oberon так же пойдут лесом.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[29]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 20.02.05 00:05
Оценка: 48 (2)
Здравствуйте, Cyberax, Вы писали:

C>Я не спорю, коллекции можно реализовать вполне нормально (java.util.* —

C>этому пример), но при этом потеряем статическую типизацию. И что самое
C>важное, все дополнительные возможности языка Oberon так же пойдут лесом.

Внесу ясность.
Я за статическую типизацию.
У меня привычки Си++ного программиста, и мне статической типизации в Обероне не хватает. (Я признавал это с самого начала.)
Поэтому я и думаю, как бы добавить эту фичу в Оберон минимальной ценой.
Но давайте посмотрим на это с другой стороны. Хотя бы на минуту.
На этих (возможно, многих раздражающих) топиках об Обероне обсуждались две темы: язык Оберон и ОС Оберон.
Так вот у каждого из них нашлось ровно по одному существенному недостатку.
В ОС Оберон сомнительна та особенность, что каждый модуль представлен в оперативной память единственной копией.
Проблема связана со статическими переменными при вытесняющей многозадачности.
Если мы должны были убить процесс, то что делать с переменными модуля (локальные переменные процесса живут в стеке и регистрах, с ними проблем нет) после убийства процесса? А если они были "испорчены" плохим процессом?
В качестве (временного) решения я предложил грузить сегмент данных прикладных модулей заново для каждого нового процесса. (Модули ядра ОС по прежнему грузятся в память однократно.)
В таком случае проблема статических переменных решается автоматически (они убиваются системой вместе с "провинившимся" процессом), но у нас остается единое адресное пространство.
Что касается языка Оберон, его единственным недостатком является отсутствие средств обобщенного программирования.
Что, в принципе, легко исправляется. В предыдущем посте я попытался предложить "минималистский" вариант решения этой задачи. (Могут быть и другие варианты.)
Замечу, что практически все интересные новшества в ЯП возникают именно в паскалеподобных языках.
ИМХО, исправить язык, у которого есть один (хотя и существенный) недостаток, гораздо проще, чем пытаться исправить язык, у которого недостатков много. (Пусть даже они иногда мелкие, но, к сожалению, заложены в самом основании языка. Как, например, адресная арифметика и неопределенность природы указателей в Си++.)
Кстати, все те достоинства, которыми похваляется язык Си++, давно не новость в мире языков программирования.
Вот у меня на полке стоит старая уже книжка П.Вегнера "Язык програмирования АДА". Издана в 1980, переведена у нас в 1983.
Здесь и значения по умолчанию, и перегрузка операторов, и шаблоны. Хоть STL пиши!
Вот пример перегрузки операторов:
function "+" (x,y: COMPLEX) return COMPLEX is
begin
  return (x.RE+y.RE, x.IM+y.IM);
end;
А вот пример обобщенной процедуры
generic (type T)
procedure SWAP (x,y: in out T) is
  temp: T;
begin
  temp := x;
  x := y;
  y := temp;
end SWAP;
и ее конкретизации
procedure SWAP_INT is new SWAP(INTEGER);
procedure SWAP_VECT is new SWAP(VECTOR);
Есть и родовые пакеты (модули).Например:
generic (type T; SIZE: INTEGER := 100)
package SYMTAB is ...
и т.д.
В Си++ интересен не столько сам язык, а появившиеся за последнее время новые идиомы (те же умные указатели и т.п.)

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: Трурль  
Дата: 21.02.05 06:10
Оценка: 30 (2)
Здравствуйте, AVC, Вы писали:


AVC>В качестве примера рассмотрим список.
MODULE Lists;
AVC>TYPE
AVC>  List = POINTER TO ListNode;
AVC>  ListNode(T) = RECORD
AVC>    data: T;
AVC>    next, prev: List;
AVC>  END;
А где-то в прикладном модуле можно было бы написать так:
TYPE
AVC>  Foo = POINTER TO FooDesc;
AVC>  FooDesc = RECORD ... END;
AVC>VAR
AVC>  FooList: Lists.List(Foo);
Я, конечно, привожу только набросок, в нем могут быть какие-то несогласованности.


А Вы не читали Paul Roe and Clemens Szyperski "Lightweight Parametric Polymorphism for Oberon"?

TYPE 
  Ptr(A) = POINTER TO A;
  List(A) = Ptr(ListDesc(A));
  ListDesc(A) = RECORD elem: Ptr(A); next: List(A) END;
Re[29]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 21.02.05 11:50
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>А Вы не читали Paul Roe and Clemens Szyperski "Lightweight Parametric Polymorphism for Oberon"?


Т>
Т>TYPE 
Т>  Ptr(A) = POINTER TO A;
Т>  List(A) = Ptr(ListDesc(A));
Т>  ListDesc(A) = RECORD elem: Ptr(A); next: List(A) END;
Т>


Увы, пока не читал.
Но теперь я знаю об этой статье и сегодня же прочту (уже скачал). Спасибо!
Ясно было, что отсутствие в Обероне такой важной фичи не могло остаться без внимания.
Я предполагал, что этот вопрос как-то уже решался, но не знал кем, где и когда.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[30]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 21.02.05 12:10
Оценка:
Здравствуйте, AVC, Вы писали:

Обрадованный сообщением о применимости обобщенных типов к Оберону, нашел еще один пример (из инфы о компиляторе oo2c):
http://cvs.sourceforge.net/viewcvs.py/*checkout*/ooc/ooc2/doc/from-v1-to-v2/oo2c-v2.html?rev=1.2#SEC19

A parametric type can be seen as a type definition with a certain degree of freedom. The freedom comes in form of type parameters acting as placeholders for type arguments that are provided when the parametric type is used in a particular context. There are two restrictions on type parameters and type arguments: the parameter must be based on a record pointer, and the argument must be an extension of the parameter's base type.

Take for example the type `ArrayList'. The element type of the list can be any type derived from `Object', like `MyElementType', which is provided when creating an `ArrayList' variable:

TYPE
ArrayList*(E: Object.Object) = POINTER TO ArrayListDesc(E);
ArrayListDesc*(E: Object.Object) = RECORD
...
END;
...
VAR myList: ArrayList(MyElementType);


The compiler statically detects any uses of `myList' or of its methods that are incompatible with the declared element type `MyElementType'.

Практически один в один! Я и раньше предполагал, что иногда занимаюсь изобретением велосипедов.
Но уже радует, что не вечных двигателей!

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[30]: Спасибо за информацию!
От: AVC Россия  
Дата: 21.02.05 13:40
Оценка:
AVC>Здравствуйте, Трурль, Вы писали:

Т>>А Вы не читали Paul Roe and Clemens Szyperski "Lightweight Parametric Polymorphism for Oberon"?


Прочитал.
Extended Oberon — именно, то я хотел предложить. (Только у меня это были непроработанные мысли.)
Достигнуты именно те цели, к которым я хотел приплыть:
— нет никакой дополнительной нагрузки на рантайм;
— используется единственный обобщенный код, который может быть представлен в объектном коде (например, в виде DLL).
И т.д.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 21.02.05 13:41
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Но может оказаться так, что размерность s3 не совпадает с требуемой. Чтобы совсем все было плохо, пусть она будет меньше, чем надо.


Будет System trap — precondition failed.

Впрочем, я с Вами согласен. Поверх этих процедур можно навесить ООП.
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 21.02.05 14:13
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

AVC>>Но может оказаться так, что размерность s3 не совпадает с требуемой. Чтобы совсем все было плохо, пусть она будет меньше, чем надо.

СГ>Будет System trap — precondition failed.
СГ>Впрочем, я с Вами согласен. Поверх этих процедур можно навесить ООП.

Главное, это позволит менять реализацию АТД.
В принципе, предложенный Вами вариант (ARRAY OF SET) вполне пригоден в некоторых случаях. Например, иногда требуются множества без поддержки операций объединения, пересечения и т.п. (В книге Ахо, Ульмана и Хопкрофта "Структуры данных и алгоритмы" они называются "словарями" (Dictionary).)
Но остаются два дефекта:
1) клиентский код жестко привязывается к реализации таких множеств, и ее уже нельзя будет поменять;
2) компилятор не может различить разные типы, имеющие в основе реализации одну структуру данных (такой пример приводил Кодт).

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.