New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplified syntax for lambda #634
Comments
I don't understand this rule:
My interpretation of your rules is that
as one of your examples, where Like most people I generally am uneasy with rules that are so sensitive to addition/removal of parentheses - F# already uses these in a few places but we've tried not to make it pervasive in the basic expression-oriented part of the language |
Thanks @enricosada
Agreed, there will be a lot of related bugs/issues raised when it's this sensitive, will frustrate more than help people. |
Without an explicit lambda boundary even quite simple expressions become ambiguous:
What about
Or with an underscore instead:
I prefer the underscore because it stands out more as a language feature but wouldn't want it to clash with #506. Would the following lambda return the property or a function to get the property?
|
@theprash I think you have nicely highlighted that as you try to remove ambiguity ... you end up nearly where you started, and for the sake of 1 less arg char/val is it worth it!? I think |
sry @dsyme i'll remove that. Later, while writing the nested usage example, i found the in Added
again, trying to write down the examples, making optional the parens may helps with some scenarios, but some of these can be better done with
Anyway, allow the optional parens add lot of corner case to discuss like You added some in the #506 (comment) about require require parentheses if the expression is non-atomic xs |> List.map it.Property
xs |> List.map it.Property1.Property2
xs |> List.map it.Method
xs |> List.map (it.Method arg)
xs |> List.map (it.Method(1,2))
xs |> List.map (it.Method().Property)
xs |> List.map (it.Method(1).Property)
xs |> List.map (it + 1)
xs |> List.map (it > 10)
xs |> List.map it.[1]
xs |> List.map it.[1..10] @dsyme added |
I'm really not a fan of |
Yeah ... can we kick |
... oh ... no Tribe Called Quest fans in the audience ... 😒 |
I think |
I would generally be in favor of removing match operation with
| Add n -> (+) n
| Sub n -> x -> x - n
| Collatz -> x -> if x % 2 = 0 then x / 2 else x * 3 + 1 Will the For reference, here's how that match statement would be written with match operation with
| Add n -> (+) n
| Sub n -> (fun x -> x - n)
| Collatz -> (fun x -> if x % 2 = 0 then x / 2 else x * 3 + 1) |
-> is right associative, so I think it would parse out correctly but I nobody should rely on my word. |
Why wouldn't deconstruct be possible e.g. given List.map(fun (a,b) -> a + b) why would this not be doable List.map((a,b) -> a + b) |
In general it looks like a nice idea however the root issues is code generation absence. Just add snippets support to Visual Studio for F# and it will be much more pleasant to write. You just type |
@xperiandri no, the root issue is not code generation absence. You still have to read fun over and over despite it providing no useful information. It's cool that you wrote snippets that cut out some of the typing but it does not eliminate the reading. |
I'm F# beginner, i've been writing C# professionally 12 years. "it"suggestion looks ugly as hell to me and i feel it would be a taint to this beatiful language. I've written lot and lot of lambdas in C# , but after using F# for a while and => feels very unnatural for F# because -> is already used with fun keyword. I think it would make language harder to read compared to just making fun keyword optional. |
@wanton7 yeah I don't really understand the "it" suggestion. I think some libraries already use => for a different meaning. I've not seen any reason why we can't just eliminate |
I don't like the 'it' version because it is too restrictive, 'it' syntax supports only 'fun it -> ...'. In fact, I think that 'function' can also be used instead of 'fun'. The 'function' can always be used instead of 'fun' and is more powerful. With 'funtion', the 'match' keyword is not needed, because you can rewrite 'match x with ...' as 'x |> function ...'. In other words, I would like if there will be a shorter syntax for 'function' lambda, one with '->' or one with '=>' such as |
oooh interesting. That does sound even more useful. |
Oh, my mistake was that |
That's an interesting question: would functions of arity 2 or higher* be given a shorthand syntax as well? I.e., would My inclination is to say that this should not be allowed, since it's too ambiguous: So I'm proposing that * Of course, all functions in F# are curried so they're really of arity 1. But F# lets you pretend that they're arity 2 or higher via |
I'm really not a fan of
ToUpper should just be a function in my opinion. As for the |
I think "it" is bad and we're all just agreeing that it's bad so I think we can agree to not do "it" and move on from that. //works perfectly fine
let x = function Some t -> t * 2 | None -> 3
//This constructor is applied to 0 argument(s) but expects 1
//not sure why it's totally okay for function but not okay with fun
let y = fun Some t -> t * 2 Pondering about this more I'm starting to see the ways that things actually get ambiguous without the fun, even with multiple arrows. At the very least if we're going to keep fun, I would very much appreciate it if we deprecated |
While the error you see can be improved, what it really means is that you are using a constructor ( // legal (but a necessary warning is raised, as it should, for missing None)
let y = fun (Some t) -> t * 2
I beg to disagree.
gets desugared to: fun x -> match x with X -> y | Y -> z Apart from its current frequent use (mainly in cases where you do not need to access the argument itself, but just need to match over it), I think making
You are right that it is currently not used, as it is an invalid operator character. Though personally, I don't like it, but that's just because I think going from On the original proposal:
The fat arrow is currently a valid operator. This would also lead to backwards compatibility issues, as has already been mentioned. I see much more in the proposals elsewhere (the link escapes me) where we allow to create implicit variables for access of properties-as-functions, something like |
While removing the How about using some special quotes and an identifier beforehand: xs |> List.map x`(x.Name)
xs |> List.map x`(x + 2)
xs |> List.map x`(x.[1])
xs |> List.map x`(Some 3, Very(Complex(x, (fun y -> x + y))))) So |
@matthid, I like where that leads to. But perhaps we can get rid of the declaration completely? Though admittedly, we'd get scoping issues for magic variables: // using "_" for illustrative purposes, any other "magic" placeholder would probably be better, as "_" now means something else
xs |> List.map _.Name
xs |> List.map (_ + 2)
xs |> List.map _.[1]
xs |> List.map (Some 3, Very(Complex(_, (fun y -> _ + y)))) // scope issue? Something along those lines would reduce clutter and lead to less parentheses. Whether doable / possible or whether it even gets traction in the community, I don't know, but I often find myself writing the same pattern again and again, esp. when just accessing a property of an instance of a class, or record. |
As an idea (another crazy idea) for member access, we could consider it an operator. Very unusual operator though (postfix, consists of non-operator characters and so on). But we can enclose it in brackets to turn into the function: xs |> List.map (.Name)
xs |> List.map (.[1]) Thus we could do without underscore sign here. |
@miegir, interesting thought, though that'll only work where there's actual class member access needed. In F# it's very common to use module functions instead, and I don't see how this syntax could be expanded to such cases. |
The idea of @miegir could be seen as super shorthand SRTP expression. |
#506 is for discussion of the member access. This issue is for discussing how to simplify syntax for lambda. Lets not get derailed into discussing that issue here. @abelbraaksma could you elaborate on the kinds of backwards compatibility issues that merging fun and function could have? It seems to me that it only expands the available options for input. function Some t -> t | None -> 0
//vs
fun Some t -> t | None -> 0
//proposed
\ Some t -> t | None -> 0 If this is certainly the case that it would cause backward compatibility issues then we should create the shorthand for function and deprecate fun. After all |
@voronoipotato Honestly, I don't see both implemented. If one is implemented the other one probably gets |
@matthid Either way discussing them both in the same place is a mess. I personally disagree since accessing members is definitely definitely not the same as a better syntax for lambdas. Yes you can torture one into the other but it's pretty visually obvious that it's torturing. |
It's just that they pretty much solve the same problem. If one is accepted there is no good reason to take the other one. Personally I'd rather have better lambdas then property shortcut (that's why I personally don't see any need to rush #506) |
I would rather have both. The fact that you don't want both is fine but that's your opinion. You can state you don't really care for #506 on that issue, however it's in many ways an unrelated issue to this one. Yes you can interpret #506 such that you can write full lambdas with it but I think that's a gross over-expansion of #506 and fundamentally misses the intent of the feature which is simply to access members/properties. //#634 is way more useful for the broader case but for member accessing....
l |> List.map (\ x -> x.Data)
//Desugars to
l | >List.map (function x -> x.Data)
//#506 is visually cleaner and more obvious
l |> List.map _.Data
//Desugars to
l |> List.map (fun x -> x.Data) Anything other than property / member access on the underscore feature is imho ugly as sin and lovecraftian. However property/member access specifically is nice and good, and completely does not step on the toes of actual lambdas. To be clear I'm not referring to your proposal of x`(x + 2), which I view as a lambda. Since there is a clear declaration of parameters and function body. I'm not entirely sure how that would work with lambdas with multiple arguments since the quote is after the argument however. |
I would back to disagree ;). Here are some arguments:
It is true that I think that either merging |
I'm realizing if you wanted to have fun match (or have function accept more than one argument) you probably need to destructure in parentheses like you do in fun. I better understand however how this is out of scope for this issue. Frankly at this point I think if I'm not simplifying the language in any way, and I'm at best saving two characters here, I just don't see how this is worth it. If we could merge the matching \ (Some t) y -> t * y | None y -> y Bringing the best of lambda and function with a more concise syntax I'm all for this issue. Then we can deprecate fun and function and have one simplified and direct way to create functions. fun of course would continue to exist for ocaml compatibility. Otherwise I simply don't see a reasonable amount of value for what amounts to yet another way to declare lambdas. We should be clearing cruft and consolidating features where possible. Having multiple ways of doing the same thing can create pain points so it's important that if we add a feature like this, that we can "kill" two others. Creating one recommended path for this. With the release could include a script that safely auto-replaces fun/function with the syntax. |
Note that deprecating anything is typically a no-go unless there are extremely strong reasons for it. I don't decide on language features, @dsyme does, and if the past is any indication, my guess is he wouldn't (ever?) deprecate something so fundamental as I think there's more chance for syntax like in the |
Yeah, fun to λ only saves 2 characters anyway. It's not like we can't create font ligatures that do this, because someone already is in the process of adding a fun to λ ligature into firacode. I think adding a third way of doing lambdas is bad. If deprecation can't meaningfully happen it's probably just not worth it. |
I'd also like to see the 'fun' keyword be made optional. Seems like a pretty popular opinion here. Any chance this will actually make it in the language? |
I guess that depends on someone being able to find all the corner cases involved and doing the actual implementation ;) |
I propose we add a simplified syntax for lambda. this helps to cover some scenarios, not to completly replace the
fun
syntaxA scenario: F# allow easy value transformations (
map
, etc), who lots of time use simple rules, so short lambdaThe existing way of approaching this problem in F# is like
Current:
xs |> List.map (fun x -> x.Length + 1)
actualTwo proposed solutions:
xs |> List.map (x -> x.Length +1)
drop thefun
keywordxs |> List.map (x => x.Length +1)
drop thefun
keyword, use fat arrowxs |> List.map ( it.Length + 1 )
use newit
in blockAlready proposed variant, but who cannot use the value like
(fun x -> x + 2)
so discarted it for this proposal for a generic lambda (is discussed in #506),xs |> List.map (.Length)
xs |> List.map _.Length
( in Allow _.Property shorthand for accessor functions #506 )1 Drop
fun
This shorten just a bit the sintax
2 Drop
fun
, use fat arrowThis shorten just a bit the sintax, and is familiar with other lang like c#.
3 use a new keyword
it
like :Rules:
(fun (x:int) -> x +2)
doesnt exists, just usefun
. or( let x : int = it in x + y)
as normal expression(fun (x,y) -> x +y)
doesnt exists, just usefun
. or( let x,y = it in x + y)
because is a normal expression( it.Name )
not(it.Name)
)fun
, is expected to be a binding in scope, like normal bindingxs |> List.map ( Some 3, Very(Complex(it, (fun y -> x + it)))))
Some variations:
1
and2
about nested usageA
andB
about parens (optional vs mandatory)Variation 1
fun
if nestedxs |> List.map ( Some 3, Very(Complex(it, ( it + it )))))
doesnt compile, and is error prone anywayxs |> List.map ( Some 3, Very(Complex(it, (fun x -> x+ it )))))
okVariation 2
Variation A
Variation B
List.map it.Name
vsList.map ( it.Name )
is not that much as overhead for a consistent sintax (as a note,List.map _.Name
from Allow _.Property shorthand for accessor functions #506 can cover this additional shortcut sintax)Pros and Cons
The advantages of making this adjustment to F# are to allow simplified lambda block, with a consistent sintax for both shortcuts like
(fun x -> x.Name.ToUpper())
to( it.Name.ToUpper() )
(fun x -> x + x)
to( it+ it )
The disadvantages of making this adjustment to F# are:
fun
keyword. butit
wasfun
until it lasted (sry, i had to)it
used in fsi repl. but becauseit
get shadow'ed, is not that much a problem for backward compatibility (old code doesnt use new sintax)Extra information
Estimated cost (XS, S, M, L, XL, XXL): XL
Related suggestions:
_.Property
shortcut)More related work:
_.Prop
sintaxAffidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply:
The text was updated successfully, but these errors were encountered: