[ ] conforms to ANS Forth. PFE (Guido Draheim) [ ] already implements the proposal in full since release [ ]: [ ] implements the proposal in full in a development version: [ ] will implement the proposal in full in release [ ]. [ ] will implement the proposal in full in some future release. [ ] There are no plans to implement the proposal in full in [ ]. [ ] will never implement the proposal in full: PFE
[ ] I have used (parts of) this proposal in my programs: [ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it: Graham Smith [ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard: [ ] I would not use (parts of) this proposal in my programs.
ALLOCATEare not specified, and an application has no entitlement to use them as
THROWcodes. The leads to very clumsy code of the form:
: ?THROW \ ior throwcode -- SWAP IF THROW ELSE DROP THEN ; ALLOCATEHowever, we also see many instances of code such as
ALLOCATE THROWwhich leads to silent aborts when a system issues
-1 THROW(as it is currently entitled to) or incorrect error messages.
THROWable. The only downside has been some necessary conversion of operating system error codes to ANS or application error codes.
Some years ago, some people objected to making iors the same
THROW codes because of the documentation overhead. This
RfD is made to sample opinion again, particularly among Forth system
THROWcode table (Table 9.2 in 9.3.5) so that there is a separate
THROWcode for each word that returns an ior.
THROW/ior impact - table 9.2 in Basis1
name Type Constant? Meaning
- - the
X:ThowIORsextension is present
value text -59
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.
.ERROR we have in Gforth), a consent is easier to reach.
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
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.
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.
Stephen Pelc points out that the proposal does not say that you must use these throw 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.
Given the range of hardware and O/S, it is impossible in a standard to go
beyond saying that
WRITE-FILE failed and a
occurred. Most hosted systems require further work to get an extended error
code and/or string.
Note that you can be both a system implementor and a programmer, so you can submit both kinds of ballots.