Re: [Axiom-developer] Re: Defining piece-wise functions and drawing, integrating, ...

[Ralf Hemmecke]

> I would agree to replace "Set" with something more algebraic,
> e.g. a topos.
>
> http://en.wikipedia.org/wiki/Topos

Cool. ;-) How many people know topoi in contrast to the number of people 
who grew up with sets?

> The short answer to why everything must be algebraic is:
> category theory. You can ask why try to base the Axiom library
> on category theory, but that is an argument at a very different
> level.

Oh, I have no problem with basing a library on category theory. But 
maybe at some point we should drop the "the" in "the Axiom library".

In fact, I would love to see a system that allows different views.
As mathematics can be based on set theory or category theory. Currently 
I think that would make two libraries. The interesting part comes when 
they should be allowed to be used at the same time.

> In fact I think it is quite wrong that Axiom's library places
> SetCategory so near to the top of the algebra hierarchy. It
> would be better to start with something more primitive like the
> concept of a cartesian close category.

I already hear people saying ... but hey, "sets" are much simpler than 
ccc's.

There are just different views and Axiom should support both of them and 
even more.

> > Actually, you could probably turn an ExpressionTree into some
> > form of universal algebra (just leave the set of operations
> > empty).
>
> That would not make me nearly as happy as category theory. :-(

OK, you are responsible to start a library that builds on category theory.

> > Oh, maybe SExpression is near to what I want. But is somehow 
> > sounds to LISPish for me. ;-) Anyway, I think it would be a good
> > thing to have a very general expression domain (maybe like
> > SExpression) and yet others that only allow certain expression
> > trees that correspond to a grammar.

> Yes. I think Gaby had some ideas along that line. We discussed
> some aspects of that here:

> http://wiki.axiom-developer.org/SandBoxInductiveType
>
> and on this list.

I don't think that this would allow me to transform the program (= 
inductive type) at runtime as I could do with expression trees.

Ralf