Skip to content
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

Get rid of AllowAmbiguousTypes #108

Open
Mikolaj opened this issue Jan 13, 2024 · 1 comment
Open

Get rid of AllowAmbiguousTypes #108

Mikolaj opened this issue Jan 13, 2024 · 1 comment
Labels

Comments

@Mikolaj
Copy link
Owner

Mikolaj commented Jan 13, 2024

Edsko says: "I think AllowAmbiguousTypes is almost never the right solution; the main problem is that it gives the user no indication at all as to which type variables might be problematic. If you use the explicit inverse approach (which is only needed in rare cases), at least ghc will clearly point to where the problem is (cannot prove that such and such is equal to such and such)."

So probably the numerous AllowAmbiguousTypes in horde-ad code contribute to the unhelpful error messages when developing horde-ad or using it as a library. Let's get rid of them once the code stabilizes again. Some cases may require just the usage of Proxy arguments. More ideas are at https://www.youtube.com/watch?v=1vd9mvH8Bos&list=PLD8gywOEY4HaG5VSrKVnHxCptlJv2GAn7&index=3

@Mikolaj
Copy link
Owner Author

Mikolaj commented Feb 24, 2024

Notes to self:

  • I'm still unclear where to use SNat, Proxy and Proxy#.
  • I'm also currently using the orthotope's idiom valueOf @k, which may change to proxy_value# and others, more or less forced or suggested by the addition of SNat, Proxy or Proxy#.
  • An example: I'm currently using Proxy in the method sslice, but nothing in the corresponding term AstSliceS. Probably term constructors don't need Proxy as much, but there is SNat in a couple, so it's not clear-cut.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant