[Aardappel]

Yes, those are equivalent.

Multiple function arguments require a keyword in the caller, much like "else" introduces the second function argument in an if-then-else. So if "find" would take two functions, one for even and one for odd list elements, it would look like: "var i = find_even_odd [ 1, 2, 3 ]: _ > r odd: _ > r"

There are no features that prevent it from "approaching" C's speed, merely a question of implementation work. The language started out as very high level, so code generation needs to be improved to not do as many things at runtime as it currently does. The language semantics are totally able to be within 1.5x of C.

[hyperpallium]

Fantastic, thanks.

The many uses of : syntax are intriguing - lambdas, functions, control, python-style structure, data, globals. I reckon you've established it works in all cases, but I'm not yet familiar enough to see that for myself.

For initial adoption, I wonder if more regular sample code, without the special-case abbreviations, might be more effective? (Followed by the short version.) OTOH, maybe at this early stage it's best to select for developers interested/capable enough to handle it!

EDIT if : is used for both blocks and code structure, could everything be one-line (or is \n significant?) Not great style, but helps in understanding the syntax. Maybe returns and vars need their own lines?

  def find(xs, fun): for(xs) x, i: if fun(x): return i return -1

  var r = 2 var i = find [ 1, 2, 3 ]: _ > r

[Aardappel]

Yes, ":" appears a bit overloaded, though many of those cases are actually one and the same.

What would be more regular sample code? Do you mean just writing "find([ 1, 2, 3 ]) x: x > r" with explicit () and explicit variables? I agree that is easier to read, though the extreme terseness is also a feature..

Yes, everything can be one line, but in this case it would look a bit ugly:

def find(xs, fun): (for(xs) x, i: if fun(x): return i); return -1

[hyperpallium]

> Do you mean just writing "find([ 1, 2, 3 ]) x: x > r" with explicit () and explicit variables? I agree that is easier to read, though the extreme terseness is also a feature..

Yes, amd yes it depends on the purpose. For learning, it can be impossible to parse; redundancy helps distinguish parts and provides a check you got it right.

OTOH for showcasing features, IMHO, the generality of : is a more impressive feature to demo.

Anyway, it's certainly intriguing! And maybe that's the true purpose of showcase code...