[Aldor-l] LabelSpecies for L: LabelType -> CombinatorialSpecies L

[Ralf Hemmecke]

>> On 10/22/2006 03:06 PM, Martin Rubey wrote:
>>> I think I got something nice. Since we only need the LabelType Parameter for
>>> the structures, it really should be a parameter of that function.
>> I've thought about that, too, but I actually decided for
>>
>> (L: LabelType) -> CombinatorialSpecies L
>>
>> since that is in perfect analogy with the definition of List and Set.
> 
> Yes, but the other definition is in perfect ananlogy with Species as defined in
> Bergeron Labelle Leroux.

Right. But what does it buy you. I am more in favour of

(L: LabelType) -> CombinatorialSpecies L

and putting the algebra stuff into CombinatorialSpeciesAlgebra (which 
would include the grammar stuff). Why do you insist on doing everything 
on toplevel? Don't you like packages (or domains in that case)?

I am not saying that I insist on my design, but currently I don't see a 
real good reason to change it, because all the stuff without the L 
parameter could be done nicely in CombinatorialSpeciesAlgebra. (Hmmm, 
the latter is probably something that is called 'decomposable objects' 
in mupad-combinat.

>> Look at your definition of '=' in CharacteristicSpecies. You use 'pretend'. Do
>> you believe me that I can construct something that says that two structures are
>> equal although they are not? That makes your code not doing what it should.
> 
> I guess that refers to my question above?

I referred to the code you attached in you last mail. (Sorry, I don't 
see a question of you above.)

>> There is another reason why I decided against it. It puts the type of the
>> second argument into the Rep record. That is nothing else than Object as
>> defined in section 21.10 of the AUG. I did not want to bundle type and value
>> explicitly as data.

> Why?

Why don't we use Java then. You would get that bundeling for free and 
nicely hidden. Now in Aldor you make that explicit. I simply don't think 
that is the 'natural' Aldor way. (OK, that is just my opinion and 
totally subjective.)

>> In fact,
>>
>> Rep == Record(L: LabelType, l: List L);
>>
>> is nearly the same as
>>
>> Rep == (L: LabelType) -> CombinatorialSpecies L
>>
>> well, you had that in 'LabelSpecies'.
> 
> I don't think so. There are some differences:
> 
> * the former seems to work. 

Does the second not work? Didn't you say

LabelSpecies: with {
         coerce: ((L: LabelType) -> CombinatorialSpecies L) -> %;
         coerce: % -> ((L: LabelType) -> CombinatorialSpecies L);
} == add {
         coerce(F: (L: LabelType) -> CombinatorialSpecies L): % == {
                 F pretend %
         }
         coerce(F: %): ((L: LabelType) -> CombinatorialSpecies L) == {
                 F pretend ((L: LabelType) -> CombinatorialSpecies L)
         }
}

Even if there is not explicit Rep, but you clearly have

Rep == (L: LabelType) -> CombinatorialSpecies L

in that code.

> * If I use the second approach, species suddenly become top-level objects.

Sorry, I cannot follow. Maybe I don't understand your interpretation of 
"species" in that sentence.

> * If I just want to have the generatingSeries, why should I bother passing a
>   LabelType? This is not very natural.

I must admit that this point goes to you. But I have to think about it.

> * the latter Rep requires another layer, namely LabelSpecies. Already the
>   difficulty of coming up with a good name suggests that this is not a good
>   idea.

Why don't you like CombinatorialSpeciesAlgebra?

> I'll make a branch and see how far I get.

Fine. Maybe we should start a wiki for AC where we describe what all 
these branches are for and who is the maintainer.
Nicolas, do you know whether sourceforge provides a wiki environment?

Ralf