ANS Forth 
Author Message
 ANS Forth

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?  





        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?  




  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  ( -- )

        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  ( -- )

        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  ( -- )

: remaining-stream  ( c-addr u -- )

: CHAR  ( "ccc" -- char )

  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 )

        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?  


  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

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
--

      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...'                  /______\



Sat, 31 Jul 1993 15:29:28 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. ANS Forth in ANS Forth?

2. ans forth link broken at forth.org

3. comp.lang.forth FAQ: ANS Forth (7 of 7)

4. Implementing ANS Forth Wordlist(s) in Forth-83

5. Forth books (was "ANS Forth")

6. ANS Forth & Compatable Forth

7. comp.lang.forth FAQ: ANS Forth (7 of 7)

8. What ANS Forth misses /was: Fix Forth, please

9. ANN: PF11, an ANS Forth for the 68HC11

10. Opinions about ANS FORTH

11. Blocks or Files?, was Re: Opinions about ANS FORTH

12. Opinions about ANS FORTH

 

 
Powered by phpBB® Forum Software