Ralf Hemmecke wrote:
>
> I'm surprised. Why is rest translated into CDR and first not into CAR?
> Oh, because of
>
> first x == SPADfirst(x)$Lisp
> rest x == CDR(x)$Lisp
>
> and
>
> (defmacro |SPADfirst| (l)
> (let ((tem (gensym)))
> `(let ((,tem ,l)) (if ,tem (car ,tem) (first-error)))))
>
> This makes it somehow not crash because of errors.
>
> Ummm, I have some issues.
>
> 1) The call
> rest []
> should fail or even crash FriCAS instead of silently return
> the empty list.
> 2) The call
> first []
> should fail or crash FriCAS.
> 3) My wish for 1) and 2) applies to spad programs only, in the
> Interpreter, I would certainly like to keep my FriCAS session if by
> mistake I take the first element of an empty list.
>
> The implementation of List internally uses Qfirst ==> QCAR$Lisp.
>
> (defmacro qcar (x) `(car (the cons ,x)))
>
> (I don't understand why QCAR is not simply CAR, but that would be a lisp
> question.)
> Unfortunately the fast version isn't exported. :-( I didn't know.
>
> Maybe it's too early, but, Waldek, do you see a chance that one could
> have failsafe versions for first/rest and by default the quick versions
> if the code is compiled by the spad compiler.
>
> I somehow think of
>
> SomeDomain_Interpreter: SameExportsAsSomeDomain == SomeDomain add
> ...
> -- override functions that are not failsafe.
> ...
>
> I.e. each potentially crashing domain would have a corresponding
> ..._Interpreter wrapper domain that does the error handling.
>
> I guess catching crashes by the Interpreter without such wrapper domains
> it probably impossible in general.
>
> Anyway, I think, that the error test that first currently performs, is a
> waste of time. It is testing for something that should never happen. It
> helps debugging, yes, but why would one want it to be there in a program
> that one has carefully proved to be correct?
First about Lisp matters: in Lisp nil = CAR(nil) = CDR(nil). In
typical implementation this is arranged in a way which have no
runtime cost. QCAR(x) is basicaly saying to Lisp "I want CAR(x)
and BTW I am really sure that x is a nonempty (possibly improper) list".
Given that applying CAR to something which is not a list is an
error (not that emply list is a list and Lisp CAR is legal on it),
the difference is small, but Lisp compiler is less likely to
insert extra checks than in case of CAR (OTOH for QCAR Lisp
compiler may decide to check your words and insert extra test
to verify that the list is nonempty).
Now, back to Spad: the current convention is that potentially
failing Spad operation check their arguments: array accessors
check that indices are in bounds, 'first' check that it got
sensible list. You may ask why 'rest' preforms no check. Possible
answer is that due to Lisp definition rest on empty list returns
empty list which is type-correct result. OTOH if you have list of
integers geting nil would violate type rules, so is not
acceptable.
Concerning wasting time: Spad convention is to have qelt for
fast non-checking accessors. For list this would be
'qelt(l, "first")' and 'qelt(l, "rest")', etc. I am not
sure if they work, but even if they work they are not fast.
We could easily add them, but I am not sure if they are
needed -- I do not expect significant speed gains due to
such accessors.
Concrening crashing on incorrect 'first': IME during
developement of Spad code checks automatic checks help
a lot. Since we encourage users to develop own Spad
code shipping with checks on by default is only
reasonable way. Also, it is not so easy to separate
interpreter from compiler, because from interpreter
you can call all exported routines giving them potentially
incorrect data.
BTW: If you want speed gain due to skiping checks you need to
also skip Lisp checks by setting safety to 0.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
