Andrew Cherry

My feedback

  1. 168 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 →
    Andrew Cherry commented  · 

    I don't think my opinion has changed much from commenting back in February. Aether (disclaimer, i'm the maintainer) provides a reasonable library solution (in my opinion) given the constraints of the language. Even the limited possibilities that Aether provides have proven very useful when writing other libraries and being able to work with complex structures effectively. (See for example the approach that Freya takes to providing lenses in to OWIN state to provide strongly typed, safe access to request/response properties).

    A specific extension of the language to support lens functionality (and realistically people only seem to be talking about "functional properties" which in my head is a small subset of the usefulness of lenses and related techniques - lenses with prisms, transducers, etc. etc.) seems over specific and maybe a little short sighted in terms of not attacking the problem in a more interesting way.

    As Henrik mentions, an extension of the type system would enable us to write a far more general and useful system as a library, rather than baking specific approaches in to a language core. I'm with Henrik on this one - I would vote for careful selection of a few key extensions to the core of the language and type system which would enable new things to be built as libraries, rather than baking things that seem useful today in to the language itself. That way lies PHP.

    Andrew Cherry commented  · 

    I think I commented a bit on this elsewhere in a discussion, but it came up again just now in another context ( https://github.com/SuaveIO/suave/pull/206#discussion_r24602874 ), and @dsyme thought it might be useful to include here...

    I use lenses (Aether library), but they're not the Kmett library style of lens (which, from memory, are van Laarhoven lenses). With our type system as it stands, we're restricted to the more naive style of lens that Aether implements (get, set pairs). I do still find that they're useful however.

    (See that linked discussion for a little more detail and some examples).

    However... I'm not sure I can agree with lenses, as a concept, becoming a language feature. It's overly specific, to my mind. Either we need to be saying something like
    "We need a better way of modifying properties in deeply nested immutable data structures", which would be reasonable perhaps, or we should be saying "we need the type system to be a bit different/more to enable us to write some functional techniques which would make, e.g. lenses, possible". I'm not sure that lenses as a thing though is a language level change.

  2. 457 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  37 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Andrew Cherry supported this idea  · 
  3. 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…

    Andrew Cherry supported this idea  · 
  4. 36 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 →
    Andrew Cherry supported this idea  · 
  5. 131 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  11 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Andrew Cherry supported this idea  · 
    Andrew Cherry commented  · 

    A fairly similar syntax of let functionName ?(parameterName: [type]) () = [...] seems like it would work if parameterName became type option? That would seem like it would fit with defaultArg still, etc...

Feedback and Knowledge Base