Eldred Habert

I think RGBLINK's behavior can be altered as you suggest; RGBASM's however is largely due to how it generates `SECTION`s. [The comment explains it best](https://github.com/rednex/rgbds/blob/8b60efa1495128301a407e93bd7c4ac0eb0b0f1e/src/asm/section.c#L61-L66).

No, if we're changing the behavior, then it should be done right by preventing all further output to that section.

Unless there is a syntax error, modern compilers can still process the AST; RGBASM cannot do that for the same reason as usual. This is why it's especially difficult to...

Much of the codebase assumes that section sizes are valid, so I don't think it's feasible to push section sizes beyond $FFFF bytes, if going past $8000 isn't gonna crash...

One of the things for *sure*: such functions will be "pure". No side effects, only produce an expression. I would like avoiding the approach macros currently take (re-lexing+parsing a buffer),...

If so, I'll go with 0 for a first implementation, and maybe extend with a "capture" syntax later so 1 can be produced.

No, because the right-hand is always evaluated before the left-hand. The behavior that's been decided on is "output 0", and a syntax akin to C++'s captures may be added in...

Making these work in a useful way would require #619, if only because recursive functions would require the same kind of expression system rewrite that short-circuiting operators would. Therefore, and...

Lazy evaluation of symbols is important. Eager evaluation can be forced using naked braces (since #634), but lazy evaluation cannot otherwise be done.

This would be especially helpful to clarify intent, as it's neither obvious nor widely agreed upon whether X or Y goes first (typical usage is `X, Y`, but e.g. OAM...