lean4-htt/library/init/lean/parser
Leonardo de Moura 0dcdc2c198 feat(library/init/lean/parser/term): add support for "named" patterns n@(x :: s)
@kha, the implementation is a little bit hackish. It is whitespace
sensitive to avoid `f @g`, an application with argument `@g` to be
parsed as a named pattern.
Here are other approaches I have considered:

1- In the `namedPattern`, we add a guard that ensures the pattern
is *not* an identifier. Thus, `f @g` would not be considered a valid
`namedPattern`. Drawback: we would always try to parse it as a
namedPattern first, fail, and then try as an application.

2- Enforce whitespace before application arguments. Drawback: `f(a+b)`
would not be a valid application anymore.
2019-07-16 10:09:01 -07:00
..
command.lean fix(library/init/lean/parser/command): add partial modifier 2019-07-15 16:35:14 -07:00
default.lean feat(library/init/lean/parser): add module.lean 2019-07-12 16:42:25 -07:00
identifier.lean feat(library/init/lean/parser/identifier): add indentifier.lean back 2019-06-06 15:18:22 -07:00
level.lean fix(library/init/lean/parser): use symbolOrIdent when parsing max and imax 2019-07-14 08:22:07 -07:00
module.lean feat(library/init/lean/parser): improve error messages 2019-07-16 08:16:03 -07:00
parser.lean feat(library/init/lean/parser/term): add support for "named" patterns n@(x :: s) 2019-07-16 10:09:01 -07:00
term.lean feat(library/init/lean/parser/term): add support for "named" patterns n@(x :: s) 2019-07-16 10:09:01 -07:00
trie.lean chore(frontends/lean): use => instead of := in match-expressions 2019-07-04 11:38:38 -07:00