Mastr Mastic

My feedback

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

    Will, personally I can't think of any (at least atm); I also can't think what more they need to do, because after all that is their purpose.
    But how about share your thoughts and let us know what's daunting about macros.

    I mean, yeah, it can definitely be misused like any other feature, but the good thing about macros is that you can simply choose not to use them.
    They will not invade your work, but only be there for you to use when the trade-offs worth it in your opinion.
    And perhaps if macros will be implemented (fingers crossed) they could also be removed from a certain point (very much like #undefine in C & C++).

    That being said, I'd like to point out (to everyone) that all in all, macros allow you to make code more compact, shorter, succinct, readable, simpler, etc.
    That's their point (syntactic sugar).
    Now just notice how about any best practice you read in a book, online, hear from a friend will have the same reasons for usage. That's what we need, simple compact code.
    So my viewpoint is: Program with care, play nice, have macro support, and the result is a maintainable code, that is a pleasure for the eyes to see.

    Mastr Mastic commented  · 

    @Will Smith
    There is mess with abstractions as-well.
    As for the attribute, I'll mention again that this is merely an example.
    Sure, the F# team could introduce a ModuleSuffixAttribute as a shortcut, and maybe even have an optional Boolean parameter for RequireQualifiedAccess, and I was even about to suggest this but then the idea of macros came up and swiped it away because with macros you could do that + more + a lot more!

    Mastr Mastic commented  · 

    Also if I may add another macro use case:
    More aliasing functionality.

    for instance, I highly dislike having to re-type this again and again:
    [<CompilationRepresentationAttribute(CompilationRepresentationFlags.ModuleSuffix)>])

    Type aliasing can't deal with this since the result is not a type.
    Inheritance is not an option since the attribute is sealed.
    Only option I can think of to deal with these kind of cases (this is merely an example) is macros.

    Mastr Mastic commented  · 

    Fully seconded, and Bryan you're a hero for initiating this.
    Macros are so underrated and to be fully honest, in my opinion this is a must!
    I'll even go as far to say that imo every programming language should have macro support.

    For instance, I can't begin to describe how much I dislike GUI development just because you have to manually raise events and legit repeat yourself again and again and again, which just results in filthy messy code.

    Mastr Mastic supported this idea  · 
  2. 270 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    17 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Mastr Mastic commented  · 

    Should be optional, not removed (otherwise code will break).
    And I'm all for it.
    It happens to me countless of times that I forget it because my mind just always expects better.

  3. 19 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 →
    Mastr Mastic commented  · 

    I would love this, and especially if the VS would support this in the IntelliSense tooltips.

  4. 76 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 →
    Mastr Mastic commented  · 

    It makes perfect sense that this should be supported, especially for a functional language.

  5. 98 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
  6. 133 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 →
    Mastr Mastic commented  · 

    @Jack Pappas No worries there I think, this pretty much has to stay as default for the language so not to break existing-code (which I'm sure is one primary concern for the F# team).

    I do like the idea of the compiler flag very much and also I think attributes, keywords, or different syntax would be required to get more specific from one instance to another within the same compilation.

    Thanks for your input.

    Mastr Mastic commented  · 

    I'd like to expand a bit further on what I've mentioned about WPF and MVVM.
    This issue makes F# not reliable for your view-models because other than being cumbersome and tedious (`{Binding Property}` becomes {`Binding Path=(namespace:InterfaceType.Property)}` for each property.
    (You have to type `Path=` to avoid an exception)) it also introduces limitations.

    For instance, one limitation that shows up frequently is that WPF DataTemplates do not support interfaces, yet passing an interface is your only way to expose your members because they are explicit.
    (See: http://stackoverflow.com/a/327993/825637)

    Mastr Mastic shared this idea  · 
  7. 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…

    Mastr Mastic commented  · 

    I agree with Philip on the keyword, it seems much more cleaner than an attribute.

    Mastr Mastic commented  · 

    @Andrew Khmylov I cannot agree because imo `rec` is not for the compiler, it is for us, and to me very necessary.
    For instance when you re-bind a symbol for a function, to a function that uses it, how would you express yourself without using `rec` if you intend to call the previous binding or the new (recursive) one?

    Mastr Mastic supported this idea  · 

Feedback and Knowledge Base