Ralf Hemmecke wrote:
>
> Various formatters like MathML and TeXmacs and HTML seem to rely on the
> fact that OutputForm is represented by a normal Lisp s-expression, but
> instead of coercing to SExpression and then using the exported functions
> from SExpression, they rather call LISP functions directly on an element
> of type OutputForm.
>
> Maybe that is not relevant for the trasnlation of i-output.boot, but I
> think it should be cleaned up. That would probably remove quite a lot of
> $Lisp calls so that (when mathprint and outtrans are SPAD functions)
> eventually the Lisp relation is gone from the formatters.
>
> What do you think about it?
I am thinking exactly about this. Currently form is either
atomic or composite. I would keep this distinction, it
looks natural. Atomic forms are either integers, or are
converted to strings and then strings are acted on.
In particular "%e", "%pi" and "%i" have special meaning.
Some string handling will be necessary anyway so as
first step we can keep current scheme, but ideally we
would like better way to handle atomic forms.
Composite forms either have an operator (which currently
must be a symbol) or are "function application". I
think that we can introduce (ATM a fictional) operator
to represent application, so that way all form will
be operator applied to some arguments. Arguments
are again input forms and we need to dispatch on
the operator. Operators are divided between
nulary, unary, binary, nary, special and plexes.
For me it looks like resonable classification,
except for unary operators, which logically are
more or less atoms. So we probably should merge
unary operators with atoms or declare that atoms
are integer and verbatim strings and that special
stuff should be unary operator.
Anyway, for composite forms we need accessor to
get list arguments and operator. And we probably
should have a separate type for operators. For
operators we need a way to get its class,
corresponding symbol and some features.
Today opeators are symbols, so that would be
Rep for this type.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
