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

Parsing of lambda and where #997

Closed
brianhuffman opened this issue Dec 4, 2020 · 3 comments
Closed

Parsing of lambda and where #997

brianhuffman opened this issue Dec 4, 2020 · 3 comments
Labels
design needed We need to specify precisely what we want language Changes or extensions to the language

Comments

@brianhuffman
Copy link
Contributor

Currently, the cryptol parser doesn't extend the scope of lambdas over where clauses. For example:

Cryptol> (\(x:[8]) -> y+y where y = x + 2)

[error] at <interactive>:1:28--1:29 Value not in scope: x

It might be considered less surprising if we changed the parser so that the scope of the lambda extended over the where clause, so that this would be accepted.

@brianhuffman brianhuffman added language Changes or extensions to the language design needed We need to specify precisely what we want labels Dec 4, 2020
@brianhuffman
Copy link
Contributor Author

brianhuffman commented Dec 4, 2020

A related question is how should where interact with if/then/else.
Should if a then b else c where d = e parse as

  • (if a then b else c) where d = e, or as
  • if a then b else (c where d = e)?

@robdockins
Copy link
Contributor

I think where should extend left as far as possible, even across lambdas and if/then/else, etc. For example, the following program currently works (and I think it should), where as the proposed change would break it.

asdf : Integer -> Integer
asdf x = f \y -> x+y
  where
    f g = g (g 0)

@robdockins
Copy link
Contributor

I get the impression that we have not arrived at a strong consensus that this should be changed, and I'm going to suggest we break the tie in favor of not changing things.

If you disagree and think this deserves more discussion, feel free to reopen.

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