[Axiom-math] Re: [fricas-devel] Re: [open-axiom-devel] [fricas-devel] Re: [fricas-devel] Re: [fricas-devel] Re: [fricas-devel] Re: iterators and cartesian product.

[Bill Page]

On 10/24/07, Ralf Hemmecke wrote:
> ...
> I cannot live anymore without "Generator". And I very much hope it will
> make it into SPAD.
>
> > Contrast this with 'Stream' in
> > Axiom which (so far as I understand) does not require such an
> > extension of Spad.
>
> For me a stream is like a generator with memory.

It is not my intention to sound critical but I would like to
understand better this distinction. If Stream is a generalization of
Generator, why do we need Generator?

> If I step a generator then I can never repeat that step. Take (Aldor)
>
> g: Generator Integer := generate yield 1;
>
> l1: List Integer := [x for x in g];
> l2: List Integer := [x for x in g]
>
> that yields l1=[1] and l2=[].
>
> If you replace g by
>
> s: Stream(Integer) := ...
>
> you would probably expect that also l2=[1]
>
> Oh, I am totally wrong. Streams are always infinite, Generators are not.

No, there are finite Streams. For example:

(1) -> s:=construct([1,2,3])$Stream(Integer)

   (1)  [1,2,3]
                                               Type: Stream Integer
(2) -> possiblyInfinite? s

   (2)  false
                                                      Type: Boolean
(3) -> explicitlyFinite? s

   (3)  true
                                                      Type: Boolean
(4) -> t:=expand(1..)

   (4)  [1,2,3,4,5,6,7,8,9,10,...]
                                               Type: Stream Integer
(5) -> possiblyInfinite? t

   (5)  true
                                                      Type: Boolean
(6) -> explicitlyFinite? t

   (6)  false
                                                      Type: Boolean
(7) -> u:=repeating [1,2,3]

         _____
   (7)  [1,2,3]
                                       Type: Stream PositiveInteger
(8) -> possiblyInfinite? u

   (8)  true
                                                      Type: Boolean
(9) -> explicitlyFinite? u

   (9)  false
                                                      Type: Boolean

> ...
> > Yes, that is "ok" but ... we already have a domain construction
> > Product in the Axiom library that takes two *domains* as it's
> > parameters.
>
> OK if you like that so much then OK.

Hmmm.... I didn't say that I like it. ;-) I said that is the way it
works now and in Spad there is no way to overload domain names.

> As Martin said, that is very much what we do in Aldor-combinat.
> There is a Product functor that takes two species and produces
> the product species. Each species comes with a function
>
>    structures: SetSpecies L -> Generator %;
>
> So for us it would mean
>
>    for s in structures([1,2,3,4])$Times(F, G)(Integer) repeat ...
>
> where F and G would be the species corresponding to 1..9 and
> 1..4. I don't see that this makes life easier.
>

Well, that *is* exactly the model that I am considering. I like the
way Aldor-combinat works and I think it would be great if this could
be fully supported in Axiom.

The larger question remains however: When to use a domain to directly
model something that is "set-like" and when to define a higher-order
domain whose objects are "set-like"? To me this is not clear in either
Spad or Aldor.

> I am sure one could simplify some libraries so that you end up with
>
>    for s in generator()$Product(1..9, 1..9) repeat
>
> where 1..9 should be interpreted as a domain that also provides a function
>
>    generator: () -> Generator %
>
> Fine. But look closer and you see that I build again on the concept of
> Generator.
>

Yes, certainly. 'generator' is also an operation available in Axiom
for constructing objects of type 'Stream'.

> If I understand you correctly, you basically want to have the same
> functions but like the compiler to allow you to write
>
>    for s in Product(1..9, 1..9) ...
>
> as syntactic sugar for my line above.
>

Yes, I think that is accurate and essentially the way Aldor works now,
right? One might also choose a slightly more primitive solution with a
lower-level interface such as the one Gaby recently described for C++.
In any case, I think one does want to make this the responsibility of
the programmer of the domain. One could probably define a particular
built-in category known to the compiler and the interpreter with a
default implementation for 'generator'. A good candidate for such a
category would be StepThrough (although I consider that a rather dumb
name... ).

> I hopefully don't introduce too much confusion here. I don't know enough
> of the limitations of SPAD.
>

Well of course this thread is primarily about Spad and the possible
(re-)design of the existing Axiom library. Since Aldor is not (at
least not yet) an integral part of any version/fork of Axiom, Aldor is
useful as an inspiration but not for actual implementation.

Regards,
Bill Page.