RE: [colorforth] abort

[Fréderic DUBOIS <frederic.dubois@xxxxxxxxxxxxx>]

> -----Message d'origine-----
> De : Michael M. Butler [mailto:mmb@xxxxxxxxx]
> Envoyé : mar. 3 juin 2003 20:43
> À : colorforth@xxxxxxxxxxxxxxxxxx
> Objet : Re: [colorforth] abort
> 
> 
> On Tue, 3 Jun 2003 12:56:39 -0400 (EDT), Mark Slicker 
> <maslicke@xxxxxxxxxxx> wrote:
> > There apears to be clear tradeoffs between the aproachs. 
> Forth in style
> > of Chuck Moore is pushing the limits of the machine, producing code
> > which is small, simple, fast and efficient. The consequence 
> is that a
> > greater amount of skill is needed by the programmer and the 
> system is 
> > more fragile.
> 
> But consider that "fragile" might be good if you want the 
> (sub)system to 
> "break" clearly and unambiguously when something goes 
> horribly wrong.  I 
> sometimes use the adjective "crystalline" or "gemlike" to

Like diamonds?
 
> describe those 
> sorts of systems.
> 

But you lose some important information: you don't know where and/or why the
system has crashed. That may have an impact on your productivity.
ABORT can exist ( the topic line ) in order to let the system write it's
epitaph before dying; but that should be in your debug toolbox, not in the
kernel.

> 
> MMB
> 
> PS: I think the only acceptable reason for a stack underflow 
> in validated 
> FORTH code ought to be a cosmic ray hit. :)
> 

This may be a problem if you're writing space probe control software :)
Stack underflow checking is _of course_ for debug only.

 Amicalement,
  Frederic


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com