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

Syntax change proposal for fixity declarations #2330

Closed
janmasrovira opened this issue Aug 31, 2023 · 1 comment · Fixed by #2332
Closed

Syntax change proposal for fixity declarations #2330

janmasrovira opened this issue Aug 31, 2023 · 1 comment · Fixed by #2332
Assignees
Labels
Milestone

Comments

@janmasrovira
Copy link
Collaborator

janmasrovira commented Aug 31, 2023

Currently fixity declarations use yaml syntax. E.g:

syntax fixity additive {arity: binary, assoc: left, above: [comparison, range, cons]};

The advantage is that we can use an existing familiar syntax and parser.
The problem is that there is no currently available parser that has location information for the parsed items. This makes it impossible to properly highlight and give go-to information to the parsed identifiers.

We could write a custom yaml parser for the subset that we support in the fixity declarations. But the yaml syntax does not really play well with juvix syntax.

  1. We use ; instead of , to separate items.
  2. We support : as a valid character. So assoc: is a valid juvix identifier.

We could implement a custom lexer, but that would make the implementation slightly more involved. Also, having special lexical rules in some specific context could be confusing.

I propose an alternative record-inspired syntax. E.g.

syntax fixity rapp := binary {assoc := right; above := [lapp; rapp]; below := [rapp] }
syntax fixity rapp := unary {assoc := postfix; below := [x; y] }

In this syntax we have two "constructors": binary and unary. The fixity properties are given in the same way we create records. Note that for lists we use the builtin list syntax [a;b;c].

@lukaszcz
Copy link
Collaborator

I think that's a fine idea, but then perhaps to keep things consistent we should introduce similar syntax in other places we use YAML (except pragmas, which allow unknown fields for backward compatibility): currently that's just fixities and iterators.

@janmasrovira janmasrovira changed the title Syntax change proposal for fixity declarations. Syntax change proposal for fixity declarations Aug 31, 2023
@lukaszcz lukaszcz added this to the 0.5.0 milestone Sep 7, 2023
jonaprieto pushed a commit that referenced this issue Sep 14, 2023
- Closes #2330
- Closes #2329 

This pr implements the syntax changes described in #2330. It drops
support for the old yaml-based syntax.
Some valid examples:
```
syntax iterator for {init := 1; range := 1};

syntax fixity cons := binary {assoc := right};
syntax fixity cmp := binary;
syntax fixity cmp := binary {}; -- debatable whether we want to accept empty {} or not. I think we should
```
# Future work
This pr creates an asymmetry between iterators and operators
definitions. Iterators definition do not require a constructor. We could
add it to make it homogeneous, but it looks a bit redundant:
```
syntax iterator for := mkIterator {init := 1; range := 1};
```

We could consider merging iterator and fixity declarations with this
alternative syntax.
```
syntax XXX for := iterator {init := 1; range := 1};

syntax XXX cons := binary {assoc := right};
```
where `XXX` is a common keyword. Suggestion by @lukaszcz XXX = declare

---------

Co-authored-by: Łukasz Czajka <[email protected]>
Co-authored-by: Lukasz Czajka <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants