On 12/03/14 21:04, Waldek Hebisch wrote: > Most of '$Lisp' are _not_ user interface. If you look at top users > of '$Lisp' calls you will see: > > ../algebra/omdev.spad.pamphlet:59 > ../algebra/fortran.spad.pamphlet:57 > ../algebra/sf.spad.pamphlet:56 > ../algebra/files.spad.pamphlet:55 > ../algebra/si.spad.pamphlet:54 > ../algebra/u32vec.spad.pamphlet:41 > ../algebra/list.spad.pamphlet:39 > ../algebra/string.spad.pamphlet:36 > ../algebra/integer.spad.pamphlet:35 > ../algebra/mathml.spad.pamphlet:32 > ../algebra/boolean.spad.pamphlet:24 > ../algebra/numarr.spad.pamphlet:22 > > Most of them wrap Lisp functionality and make it available as Spad > functions. For example in sf.spad we have > > x + y == add_DF(x, y)$Lisp > > This effectively tells Spad compiler how to add machine floats. > _All_ other places in algebra which want to add machine floats > should use '+' from DoubleFloat instead of calling underlying > Lisp operation. Operation like this form largest and most > important group, basically anything we do with integers, machine > floats, booleans, stings, lists will end up being performed > as one or more Lisp operations. So all primiteve operations > are taken from Lisp and other are written in terms of primitives > (via Spad wrappers). Normally you should have no need to > direcly use Lisp primitives, because you can get the same effect > from Spad operations. Of course, you need Lisp primitives when > you want to add new basic type, but then you need _new_ primitives > specially written for your new type. > > Other group of operations are ones which form system interface. > Such operations form bulk of '$Lisp' calls in 'files.spad'. > > Next, there are calls to interpreter functions. Those are > candidates for replacements by Spad code. In principle > user may want to call them. Note however that functions > which looked useful are typically exposed via Spad interface. > Also, technically it is possible to call from Spad > arbitrary interpreter function and there is no reason to > think that functions already called are more likely to be > called than other. So when you think about documenting > such calls for possible uses, you really have task of > documenting interpreter functions.
OK, thanks for this, I have added it to: http://www.euclideanspace.com/maths/standards/program/spad/lisp so it does not get lost and I will park it for now until its decided what happens to Lisp calls. > > Well, practical: yes, easy: no. > What needs to happen? it seems to me that: Rep of OutputForm is 'SExpression' and SExpression is SExpressionOf(String, Symbol, Integer, DoubleFloat, OutputForm) So what OutputForm holds is a recursively defined structure which is effectively a tree of lisp types. What this holds is an intermediate form of an expression in a way that is not specific to any domain and can be understood by all the output formatters. This avoids cross-cut issues, that is, every domain does not need to know specifically about every output format. So I get the impression that what needs to happen is the Rep of OutputForm needs to be changed from SExpression to something less lisp-like and more type-safe. So the Rep of OutputForm would contain is a union of: String, Symbol, Integer and DoubleFloat and this union would also contain formatting terms such as: "AGGLST","AGGSET","TAG","SLASH", "VCONCAT", "CONCATB","CONCAT", "QUOTE","BRACKET","BRACE","PAREN", "OVERBAR","ROOT", "SEGMENT","SC","MATRIX","ZAG" "SUB" and "SUPERSUB" These formatting terms have parameters which are also terms. So its still recursively defined but more type-safe and less lisp specific. This would allow us to get rid of a lot of 'pretends' in OutputForm but it would require all the formatters (such as HTMLFormat, MathMLFormat, SVGFormat and X3DFormat) to be changed to use this type-safe structure at the same time these formatters would be changed to call SPAD replacements for the calls to i-output.boot, this would get rid of a lot more 'pretends'. This would be a lot of reworking of code but at the end of it you would have something properly type-safe and Lisp-independent. Can SExpression be removed completely? 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.
