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.
> So far, I am going to try adding parseElem to my packages, like this:
>
> -----------------------------------------------------------
> )abbrev package UPOL1 UPol1
> UPol1(v : Symbol, R : Ring) : Export == Implementation where
>
> P ==> UP(v, R)
> ParseCoefFunction ==> String -> Product(R, String)
> Export == with
> ...
> parseElem : (ParseCoefFunction, String) -> Product(P, String)
>
> Implementation == add
> ...
> parseElem(parseCoef : ParseCoefFunction, str : String) :
> Product(P, String) ==
>
> <parsing a polynomial expressed via parseCoef>
> -----------------------------------------------------------
>
> But
> 1) I do not know, so far, how this will work in the whole project,
> 2) passing a parsing function as an argument actually means refusing to
> define and use the user categories.
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.
--
Waldek Hebisch
[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.
