On 12/03/14 01:12, Waldek Hebisch wrote: > 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.
As an experiment I started to tabulate the lisp calls here: http://www.euclideanspace.com/maths/standards/program/spad/lisp I only got as far as the pamphlets starting with 'a' and it doesn't really add any value as it stands, it needs someone such as yourself, to explain what each one does. They should really be documented because they are part of the user interface, well part of the SPAD programmer interface. Even new SPAD programmers may start by modifying library code and so will come across these. However, since you say you can remove them relatively easily, I won't waste any more time on them. > 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. I suspect that graphical interface should really have something closer to intermediate form, that is, a set of strings need to be arranged vertically or horizontally but not try to calculate position in terms of fixed width characters. I think that what needs to be on the mathematical side of the interface is stuff like truncating numbers to a certain number of decimal points and removing unnecessary brackets round infix operators. I think you saying that it would not be practical to write i-output.boot in SPAD, in which case I will wait for now and look forward to the outcome of what you and Krystian are doing with great anticipation. Martin -- 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.
