Параметрический полиморфизм и Оберон.

[valexey]

В общем, думая над реализацией задачки на Обероне-07 мысль вертится вокруг стандартной библиотеки, в том числе вокруг контейнеров и алгоритмов, и как следствие, постоянно бьется об отсутствие какой-либо обобщенки в Обероне-07.

Посему предлагаю еще раз обсудить (ибо уже обсуждалось вроде бы где-то) например вот такой вариант введения параметрического полиморфизма в оберон (с поправкой на Оберон-07 конечно): http://research.microsoft.com/en-us/um/people/cszypers/pub/jmlc97.pdf

(ну и файлик приложил в аттач этот, мало ли, вдруг ссылка протухнет)

[valexey]

Но вообще, мне кажется, что под такую задачу синтаксис надо существенно менять. Потому как вот такая вот запись:

Код: [Выделить]

PROCEDURE <A> (l: List(A)) Map (p: Proc(A));
куда менее понятна и вообще громоздка нежели вот такая:

Код: [Выделить]

map :: (a -> b) -> [a] -> [b]


[DIzer]

Код: [Выделить]

map :: (a -> b) -> [a] -> [b]


Какой то Хаскель оголтелый.., а перегрузки не хватит?  

[Geniepro]

Но вообще, мне кажется, что под такую задачу синтаксис надо существенно менять. Потому как вот такая вот запись:

Код: [Выделить]

PROCEDURE <A> (l: List(A)) Map (p: Proc(A));
куда менее понятна и вообще громоздка нежели вот такая:

Код: [Выделить]

map :: (a -> b) -> [a] -> [b]


Можно как в окамле неизвестный тип помечать апострофом (штрихом):

Код: [Выделить]

PROCEDURE (l: List(`A)) Map (p: Proc(`A));


[Geniepro]

а перегрузки не хватит?  

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

При перегрузке же придётся для каждого этого типа реализовывать отдельный вариант такой процедуры, просто имена у них будут совпадать. Смысл? уж проще тогда как сейчас в обероне сделать -- без перегрузки, разные имена.

[DIzer]

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

При перегрузке же придётся для каждого этого типа реализовывать отдельный вариант такой процедуры, просто имена у них будут совпадать. Смысл? уж проще тогда как сейчас в обероне сделать -- без перегрузки, разные имена.
[/quote]
Да нет, я про задачу (не понятно зачем Алексею это нужно и про какую задачу он говорит). Хотя первое понял (по статье), а со вторым  затык.. Да  и непонятно какой Оберон
имеется ввиду - в стандарте и 07 вроде ресиверов нет (в статье вроде неявно подразумевался Оберон 2).

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

ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.

[valexey]

ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.

А это уже проходили. В Аде. Часто плодить модули ради мелкой фиговины (фиговина мелкая, но используется широко и параметризуется разными типами) как-то не кошерно.

[Rifat]

В одной из статей Ершова есть следующее определение.  "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с  другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.

[valexey]

В одной из статей Ершова есть следующее определение.  "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с  другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.

Во-первых под определение Ершова подпадают не только модули, но и функции/процедуры (внезапно, да).
Во-вторых параметризация должна быть типобезопасной.

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

ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.

А это уже проходили. В Аде. Часто плодить модули ради мелкой фиговины (фиговина мелкая, но используется широко и параметризуется разными типами) как-то не кошерно.

Если используется широко, то пофигу, мелкая она или нет.
Кошерно-не кошерно - это вообще не довод. "Вам шашечки или ехать?!"(с)

[DIzer]

В одной из статей Ершова есть следующее определение.  "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с  другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.

Во-первых под определение Ершова подпадают не только модули, но и функции/процедуры (внезапно, да).
Во-вторых параметризация должна быть типобезопасной.

Давайте не скатываться на обсуждение малоактуальных для нас определений. В предыдущем топике, я постарался показать что оно малополезно, даже если подходить к нему достаточно серьезно , не знаю дошло или нет...  Однако, Рифат поставил проблему ЧЕТКО - вводя такие смеси  в один модуль , мы затрудняем и без того сложную разработку многокомпонентных систем. Может быть ввести новую единицу, с рабочим названием -   модуль шаболонов , и разработать для него:  1 Свойства которым он будет обладать 2 Синтаксис определений...

[Илья Ермаков]

Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант), а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...

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

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

[Geniepro]

Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант)

копипаст -- зло, как поддерживать в актуальном состоянии изменения во всех скопипастенных местах?

, а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...

Это из пушки по воробьям -- для простой в принципе вещи делать целый инструментарий, которым всё равно никто не будет пользоваться ибо лениво. Слишком сложно и неудобно...

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

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

Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант), а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...

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

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

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