Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!apple!agate!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Re: Multi-line custom compilers
Message-ID: <9009042114.AA01997@ucbvax.Berkeley.EDU>
Date: 31 Aug 90 19:15:13 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 71

> > a version of WORD (call it GETWORD for the sake of discussion) that
> > will read past line boundaries.

>	: GETWORD   ( delim -- string )
>		BEGIN
>			DUP WORD	( parse next word )
>		DUP C@ 0= WHILE		( while at end of line )
>			DROP		( toss the null word parsed )
>			QUERY		( read the next line )
>		REPEAT
>		SWAP DROP		( toss the delimiter )
>	;

With the Basis12 version of QUERY, which works not only for keyboard input
but also for other input stream sources, this is pretty close.

There is a problem with this solution relating to the problem of "hard end
of input stream".  QUERY has no way to report that it did not succeed in
acquiring another chunk of input.


   Input Source			End Conditions


     Keyboard		No end condition; user is assumed to supply an
			endless series of input lines.

      Block		Questionable.  Should GETWORD read past the end of
			a block?  Should that depend on whether the block was
			loaded with LOAD or with THRU ?  Should there be
			a "splice" word equivalent to FIG's "-->" ?

  Block inside file	Presumably, GETWORD could read the next block, up to
			the last block in the file, but what about shadow
			screens?

     Text file		End-of-file prevents QUERY from acquiring another
			input line.

 String (EVALUATE)	End-of-string is end of input stream.  QUERY cannot
			acquire more from this input source.


Personally, I feel that the traditional Forth "dual-mode" input stream
mechanism (BLK, BLOCK, TIB, #TIB, >IN) is a horrible disgusting mess.
I prefer (and supply in my products) a stream abstraction where all
input sources are uniformly accessed via a GETWORD procedure which
ignores line boundaries.  Refilling of input buffers from whatever source
is handled transparently in a lower layer.

I surveyed a lot of users and vendors, and nearly everybody prefers this
model, but the weight of "common practice" is squarely on the side of the
traditional mechanism, so that is what is in ANS Basis.  The stream model
would break everybody's code.

I have the dubious distinction of being the author of a part of Basis
(the file input mechanism) that I don't really like.  But at least it works,
assuming that we can fix the "end condition" problem.  I have submitted
a proposal to fix it.  The gist of the proposal is to add a new word REFILL
which is like the generalized (works on all input sources) QUERY .  REFILL
returns a flag telling whether or not it succeeded in refilling the input
buffer.

Such are the trials and tribulations of codifying existing practice, rather
than inventing a new language.

This traditional input stream mess is one of the reasons that I prefer a
functional definition of the language, rather than a virtual machine model
where you get to torque on all the visible nuts and bolts.

Mitch Bradley, wmb@Eng.Sun.COM