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

Numeric constraint disjunctions #1369

Open
rybla opened this issue Jun 21, 2022 · 0 comments
Open

Numeric constraint disjunctions #1369

rybla opened this issue Jun 21, 2022 · 0 comments
Labels
design needed We need to specify precisely what we want language Changes or extensions to the language

Comments

@rybla
Copy link
Collaborator

rybla commented Jun 21, 2022

As a generalization of #701, a signature's constraints could be allowed to include up to one numeric constraint disjunction. A numeric constraint disjunction has the form

(c, ..., c) \/ ... \/ (c, ..., c)

where each disjunct is a conjunction of numeric constraints that are not disjunctions.

The implementation of a function that has a numeric constraint disjunction in its signature needs to include a branch for each disjunct (i.e. case) of the disjunction. For example, as well as some proposed syntax, the following declares a function bar which requires n to either be 1 or divisible by 2.

bar : {n} {fin n, n == 1 \/ n % 2 == 0) => [n] -> [n]
bar `(n == 1) [x] = ...
bar `(n % 2 == 0) xs = ...

Each case of such a declaration can be type checked by including the case's disjunct into the assumed constraints and then typechecking the body of the case as usual.

There need not be any exhaustivity or exclusivity check over the disjunction. In the case of overlapping cases, the first matching case will be chosen at runtime, but nothing at typecheck-time is affected.

This feature generalizes #701 since that feature is the same as the feature proposed here, except with an additional requirement of exhaustivity (and perhaps also exclusivity) as the entire disjunction encoded by the pattern matching is assumed to always be satisfiable, since the domain of the disjunction cannot be specified in the top-level type of the declaration.

#701 gives some justifications for why constraint-aware conditioning can be useful, and this proposal allows for conditioning on disjunctions of constraints which may not be exhaustive.

  • If a function requires a size from a discrete set, then this set can be specified as a disjunction of equalities e.g. foo : {n} (n == 128 \/ n == 256 \/ n == 512) [n] -> [n].
  • If a function requires a size from a discontinuous set, then this set can be specified as a disjunction of constraints e.g. foo : {n} (n == 0 \/ n == 2 \/ n >= 4) [n] -> [n].
  • TODO: actual use cases in example implementations
@rybla rybla added the language Changes or extensions to the language label Jun 21, 2022
@rybla rybla mentioned this issue Jul 8, 2022
8 tasks
@yav yav added the design needed We need to specify precisely what we want label Sep 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design needed We need to specify precisely what we want language Changes or extensions to the language
Projects
None yet
Development

No branches or pull requests

2 participants