Message-ID: <394B6CCA.6321307A@forth.org> Date: Sat, 17 Jun 2000 15:19:22 +0300 From: Michael Gassanenko To: ansforth-real@minerva.com Subject: TO spec for DEFER -- rephrase 2 References: <3948FD4A.591A2F7E@forth.org> I thank "Stephen Pelc" and "Elizabeth D. Rather" for comments. Now, rephrase 2. ------- >I try to rephrase M.Milendorf's proposal so that >it would be absolutely acceptable. last time I wrote: >I tried to address all questions relating DEFER/TO/IS. >If you agree, please, let me know via personal e-mail, >because otherwise I'll get no fedback if everybody agrees. >If you disagree, your comments are welcome. I did not want to prevent discussing this topic in ansforth-real@minerva.com . I wanted to ask the people not willing to make noise sending "ok"+quotation to ansforth-real@minerva.com to let me hear something. So, if you have something to say, --> ansforth-real@minerva.com . If you can say only 'ok', --> mlg@forth.org . If you write to me personally and do not want me to cite your mail in the mailing list or proposal comments or anywhere else, please, indicate that explicitly. Otherwise I will assume you have nothing against citations. (Finally, it's a technical discussion.) Regards, Michael L. Gassanenko ======================================================== History of changes (mlg): -- rephrase 2 -- Since it is Michael Milendorf's proposal, not mine, and it is about TO, not IS, since and IS still raises some questions, I have removed any mention of IS. Let one proposal solve one problem. changed: "name is of type not *supported* by TO" --> --> "name is of type not *recognized* by TO" removed: "Optional word sets may extend the compilation semantics of TO to support other types of words as well." -- true by default. (anybody disagrees?) -- rephrase 1 -- x|xt is xt since xt is a subtype of x. But we indeed need be clear about that TO requires an xt on the stack. I use the phrase "set name to x" instead of "store x to name": 'store' cannot mean 'associate' (this word is used in the definition of DEFER ), while 'set' may mean both 'store' and 'associate'. See also "Notes on the rephrase" that follow the rephrased proposal. Examples are removes since for other words ANS Forth gives no examples. ---- proposal ------------------------------- Title: Extend definition of 6.2.2295 TO word to work with DEFERred words Justification:The ANSI X3.215-1994 definition of TO word makes an assumption that TO can change the content of VALUE words only. The established practice of IEEE 1275-1994 systems utilize TO word as an assignment function for both VALUE and DEFER types of words. Problem: If DEFER word is accepted as part of the Forth standard a word is needed for assignment of DEFER words. The accepted practice is to use TO function for such purposes. ---- proposed rephrase ---------------------- Proposal: Change the current definition of 6.2.2295 TO, 13.6.1.2295 TO, modify 4.1.2 "Ambiguous conditions", Table 9.2 "THROW code assignments", to say the following: ---- 6.2.2295 TO CORE EXT Interpretation: ( x "name" -- ) Skip leading spaces and parse _name_ delimited by a space. If _name_ is a deferred word or a value, set _name_ to _x_. If _name_ is a deferred word, an ambiguous condition exists if _x_ is not a valid execution token. An ambiguous condition exists if _name_ is of type not recognized by TO. Compilation: ( "name" -- ) Skip leading spaces and parse _name_ delimited by a space. If _name_ is a deferred word or a value, append the run-time semantics given below to the current definition. An ambiguous condition exists if _name_ is of type not recognized by TO. Run-time: ( x -- ) Set _name_ to _x_. If _name_ is a deferred word, an ambiguous condition exists if _x_ is not a valid execution token. Note: An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO. See: 6.2.2405 VALUE, ?.?.???? DEFER, 13.6.1.2295 TO, ?.?.???? IS. ---- 13.6.1.2295 TO LOCAL Extend the compilation semantics of 6.2.2295 TO to include: Compilation: ( "name" -- ) If _name_ was defined by (LOCAL), append the run-time semantics given below to the current definition. Note: Due to the locals' privileged position in the search order, naming conflicts are resolved in favour of locals. Run-time: ( x -- ) Set _name_ to _x_. Note: An ambiguous condition exists if either POSTPONE or [COMPILE] is applied to TO. See: 3.4.1 Parsing, 6.2.2295 TO, 6.2.2405 VALUE, ?.?.???? DEFER, 13.6.1.0086 (LOCAL). ---- 4.1.2 Ambiguous conditions Remove: - name not defined by 6.2.2405 VALUE used by 6.2.2295 TO; Add: - name of type not recognized by 6.2.2295 TO used with TO; - storing an invalid execution token into a deferred word (6.2.2295 TO) ---- Table 9.2 - THROW code assignments -60 execution of a deferred word associated with an invalid execution token ---- end of the proposed rephrase ---------------------- Experience: Many years of use in OpenBoot and OpenFirmware systems. Comments: See PROPOSALS for DEFER, BEHAVIOR. ------------- end of proposal -------------------------- ========================================================= Notes on the rephrase: The proposed structure of the entry for TO (main+optional) facilitates the developer's task of documenting the unstandard use of TO/IS, e.g. a compatibility wordset may define TO/IS to write to the first cell of the data field for CREATEd words. The new formulation says explicitly what happens if there are two words called _name_, a local and a value. In the previous formulation, that could be inferred from "the locals' privileged position in the search order" mentioned in some other section. Two exception codes are reserved for storing an invalid xt into a deferred word: -59 may be thrown by TO on assignment -60 may be thrown by a deferred word when it is invoked --------------- ================================================================ ------ the original version -- FYI ----------------------------- -----Original Message----- From: Michael Milendorf (Godin) - Sun BOS Firmware [SMTP:milendor@chicklet.East.Sun.COM] Sent: Thu 28 Oct 99 13:17 To: j14-chairs@minerva.com Subject: PROPOSAL FOR 99/2 MEETING: Extend definition of 6.2.2295 TO word to work with DEFER words Title: Extend definition of 6.2.2295 TO word to work with DEFER words Justification:The ANSI X3.215-1994 definition of TO word makes an assumption that TO can change the content of VALUE words only. The established practice of IEEE 1275-1994 systems utilize TO word as an assignment function for both VALUE and DEFER types of words. Problem: If DEFER word is accepted as part of the Forth standard a word is needed for assignment of DEFER words. The accepted practice is to use TO function for such purposes. Proposal: Change the current definition of 6.2.2295 to say the following: 6.2.2295 TO Interpretation: ( x|xt "name" -- ) Skip leading spaces and parse name delimited by a space. Store x|xt in name. An ambiguous condition exists if name was not defined by VALUE or DEFER. Compilation: ( "name" -- ) Skip leading spaces and parse name delimited by a space. Append the run-time semantics given below to the current definition. An ambiguous condition exists if name was not defined by VALUE or DEFER. Run-time: ( x|xt -- ) Store x|xt in name. Examples: ok 0 value z ok z . 0 ok 1 to z ok z . 1 ok defer foo ok foo <--deferred word not initialized ok ' 1 to foo ok foo . 1 ok ' 2 to foo ok foo . 2 ok Experience: Many years of use in OpenBoot and OpenFirmware systems. Comments: See PROPOSALS for DEFER, BEHAVIOR.