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

Allow multiple constraint arrows (=>) in type scheme syntax #599

Closed
brianhuffman opened this issue May 29, 2019 · 0 comments
Closed

Allow multiple constraint arrows (=>) in type scheme syntax #599

brianhuffman opened this issue May 29, 2019 · 0 comments
Labels
feature request Asking for new or improved functionality parser Issues with lexing or parsing.

Comments

@brianhuffman
Copy link
Contributor

This would be convenient when writing large type signatures that contain many complex type constraints. It would let us write each constraint on a separate line with its own => at the end, making it much easier to cut/paste/rearrange the constraints.

For example, we could write

ExpandKey :
  {KEY_NUM_COLS, NUM_ROUNDS, NUM_KEY_EXP_ROUNDS}
  (8 >= KEY_NUM_COLS) =>
  (KEY_NUM_COLS >= 2) =>
  fin NUM_ROUNDS =>
  ((1 + NUM_KEY_EXP_ROUNDS) * KEY_NUM_COLS >= 4 * (1 + NUM_ROUNDS)) =>
  8 >= width NUM_KEY_EXP_ROUNDS =>
  (NUM_KEY_EXP_ROUNDS >= 1) =>
  { key : [KEY_NUM_COLS][4]byte_t } ->
  { roundKeys : [NUM_ROUNDS+1]roundKey_t }

instead of something like

ExpandKey :
  {KEY_NUM_COLS, NUM_ROUNDS, NUM_KEY_EXP_ROUNDS}
  (8 >= KEY_NUM_COLS, KEY_NUM_COLS >= 2,
   fin NUM_ROUNDS,
   (1 + NUM_KEY_EXP_ROUNDS) * KEY_NUM_COLS >= 4 * (1 + NUM_ROUNDS),
   8 >= width NUM_KEY_EXP_ROUNDS, NUM_KEY_EXP_ROUNDS >= 1) =>
  { key : [KEY_NUM_COLS][4]byte_t } ->
  { roundKeys : [NUM_ROUNDS+1]roundKey_t }

It could be treated as syntactic sugar for a comma-separated list of constraints. When pretty-printing type schemas, we could just always use the comma-separated syntax that we have now.

@brianhuffman brianhuffman added feature request Asking for new or improved functionality parser Issues with lexing or parsing. labels May 29, 2019
@yav yav closed this as completed in c5ab964 May 29, 2019
@brianhuffman brianhuffman mentioned this issue Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Asking for new or improved functionality parser Issues with lexing or parsing.
Projects
None yet
Development

No branches or pull requests

1 participant