Причина, по которой существует так много интерпретаторов LISP, заключается в том, что LISP является в основном предшественником JSON: простой формат для кодирования данных. Это делает интерфейсную часть довольно простой в обращении. По сравнению с этим, Haskell, особенно с языковыми расширениями, не самый простой для анализа язык.
Вот некоторые синтаксические конструкции, которые звучат сложно, чтобы получить право:
- операторы с настраиваемым приоритетом, ассоциативностью и фиксированностью,
- вложенных комментариев
- правило размещения
- синтаксис шаблона
do - блоки и обесцвечивание в монадический код
Каждый из них, за исключением, возможно, операторов, может быть решен студентами после их курса по компиляции, но это отвлечет внимание от того, как на самом деле работает Haskell. В дополнение к этому, вы можете не захотеть напрямую реализовывать все синтаксические конструкции Haskell, а вместо этого реализовывать проходы, чтобы избавиться от них. Что подводит нас к буквальному суть проблемы, каламбур полностью предназначен.
Мое предложение - реализовать проверку типов и интерпретатор для Core вместо полной версии Haskell. Обе эти задачи уже довольно сложны.
Этот язык, хотя и является строго типизированным функциональным языком, гораздо менее сложен в плане оптимизации и генерации кода.
Тем не менее, он по-прежнему не зависит от базовой машины.
Поэтому GHC использует его в качестве языка-посредника и переводит в него большинство синтаксических конструкций Haskell.
Кроме того, вы не должны уклоняться от использования внешнего интерфейса GHC (или другого компилятора).
Я не считаю это мошенничеством, поскольку пользовательские LISP используют синтаксический анализатор системы LISP хоста (по крайней мере, во время начальной загрузки). Очистка Core фрагментов и представление их учащимся вместе с исходным кодом должны дать вам представление о том, что делает интерфейс, и почему предпочтительно не переопределять его.
Вот несколько ссылок на документацию Core, используемую в GHC: