Ralf Hemmecke wrote:
>
> > I am commited to moving code from Boot to Spad. However, I am
> > worried by "big bang, fresh start" approach you seem to prefer.
>
> Hmmm... I usually go for the "rewrite from scratch". ;-)
> Well, in this case it will basically be one anyway, because it seems
> that the most important function is mathprint and that function has to
> be moved to SPAD (i.e. written from scratch) anyway.
Moved to SPAD != written from scratch. Spad and Boot share most
of syntax and semantics is reasonable close. In favourable
cases convertion means adding type declarations and coercions.
In quick and dirty version may be a lot of '$Lisp' calls
to functions implemented in other files. Once Spad version
is working this may be cleaned up and replaced by functions
from Spad library. Of course, Boot pattern matching is not
available in Spad and ATM Spad has no dynamic variables,
so one has to change code accordingly. But usually such
changes are quite mechanical in nature. Bottom line is
that Spad code looks quite different but can be obtained
much faster then writing from scratch. In particular
suring such rewrite code is supposed to perform exactly
the same thing as original, so testing reduces to comparing
output of new routine with output of the old one. In
this way it is much easier to find errors. Of course,
rewrite may discover bugs in original code, in such
case it is better to postpone fix after rewrite (unless Boot
original can be fixed easily). Important point is that
during cleanup/rewrite code is supposed to be functionally
equivalent to original.
> > There are dependencies, some are non-obvious.
>
> What you mentioned about hyperdoc, is not so clear to me.
>
> > HyperDoc use of OutputForm needs to be cleaned up: currently
> > HyperDoc uses a set of "universal" routines to convert
> > s-expressions to text form.
>
> Hmmmm... can you say which part of HyperDoc uses OutputForm or
> SExpression? I don't exactly see a reason, why hyperdoc should ever have
> to touch OutputForm or i-output.boot or any of the formatting domains
> like HTMLFormat, TexmacsFormat, etc.
HyperDoc has to print Spad objects (in particular types). For
larger things it uses 2D output routines. But some object are
inline, so it needs stining (1D) form.
> > In particular, we need routine to do 1D text output of
> > OutputForm.
>
> Yes. Maybe we can start first with that. Since some time I am missing a
> format that would allow me to copy & paste things back to fricas.
>
> > Coming back to 'i-output.boot', I would like to have
> > Spad version. I believe that this is possible to do
> > _keeping_ existing representation,
>
> You mean, SExpression?
Yes. But once code is cleaned up you rarely have need to
look at representation, so it does not matter much. OTOH
as long as code is not clean enough it is hard to change
representation. Of course, to get better assurance to
code is clean it makes sense to build it and test with
alternative representation. And failures after changing
represetaton may help identify deeper problems.
> What I actually don't understand is why SExpression must depend on
> OutputForm. Is this used in some place?
It does not, I just commited appropriate change.
--
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.
