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

[Gabriel Dos Reis]

On Fri, 13 Jul 2007, Ralf Hemmecke wrote:

| 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.

I don't suggest that "pretend" be removed.  Just like general casts in C, or
similar constructs in other languages, I don't think it should be
removed and yet make Spad (or Aldor) expressive enough.  

However, I do believe that `rep' and `per' are fundamentally part
of the language semantics of domain.  I don't think Rep should be there.
Rep is quite of redundant with the pair rep/per.
`rep' and `per' are there to fold/unfold views -- they are at the core
of Spad or Aldor.

| 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.

Yes.  How would that conflict with making rep and per part of the language?

Many (most?) domains have only on representation, so it makes sense
to `optimize' the notation for the common cases.  For those that do
need more refinement, users can provide their own views and the language
will recognize that.  There is a precedence for that.  In C++ for example,
user-defined types come equipped with a compiler generated copy constructor
if user the user does not declare one.  For many value types, that is
exactly what is needed and the semantics is optimal.

So, think about this:

  (1) if a domain defines Rep, then automatically rep/per are
     generated.

  (2) if a domain defines one of per or rep, then the automatic
      definition of the other is suppressed.

| 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 %.

I sort of agree.  When you have seveval representations (algebra in universal
algebra sense) that abstract to the a given domain, then you actually
have a category (in CT sense).  Would it not be convenient to express
that in the code and actually use Spad categories?

| 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.

Well, I'm not a language designer by education.  Only by experience
and as a user.  So don't dimunish yourself :-)

-- Gaby