Forums

## Cobra design points [was: Partial Application]

General discussion about Cobra. Releases and general news will also be posted here.
Feel free to ask questions or just say "Hello".

### Re: Cobra design points [was: Partial Application]

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

Posts: 24

### Re: Cobra design points [was: Partial Application]

@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.
Charles

Posts: 2513
Location: Los Angeles, CA

### Re: Cobra design points [was: Partial Application]

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

Posts: 24

### Re: Cobra design points [was: Partial Application]

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

Posts: 2513
Location: Los Angeles, CA

### Re: Cobra design points [was: Partial Application]

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

Posts: 632
Location: New Plymouth, Taranaki, New Zealand

### Re: Cobra design points [was: Partial Application]

@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.
kirai84

Posts: 24

### Re: Cobra design points [was: Partial Application]

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

Posts: 2513
Location: Los Angeles, CA

### Re: Cobra design points [was: Partial Application]

Another brainstorm - allow these 3 options

`do(a,b,c) b.method(c,a) #Regular lambda, args out of orderdo ~a.method(~b, ~c) #Serpentarium, args in orderc,d,e = 1,2,3do d.method(c,e) #Thunk, no args`
jaegs

Posts: 58

Previous