[clean-list] Passing an environment around

[Pieter Koopman]

At 09:16 19/10/00 -0200, Jos=E9 Romildo Malaquias wrote:
>Your sugestion is the first alternative to solve the problem
>I have posted in the original message of this thread. As you
>mention, there is the problem of evaluating the body of
>the operator (of type Memory -> Value) repeated times for
>the same memory, making the solution ineficient.

Agreed. I had the impression that you had difficulties to
make infix operators for this.

>Then
>you sugest making the sharing explicit in the code. That
>works for sharing in the same function definition. The
>biggest problem with that is that when you do that, you
>substitute the operators by their implementation:
>
>   x .+. y .+. y
>
>becomes
>
>   let vx =3D x mem; vy =3D y mem
>   in  vx + vy + vy
>       ^^^^^^^^^^^^
>
>That is possible in your example because you know the
>implementation of the operator .+.
>
>   (.+.) a b =3D \mem -> a mem + b mem
>
>What about complex operator definitions hidden in the
>implementation module of the library? This technique is
>not feasible for them.

What about using different instances of the same operator?

instance + [({#Char},Int)] -> Int
where (+) e1 e2 =3D \mem -> e1 mem + e2 mem

instance * [({#Char},Int)] -> Int
where (*) e1 e2 =3D \mem ->  e1 mem * e2 mem

f x y =3D x + y + y

fopt x y =3D \mem -> let vx =3D x mem; vy =3D y mem
                    in  vx + vy + vy

now the expressions in the body of the function and its optimized version=20
are syntactical equal.

This still is not very nice...
You have to indicate the sharing yourself and you need to have knowledge of=
=20
the structure of Operator, but not of required instance of +.
However, I think this is the best you can achieve without memoization.

I do not see how a referential transparent use of implicit parameters or=20
joining the algebraic expression and the environment solve the memoization=
=20
problem.

Pieter Koopman