[RFC FS-1048 discussion] - Extend ComputationExpression builders with Map : m<'a> * ('a -> 'b) -> m<'b> about fslang-design HOT 10 CLOSED

@rmunn Hmm, good point, that's an asymmetry. About the chaining concern first, IIRC, this next code block would get compiled like so, no?

// sugared
builder {
    let! x = xexpr
    return f x
    let! y = yexpr
    return g y }
// desugared
builder.Bind(xexpr, fun x ->
    builder.Combine
       (builder.Return(f x),
        builder.Bind(fun y ->
            builder.Return(g y)
        )
    )
)

First of all, I don't know the semantics of return vs yield should be a concern of this feature.

Putting aside the normal semantics of return, it we wanted to allow this to use map, I don't see any other way than:

builder.Combine(builder.Map(fun x -> f x),
                builder.Map(fun y -> g y))

Also, this would not be possible if x is used anywhere else in the expression. If x is being used later somewhere else, even in the next expression, this transformation would no longer be possible (which I think makes sense; it's not following the semantics of map anymore).

As for the other issue, what if we introduce a MapYield method as well? That way, it would be completely optional, and could have different semantics than Map. Come to think of it, maybe we should call "Map" "MapReturn" instead.

from fslang-design.

To quote https://fsharpforfunandprofit.com/posts/computation-expressions-builder-part1/#introducing-yield

At this point you might be wondering: if return and yield are basically the same thing, why are there two different keywords? The answer is mainly so that you can enforce appropriate syntax by implementing one but not the other. For example, the seq expression does allow yield but doesn’t allow return, while the async does allow return, but does not allow yield, as you can see from the snippets below.
In fact, you could create slightly different behavior for return vs. yield, so that, for example, using return stops the rest of the computation expression from being evaluated, while yield doesn’t.

More generally, of course, yield should be used for sequence/enumeration semantics, while return is normally used once per expression. (We’ll see how yield can be used multiple times in the next post.)

from fslang-design.

It's probably be worth thinking about how this interacts with Apply.

I suspect we want let! ... return ... to be desugared by MapReturn if it is defined, else Apply & Return if they are defined, else Bind and Return.

from fslang-design.

Something to consider is whether this should also apply to let! followed by yield, as well as let! followed by return. Since both yield and return have type 'T -> M<'T>, they are essentially the same operation from a monadic point of view, and let! followed by yield could also be compiled to map. But do yield and return have the same semantics from the point of view of the programmer using a CE builder? E.g., would this be meaningful?

seq {
    let! x = someSeqProducingFun()
    yield g x
    let! y = anotherSeqProducingFun()
    yield h y
}

One major difference between yield and return, of course, is the intended usage in CEs: return is intended to be used once, for a CE that conceptually returns "a single value" (for whatever "value" and "single" mean in that given CE), such as an async. While yield is intended to be called multiple times, in CEs that conceptually return multiple values, like seq. So the ultimate question is, is it meaningful to have multiple let! -> yield operations (as in the above) translated to map in a CE such as seq?

from fslang-design.

Apart from style conventions regarding return and yield, I think there is technically a difference wrt how Custom Operations maintain variable space.

from fslang-design.

cc @dsyme

from fslang-design.

Any more thoughts on this?

from fslang-design.

There's no mention of do! ... return ... in the current RFC. I suppose it'd be supported, wouldn't it?

from fslang-design.

@mistiara That would have to be considered, yes.

from fslang-design.

I just read over FS-1063 (RFC). If I am not mistaken, it now covers the cases that this RFC (FS-1048) address. Closing as this RFC is now redundant.

from fslang-design.