Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!rutgers!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for Interpreter
Message-ID: <1639.UUL1.3#5129@willett.pgh.pa.us>
Date: 30 Aug 90 03:01:32 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 72

Category 10,  Topic 24
Message 12        Wed Aug 29, 1990
R.BERKEY [Robert]            at 04:16 PDT
 
  Subject: BASIS12 input-stream definitions

Mitch,

Thanks for looking at the code I wrote for <NAME> using BASIS, and opining
that the basic axioms are satisfied.  That led me to get out BASIS12 to check
out my impression that "it's not clear how to set >IN in BASIS."

I do see some problems here.  BASIS12 simultaneously explores three
descriptions of the input stream associated with the "text input buffer".  One
of these descriptions follows along Forth-83 lines, for the buffer area that
Forth-79 called the "terminal input buffer".  The second description is a
concept with a stable TIB , with >IN and #TIB each relative to TIB .  And the
third description is a concept in which TIB is mutable.

   (1) The address-offset calculations in the coding for <NAME> are
   using address units.  So CHARS must be added to the definition of
   <NAME> .

   (While I'm on this point, the text for the definition of "input
   stream" has the same problem.)  (Note that >IN was changed from
   "address units" to "character" units in Vancouver.)

   (2) How does a program know what values go into >IN ?

   >IN itself doesn't say, but an inference can be drawn from other
   text.  The glossary entry for #TIB gives specific values that can be
   stored into #TIB .  And the definition of "input stream" makes it
   clear that the values in >IN parallel those in #TIB .

   However, the values that can be stored in #TIB are
   {0..capacity of the input buffer}.  This, of course, invalidates
   the <NAME> implementation.  An editor's box below #TIB notes
   that #TIB needs work, "Problem similar to one just fixed for >IN
   ...At the very least, the range specification must be deleted."

   But making the text of #TIB similar to that in >IN would remove
   the inference that determines valid values for >IN .

   (3) The original source of my concern about setting >IN stemmed from
   the rationale note that says, "Re-reading the input stream by
   setting the contents of >IN to some arbitrary value, such as zero,
   is incorrect."  This seemed to imply that it's a system perogative
   as to what goes into >IN .

   Maybe that's just my misinterpretation, but the text of >IN doesn't
   help things.  (a) It does not identify the values that a program can
   store there.  (b) It uses the concept "start of the current input
   stream".  And the definition of "input stream" doesn't clearly
   identify "start of the current input stream".

   (4) What is TIB ?

   It returns the address of something called the "text input buffer".
   But "text input buffer" isn't further described.

   The intent is presumably that systems can change the value returned
   by TIB .  If so, when does it change?

   Without this information, programs cannot use TIB .

   (5) The word SOURCE-FILE doesn't exist in BASIS12.

 Robert

-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us