Commit Graph

5 Commits

Author SHA1 Message Date
rvcas 3675762c3e feat(bls): aiken level g1 and g2 literals 2023-11-15 15:55:56 -05:00
rvcas d808197507
chore: clippy fix 2023-09-13 18:17:59 -04:00
KtorZ 78d34f7f76 Fix parsing of negative int patterns and constants
This was trickier than expected as the expression parser, and in particular the bin-op parser will interpret negative patterns as a continuation of a binary operation and eventually choke on the next right-arrow symbol. This is due to how we actually completely erase newlines once we're done with the lexer. The newline separating when clause is actually semantically important. In principle, we could only parse an expression until the next newline.

  Ideally, we would keep that newline in the list of token but it's difficult to figure out which newline to keep between two right arrows since a clause guard can be written over multiple lines. Though, since we know that this is only truly a problem for negative integers, we can use the same trick as for tuples and define a new 'NewLineMinus' token. That token CANNOT be part of a binop expression. That means it's impossible to write a binary operation with a minus over multiple lines, or more specifically, with the '-' symbol on a newline. This sounds like a fair limitation. What we get in exchange is less ambiguity when parsing patterns following expressions in when clause cases.

  Another more cumbersome option could be to preserve the first newline encountered after a 'right-arrow' symbol and before any parenthesis or curly brace is found (which would otherwise signal the beginning of a new block). That requires to traverse, at least partially, the list of tokens twice. This feels unnecessary for now and until we do face a similar issue with a binary operator.
2023-07-06 16:10:46 -04:00
KtorZ 549cf22cdd Rename (Un)TypedExpr.Int -> (Un)TypedExpr.UInt
We do not actually every parse negative values in there, as a negative value is a combination of a 'Negate' and 'UInt' expression.
  However, for patterns and constant, it'll be simpler to parse whole Int values as there's no ambiguity with arithmetic operations
  there. To avoid confusion of having some 'Int' constructors containing only non-negative values, and some being on the whole range,
  I've renamed the constructor to 'UInt' to make this more obvious.
2023-07-06 16:10:46 -04:00
KtorZ 66296df9c3
Move parsing of literals under new 'literal' parser module group
Also moved the logic for 'int' and 'string' there though it is trivial. Yet, for bytearray, it tidies things nicely by removing them from the 'utils' module.
2023-07-05 14:37:29 +02:00