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

Better Aiken's lexical scope errors #236

Closed
Tracked by #191
KtorZ opened this issue Jan 4, 2023 · 0 comments · Fixed by #254
Closed
Tracked by #191

Better Aiken's lexical scope errors #236

KtorZ opened this issue Jan 4, 2023 · 0 comments · Fixed by #254
Assignees
Labels
parsing Parser work typechecking Types and inference
Milestone

Comments

@KtorZ
Copy link
Member

KtorZ commented Jan 4, 2023

Aiken uses {} for lexical scope, which is rather unusual as people are generally used to (). At the moment, using brackets in an unexpected location may result in a not_fn error as the compiler infers a function call due to brackets.

For example:

let foo = bar

(some_expression || True) && baz

actually parses as:

let foo = bar(some_expression || True) && baz

which results in attempting to use bar as a function with some_expression || True as argument. Here, one should have written:

let foo = bar

{ some_expression || True } && baz

which is rather unusual for developers.

Possible ways forward:

  • Improve this particular error message to hint what I just did; re-explain how block-scope are made via {} and not brackets (), with an example.
  • Forbid newlines before open brackets; turn it into a parse-error (this holds for both functions and tuple definitions)
  • Allow use of brackets in (at least) boolean and arithmetic expressions for lexical scoping.
@KtorZ KtorZ mentioned this issue Jan 4, 2023
27 tasks
@KtorZ KtorZ self-assigned this Jan 4, 2023
@KtorZ KtorZ added parsing Parser work typechecking Types and inference labels Jan 4, 2023
@KtorZ KtorZ added this to the Language PoC milestone Jan 4, 2023
KtorZ added a commit that referenced this issue Jan 14, 2023
  This changes allow to use parenthesis `(` `)` to encapsulate
  expressions in addition to braces `{` `}` used to define blocks.

  The main use-case is for arithmetic and boolean expressions for which
  developers are used to using parenthesis. For example:

  ```
  { 14 + 42 } * 1337
  ```

  can now be written as:

  ```
  ( 14 + 42 ) * 1337
  ```

  This may sound straightforward at first but wasn't necessarily trivial
  in Aiken given that (a) everything is an expression, (b) whitespaces
  do not generally matter and (c) there's no symbol indicating the end
  of a 'statement' (because there's no statement).

  Thus, we have to properly disambiguate between:

  ```
  let foo = bar(14 + 42)
  ```

  and

  ```
  let foo = bar
  (14 + 42)
  ```

  Before this commit, the latter would be interpreted as a function call
  and would lead to a somewhat puzzling error. Now, the newline serves
  as a delimiting symbol. The trade-off being that for a function call,
  the left parenthesis has to be on the same line as the function name
  identifier -- which is a fair trade off. So this is still allowed:

  ```
  let foo = bar(
    14 + 42
  )
  ```

  As there's very little ambiguity about it.

  This fixes #236 and would seemingly allow us to get rid of the leading
  `#` in front of tuples.
rvcas pushed a commit that referenced this issue Jan 14, 2023
  This changes allow to use parenthesis `(` `)` to encapsulate
  expressions in addition to braces `{` `}` used to define blocks.

  The main use-case is for arithmetic and boolean expressions for which
  developers are used to using parenthesis. For example:

  ```
  { 14 + 42 } * 1337
  ```

  can now be written as:

  ```
  ( 14 + 42 ) * 1337
  ```

  This may sound straightforward at first but wasn't necessarily trivial
  in Aiken given that (a) everything is an expression, (b) whitespaces
  do not generally matter and (c) there's no symbol indicating the end
  of a 'statement' (because there's no statement).

  Thus, we have to properly disambiguate between:

  ```
  let foo = bar(14 + 42)
  ```

  and

  ```
  let foo = bar
  (14 + 42)
  ```

  Before this commit, the latter would be interpreted as a function call
  and would lead to a somewhat puzzling error. Now, the newline serves
  as a delimiting symbol. The trade-off being that for a function call,
  the left parenthesis has to be on the same line as the function name
  identifier -- which is a fair trade off. So this is still allowed:

  ```
  let foo = bar(
    14 + 42
  )
  ```

  As there's very little ambiguity about it.

  This fixes #236 and would seemingly allow us to get rid of the leading
  `#` in front of tuples.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parsing Parser work typechecking Types and inference
Projects
Status: 🚀 Released
Development

Successfully merging a pull request may close this issue.

1 participant