On Wed, Sep 17, 2008 at 4:20 PM, Waldek Hebisch wrote:
> AFAICS we need "::" (coercion), "$" (package call) and "@"
> (required result type). In general we need parentheses around
> arguments, in particular both "::" and "@" bind pretty tightly,
> but in practice we are likely to apply them to large expressions.
>
> Also, we do not handle logical operators ('not' is correctly
> handled by application rule, but 'and' and 'or' are mangled).
>
> Next, "rem" and "quo", comparisons and "SEQ" are just unparsed
> as function applications and interpreter parser can handle them in
> that form. I am not sure if we really want parser to allow
> such prefix forms. If we use such prefix forms we should be
> careful to avoid accidentally turning them into infix operators
> --> we need a lot of parenthesis
>
This sounds very ambitious to me. In order to keep this project to a
reasonable size, I would like to propose we first solve a somewhat
smaller problem: I would just like to be able to properly unparse only
those values of InputForm which we can generate by coercions, i.e. in
the sense that:
parse(unparse(x::InputForm)) = x::InputForm
where x is any value for which such a coercion already exists. I would
like to largely ignore for now the other more direct ways by which one
can construct values of InputForm. For example:
(1) -> (1$SquareMatrix(3,Polynomial Complex Integer))::InputForm
(1)
(squareMatrix
(matrix
(construct (construct (complex 1 0) (complex 0 0) (complex 0 0))
(construct (complex 0 0) (complex 1 0) (complex 0 0))
(construct (complex 0 0) (complex 0 0) (complex 1 0)))
)
)
Type: InputForm
(2) -> test(parse(unparse(%))$InputForm=%)
(2) true
Type: Boolean
I think this is a much smaller set than all possible values of
InputForm since typically such coercions attempt to find some simple
and direct construction that evaluate to a given value. The most
complicated of these originate in "symbolic" domains like Polynomial
and Expression. Of course as we add new domains and new functionality
to old domains we may end up expanding the set of InputForms that we
can generate. When/if we do this, I think that is also a good time to
consider what extensions (if any) might be necessary in order to
unparse these values.
InputForm values generated by coercions are exactly those that we need
to be able to unparse for the Sage interface (and perhaps as input to
other systems) so that with a minimum translation they may often be
able to reconstruct accurate versions of these values.
So far I do not know of any way to generate $ package calls or @
result assertions through such coercions.
> ...
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
