new parsing scheme is documented

This commit is contained in:
Araq 2013-04-21 20:09:46 +02:00
commit 8a595b631b
4 changed files with 293 additions and 455 deletions

View file

@ -10,10 +10,8 @@ version 0.9.2
- parser/grammar: enforce 'simpleExpr' more often --> doesn't work; tkProc is
part of primary!
* check that of branches can only receive even simpler expressions, don't
allow of (var x = 23; nkIdent)
* document the new grammar: ^+ ^* operators; indentation handling
* remove rules in the manual as it's too hard to keep it up to date
* improve rules to contain the AST structure
allow 'of (var x = 23; nkIdent)'
* bugfix: 'import x var y = 0' compiles
* the typeDesc/expr unification is weird and only necessary because of
the ambiguous a[T] construct: It would be easy to support a[expr] for
generics but require a[.typeDesc] if that's required; this would also
@ -48,7 +46,7 @@ version 0.9.4
- implement full 'not nil' checking
- make 'bind' default for templates and introduce 'mixin';
special rule for ``[]=``
- implicit deref for parameter matching; overloading based on 'var T'
- implicit deref for parameter matching
- ``=`` should be overloadable; requires specialization for ``=``; general
lift mechanism in the compiler is already implemented for 'fields'
- lazy overloading resolution:
@ -66,9 +64,7 @@ version 0.9.X
- improve the compiler as a service
- better support for macros that rewrite procs
- macros need access to types and symbols (partially implemented)
- rethink the syntax/grammar:
* parser is not strict enough with newlines
* change comment handling in the AST
- perhaps: change comment handling in the AST
Concurrency
@ -108,7 +104,8 @@ Not essential for 1.0.0
- mocking support with ``tyProxy`` that does: fallback for ``.`` operator
- overloading of ``.``? Special case ``.=``?
- allow implicit forward declarations of procs via a pragma (so that the
wrappers can deactivate it)
wrappers can deactivate it): better solution: introduce the notion of a
'proc section' that is similar to a type section.
- implement the "snoopResult" pragma; no, make a strutils with string append
semantics instead ...
- implement "closure tuple consists of a single 'ref'" optimization