Cobra design points [was: Partial Application]

[kirai84]

All the three statements above seem quite natural to me, though I'm not a frequent Cobra user.
I think this also can be done like this:

# with do, most readable but may be tricky to parse:
t.sort(do ~b, ~a.compareTo(b))
# without "do", even more readable and tricky to parse:
t.sort(~b, ~a.compareTo(b))
# alternatives easier to parse, but seem less natural:
t.sort(~b; ~a.compareTo(b))
t.sort(do ~b; ~a.compareTo(b))
t.sort(do(~b) ~a.compareTo(b))
t.sort(do(~b) = ~a.compareTo(b))
t.sort(do ~b = ~a.compareTo(b))
# and so forth...

This could be useful especially when there are more than two args, so you need't turn it into a serpentarium.

[Charles]

@kirai84, I don't follow your syntax ideas. If the expression has the vars in the same order as they would appear in the parameter list (~a.compareTo(~b)) then what are all the "do ~b", "do(~b)", etc. accomplishing? Also, I'm expecting that if you specify "do(args)" that the "args" portion is all of the args and in order.

[kirai84]

The thing is that "do(~b)" is still shorter than "do(b, a, c)" and the "~" shows that this is not a full and ordered parameter list. Still I do agree that this isn't a good solution. I was just trying to throw in as many ideas as I can. A little brainstorm.

The only idea I like myself is

~b, ~a.doSomething(b, ~c)

against

~~a.doSomething(~b, ~~~c)

and

do(b, a, c) = a.doSomething(b, c)

(The comma after ~b is actually easy to parse).

[Charles]

Well if we're brainstorming then:

~2~b.doSomething(~1~a, ~3~c)
b~2.doSomething(a~1, c~3)

I can't recall the last time I saw more than two args in a lambda, though I'm sure it happens on occasion.

[hopscc]

And from a totally dissenting direction:
That rude sound you hear is me being violently ill

For the purported benefit of saving yourself typing a few characters explicitly specifying the closure args
( do(a, a2,..) =...
you are
- Making a simple closure unreadable - or at least less readable ( single or multiple arbitrarily placed new punctuation)
- removing for this one case the cobra-keyword-leadin paradigm for code structure used everywhere else
- introducing a new different syntax for a simple case as clearly expressed using the full ('do') format
- hiding the keyword flagging a closure/anonMethod elsewhere (do).

There is NO real benefit to this syntax and much disadvantage to introducing it ( if only in readability terms)

Leave it as do introduces closures (all cases) , explicitly specify closure args and get closure type inference working - that will cover 90% of the cases.


( not withstanding that '~' is more familiarly and suitably the character for RE ops ( ~, ~= ) (:-))

FWIW the java discussion around closures seem to be determining that the sweet spots for closures are the
0 and 1 arg (SAM) cases.

[kirai84]

@hopscc, your considerations are very reasonable, and yet I do suffer from the necessity of typing args in lambdas, and I would really appreciate such shortcut syntax for them. There IS a real benefit to it imho.

Yet another idea for the brainstorm:

def someMethod
    # Equivalent to "do(a, b, c) b.doSomething(a, c)".
    # The order of args is always alphabetical.
    # ~~ can be replaced with something else, "do(~)" for example.
    foo = ~~ b.doSomething(a, c)

    b = 42

    # ~b is the local variable declared above.
    baz = ~~ b.doSomething(a, ~b)

Using of one-letter variables is common in such cases anyway.

[Charles]

Re: hopscc's comments, the first baby step will be type inference and then we'll take stock after that. I have type inference working in a sense (in a local workspace), but problems in other areas make it useless. I'll be looking into this post 0.9.

[jaegs]

Another brainstorm - allow these 3 options

do(a,b,c) b.method(c,a) #Regular lambda, args out of order

do ~a.method(~b, ~c) #Serpentarium, args in order

c,d,e = 1,2,3
do d.method(c,e) #Thunk, no args