Ответ на »сообщение 5845« (Антон Григорьев)
___________________________
Вам придётся писать две функции.
Боюсь, что больше :).
Для простых типов понятие больше/меньше очевидно.
Для сложных возможны варианты.
Придется указывать, по какому критерию сортировать.
Т.е. опять явно писать процедуру сравнения.

С математической точки зрения, задавая тип дпнных мы описываем множество возможных значений.
Это множество может быть неупорядоченным, упорядоченным и (кто нибудь знает точный термин?) многократно упорядоченным.  Все ваши рассуждения относятся только к простым упорядоченным множествам которым соответствуют только числовые типы. Даже для строковых переменных возможны варианты упорядочивания.

Ответ на »сообщение 5832« (Сергей Перовский)
___________________________

Так "любого типа" или "для которых определены"?
callback-функции и являются тем самым определением операции сравнения без которой сортировка невозможна.
Или речь идет обо всех стандартных типах?

"любого типа, для которого определены".

Я согласен с тем, что callback-функция в каждом отдельно взятом случае эквивалентна определению операции сравнения. Но представьте, что у вас две библиотеки - одна экспортирует функцию для поиска наибольшего элемента в массиве, а другая - для сортировки массива. И авторы этих библиотек для функций сравнения определили разные прототипы. Вам придётся писать две функции. А если есть шаблон, который использует операцию сравнения, то сколько бы разных библиотек не делали свои шаблоны, функцию сравнения вам придётся писать только один раз.

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

Пробуем изменять какую-то из характеристик языка (на алгоритмическом и "типоданновом" уровне) огульным добавлением чего-то, что есть в других языках. Получаем немедленное ухудшение другой характеристики из этой четвёрки. Отсюда заключаем, что Обероны попадают в окрестность оптимума по этим параметрам.

Например добавим а Оберон константы для массивов и записей. Какие характеристики это ухудшит?

Ответ на »сообщение 5841« (Сергей Перовский)
___________________________

Ответ на »сообщение 5838« (Илья Ермаков)
___________________________
Эта область, в которой невозможно улучшить однин критерий не ухудшив другой называется множеством Паретто :)

Да, вспоминается что-то такое красивое с лекций по методам оптимизации, сданное на 4 курсе и забытое за неиспользованием :-)

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

>>>Хотелось бы просто безтиповый VAR, чтобы затем можно было с ним через метаданные работать. И безопасности/герметичности это никак не нарушит, т.к. без средств SYSTEM всё равно ничего вредного с этим параметром не сделаешь.

В принципе, такое расширение кажется сравнительно несложным: передавать в процедуру вместе с переменной ее дескриптор типа (определив дескрипторы типа для базовых типов).
А как использовать эту переменную?
Если через type-guard

i(INTEGER)

то как "обобщать" код?

Ответ на »сообщение 5838« (Илья Ермаков)
___________________________
Пробуем изменять какую-то из характеристик языка (на алгоритмическом и "типоданновом" уровне) огульным добавлением чего-то, что есть в других языках. Получаем немедленное ухудшение другой характеристики из этой четвёрки. Отсюда заключаем, что Обероны попадают в окрестность оптимума по этим параметрам.
Эта область, в которой невозможно улучшить однин критерий не ухудшив другой называется множеством Паретто :)
И, как правило, это не "окресность", а очень большое множество.
Если мы имеем дело с "хорошим" Паретто, это обычно значит, что мы не учли какой то важный криткрий.
Так что большинство языков попадут в это множество - по каким то критериям они будут уступать Оберону, по каким то превосходить. Это и есть самое интересное.

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

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

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

А велика ли потребность в map/reduce?
Разве обычные for или while не решают задачу прохода по массиву?

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

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

Ответ на »сообщение 5825« (Антон Григорьев)
___________________________

Ответ на »сообщение 5824« (AVC)
___________________________
Что-то мне кажется, сортировка строк и сортировка целых чисел суть разные вещи. Тем более, если "любой элемент" является записью, в которой есть и числа, и строки. Думаю, у каждого обобщения есть предел, внутри которого, скажем, метаинформация о типах сильно помогает.
Вот что хотелось бы, так это иметь гиперполиморфный ссылочный параметр. Указательный есть - ANYPTR. Хотелось бы просто безтиповый VAR, чтобы затем можно было с ним через метаданные работать. И безопасности/герметичности это никак не нарушит, т.к. без средств SYSTEM всё равно ничего вредного с этим параметром не сделаешь.

Ответ на »сообщение 5830« (Сергей Перовский)
___________________________

Ответ на »сообщение 5821« (Илья Ермаков)
___________________________
К примеру, надёжность, высокоуровневость, компактность, эффективность.
Из всех этих показателей реально померить удается только компактность.
Все остальное оценивается так же субъективно.
Мы остались на уровне нравится/ненравится.
Но оценить баланс-то можно!
Пробуем изменять какую-то из характеристик языка (на алгоритмическом и "типоданновом" уровне) огульным добавлением чего-то, что есть в других языках. Получаем немедленное ухудшение другой характеристики из этой четвёрки. Отсюда заключаем, что Обероны попадают в окрестность оптимума по этим параметрам.

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

Ответ на »сообщение 5836« (AVC)
___________________________
>>> Разве обычные for или while не решают задачу прохода по массиву?
Учитывая сколько споров было по поводу вариантов этих циклов, то очевидно как-то не очень хорошо они решают эту задачу... Точнее особенности, которые необходимо учитывать при решении этой задачи.