Hi Oskar,

> But this is not the point because you're going to loose unsaved data
> and the error could also be caught somewhere else.

This is right. These errors are just signals, which could be easily
added to the signal handler (just extend sighandler() in "src/main.c" or
'sighandlerE' in "src64/main.l" with another "else if" clause).

I decided not to catch "hard" errors like segmentation violations and
bus faults, because there is a high risk that the heap is damaged
(inconsistent) after they occur, and letting the interpreter continue
might worsen things (crashing upon next garbage collection, creating an
inconsistent database, etc.).

> But when it comes to classes you are using a different scheme to dereference
> : ($384486372)   # -> Segmentation fault
> : (show $384486372)
> -> ((draw> NIL (NIL (: x) (: y) (: dx) (: dy))) ...

Yes. An analog case. The value of that symbol is not a function, but a
list of method definitions.

> Anyhow, not that impotant, as I said before.

All right :)

> > PicoLisp is a pragmatic language.
> Pragmatic to whom?

To the developers and to the users of the language, because it is
simpler to write and to understand. I believe that is "pragmatic" to
concentrate on things which are necessary in practical work, and not to
bother about the rest. Opinions vary, of course, about what is necessary
and what not.

> > It doesn't check at runtime for all possible error conditions
> which won't occur during normal usage.
> What is normal usage?

With "normal" I meant

   1. productive programming, after the initial learning
      phase is over, and trivial errors become rare

   2. running in a debugged application, after errors like the above are
      caught early in test runs

> > Catching the segfault signals is also not a good idea, because the
> Lisp heap is most probably be damanged afterwards.
> A fine excuse?

Not an excuse. See above. If you like, just add an else/if clause to
sighandler() in "src/main.c", or 'sighandlerE' in "src64/main.l".

♪♫ Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to