Serge D. Mechveliani wrote:
>
> People,
> I need to build (in Spad) an element x : (D : EuclideanDomain)
> into SExpression.
> I do not mind to set it there, for example, via OutputForm.
> So, I try
>
> -----------------------------------------
> )abbrev package FOO Foo
> Foo(D : EuclideanDomain) : with
> f : D -> SExpression
> ==
> add
> f x ==
> xOF := coerce(x) :: OutputForm
> xI := convert(xOF) $InputForm
> xStr := unparse(xI) :: String
> convert(xStr :: Symbol) $SExpression
> -----------------------------------------
>
> I have spent 1 hour to find this conversion which satisfies the compiler.
> Instead of writing
> x :: OutputForm :: String :: SExpression,
>
> one needs to guess of all these clever coerce, convert, unparse,
> and also of introducing InputForm, where this InputForm seems to have
> no relevance to the subject.
>
> 1. Is there possible a simpler code?
Why:
f x == convert(empty()$List(SExpression))@SExpression
does not do? In other words, what properties the mapping you
want should have.
BTW: I am pretty sure that the mapping I gave (which always
gives empty list) is useless for you. But the mapping you
build looks almost equally useless, so I have no clue what
you really want. Note that your function produces a single
string, so it is not clear why you want SExpression and
not Sting as a result type. Also, the String you get
in general is not enough to reconstruct the 'x' you
started with, so I do not know what uses beyond debugging
you have in mind.
BTW2:
f x == (coerce(x)::OutputForm) pretend SExpression
may be better than what you have (but still is lossy).
> 2. If it is not, can the compiler be improved in this point?
I suspect that what you really want to do simply requires
addind substantial code to implement and I do not expect
compiler to automatically generate this code.
To make this more clear: unlike languages like ML in FriCAS
generic coding does not require common repersentation.
FriCAS domains are free to use any representations they
want. Of course this is paired with obligation to
provide implementation for exported functions which
works with choosen representation. And this means
that normally all "real work" is done by functions
provided by the domain -- in other words interface
is purely abstract (I wrote normally, because in few
performance critical places algebra code uses 'pretend'
to bypass abstraction barier). For you consequence is
that any mapping which goes from arbitrary EuclideanDomain
to SExpression must be based on operations defined in
EuclideanDomain, and those are probably not enough to
dd what you want. Note that mapping to OutputForm
is build by providing support in each domain
(only domains knows how to output its elements).
--
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.
