wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (08/30/90)
> 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. Here's how this came about: 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. I proposed that the system guarantee that at least 2 string buffers of at least 80 characters each. 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. 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. 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. 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. 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
rob@innovus.UUCP (Rob Sciuk) (09/06/90)
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