Автор Тема: Параметрический полиморфизм и Оберон.  (Прочитано 15301 раз)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
В общем, думая над реализацией задачки на Обероне-07 мысль вертится вокруг стандартной библиотеки, в том числе вокруг контейнеров и алгоритмов, и как следствие, постоянно бьется об отсутствие какой-либо обобщенки в Обероне-07.

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

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

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #1 : Март 31, 2011, 11:05:26 pm »
Но вообще, мне кажется, что под такую задачу синтаксис надо существенно менять. Потому как вот такая вот запись:
PROCEDURE <A> (l: List(A)) Map (p: Proc(A));
куда менее понятна и вообще громоздка нежели вот такая:
map :: (a -> b) -> [a] -> [b]
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Параметрический полиморфизм и Оберон.
« Ответ #2 : Апрель 01, 2011, 06:22:23 am »

map :: (a -> b) -> [a] -> [b]
Какой то Хаскель оголтелый.., а перегрузки не хватит?  :)

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #3 : Апрель 01, 2011, 06:55:38 am »
Но вообще, мне кажется, что под такую задачу синтаксис надо существенно менять. Потому как вот такая вот запись:
PROCEDURE <A> (l: List(A)) Map (p: Proc(A));
куда менее понятна и вообще громоздка нежели вот такая:
map :: (a -> b) -> [a] -> [b]

Можно как в окамле неизвестный тип помечать апострофом (штрихом):
PROCEDURE (l: List(`A)) Map (p: Proc(`A));
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #4 : Апрель 01, 2011, 07:06:07 am »
а перегрузки не хватит?  :)
Перегрузка -- не решение, ведь речь о том, что бы заставить один и тот же алгоритм, реализованный в виде одной процедуры, обрабатывать контейнеры с элементами разных типов.

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

Салат «рекурсия»: помидоры, огурцы, салат…

DIzer

  • Гость
Re:Параметрический полиморфизм и Оберон.
« Ответ #5 : Апрель 01, 2011, 07:53:17 am »

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

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

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

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #6 : Апрель 01, 2011, 08:13:35 am »
ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.
« Последнее редактирование: Апрель 01, 2011, 08:15:11 am от Валерий Лаптев »

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #7 : Апрель 01, 2011, 08:35:48 am »
ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.
А это уже проходили. В Аде. Часто плодить модули ради мелкой фиговины (фиговина мелкая, но используется широко и параметризуется разными типами) как-то не кошерно.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Rifat

  • Jr. Member
  • **
  • Сообщений: 62
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #8 : Апрель 01, 2011, 10:05:59 am »
В одной из статей Ершова есть следующее определение.  "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с  другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #9 : Апрель 01, 2011, 10:10:03 am »
В одной из статей Ершова есть следующее определение.  "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с  другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.
Во-первых под определение Ершова подпадают не только модули, но и функции/процедуры (внезапно, да).
Во-вторых параметризация должна быть типобезопасной.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

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

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #10 : Апрель 01, 2011, 11:31:06 am »
ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.
А это уже проходили. В Аде. Часто плодить модули ради мелкой фиговины (фиговина мелкая, но используется широко и параметризуется разными типами) как-то не кошерно.
Если используется широко, то пофигу, мелкая она или нет.
Кошерно-не кошерно - это вообще не довод. "Вам шашечки или ехать?!"(с)

DIzer

  • Гость
Re:Параметрический полиморфизм и Оберон.
« Ответ #11 : Апрель 01, 2011, 12:18:55 pm »
В одной из статей Ершова есть следующее определение.  "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с  другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.
Во-первых под определение Ершова подпадают не только модули, но и функции/процедуры (внезапно, да).
Во-вторых параметризация должна быть типобезопасной.
Давайте не скатываться на обсуждение малоактуальных для нас определений. В предыдущем топике, я постарался показать что оно малополезно, даже если подходить к нему достаточно серьезно ;), не знаю дошло или нет...  Однако, Рифат поставил проблему ЧЕТКО - вводя такие смеси  в один модуль , мы затрудняем и без того сложную разработку многокомпонентных систем. Может быть ввести новую единицу, с рабочим названием -   модуль шаболонов , и разработать для него:  1 Свойства которым он будет обладать 2 Синтаксис определений...

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Параметрический полиморфизм и Оберон.
« Ответ #12 : Апрель 01, 2011, 05:24:20 pm »
Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант), а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...

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

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

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #13 : Апрель 01, 2011, 05:44:36 pm »
Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант)

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

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

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

Не стоит перекладывать работу разработчика компилятора на плеци его пользователей.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

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

  • Jr. Member
  • **
  • Сообщений: 58
    • Просмотр профиля
Re:Параметрический полиморфизм и Оберон.
« Ответ #14 : Апрель 01, 2011, 06:14:39 pm »
Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант), а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...

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

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