Forums

Better lambda expressions

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

Better lambda expressions

Postby terenced » Thu Feb 24, 2011 11:44 am

It might be just me, but I find Cobra's lambda's expression ugly.
Instead of
t.sort(do(a as int, b as int)=a.compareTo(b))

t.sort( { a,b | a.compareTo(b) } )

and if we want the type
t.sort( { a as int,b as int | a.compareTo(b) } )


Not sure about anonymous methods, but maybe
.callArithmeticOp(3, 4, {a as int, b as int|
return a * b})


These are just suggestions. I like my lambda example (inspired/stolen from boo), but not necessarily the anonymous methods.
What are yours thoughts? Maybe we could have something similar to C#, with the => operator.

On a side note, what's the status of Linq in Cobra?
terenced
 
Posts: 15
Location: Montreal, Quebec, Canada

Re: Better lambda expressions

Postby FierceForm » Thu Feb 24, 2011 4:07 pm

I prefer it like it is now.
FierceForm
 
Posts: 3

Re: Better lambda expressions

Postby Charles » Thu Feb 24, 2011 11:15 pm

# For reference, here is a named method declaration:
def foo(a as int, b as int)
pass
# Let's start with anonymous methods which are obviously methods without names.
# So an anon. method could be:
def (a as int, b as int)
# But I chose 'do' as the keyword because I thought it read better in code:
do(a is int, b as int) ...

# The lack of inference on the arguments is a gap in Cobra, not a design point.
# Assuming it was supported, we are really comparing:
customers.sort(do(a, b)=a.name.compareTo(b.name))
customers.sort({ a, b | a.name.compareTo(b.name)})

# The difference is not great and the first fits in better with Cobra's use of keywords to start things off
# as well as it's existing 'def' syntax which uses an argument list in parens.

# Also, the second introduces new overloading on {} and |,
# although that's a minor point.

# I do occasionally imagine possibilities like:
customers.sort(on .name)
# That reads well and 'on' is already reserved.
# I haven't thought through the full implications
# or decided if it's worth having special language syntax just for .sort arguments.

Regarding LINQ, there are two levels to support it on. The first is at the library level which involves at least (a) reading extension methods and (b) supporting lambda expressions with type inference. I actually have (a) part way done in a workspace. We'll definitely get (b) as well.

There is also supporting LINQ with additional syntactic sugar. I haven't thought much about this and haven't decided on it.

C# supports both. You can stack up method calls with lambdas to construct a query, or use the special syntax although it does not cover all possibilities. Consequently, it's not uncommon to see the two mixed.
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Better lambda expressions

Postby hopscc » Fri Feb 25, 2011 1:27 am

The lack of inference on the arguments is a gap in Cobra, not a design point.


I would beg to differ - Its a gap in something else as there's been a notice about a fix for this on
ticket:204
and a patch and description/critique for this and its sibling on
ticket:39
both reclining in unexamined/unreplied/unapplied splendour for 9 months now....
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand

Re: Better lambda expressions

Postby Charles » Sat Feb 26, 2011 1:55 pm

Comments on ticket:39 whose patch changes the language (in addition to adding inference).
Charles
 
Posts: 2515
Location: Los Angeles, CA

Re: Better lambda expressions

Postby hopscc » Wed Mar 02, 2011 7:27 am

New (larger) patch and short description on ticket:39
hopscc
 
Posts: 632
Location: New Plymouth, Taranaki, New Zealand


Return to Discussion

Who is online

Users browsing this forum: No registered users and 48 guests

cron