Hi Alex,
thanks for your answer. It is a great pleasure to see how PicoLisp works...
In general, PicoLisp doesn't catch such errors, as this would induce
relatively high runtime overhead, in contrast to their extremely rare
occurrence in production programs.
I agree and I did not expect it.
And, after all, "Segmentation fault" *is* an error message, generated by
the hardware, isn't it? And you test your program at least once, don't
you?
It is and I do many times.
But this is not the point because you're going to loose unsaved data
and the error could also be caught somewhere else.
Setting a symbol to a number (like '1' above) is perfectly legal. And
"calling" a symbol with a numeric value means to call an internal
function (i.e. a function pointer). However, at memory location '1'
there is probably no function, but the interpreter cannot know this.
But when it comes to classes you are using a different scheme to dereference
memory locations:
: (load "@doc/shape.l")
-> move>
: (setq R (new +Rectangle 0 0 30 20))
-> $384486372
: ($384486372) # -> Segmentation fault
: (show $384486372)
-> ((draw> NIL (NIL (: x) (: y) (: dx) (: dy))) ...
: (show ($384486372))
!? (perimeter> NIL (* 2 (+ (: dx) (: dy))))
perimeter> -- Bad message
: (show (($384419102))) # ->Segmentation fault
Anyhow, not that impotant, as I said before.
Perhaps the FAQ
http://software-lab.de/doc/faq.html#segfault
should elaborate more on that?
> PicoLisp is a pragmatic language.
Pragmatic to whom?
> It doesn't check at runtime for all possible error conditions which
won't occur during normal usage.
What is normal usage?
> Catching the segfault signals is also not a good idea, because the
Lisp heap is most probably be damanged afterwards.
A fine excuse?
all the best
oskar
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
