История изменений

Где почитать? Прямо такой статьи не видел.

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

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

В Haskell практически тотальная ссылочная прозрачность. Короче говоря, за исключением явных ссылок и изменяемых массивов, старые объекты никак не могут ссылаться на новые объекты. По словам разработчиков это дает огромное преимущество сборщику мусора. Система времени исполнения GHC способна переваривать гигабайты кратко-живущих объектов, на что собственно и рассчитан сборщик мусора.

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

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

Где почитать? Прямо такой статьи не видел.

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

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

В Haskell практически тотальная ссылочная прозрачность. Короче говоря, за исключением явных ссылок и изменяемых массивов, новые объекты никак не могут ссылаться на старые объекты. По словам разработчиков это дает огромное преимущество сборщику мусора. Система времени исполнения GHC способна переваривать гигабайты кратко-живущих объектов, на что собственно и рассчитан сборщик мусора.

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

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