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

Как видите, такие механизмы слишком удаляют нас от идеи простого 100%-компилируемого языка, почему и не были включены в Оберон.

Да, эти механизмы потребуют изменения системы типов Оберона.

В таких языках, как Хаскелл, Clean, O'Caml используются системы типов, основанные на так называемой системе типов Хиндли-Милнера.
В Хаскелле и Clean, кстати, эта система усовершенствована. В неё добавлены классы типов - своего рода абстрактные классы или интерфейсы.

А любопытно было бы представить себе вариант Оберона с системой типов как в Хаскелле...
Такой вариант, вероятно, и дженериков не требовал бы, да и ненамного сложнее был бы.
Зато какой выигрыш в плане сокращения повторяющегося кода!

Илья, насколько я понимаю, судьба Оберона (точнее, Компонентного Паскаля) - в Ваших руках.
Может быть Вы всё таки подумаете на досуге, как совместить с КП систему типов Хиндли-Милнера?
Только подумайте, как небольшое усложнение языка упростит его использование и надёжность!
Появится возможность автоматического вывода типов (type inference) во время компиляции!

Это будет куда больший шаг в развитии и усовершенствования Оберонов путём небольшого усложнения компилятора и небольшого замедления его работы! В конце концов, мы сейчас работаем не на 25-МГцевых процессорах!
В конце концов, нельзя же, что бы такое семейство языков застоялось и не развивалось!
Хотя в результате это уже будет другой язык... :о))
Но как Модула-2 добавила в Паскаль модули, а Оберон - расширение типов, так и этот новый язык являлся бы развитием Паскалевской линии языков...
Даже Вирт преодолевал время от времени свой консерватизм. Теперь его знамя в Ваших руках! ;о)

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

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

Хаскелл не относится к динамическим языкам. Хаскелл - язык с сильной СТАТИЧЕСКОЙ типизацией, как Оберон, например.

Рантайм в Хаскелле ничуть не жирнее, чем в Оберонах - сборщик мусора да небольшой набор стандартных функций. Размеры exe-файлов примерно совпадают с exe-файлами Компонентного Паскаля/БлекБокса, быстродействие программ - на одном уровне...

Виртуальная машина имеется в интерпретаторах Хаскелла, и некоторых псевдокомпиляторах, но основной компилятор GHC генерирует честный машинный код, насколько мне известно...
Вообще-то, если точнее, GHC генерирует код на ANSI-C, который затем передаётся стандартному компилятору GCC. Т.е. подход примерно как у версии XDS-C или у того же GNAT...


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

Не обязательно, хотя и желательно. Признаюсь, я замечал, что полиморфные функции в Хаскелле немного медленнее, чем конкретизированные.
Конечно, это недостаток, и лучше бы GHC генерировал "множество перегруженных вариантов в машинном коде, под каждый вариант вызова". Да, не всё гладко в Датском Королевстве... :о)
Тем не менее, это показывает, что в компилируемых языках вполне можно обойтись одной полиморфной функцией вместо кучи перегруженных...

Ответ на »сообщение 2028« (Jack Of Shadows)
___________________________

Делать из заточенного под императивный подход Оберона функциональный язык совершенно бессмысленно. Каждому инструменту своя ниша.


Да, вот только есть такой пунктик насчет ниши:

Мой конкретный опыт (повторю в 1001-й раз, что при выборе инструментов меня, "прикладника", интересует только интегральная долгосрочная -- имея в виду и смену сотрудников/студентов -- эффективность) таков, что появление Оберона позволило мне полностью забить на функциональные языки -- полностью и, по всей очевидности, надолго. Нет абсолютно ничего в ФЯ, о чем пока пришлось бы пожалеть (решив целую серию конкретных задач, в т.ч. долгое время не решавшихся, и "побив" при этом конкурентов).

Еще раз для сугубой конкретности:

две сферы приложения моих усилий (с т.зр. программирования) -- символическая алгебра и обработка данных (читай: численные расчеты вроде минимизации пресловутых квадратов и проч.).
Первое -- классическая историческая ниша ФЯ,
второе -- классическая историческая ниша фортрана.

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

И там есть "срединная область".

У задач каждой из двух ниш по мере естественного усложнения наблюдается имманентная тенденция выползания в "срединную область".

Наивный народ в основном пытается соединить ниши с помощью Ц** (как я когда-то игрался с ПЛ/1).

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

ФЯ-кандидаты на подобную роль (а это с неизбежностью синтетические языки, как и Оберон) обламываются на своей сложности (хотя бы в плане быстроты обучения), не давая никаких реальных преимуществ.

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

В чистом виде интерпретируемых языков мало.
Да и в компилируемых -- вызов обероновского NEW интерпретируется.

Это, кстати, подчеркивает постоянно упускаемый из виду факт, что Оберон -- синтетический язык, ставить его в ряд с каким-нить фортраном или Ц, противопоставляя ФЯ (как тут делают "слышавшие про символическую алгебру") -- грубо неправильно.

Ответ на »сообщение 2030« (Geniepro)
___________________________
Хаскелл - вполне даже компилируемый язык. Тем не менее в нём этой проблемы нет.
Ну, скорее частично предкомпилируемый язык. В чистом виде интерпретируемых языков мало. Еще в Smalltalk были отработаны механизмы предкомпиляции блоков кода перед выполнением. Однако в динамических языках никуда не деться от жирного рантайма, т.к. даже в компилирующей реализации многие элементарные операции выполняются не в сгенерированном машинном коде, а через вызовы к виртуальной машине.
А для эффективной реализации полиморфных функций в конечном счете все равно нужно "на лету" генерировать множество перегруженных вариантов в машинном коде, под каждый вариант вызова. Как видите, такие механизмы слишком удаляют нас от идеи простого 100%-компилируемого языка, почему и не были включены в Оберон.

Наконец-то все угомонились.

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

Вы не поняли - проблема в том, что выбор полиморфной процедуры осуществляется в compile-time. Если мы ввели в модуль новую процедуру в полиморфную группу, и правила выбора для конкретного вызова изменились, то для того, чтобы эти правила вступили в силу, потребуется перекомпиляция модуля, содержащего этот вызов. И механизм контроля совместимости модулей-клиентов с текущей версией полиморфной группы процедур модуля.

Вы смешиваете перегрузку функций с полиморфизмом.

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

Совсем другое дело, когда для разных типов данных, удовлетворяющих общему интерфейсу (классу типов в терминах Хаскелла), можно применить ОДНУ функцию, реализующий ОДИН алгоритм с общей для всех этих типов данных семантикой...
Вот это и есть полиморфизм...

В Хаскелле, например, та же самая функция map выглядит так:

map :: (a -> b) -> [a] -> [ b] -- Спецификация типа

map _  [  ]  = []
map f (x:xs) = (f x):(map f xs)

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

Здесь мы видим, что у map два аргумента, первый из которых является функцией-преобразователем, второй - списком объектов любого типа, кодируемого здесь как a, а результат - списком объектов также любого типа, кодируемого здесь как b.
При этом типы a и b могут совпадать, а могут и не совпадать.

Также на функцию-преобразователь накладывается единственное ограничение - у неё должен быть один параметр типа a, а результат типа b... Что делает функция-преобразователь - функцию map АБСОЛЮТНО не интересует.

Таким образом единственная функция map преобразует списки любых объектов, для которых существует нужная функция-преобразователь...


Это решается либо интерпретацией, как в ФЯ, либо промежуточным представлением и JIT.

Хаскелл - вполне даже компилируемый язык. Тем не менее в нём этой проблемы нет.

Ответ на »сообщение 2027« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2025« (Илья Ермаков)
___________________________
Противоречие, несовместимость, прямо говоря - дырка. Compile-time и run-time конфликтуют. Так что как расширять полиморфные процедуры в компилирующей реализации - с ходу неясно.
Введением классов типов, как это сделано в хаскеле.
То есть вместо Proc(a: INTEGER) у вас будет Proc(a: Ord) Где Ord это класс типов в которые входят Integer, Byte и в будущем еще что либо пока не известное на этапе реализации.

Вы не поняли - проблема в том, что выбор полиморфной процедуры осуществляется в compile-time. Если мы ввели в модуль новую процедуру в полиморфную группу, и правила выбора для конкретного вызова изменились, то для того, чтобы эти правила вступили в силу, потребуется перекомпиляция модуля, содержащего этот вызов. И механизм контроля совместимости модулей-клиентов с текущей версией полиморфной группы процедур модуля.
Это решается либо интерпретацией, как в ФЯ, либо промежуточным представлением и JIT.

Ответ на »сообщение 2026« (Илья Ермаков)
___________________________
И бездумно мешать их вряд ли стоит... 
Вот в этом я с вами полностью согласен. Делать из заточенного под императивный подход Оберона функциональный язык совершенно бессмысленно.
Каждому инструменту своя ниша.

Ответ на »сообщение 2025« (Илья Ермаков)
___________________________
Противоречие, несовместимость, прямо говоря - дырка. Compile-time и run-time конфликтуют. Так что как расширять полиморфные процедуры в компилирующей реализации - с ходу неясно.
Введением классов типов, как это сделано в хаскеле.
То есть вместо Proc(a: INTEGER) у вас будет Proc(a: Ord) Где Ord это класс типов в которые входят Integer, Byte и в будущем еще что либо пока не известное на этапе реализации.