Your prototype

[Armin Rigo]

Hello Galchin, hello everybody,

No more changes to the Python prototype. I am reconsidering the basic=20
principles. A posteriori I would say I found the Python-implemented ideas=20
too static, with messy ways to specify reduction rules. For example, I=20
found it very difficult to generalize the prototype to the case of arrows=20
of more than a one argument (what in OOP we would call "methods which are=20
virtual on several arguments").

On the other hand, I suspect that too opened reduction rules (in the kind=20
of these implemented in Maude) are dangerous. Only the programmer is=20
responsible for checking that the computations converge, and there is no=20
formal proof of it. We then need tricks to prevent infinite loops.

I prefer the Prolog approach, and particularly the one implemented in the=20
Mercury language : predicates (i.e. n-ary relations) are written as a set=20
of mathematical rules, and then the programmer specifies how,=20
computationally, each predicate may be used (e.g. if it is supposed to be a=
=20
function, then you tell Mercury that for any value of the "input"=20
argument(s) there is exactly one matching value of the "output"=20
argument(s)). The compiler infers which computations it should perform from=
=20
this data. The interesting point is that even if a predicate may have only=
=20
one mathematical definition, it may be used in several ways (e.g. if it=20
represents a bijective (one-to-one) relation, then for each value of the=20
"input" there is exactly one "output", and conversely). The same code works=
=20
in all "directions".

The ideas I am getting while trying to integrate the previous Python=20
prototype into a Mercury-style language, is that we should get rid of types=
=20
defined by a fixed set of constructors. Instead, all types should be=20
totally abstract, and constructors should be replaced by usual predicates.=
=20
This simple change (combined with a reflexivity Mercury mainly lacks) might=
=20
let us write programs in the same spirit that my Python prototype.

To be more specific, let me say that my goal is to dissociate the type of=20
objects from their in-memory implementation. When one wants to write an=20
image-processing algorithm, one doesn't need to bother about the way the=20
pixels are stored in memory; but on the other hand, we cannot afford the=20
(in this case high) cost of calling virtual methods just to read and write=
=20
pixels (said in an OOP world; more generally, replace "calling virtual=20
methods" by "doing any kind of indirection"). More about it later.

Of course all this is influenced by Brian's Arrows. Maybe I will eventually=
=20
understand Arrows well enough and find out that it is actually exactly what=
=20
I am reaching for.


A bient=F4t,

Armin.=20