GitLab

features and bugs essential (to fix) for reliable usage

fix parser string issues + integration tests nope, rewrite
fix basic array parsing issue + integration tests nope, rewrite

parser rewrite:

1. grammar description, PEG-format with annotated semantic rules for expansions
2. rfc for grammar
3. fix semicolon issues (newlines), write integration tests (can be reused in parser rewrite)
4. complete unit tests in manual
5. test grammar description without expansion,environment variables and function piping and with parser generator against unit tests
6. write and test parser
7. write parser-tooling (test and simplify environment handling (trait stuff with dynamic dispatch), function piping, ..?)
8. document+test, how they should interact
9. stick them together in a documented and defined way

how to deal with shell variable expansions like aliases, environment variables etc? how much does nom simplify things and how much slowdown do we get from macro stuff?)

Notion of fn-scope and st-scope (function+statement-scope), copy and assignment expression to be introduced with rules. Parser shall retrieve necessary information. Inside a new function (fn-scope+1) st-scope is set to 0.

Syntax

references + mutations with function return:

fn teamonster &t1:int m2:int -> int int
  #mut err = 5 #forbidden
  let ok = 1
  mut ok += 1
  echo $m1 $m2
  mut t1 += $m2 #ok: t1 and m2 defined at current or lower function scope
  #let t1 += $m2 #forbidden
  #no references and let binding with same name in same **function scope** (starts with 0)
  #drop can only drop local scoped variables
  #scripts must be safe: variable names can only be used in {} braces "text${var}text" or "text${var}[range]text"
  #editor (and later REPL): underline escaped symbols
  #let bindings can shadow in same function scope, ie in loops, matches, conditionals
  let t1copy = $t1
  ret $t1, $t1copy
end
let tea = 2
let args = [ @(teamonster $tea 2) ]
# $tea was given as reference
echo @args

2 2
4 4

TODO clarify: env, alias and builtins interaction (representation as btreemap?). Are they checked on syntax check mode? Should we rename the syntax check mode (this is semantic information)?

#blk1:
for ...1 ; ...2 ; end
#blk2: identical with ; getting lexed to **newline**
for ...1
...2
end

speed improvement ideas:

• bumpalo for region-based allocation: Ideal for parsing?
• else: general purpose multi-thread no_std (handling out-of-memory would be ideal), but default-enabling in Linux of over-commitment breaks this anyway?!
• benchmark parsing phases?