RE: [colorforth] abort

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Tue, 3 Jun 2003, [iso-8859-1] Fréderic DUBOIS wrote:

> > -----Message d'origine-----
> > De : Mark Slicker [mailto:maslicke@xxxxxxxxxxx]
> > Envoyé : lun. 2 juin 2003 20:17
> > À : colorforth@xxxxxxxxxxxxxxxxxx
> > Objet : Re: [colorforth] abort
> >
> > I suppose crashing is ok if you don't loose important information, and
> > boot times are minimal. However it is seen by many as an annoyance.
> >
>
> Even when booting very fast, crashs are a problem as you may loose
> modifications. This forces you to flush/save your data on disk before
> running new code. At the beginning, one expects that kind of crash, but
> thereafter if a rare condition happens, you may lose both your modifications
> and informations on what provoked this crash.

True. I guess I don't understand why you would let a crash happen if it is
easily avoidable. It is something I have no tolerance for in applications
I publish or use.

> >
> > Mark
> >
> > On Mon, 2 Jun 2003, Chuck Moore wrote:
> >
> > > Abort  generates indecision in my mind. I'm disturbed by
> > all the words in
> > > ANSI Forth and have tried to minimize them.
> > >
> > > The concept of  catch  and  throw  are an example. They
> > seem to emphasize
> > > the importance of errors. Much better to eliminate the
> > possibility of error
> > > than to compensate for it. So I left out  abort.
> > >
>
> I just moved from a defered ABORT to CATCH / THROW in my system. I found
> that CATCH was better to handle errors. If I look at my exception list...
> 1 word not found
> 2 floppy I/O error
> 3 stack underflow
> 4 file I/O error ( DOS-hosted version )
> ... I see that 1. is resolved by the Colorforth editor, 3 is resolved by
> using circular stack,

3 can be resolved in the design of software. Although for Forth hardware
that is a nice solution.

> 4 is a complexity brought by the OS, and 2 rarely
> happens and cannot in general be solved. It shows that Abort and friends are
> solving consequences of the problem, not the problem itself.
> One of the idea of CATCH is to delay decisions on what to do when an error
> occurs and let an application decide. I think this may happen when one
> writes libraries, or some code to be shared. Maybe, this means we should not
> do that?

I'm not familer with ANS Forth version, but in general it seems to be
developed as an alternative to error codes, a special value
returned to indicate an error. It is perhaps a superior mechanism, errors
not handled get reported by the system.

What Chuck is doing it seems, is either eliminating the possibility of
error or dealing with the error directly when it happens (or aparently in
some cases not dealing with the error at all).

It seem to fall in line the philosophy of early binding, making decisions
as early in the devlopment process as possible.

In constrast, I have heard languages like Smalltalk and Lisp advocate a
late binding aproach.

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. Lisp and Smalltalk seem to pushing the limits of flexibility,
efficiency takes a back seat.

The implications for code sharing are unclear to me. I find Forth code
very reusable but the granularity is much smaller. I reuse ideas in code,
and sometimes single lines. It is nothing like the verbataim use of code
common in C environments.

I hold out hope for collaboratively built Forth systems, where ideas and
code can be exchanged freely. However from my experience, it does not seem
a likely occurrence.

Mark

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


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