Why would I want to use the upcoming let! ... and! syntax?

Question

The language suggestion states that the advantages are detailed in the linked paper. I had a quick skim through and I can't see it spelled out explicitly.

Is the advantage just that each statement gets executed in parallel so I might get a speed boost? Or is there some kind of logic it caters for, that is not convenient using the usual monadic let!?

I understand that, this being applicative, means that it comes with the limitation that I can't use previous expressions to determine the logic of subsequent expressions. So does that mean the trade off is flexibility for efficiency?

score 6 · Accepted Answer · answered Sep 03 '20 at 13:17

6

The way I understood Don Syme's description, when I read it a while ago, was every step in the let! ... and! ... chain will be executed, unlike when you use let! ... let! .... Say, for instance, that you use the option CE. Then if you write

option {
    let! a = parseInt("a")
    let! b = parseInt("b")
    return a + b
}

only the first let! will be executed, as the CE short-circuits as soon as it meets a None. Writing instead let! a ... and! b = ... will try to parse both strings; though not necessarily in parallel, as I understand it.

I see a huge benefit in this, when parsing data from external sources. Consider for instance running

parse {
    let! name = tryParse<Name>("John Doe")
    and! email = tryParse<EMail>("johndoe@")
    and! age = tryParse<uint>("abc")
    return (name, email, age)
}

and getting an Error(["'johndoe@' isn't a valid e-mail"; "'abc' isn't a valid uint"]) in return, instead of only the first of the errors. That's pretty neat to me.

answered Sep 03 '20 at 13:17

torbonde

2,459
1
15
17

3

Additionally, each computation is independent from one another. One cannot depend on the output of another. This is a restriction, but can also be beneficial because any engine that processes them can trivially parallelize them. – Phillip Carter Sep 03 '20 at 17:29
1

There is also a perf benefit where the compiler and compute what the call graph looks like up front. This isn't likely to be all that large of a perf benefit though. – Phillip Carter Sep 03 '20 at 17:30
@PhillipCarter In the Dom Syme link, the definition of `Result.zip` does not seem to accumulate errors so presumably this implementation would not work as this answer describes. Is is a simple matter of amending the definition of zip to get it to work in this way? – Chechy Levas Sep 03 '20 at 18:04
1

There are two possible applicatives for Result, the short-circuit one and the accumulative. The accumulative was probably not used in that sample because it doesn't form a monad, so you won't be able to see the benefit of switching from monadic computation expressions to applicative ones. – Gus Sep 04 '20 at 07:57

score 4 · Answer 2 · answered Sep 03 '20 at 20:53

I am excited for this for two reasons. Potentially better performance and that some things that can't fit into the Monad pattern can fit into the Applicative Functor pattern.

In order to support the already existing let! one need to implement Bind and Return, ie the Monad pattern.

let! and and! requires Apply and Pure (not exactly sure what F# the equivalent are named), ie the Applicative Functor pattern.

Applicative Functors are less powerful than Monads but still very useful. For example, in parsers.

As mentioned by Philip Carter, Applicative Functor can be made more efficient than Monads as it's possible to cache them.

The reason is the signature of Bind: M<'T> -> ('T -> M<'U>) -> M<'U>.

One typical way you implement bind is that you "execute" the first argument to produce a value of 'T and pass it the second argument to get the next step M<'U> which you execute as well.

As the second argument is a function that can return any M<'U> it means caching is not possible.

With Apply the signature is: M<'T -> 'U> -> M<'T> -> M<'U>. As neither of the two inputs are functions you can potentially cache them or do precomputation.

This is useful for parsers, for example in FParsec for performance reasons it's not recommended to use Bind.

In addition; a "drawback" with Bind is that if the first input doesn't produce a value 'T there is no way to get the second computation M<'U>. If you are building some kind of validator monad this means that as soon as a valid value can't be produced because the input is invalid then the validation will stop and you won't get a report of the remaining input.

With Applicative Functor you can execute all validators to produce a validation report for the entire document.

So I think it's pretty cool!

Why would I want to use the upcoming let! ... and! syntax?

2 Answers2