exercitus vir

My feedback

  1. 58 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    10 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    This is possible using the following (already supported) syntax:

    let add : int -> int -> int =
    fun x y -> x * y

    The only restriction is that you currently cannot add "inline" to the function value:

    let add : int -> int -> int =
    inline fun x y -> x + y

    Lifting this restriction has been requested and approved by Don Syme here, so someone just needs to propose a tested PR: https://fslang.uservoice.com/forums/245727-f-language/suggestions/6237585-allow-inline-keyword-in-the-case-let-f-fun-a

    exercitus vir commented  · 

    Sergey, thanks for pointing that out. Since this is already possible, it does not seem that this suggestion really adds much value.

  2. 27 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    This is too much magic for my taste. If I saw `base.Data` I would look for such a field or member, but would need to remember that F# magically transforms cases of tuples with common components to this.

  3. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    You could instead just do this:

    type Note = { name: string, pitch : uint }

    module Note =
    let C = { name = "C", pitch = 0 }
    let CSharp = { name = "C#", pitch = 1 }
    //etc.

    let name = Note.C.name
    let pitch = Note .C.pitch

  4. 20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir shared this idea  · 
  5. 8 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir shared this idea  · 
  6. 492 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    16 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    I just want to repeat my question from about one year ago, because I would really appreciate some comments (concerns, feasibility, effort) from the F# team on this:

    "Any comment from Don Syme or the F# Software Foundation Language Group on the chances of simulating higher-kinded polymorphism in the near future?

    I think this is a really important feature. Many expert functional programmers forego F# because they think can't take a language serious that does not have it. The F# community is losing a lot of potential expert functional programmers [because of this]."

    This issue being more than 2 years old requires some kind of official response. Either decline it or approve it in principle, but not answering just keeps our hopes up and keeps our votes from being used for other feature requests.

    exercitus vir commented  · 

    Any comment from Don Syme or the F# Software Foundation Language Group on the chances of simulating higher-kinded polymorphism in the near future?

    I think this is a really important feature. Many expert functional programmers forego F# because they think can't take a language serious that does not have it. The F# community is losing a lot of potential expert functional programmers do to this.

  7. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir supported this idea  · 
    exercitus vir commented  · 

    You could use #endnowarn "[number]" to explicitely end a compiler directive.

  8. 3 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 →
    exercitus vir commented  · 

    I think "serializable" and "blittable" are two completely different issues and should be kept seperate. Serialization is an abstract concept that can apply to any proper data type and "blittable" seems to be about unmanaged types (I don't really understand what blittable means).

    I find serialization via attributes and Reflection less than ideal (slow and unsafe). The C# team actually wants to get away from serialization via Reflection.

  9. 14 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    Would it be possible to simply return a `byref` type to implement this feature?

  10. 9 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →

    I’m marking this as approved in principle for F# 4.×. you are invited to submit a quality and tested implementation would be needed, to be submitted to http://github.com/Microsoft/visualfsharp.

    See http://fsharp.github.io/2014/06/18/fsharp-contributions.html for details about contributing to the F# language and core library

    FWIW I’ve actually taken a look at this once or twice and it was surprisingly invasive to implement. But by all means give it a go and ask if you need help.

    Don Syme
    BDFL F# Language/Core Library Evolution

    exercitus vir commented  · 

    Isn't a single underscore just a convention? You can use any other lower-case letter or non-letter-character as a last match to match anything. It seems that the underscore itself has no special meaning in F# other than being allowed as type parameters without leading '.

  11. 31 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    I agree. Modules are compiled down to static classes anyway, so there should be no technical reason for disallowing it.

  12. 127 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    This is adding the name at compile-time right?

  13. 179 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    19 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    This is awesome.

  14. 11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →

    This is approved-in-principle for F# 4.x+

    A detailed design is needed. I would prefer one that is idiom-based and doesn’t force type providers to use a later FSharp.Core.dll

    Implementations of approved language design items 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

    exercitus vir commented  · 

    I also think that this would allow for many more interesting use cases for type providers.

  15. 181 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 →
    exercitus vir commented  · 

    I am against this. ToString() carries no semantics. To what kind of string? Is it an atomic value or structured value? Is it for logging or display to the user? There is no consistency. The ToString() method should simply be deprecated.

    You can always simply call sprintf "%A" any structural type to get a good structured representation even if its very slow.

  16. 248 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  8 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    I like that this would be independent of the package management client.

  17. 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…

    exercitus vir commented  · 

    I second the the idea of always issuing a warning. You can always disable it with an in-place compiler directive if you really don't require tail-recursion.

  18. 136 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    exercitus vir commented  · 

    Could Don Syme or someone from the F# team comment on whether this can be realized?

  19. 2 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 →
    exercitus vir commented  · 

    I also noticed that removing units of measure using functions such as `float` or `double` compiles to (in release mode) for example `(Double) doubleValue` in CIL. Unless this cast is ignored by the CLR if the value is of the same type as the desired cast, this explicit cast should not appear in the CIL produced by F#.

    I would be interested to know if currently `(Double) doubleValue` is optimized to simply `double` by the CLR to avoid unnecessary casts.

    exercitus vir commented  · 

    You could solve the safety issue by introducing a new attribute similar to `GeneralizableValueAttribute` for value restriction. For example, `TypeWithMeasure` and `TypeWithoutMeasure` should only be callable from functions with an Attribute that might be called `ValueReturnedWithMeasureAttribute` and `ValueReturnedWithoutMeasureAttribute` to prevent accidental usage of `TypeWithMeasure` and `TypeWithoutMeasure`.

    exercitus vir commented  · 

    I just noticed that the following functions also exist, but I still think that we need a generic version:

    Int16WithMeasure : int16 -> int16<'u>
    Int32WithMeasure : int32 -> int32<'u>
    Int64WithMeasure : int64 -> int64<'u>
    SByteWithMeasure : sbyte -> sbyte<'u>

    exercitus vir shared this idea  · 
  20. 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 →
    exercitus vir commented  · 

    Regarding this implementation I'd like to elaborate on what Jack Pappas said: Implementing an extension interface, would generate an adapter type and an adapter function that adapts the extended type to the same extension interface while making it appears identical to the extend type. This means that adapter type would need to inherit the extended type with all its interfaces in addition to implementing the new interface. IComparable must also be implemented to return the same result as the extended type. The only restriction is that this does not work with to-be-extended types that cannot be inherited from.

← Previous 1

Feedback and Knowledge Base