## Good syntax for single argument methods?

I'm looking for good non-brace syntax for a single argument method call. I can't use space since it is already taken for infix operations (e.g. x + y vs. draw circle(...)). I was thinking about using hash; e.g. draw#circle(....) where circle is a method that produces a circle shape to draw. Are there any better options that have been tried before?

As for why I don't just go with braces, I'm looking for a special syntax to capture "verb on what" in a way that can more easily be read left to right without nesting.

## Comment viewing options

### I always liked smalltalk for methods

no argument in smalltalk could be something like
aThing Display

any number would be something like
aThing DisplayAtX: left+7 Y: top+22

which means something like aThing.DisplayAtX:Y:(left+7,top+22)

### Dot notation.

if circle produces something to draw, then this is like reverse function composition:

\x . draw (circle x) = draw ◦ circle


As I don't like unicode characters too much I would probably use a dot, as in:

draw . circle(...)


### Unicode isn't a problem for

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.

### Could try analyzing the parse tree

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.)

### Consider an arrow-like operator

You could use something like F#'s reverse-pipe application operator:

draw <| circle(...)

or, maybe

draw << circle(...)

The idea is to cue the direction of data flow; a fancy Unicode pretty-printing could render it as an arrow of some sort.

Other points: although you could choose any precedence, the heavy weight of an arrowlike operator would seem to connote a low operator precedence -- compared to #, which looks high-precedence to me.

### I don't know about Scala,

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

### if it can be done well

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!

### Bite the bullet and put in the brackets, e.g., factorial.[3]

Just bite the bullet and put in the brackets, e.g. factorial.[3]

That way everything is simple, consistent, and readable.

### i think i concur

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.