Oil language syntactic/semantic issues

[andychu]

• what is the exit status of var, setvar, func, proc, etc. ? Sometimes we die hard, but sometimes return 1 and let errexit take care of it. (moved to test and document var x = $(false) #942
  • note that inline function calls may fail in the middle of a command
• What's the exit status of a block? -- blocks don't have exit status, commands do
• But what about the exit status of the builtin that calls the block?
  • cd, shopt, shvar, env, etc. -- it's generally 0; failure can be handled in the block
• should there be lexical scope ? (deferred)
• Should setvar / set respect dynamic scope?
  • or only modify locals and globals, with do setvar(name, val, up=1) for modifying up the stack?
  • note that LookupVar in oil_lang/expr_eval.py only looks up locals and globals
  • maybe you need setglobal too?
• var sum = 1 fails because sum() function already exists. Maybe only check locals. Globals are OK to shadow.
  • fixed after changing var / const / setvar semantics
• errors and exceptions -- try/catch, or anything else?
  • mostly fixed with if try
• how to throw away return value? e.g. = myfunc() without pretty printing.
  • can't use do, pass is discouraged.
  • solution: _ myfunc()
• block syntax: change it to x = ^( echo hi ), and dicts should go back to {} so they're consistent with every other language, and JSON
• Should break and continue be allowed within blocks?

Example:

for x in 1 2 3 {
  cd /dir-$x {
     break  # probably don't want this?
  }
}

• Fully-nested data structures: Fully nested data structures #741
• by default, math shouldn't overflow. (Does this means we need operators that explicitly overflow, like Swift? It uses &+ &- and &* for overflowing operations.) See language semantics shouldn't depend on the compiler #824

Syntax

• "$len(x)" should be an error, because ( isn't respected?
  • "${len}(x)" is the unambiguous way to write it.
  • ${len(x)} will be accepted
• what to do about singleton tuples? (resolved)
  • tup(42)
• x = class is invalid -- do we need a different way to handle keywords? I think so
• back out of div / mod / xor ? To match Python / C++ / Tea
• ++ operator for concatenation

Shell Collisions

• if ((0,0) > othertuple)) { isn't parsed right!
  • probably need a parse_legacy mode or something. Maybe the new lex_mode_e.OilCommand mode will disallow it. (OilCommand lexer mode #630)

[andychu]

I think it should be:

• Tuple([1, 2, 3]) -- takes an arbitrary iterable
• tup() -- empty tuple
• tup(x) -- singleton tuple

[andychu]

Hmm everything here is taken care of or moved to another issue!