On Thu, Jul 10, 2008 at 02:06:33PM +0300, Andrei Ivushkin wrote:
> (setq X ((1 . 2) (3 . 4)))
>
> It crashes with segmentation fault...
Sadly ... yes ;-)
I must say, though, that it was never a major goal in PicoLisp to
protect the programmer from all possible kinds of errors.
Whenever there is a tradeoff between runtime checks and execution speed,
speed is given favor. The above case is especially difficult, as the
interpreter cannot distinguish legal from illegal pointers (here '1') to
executable C-code.
In retrospect, I think this strategy is good, as such errors happen
rather seldom in typical development work. And if they happen, they are
usually quickly located and fixed. It would would be a huge waste of
computing resources to check such things over and over again.
> but the system should warn about incorrect syntax, isn't it?
One problem is perhaps that there is virtually no syntax at all in Lisp.
Almost every expression might be legal code given a suitable context.
BTW, there are may ways to shoot into your foot with PicoLisp. How about
this one:
: (de foo (R S)
(let T (and R S)
(bar R (mumble S) T) ) )
You see the glitch? The system symbol 'T' is bound to some value
(possibly even 'NIL') during the execution of 'bar' and 'mumble'.
One slight remedy is to use the 'lint' function as often as possible:
: (lint 'foo)
-> ((var T) (def mumble bar))
It tells you that 'T' is a bad variable, and that 'mumble' and 'bar'
need to be defined.
Usually you don't call 'lint' for each function separately, but let
'lintAll' do the work:
: (lintAll)
-> ((foo (var T) (def mumble bar)))
But don't rely on runtime checks or 'lint' diagnoses! It cannot be a
substitute for thorough testing. A strong recommendation is to write a
set of unit tests for each application. You can see an example for the
PicoLisp kernel in "lib/test.l".
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
