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

Store argument well formed-ness constraints in Data constructor representation type #34

Open
fxdpntthm opened this issue Apr 29, 2022 · 1 comment
Labels
enhancement New feature or request Low Priority Things that are good to have but not needed

Comments

@fxdpntthm
Copy link
Collaborator

Consider our favorite data Ord a => BST a :: L | N a (T a) (T a)
And a wrapper datatype data WD a = MkWD (BST a)

we currently store MkWD :: BST a -> WD a but in ideal world we would like to store MkWD :: BST @ a => BST a -> WD a. This will potentially enable short circuiting the solver to reuse the dictionaries eg:

f :: Ord a => a -> T a -> T a
f a (MkWD t)= MkWD (insert a t) 
@fxdpntthm fxdpntthm added enhancement New feature or request Low Priority Things that are good to have but not needed labels Apr 29, 2022
@fxdpntthm
Copy link
Collaborator Author

Possible issue with engineering.
datacon context, type arguments are all knot tied, so elaborating it will be troublesome.
Currently we use the stupid_theta route, were we just drop them while compiling to core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Low Priority Things that are good to have but not needed
Projects
None yet
Development

No branches or pull requests

1 participant