Yemi Bedu

My feedback

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

    Yemi Bedu commented  · 

    Hello,
    So the example of add with embedded rebalance seems to be implemented as such just direct from an algorithm (add rebalanced sub trees). That would not be the same to say that anyone would *not* want a tail recursive version (if possible). Since you can not no in advance whether l or r is heavy, you sacrifice time loss with memory foot print and readability.

    So what would be of interest are examples yay or nay for constructing a tail recursive function. As well, an inspiration from other languages about implementation. I prefer an on by default warning.

    https://groups.google.com/forum/#!topic/javaposse/j8NioEUaCuc mentions Scala using annotations to help emit errors. http://www.scala-lang.org/api/current/scala/annotation/tailrec.html

    I like that because if I add that kind of attribute, I must really want such a property of my function. The local attribute would possibly focus static analysis too. A default warning would be nice for the rest of my code. that could help with faster feedback from tooling.

    So when someone comes across the warning, what will be the hint to fix it? Should it be recommended to look for folding or other deliberate loop constructs? Do we mention that it lacks the general semantics? Thank you. Good day.

  2. 215 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  18 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Yemi Bedu commented  · 

    What is the expectation for these types to shadow each other?
    Would you want the compiler to warn about a named record that matches your anonymous one in certain use cases?
    Examples would be anonymous record of { Length:int ; Width:int } that could be in a lot of places.
    Another example is if you describe a Point { X:int ; Y:int } and later the anonymous version gets used in a function.
    Should it infer Point or just warn "a named record of type Point matches"?

    Would we want the allow declaration signatures to be anonymous

    let Girl = {Name: string ; Age: int }
    let Boy = {Name: string; Age: int }
    let greet (child: {Name;Age}) = printfn "%A" child.Name

    greet {Name="you";Age=21}

  3. 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 →
    Yemi Bedu commented  · 

    https://fslang.uservoice.com/forums/245727-f-language/suggestions/5975797-allow-implicit-quotation-of-expressions-used-as-a

    Hello,
    So I would recommend that the above be extended to work with general methods (functions)

    The definition of it could look like:
    def nameof (q:'T) = match q with
    | Quotations.Patterns.ValueWithName(o, ty, n) -> n
    | Quotations.Patterns.Let(v, e1,e2) -> v.Name | expr -> expr.ToString()

    which is shorthand for writing:
    let nameof ([<ReflectedDefinition>] q:Quotations.Expr<'T>) : string = match q with
    | Quotations.Patterns.ValueWithName(o, ty, n) -> n
    | Quotations.Patterns.Let(v, e1,e2) -> v.Name | expr -> expr.ToString()

    let y = 1

    printfn "%s" (nameof y)

    Thank you. Good day.

    Yemi Bedu supported this idea  · 
  4. 1 vote
    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 →
    Yemi Bedu commented  · 

    Hello,
    So if you have the following (0 indexed):
    printfn "%A %A[0] %A" a b c
    printfn "%A %A[1] %A" a b c
    printfn "%A %A %A" a b c
    printfn "%A %A %A[1]" a b c

    The first and fourth would seem to be a compiler error and the second and third should be okay. It seems like subtle errors can easily creep in that may not be obvious with a quick eye scan. How can this be made more clear or is it better to cancel this in favor the following:

    https://fslang.uservoice.com/forums/245727-f-language/suggestions/6002107-add-string-interpolation-to-println-syntax-from-s

  5. 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 →
    Yemi Bedu supported this idea  · 
    Yemi Bedu commented  · 

    https://fslang.uservoice.com/forums/245727-f-language/suggestions/5674940-implement-syntactic-macros

    Allowing my suggested function extension or macros would allow this implementation to be trivial. I explain this again below:
    -----

    So what would be nice is to extend the resolution of function parameters so that they wrap their parameters to be quotation expressions if it is a macro definition. Otherwise it would pass in the direct object value as normal. We can introduce a new keyword to make the distinction.

    The definition of it could look like:
    // def is a let that will pass in arguments as a Quotations.Expr
    def nameof (arg:Quotations.Expr) : string = match arg with | Quotations.Patterns.Let(v, e1,e2) -> v.Name | expr -> expr.ToString()

    let y = 1

    printfn "%s" (nameof y)

    The boxing will just find the most local definition of parameter if it is a variable or wrap the expression directly as <@ expression @>
    This could allow us to use a lot of existing code and framework already in F#

  6. 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 →
    Yemi Bedu supported this idea  · 

Feedback and Knowledge Base