LINUX.ORG.RU

Компилятор GHC языка Haskell: теория языков программирования в работе

 , ,


1

7

31 марта в Санкт-Петербурге стартует двухдневный курс лекций Виталия Брагилевского о внутреннем устройстве компилятора GHC.

Компилятор GHC (The Glasgow Haskell Compiler) языка Haskell уже в течение почти 30 лет представляет собой площадку для экспериментов в области теории языков программирования. В рамках этого курса мы посмотрим, какие именно результаты теории в нём реализованы, а также обсудим, как можно подключиться к его разработке.

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

Вторая часть (три лекции) будет посвящена внутреннему языку GHC Core, в который транслируется код на Haskell и который представляет собой расширение системы полиморфного λ-исчисления высших порядков System Fω, а также вычислению выражений Core с использованием STG-машины.

Лекции будут проходить в ПОМИ РАН (Набережная реки Фонтанки, 27, Мраморный зал (2 этаж)).

Участие бесплатное, регистрация не требуется.

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: anonymous_incognito (всего исправлений: 1)

Спасибо за новость. Интересный и нужный курс. Haskell рулит!

{-# LANGUAGE ExistentialQuantification #-}
data Foo = forall a. Foo a
ignorefoo f = 1 where (Foo a) = f

Odalist ★★★★★
()
Последнее исправление: Odalist (всего исправлений: 1)

Поминания — это звучит символично. Хаскель поминания.

anonymous
()

Это хорошо.

С GHC надо что-то делать с системной стороны. Там много legacy и работы.

Как он поставляеться и работает... Использование внутренних дубликатов утилит и библиотек. Он ведет себя как Виндовая программа - тянет с собой кроме компилятора ещё целый табор и зоопарк, который потом конфликтует с установленными на системе нужными тебе инструментами.

PiroXiline
()

GHC хорош, очень хорош, особенно с его возможностями code inlining, которым можно управлять

dave ★★★★★
()
Ответ на: комментарий от Myau

Обычно снимают и выкладывают.

ymn ★★★★★
() автор топика

Надо бы съездить. Вот уже пошел дешевую гостиницу на одну ночь искать...

gns ★★★★★
()

Haskell

ПОМИ РАН

эта аватарка со смертью

Символичненько!

shkolnick-kun ★★★★★
()
Ответ на: комментарий от iVS

Не совсем. Речь скорее о прагмах INLINE и INLINABLE и задаваемых им приоритетах.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Clayman

Я нашел что-то на Невском, сейчас групон кучу скидок предлагает.. Поезд, сцуко дороже :)

gns ★★★★★
()

Спасибо за новость! С нетерпением ждём видео!

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от DELIRIUM

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

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

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

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

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

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

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от dave

Идею понял, но мне это не интересно: я думал, вдруг можно что-то перетащить в clang, а тут не тот случай)

DELIRIUM ☆☆☆☆☆
()
Последнее исправление: DELIRIUM (всего исправлений: 1)
Ответ на: комментарий от DELIRIUM

«Ну кроме исходников компилятора» Как бы более достоверной информации и нет в нашей профессии...

Ну а если дело принципа не читать исходник то.. информация на википедии есть и 100 сайтов, гугл вам в помощь.

HasKup9012
()
Ответ на: комментарий от anonymous

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

Например, если у функции есть ограничения по параметрическим классам типов, то такую функцию желательно снабдить прагмой INLINABLE или иногда INLINE. Это приведет к тому, что псевдокод исходной функции будет зашит в бинарной библиотеке (чем-то аналогично атрибуту ReflectedDefinition в F#).

Потом, при использовании соответствующей бинарной библиотеки из приложения или какой совсем другой библиотеки для исходного кода той самой функции может произойти inlining на этапе компиляции.

В Scala и Java есть похожие штуки, но я их особо не щупал в отличие от описанной возможности в Haskell, которая замечательно работает.

Ну, и вдобавок. В Haskell ссылочная прозрачность. А потому инлайнить можно совершенно безопасно и в любых количествах где-угодно и как угодно. Ничего подобного даже близкого нет ни в JVM, ни в Си в силу фундаментальных ограничений. А те немногие, кто используют вынужденно unsafePerformIO, должны часто использовать прагму NOINLINE

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от Odalist

Это не только начало, но и конец одновременно :). Но я сожалею, что написал комментарий, потому что не заметил, что подняли тред едва ли не месячной давности. Не некропостинг, конечно, но флудилку лучше устраивать в реалтайме.

Virtuos86 ★★★★★
()
Последнее исправление: Virtuos86 (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.