ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 10, Topic 27 Message 27 Fri Aug 31, 1990 D.RUFFER [Dennis] at 13:32 EDT From Elizabeth Rather, Chair, ANS X3J14 Technical Committee: This is addressed to those who have been commenting extensively on our work on UseNet and related boards. Although Mitch Bradley has been doing a great job of answering your specific comments (thanks, Mitch!), I do have a couple of personal (unofficial) remarks on recently popular topics. 2. Control structures: Wil Baden did a great job of spearheading our compromise on this issue. The upshot is that the ingredients (IF, BEGIN, WHILE, etc.) can work independently, and we document how to use them in combination to provide and satisfy conditional or unconditional forward or backward branches. POSTPONE allows you to compile references to these words (or others) as you wish. The complicated code you're all exchanging and wondering how to make work seems unnecessarily arcane. We accept an obligation to support any kind (topology) of control structure, but not all arbitrary custom syntactic variants. Wil wrote a nice paper on this subject which we'll include in the Rationale section of BASIS13. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/02/91)
Category 10, Topic 27
Message 28 Mon Dec 31, 1990
JAX at 20:40 PST
Dennis ---
Could you possibly print out this and drop it in the X3J14 hopper?
Thank you!
=jax=
-------------------------------------------------------------------
X3J14 Comment January 1, 1991 Page 1 of 1
Title: CATCH THROW "post".
Words: CATCH THROW
Abstract:
Minor quibbles on CATCH THROW.
Comment:
CATCH 14.1.0875 and THROW 14.1.2275 need the M attribute.
Meta-operation on the return stack has multiprogramming impact
in the form of a frame pointer that must be preserved through
context Switches.
Also, the stack diagram for CATCH was altered in BASIS14, but that of
THROW was left contorted.
Submitted by:
Jack J. Woehr Voice: (303) 422-8088
Vesta Technology Inc. FAX: (303) 422-9800
7100 W. 44th Ave, Suite #101 BBS: (303) 278-0364
Wheat Ridge, CO 80033 jax@well.UUCP JAX on GEnie
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpcameronjames@snoc01.enet.dec.com (James Cameron) (01/03/91)
|>Category 10, Topic 27 |>Message 28 Mon Dec 31, 1990 |>JAX at 20:40 PST |> |> Title: CATCH THROW "post". |> |> CATCH 14.1.0875 and THROW 14.1.2275 need the M attribute. |> Meta-operation on the return stack has multiprogramming impact |> in the form of a frame pointer that must be preserved through |> context Switches. I'm surprised they missed this. I changed the VARIABLE to USER when I implemented it a couple of months ago. While we're at it; are there any standards around the number that is passed to THROW? I'd like to separate the numbering between system and application situations. (I haven't seen the BASIS document because I gather I can't read the funny format that it is in; so apologies if it is in there). James Cameron cameronjames@snoc01.enet.dec.com
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (01/03/91)
> I'm surprised they missed this. I changed the VARIABLE to USER > when I implemented it a couple of months ago. We didn't miss it; as detailed in a previous posting, I believe that CATCH and THROW do NOT need the M attribute. The fact that the implementation needs to account for multiprogramming does not imply that CATCH and THROW have multiprogramming implications from the application's perspective. The sample implementation notes that HANDLER should be a USER variable: VARIABLE HANDLER \ Most recent error handler (should be a USER variable) The example was written this way because the usage of the word USER is inconsistent among several popular implementations. Traditionally, USER was a defining word with interface diagram: USER \ wordname ( user-area-offset -- ) F83 changed USER to a vocabulary name. Both variations have problems; in the sample implementation, I decided to punt and define HANDLER as a VARIABLE , leaving it to the implementor to read the comment and do the right thing for the particular system. > While we're at it; are there any standards around the number > that is passed to THROW? I'd like to separate the numbering between > system and application situations. Glad you asked that. That was one of the issues addressed at the last meeting. Greg Bailey and I worked it out over a plate of spicy chicken wings, while everybody else was eating lunch at Hardee's. From BASIS 14, section 14.5: Conforming programs may not define values for use with THROW in the inclusive range {-1 ... -4095}. These values are reserved for optional system use. The values {-1 ... -255} inclusive are reserved for assignment by this standard. The values {-256 ... -4095} are reserved for implementation defined assignments. A conforming system may choose to execute THROW when any particular ambiguous condition is detected and, if so, must use the value assigned that particular condition in the following table: Table 14.1. ANS Forth THROW code assignments To be determined (within the range -1 ... -255) Rationale Note: One important use for an error handler is to maintain program control under many conditions which ABORT . This is practical only if a range of codes is reserved. Note that an application may overload many standard words in such a way as to THROW ambiguous conditions not normally THROWn by a particular system (Greg Bailey) By the way, BASIS 14 changed the term "exception condition" to "ambiguous condition", reflecting the fact that term was intended to mean that the standard does not specify precisely what has to happen in one of these situations. For example, the standard does not prescribe what an implementation has to do in case of multiplication overflow. It could be silently ignored, or an ABORT might happen, or the process might be killed (I hope not), the result might wrap around, or max out, or be total garbage. The word "exception" was too loaded, because it always seemed to conjure up visions of a trap or an ABORT happening. Mitch
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/17/91)
Category 10, Topic 27 Message 33 Tue Jan 15, 1991 W.BADEN1 [Wil] at 20:14 PST Some readers may have the impression that my solution of the control flow problem is complicated and unwieldy. On the contrary it is as simple as it can be and no simpler. The six deficient and impossible-to-use system words of Forth-83 yield to two elementary words that complete the word-set that every Forth must have. One of these is an unconditional forward branch that complements the unconditional backward branch that virtually every Forth system already has. The other satisfies the minimum requirement to massage the implicit control flow stack. These two words can be added to any existing Forth system, even polyForth, cmForth, figForth, Forth-79, and native machine code compilers, to give them the ability to effect any control flow structure in a transparent and portable way. A further advantage of these words is that the occasional craving to roll-your- own control flow structure can be satisfied by using these words directly without having to define a never-used-again control structure. The adoption of two words accomplishes what the six Forth-83 system extension words were intended to do, but can't. ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/17/91)
Category 10, Topic 27
Message 34 Tue Jan 15, 1991
W.BADEN1 [Wil] at 20:17 PST
Discussion:
The lack of a way to accomplish what the non-portable, inadequate, and
unusable Forth-83 BRANCH-MARK-RESOLVE words attempted to do is felt by some to
be a serious omission.
In brief, the Forth-83 words are unacceptable because they assume a particular
object form, require the data stack for information during compilation, and
yet do not give any way to access the stack information. They are incapable of
defining ELSE and WHILE...REPEAT independently of implementation.
The paper "Flowgraph Basis" gives a set of seven operations that can describe
the topology of any flowgraph. Algorithms to describe any flowgraph with these
seven operations are given in the paper. Five of these operations have a
direct correspondence with Forth words: IF, UNTIL, AGAIN, THEN, BEGIN. These
specify forward and backward conditional branches, unconditional backward
branch, and the destination of forward and backward branches.
All that is necessary to give Forth the ability to make a portable definition
of any control structure is to adopt the two additional operations described
in "Flowgraph Basis".
One operation, ALTHOUGH, is the mirror of AGAIN, and specifies an
unconditional forward branch. Adoption of this alone still would not make ELSE
and WHILE...REPEAT definable.
The operations produce and consume values on a stack whose implementation is
hidden. We call that stack the control flow stack. The operation [ n ] SO
provides the basic operation to manipulate the control flow stack.
[ n ] SO
Take the nth element from the top of the control flow stack
and move it to the top of the control flow stack.
Each of the seven operations has a graphical correspondence as well as a
control-flow correspondence. These correspondences are shown in "Flowgraph
Basis". E.g., the argument n of SO is related to the number of lines crossed
by a line in a planar representation of a flowgraph.
A paleolithic 1970's style Forth implementation of the seven operations is
given below. The values of the constants whose names begin with ' is of course
implementation dependent.
: IF '?>Branch , HERE 0 , ; IMMEDIATE
: UNTIL '?<Branch , , ; IMMEDIATE
: AGAIN '<Branch , , ; IMMEDIATE
: THEN HERE SWAP ! ; IMMEDIATE
: BEGIN HERE ; IMMEDIATE
: ALTHOUGH '>Branch , HERE 0 , ; IMMEDIATE
: SO ROLL ; IMMEDIATE
ALTHOUGH is the essentil ingredient of ELSE. It could also be used in
customized control structures. First we make an implementation independent
definition of a useful auxiliary word (still in 1970's style).
: BUT 1 [COMPILE] SO ; IMMEDIATE
BUT
Interchange the top two elements of the control flow stack.
Now we can define in any implementation.
: ELSE [COMPILE] ALTHOUGH [COMPILE] BUT [COMPILE] THEN ;
IMMEDIATE
: WHILE [COMPILE] IF [COMPILE] BUT ; IMMEDIATE
: REPEAT [COMPILE] AGAIN [COMPILE] THEN ; IMMEDIATE
An example of ALTHOUGH is a customized optimization of BEGIN...WHILE...REPEAT.
: MEANWHILE [COMPILE] ALTHOUGH [COMPILE] BEGIN [COMPILE] BUT ;
IMMEDIATE
MEANWHILE mumble THEN grumble UNTIL
optimizes
BEGIN grumble 0= WHILE mumble REPEAT
Proposal:
Add ALTHOUGH, BUT, and SO to the implementor's toolkit.
ALTHOUGH
(The definition of ALTHOUGH should be cannibalized from the
current definition of IF by replacing references to
conditional branching with unconditional branching.)
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (01/24/91)
Category 10, Topic 27 Message 35 Mon Jan 21, 1991 W.BADEN1 [Wil] at 21:04 PST I had thought that the rationale for WHILE had made it clear that the X3J14 definition is not something new, but how WHILE has been implemented in polyForth and other industrial strength Forth's for many years. Outside of that arena there had been a clamor for multiple WHILE's, with varying exotic definitions, by persons who were not aware of the classical Forth definition, now X3J14 definition. The ability had been in hard-line, lean 'n' mean, Forth systems for a long, long time. X3J14 just acknowledged that fact, and recognized how WHILE would continue to be implemented in that section of the Forth community. This approach to control flow can be implemented in every system, while xBranch, etc., would *never* be implemented by the hard-liners. Indeed 72 percent of it has already been implemented in *every* system. This approach lets everyone do what was wanted to be done with xBranch, but could not be done. It is as simple as it can be, but not simpler. Procedamus in Pace. ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp