rep, per, Rep in SPAD/Aldor, was: Re: [Axiom-developer] Unions in Spad

[Ralf Hemmecke]

> However, many times I've come across to bugs in the Spad compiler
> either unable to perform that automatic conversion, or that automatic
> conversion seriously confuses it.  Note also that if an operation
> is defined on both $ and Rep, then on takes precedence.  That choice
> should be left to the user, who knows what he/she intended.

Exactly.

> Therefore, I see a need for per and rep.  In fact, in my local
> tree I have both per and rep -- but unlike Aldor, they are not
> macros: they are built-in operators.  Ideally, I would like to
> see pretend uses close to zero.

I agree that pretend should almost never be seen in higher level code. 
That rep and per are just macros in Aldor is not really problematic.

rep, per, Rep are *not* part of the Aldor language. (Gaby, I know that 
you know.)  Although, all this macro business is a bit hard to 
understand, I would not really agree to add rep, per, and Rep to the 
language specification. The "pretend" is enough. I would only say that 
they should become part of the language if "pretend" disappears. but 
then we trade one construct for three. And maybe "pretend" cannot be 
made superfluous.

Why am I saying this? Maybe Martin now starts to listen more 
carefully... ;-)

In Aldor-Combinat, our species export two functions (simplified)

  structures: Set L -> Generator %;
  isoTypes:   Set L -> Generator %;

where L is the domain of labels of the structure.

I have not really a full picture yet (so don't take that overly 
serious), but sometimes it comes to Martin's and my mind that isotypes 
should actually return something else. For example, take Partition. 
structures, would return set partitions while isoTypes (currently) 
return representatives of an equivalence classes (a.k.a. isomorphism 
type). Clearly these equivalence classes are in one-to-one 
correspondence with integer partitions. Integer partitions could be 
handled much more efficiently. So it would be useful to have 2 different 
representations for one domain.

Let me for a moment even use an additional symbol %2. I'd like to say

  isoTypes: Set L -> Generator %2;

Of course that doesn't work in Aldor, but to my current knowledge it 
seems that having several of these % symbols would better fit to the 
multisort-algebra view on domains. It is not always the case that just 
one carrier set is the most important and called %.

This is another hint why I would rather not like Rep, rep, per as new 
keywords. That is too restrictive.

I am not a language guy so please point me to the nonsense that I have 
written.

Ralf