Syntax Flow, Unresolved Ideas - Suggestions Welcome

[ozra]

Ok, with the "new" braces as part of the near future plan, it's time to shape up the fringes of Onyx syntax flow. I basically implemented the whole parser basics in just a handful of days of manic frenzy - from just starting out the first lines of Onyx. So there are a few edge cases that should be straightened out.

1 ) To a human - obvious line-continuations of expressions - requires non-indent by the compiler in at least one case, where there should be no restriction:

foo
   .bar

Above is currently not allowed - it accepts only this:

foo
.bar

I consider this a bug, a simple lookahead solves it. It works for operators already - so it's not like it's something newfangled. Will be fixed!

2 ) Now - to a muddier case that has to be decided on - I do have a leaning already to which I find more reasonable, but I'll try to stay objective:

Onyx allows "indented arguments calls" syntax, which is unorthodox, but turned out extremely clean if I may say so - for DSL'ish applications and contexts. This does give rise to a conflict in one case (two - but one has already been resolved, memory refresher follows below).

this-is
   indented
   args
   [call, mkay?]

-- Symmetrically Explicit: `this_is(indented, args, [call, mkay?])`

if this-is a, if-cond => we agree

-- Symmetrically Explicit: `if ( this_is(a, if_cond) ) { we(agree); }`

-- Earlier discussions has led to this: _in control structure "heads"_ 
-- (_conditions in an if-expression for instance_ *¹) - indent calls are not 
-- seen as reasonable, and therefore an indent in that context means "open the 
-- block for the if-control structure":

if this-is a, if-cond
    we agree

-- Symmetrically Explicit: `if ( this_is(a, if_cond) ) { we(agree); }`
-- _as opposed to:_ `if ( this_is(a, if_cond(we(agree))) )` - if seen as indent call

-- But - what about this?:
if this-is a, if-cond => and-we-begin-a-body
    and-then indent
    then-what?

Since the indent is done in the body - not the head - of the control structure - and thereby is "simply in a generic block of expressions":

• ¿ should the indent then mean to form the call: and_we_begin_a_body(and_then(indent), from(there))?
• ¿ or should we consider the one-liner expressions block(s) a special case on par with control-structure-heads? Which instead would mean this: if ( this_is(a, if_cond) ) { and_we_begin_a_body(); and_then(indent); then_what?(); }

It's not an open and shut case to me.

Are there any other gray areas anyone can think of regarding basic structure?

• ¹ - _(yes if's can be used as statements too - by simply not caring about the "return value" - but at the end of functions it's good to be aware that they in fact are expressions in Onyx - not statements like in JS/Java/C++. This feature is something one can't live without, once used to it)_

[Sod-Almighty]

if this-is a, if-cond => and-we-begin-a-body    and-then indent    then-what?

Syntax error. No other language AFAIK permits an if to have a trailing body and a nested body. It's unnecessary and ugly.

In any case, if it were to be allowed, then they should be different statements. The only time they should comprise a single call, is if the "arguments" are indented further than the start of the call:

if this-is a, if-cond => and-we-begin-a-body                                          and-then indent                                          then-what?

...which cannot be determined when using tabs for indentation, because the tab width might be anything.

[ozra]

Hmm, maybe you're right: if there are two equally - more or less - viable solutions, then neither will be clear. That probably is a better approach.

And as for the last: as you say, cannot depend on "character counts" as representing width.