mavnn

My feedback

  1. 39 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    29 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    mavnn commented  · 

    I'd also like to go on record as not wanting this as a feature; I say this dispite having written build scripts that *do* use #load statements in fsx files to feed the compiler source in the correct order.

    It works, but it's ugly and it's not an improvement; optionally moving this information out of fsproj files might be helpful, but I'd rather see a dedicated file for this (like fsi files for signature information).

  2. 92 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    15 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    mavnn commented  · 

    I'm out of votes, unfortunately. This would be pretty awesome, however. Alternatively, something similar to member constraints where you could say "anything that matches the signature of this interface" as a constraint.

  3. 111 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →

    Marking as “approved in principle” (it will show as “planned”).

    However, in reality it is both relatively low priority and relatively hard to implement, so I don’t expect this to happen any time soon.

    For example, we would have to reverse-map the metadata associated with F#-specific types. This is already done in F# reflection FSharpType.IsRecord and so on.

    mavnn commented  · 

    Yes please for this one; let's allow TPs to create idiomatic F# apis!

    mavnn supported this idea  · 
  4. 453 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    40 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    mavnn supported this idea  · 
    mavnn commented  · 

    @Bryan sorry for the slow response. Type providers that could take a type would allow you to generate things like lenses on the fly. Having said that...

    ... I actually very much like the idea of syntactic macros and have voted for this idea. So I'm not going to spend too long disagreeing with you!

    It does have to said that a lot of very similar functionality could be provided by better support for evaluating quotations and that may be the more practical solution in the short term.

    mavnn commented  · 

    @Bryan I don't know if this is what Dave was thinking, but a lot of type kind like functionality could be implemented by type providers that could be parameterized by type or by quotation.

    Combined with better quotation evaluation out of the box, it would cover most of the use cases I've seen so far, especially Mauricio's lens et al.

  5. 311 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    23 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →

    I am generally in favour of addressing this in F# 4.x+. I would want seq { .. } and async { … } tailcalls to also be addressed.

    A more detailed design is needed and some trialling would be great. Jack’s work is a great start. However, this is not an easy piece of work to do in a non-invasive way and my own experiments in this area have not yet led to something I feel confident to include in the F# language design.

    An implementation and testing would need to be provided by someone in the F# community (possibly including Microsoft or Microsoft Research, though not limited to them).

    Currently, initial implementations of approved language design can be submitted as pull requests to the appropriate branch of https://github.com/Microsoft/visualfsharp. See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for info on how to contribute to the F# language/core library design

    I encourage you to consider continue…

    mavnn supported this idea  · 

Feedback and Knowledge Base