ozra / onyx-lang

The Onyx Programming Language
Other
97 stars 5 forks source link

Suggestion: commas optional #66

Closed stugol closed 8 years ago

stugol commented 8 years ago

Some languages allow this:

fn(a,b,c) ->
   say a b c

fn 1 2 3   --- "1 2 3"

In other words, commas can be omitted. Is this feasible for Onyx?

Multiline arrays already do this to some extent, so it wouldn't be too big a departure from the established syntax.

ozra commented 8 years ago

This can only ever be possible with literal arguments like numbers, tags, lists, etc. As soon as you pop in an identifier it will be parsed as a call.

-- above rewritten as seen by compiler:
fn(a,b,c) ->
   say(a(b(c())))

fn(1, 2, 3)   --- provided the proposal in effect

I've tried it out in languages supporting it, but I felt it only ever added confusion: Once you decide to change a literal int in some code to a variable, or worse: a call, and forget to add the comma after, you have either a boring bug or, depending on overloads, a really confusing bug!

In Haskell it is standard notation, but that's because all functions take only one argument, and hence a "multi parameter function" really just takes a function as argument, calling the next, calling...

The only pro is shaving a comma. The cons are many.

This is one of those few definite no-go's.

ozra commented 8 years ago

Re-opened in light of new perspectives, there are valid use cases apart from "normal code" (where staying away from it to avoid unnecessary bugs is good - but from now on a choice.)

stugol commented 8 years ago

Commas should be optional when indenting arguments:

fn(a,b,c) ->

fn "Hello"
   "Indented"
   "Arguments"
ozra commented 8 years ago

Definitional clarification:

  1. Can only be done after a literal
  2. Commas can be omitted after args, provided 1) is fulfilled
  3. Indent-style arguments can be begun at a later point than directly after function, provided 1) is fulfilled
  4. Neither is a recommended practice unless in an obvious DSL'ish context (don't mix omissions with common structured code). Ultimately it is of course the coders decision, and also here the stylizer can simply convert back and forth to keep repo-style fully comma separated for instance.

Further: when call is discovered to be "indent arg mode", new-lines act as commas also for further args, whether literal or not, so no commas are needed when line break is used (similar to multi-line Set-, Map- and List-literals)

ozra commented 8 years ago

After trying it out a bit, it causes trouble more often than not; constants feel like literals, but aren't, and cause type-new calls, this will be a no go.