[Aldor-l] Expressions and keeping operator history on rings

[Christian Aistleitner]

Hello,

following a mail from Stephen Watt (see
http://www.aldor.org/pipermail/aldor-l/2006-May/000191.html
) Ralf and I discussed the described approach.

Besides the obvious downside and advantages, we thought about what such an  
implementation would look like.

I proposed something like:

ExpressionCollectorRing( R: Ring ): with {
     Ring;
     coerce: % -> ExpressionTree;
} == add {
     Rep == Record( r: R, et: ExpressionTree )
     ...
     ...
     (+)( a: %, b: % ): % == {
         per record( (rep a).r + (rep b).r, ExpressionTreePlus . [ (rep  
a).et, (rep b).et ] );
     }
     ...
     ...
}

. Ralf thought that it might be cumbersome (and to much overhead), as
coerce( 1 + 1 )
would result in (+ 1 1) and not to the simplified 2.

I guess typically, you would not use ExpressionCollectorRing. You would  
only use it, if you want to obtain the expression tree. Then I'd not  
consider this an overhead but the "needed effect".
Of course, if you want to represent a 2 of R in ExpressionCollectorRing,  
you would adjoin a coerce function

ExpressionCollectorRing( R: Ring ): with {
     Ring;
     coerce: % -> ExpressionTree;
     if ( R has ExrpessionType ) then
     {
	coerce: R -> %;
     }
} == add {
     Rep == Record( r: R, et: ExpressionTree )
     ...
     ...
     coerce( r: R ): % == {
	per record( r, extree r );
     }
}

So calling coerce( coerce( 2 at R ) ) would give you (2). But I'd consider it  
painful to have a
integer: Literal -> %
function, which would allow 2@(ExpressionCollectorRing( ... )).
The reason is that you probably cannot properly implement such a function.  
It would require R to have integer: Literal -> % and ExpressionType.

So compared to my coerce function, its just syntactic sugar -- taylored to  
Integers.

As a consequence, you would also have to implement the same function for  
Strings and Floats.


The second question was whether ExpressionTypes should keep type  
information or omit it. Currently they omit it (except for some leaves,  
where the basic type accidentally coincides with their corresponding type).

Ralf said that it might be useful to keep type information, while I do not.
Ralf proposed that it might be useful to get 2D output and reuse this  
output (completely or in parts) as input.

There are several possible interpretations.
Do you want to use Aldor from a GUI and be able to select
  4 3    3
y z + 7x
from
  2 4 3    3
x y z + 7x +5
and copy paste it after "poly :="?

Or do you want to be able to extract parts of an expression tree from  
within Aldor code and reuse this subexpression of type T, where a type T  
is expected?


--
Kind regards,
Christian