On Fri, Mar 30, 2012 at 07:14:00PM +0200, Waldek Hebisch wrote:
> Serge D. Mechveliani wrote:
> >
> > Earlier, we wrote about adding instances to a library domain:
> >
> > >> Now, if one needs to use this Sized for Integer in Spad, one has
> > >> to define a copy domain Integer2 and add an implemantation of
> > >> Sized to Integer2 ?
> >
> > Bill Page:
> > >
> > > In Axiom there is a way to introduce new operations related to Integer
> > > without redefining what you mean by Integer. This is done by defining
> > > a package. It is common to see in the Axiom library for example
> > > something like:
> > >
> ...
> >
> > Consider the following concrete example. I define
> >
> > --------------------------------------------------------
> > ParseCategory : Category == SetCategory with
> > parseElem : String -> Product(%, String)
> > ++ parseElem parses from String and yields
> > ++ construct(<parsed element> : %, <remaining string>).
> > ++ Example: parseElem("- 12 x1") :: Product(Integer, String) ->
> > ++ construct(-12, " x1")
> > --------------------------------------------------------
> ...
> > -- and so on, may be, for 20 library constructors.
> > And I could not imagine any other natural way of programming things.
> >
> > Nowm, how to avoid making 20 copies of these parametric library domains?
> > How does your approach with a package apply to this example?
>
> Why do you need Integer (etc.) to have ParseCategory? You can
> have:
>
> ParseCategory(T : SetCategory) : Category == SetCategory with
> parseElem : String -> Product(T, String)
> ++ parseElem parses from String and yields
> ++ construct(<parsed element> : %, <remaining string>).
> ++ Example: parseElem("- 12 x1") :: Product(Integer, String) ->
> ++ construct(-12, " x1")
>
> and then implement packages of that category.
I am not sure that I understand the approach.
I am sorry, may be, I would understand this later.
My current idea is as follows.
Implementing these packages, one needs to implement parseElem for a
constructed data via applying parseElem to an argument data.
And constructed things are build over Integer by composing Fraction,
UP, GDMP, etc. In this approach, one needs to declare a user category
for several library domains (basic and parametric too) -- which is very
stangely not possible in Spad.
Alternatively, one can pass a parsing function as an argument to another
parsing function. In this approach ParseCategory is not needed at all.
But generally, categories serve exactly the aim of improving style:
avoiding passing functions as additional arguments.
> I would say that in FriCAS Integer is supposed to belong to categories
> that have some significance, not to random ad-hoc things which were
> invented to solve some coding problem. So not adding 'ParseCategory'
> to Integer looks like advantage of this approach.
Probably, this is against mathematics.
Looking into various textbooks and papers, we shall find hundreds of new
categories to which belong Integer, Fraction R, UP(v, R) etc., -- as the
authors define. And we were not aware of these numerous categories, each
year there may appear several of them, and they are useful for defining
various algorithms.
One book writes that Integer has Euclidean divRem, and there appears
another book that relates height to Integer, and to List T,
where T has Height, and so on.
Axiom can require:
"this small set of categories are for Integer, and this set is for
UP(v, R), and if you need to add there an user category instance,
call it, say Integer2, Integer3, UPol2 ...
"
But this is awkward. Because this leads to making copies for many
library domain constructors.
The ability to add an user category to the standard domain constructor
is an advantage.
I also imagine how an Haskeller will be amazed when one introduces a
class Foo a, tries to delare its instance for
Foo a => Foo (List a),
and the system says "user class instances are not possible for List !".
Regards,
------
Sergei
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
