You can subscribe to this list here.
2007 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(73) 
_{Sep}
(57) 
_{Oct}
(138) 
_{Nov}
(91) 
_{Dec}
(99) 

2008 
_{Jan}
(91) 
_{Feb}
(53) 
_{Mar}
(37) 
_{Apr}
(125) 
_{May}
(176) 
_{Jun}
(23) 
_{Jul}
(135) 
_{Aug}
(119) 
_{Sep}
(26) 
_{Oct}
(38) 
_{Nov}
(46) 
_{Dec}
(11) 
2009 
_{Jan}
(4) 
_{Feb}
(2) 
_{Mar}
(5) 
_{Apr}
(15) 
_{May}
(4) 
_{Jun}
(18) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(17) 
_{Oct}
(9) 
_{Nov}
(14) 
_{Dec}
(11) 
2010 
_{Jan}
(9) 
_{Feb}
(6) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}
(4) 
_{Jun}
(3) 
_{Jul}

_{Aug}
(10) 
_{Sep}
(7) 
_{Oct}
(7) 
_{Nov}
(36) 
_{Dec}
(23) 
2011 
_{Jan}
(2) 
_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(11) 
_{May}
(5) 
_{Jun}
(17) 
_{Jul}
(2) 
_{Aug}
(26) 
_{Sep}
(14) 
_{Oct}
(51) 
_{Nov}
(39) 
_{Dec}
(7) 
2012 
_{Jan}
(24) 
_{Feb}
(7) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(9) 
_{Jun}
(7) 
_{Jul}
(3) 
_{Aug}
(1) 
_{Sep}
(8) 
_{Oct}
(12) 
_{Nov}
(1) 
_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(35) 
_{May}
(28) 
_{Jun}
(14) 
_{Jul}
(10) 
_{Aug}
(3) 
_{Sep}
(6) 
_{Oct}

_{Nov}
(1) 
_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(4) 
_{May}
(3) 
_{Jun}
(2) 
_{Jul}
(2) 
_{Aug}
(2) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(1) 
2
(1) 
3
(2) 
4
(2) 
5
(1) 
6
(1) 
7

8

9
(2) 
10

11

12
(1) 
13

14

15
(6) 
16
(11) 
17
(2) 
18
(3) 
19
(1) 
20

21
(6) 
22
(25) 
23
(6) 
24
(34) 
25
(5) 
26
(2) 
27
(1) 
28
(7) 
29
(3) 
30
(3) 
31
(12) 



From: Gabriel Dos Reis <gdr@cs...>  20071031 23:59:50

On Wed, 31 Oct 2007, Bill Page wrote:  I think the lack of mutability in functional  languages like Haskell is one of the harder things to get used to but  at the same time one of it's greatest strengths. Haskell has imperative skin  check out `monad'.  Gaby 
From: Bill Page <bill.page@ne...>  20071031 20:29:04

On 31 Oct 2007 20:38:43 +0100, Francois Maltey wrote: > Hello, again > > > It's ok, but way should we require the dummy variable 't' when we can > > operate directly on functions with the higherorder function > > 'product'? I think > > > > t +> [wholePart t, sin t] > > > > is just a slightly awkward way to write: > > > > product(wholePart,sin) > > Is it the reason why you want a ?function? product (A>X, A>Y, ...) ? > No, not the real reason. My main reason for wanting the higherorder function (i.e. functional? or maybe sometimes called functor?) is that such functions arise naturally when you try to given the formal (categorical) semantics of exactly what you mean by the domain called Product (or Record). > > > > > It's a good thing that record will remain mutable and the other > > > structure product won't be mutable. So there is no ambiguity. > > > > > > > Maybe there should be both 'Record' and 'Record!' where as usual the ! > > denotes mutability? > > > I'm mot sure : mathematics don't speak about record but product > or << couples or triplets or nuplet in French >> or Tupple ? > You are right. Now Axiom and Aldor has a confusing mixture of terminology about Product, DirectProduct, Tuple, Cross, Record, ... All of these are (almost) the same kind of thing. > And Record! is the most logic, but perhaps not usable because everybody > think << Record >>. > I think it is good if 'Record' is not mutable by default and one is required to use a slightly more exotic name if you want mutability. Regards, Bill Page. 
From: Francois Maltey <fmaltey@ne...>  20071031 19:38:48

Hello, again > It's ok, but way should we require the dummy variable 't' when we can > operate directly on functions with the higherorder function > 'product'? I think > > t +> [wholePart t, sin t] > > is just a slightly awkward way to write: > > product(wholePart,sin) Is it the reason why you want a ?function? product (A>X, A>Y, ...) ? > > > It's a good thing that record will remain mutable and the other > > structure product won't be mutable. So there is no ambiguity. > > > > Maybe there should be both 'Record' and 'Record!' where as usual the ! > denotes mutability? > I'm mot sure : mathematics don't speak about record but product or << couples or triplets or nuplet in French >> or Tupple ? And Record! is the most logic, but perhaps not usable because everybody think << Record >>. 
From: Bill Page <bill.page@ne...>  20071031 18:42:43

On 31 Oct 2007 19:23:44 +0100, Francois Maltey wrote: > > And what do you think about a map as : > > map (t +> [wholePart t, sin t], [1.1,2.2,3.3]) > > where [....]creates a makeprod with right types. > It's ok, but way should we require the dummy variable 't' when we can operate directly on functions with the higherorder function 'product'? I think t +> [wholePart t, sin t] is just a slightly awkward way to write: product(wholePart,sin) > It's a good thing that record will remain mutable and the other > structure product won't be mutable. So there is no ambiguity. > Maybe there should be both 'Record' and 'Record!' where as usual the ! denotes mutability? Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20071031 18:36:53

On 10/31/07, Ralf Hemmecke wrote: > ... > Of course the A must come from somewhere, but who would like to write a > cross of two functions in that way? > > I would better have something like > > cross: (A: Type) > (A>X,A>Y) > (A>%) > > later say > > product == cross(Integer) > > and then use "product" as I did above. > Ok, that's fine. > And since this A is actually part of the Limit definition there should > rather be something like (dream dream ...) > > Limit(A: Type): ... { this introduces A > Product(X: Type, Y: Type): with {...} == add {...} > } > > within "with {..}" and "add {...}" there would be no need to say > anything about "product", since it would come through the Limit > construction. > > Oh, that is not well thought of... How would the compile know that the > function is called "product"? Hmmmmm..... > The domain constructor 'Limit', as a generalization of 'Product' needs to be defined over both a set of domains and some arrows (functions) involving those domains Limit(A,B,C, ... A>B, B>C, ... ) then 'limit', as a generalization of 'product' is the following uniquely defined exported operation limit(X:Type,f:X>A,g:X>B, h:X>C, ... ): X > % for any X, f, g, h, ... such that everything commutes. But I am not sure how best to write the signature of 'Limit'. It requires both a Tuple(Type) and a Tuple of maps involving (possibly just some of) those Type. A reasonable general syntax probably requires an extension of the compiler but special cases can be easily defined, e.g. Equalizer(A:Type,B:Type,p:A>B,q:A>B) equalizer(X:Type,f:X>A):Union(X>%,"failed") where "failed" is returned in the case p f ~= q f http://en.wikipedia.org/wiki/Equalizer_%28mathematics%29 http://en.wikipedia.org/wiki/Limit_(category_theory) > ... > >> > >> product: (X > A, X > B) > X > %. > > > > What is X above? > > Allquantified. In fact, I was thinking that the compiler would silently > introduce this "Limit(X)" from above. It might be nice to define such generic operations where any domain X (or other implicit types required for "unification") is deduced from context. I guess this would be a natural generalization concept of a "mode" in the Axiom interpreter where a type place marker can be denoted by '?', but I am not sure if this belongs in the compiler or not. > > >> You don't want to write down that function definition yourself, right? > > > Well, I would actually expect it to be exported by a basic builtin > > domain like 'Record' since that is what most directly corresponds to > > categorical Product. If this was made sufficiently general, there > > would be no need for a separately programmed domain in the library. > > I think I can support this. > Great. :) Regards, Bill Page. 
From: Francois Maltey <fmaltey@ne...>  20071031 18:23:44

Hello, > > > The main issue has to do with programming style. The forloop is a > > > construction from imperativestyle programming. Operations like > > > 'product' above operate directly on functions and return functions. > > > This is most common in a functionalprogramming style and might be > > > used for example in conjuction with another operation such as 'map' to > > > produce the same results a a forloop constrcut: > map(product(Float,wholePart,sin),[1.1,2.2,3.3]) > versus > [makeprod(wholePart x, sin x)$Product(Integer,Float) for x in [1.1,2.2,3.3]] And what do you think about a map as : map (t +> [wholePart t, sin t], [1.1,2.2,3.3]) where [....] creates a makeprod with right types. It's a good thing that record will remain mutable and the other structure product won't be mutable. So there is no ambiguity. Have a nice day ! F. the naive guy. 
From: Bill Page <bill.page@ne...>  20071031 17:16:34

On 10/31/07, Ralf Hemmecke wrote: > > Yes exactly, although I am not sure why we need both Cross and Record. > > Elements of Record are mutable, elements of Cross are not. > Ok, thanks. I am not so sure how to deal with that distinction in a "categorical" manner. I suppose mutability is an imperativestyle programming notion. I think the lack of mutability in functional languages like Haskell is one of the harder things to get used to but at the same time one of it's greatest strengths. In general I would like Aldor/SPAD to promote a more functional style without necessarily requiring it. > > PS: Shouldn't this discussion go to axiomdeveloper instead of axiommath? > Maybe you are right but recently I have been avoiding axiomdeveloper since Tim made it clear that the Axiom project per se was interested primarily in documentation and the "30 year horizon". I originally included axiommath because I thought there might still be some people subscribed there who are interested in more immediate issues in Axiom and about category theory in Axiom/Aldor. But I have to admit that the profusion of email lists about Axiom, it's forks and Aldor is confusing to me and probably to our collective disadvantage. Regards, Bill Page. 
From: Ralf Hemmecke <ralf@he...>  20071031 17:06:23

Hello Bill, On 10/31/2007 05:29 PM, Bill Page wrote: > On 10/31/07, Ralf Hemmecke <hemmecke@...> wrote: >>> The main issue has to do with programming style. The forloop is a >>> construction from imperativestyle programming. Operations like >>> 'product' above operate directly on functions and return functions. >>> This is most common in a functionalprogramming style and might be >>> used for example in conjuction with another operation such as 'map' to >>> produce the same results a a forloop constrcut: >>> map(product(Float,wholePart,sin),[1.1,2.2,3.3]) >>> >>> versus >>> >>> [makeprod(wholePart x, sin x)$Product(Integer,Float) for x in [1.1,2.2,3.3]] >> Bill, >> >> you probably mean something like >> >> map(product(wholePart, sin), [1.1,2.2,3.3]) >> >> right? >> > > No. The signature must include a dependent type, like this: > > product: (A:Type, A>X,A>Y) > (A>%) Of course the A must come from somewhere, but who would like to write a cross of two functions in that way? I would better have something like cross: (A: Type) > (A>X,A>Y) > (A>%) later say product == cross(Integer) and then use "product" as I did above. And since this A is actually part of the Limit definition there should rather be something like (dream dream ...) Limit(A: Type): ... { this introduces A Product(X: Type, Y: Type): with {...} == add {...} } within "with {..}" and "add {...}" there would be no need to say anything about "product", since it would come through the Limit construction. Oh, that is not well thought of... How would the compile know that the function is called "product"? Hmmmmm..... >> Let's look at the signatures: >> >> wholePart: Float > Integer >> sin: Float > Float;  I don't like Float, by the way... ;) >> [1.1,2.2,3.3]: List Float >> >> So we must have >> >> product: (Float > Integer, Float > Float) > >> (Float > Product(Integer, Float)) >> >> and a corresponding signature for map. You surely believe that I can >> program exactly that in Aldor. >> > > To define 'product' in general (i.e. as a categorical limit) for any > domain Product(A,B) and domain C we must have > > product(C,f,g):C>Product(A,B) > > defined for any functions > > f:C>A > g:C>B > > I don't think you can do that without passing the independent domain C. No, of course not. But I would have hidden it in Product(C)(A,B). But also that looks ugly. >> But I guesss that is not your point. Your point is (please correct) that >> you want a categorical definition of "Product". >> >> Product(A, B) should automatically export >> >> product: (A, B) > % > > No, this is not well defined. > >> as well as >> >> product: (X > A, X > B) > X > %. > > What is X above? Allquantified. In fact, I was thinking that the compiler would silently introduce this "Limit(X)" from above. >> You don't want to write down that function definition yourself, right? > Well, I would actually expect it to be exported by a basic builtin > domain like 'Record' since that is what most directly corresponds to > categorical Product. If this was made sufficiently general, there > would be no need for a separately programmed domain in the library. I think I can support this. Ralf 
From: Ralf Hemmecke <ralf@he...>  20071031 16:47:59

> Yes exactly, although I am not sure why we need both Cross and Record. Elements of Record are mutable, elements of Cross are not. Ralf PS: Shouldn't this discussion go to axiomdeveloper instead of axiommath? 
From: Bill Page <bill.page@ne...>  20071031 16:31:15

 Forwarded message  From: Bill Page <bill.page@...> Date: Oct 31, 2007 10:54 AM Subject: Re: [openaxiomdevel] [fricasdevel] Re: [fricasdevel] Re: iterators and cartesian product. To: Ralf Hemmecke <ralf@...> On 10/30/07, Ralf Hemmecke wrote: > Hi Bill, > > this goes offlist since I don't want to spam them... > Ok if you like, but I think other people on this list probably have similar questions as you do so it would probably be of interest to them too even though this thread is already quite long. > On 10/22/2007 08:06 PM, Bill Page wrote: > > On 10/22/07, Gabriel Dos Reis <gdr@...> wrote: > >> On Mon, 22 Oct 2007, Bill Page wrote: > >> > >>  As I said, I want > >>  > >>  Product(1..9,1..4) > >>  > >>  to be a domain  the crossproduct of two other domains. > >> > >> I do not think > >> > >> I want 1..9 to be a domain so that I can write > >> Product(1..9, 1..4) to be a cross product of two domains > >> > >> is an explanation of why `1..9' should be a domain. > > > > As I said earlier, I think the semantics of Product should be given > > categorically by the existence of the unique operation > > > > Product(X:Type, Y:Type): with ... > > > > product: (A:Type, A>X,A>Y) > (A>%) > > > > as a categorical limit. > > As you know I like the categorical approach, but I don't understand, > what a definition like your "product" has anything to do with how the > "for" loop is traversed? > > You certainly know that a function > > product: (A:Type, A>X,A>Y) > (A>%) > > is easily implemented (in Aldor, I don't know for spad). > But I really don't see the connection to the "for". > The main issue has to do with programming style. The forloop is a construction from imperativestyle programming. Operations like 'product' above operate directly on functions and return functions. This is most common in a functionalprogramming style and might be used for example in conjuction with another operation such as 'map' to produce the same results a a forloop constrcut: map(product(Float,wholePart,sin),[1.1,2.2,3.3]) versus [makeprod(wholePart x, sin x)$Product(Integer,Float) for x in [1.1,2.2,3.3]] The functionalstyle has no dummy variables and no explicit forloop. In general one might view imperativestyle programming as inherently more "primitive" than functional programming so I think it should be "allowed" because it is sometimes convenient but not encouraged. Aldor and Spad usually provide both options. But the point with respect to category theory is really that because the operation 'product' exists and is uniquely defined (as a limit), it actual defines exactly what is meant by the domain constructor Product, i.e. it provides the semantics of Product. This has nothing directly to do with forloops. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20071031 16:30:23

 Forwarded message  From: Ralf Hemmecke <ralf@...> Date: Oct 30, 2007 4:58 PM Subject: Re: [openaxiomdevel] [fricasdevel] Re: [fricasdevel] Re: iterators and cartesian product. To: Bill Page <bill.page@...> Hi Bill, this goes offlist since I don't want to spam them... On 10/22/2007 08:06 PM, Bill Page wrote: > On 10/22/07, Gabriel Dos Reis <gdr@...> wrote: >> On Mon, 22 Oct 2007, Bill Page wrote: >> >>  As I said, I want >>  >>  Product(1..9,1..4) >>  >>  to be a domain  the crossproduct of two other domains. >> >> I do not think >> >> I want 1..9 to be a domain so that I can write >> Product(1..9, 1..4) to be a cross product of two domains >> >> is an explanation of why `1..9' should be a domain. > > As I said earlier, I think the semantics of Product should be given > categorically by the existence of the unique operation > > Product(X:Type, Y:Type): with ... > > product: (A:Type, A>X,A>Y) > (A>%) > > as a categorical limit. As you know I like the categorical approach, but I don't understand, what a definition like your "product" has anything to do with how the "for" loop is traversed? You certainly know that a function product: (A:Type, A>X,A>Y) > (A>%) is easily implemented (in Aldor, I don't know for spad). But I really don't see the connection to the "for". Ralf 
From: Bill Page <bill.page@ne...>  20071031 16:29:52

On 10/31/07, Ralf Hemmecke <hemmecke@...> wrote: > > The main issue has to do with programming style. The forloop is a > > construction from imperativestyle programming. Operations like > > 'product' above operate directly on functions and return functions. > > This is most common in a functionalprogramming style and might be > > used for example in conjuction with another operation such as 'map' to > > produce the same results a a forloop constrcut: > > > map(product(Float,wholePart,sin),[1.1,2.2,3.3]) > > > > versus > > > > [makeprod(wholePart x, sin x)$Product(Integer,Float) for x in [1.1,2.2,3.3]] > > Bill, > > you probably mean something like > > map(product(wholePart, sin), [1.1,2.2,3.3]) > > right? > No. The signature must include a dependent type, like this: product: (A:Type, A>X,A>Y) > (A>%) > Let's look at the signatures: > > wholePart: Float > Integer > sin: Float > Float;  I don't like Float, by the way... ;) > [1.1,2.2,3.3]: List Float > > So we must have > > product: (Float > Integer, Float > Float) > > (Float > Product(Integer, Float)) > > and a corresponding signature for map. You surely believe that I can > program exactly that in Aldor. > To define 'product' in general (i.e. as a categorical limit) for any domain Product(A,B) and domain C we must have product(C,f,g):C>Product(A,B) defined for any functions f:C>A g:C>B I don't think you can do that without passing the independent domain C. > But I guesss that is not your point. Your point is (please correct) that > you want a categorical definition of "Product". > > Product(A, B) should automatically export > > product: (A, B) > % No, this is not well defined. > > as well as > > product: (X > A, X > B) > X > %. What is X above? > > You don't want to write down that function definition yourself, right? > Well, I would actually expect it to be exported by a basic builtin domain like 'Record' since that is what most directly corresponds to categorical Product. If this was made sufficiently general, there would be no need for a separately programmed domain in the library. > In terms of Aldor, we have Product = Cross and that is a builtin type. > So it should be possible (and perhaps be reasonable to extend Cross > through the compiler, ie, give it a few more exports than it has now. > Yes exactly, although I am not sure why we need both Cross and Record. > But maybe your proposal goes further and you want to be able to define > domains/functors through categorical limit constructions. So, in fact, > you want to enrich Aldor/SPAD by new keywords "Limit" and "CoLimit" and > make "Cross" a library defined type. > Yes, maybe. What might be even nicer is if it were possible to implement adjoint functors as described by Saul Youssef as an even more basic concept in Aldor/SPAD. He shows how to define Limits and CoLimits in this more fundamental way. > If that is what you think/want, then I can somehow understand you and > would even support it. But to my taste that was not clear enough yet in > all the previous discussions. > > (I have no problem if you forward this and/or my previous mail to the > lists.) > Ok, thanks. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20071030 16:53:39

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 "setlike" and when to define a > >>> higherorder domain whose objects are "setlike"? To me this is > >>> not clear in either Spad or Aldor. > >> I don't think you gain very much if you only consider setlike > >> 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 objectoriented 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 [Aldorl] 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. 
From: Gabriel Dos Reis <gdr@cs...>  20071030 15:58:46

On Tue, 30 Oct 2007, Ralf Hemmecke wrote:  Dear Gaby,   I've read the Wikipedia articles about Generator and Iterator, but somehow  their difference is not completely clear to me. Seemingly a generator is more  general than an iterator. Yes, generator  based on coroutines  is more general than iterator  which is based on functions. But the generality comes at a price. Furthermore, I do not believe that they are mutually exclusive.   But now, coming to SPAD, do you think it is worthwhile to think of an  implementation (for SPAD) of the Iterator concept a la C++? It depends on people. From my perspective, certainly yes. But different people have different opinions. For OpenAxiom, it is certainly something I'm actively considering.  Wouldn't the  Generator thing be enough? Or is there no plan to introduce Generator to SPAD? Enough from the theoretical point of view, certainly. But that is not all to it. Personnally, I tend to consider also the effienc at which features are delivered  but I acknowledged that is not a universal view.  Gaby 
From: Ralf Hemmecke <ralf@he...>  20071030 15:53:20

Dear Gaby, I've read the Wikipedia articles about Generator and Iterator, but somehow their difference is not completely clear to me. Seemingly a generator is more general than an iterator. But now, coming to SPAD, do you think it is worthwhile to think of an implementation (for SPAD) of the Iterator concept a la C++? Wouldn't the Generator thing be enough? Or is there no plan to introduce Generator to SPAD? Ralf PS: I would vote for Generator instead of Iterator (a la C++). On 10/24/2007 05:56 PM, Gabriel Dos Reis wrote: > On Wed, 24 Oct 2007, Bill Page wrote: > >  But converting a >  domain (Product) to a List just to iterate over it seems like a waste >  and is still less economical. I would like the compiler to make this >  operation transparent and more efficient. > > Iteration is an old topic  did I say that SIMULA had coroutines? > This problem has been studied to depth, with lots of solutions. As > Waldek would say, a variety of solutions is an indication that > opinions are split over which is better. > > I do fully agree that it does not make much sense, from efficiency > point of view, to make a list just be to able to iterate over elments > of Product. There are various solutions to that problem. One being > generartors  or coroutines or semicoroutines. Another, quite > effective, is the notion of `iterator' in used the C++ Standard Template > Library. > > http://www.sgi.com/tech/stl/ > > It relies on semantics description of iterators, along with hierarchical > categorisations of algorithms and containers bases on complexity and > semantics description of iterators. Note that STL is the result of a > long term project, some of the earlier description may be found here > > http://www.stepanovpapers.com/ > > Basically, a domain that whish to be iterated over provides two > operations  begin() and end()  that people use to initiate/end > iteration over data structures. That does not require coroutines. > It can be made to work in Spad if we had good support for nested > domains. > > Now, you may say that you really want begin() and end() to be implicit > in some cases, that can be made to work too  just like generate() is > implicitly called in Aldor. For C++, there is a welladvanced > proposal for C++0x to make that work: > > vector<int> v; > // ... > for (int x: v) > // ... > > would be roughly equivalent to > > for (auto p = v.begin(); p != v.end(); ++p) { > int x = *p; > // ... > } > > Notice that this solution, when applied to BinaryTree, does not > require one to first construct a List and then iterate, and finally > throw it away. One caniterate over BinaryTree without recursion. > >  Gaby 
From: Martin Rubey <martin.rubey@un...>  20071029 13:39:18

Francois Maltey <fmaltey@...> writes: > Dear Martin, > > > what does a looping construct have to do with a Cartesian product? > > The construct arround reduce/concat isn't so usual in order to > built several overlapped loops. > cartesian product and repeat keyword are two possibilities. > > > > The * isn't the better operator because this locks > > > {1,2,3} * {1,2,3} = {1,2,3,4,6,9} > > > and {1,2,3} + {1,2,3} = {2,3,4,5,6} > > > > I actually wondered already once, why "+" is not union$Set, "" not > > difference$Set. I was thinking of Boolean algebra. Now, I looked a little closer to find the Category "Logic", which exports /\ and \/, which would in fact be a lot better than + and *. > I think that operator for sets are missing. > union (union (E, F), G) is less clever than E union F union G. (1) > \/(a: Set INT, b: Set INT): Set INT == union(a, b) Function declaration ?\/? : (Set Integer,Set Integer) > Set Integer has been added to workspace. (2) > set [1,2,3] \/ set [2,3,4] Compiling function \/ with type (Set Integer,Set Integer) > Set Integer (2) {1,2,3,4} Type: Set Integer > But why do you want a +. It might be possible to have more operators > than only +, , *, /, ^, ::, $, # and @. yes, but I want to be use the "right" operators. As we know already (see Monoid / AbelianMonoid discussion), currently this is not always possible in Aldor or Axiom. But when it is, we should use them. Just to make sure, I did not say that your definition of * and + for sets is bad per se. I only found it unusual. And I do not want "unusual" things in the axiom library. The user should make this definitions himself. Unfortunately, there is a bug in the interpreter: (1) > _*(A: Set INT, B: Set INT): Set INT == set concat [[(a*b)$Integer for a in members A] for b in members B] Function declaration ?*? : (Set Integer,Set Integer) > Set Integer has been added to workspace. Type: Void (2) > 2*3 Compiling function * with type (Set Integer,Set Integer) > Set Integer Conversion failed in the compiled user function * . Cannot convert from type Integer to Set Integer for value 2 > axiom doesn't understand that sin+cos is the function x +> (sin x + cos x) I do not see the connection to the topic above. But still, you can quite easily build a domain that has, for example, univariate functions as objects. That might indeed be useful. Martin 
From: Francois Maltey <fmaltey@ne...>  20071029 13:09:11

Dear Martin, > what does a looping construct have to do with a Cartesian product? The construct arround reduce/concat isn't so usual in order to built several overlapped loops. cartesian product and repeat keyword are two possibilities. > > The * isn't the better operator because this locks > > {1,2,3} * {1,2,3} = {1,2,3,4,6,9} > > and {1,2,3} + {1,2,3} = {2,3,4,5,6} > > I actually wondered already once, why "+" is not union$Set, "" not > difference$Set. I think that operator for sets are missing. union (union (E, F), G) is less clever than E union F union G. But why do you want a +. It might be possible to have more operators than only +, , *, /, ^, ::, $, # and @. > I didn't think of the possibility above, although I doubt that > it would be too useful. For finite set it's not useful, but very useful for intervals ; and intervals and set are close. I like to use it for chaotic systems, with numerical instability. or in order to separate root of a function. newton methods can forget some mutiple roots. interval methods, with operations over intervals, can add false roots. > After all, you can even define it only if the elements > understand "+" and "*". I meet this needs for functions. axiom doesn't understand that sin+cos is the fuction x +> (sin x + cos x) François 
From: Gabriel Dos Reis <gdr@cs...>  20071029 07:46:00

Ralf Hemmecke <ralf@...> writes:  Someone with the same problem?   Start OpenAxiom  Click on "Browse" in Hyperdoc  Enter "Stream"  Click "Constructors"  Click "operations"  Click "Signatures"  click "elt" I'm current;y on travel with my windows only machine so I cannot test this at the moment. [...]  (1) >  (1) >  >> System error:  The tag SPAD_READER is undefined. Hmm, this usually indicates a mismatch between CATCH/THROW pairs at the Lisp level. I'll be looking into that. Thanks.  Gaby 
From: Ralf Hemmecke <ralf@he...>  20071028 23:53:45

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. ;) 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). 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. >>> The larger question remains however: When to use a domain to >>> directly model something that is "setlike" and when to define a >>> higherorder domain whose objects are "setlike"? To me this is >>> not clear in either Spad or Aldor. >> I don't think you gain very much if you only consider setlike >> 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...) 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.) > 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? Ralf 
From: Bill Page <bill.page@ne...>  20071028 21:37:37

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". > Second, according to the documentation a Stream is a pair (A,B) where A > is a list of precomputed functions and B is a function that computes the > next value. > > If you would like to know the difference between Stream and Generator, > then think of a Generator as the B part above. > Ok. > ... > > The larger question remains however: When to use a domain to directly > > model something that is "setlike" and when to define a higherorder > > domain whose objects are "setlike"? To me this is not clear in either > > Spad or Aldor. > > I don't think you gain very much if you only consider setlike 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? Yes, I think that makes sense. But there are of course some operations that connect elements of any well defined set, no? If it is only a matter of degree, then I still think it is rather confusing that Axiom (and Aldor) provides these two rather different alternative implementation of something that is essentially the same. 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. But of course that is not the way Axiom was designed. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20071028 21:26:28

On 10/27/07, Ralf Hemmecke wrote: > > > Def: Two domains P and Q are equivalent if and only if both domains satisfy > > exactly the same set of categories: (P has x) = (Q has x) for all Category > > expressions x *and* neither P nor Q has any explicit exports that are not > > provided by some named category. > > Let's see... > > Cat: Category == with { > coerce: Integer > %; > coerce: % > Integer; > bar: (%, %) > %; > } > P: Cat == add { > Rep == Integer; import from Rep > coerce(x: Integer): % == per x; > coerce(x: %): Integer == rep x; > bar(x: %, y: %): % == per(rep x + rep y); > } > ^ > > Q: Cat == add { > Rep == Integer; import from Rep > coerce(x: Integer): % == per x; > coerce(x: %): Integer == rep x; > bar(x: %, y: %): % == per(rep x  rep y); > } > ^ > > You are saying that P and Q are equivalent. > No. I should have explicitly written "typeequivalent" as I did elsewhere in that message. I would only want to say that their types are equivalent  that they necessarily represent the same kind of things. Something like: "they are both monoids". I would also say that without giving more information about the use of the category 'Cat' you are at risk of abusing the intention of defining a category  at least in the context of the design of a library such as Axiom library. What is the "meaning" of 'Cat' if it makes sense to give two rather different definitions of 'bar'? I started my discussion by saying that I assumed that the intention of defining a category was to represent some specific aspect or common mathematical property of a as set of mathematical object(s). I do not want to think of a category as a mere syntactical convenience for example like a macro. Regards, Bill Page. 
From: Ralf Hemmecke <ralf@he...>  20071028 20:32:10

> Def: Two domains P and Q are equivalent if and only if both domains satisfy > exactly the same set of categories: (P has x) = (Q has x) for all Category > expressions x *and* neither P nor Q has any explicit exports that are not > provided by some named category. Let's see... Cat: Category == with { coerce: Integer > %; coerce: % > Integer; bar: (%, %) > %; } P: Cat == add { Rep == Integer; import from Rep coerce(x: Integer): % == per x; coerce(x: %): Integer == rep x; bar(x: %, y: %): % == per(rep x + rep y); } ^ Q: Cat == add { Rep == Integer; import from Rep coerce(x: Integer): % == per x; coerce(x: %): Integer == rep x; bar(x: %, y: %): % == per(rep x  rep y); } ^ You are saying that P and Q are equivalent. Ralf 
From: Ralf Hemmecke <ralf@he...>  20071028 20:32:09

On 10/25/2007 06:50 PM, Bill Page wrote: > On 10/24/07, Ralf Hemmecke wrote: >>>  '1..' is another (better?) name for PositiveInteger >>> >>> No, it is not. Both behave quite differently in many situations. >> What? >> >> Suppose I have given >> >> PositiveIntegerCategory >> >> and suppose >> >> PositiveInteger: PositiveIntegerCategory == add {...} >> > > In the existing Axiom library PositiveInteger is a subdomain of > Integer. The Axiom interpreter infers the following domain > > UniversalSegment PositiveInteger > > of the expression '1..'. 'UniversalSegment(S)' includes an operation > 'expand' that returns a Stream(S) provided S had OrderedRing. > >> then >> >> (..)(i: Integer): PositiveIntegerCategory == PositiveInteger >> >> For simplicity I simply ignore the parameter and in the following I >> simply use an existing "IntegerType" from LibAldor. >> >> BEGIN aaa.as >> #include "aldor" >> #include "aldorio" >> PositiveInteger: IntegerType == Integer add; >> (..)(i: Integer): IntegerType == PositiveInteger add; >> one:*Integer == 1$Integer; >> import from one..; >> stdout << 3 << newline; >> END aaa.as >> >> (I don't import from Integer since I use ":*" instead of ":". Remove the >> * and see what the compiler tells you.) >> >> Add the line >> >> for i in one.. repeat stdout << i << newline; >> >> to the program above and try to compile. Of course it must fail. >> >aldor fx laldor aaa.as >> "aaa.as", line 9: for i in one.. repeat stdout << i << newline; >> ....^.......^ >> [L9 C5] #2 (Error) No meaning for identifier `i'. >> [L9 C13] #1 (Error) Argument 1 of `generator' did not match any possible >> parameter type. >> The rejected type is >> IntegerType with >> == Posi.... >> Expected type String. >> >> Since there is no function (..) which returns a Generator(Something). >> >> But still, I cannot see, why >> >> one.. >> >> behaves in any way different from PositiveInteger. >> > > The point is that '1..' as a 'UniversalSegment' provides only certain > specific exports which differ from those available in > 'PositiveInteger'. I think, you are confusing the elementdomain difference. If you say '1..' as a 'UniversalSegment' that can only mean that 1.. is of *type* UniversalSegment Now, UniversalSegment(T) is a domain, so "1.." is an elment and thus "1.." does not export anything. (That is in total contrast to what I have constructed above. "one.." is a *domain* or type IntegerType.) Ralf 
From: Ralf Hemmecke <ralf@he...>  20071028 20:32:09

On 10/25/2007 06:40 PM, Bill Page wrote: > 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? 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. Second, according to the documentation a Stream is a pair (A,B) where A is a list of precomputed functions and B is a function that computes the next value. If you would like to know the difference between Stream and Generator, then think of a Generator as the B part above. In fact, in aldorcombinat, I have implemented a "DataStream" which has representation: Rep == Record( gen: Generator T, cache: PrimitiveArray T, size: I, numberOfElements: I, constant?: Boolean ); In more simpler terms, my A is Array and my B is Generator. Does that help? > The larger question remains however: When to use a domain to directly > model something that is "setlike" and when to define a higherorder > domain whose objects are "setlike"? To me this is not clear in either > Spad or Aldor. I don't think you gain very much if you only consider setlike 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. Ralf 
From: Ralf Hemmecke <ralf@he...>  20071028 20:32:09

Someone with the same problem? Start OpenAxiom Click on "Browse" in Hyperdoc Enter "Stream" Click "Constructors" Click "operations" Click "Signatures" click "elt" That does not happen with golden axiom Version: Axiom (September 2006) woodpecker:~>openaxiom GCL (GNU Common Lisp) 2.6.8 CLtL1 Aug 23 2007 17:30:07 Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) Binary License: GPL due to GPL'ed components: (BFD UNEXEC) Modifications of this banner must retain notice of a compatible license Dedicated to the memory of W. Schelter Use (help) to get some basic information on how to use GCL. Temporary directory for compiler files set to /tmp/hemmecke/ AXIOM Computer Algebra System Version: OpenAxiom 1.1.020071016 Timestamp: Thursday October 18, 2007 at 21:25:16  Issue )copyright to view copyright notices. Issue )summary for a summary of useful system commands. Issue )quit to leave AXIOM and return to shell.  (1) > (1) > >> System error: The tag SPAD_READER is undefined. 