[ ] 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.
ALLOCATE
are not
specified, and an application has no entitlement to use them as
THROW
codes. The leads to very clumsy code of the form:
ALLOCATE IForTHROW ENDIF
: ?THROW \ ior throwcode -- SWAP IF THROW ELSE DROP THEN ; ALLOCATEHowever, we also see many instances of code such as?THROW
ALLOCATE THROWwhich leads to silent aborts when a system issues
-1 THROW
(as it is currently entitled to) or incorrect error messages.
THROW
able. 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
as THROW
codes because of the documentation overhead. This
RfD is made to sample opinion again, particularly among Forth system
implementers.
THROW
codes.
THROW
code table (Table 9.2 in 9.3.5) so that
there is a separate THROW
code for each word that returns
an ior.
THROW/ior impact - table 9.2 in Basis1
name Type Constant? Meaning X:ThorwIORs
- - the X:ThowIORs
extension is present
value text -59 ALLOCATE
-60 FREE
-61 RESIZE
-62 CLOSE-FILE
-63 CREATE-FILE
-64 DELETE-FILE
-65 FILE-POSITION
-66 FILE-SIZE
-67 FILE-STATUS
-68 FLUSH-FILE
-69 OPEN-FILE
-70 READ-FILE
-71 READ-LINE
-72 RENAME-FILE
-73 REPOSITION-FILE
-74 RESIZE-FILE
-75 WRITE-FILE
-76 WRITE-LINE
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.
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.
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 THROW
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.