Geniepro писал(а):
Сам Хаскелл-98 и его библиотеки поддерживаются-то всеми трансляторами. Конкретно GHC является фактически лабораторией, в которой исследуются системы типов. Поэтому в GHC много расширений языка, которые, естественно, не поддерживаются другими трансляторами.
Скоро будут сам язык пересматривать, стандарт Haskell-2010 принимать. В него, как я понимаю, войдёт и обширная библиотека Haskell Platform.
Ну вот и отлично. Собственно я лишь озвучил мнение самих хаскелистов относительно того же jhc и стандарта -- говорят в Haskell 98 слишком мало всего. Бедновато-с.
Geniepro писал(а):
Ну так любой язык время от времени пересматривается.
Вы хотите сказать, что С++ тоже незрелый язык, учитывая что нет двух полностью совместимых трансляторов для него?
Ну, по факту программ собирающихся множеством компиляторов довольно много таки. И мне затруднительно назвать какой-то компилятор более мейнстримовым нежели другие.
Geniepro писал(а):
А как ситуация с оберонами? Вот есть реализации того же CP -- Блэкбокс и GPCP (для .NET и JVM) -- насколько переносимы программы между ними?
Обероны друг с другом не совместимы. Но не будем о грустном.
Давайте не будем засорять хотя бы эту тему холиворами. Пусть это обсуждение останется максимально технически направленным.
В общем, попробую поставить/собрать jhc И прогнать на нем тот пример со списком. Хотя, думается мне, он в том примере список честно создавать заленится
PS. Кстати, а как идет сборка у ghc? Оно в качестве бэкенда таки использует gcc, или же напрямую пишет бинарь? А то у меня такое ощущение что там собака порылась не на уровне хаскеля а где-то на уровне менеджера памяти, ибо std::list<int> lst(10000000) в точности также сжирает порядка 229 мег ОЗУ. Зато вот std::vector<int> vec(10000000) честно сжирает 38 мег, как ему и положено. Попробую мелкомягким компилятором сейчас, чтобы удостовериться что это не из за неких фенечек std::list'a так происходит.
PPS. Проверил. На мелкомягком компиляторе та же ситуация. Видимо аллокатор тут не причем. Таков сам по себе std::list.