Page 2 of 2
Re: Cobra design points [was: Partial Application]
Posted:
Thu Jul 19, 2012 3:44 am
by 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.
Re: Cobra design points [was: Partial Application]
Posted:
Fri Jul 20, 2012 10:33 am
by 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.
Re: Cobra design points [was: Partial Application]
Posted:
Fri Jul 20, 2012 6:23 pm
by 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).
Re: Cobra design points [was: Partial Application]
Posted:
Fri Jul 20, 2012 8:13 pm
by 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.
Re: Cobra design points [was: Partial Application]
Posted:
Sat Jul 21, 2012 1:39 am
by 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.
Re: Cobra design points [was: Partial Application]
Posted:
Sat Jul 21, 2012 2:38 am
by 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.
Re: Cobra design points [was: Partial Application]
Posted:
Sat Jul 21, 2012 8:05 am
by 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.
Re: Cobra design points [was: Partial Application]
Posted:
Sun Jul 22, 2012 8:55 am
by 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