Являются ли неявные параметры проблемой для встраивания в GHC?

Мне любопытны возражения против неявных параметров , обсуждаемых в Functional Pearl :Неявные конфигурации статья Киселёва и Шана.

Неправильно встроенный код (β -редуцировать )при наличии неявных параметров.

Правда? Я ожидаю, что GHC должен быть встроен в ту же область, что и переданный неявный параметр, нет?

Мне кажется, я понимаю их возражение, что:

поведение термина может измениться, если его сигнатура будет добавлена, удалена или изменена.

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

Я предполагаю, что этот пример полиморфной рекурсии также охватывает то, что они подразумевают под «обобщением по неявным параметрам»? Что-нибудь еще?

Является ли класс типов ReifiesStorableиз Data.Reflection разумным решением этих трудностей? Казалось бы, он десериализует всю неявную структуру данных каждый раз, когда к ней обращаются, что может иметь катастрофические последствия для производительности. Например, -мы можем захотеть, чтобы наша неявная информация была таблицей Кэли или таблицей символов, которая занимает гигабайт оперативной памяти и должна быть доступна во время миллионов алгебраических операций.

Возможно, есть какое-то лучшее решение, использующее неявные параметры, или другой метод, который компилятор может легко оптимизировать за кулисами, при этом гарантируя больше через систему типов, использующую потоки состояния или что-то еще?