Ralf Hemmecke wrote:
>
> I guess you refer to me saying that I want InputForm reflecting input
> expressions (without types or rather like what you see in .ap files) and
> that I rather like *another* type that reflects the expression together
> with *full* type information.
>
I think there is a little misconception here: looking at how InputForm
is used and implemented it is for me clear that the goal of
InputForm was _not_ to represent parse trees. Rather, goal was
to represent algebra values (in particular expressions) in a form
that can be conveted to functions (machine code). Using parse
trees and interpreter is a shortcut which avoids duplicating code.
Given that I feel that when we convert algebra values to InputForm
we should include enough type information to reconstruct original
type.
Also, note that when InputForm is produced by parse, then it
represents input. But when we convert algebraic expression
to input form the original input is long gone and we may
get quite different thing. "(x^50 - 1)/(x-1)" is a simple
example -- after evaluation division is gone and there is
no way to know it was there.
--
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
-~----------~----~----~----~------~----~------~--~---
