Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
infer module kind from its input #621
Brief Module Syntax
I propose we make it easier to compose function chains by inferring the module by examining the data type being operated on.
The existing way of approaching this problem in F# is to use List.map id |> List.map id |> List.map id. Saying List dot "List." each time is repetitive. The same goes for Seq and Array.
Pros and Cons
The advantages of making this adjustment to F# are:
The disadvantages of making this adjustment to F# are:
Estimated cost (XS, S, M, L, XL, XXL): M
Related suggestions: (put links to related suggestions here)
Affidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply:
class Mappable = abstract map : ( 'a -> 'b ) -> 'm<'a> -> 'm<'b> type Seq with class Mappable with member map = Seq.map type Option with class Mappable with member map = Option.map
Then it would be possible to just write a single
let map (f : 'a -> 'b) (collection : Mappable) = collection.map f
The syntax would, of course, depend on how #243 would eventually be implemented.
@rmunn: thanks for the class link. Nice feature. Not quite the same thing though. We could take context further than this in a sensible default direction, perhaps. I wonder if this suggestion could supplement this direction (that link is a very long thread... I skimmed some of the discussion so not completely groked as of this writing).
As I understand it, the
For this sort of inference to work, the compiler would need to be made aware that the
Since F# is always explicit, this could be achieved without any ambiguity. Name matching -- yes, but with a type to help the match i.e. eventually akin to |> function | (typeKind,name) -> Perhaps a type alias / open keyword could set up the link between module and generic parent type? @plaste " List<'t> type and the List module currently have nothing to do with each other" That's correct. Some good by convention glue holds it together.…
On 20 November 2017 at 09:31, piaste ***@***.***> wrote: As I understand it, the List<'t> type and the List module currently have nothing to do with each other, except that they kind of happen to share a name (minus the type parameter). Ditto for Array, Seq, et cetera. From the compiler's point of view, the fact that they contain functions which operate on certain types is pure coincidence. For this sort of inference to work, the compiler would need to be made aware that the List module is semantically connected to the type. Should the rule be simple name matching? Or should the connection be explicit, such as with an attribute? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#621 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABzhWUFDCa8LySSUVq8ZBextgzRhwVqFks5s4KxKgaJpZM4QhYyq> .