Oberon space
General Category => Общий раздел => Тема начата: valexey от Март 31, 2011, 10:19:23 pm
-
В общем, думая над реализацией задачки на Обероне-07 мысль вертится вокруг стандартной библиотеки, в том числе вокруг контейнеров и алгоритмов, и как следствие, постоянно бьется об отсутствие какой-либо обобщенки в Обероне-07.
Посему предлагаю еще раз обсудить (ибо уже обсуждалось вроде бы где-то) например вот такой вариант введения параметрического полиморфизма в оберон (с поправкой на Оберон-07 конечно): http://research.microsoft.com/en-us/um/people/cszypers/pub/jmlc97.pdf
(ну и файлик приложил в аттач этот, мало ли, вдруг ссылка протухнет)
-
Но вообще, мне кажется, что под такую задачу синтаксис надо существенно менять. Потому как вот такая вот запись:
PROCEDURE <A> (l: List(A)) Map (p: Proc(A));
куда менее понятна и вообще громоздка нежели вот такая:
map :: (a -> b) -> [a] -> [b]
-
map :: (a -> b) -> [a] -> [b]
Какой то Хаскель оголтелый.., а перегрузки не хватит? :)
-
Но вообще, мне кажется, что под такую задачу синтаксис надо существенно менять. Потому как вот такая вот запись:
PROCEDURE <A> (l: List(A)) Map (p: Proc(A));
куда менее понятна и вообще громоздка нежели вот такая:
map :: (a -> b) -> [a] -> [b]
Можно как в окамле неизвестный тип помечать апострофом (штрихом):
PROCEDURE (l: List(`A)) Map (p: Proc(`A));
-
а перегрузки не хватит? :)
Перегрузка -- не решение, ведь речь о том, что бы заставить один и тот же алгоритм, реализованный в виде одной процедуры, обрабатывать контейнеры с элементами разных типов.
При перегрузке же придётся для каждого этого типа реализовывать отдельный вариант такой процедуры, просто имена у них будут совпадать. Смысл? уж проще тогда как сейчас в обероне сделать -- без перегрузки, разные имена.
-
Перегрузка -- не решение, ведь речь о том, что бы заставить один и тот же алгоритм, реализованный в виде одной процедуры, обрабатывать контейнеры с элементами разных типов.
При перегрузке же придётся для каждого этого типа реализовывать отдельный вариант такой процедуры, просто имена у них будут совпадать. Смысл? уж проще тогда как сейчас в обероне сделать -- без перегрузки, разные имена.
[/quote]
Да нет, я про задачу (не понятно зачем Алексею это нужно и про какую задачу он говорит). Хотя первое понял (по статье), а со вторым затык.. Да и непонятно какой Оберон
имеется ввиду - в стандарте и 07 вроде ресиверов нет (в статье вроде неявно подразумевался Оберон 2).
-
ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.
-
ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.
А это уже проходили. В Аде. Часто плодить модули ради мелкой фиговины (фиговина мелкая, но используется широко и параметризуется разными типами) как-то не кошерно.
-
В одной из статей Ершова есть следующее определение. "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.
-
В одной из статей Ершова есть следующее определение. "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.
Во-первых под определение Ершова подпадают не только модули, но и функции/процедуры (внезапно, да).
Во-вторых параметризация должна быть типобезопасной.
-
ИМХО шаблоны - только на уровне модулей. Ибо модуль органично смотрится как реализация контейнера. Отдельные процедуры в нешаблонных модулях - не стоят гемора.
И кстати, это не потребует кардинальных изменений синтаксиса. Только заголовок шаблона для модуля и синтаксис имени модуля-шаблона в операторе import.
А это уже проходили. В Аде. Часто плодить модули ради мелкой фиговины (фиговина мелкая, но используется широко и параметризуется разными типами) как-то не кошерно.
Если используется широко, то пофигу, мелкая она или нет.
Кошерно-не кошерно - это вообще не довод. "Вам шашечки или ехать?!"(с)
-
В одной из статей Ершова есть следующее определение. "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.
Во-первых под определение Ершова подпадают не только модули, но и функции/процедуры (внезапно, да).
Во-вторых параметризация должна быть типобезопасной.
Давайте не скатываться на обсуждение малоактуальных для нас определений. В предыдущем топике, я постарался показать что оно малополезно, даже если подходить к нему достаточно серьезно ;), не знаю дошло или нет... Однако, Рифат поставил проблему ЧЕТКО - вводя такие смеси в один модуль , мы затрудняем и без того сложную разработку многокомпонентных систем. Может быть ввести новую единицу, с рабочим названием - модуль шаболонов , и разработать для него: 1 Свойства которым он будет обладать 2 Синтаксис определений...
-
Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант), а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...
Даже в банальном копипасте и то часто вижу плюс - не плодить зависимостей на основании какого-то мелкого алгоритма, который сегодня одинаков, а завтра может поменяться. Иногда просто, чтобы не связывать между собой подсистемы, делаю копию.
Такие алгоритмы - они как "элементная база", "спаяли" с его использованием, и менять нет нужды. Это не компонент в смысле компонентного программирования. Это... элемент разработки, что ли...
-
Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант)
копипаст -- зло, как поддерживать в актуальном состоянии изменения во всех скопипастенных местах?
, а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...
Это из пушки по воробьям -- для простой в принципе вещи делать целый инструментарий, которым всё равно никто не будет пользоваться ибо лениво. Слишком сложно и неудобно...
Не стоит перекладывать работу разработчика компилятора на плеци его пользователей.
-
Если "мелкая фиговина, повторяющаяся часто в применении к различным типам", то я за копипаст (плохо, но как промежуточный вариант), а вообще - за решение этого на уровне инструмента разработки, когда это как-то встраивается по образцу, что ли...
Даже в банальном копипасте и то часто вижу плюс - не плодить зависимостей на основании какого-то мелкого алгоритма, который сегодня одинаков, а завтра может поменяться. Иногда просто, чтобы не связывать между собой подсистемы, делаю копию.
Такие алгоритмы - они как "элементная база", "спаяли" с его использованием, и менять нет нужды. Это не компонент в смысле компонентного программирования. Это... элемент разработки, что ли...
Очень важное понятие - элемент разработки.
Надо собирать каталог. Вон паттерны собрали - получился хороший инструментальный "чемоданчик". Надо и "элементы разработки" аналогично собрать и проанализировать. Тонгда станет понятно, где шаблон полезен, а где можно обойтись.
-
копипаст -- зло, как поддерживать в актуальном состоянии изменения во всех скопипастенных местах?
Вот тут мы и подходим к ключевому моменту - А ЗАЧЕМ? И вот здесь критерий отличия компонента в смысле компонентного программирования от элемента разработки.
Зачем Вам синхронно менять какой-нибудь алгоритм сортировки или поиска, или ещё чего-нибудь? Разумеется, мы предполагаем, что он был правилен (такие алгоритмы просто недопустимо писать неправильно).
Вы можете захотеть поменять его в одном из приложений-компонентов, под требования этого компонента. И он тут же перестанет быть таким же, как в других местах.
Это такая же разница, как между заменой электронного модуля на более совершенный или между идеей заменить все микросхемы в модуле, потому что появились более совершенные - второе просто не придёт в голову, да и невозможно.
Более того, такая невозможность - благо, если некоторый общего назначения алгоритм работает, зачем моей программе зависеть от каких-то его дальнейших изменений-усовершествований, мало ли.