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

Constructors that require arguments shouldn't be in patterns without arguments #1309

Open
Negabinary opened this issue May 16, 2024 · 4 comments

Comments

@Negabinary
Copy link
Contributor

image

This example should ideally have a static error on the X because it doesn't have an argument.

type T = +X(Int) in
let X = fun x -> X(x) in
?

@disconcision I wonder if you have any ideas how to do this?

@disconcision
Copy link
Member

hmm.. would need to decide what the error should be. the example shown doesn't seem fatally problematic, in that even if someone believed X gets bound by the let, it would still have the same result. but if the type had another constructor say Y of the same type, then it would be more confusing. in principle though in such cases would have refutable pattern errors, assuming it's possible to do refutability for arrow typed things

@disconcision
Copy link
Member

probably just an arity error for constructors in patterns would do it?

@Negabinary
Copy link
Contributor Author

It's probably more problematic in a case statement:

image

An arity error would probably do it; we just need to pass some sort of "expected arity" through pattern statics

@disconcision
Copy link
Member

disconcision commented May 17, 2024

not sure we need any more information. we know constructor arities from types in ctx. so:

  1. for pattern ap statics, check if fun pos is constructor with arrow type. inline its statics (ie dont recurse on funpos)
  2. for pattern constructor statics, it must be non arrow type (since we know we didnt pass thru ap)

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