So, you'd have to use a : whenever you passed a function call to something like an if or a match?

a = 1
b ->

if a
   say "ok"

if b
   say "compile error"

if b:
   say "ok"

Presumably you can't use the indent syntax when using an if? Or can you?

b(n) ->

if b
   4
      say "woot"      -- ?

I like the idea in principle - it would make dsls a lot easier to write - but I anticipate problems.

b(n) ->

if b
   say "how good will the compile error be for this?"

On a side note: I don't need commas when splitting arrays and hashes over multiple lines? Awesome.

I think we need a compromise: Special syntax when defining a function, to specifically enable this indent-based usage. Think about it. Most of the time, people won't be using functions in this manner; but having to remember to put : after ifs and matches and such is going to be frustrating; not to mention visually unappealing. So instead, make it the exception:

normal-fn(n) -> n
dsl-fn(a = 0, b = 0)& -> a + b            -- & means "can be used as a dsl function"

if normal-fn
   say "perfectly fine"

if dsl-fn:
   say "needs the colon here"

if dsl-fn
   4, 5
      say "doesn't need it here"

On a side note: I don't need commas when splitting arrays and hashes over multiple lines? Awesome.

That's right, I wanted "lists" to be like natural lists, inspired by livescript/coffeescript/YAML, feels much more intuitive :-) (see #9, ctrl-f search for "List" and "Map" respectively to go directly to the details on the syntax)

Hmm, yes, it would really become ridiculous - in all control structures - since it essentially will mean expression-block-starters becomes mandatory in practice (functions are used most all of the time in Onyx, since they often "wrap"/"isolate" values as getters.)

You're also absolutely right on the error message - it will be possible to heuristically figure out what the user probably meant in most cases, and hint in the error, but that's not good enough.

Specifying behaviour per functions is no-go. The main reason in Onyx for compiling faaaast (as possible.. and we want that) is that lexing and parsing can identify everything (essential) without knowing anything of semantics (like what kind of function, or if it even is one, that a certain symbol represents). For instance C++ mixes lexing, parsing and semantics in a big O(n_hell^99999) soup, and we know how fast that compiles :-/

While the indent upon indent for if => call => if-expression-block would work, that certainly is nothing to aim for, it looks like... #!x¤$ck, and given your feedback it's clear that it falls flat to begin with.

Which brings me to an idea: since the primary use case for the call syntax is for enabling DSL'ish constructs, they should not be expected in control structures. So, when in a control-structure any indent is interpreted as belonging to the control structure - not the call.

It's an exception to the call syntax rule that is very reasonable and expected behaviour in my opinion.

Ideas?

they should not be expected in control structures. So, when in a control-structure any indent is interpreted as belonging to the control structure - not the call

Agreed. DSLs are markup, not conditional expressions.

I implemented it and it worked smoothly with the current crazy-specs without a hinge. (Better not get to happy until the trolls under the surface has unleashed their ugly fury)

Sample code using "Temel" (tested):

require "./temel/src/temel"

is-welcome = true

items = [
   "foo ya"
   "boo ya"
   "blargh hya"
]

some-name = "Burns"


my-page = html
   head
      title "Testing it out!"
      script
         { type: "bad-script" }
         "my-fine-file.bad-ass"
   body
      div
         {id: "main-div"}

         if is-welcome ? h1 "Welcome" : h2 "This is it"

         article
            h2 "The fat and the furious"
            p
               "
               Long
               article text
               here
               and stuff, mkay Mr. {some-name}!
               "

               ul items.map(~> li _1).join

      div {id: "footer"},
         nav ul
            li a {href: "asdfsadf"}, "Contact"
            li a {href: "bfadfasdf.se"}, "About"

say my-page

=> <html><head><title>Testing it out!</title><script type="bad-script">my-fine-file.bad-ass</script></head><body><div id="main-div"><h1>Welcome</h1><article><h2>The fat and the furious</h2><p> Long article text here and stuff, mkay Mr. Burns! <ul><li>foo ya</li><li>boo ya</li><li>blargh hya</li></ul></p></article></div><div id="footer"><nav><ul><li><a href="asdfsadf">Contact</a></li><li><a href="bfadfasdf.se">About</a></li></ul></nav></div></body></html>

I must honestly say, when I whipped it up to test indent-calls, I just realized it when the html came out without a snag, I was like "Aaaaaaah yeah, baby!". Didn't expect it to turn out so well so simply. This is the smoothest way of templating html I've seen (ymmv and all that ;-) ) - and it's all compiled to blazing binary code! Fuck node.js B-) Temel is to thank for not having to code poc-functions just to try it.

How about:

script { type: "bad-script" }
  "my-fine-file.bad-ass"

Was the above not an example, I would've written it:

script {type: "bad-script"}, "my-fine-file.bad-ass"

Of course you can currently write:

script { type: "bad-script" },
  "my-fine-file.bad-ass"

Supporting the same without the comma has the same strings attached as #66 - it can be done, but rules differ depending on if it's a literal or not in that case. Of course with this new perspective of DSL-usage, both are worth thinking about. If you'd like, could you add that to #66? I re-opened it.

Righty ho.