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]

Postby kirai84 » Thu Jul 19, 2012 3:44 am

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]

Postby Charles » Fri Jul 20, 2012 10:33 am

@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: 2510
Location: Los Angeles, CA

Re: Cobra design points [was: Partial Application]

Postby kirai84 » Fri Jul 20, 2012 6:23 pm

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]

Postby Charles » Fri Jul 20, 2012 8:13 pm

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: 2510
Location: Los Angeles, CA

Re: Cobra design points [was: Partial Application]

Postby hopscc » Sat Jul 21, 2012 1:39 am

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: 631
Location: New Plymouth, Taranaki, New Zealand

Re: Cobra design points [was: Partial Application]

Postby kirai84 » Sat Jul 21, 2012 2:38 am

@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]

Postby Charles » Sat Jul 21, 2012 8:05 am

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: 2510
Location: Los Angeles, CA

Re: Cobra design points [was: Partial Application]

Postby jaegs » Sun Jul 22, 2012 8:55 am

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
jaegs
 
Posts: 58

Previous

Return to Discussion

Who is online

Users browsing this forum: No registered users and 2 guests

cron