Syntax Structure

[ozra]

[RFC] Syntax Structure

"offside syntax": significant indent and optional end tokens

Yes ,you do know how to write proper sentences ,right ? It' s
  quiteannoying  to read Improperly Formatted sentences
   .Even when
 the content is good . Here 's a run_down with about forty_seven
  Reasons
   :
     1 . You convey a message , getting the  words right is hard enough
 1 .1 : Our reasoning minds ( especially programmers) are spatially orientated
   1-2-  Not structuring information so that it conveys intent ,spatially, is a bad mistake.
1.3.
   2.  Using non_spatial constructs to convey it : {2.1 doesn't help that much does it ?;2.2 At least I don 't think so;}3. My eyes are already bleeding from this exercise— maybe someone more clear_headed likes this ?;}

Structure, indentation and white space is important. If above didn't convince you... Yes, yes, no-one worth their salt writes with such bad style -- granted -- though it did get the point across. I hope!

Onyx is structured via indentation and has optional end tokens to make block ends explicit when wanted. There's experimental pattern matching support for the end-tokens also, making it possible to match up intended block starts even more explicitly. This will likely be dropped from the syntax though.

Details:

• Both spaces and tabs should be allowed - but never mixed! Currently three spaces (yes you read that correctly) is recommended style.
  • Old-school-eight "costs" way too much column estate when sticking to 80 chars limit (which still is a good practise: edit three files side by side, diffs, etc.).
  • Two-places is too unclear - code bases where I've seen indent-fix-only check-ins have been two-places indented (and non offset-ruled)
  • After lots of experimenting over the years I've found the odd number of three to be the over all most clearest indent size. Discussions on this regarding some standard style guides is welcome.
• White space is significant in expressions to some extent.
  • Some operators have one meaning at the end of a expressive unit, an identifier, a type, and another meaning if spaced. It's obvious when seen, really. This benefits us with terser, more concise ways of expressing more things.
  • From the top off my head: (my-perfectly-legal-identifier-for-a-fn? 47) and (my-perfectly-legal-identifier-for-a-fn! 47, which is not the same as my-perfectly-regular-identifier-for-a-fn !47)
  • It is very clear even without syntax highlighting (I often read up on code bases via thick piles of print outs - perfect in the garden). And with highlighting - the separation is as clear as day and night.
  • Onyx allows juxtaposition calls, and parenthesized calls: a-func arg1, arg2 is the same as a-func(arg1, arg2), but watch out for: a-func (arg1, arg2) - that called the method through juxtaposition rule - the parentheses instead expressed a grouping (which would syntax error in this case). A reason why the ident SPACE ... precedes: a-func (foo == true), (if bar == 47 ? 1 : -1).
• Hyphens (dash), underscores, ENDASH or camelCase can be used interchangeably in identifiers - do yourself a favour and stick to one style though! That means, if there's a method defined as the-method in a lib, you can use it as the_method - if you're hell bent on avoiding fluidly readable identifiers. And vice versa.
  • a study comparing snake_case and camelCase concludes that camelCase is much slower to parse for the human brain.
  • lisp-case is much more fluent to read than snake_case, requirng less eye-relocation-movements, and it's becoming more and more popular in URI's, filenames, etc. not to mention that it's common place in (esp. germanic) natural languages. It is definitely preferred from what I can tell. However, as mentioned, currently all styles are allowed interchangeably. And studies relating to this are still very few, and not of highest quality. So there's room for discussion here.

Here's an example showing off one of the many ways below code can be written and formatted (specially cond/case syntax currently has a shitload of variations to choose from - waiting to be reduced!), including the experimental pattern matching end token extension.

type Foo
    mood = #happy
    bar = "Hey"

    speak(word, mood) ->
        @mood = mood
        speak word

    speak(@word) ->
        speak

    speak() ->
        cond @mood
            #happy
                say "{@bar} - Yeay!"
            #sad
                say "{@bar}. Sob."
            *
                say "{@bar}."
        end
    end~speak
end-type  -- could have done `end-type~Foo`, `end` or nothing.

-- don't do the below at home kids!
my-foo = Foo()
my_foo.speak "Hello", mood: #workaholistic
myFoo.speak "Hi again"

Prior Art

For offside / indentation significance: ISWIM, Python, Haskell, Nim, Cytoc-Cython ;-), LiveScript, CoffeeScript, SugarCpp, F#, etc.

The voluntary end tokens look more like Ruby, Lua, Pascal, etc., and - dare I say it - Visual Basic, for the extended semantic matching.

Preference and Motivation

I've coded in C, then C++, for a loooong time (well, aside from hoards of other languages and a lot of assembler of course). But already in '99 I had enough with the braces-semicolon syntax. I coded a simple heuristic transpiler called Cython (no relation what so ever to the project with the same name that came 9 years later), obviously inspired by Python lexicography.

I find the indent based structuring superior, after having used both, side by side, for about 15 years. "If it looks right - it is right". Not to mention that studies on the programmer's mind seem to hint at it being a better choice. Lacking only one thing in most languages that leverage it; one very important thing; the possibility of ending blocks explicitly (and doing it for long/complex blocks).

When scopes grow over more than a few lines, or nesting depth grows, those dangling ends become very... loose.

The perfect solution is of course: both!

The recommendation, as I see it, is to absolutely not use end-tokens in constructs that are just a few lines, with no complex nesting - it's just visual clutter. Beyond that it's much clearer to use explicit end-tokens, and you can catch and contain scoping and localize syntax errors much better.

Some References

• On spatial cognition and codespace mapping to mental models:
  • http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.199.5737&rep=rep1&type=pdf

[stugol]

What does a leading # signify? For example in #happy? Is it a symbol?

Suggest case instead of cond.

I approve of hyphen-case and indent-based structuring.

[ozra]

@stugol - Yes, that's it! It is referred to as Tag in Onyx-lingua, however it's the exact same thing. (see #9)

Regarding case|cond|etc. see #13.