Ralf Hemmecke wrote:
>
> This is the only place that SExpression appears in integer.spad.pamphlet.
>
> https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/integer.spad.pamphlet#L198
>
> x exquo y ==
> zero? y => "failed"
> z : SExpression := INTEXQUO(x, y)$Lisp
> integer?(z) => z pretend %
> "failed"
>
> Since that file uses implicitly that the underlying form is a lisp
> s-expression, I find it a bit artificial to have SExpression in this place.
>
> Since INTEXQUO is defined like this:
>
> (defun INTEXQUO(X Y)
> (multiple-value-bind (quo remv) (TRUNCATE X Y)
> (if (= 0 remv) quo nil)))
>
> https://github.com/hemmecke/fricas/blob/master/src/interp/spad.lisp#L65
>
> why not replacing SExpression by a direct Lisp call and thus make
> integer not depend on SExpression?
>
> However, replacing the code like so...
>
> x exquo y ==
> zero? y => "failed"
> z := (INTEXQUO(x, y)$Lisp) pretend %
> -- or better this?
> -- z: % := (INTEXQUO(x, y)$Lisp) pretend %
> NULL(z)$Lisp => "failed"
> z
>
> (on top of r1699) compiles the algebra, but hangs (similarly to my
> LispExpression patch) during the the build of coverex.pht. Isn't that
> strange?
Nothing strange. Basic Spad types have fixed relation to Lisp
types. You are not allowed to store someting different than
Lisp integer in Spad Integer variable. Similarely, Spad
string must be Lisp string, Spad List must be Lisp list,
Spad DoubleFloat must be Lisp DOUBLE-FLOAT, Spad
Boolean must be either Lisp NIL or Lisp symbol T.
Spad compiler, basic domains and Spad runtime support
cooperate to ensure this. You have broken the contract,
and the result is as usual (hang or crash).
If you insist on something different than SExpression, then
None should work. But one of uses of SExpression is to
deal with low level values. In this case SExpression
provides you nice function to test if the result trurly
is an integer.
To put this differently: to have real language we need
to represent Spad data as bits in memory. We also
want garbage collection. AFAIK state of the art
with garbage collection is still that data must have
tags so that garbage collector can understand it.
We need at least integers, strings, lists, machine
floats and arrays of tagged data. We want to do
CAS, so we need true integers. Also, to represent
math object symbols are quite nice. As you see
we get something close to SExpression. Given that
we need it anyway, we may expose it as Spad domain,
to allow low level programming in Spad. Based on
similar reasoning as above some folks claim that
we absolutely need Lisp for FriCAS (or CAS in
general). But such general claim is wrong (or
at least misleading):
- s-expression form small part of Lisp
- some aspects of Lisp s-expressions are suboptimal
for FriCAS: in FriCAS symbols, lists and booleans
are conceptualy disjoint. But Lisp uses low level
tricks to ensure that NIL is both a symbol and
an empty lists. Moreover, in Lisp booleans are
just subset of symbols consiting of two values,
that is NIL and T.
- in Lisp symbols have slots to store function,
value and property list. In FriCAS those slots
are not needed so pure waste.
The point of above is that something like current
SExpression will stay. Of course, when possible
we want higher level code. But in low level parts
use of SExpression is quite appropriate. In fact,
introducing direct Lisp call in the code above
would be a step backwards.
--
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.
