You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
We use ; instead of , to separate items.
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.
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].
The text was updated successfully, but these errors were encountered:
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
changed the title
Syntax change proposal for fixity declarations.
Syntax change proposal for fixity declarations
Aug 31, 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]>
Currently fixity declarations use yaml syntax. E.g:
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.;
instead of,
to separate items.:
as a valid character. Soassoc:
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.
In this syntax we have two "constructors":
binary
andunary
. 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]
.The text was updated successfully, but these errors were encountered: