Bryan Edds

My feedback

  1. 4 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      1 comment  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
      Bryan Edds supported this idea  · 
      Bryan Edds commented  · 

      To help support abstract data types as explained here - https://vimeo.com/128464151 - and as discussed in a bug report here - https://github.com/Microsoft/visualfsharp/issues/984

      I propose that we add one exception to the proposed rule, rendering it -

      "Restrict "private" for items in namespaces to mean "private to the namespace declaration group" [except where functions are defined in a module with the same name as the type and in the same namespace.]"

      We can create module with the same name as the type in namespace by using the [<CompilationRepresentation (CompilationRepresentationFlags.ModuleSuffix)>] attribute on the module, which is a common technique in F#.

      This may seem like a minor exception, but it will keep from breaking code that heavily uses the above abstract data type style, such as here - https://github.com/bryanedds/Prime

      - and here - https://github.com/bryanedds/NuGameEngine

    • 80 votes
      Vote
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        Signed in as (Sign out)
        You have left! (?) (thinking…)
        5 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
        Bryan Edds supported this idea  · 
        Bryan Edds commented  · 

        Just ran into this problem today, and worked around it with the scary inline workaround :) Would be nice if this worked and didn't cause any problems elsewhere!

      • 168 votes
        Vote
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          Signed in as (Sign out)
          You have left! (?) (thinking…)
          15 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
          Bryan Edds commented  · 

          Hi Don!

          I somewhat regret suggesting lensing semantics for -

          let a = { a with B.C = c }

          This is because B is currently used to specify the containing type of C.

          Instead, I really do think we want a semantics for this more unique syntax -

          let a = a.B.C $= c

          Why overload existing syntax if we don't have to?

          Bryan Edds commented  · 

          I think those are just a matter of defining the right operators.

          I think also there is a marked difference in the scope of what Haskell's lenses accomplishes and what we actually need in F#. The two may differ more than one may initially think. Or not - I too am no expert.

          However, I think it would be great to ask Edward Kmett himself to take a look at the lens proposal during the design process. Though he is busy as always, and even though he's not an F# user AFAIK, I think he would willing to prioritize some time for it.

          I have his contacts, and he spends a good deal of time on #Haskell on Freenode IRC.

          Bryan Edds shared this idea  · 
        • 457 votes
          Vote
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)
            You have left! (?) (thinking…)
            under review  ·  37 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
            Bryan Edds commented  · 

            To amend my previous comment, I have to say that I quite urgently would also like this functionality to work for non-record property getters now. This is because I now use type extensions to provide syntactically clean getters to dynamic record-style fields like so -

            type Entity with
            ____member entity.CharacterType = entity?CharacterType : CharacterType
            ____static member setCharacterType (value : CharacterType) (entity : Entity) = entity?CharacterType <- value

            With this, I can do this -

            let ct = character.CharacterType

            and

            let c = Entity.setCharacterType ct c

            I know this contradicts what I said earlier, but I need this functionality very badly. Doubly so in the face of needing first-class lenses in F# (that is, support for lensing with F# syntax rather than with a library - tho that is a different subject for the most part).

            Bryan Edds commented  · 

            After further thought, I want to provide an alternative to this suggestion. While the original proposer suggested turning record fields AND class properties into functions, I think only the former should be suggested due to the weakness of the type inferencer.

            Consider this -

            type Record = { Member : int }
            fun record -> record.Member // This line compiles fine...
            (record.Member) // Therefore this syntax should remain a part of this proposal.

            type Class (aMember : int) = let Member = aMember
            fun obj -> obj.Member // This line does NOT compile!...
            (obj.Member) // Therefore, this syntax should NOT be a part of this proposal.

            I think we should concentrate only on getting the syntax working for record fields, and then once that hurdle is cleared, we should consider making the proposed syntax work for the other things that the inferencer is not so handy with.

            * While I say the inferencer is weak in this case, I don't mean that as a critique. In fact, I think the weakness is beneficial and necessary to properly idiomatic programming in F#. A lot of people arbitrarily use classes in F# where a record would be more appropriate due to its functional idomaticy. Doing so confounds their API and pollutes the code of its end-users. Having the inferencer punish such practices by requiring noisy type annotations _is a good thing_. In doing so, we come to understand and respect the power of intelligent limitations.

            Bryan Edds commented  · 

            I believe the ideal syntax for this in F# would use precisely Loic's suggestion of -

            (.Name)

            This should be usable for all the different types of members including record fields, properties, object members, et al. The alternative of -

            #Name

            - would be confusingly close to SML's, collide with OCaml's object member syntax, and too far afield from F#'s intended syntax.

          • 453 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              38 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
              Bryan Edds commented  · 

              Hi mavnn!

              It would be interesting to see some explanation of what the semantics of better / expanded type providers and quotations would entail, along with a couple of examples demonstrating how they would obviate macros.

              Would you or Dave mind writing something like that up as an F# user voice suggestion so we can study upon and vote for it?

              Bryan Edds commented  · 

              Dave and all,

              Here's a super nice macro use case; Making FSCL more syntactically elegant. FSCL is amazing, but the amount of attributes and <@code quotation symbols@> flying around in its usage code makes it much harder to read and write than it should be, as well as error prone -

              "Ah, why doesn't this work?! Did I leave out an attribute or parameter again?"

              Imagine all that encapsulated behind a DSL that looks like first-class F# syntax - all just by opening the appropriate module.

              Could expanded code quotations and / or type providers really obviate macros in cases like this?

              Bryan Edds commented  · 

              Hi Dave!

              Could you elaborate on what you mean by 'expanded' in these cases, and perhaps give examples where they would obviate macros?

              Bryan Edds commented  · 

              I'm starting to wonder if there is a bit of confusion between textual macros (like those found in C and C++) and my suggestion of syntactic macros.

              For surefire clarification, here are links describing each -

              Textual Macros - http://en.wikipedia.org/wiki/Macro_%28computer_science%29#Text_substitution_macros

              Syntactic Macros - http://en.wikipedia.org/wiki/Macro_%28computer_science%29#Syntactic_macros

              The difference between the two is very big, and I too would object to any suggestion of putting textual macros in F#! :)

              Bryan Edds commented  · 

              * Just for clarification *

              The compiler switch for enabling macros should allow new macros to be defined. Using existing macros should not require a compiler flag. This way, library developer can opt-in to access macro implementation syntax, and consumers can use library macros more transparently (either as if they were an ambient language feature, or a custom syntax imported from an F# namespace / module).

              Bryan Edds commented  · 

              Sorry I haven't been posting the use cases for macros like I promised - I've been in the hospital for 4 days now (obviously unrelated).

              Will, if macros are only able to be enabled via a compiler-switch, it will not effectively change the language for the typical user, so there are no direct down sides there.

              For people who need to program at the language level (such as framework developers), macros are a must (at least in a black-box language like F#). For those who have only ever consumed those types of services (as opposed to writing them properly), they will only see macros through the the Blub Paradox - http://paulgraham.com/avg.html .

              Therefore, only programmers who write at the language level will ever turn on the feature, but those who blithely consume our work will keep the feature off - if they even know it exists in the first place.

              * Yes, F# is a black-box language. Just because the compiler is open source does not mean it is white box. If you want to see a white box language, look at AML here - https://github.com/bryanedds/OmniBlade

              Bryan Edds commented  · 

              Macro use case of the day -

              If we can allow macros to be imported based on a containing namespace / module, various DSL contexts could be opened separately, without clashing.

              Bryan Edds commented  · 

              Macro use case of the day #3 -

              Let the community take more of a role in prototyping new F# language features with macros instead of forcing them to hack their own private compiler branch and thereby losing all portability.

              Bryan Edds commented  · 

              Macro use case for the day #2 -

              Implement F# features outside the compiler so that even idiomatic F# code can be back-ported to OCaml.

              Bryan Edds commented  · 

              Tomas, my friend, you ask for too much! I will attempt to post one use case for F# macros here every business day as long as I can manage :)

              For today, the use case is more-automated generation of lens values. Lenses, both full and partial, are no where near first-class enough in F#. You can't do real FP without them. Macros should bring us closer, and also give a prototype showing how the language implementers might design them in the case they do make them first-class.

              Bryan Edds shared this idea  · 
            • 150 votes
              Vote
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                Signed in as (Sign out)
                You have left! (?) (thinking…)
                under review  ·  10 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
                Bryan Edds commented  · 

                Please don't do this. If you look at how badly variances complicate scala code and it's type system while realizing how surprisingly non-useful the feature is in practice (which is precisely as Jon H says), you realize such a feature is a net loss.

                If you're wanting variance for interop, just remind yourself how much smaller this problem is, and how much easier it is to work around, than all the other problems with writing interop code.

              • 37 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
                  Bryan Edds commented  · 

                  This is silly. You have many alternative options -

                  [1; 2; 3; 4] |> List.map ((+) 1)

                  [1; 2; 3; 4] |> List.map (add 1) // where add = (+)

                  [1; 2; 3; 4] |> List.map incr // where incr n = n + 1

                  These are all equivalent and good enough.

                • 116 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                    6 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →

                    Marking this as “approved in principle” per comment below.

                    However it will be a difficult feature to land in practice and will be subject to very many caveats and likely limitations. There’s no certainty that this will make it into F#.

                    We will open an RFC for it eventually (it won’t be fast :) )

                    https://github.com/fsharp/FSharpLangDesign/tree/master/RFCs

                    Don Syme
                    F# Language Evolution

                    Bryan Edds commented  · 

                    I think this is very interesting and would love to hear about its advantages and disadvatages from the F# team.

                  • 67 votes
                    Vote
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      Signed in as (Sign out)
                      You have left! (?) (thinking…)
                      under review  ·  4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
                      Bryan Edds commented  · 

                      I like this, though I don't know what the downsides might be.

                    Feedback and Knowledge Base