This document is produced by TC X3J14 as its clarification of questions raised about ANSI X3.215-1994, American National Standard for Information Systems - Programming Languages - Forth. The questions covered herein were raised by query Q0002, regarding the significance of defining search orders in which a given wordlist occurs more than once. There are four parts in this document: 1. The original question as received. 2. The TC's reply. 3. The Letter Ballot issued by TC Chair. 4. TC Chair's statement of ballot results. =============== 1. Q0002 as received. =========================== The following query has been assigned number Q0002 and has been tentatively assigned to Mitch Bradley for drafting a response. - Greg Bailey, by direction, Tue, 21 Mar 95 12:44:17 PST -------------------------------------------------------------- Subject: request for interpretation To: x3j14@minerva.com Cc: beebeebee@aol.com From: John Rible Date: Fri, 17 Mar 1995 01:46:52 -0800 Message-Id: <199503170944.BAA21566@mail3.netcom.com> Received: from cruzio.com by med3.minerva.com ; Fri, 17 Mar 1995 01:48 PST Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >From jrible Fri Mar 17 01:46:52 0800 1995 remote from cruzio.com Received: from cruzio.com by mail3.netcom.com (8.6.10/Netcom) id BAA21566; Fri, 17 Mar 1995 01:44:27 -0800 Received: from cruzio38.cruzio.com by cruzio.cruzio.com id aa29048; 17 Mar 95 1:40 PST X-Sender: jrible@cruzio.com X-Mailer: Content-Length: 2656 folks- A friend has implemented wordlists using a linked-list to maintain the search order. He put two links in each wordlist structure, one for a static list of wordlists, the other a dynamic link for the search order. This avoided having to allocate an arbitrary amount of space for the search order list/stack. After arguing with him that this is not compliant with the standard, I can't find anything explicit that backs me up. The problem with his method is that each wordlist can only appear ONCE in the search order. Well, that's not a problem in itself, but when a wordlist already in the search order is added to the top its previous location is lost! Again, that's not a real problem if the complete search order is always set explicitly, since the deeper occurrance will never produce a match. But it sure messes up partial search order changes, such as using ALSO or PREVIOUS to temporarily change the order. For example, the following sequence will hang his system: ONLY FORTH VOCABULARY HIDDEN ... ALSO HIDDEN ALSO FORTH \ so FORTH is searched first ... PREVIOUS \ FORTH is no longer in the search order!!! The requirement that I can't find, but believe that we intended, based on extensive common practice, would require the phrase set-order get-order to have no effect on the stack (as long as set-order got valid arguments, anyway). The problem sure seemed obvious to me, but he doesn't think it is, and even came up with the following definitions to deal with the issue: ' NIP VALUE 'ALSO : ALSO ( - ) ['] 1+ TO 'ALSO ; : ONLY ( - ) -1 SET-ORDER ['] NIP TO 'ALSO ; : PREVIOUS ( - ) GET-ORDER NIP 1- SET-ORDER ; : ( wid - ) \ wid is the address of the wordlist data structure >R GET-ORDER 'ALSO EXECUTE R> SWAP SET-ORDER ['] NIP TO 'ALSO ; : FORTH ( - ) FORTH-WORDLIST ; : VOCABULARY ( 'name' - ) CREATE ... DOES> ; While these deal with some of the situations of adding and removing search-order entries, I've seen a lot of places (in Sun's OpenBoot, for example) where existing code would go up in flames if temporarily adding and removing a vocabulary that happened to already be in the search order took it out completely, as in my example above. Of course, the pathological (but currently working) ONLY FORTH ALSO PREVIOUS also leaves his search order empty. Thanks for your responses (even the "you're a *&^#@*$%# idiot for wasting my time" ones add a data point!-) John Rible QuickSand "hardware, software, and so forth" jrible@cruzio.com 317 California Street, Santa Cruz, CA 95060-4215 408-458-0399 =============== 2. TC Reply to Q0002. =========================== From: Erather@aol.com Subject: Official Response to Q0002 To: X3J14 Technical Committee Cc: lbarra@itic.nw.dc.us Date: Fri, 31 Mar 95 12:52:24 PST Doc#: X3J14/Q0002R Reference Doc#: X3.215.1994 ANS Forth Date: March 31, 1995 Title: Response to Request for Interpretation Q0002, Clarification of Search Orders Q0002 DRAFT rev 1 Key > Indicates lines from the original inquiry. The entiry text of the inquiry is cited in this way. | Indicates excerpts from the standard Unmarked lines comprise the response to the inquiry. > A friend has implemented wordlists using a linked-list to maintain > the search order. He put two links in each wordlist structure, one for > a static list of wordlists, the other a dynamic link for the search > order. This avoided having to allocate an arbitrary amount of space > for the search order list/stack. > After arguing with him that this is not compliant with the standard, I > can't find anything explicit that backs me up. The problem with his > method is that each wordlist can only appear ONCE in the search > order. Well, that's not a problem in itself, but when a wordlist > already in the search order is added to the top its previous location > is lost! Again, that's not a real problem if the complete search order > is always set explicitly, since the deeper occurrance will never > produce a match. In the following excerpt from the definition of SET-ORDER, the phrase "word lists" means "sequence of word lists". | Set the search order to the word lists identified by widn ... wid1. | Subsequently, ... GET-ORDER must return exactly the same sequence of wids "widn .. wid1" that appeared in the arguments to the most recent execution of SET-ORDER , even if a particular word list identifier appears more than once in that sequence. A Standard System is permitted to optimize its searching process so that the existence of repetetions in the search order need not result in redundant searches, but if so (a) the behavior of GET-ORDER and SET-ORDER must be as described in the preceding paragraph, and (b) the results of a search must be indistinguishable in all cases from the results were there no such optimizations. > But it sure messes up partial search order changes, such as using ALSO > or PREVIOUS to temporarily change the order. For example, the > following sequence will hang his system: > ONLY FORTH > VOCABULARY HIDDEN > ... > ALSO HIDDEN ALSO FORTH \ so FORTH is searched first > ... > PREVIOUS \ FORTH is no longer in the search order!!! Historically, in most implementations of the ALSO .. ONLY search order mechanism, the sequence shown would result in the search order containing The standard intends to codify that existing practice. > The requirement that I can't find, but believe that we intended, based > on extensive common practice, would require the phrase "set-order get-order" > to have no effect on the stack (as long as set-order got valid arguments, > anyway). The problem sure seemed obvious to me, but he doesn't think it > is, and even came up with the following definitions to deal with the issue: > ' NIP VALUE 'ALSO > > : ALSO ( - ) ['] 1+ TO 'ALSO ; > : ONLY ( - ) -1 SET-ORDER ['] NIP TO 'ALSO ; > : PREVIOUS ( - ) GET-ORDER NIP 1- SET-ORDER ; > : ( wid - ) \ wid is the address of the wordlist data structure > >R GET-ORDER 'ALSO EXECUTE R> SWAP SET-ORDER ['] NIP TO 'ALSO ; > > : FORTH ( - ) FORTH-WORDLIST ; > : VOCABULARY ( 'name' - ) CREATE ... DOES> ; With these definitions, the sequence "ALSO GET-ORDER" would not yield the result specified by the standard. > While these deal with some of the situations of adding and removing > search-order entries, I've seen a lot of places (in Sun's OpenBoot, > for example) where existing code would go up in flames if temporarily > adding and removing a vocabulary that happened to already be in the > search order took it out completely, as in my example above. Of course, > the pathological (but currently working) ONLY FORTH ALSO PREVIOUS also > leaves his search order empty. The ANS Forth search order wordset is intended to provide a predictable mechanism for managing search orders in arbitrary ways, albeit subject to the system-dependent limitation on the maximum number of word lists. Some applications, for example, choose to use the search order as a "stack", adding and removing word lists without regard to whether or not those word lists already appear in the search order. =============== 3. Letter Ballot. =============================== From: Erather@aol.com Subject: Letter Ballot 013 To: X3J14 Technical Committee Cc: lbarra@itic.nw.dc.us Date: Fri, 31 Mar 95 12:54:18 PST X3 Subgroup Letter Ballot Authorized by X3 Procedures - Distributed by X3 Subgroup X3J14 Project: X3J14, ANS Forth Doc#: X3J14/LB013 Reference Doc#s: X3J14/Q0002R, X3.215.1994 ANS Forth Date: March 31, 1995 Title: Response to Request for Interpretation Q0002 Ballot Period: 30 Days Ballot Closes NOON DATE: April 30, 1995 Respond to: greg@minerva.com or: Elizabeth D. Rather, Chair FORTH, Inc. 111 N. Sepulveda Blvd. Suite 300 Manhattan Beach, CA 90266 (310) 372-8493 FAX (310) 318-7130 Statement: Document X3J14/Q0002R contains a proposed Response to Request for Interpretation Q0002. Question: Do you agree that this response represents the intended interpretation of X3.215.1994 ANS Forth? YES____ NO____ ABSTAIN____ [NO or ABSTAIN votes require an explanation] Signature: [not required for email ballots] Name: Organization: INSTRUCTIONS: Please return the entire letter ballot with your response _either_ by email to greg@minerva.com _or_ by regular mail or fax to me at the above address, before the closing date & time. All TC members must vote. Failure to vote in two consecutive ballots may cause you to lose your voting rights in X3J14. Thank you for your participation. Elizabeth D. Rather, Chair, X3J14 =============== 4. Results of Letter Ballot. ==================== From: Erather@aol.com Subject: Letter Ballot Results To: X3J14 Technical Committee Date: Fri, 05 May 95 18:50:18 PDT Letter ballots [12 and] 13 have closed. Both passed. Results follow. [...] Letter ballot 13: 13 yes, 1 no, 0 abstaining. [...] Jax [Jack Woehr] voted No on LB13. His comments follow: LB13, Woehr: I made a proposal which was drowned out in Mitch's discus- sion with himself on the maillist. It was letting Mitch make all the decisions in consultation with himself that got us in trouble at the spring meeting in Oregon in 1992 and delayed the standard by about a year. I expect my proposals to be heard, even if not adopted, in hopes we can avoid similar problems in the future. --------- FOR THE RECORD ----------------------------------- [Here is the e-mail message to which Woehr refers. The active part of the discussion occurred over a three day period, involved about a dozen e-mail messages, and had seven participants who posted.] > > > I think Mitch has gotten the issue here backward. <...> > the arguments that it passes to SET-ORDER be mutually distinct? > > I believe that the answer is emphatically "no". I agree with Mitch whole-heartedly. I would move to add that: "It is the sense of the X3J14 TC that no element of SEARCH ORDER Wordset introduces novelty into general Forth praxis, with the exception that a WORDLIST now has a tangible representation on the stack, whereas FORTH-83 VOCABULARY had no such tangible representation. In all other respects the de-facto behavior of Forth search order operations are utterly unchanged from Forth-83." Do I hear a second? =jax= [...] Thank you all for your participation. Of the 14 votes received, 9 came by email, and the rest by fax (plus mine!). Regards... Elizabeth ====================================================================