> Posted by: "Bernd Paysan" bernd.paysan@... berndpaysan

> Gforth and bigFORTH have made IORs throwable since the dawn of their ANS
> Forth compatibility (both during the draft process). However, we use the
> system-specific part of the throw code table, and have a way how to convert
> signal and errno numbers into the THROW space.
>
> If you relax your proposal in such a way that IORs must be throwable, and
> the system also must provide a way to print out diagnostic strings (e.g.
> the .ERROR we have in Gforth), a consent is easier to reach.

The proposal does not say that you *must* use these numbers, it
says that if you use these numbers, this is what the standard
means by those specific numbers. Consequently gForth will not
conflict with the proposal.

> I like to keep as much information as possible about the
> original error, so mapping errors to words that
> misbehave isn't such a good idea - a word like
> WRITE-FILE can fail for quite a number of reasons (no
> space left on device, pipe closed, low-level IO error,
> buffer outside address space, etc.). A backtracing
> utility is a better way to locate the error, and you'll
> then see which word misbehaved, as well.

Given the range of hardware and O/S, it is impossible in a
standard to go beyond saying that WRITE-FILE failed and a THROW
occurred. Most hosted systems require further work to get an
extended error code and/or string.

> So in general, I fully support the part of your proposal where IORs are made
> throwable, but I don't support your throw code scheme.

Again, the proposal does not make you use these numbers, it says
that if you do use these numbers, this is what they should mean.

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads