Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!world!dcp From: dcp@world.std.com (David C. Petty) Newsgroups: comp.lang.forth Subject: ANS Forth Keywords: ANS Forth Message-ID: <1991Feb12.072928.11890@world.std.com> Date: 12 Feb 91 07:29:28 GMT Reply-To: dcp@world (David C. Petty) Organization: The World @ Software Tool & Die Lines: 224 I am posting this proposal (which was passed at the most recent meeting of X3J14, because everything was deleted from it except for (16)) so that anyone and everyone can respond to the questions raised in it. One member of the X3J14 Technical Committee (TC) has agreed to respond point-by-point to these questions. Those responses will also be posted. ---------------------------------------------------------------------- ANSI ASC X3 / X3J14 Forth Technical Proposal TP91-1082 ---------------------------------------------------------------------- Title: Clarify BASIS on the subject of the Forth input stream. ---------------------------------------------------------------------- Related Proposals: TP90-833, TP91-1070 ---------------------------------------------------------------------- Keyword(s): input stream, block file, implementation-defined default block space, text file ---------------------------------------------------------------------- Forth word(s): #TIB ( >IN BLK EVALUATE INCLUDE INCLUDE-FILE LOAD LOAD-FILE QUERY REFILL SOURCE-FILE SPAN TIB \ ---------------------------------------------------------------------- Abstract: Clarify BASIS on the subject of the Forth input stream. BASIS is still unclear on the specific input stream ``entitlements'' to the point that we have heard differing interprpreter, 5.3.2 addressable memory, 5.3.4.1 Input Stream, 8.1.006 #TIB, 8.1.0080 (, 8.1.0560 >IN, 8.1.0790 BLK, 8.1.1360 EVALUATE, 10.1.1713 INCLUDE, 10.1.1717 INCLUDE-FILE, 11.1.1790 LOAD, 10.2.1792 LOAD-FILE, 8.2.2040 QUERY, 8.2.2125 REFILL, 10.1.2218 SOURCE-FILE, 8.2.2240 SPAN, 8.1.2290 TIB, and 8.2.2535 \ (plus other new sections). ---------------------------------------------------------------------- Discussion: In the following discussion the term ``legitimate'' means ``portable, consistent with the intention of X3J14, and within the boundaries of good taste.'' 1) There is a question about the general nature of #TIB. Which of the following are legitimate and correct in ANS Forth? : stream-empty? ( -- flag ) BLK @ : stream-empty? ( -- flag ) IF 1024 #TIB @ >IN @ = ; ELSE #TIB @ THEN >IN @ = ; It appears, given the letter of BASIS, that the first ought to be correct in all cases, but is #TIB also meant to hold the input stream length? 2) There is a question about the general nature of TIB. Which of the following are legitimate and correct in ANS Forth? : stream ( -- c-addr u ) BLK @ ?DUP : stream ( -- c-addr u ) IF BLOCK 1024 TIB #TIB @ ; ELSE TIB #TIB @ THEN ; It appears, given the letter of BASIS, that the first ought to be correct in all cases, but is TIB also meant to specify the beginning of the input stream (i.e., does it call BLOCK)? Also, does the value returned by TIB ever change, e.g. during EVALUATE, INCLUDE, or INCLUDE-FILE, or do the values of #TIB and >IN change relative to it? 3) There is a question about what >IN holds. Are the following legitimate and correct in ANS Forth? : initialize-stream ( -- ) : skip-stream ( -- ) 0 >IN ! ; #TIB @ >IN ! ; That is, can anything but a previously saved value of >IN be legitimately stored in >IN by a user? 4) There is a question about what #TIB holds. Is the following legitimate and correct in ANS Forth? : truncate-stream ( -- ) >IN @ #TIB ! ; That is, can #TIB ever be legitimately modified directly by a user? 5) There is a question about what BLK holds. Is the following legitimate and correct in ANS Forth? : ans-query ( -- ) TIB +n ACCEPT #TIB ! 0 BLK ! 0 >IN ! ; That is, (in addition to the above questions) can BLK ever be legitimately modified directly by a user? If not, what does it mean to say that ``QUERY is semantically equivalent to [that] sequence...'' (BASIS section 8.2.2040 QUERY)? 6) There is a question about accessing the contents of the input stream. Is any of the following legitimate and correct in ANS Forth? : uppercase ( c-addr u -- ) ... ; ( converts string to uppercase ) : uppercase-next-word ( -- ) >IN DUP @ 2>R BL PARSE uppercase 2R> SWAP ! ; : remaining-stream ( c-addr u -- ) stream >IN @ CHARS TUCK - >R + R> ; : CHAR ( "ccc" -- char ) remaining-stream 0= ABORT" Stream empty." C@ BL WORD DROP ; Given that uppercase-next-word will not generally work if the input stream is coming from a block (and what about EVALUATE?), can the contents of the input stream ever be legitimately modified directly by a user (uppercase-next-word, above)? Can the contents of the input stream ever be legitimately manipulated in any way directly by a user (CHAR, above), or is it only ever legitimate to parse from the input stream? If it is not legitimate for a user to directly calculate addresses within the input stream without parsing, can a user ever do anything legitimate with the value of TIB? 7) There is a question about parsing. Is the following legitimate and correct in ANS Forth? : CHAR ( "ccc" -- char ) BL WORD COUNT 0= ABORT" Stream empty." C@ ; Section 4.0575 Parsing says, ``If the current input stream is empty or contains no characters other than the delimiter, the string is empty.'' Is an empty string-implementation defined, or is the count zero? 8) Is it true that, ``words using TIB and modifying the contents of BLK, >IN, or #TIB are responsible for maintaining the integrity of the input stream specification and its contents'' (changes added)? Ought section 5.3.4.1 Input Stream paragraph four (from where the above was taken) to be so modified? Ought there to be more prose in that section about nesting and un-nesting the input stream and if so, what prose? 9) There is a question about CURRENT-FILE and SOURCE-FILE. We have heard from the TC that CURRENT-FILE is obsolete, that SOURCE-FILE is obsolete, and that they are the same! We most definitely believe (and assume) that CURRENT-FILE is not obsolete, that SOURCE-FILE (as a named value) is obsolete, and that they are definitely not the same thing (see TP91-1070). C'mon, which is it guys? 10) The wording of BASIS section 8.2.2125 REFILL is unclear and / or incorrect. When BLK contains a non-zero value and SOURCE-FILE returns a non-zero value, section 8.2.2125 specifies that REFILL takes the action ``0 >IN ! 1 BLK +! 0.'' First, does that means that the system next interprets the block specified by the new value in BLK in the ``block space'' specified by CURRENT-FILE (regardless of the value in SOURCE-FILE)? Second, if CURRENT-FILE contains a non-zero value, shouldn't REFILL return other than zero, or should the system simply abort if a user attempts a REFILL beyond the end of a block file? 11) Is SOURCE-FILE useful in any way to a user? It is used in BASIS to help explain the way INCLUDE, INCLUDE-FILE, and REFILL work, but it can only be modified by INCLUDE, INCLUDE-FILE and little can be done with it by a user except defining: : INTERPRETING-TEXT-FILE? ( -- flag ) SOURCE-FILE 0<> ;. We cannot see the need for that system value to be given a name and will help rewrite BASIS in terms of ``source file'' (the file whose text gets interpreted by INCLUDE and INCLUDE-FILE), removing any reference to SOURCE-FILE. 12) Section 10.1.1029 CURRENT-FILE refers to ``current block file'' and ``implementation-defined default block space,'' neither of which are defined. A ``block file'' probably means ``whenever the contents of CURRENT-FILE are non-zero'' and differs from the implementation-defined default block space only in that the concept of end-of-file is meaningful for a block file. Ought ``block file,'' ``current block file,'' and ``implementation-defined default block space'' be defined in the Definition of Terms and if so, how? 13) There are some unclear aspects of the specification of comments (BASIS sections 8.1.0080( and 8.2.2535 \). Section 8.1.0080 refers to ``text file,'' but that term is nowhere defined. It probably means ``whenever the contents of BLK are zero and the source fileid is non-zero.'' Ought ``text file'' be defined in the Definition of Terms? Section 8.2.235 refers to ``line,'' but section 4.0510 (the definition of the term ``line'') is inadequate to describe the lines in blocks (and block files) versus those in text files (it describes how ``lines'' are displayed). What is meant by a line within a block (e.g. is it 64 characters) and to what does section 4.0510 refer? Ought the wording of section 4.0510 be improved and if so, how? 14) There are some questions about (. - Section 8.1.0080 ( spells out that a null comment, (), is allowed so that ( cannot be implemented in terms of WORD (though sections 8.1.0190 ." and 8.2.0200 .( do not specify that behavior). Does that behavior need a rationale note? - Sections 8.1.0080 ( and 8.2.0200 .( specify that those words are immediate. Is that a mistake and if not, why not? - Does X3J14 really want to require ( to comment to the end of a text file? 15) Is the following legitimate and correct in ANS Forth and does it immediately exit the current input stream? : EXIT-INPUT ( -- ) BLK @ IF 1024 >IN ! ELSE POSTPONE \ BEGIN REFILL 0= UNTIL THEN ; 16) We asked the question of the Input Stream Working Group, ``why does section 11.1.1790 LOAD have the stack diagram ( i*w -- j*w )?'' and got explanations as to what the ``i*x'' mean. To us, that stack comment says, ``LOAD takes a variable number of arguments and leaves a variable (and potentially different) number of arguments.'' Didn't LOAD used to take a block number? ---------------------------------------------------------------------- Date: February 1, 1991 Submitted by: David C. Petty and Bent Schmidt-Nielsen Address: Post Office Box Two Cambridge, MA 02140-0001 Internet: dcp@world.std.com Telephone: +1(617)492-1232 FAX: +1(617)491-2345 ANSI ASC X3 / X3J14 Forth Standards Committee 111 North Sepulveda Boulevard, Suite 300 Manhattan Beach, CA 90266-6861 ----------------------------------------------------------------------- X3J14/87-021 12/04/1987 -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\