-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test case for recursive instantiation #33
Comments
На мой неискушенный взгляд похоже на говнокод, особенно куча разных переменных с именем |
Классика хаскеля же. Однобуквенные локальные идентификаторы. |
Upd: Этот код вообще вызывается только из одного места, где он логически не нужен oczor/src/Oczor/Infer/Infer.hs Line 39 in 14dfe83
И комментирование его там тоже не приводит к падению тестов. Похоже что можно просто удалить саму функцию и её вызов |
Похоже просто дублирование. Так как реализация ftv уже рекурсивно проходит по TypeExpr и собирается все TypeVar, то проходить рекурсивно еще раз смысла нет. |
Синтаксис Хаскеля не позволяет избавить от переменных в которых нет необходимости.
на
|
Это на случай если внутри функции будет описание типа с TypeVar который уже есть в контексте. |
Так это нормально. Называется (в пейпере Карделли который я сейчас не могу найти) non-generic type variables. Они связаны наружным forall и их "освобождать" нельзя. В любом случае нужен тест! Ниже аналоги в HNC: https://github.com/nponeccop/HNC/blob/master/hn_tests/comp-2.hn Короче тебе задание придумать тест, который упадёт после комментирования |
Непонятно, зачем рекурсия в функции:
oczor/src/Oczor/Infer/State.hs
Line 68 in 1b36249
Функцию почти не трогали, разве что Fix/unfix заменили на embed/project. Однако она на первый взгляд не имеет смысла - алгоритму W такой обход не требуется.
Замена на более логичный вариант не приводит к падению тестов.
Как понять задумку исходного рекурсивного обхода? Или придумать тест кейс чтобы второй вариант упал?
The text was updated successfully, but these errors were encountered: