Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!maccs!innovus!rob
From: rob@innovus.UUCP (Rob Sciuk)
Newsgroups: comp.lang.forth
Subject: Re: Quote (hope it is not too late!)
Message-ID: <237@innovus.UUCP>
Date: 6 Sep 90 14:33:54 GMT
References: <9008291904.AA11122@ucbvax.Berkeley.EDU>
Reply-To: rob@innovus.UUCP (Rob Sciuk)
Organization: Innovus Inc, Hamilton, Ont. Canada
Lines: 92

In article <9008291904.AA11122@ucbvax.Berkeley.EDU> Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV> writes:
>> In the printing of Basis 12 that I have (August, 21), it says that the
>> above word is in the CORE and NON-PORTABLE wordset (sic)! Well, now we
>> have a standard way of making non-portable programs in any ANS Forth
>> compatible system.
>
>The usage of " (quote) when compiled into a definition is in the CORE
>wordset.  Its usage outside of a definition (i.e. in interpret state)
>is non-portable.
>
>	[ Stuff Deleted ]
>
>Prior to Basis 12, " was only defined in compile state.  I proposed
>that it should also be defined in interpret state.  This has implications
>for the persistance of the string storage, i.e. how long does the
>string last before it is overwritten.  Put another way, how many
>string buffers are there, or how many times can you execute " in
>interpret state before one of the strings is lost.

  Good questions ... 
  Semantics aside ... I needed " (both interactive and compiled) in my own 
  implementation of Forth-83 and find no problems on porting this same version 
  to 6 different architectures and operating systems currently:

	I implemented " to work interactively in a dedicated scratch buffer 
	of 1024 bytes; it returns a counted string on the parameter stack when
	invoked interactively (as it should), and when used inside a defining
	word, the string is stored within the word definition, but otherwise
	behaves in the same way (leaving a counted string upon execution).  

	Multiple invocations would use an offset beyond the initial string 
	into the same buffer.  Garbage collection is done in a routine called 
	from QUIT (after a line of input is processed) only if the highwater 
	mark (currently 512 bytes) is exceeded within the scratch buffer.

	this gives me:

	- the ability to use " to pass multiple strings to defining words
	- reasonable string length
	- consistent execution and compilation semantics
	- reasonable # of strings before one is trashed ... which WILL occur
	  in unusual circumstances but as we are concerned with interactive
	  use it is not such a great problem ...
	
>
>I proposed that the system guarantee that at least 2 string buffers
>of at least 80 characters each.

	too restrictive!
>
>Another solution is to store the strings in the dictionary and allot
>space for them, but a lot of people (myself included) do not like
>the idea of having dead strings filling up the dictionary.

	prevents passing strings to defining words unless you define
	an area `not likely to get trashed'  VERY DANGEROUS!
>
>There was extensive discussion about this, and no consensus could be
>reached.  However, it was generally agreed that systems ought to
>allow the use of " in interpret state, at least for the convenience
>of the user in constructing arguments to file words.

	more than just file words !!! 
>
>The compromise solution was to retain the compilation semantics
>(portable, uncontroversial, unambiguous) in the CORE wordset, and
>to put the interpretation semantics (which are somewhat of a can of
>worms, but useful nevertheless) in the NON-PORTABLE wordset.

	this CAN BE DONE PORTABLY iff the definition of a string
	buffer and the garbage collection semantics are part of
	the standard ... however ... this reeks of implementation
	and probably does not belong in a standards document.
>
>It is generally the case (yes, we all can think of an exception, so
>spare us, okay?) that "canned" programs mostly need to compile strings
>rather than interpret them, so this compromise mostly works.

	you are your own standards control commission ... if i
	don't like it ... i can use the standard to implement
	whatever my application requires ... this is Forth after
	all!  in the meanwhile, my own implementation works real 
	well everywhere i've needed it!
>
>The compromise was acceptable to me, since it sends a signal to
>implementors that " in interpret state is a good thing.  I would
>have preferred more definite semantics, but it became clear that
>I had better take what I could get.
>
>Mitch

rss