I think it is better to explain more how SCOPE is supposed to
work and what problem it solves. Main point is that coerce
to OutputForm works in recursive way, so at any point coerce
need to work with incomplete information. To avoid variable
clashes we need semi-global approach, that is coordinate
use of varibables on for whole expression or sequence of
expressions.
If I understand correctly, the semi-global approach will then come from
the fact that the construction of the OutputForm happens recursively in
different domains and the actual formatter (function precondition) has
the complete OutputForm structure with basically a global view on it.
With SCOPE coerce can work alost as it works now: affected
domains will always wrap output in SCOPE marker, so no
need to "recognize". Also, the whole output of coerce
will be wrapped, so change to coerce will be quite small.
OK, I understand. Such an approach would certainly work.
Just as a side remark if "precodition" is a must then Qian's recent
commit 976a6434f04f1fc9cd2ba04e2d8b13aed061796f should rather use
format(op::OutputForm)$Formatter(Format1D)
instead formatExpression. I've overlooked that when I gave my OK.
Actual renaming of variables will be done as optional
and configrable extra transformation of output form.
If "precondition" removes all the (SCOPE ...) stuff and replaces the
variables accordingly that would be doable. However, how would it
recognize which symbols it actually has to replace and which not?
Something like
S1 ==> SUP INT; S2 ==> SUP S1
s1 := monomial(1,1)$S1
s2 := monomial(1, 2)$S2
s := s1*s2
(s::OutputForm) pretend SExpression
with output (* "?" (^ "?" 2))
would become (SCOPE (* "?" (SCOPE (^ "?" 2)))) and easy to transform.
I worry a bit about cases where there is "?" is inside a SCOPE but is
not a variable. It would be safer if then the default variable name
would rather be something that does not occur otherwise. But "failed" is
another candidate to worry about.
More generally, the idea is that we can have more
flexible relation between output form and actual
output.
Well, one may wish that and I a not strictly against it. However,
already OutputFormat itself is a bit questionable. It not only holds the
actual data that is to be shown, but already contains constructs how the
data should be show, in particular VCONCAT is such a construct. But OK,
we treat this as logical construct and the formatter can decide what to
do with it.
AFAIU, you want to introduce another layer with the signature
OutputForm -> OutputForm. I don't think there would be any problem with
it as long as we either leave the relevant heads of OutputForm as they
are now, or even better document their intended meaning as clearly as
possible, so that transformer and formatter routines can build on it and
one could perhaps apply even two or more transformers.
In that sense SCOPE should be included into the list of possible
OutputForm heads and can be treated as NOOP by the current formatters.
Note: such transformations are possible now and some
are done by default. But they may be wrong for
some domains, so we need extra semantic info in
output form to make sure such transformations
are reliable.
I am sceptical about putting more semantics into OutputForm. In fact, I
see OutputForm as the structure that comes right before the actual
output. So I would not put algebraic knowledge into it. If we want that,
I would rather opt for a general expression tree structure that has all
semantic information. You might want to look at ExpressionTree and
related domains in the Aldor library. Yes, it is a different approach
than that of OutputForm. I could not yet decide which one I find better,
but both have their pros and cons. Anyway, a proper ExpressionTree in
FriCAS would probably not be such a bad idea. I haven't thought deeply
about this, but it would also be a bit like input form.
Anyway, why can transformations not be done in our current Expression
domain and then be converted to OutputForm?
I think for a really flexible approach there is much open for discussion.
You somewhat think that changing output form
is problematic.
No, not really. Just thought it is unnecessary.
Ralf
PS: I will be away from the internet till August.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/72fe8c78-6ebb-68f4-3c30-eb73d8ee1492%40hemmecke.org.
