The '=>' syntax may not be manageable in F#, due to the existence of currying. The language syntax may require some sort of prefix before the parameters to settle ambiguity. But if they can do it, I'm all for it. yanov makes a good point though: Replacing keywords with terse symbols can reduce readability. Imagine if this was done for every keyword. I'm not saying everything should be a keyword, just that one shouldn't automatically favor terseness. My only complaint with "fun" is that there is also a "function" keyword, and simply being a shortened form of the word isn't enough to distinguish what they do, in my opinion.

By on 5/19/2009 7:35 AM ()

The problem with => is that it looks too much like -> and it already means lambda in curried function type signatures, but it still is a lot better than fun.
It's kinda like the "*" in signatures vs "," in definition for tuples, which I find confusing too, but still anything is welcome as long as it isn't a keyword.

By on 5/19/2009 7:30 AM ()

I don't like \

I always think of folder paths and escape sequences when I see it. On the other hand I would like to see F# adopt C# operators so => seems the right choice for me. I am having enough trouble switching paradigms and I would welcome anything that is known. There are many C# programmers out there who have not tried F# yet and it will benefit them too.

By on 5/19/2009 5:50 AM ()

I dislike the \ notation too.

However fun, a bit like new, often seems to get in the way of simple parsing and requires extra parentheses, so I'd be in favour of the => notation.

By on 5/19/2009 7:04 AM ()

I second this. Would be great to have \ instead of fun. Also, perhaps . instead of ->

1
let add = \a b. a + b

:)

By on 5/18/2009 7:51 PM ()

I second this. Would be great to have \ instead of fun.

So, y'all are trying to take the "fun" out of programming Visual F#, eh?

(someone had to say it, I'm just sorry it had to be me ;)

On the fence with this one. There are times where it does feel a tad verbose. However, I do like how fun stands out with syntax coloring... and it's only two characters different! Should be easy to experiment with... just do a global replace of (fun ...) with (\ ...) and see how you like it. After trying it on a small project with an Arg.parse list and a block of filters using lambdas, it does not really make that much difference to me either way.

Guess I'd be OK with them being synonymous, but taking the fun out completely would completely break OCaml compatibility. I bet I could think of some things I'd rather have too, like removing the need to manually qualify overloaded members with an attribute.

By on 5/19/2009 1:47 PM ()

Guess I'd be OK with them being synonymous, but taking the fun out completely would completely break OCaml compatibility

"fun" could stay in as a OCaml backward compatibility thing.
What I think makes "\" so great is that it doesn't overshadow short parameter names that are usually used in functional languages, also in heavy CPS code the "fun" stands out too much.

I bet I could think of some things I'd

rather have too, like removing the need to manually qualify overloaded

members with an attribute.

That's already being done
[link:cs.hubfs.net]

By on 5/19/2009 6:45 PM ()

I don't mind "fun" so much because it is easy and fast to type. There are few other operators that are not so easy to type, such as "|>" or "->". Maybe it's just me not being used to typing these things but they frequently act as a speed bump to my coding.

By on 5/19/2009 2:42 PM ()

Gain: your lambdas look like those in lambda calculus.

But: take a bigger example with longer named parameters and you will see that you will have to look for quite some time before you can find the "\" and the nasty "."

Added to this is that now it looks like lambda calculus but even the currying got wrong (the curried function that we get with

1
fun a b -> a+b

should be written as

1
\a.\b. a+b or \a.(\b. (a+b))

;)

By on 5/18/2009 9:24 PM ()

Mainly, it's shorter -- we don't need "fun" to recognize a lambda.

I was under the impression that \a b c. was generally accepted for \a.\b.\c.

:)

By on 5/18/2009 9:48 PM ()

I think

1
let add = \a b -> a + b

should be enough and souldn't be a problem especially with coloring in the IDE

1
let add = fun a b -> a + b

IMO obscures the code way too much

By on 5/19/2009 3:04 AM ()

This is subjective, for some readability, being able to distinguish important constructions with just a glance, is more important than terseness. You could probably save more by just making you function names shorter :)

By on 5/18/2009 8:20 PM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper