Martin Baker wrote:
>
> I have come across (and occasionally used myself) Lisp calls such as:
>
> sayTeX$Lisp "hello"
> mathObject2String$Lisp
> ATOM(expr)$Lisp break down an expression into atoms
> trapNumericErrors myTrap1(ff:DF-> DF, f:DF):DF ==
> s := trapNumericErrors(ff(f))$Lisp :: Union(DF, "failed")
> outputTran$Lisp
> COMPLEXP(x)$Lisp Test if x is complex number
>
> If people on this list thought it was a useful thing to do I could search
> for "$Lisp" in the library and make a more comprehensive list. I think it
> would then need those more knowledgeable than me to define their
> purpose/input/output definitions and to propose how they can be replaced by
> SPAD code (given the 'suboptimal' state of the documentation I'm guessing
> its not already documented). If that was done I could help out in doing the
> replacements.
As of today grep catches 1012 occurences of '$Lisp' in the algebra.
That is much smaller number than in say 2007. AFAICS most uses
have no "pure Spad" replacements: they define primitive operations
which Spad uses, but can not be defined in Spad. In other words,
they are effectively 'compiler builtins'. We can eliminate
some uses, but it is not entirely easy job. For example
'mathObject2String' is essentially a falback routine which is
intended to work in cases where Spad code does not understand
given Lisp object. So, it is natural to call to Lisp to
implement it. OTOH, I think that most uses are dealing with
data that Spad understands quite well, so in such cases it could
be replaced by other functions. There is a bunch of numeric
functions written in Boot and used only by Spad code, they could
be rewritten to Spad.
In itself Lisp code is not big problem: we have about 9000 lines
of handwritten Lisp and part of it is trivial to port (variable
initialization), parts needs to be replaced by entirely new code
for port anyway, the rest is not so big. More problem is that
we have about 67000 lines of Boot code. Some Boot may be dropped
(for example Boot compiler written in Boot) but most needs to
be rewritten. Since Boot and Spad have very similar syntax
rewriting should go relatively fast. But due to volume it
will take time.
>
> > Note that BOOT language is a thin
> > abstraction layer on top of CL. There's plenty of BOOT code in
> > src/interp that is not directly tied to the compiler. It could be
> > possibly rewritten into SPAD. My personal favourite, as for today, is
> > OutputForm domain. It converts data into s-expression and forwards
> > processing directly to BOOT code in src/interp/i-output.boot (~2400
> > LOC). I see no reason why it couldn't be rewritten into SPAD. Oh, by the
> > way, current implementation of mathprint function is really buggy.
>
> I have come across OutputForm when I wrote HTMLFormat which extends
> OutputForm so I do have some previous knowledge although I'm no expert. If
> the consensus on this list were that it were useful then I could look at
> it. I assume that it could not be completely replaced by SPAD code in that
> it would still require some interface to non-library code. So it would
> require someone to define this interface for me.
Main problem with 'i-output.boot' is that algorithm is nontrivial
and undocumented. Concerning "buggy", I do not think so. Of
course there are bugs. But I think that it mostly work as
intended by original authors. Big problem is that modern
standards are different and 'i-output.boot' is hard to modify.
Also, 'i-output.boot' contains hacks intended to cover up
problems elsewere. For example, the two first lines in
'outputTran' are
x in '("failed" "nil" "prime" "sqfr" "irred") =>
STRCONC('"_"",x,'"_"")
Clearly, we should generate correct form at the beginning
instead of such heavy-handed coverup.
Concerning system interfece: ideally core of 'i-output.boot'
should call no system function and just produce display list,
that list of string with positions. Then a simple routine
would print them at computed positions. The real work is
computing positions and strings. AFAICS the current
interface is: TERPRI (print newline), sayAlgebra (fancy
printer that implements highlighting), PRINTEXP (basic Lisp
printer) and PRETTYPRINT (basic Lisp printer with option
to "pretty" print).
BTW: Display list version would be easier to adapt to graphic
display.
--
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.
