THROW and iors

[Stephen Pelc]

I posted this around September 2006, but it was not the time. Now
some people seem to believe it is a good idea that ior return values
can be THROWn. Here it is again.

Stephen
=====================================
ThrowIors.txt
Stephen Pelc, 21 August 2006

Rationale
=========

Problem
-------
Error codes returned by some words, e.g. 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 IF <lit> THROW ENDIF

or

: ?THROW \ ior throwcode --
SWAP IF THROW ELSE DROP THEN ;

ALLOCATE <lit> ?THROW

However, we also see many instances of code such as

ALLOCATE THROW

which leads to silent aborts when a system issues -1 THROW (as
it is currently entitled to) or incorrect error messages.

Current practice
----------------
As far as possible within historical and commercial constraints,
MPE has attempted to make iors 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 as
THROW codes because of the documentation overhead. This RfD is
made to sample opinion again, particularly among Forth system
implementers.

Solution
--------
All words which return an ior should have one value assigned in the
THROW code table (Table 9.2 in 9.3.5). This table reserves values
-1..-255 for system-defined exceptions. Systems that ignore this
proposal are unaffected if they already avoid these values, and
systems that implement this proposal gain use of these new fixed
iors.

The only downside is that we have to define some new THROW codes.

Proposal
========
Extend the 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.

Labelling
=========
ENVIRONMENT? impact - table 3.5 in Basis1
name stack conditions

THROW/ior impact - table 9.2 in Basis1
value text



--
Stephen Pelc, steph...@mpeforth.com
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

[Bernd Paysan]

Stephen Pelc wrote:
> I posted this around September 2006, but it was not the time. Now
> some people seem to believe it is a good idea that ior return values
> can be THROWn. Here it is again.

No need for bringing this up again. As far as I can see from the
current snapshot of Forth200x, this is already in, so you remembering
that it wasn't a good time is probably wrong :-). Maybe you got too
many flames. We accepted your proposal after some heavy discussions and
minor modifications in 2007:

http://www.forth200x.org/throw-iors.html

However, I don't know who uses these additional error codes. We
certainly use the biased OS error codes, which are also expicitely
mentioned in Forth200x (and that was the minor modification which made
me happy).

In Gforth (similar in bigForth) we get

s" /foo" r/w create-file throw
:1: Permission denied
s" /foo" r/w create-file >>>throw<<<

or this

s" /home/bernd" r/w create-file throw
:2: Is a directory
s" /home/bernd" r/w create-file >>>throw<<<

And of course, "permission denied" or "is a directory" are outside the
scope of a Forth standard, these are biased POSIX or Linux or even
Windows error codes. And it is of course more useful than VFX Forth,
where this throw currently still results in a silent abort.

We use a special range of the throw-codes which are fed to strerror()
(range (-2048,-512]) or strsignal() (range (-512;-256]). We map some
error codes (especially from signals) to standard error codes, because
that way they make more sense (especially a SIGSEGV can mean both an
address violation as well as stack under/overflow).

To go a bit further into discussion, there are some useful words in the
error handling which have not yet found a way into the standard draft:

We have .ERROR to display the error, and I think this is insufficiently
factored, and there should be an ERROR$ (which I just have factored out)
which converts the number to a meaningful string. Reference
implementation might be something like

: error$ ( n -- addr u ) \ human readable error string
base @ >r decimal
s>d tuck dabs <# #s rot sign s" error #" holds #> r> base ! ;

Of course, while this is human readable, this still requires looking
into the manual ;-). Furthermore, we have EXCEPTION ( addr u -- n )
which takes a string and returns an individual (consecutive) throw-code
(in the system range (-4096,-2048]). When you pass that n to ERROR$,
you get your string back.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:js5bp1$eo7$1...@online.de...

> expicitely

+l
-e

explicitly


RP

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>I posted this around September 2006, but it was not the time. Now
>some people seem to believe it is a good idea that ior return values
>can be THROWn. Here it is again.

That proposal is in Forth 200x, but it does not say any more than
Forth-94 that the iors returned by various words are sensible throw
codes:

>Proposal
>========
>Extend the 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.

Systems are (thankfully) not required to produce these codes as iors.

More importantly, systems are (unfortunately) not required to do
anything sensible if they catch a thrown ior.

It's admittedly hard to nail such things down, because we don't nail
the system's exception handler down. And given that most systems do
the right thing, it may be good enough to put in something informal
that says that iors are expected to be THROWn, and that the system's
exception handler should react accordingly.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/

[Hugh Aguilar]

On Jun 23, 11:04 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> I posted this around September 2006, but it was not the time. Now
> some people seem to believe it is a good idea that ior return values
> can be THROWn. Here it is again.

I do that all of the time in recursive-descent search programs. The
idea is to do the recursive-descent search, and when the result is
found do a THROW. This is much more efficient than backing up out of
the whole mess passing a flag along that has to get checked at each
level to indicate that we are backing out. The value that THROW throws
is the result that was found. If the result fits in a cell, then that
is what gets thrown --- otherwise a pointer to a record on the heap
gets thrown.

Here is an example of a discussion of my code that does that:
https://groups.google.com/group/comp.lang.forth/browse_thread/thread/c0fe67c350a5cec3
Please ignore all of the modifications that Marcel Hendrix made --- he
later admitted that he didn't understand how the algorithm worked.
Also note that it is my program; Marcel Hendrix had removed my name
from the copyright notice and replaced it with "some cab driver" ---
but I am the programmer. My own code, as well as some more encryption-
cracking stuff, can be found in the novice package:
http://www.forth.org/novice.html

[Coos Haak]

Op Sun, 24 Jun 2012 04:17:56 -0400 schreef Rod Pemberton:

label's
s/'//

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

[Albert van der Horst]

In article <fda9df2a-3346-4549...@s6g2000pbi.googlegroups.com>,

Hugh Aguilar <hughag...@yahoo.com> wrote:
>
>Please ignore all of the modifications that Marcel Hendrix made --- he
>later admitted that he didn't understand how the algorithm worked.
>Also note that it is my program; Marcel Hendrix had removed my name
>from the copyright notice and replaced it with "some cab driver" ---
>but I am the programmer. My own code, as well as some more encryption-
>cracking stuff, can be found in the novice package:
>http://www.forth.org/novice.html

Funny. First you complain that Marcel Hendrix writes his own program,
then you complain that he didn't grant you the copyright.

Groetjes Albert

Maybe a little cranky, but I just got killed on level 19 by a dragon,
while I could teleport at will and had a ring of teleport control.


--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[jfong]

Albert van der Horst於 2012年6月26日星期二UTC+8上午9時08分41秒寫道：

What is the funny? Can you read?

Jach Fong

[BruceMcF]

On Jun 25, 11:13 pm, jfong <jf...@ms4.hinet.net> wrote:
> Albert van der Horst於 2012年6月26日星期二UTC+8上午9時08分41秒寫道：
>
>
>
>
>
>
>
>
>

> > In article <fda9df2a-3346-4549-8080-6c05c60a2...@s6g2000pbi.googlegroups.com>,

> > Hugh Aguilar  <hughaguila...@yahoo.com> wrote:
>
> > >Please ignore all of the modifications that Marcel Hendrix made --- he
> > >later admitted that he didn't understand how the algorithm worked.
> > >Also note that it is my program; Marcel Hendrix had removed my name
> > >from the copyright notice and replaced it with "some cab driver" ---
> > >but I am the programmer. My own code, as well as some more encryption-
> > >cracking stuff, can be found in the novice package:
> > >http://www.forth.org/novice.html
>
> > Funny. First you complain that Marcel Hendrix writes his own program,
> > then you complain that he didn't grant you the copyright.

> > Groetjes Albert

> What is the funny? Can you read?

Complaining that (1) it is *not* his program, ignore it, and (2) he
was not credited with author credit.

[jfong]

BruceMcF於 2012年6月27日星期三UTC+8上午1時18分31秒寫道：

No, Hugh Aguilar said "Please ignore all of the modifications that Marcel Hendrix made", not the program he wrote. There are so many filters about Hugh Aguilar in some guys' mind, almost make them blind.

Jach

[Hugh Aguilar]

I reread that thread:
https://groups.google.com/group/comp.lang.forth/browse_thread/thread/c0fe67c350a5cec3
This thread is highly instructive! If anybody wants to understand
Forth, and the comp.lang.forth community, I would recommend reading
this thread --- everything that anybody needs to know about
comp.lang.forth can be found in this thread.

Here are a couple of quotes from the thread:


On Nov 26 2009, 1:13 am, Hugh Aguilar <hugoagui...@rosycrew.com>
wrote:
> On Nov 25, 4:14 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>
> > >On Nov 25, 8:57=A0am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> > >> I don't use gforth. What does that error message mean? What is a
> > >> "compile-only word?"
>
> > A word without interpretation semantics.
>
> > >It doesn't like you taking the address of ";" , though I don't
> > >understand why.
>
> > Because ";" has no execution or interpretation semantics.  The
> > execution token returned by ['] represents the execution semantics,
> > but since ";" does not have that ...
>
> I don't understand how a word can not have execution semantics. That
> would be like a person not having a body --- we seem to be descending
> into mysticism.



On Dec 6 2009, 6:00 pm, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> On Dec 6, 5:30 pm, Jonah Thomas <jethom...@gmail.com> wrote:
>
> > Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> > > What you are describing doesn't make any sense at all. There is no
> > > such thing as a "dual-xt" Forth word!
>
> > There certainly can be. GForth has been described that way sometimes,
> > they set up the possibility of arranging GForth so that the special
> > words that cause trouble can have two different xt's and can give you a
> > different xt in different circumstances.
> ...
> The difference is that what I described --- two words, each with its
> own xt --- makes sense. The idea of a "dual-xt" word sounds like a
> schizophrenic nightmare.


And here is a quote from a recent thread on the Forth200x mailing list
(note how little has changed from 2009 to 2012):



From: Jenny <jenny...@googlemail.com>
To: fort...@yahoogroups.com
Sent: Tuesday, May 22, 2012 9:14 AM
Subject: [forth200x] Re: RfD: Drop execution semantics of LEAVE and
UNLOOP



--- In fort...@yahoogroups.com, Bernd Paysan <bernd.paysan@...>
wrote:

> Am Freitag, 18. Mai 2012, 19:14:39 schrieb BruceMcF:
> >
> > The least intrusive reading that eliminates that seeming contradiction
> > is to read the definition of execution token as:
> >
> > "execution token:
> > A [^] type of [\^] value that identifies the execution semantics of
> > a definition."
> >
> > Then there is no contradiction. When only one xt is return by FIND,
> > that is the execution token that does in fact identify the execution
> > semantics. When different xt's are returned by FIND, the one returned
> > in compilation state *identifies* the execution semantics, and the one
> > returned in interpretation state identifies the interpretation
> > semantics.
> >
> > In addition to being the least intrusive reading, that reading is
> > *verified* be each and every definition for which interpretation
> > semantics are specified and so are execution semantics.

At this point I am thoroughly confused. If FIND can return two
different xt's according to STATE, which do ' and ['] return - the
interpretation semantics or the execution semantics?

[Anton Ertl]

Hugh Aguilar <hughag...@yahoo.com> writes:
>At this point I am thoroughly confused. If FIND can return two
>different xt's according to STATE, which do ' and ['] return - the
>interpretation semantics or the execution semantics?

That's a good question. For most words, they are the same, so there
is no difference for them. The exceptions are:

1) Words like File wordset S" with interpretation semantics and no
defined execution semantics.

2) Words like EXIT with defined execution semantics and explicitly
undefined interpretation semantics.

3) Words like IF without execution semantics and with explicitly
undefined interpretation semantics.

A question to the Forth-94 TC resulted in an informal answer by Loring
Craymer (a TC member) that ' EXIT and ['] EXIT are non-standard,
because of the sentence in 6.1.0070:

|When interpreting, ' xyz EXECUTE is equivalent to xyz.

It's pretty clear that ' IF and ['] IF don't need to work.

As for ' S" and ['] S", it's not clear that this is required to work,
but if it is required, the xt should represent the interpretation
semantics of S" (that's what Gforth implements).

[Hugh Aguilar]

On Jul 3, 6:34 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> It's pretty clear that ' IF and ['] IF don't need to work.

WTF???

This is just absurd, this idea that some words don't have xt values,
or that some have more than one xt value that depends upon the state
of the system when FIND is called.

You were spouting this weird nonsense in 2009, and you still are in
2012. You just don't know how to write a cross-compiler.

BTW, here is another whopper from that same thread:

On Dec 8 2009, 3:18 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> There are three types of compilation involved
> 1) Host compilation
> 2) Clone compilation (target CPU same as host and memory matches)
> 3) Cross compilation (target CPU is not host CPU)
>
> In the third case you have to simulate *everything* when dealing
> with both the definition and execution of defining words. It's not
> easy. You also have to extend the normal Forth compiler by at least
> two time frames. Forth cross compilers are much more complicated
> and much more subtle than they appear to be.