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

Reflection of functions with wired-in names leads to errors #2242

Open
nikivazou opened this issue Nov 22, 2023 · 2 comments
Open

Reflection of functions with wired-in names leads to errors #2242

nikivazou opened this issue Nov 22, 2023 · 2 comments

Comments

@nikivazou
Copy link
Member

For example, here: https://gist.github.com/nikivazou/1c134d34830e73c62cc5e18b8b7c8e98

the following assertion fails

{-@ fstBug :: xys:[(a,b)] 
           -> x: {a | member x (fromList (map fst xys))}
           -> () @-}
fstBug :: Ord a => [(a,b)]-> a -> ()
fstBug xys x = assert (member x (fromList (map fst xys))) ()

because the fst in the signature is interpreted as the wired-in fst while the fst in the code as a user-defined fst function. These two are not related.

Proposed Solution: Generate an error when reflecting functions with wired-in names.

@facundominguez
Copy link
Collaborator

facundominguez commented Nov 22, 2023

Assuming wired-in names means names coming from the LH annotations about boot libraries, would it make sense to broaden the focus to any clashes between names in the current module and names coming from annotations in other modules?

@nikivazou
Copy link
Member Author

nikivazou commented Nov 22, 2023

The example comes from the LH's wired in names
'wiredInNames = S.fromList [ "head", "tail", "fst", "snd", "len"]'. For names imported from different modules, I do not have an opinion. Best to do what GHC is doing.

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

No branches or pull requests

2 participants