This could be neat, but I think it would at the very least require a new non-conflicting operator something like:
let f x y = x + y
let f' = f (y ~ 1)
or a whole new spin on partial application, you could make it look kind of like records
let f' = (f with y = 1)
Not really in love with any of this syntax, just throwing it out there.
I would love to be able to open modules in let scopes, this would be especially useful given the way that things like unchecked arithmetic is done in F#.
I do like this idea, it would be so nice to be able to combine more active pattern cases like this.
Also, would we allow overloading in the context of these special module functions? If not it's still not a replacement for actual static classes.
It seems like this might ruin the symmetry between tupled function parameters and actual tuples, unless it could be that when you create tuples you can do the same thing, and that seems to come with a host of other problems. What if you could describe function parameters more like records and extend records to allow optional construction parameters?
I have mixed feelings about this. On one hand there have been cases where having this would be useful for porting code from other languages, on the other I'd be worried that many would start to use these in cases that are more clearly expressed as recursion and in so doing make the code much more difficult to understand and maintain.
15 votesplanned · Adminfsharporg-lang (F# Software Foundation Language Group, F# Software Foundation) responded
Approved-in-principle to make some sensible additions to the Option module
Details about naming and exact additions will need to be finalized.
We will create an RFC for this at https://github.com/fsharp/FSharpLangDesign/tree/master/RFCs
F# Language Evolution
I'm not sure if they've been defined in the 4.0 pull requests but I always define something like:
Option.resolve : 'T -> 'T option -> 'T
Option.resolveBy : (unit -> 'T) -> 'T option -> 'T
Option.tryResolve : 'T option -> 'T option -> 'T option
Option.tryResolveBy (unit -> 'T option) -> 'T option -> 'T option
Just be careful, they use exceptions for flow control in OCaml because they're cheap on that runtime. On .NET exceptions are very expensive and should not be used for standard control flow. I would consider that IOException sample to be very bad form on .NET.
30 votesplanned · Adminfsharporg-lang (F# Software Foundation Language Group, F# Software Foundation) responded
Updating to planned to indicate this is approved in general terms. A detailed design and implementation would be needed.
Implementations of approved language design can now be submitted as pull requests to the appropriate branch of http://github.com/Microsoft/visualfsharp. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for information on contributing to the F# language and core library.
Don Syme, F# Language and Core Library Evolution
It also should be noted that IDictionary does not have an ordering while the arguments do. It would be ideal to capture this information.
I could see something similar to template haskell being useful, one example of use would be generating lenses.
You know, it might just be ideal to have some kind of auto generated lenses as in http://bugsquash.blogspot.com/2011/11/lenses-in-f.html
Although, it would be ideal to be able to compose them in such a way as to avoid having to reallocate for each and every update to the same record.
I don't think this goes far enough. It would be nice to have some kind of first class typed handle to properties so we could more easily compose lenses for updating records as well.
If only I had more votes to give. This would be interop between various libraries a million times better.
As you know, I've certainly been bitten by this before. The other option would be to extend the record syntax a bit so that they can do most of the same things classes can already do.
Please no, I don't want any implicit conversions ruining my type safety.
removed “until the CLR fully supports it” from title
219 votesRichard Minerich shared this idea ·