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

[Bill Page]

On 10/28/07, Ralf Hemmecke wrote:
>
> On 10/28/2007 10:37 PM, Bill Page wrote:
>  > On 10/27/07, Ralf Hemmecke wrote:
>  >> Let me cite the documentation from stream.spad.pamphlet
>  >>
>  >> ++ A stream is an implementation of an infinite sequence using ++ a
>  >> list of terms that have been computed and a function closure ++ to
>  >> compute additional terms when needed.
>  >>
>  >> First, a stream is an infinite sequence. If we get
>  >>
>  >> (6) -> s:=construct([1,2,3])$Stream(Integer) (6) -> (6)  [1,2,3]
>  >> Type: Stream Integer (7) -> s.4 7) ->
>  >>>> Error detected within library code:
>  >> elt: no such element
>  >>
>  >> Then there is either something wrong with the code or with the
>  >> documentation.
>
>  > I think it is the documentation. Given the exports of Stream, it
>  > obviously should say only "potentially infinite".
>
>
> Hmmm, I think, now we can start fighting. ;-)
>

Good. :-) I am thinking in particular about the use and meaning of the
operation 'explicitlyFinite?'.

> I would be in favour of letting Stream(T) encode the
>
>    T^N
>
> where N is the natural numbers.
>
> It seems that you want Stream(T) to denote
>
>    T^N union T^(N)
>
> where the second thing denotes the set of finite sequences (which is
> actually already modelled by List or Array).
>

No, I am only talking about the way it is implemented now.

> I have nothing against a domain that models the above union, but I would
> like to start with basic domains and then build on them. And I would
> reserve the name "Stream" for the infinite thing.

I am not sure whether I would expect STREAM to always be infinite or
not. Maybe you are right since this would be the case if we wanted to
have the semantics of STREAM given by a greatest fixed point solution
(corresponding to List as least fixed point solution) of some
recursive type equation.

>
>  >>> 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 don't think you gain very much if you only consider set-like
>  >> domains. If, however, you are looking at finite fields, for sure,
>  >> you will think of a domain, since it is more important that there
>  >> are some operations that connect the elements.
>
>  > So you say it is natural to define "PrimeField 7" as a domain itself
>  > rather than defining a general domain of "PrimeFields" and
>  > constructing "PrimeField 7" as an element of that domain?
>
> Honestly, I don't see much of a difference. In your and my view
> "PrimeField 7" is a domain, which exports certain functions.
> Nobody forbids me to create a domain whose elements are domains.
> (Maybe SPAD does forbid...)

Gaby has shown how to define something of type 'List Domain' in Spad e.g.

  [Integer,Float,String]

which I suppose must qualify as a domain that has at least lists of
domains as elements. But I think a domain that actually has *domains*
as elements is something different, i.e a list of domains is not
itself a domain, as for example a Union or Product of domains would
be.

> But I think "PrimeFields" is a rather uninteresting domain. What
> exports should it have?
>
>  > Yes, I think that makes sense. But there are of course some
>  > operations that connect elements of any well defined set, no?
>
> Which? (Sorry, but I really cannot think of one.)

Ok maybe I should have said OrderedSet, then elements are at least
connected by some ordering.

>
>  > I suppose what I am saying is that (maybe) there should really be no
>  > distinction between domains and members of domains (objects) - that
>  > all objects should also be domains in and of themselves.
>
> Let's go on with your thoughts. Could you tell me what operation the
> integer 2 (considered as a domain) should export?
>

In a pure object-oriented language (which really Spad and Aldor are
not), the objects inherit operations so that the constant '2' "knows"
how to add (+) another object.

But I think I want to withdraw my comment. From a categorical
perspective such as presented by Saul Youssef (see thread [Aldor-l]
Type equivalence of domains in Axiom and Aldor, Oct 26, 2007 12:09
AM):

>       Your questions have definite answers in category theory
> and since Aldor is *almost* doing category theory, it's tempting
> to think that the categorical answers to your questions are really
> what should naturally fit into the language.  I wrote up something
> trying this out for the 2001 workshop
>
> http://atlas.bu.edu/~youssef/papers/math/aldor/aldor.pdf
>
> I still think that this is a good way to look for flaws in
> the language - implement category theory and see what
> goes wrong.

probably I really do not want the members of domains to be domains but
rather (nullary) operations which in Spad and Aldor is what they
really *are*, e.g. zero:()->%, one:()->%

Regards,
Bill Page.