OberonCore

Ну как-то же компилирую! :о)
В принципе, в чём проблема-то? Ну не знаете Вы размеры элементов этих типов, и что с того? Зато Вы знаете, какие операции к ним можно применять, а это главное...
А если уж там эти элементы хранятся пусть даже в виде ссылок, ведущих в кучу, ну что ж, в худшем случае это приведёт к некоторому уменьшению быстродействия из-за косвенной адресации и более частых промахов в кешах...
В лучшем же случае программа хранится в некоем абстрактном представлении и переводится в конкретный тип во время линковки. Можно даже придумать что-то типа JIT-компиляции во время вызова функции, когда уже всё известно о характеристиках этих элементов...

Так в чём проблема-то?

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

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

Кстати, сравнение с С++ мне кажется глубоко неверным. Лучше сравнивать, ну например, с Адой. Хотя стандартный Хаскелл-98 гораздо компактнее и Ады и С++...

Совершенно неверно! Это всё равно, что утверждать, что в С++ якобы невозможно ООП, так как непонятно как компилировать таблицы виртуальных методов...

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

Но даже если взять и вариант, в котором полиморфные (как и любые другие) функции будут до стадии линковки/загрузки модулей находиться в виде некоего АСТ или в виде байт-кода, например, то что тут такого нехорошего, непонятно? Почему это хуже, чем хранить в виде машинного кода x86, скажите на милость? Да будет Вам известно, JIT-технология позволяет генерировать более качественный код, чем статическая кодогенерация...

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

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

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

Я-то знаю Только знаю, что пока в полной мере JIT не реализован почти нигде, а где реализован - там ещё уйма нерешённых проблем. А в смысле "здесь и сейчас" имеются названные проблемы. Т.е. автовывод типов - не за просто так. А требует определённой поддержки-цены. Речь не про сам этот автовывод (да пребудет мир с ним и с его дедушками до седьмого колена ), а про елейную манеру ФП-шников подавать все свои "конфеты" как дармовые и удивляться: "А почему ж вы не хотите то и это, ведь это так же, как и у вас, но гораздо круче, и всё за просто так"

Ну так ведь всё требует какой-то цены. Пресловутая правильность оберон-технологии тоже требует цены, и немалой. Не говорю уже о потере удобств типа foreach...
Вот взять повторное использование кода на основе обобщённых или полиморфных процедур/функций. Отсутствие этого в Оберонах приводит либо к отказу от этого повторного использования и многократного ручного написания однотипных процедур, отличающихся только мелочами вроде типов входных параметров, при этом появляется серьёзная опасность в виде многочисленных ошибок, да и просто потеря драгоценного времени высокооплачиваемых программистов...
Либо приходится использовать тайные знания о метаинформации обероновского рантайма (которая ещё небось и не в каждой реализации Оберонов имеется) и плясать с бубном, пытаясь вручную сделать то, что давно уже автоматизировано и надёжно реализовано в боле высокоуровневых языках, не говорю уже про Хаскелл, а хотя бы в той же Аде с её дженериками...

Вот Вам цена простоты Оберона. Хорошо ещё, если эта простота не будет хуже воровства для Вас лично, а вот для многих других -- именно что хуже... ;о)

Ну так тоже самое делают и оберонщики, чем мы хуже вас? 8-о :о))
Это называется пиар, господа!

Да я бы и рад, но там 550 страниц + мягкий корешок: сканировать мучение, да плюс рассыпется.


Ага, не только талмуды аля Страуструп писать, нужно ж и "Бархатный путь" пытаться накатать

Факт отсутствия "обобщёнки" всегда признавался. Дженерики были бы к месту. Естественно, наиболее компактным образом, на основе проникновения "в существо проблемы", а не копированием из других языков. А для этого нужны два условия: а) конкретная практика написания такого кода, для которого дженерики нужны (я знаю, для какого, но в своей текущей работе потребность ошущаю редко) и выработка понимая, какой именно механизм будет "серебрянной пулей" для проблемы; б) конкретное намерение и возможность это дело реализовать.

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

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

Вспоминается мой собственный опыт с "обощёнкой". Когда четыре года назад начал использовать С++, то был в восторге от того, как шаблоны позволили сократить объём кода в несколько раз по сравнению с Дельфи (там были около БД-шные задачи). Шаблоны были, пожалуй, основным для меня достоинством С++ (т.к. оборотную сторону "свободы красиво нанизывать..." я понял весьма скоро).
Но вот как-то уже два года в Обероне обхожусь без них превосходно. А тот спектр задач, который тогда решал на шаблонах, лучше и гибче решается тут на метапрограммировании.

О стандартных контейнерах иногда жалеешь, но у них есть обратная сторона: начинают использовать без понимания особенностей работы и получают дикий оверхед... Если учесть, что для повседневки часто достаточно обычных линейных списков, линейного поиска и простой сортировки вставками (вспоминается опыт Вирта по замене в компиляторе двоичных деревьев на лин. списки). А когда нужно иное, то результат написания с учётом специфики задачи часто гораздо лучше, чем у типовых контейнеров (либо у контейнеров быстро возникают тонкие параметризации, кучи версий и наворотов, со всем сопутствующим, ну, STL у всех перед глазами). Ну а упомянутая сборка мусора сильно облегчает всё енто, позволяя строить сколь угодно динамические структуры без запарки по поводу владения...

А вот это, кстати, весьма интересный вопрос, что из этого вытекает.


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

Но ценою меньшей гибкости и удобством работы (конкретно в Обероне).


С другой стороны Вы всё более настойчиво предлагаете использовать малодокументированные и непереносимые возможности "обероновского метапрограммирования", которое являетя по сути динамической типизацией "со всеми вытекающими".

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

Ну, это скорее моё предположение, что это могло бы быть полезным...

А вообще, учёт размера кеша может быть полезен, например, при настройке параметров сборщика мусора, что бы первое поколение объектов максимально полезно заполняло кеш без его переполнения... Но тут связи с JIT вобщем-то нет...

Хотелось бы повторить слова vlad'а -- зря Вы судите об "обобщёнке" по шаблонам С++. Это может быть не так ужасно... ;о)

Предлагаю вернутся к теме и рассмотреть следущую задачу (конкретную и текущую ): необходимо считывать из таблицы БД, размещенной на сервере, некоторую информацию и отображать ее на выносной панели индикации. Проблема усугубляется тем, в случае возникновения каких либо нештатных ситуаций никто ничего делать не будет, там даже не будет клавиатуры. В крайнем случае охранник позвонит в службу поддержки.
Но для тривиальных случаев (например перзагрузили машину на которой сервер БД) необходимо сделать две вещи:
1. Отобразить текущее состояние
2. Попытаться восстановить соединение с БД
При этом недопустимы ни какие трапы, системные сообщения, т.е. ничего что требует каких либо манипуляций.
В delphi я примерно представляю как это сделать, а как это будет выглядеть в BlackBox?

Этот момент я упустил...
А что там в С++ можно так "свободно и красиво нанизывать", не подскажете? ;о)

Из этого вытекает, что вся "обобщённость" шаблонов заканчивается после того, как отработал последний проход компилятора.... А вот с метапрограммированием только начинается и как раз самое интересное

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

Ну, когда тогда начал изучать - то много чего показалось Бусинки разные и перья в одно место, як у папуасов, как тут недавно на КД Info21 сказал (правда, его быстро отмодерировали...). Было, типа, круто

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

А "нормальные нештатные" обработал бы, как вкратце рассказывал выше. Всё окружение (типа БД и т.п.), как полагается, покрыто набором абстракций, в терминах которых написана основная часть приложения. Эта часть не подозревает, что под ней какая-то ненадёжная среда. А далее определяются все возможные нештатные ситуации с отключениями БД и т.п., в слое абстракций делаются разъёмы для инсталляции обработчиков. А выше в приложении описываются обработчики. При попытке обратиться к базе данных и её недоступности не происходит возврата управления основному коду и не происходит трепа, а вызывается обработчик, который разбирает ситуацию, пытается исправить ситуацию и указать технич. слою, что сделать (попробовать ещё раз, или укажет запасной сервер ну и т.п. - по логике вашего приложения). Если ситуация исправлена, то в итоге основной код получит нормальный результат как ни в чём не бывало. Ну а если не вышло - то идут особые действия, типа показа сообщения об ошибке и невозможности дальнейшей работы, пока не будет устранено то-то и то-то, ну и т.п.

Ну предположим я определился: нештатная ситуация - потеря соединения с БД, а мои действия - вывод на статус-строку текущее состояние подключения к БД и попытка восстановления соединения с БД (периодически). Вопрос: как задавить системные реакции? В Delphi для этого есть try ... exсept ... end, а как в BB "задавить" трап? Редактировать Kernel?

Не совсем понятно в каком слое абстракции?, в подсистеме SQL? Или в своей подсистеме? В Delphi я делаю обработку после except и при этом мне не нужно думать ни о каких разъемах.

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

Потому что в Delphi Вам возвращается исключение... А в подсистеме Sql, насколько я помню, для этого служат коды ошибок (поля res объектов Database и Table). Трепы при потере соединения не генерируются. Ну так и пользуйтесь либо кодами ошибок, либо оборачивайте в свой слой, имитирующий безошибочность, а ошибки посылающий по боковым разъёмам...


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