[m-rev.] for review: simplify and clarify the code implementing lambdas

[Julien Fischer]

On Thu, 3 Jun 2021, Zoltan Somogyi wrote:

> Break up a very large predicate.
> 
> compiler/lambda.m:
>     Break up the predicate that converts a rhs_lambda unification
>     to the code that constructs a closure, to allow its pieces
>     to be understood more easily.
>
>     We can construct a closure in one of two ways. In the general case,
>     we have to construct a new predicate for the closure goal, but in
>     some cases, when an existing predicate is being curried, we can use
>     that existing predicate.
>
>     Before this diff, the code that tested whether we could curry an existing
>     predicate was in the *middle* of the code needed for the general case,
>     though the size of the predicate made that fact hard to see.
>
>     This diff moves to separate new predicates
>
>     - the code that tests for whether currying is possible, and
>     - the code that handles the general case.
>
>     To make the new predicates easier to understand, pass them the info they
>     need in the packaged form of the RHS of the old unification.
>
>     Likewise, in the some existing predicates, pass a RHS as a whole instead
>     passing its components separately (and not even next to each other,
>     much less in the same order).
>
>     In some predicates, change argument orders to conform to our style
>     guidelines.
>
>     Give some variables better names. (For example, the old code named
>     a variable containing the list of arguments of a construction unification
>     its "nonlocals", which is wrong in at least two separate ways.)
>
>     Move a predicate to make predicate definition order match predicate call
>     order.
>
>     Replace some bools with values of bespoke types.
> 
> compiler/float_regs.m:
>     Conform to the changes above.

That's fine.

Julien.