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

Builtin vs. hardcoded types #2163

Open
sauclovian-g opened this issue Dec 17, 2024 · 0 comments
Open

Builtin vs. hardcoded types #2163

sauclovian-g opened this issue Dec 17, 2024 · 0 comments
Assignees
Labels
needs test Issues for which we should add a regression test tech debt Issues that document or involve technical debt type: bug Issues reporting bugs or unexpected/unwanted behavior
Milestone

Comments

@sauclovian-g
Copy link
Contributor

Right now (since merging #2157) most of the assorted builtin types are declared in a table in the interpreter, but some appear as hardcoded special cases of TyCon in AST.hs. The latter are also reserved words in the lexer and parser.

Some of these special cases need to be special cases because they have special semantics (e.g. Term) and some of them are inherently hardcoded (e.g. Int) but there are several there's probably no need to do anything special with and these should probably be moved to the builtins table.

The obvious candidates are: AIG CFG JVMSpec LLVMSpec MIRSpec.

Relatedly, once other cleanup makes them less special and given suitable infrastructure to deal with them having kind * -> * instead of *, most of the monad types enumerated in Context in AST.hs won't need to be hardcoded either, although this is more ambitious.

Finally, it seems unlikely that any of the names of named types (even those like Int) actually need to be reserved words, and tidiness suggests that at least some of them shouldn't be.

@sauclovian-g sauclovian-g added type: bug Issues reporting bugs or unexpected/unwanted behavior needs test Issues for which we should add a regression test tech debt Issues that document or involve technical debt labels Dec 17, 2024
@sauclovian-g sauclovian-g added this to the 2025T1 milestone Dec 17, 2024
@sauclovian-g sauclovian-g self-assigned this Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs test Issues for which we should add a regression test tech debt Issues that document or involve technical debt type: bug Issues reporting bugs or unexpected/unwanted behavior
Projects
None yet
Development

No branches or pull requests

1 participant