Lambda the Ultimate

Unicode isn't a problem for me, but it would have to map to some ascii input (e.g. We can render # as open dot). But this isn't really function composition, while '.' is already used for standard noun.verb OOP syntax.

I've gone with # for now, maybe it will make sense when I post a video...soon.

Haskell differentiates between records accessors "record.value" and function composition "f . g" depending on whether there are spaces around the dot, which works quite well.

My compiler analyzes the parse tree to disambiguate between namespace qualified identifiers and method selection.

I.e., it has a separate pass where it simply looks whether "f.g.x" is the identifier "x" in namespace "f.g", or a method selector applied to a constant, like "x f.g".

But it's a bit weird and I don't think it's important if you don't expect many people to use the language.

(It's also pretty expensive. Direct expression is much cheaper.)

Oh that is nice! Either would work well. I could render

How do I tell the difference between draw circle (1,2) that translates to draw.circle((1,2)) and draw(circle(1,2)). I'm already translating x + y into x.+(y), a habit I picked up from scalac. I guess we could look at the ID, if an operator, it is a member call, otherwise it is a single argument mood call, but then I can't do nice things like "0 until 10" (which means 0.until(10))

In Ruby draw circle(1,2) always translates to draw(circle(1,2)) since "circle" is not an operator. draw + (1,2) translates to draw.+(1,2) because "+" is an operator. You need to know precedence for operators anyway, so you could have user declared operators with letters. Then "0 until 10" would work if you declared "until" as an operator with a given precedence.

It would be weird to have a textual operator, and again, from scalac, operators are just strings of non-letter symbols; precedence is defined by the leading character. I could redefine until as '..' (0 .. 10 make sense?)

So do you want textual operators like 0 until 10, or not? Either way you can have both single argument calls without braces and operator calls without braces as long as you can determine what is an operator and what isn't. If you restrict operators to non-letter symbols you can determine what's an operator that way. Otherwise you'll have to declare what is and what isn't an operator. You can't have both undeclared textual operators AND single argument calls without braces, because then foo bar baz is ambiguous: is that two single argument calls or a single bar(foo,baz) call. You need to distinguish those somehow.

I think you want brackets around arguments if you want fixed arities with no partial evaluation. If you allow partial evaluation strictly in argument order, then s-expressions make sense. If you want to allow arbitrary partial evaluation, then named arguments are required.

It worries me that some folks seem to think that as long as there are rules a machine can follow, then it is ok to come up with whatever syntax they want in the name of some kind of insane chase after concise/clearer syntax.

I'd rather have things that are slightly laborious for users but remains simple, consistent, and clear.

I'm just trying to say that if yet another language gets into the rats nest of stupid syntax tricks like scala & haxe did, well, i think that sucks and is not really in the best enlightended ux self interest of the language.

obviously my $0.02 rant :-)

I don't know about Scala, but in my experience with Haskell and Ruby the lack of parentheses everywhere helps both readability and writability quite a bit. One thing that I dislike about Haskell syntax is that you're often typing some subexpression :

foo |

Now you type a function call in that subexpression:

foo bar|

And you realize that you need parentheses now, so you go back with your cursor and insert them:

foo bar|
foo |bar
foo (|bar
foo (bar |
foo (bar )|
foo (bar |)

Another thing is that you often get more parentheses when dealing with operators:

foo (a+b) (c-d)

Whereas in C:

foo(a+b, c-d)

Ruby syntax has neither of these issues because you can write:

foo bar(|)

and:

foo(a+b, c-d)

Or if you want even:

foo a+b, c-d

then sure! But, I urge people to study deeply those other implementations with a very critical eye to find where they cause trouble. Unfortunately it seems like a lot of apologists think bad usability in these areas is OK, which personally just grosses me out. Yeah like I really want to be tracking down THAT kind of root cause for bugs / road blocks. It is often hard to turn up search results that help one quickly find out about those syntax problems. Scala has had enough time for the issues around when to use () vs. not etc. to have been bubbled up and yet most people still don't seem to see the ethical bankruptcy there, even. Still of course it is all horses for courses. My big dream would be for every language to support a simple s-expr format as well as whatever drug addled m-expr syntax they want, so that I can still use their language safely happily!

at least, whatever you do, if it ends up anything like all the confusion around such things in Scala, then it has failed. or e.g. in haxe 'properties' are methods that don't require "()" but in the end they are so fubar that i think i'd rather just put up with .getX() and .setX().

i think "simple, consistent, and readable" has won out for me over the years vs. being worried about having to type extra glyphs.

although it is a close race.