Twas brillig at 11:53:05 20.11.2008 UTC+03 when sin@altlinux.ru did gyre and gimble:

 ES> Но я полагаю, что Haskell запускает для своих приложений внутренюю
 ES> среду, позволяющую реализовать его функциональность на компьютерах,
 ES> аппаратно её не поддерживающих.  С++ же настолько же близок к
 ES> железу, что и C... В этом они с Haskel не сравнимы..

Как это отражается на функционировании? Всё остальное - среда, не среда
- полнейший bullshit.

 >> Не совместим. extern "C", #define class class_, и т.д.

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

Кто будет оборачивать коды ошибки в исключения? Кто будет реализовывать
RAII? Вы не понимаете, что C++-ный код враппера тупо будет размазан по
всей программе тонким слоем? Причём в каждой программе - свой код.

 >> Связки для Haskell занимаются ровно тем, что в C++ делается либо
 >> неявно и несепарабельно (превед!), либо отдельной связкой,
 >> называемой обёрткой: преодолением разницы в подоходах языков к
 >> управлению памятью и ресурсами и обработке ошибок.

 ES> Я не совсем понял, о чём здесь идёт речь,

А вы подумайте, подумайте. Ключевые слова: разница в семантике
управления памятью и обработке ошибок, RAII.

 ES> но вот это, например, явная связка:
 ES> http://www.cse.unsw.edu/~chak/haskell/gtk/
 ES> http://haskell.org/gtk2hs/

gtkmm.

 ES> Кстати, GTK как раз и содержит в заголовочных файлах ряд
 ES> вышеозначенных несовместимостей, которые, как я полагаю, сделаны по
 ES> причине явных предпочтений авторов в пользу С, по сравнению с C++.

О да. А также он содержит ряд вышенеозначенных несовместимостей,
мешающих без ручного кода сделать Haskell-биндинг. Как я полагаю,
сделаны они по причине явных предпочтений авторов в пользу C по
сравнению с Haskell. Могли бы потрудиться и написать попроще, чтобы
биндинги генерить можно было. Впрочем, для C++ всё равно биндинг нужен.

 ES> По моему вы недооцениваете порядок сложности того, что
 ES> предлагаете...  Иначе почему концепция, которую взяла за основу в
 ES> c2hs близка к мёртвому проекту "A GTK+ Binding for Haskell",
 ES> который был сменён gtk2hs?

Потому, что GTK+ Binding for Haskell забросили авторы? Это не имеет ни
малейшего отношения к делу.

 ES> А ведь в gtk2hs я вижу кучу ручного кода....

В gtkmm я тоже вижу кучу ручного кода.

gtk2hs - 1.1M
gtkmm-1.2.10 - 704k

Где разница?

 >> Здесь наши очевидности расходятся.

 ES> С некоторого момента очевидности уже недоказуемы - эта граница
 ES> называется мировоззренческой позицией.

Нет уж, извините. Я требую вполне конкретных вещей, а вы не можете их
предоставить.

Пока что вы

a) сказали, что "Haskell, очевидно, не язык системного
программирования". Я утверждаю с той же степенью авторитетности, что
"C++, очевидно, не язык системного программирования"

b) Предоставили некий набор правил, по которым определяется
"системность" языка, и не смогли опровергнуть, что Haskell под них не
попадает.

 >> Покажите несуразное сравнение. Я пока вижу только суразные.

 ES> "Тогда Haskell - это тоже язык системного программирования"

Тогда опровергните! Не "мне кажется" или "я считаю", а фактами. Раз уж
вы выдвинули свою теорию о классификации языков - она должна выдержать
первое же испытание.

--