> We are talking about different things here. IIUC species are functors
> from finite sets to finite sets. In particular they should act on
> morphims of category of finite sets. In practice, isomorphism classes
> of finite sets are determined by cardinality (a single number).
> To take into account isomorphims minimally one needs to look at images
> of permutations of a single set. So permutations that I am taking
> about at least formally are quite different than the elements
> of domain Permutation -- they are morphims of the category of
> finite sets. I wonder if Aldor combinat handle this aspect...
Ehm, I don't think I got what you were trying to say. What permutations
are is clear. And we all agree that there are isomorphic representations
of permutations.
As I said before, aldor cannot deal with finite sets in general, only
with finite sets of elements of a particular type. But that is not
really a restriction.
So let's say you have a type L then aldor-combinats Permutation(L) gives
you a way to list all permutations on a fixed finite subset of L.
Of course, it gives you only one particular form/representation of such
a permutation.
Could you more clearly specify what you want or thought about. I already
have a vague feeling, but it's totally clear.
>> That is, you can give your grammar at the top level. In the other approach,
>> you would have to give the grammar to a wrapper function, which then
>> generates
>> the objects:
>>
>> BinTree := grammar(B=X+B*B)
>>
>> and you would then have methods to generate them, find the generating
>> functions
>> etc.:
>>
>> structures([1,2,3,4], BinTree)
>> generatingSeries(BinTree)
>>
>> But this doesn't integrate nicely with permutations, lists or sets, where
>> natural Aldor/Axiom domains exist.
>
> What is wrong with something like:
>
> SpeciesDomain(s : Species): SpeciesDomainCategory ==...
Waldek, could you be more precise here. I don't understand what
SpeciesDomain is all about. What would be SpeciesDomainCategory? And why
would there be a parameter of type Species?
> Partially. You feel that this way of programming works well
> (better that what Mupad folks chose) -- that is clear. But
> my point of view is that we have three formal systems: Aldor
> with "fixed" types, full Aldor and Aldor types. By "fixed" types
> I mean that all types should (at least in principle) be determined
> at compile time. Aldor with "fixed" types is just a small
> subset of full Aldor. In other words, we have "identity"
> embedding form Aldor with "fixed" types to full Aldor.
Do I understand correctly that "fixed"-types Aldor is where
I am not allowed to *use* my own newly created _parametric_
domains/categories? A definition like
A: with {foo: Integer} == add {foo: Integer == 1}
should be OK, right?
> Full Aldor looks much more powerful, because you can do
> at runtime computations with types.
Would you say that the program below classifies as
Aldor with "fixed" types
?
>aldor -grun -laldor aaa.as
#1 (Warning) The file `aaa' will now be out of date.
--- elements 1
(1 nil)
--- elements 2
(1 (2 nil))
--- elements 3
(1 (2 (3 nil)))
--- elements 4
(1 (2 (3 (4 nil))))
You certainly see that this can easily be extended to generate binary trees.
> But if you work only
> with types you are in the thired formal system: Aldor types.
> Again Aldor types are just a small subset of full Aldor.
> My impression is that Aldor types give you rather weak
> programming language (quite a lot of things which work
> on elements do not work on types). This language is
> different (not isomorphic to) than Aldor with "fixed"
> types, but I think that it should be rather strigtforward
> to express equivalent computation at element level
> -- basically the only feature that types have and
> normal elements do not have is lazy evaluation.
Yep. Lazy evaluation is sometimes useful, but I don't want to call for
it on the element level since that has probably a lot of consequences.
Maybe one could think about a new keyword "lazy", but it should be well
thought of before it is introduced.
> But
> it is known (and used in Axiom/FriCAS) that if you
> stick to apropriate protocol you can easily emulate
> lazy evaluation.
Are you speaking about the "delay" keyword?
Aldor-combinat comes with a re-implementation of series and since I
wanted to define them recursively, I basically delayed computation by
putting it into a "generate" environment.
> Put it differently: power of types come from interactions
> with elements. So I was expecting something like "see,
> we compute this type, declare element and get such and
> such behaviour -- you can not do this with elements
> alone". But all I got this far is:
>
> - different (you feel that nicer) syntax
> - solving recurences (which seem to be lazy evaluation)
>
> In other words, it looks possible that you could keep most
> of the code structure you have (with all its advantages) but
> work at element level -- doing mostly local syntactical changes.
> Now, to know for sure one would have to recode combinat
> (which I am not going to do).
Waldek, could you give a suggestion of how you would define species (as
elements) so that you get from *one* equation like
b = 1 + x*b*b
(and not grammar("b=1+x*b*b")) not only an appropriate representation
for binary trees, but at the same time the generating series (plural).
What we want is that such an expression is to be handled by the
interpreter. (I know that doesn't work at the moment.) Why would one
want to have any other syntax?
I agree with you that computing with types might be an efficiency
problem, but do you see some theoretical reason why that cannot be
resolved in the future by a better compiler?
Ralf
---BEGIN aaa.as
#include "aldor"
#include "aldorio"
macro Z == Integer;
macro I == MachineInteger;
Cat: Category == OutputType with {elements: List Z -> Generator %}
1: Cat == add {Rep == List Z; import from I;
elements(l: List Z): Generator % == generate {if zero? #l then yield
per l}
(tw: TextWriter) << (x: %): TextWriter == tw << "nil";
}
X: Cat == add {Rep == List Z; import from Rep, Z, I;
elements(l: List Z): Generator % == generate {if one? #l then yield
per l}
(tw: TextWriter) << (x: %): TextWriter == tw << first rep x;
}
L: Cat == add {Rep == Union(left: 1, right: Record(fst: X, snd: L));
import from Rep;
elementsrec(l: List Z): Generator Record(fst: X, snd: L) == generate {
u: List Z := empty;
v: List Z := l;
while not empty? v repeat {
for x in elements(u)$X repeat for y in elements(v)$L repeat yield
[x, y];
u := cons(first v, u);
v := rest v;
}
for x in elements(u)$X repeat for y in elements(v)$L repeat yield
[x, y];
}
elements(l: List Z): Generator % == generate {
for u in elements(l)$1 repeat yield per union u;
for u in elementsrec(l) repeat yield per union u;
}
(tw: TextWriter) << (x: %): TextWriter == {
if rep x case left then tw << rep(x).left;
else {y := rep(x).right; tw << "(" << y.fst << " " << y.snd << ")"}
}
}
print(n: Z): () == {
import from L, Z, List Z;
l := [i for i in 1..n];
stdout << "--- elements " << n << newline;
for e in elements(l) repeat stdout << e << newline;
stdout << newline;
}
main(): () == {import from Z; for i in 1..4 repeat print i}
main();
---END aaa.as
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Aldor-combinat-devel mailing list
Aldor-combinat-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aldor-combinat-devel
