wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (06/15/90)
Robert Berkey writes: > ... Forth-83 specifies the accessability of the text input buffer. > QUOTE-TO.SCR ... is fully portable under the Forth-83 Standard. > ... QUOTE-TO.SCR defines "CREATE Dennis Ruffer writes: > I'm not versed well enough in BASIS to know if [QUOTE-TO.SCR] complies > [in BASIS] ... I seem to remember something about >IN. It should work in BASIS. Every effort was made to preserve the accessability of the input stream. In particular, I went to some amount of trouble to ensure that this works when loading from files too. A different BASIS solution to the same problem would be to construct a string containing, for example, "CREATE FOO" (assuming that FOO is the argument you want to pass to CREATE, and EVALUATE that string. This is probably a bit more straightforward than saving and restoring the input stream. > Berkey: ... It wasn't so easy. I think this is indicative of a design flaw in Forth itself. Addressing into the input stream is a convoluted process, since you have to consider several possible input sources (keyboard, block, file, EVALUATE string). In practice, these resolve to 2 different input stream sources: Current address End address Sources TIB >IN @ + TIB #TIB + keyboard, EVALUATE, text file BLK @ BLOCK >IN @ + BLK @ BLOCK 1024 + block The input source can be distinguished by: BLK SOURCE-FILE input source 0 0 keyboard 0 nonzero text file (SOURCE-FILE is fileid) nonzero 0 block from "global" block space nonzero nonzero block from block file (SOURCE-FILE is fileid) Aaaaaaargh! I just found a bug in BASIS. There is no way to discern that the input source is a string passed to EVALUATE . I'll submit this to the committee forthwith. Anyway, back to the train of thought: this whole business of having to figure out how to find the input stream is too complicated, but since it is deeply-ingrained "common practice", the committee as a whole didn't feel either entitled or motivated to invent something better. Assuming that we can resolve the "EVALUATE bug" just identified, then at least it will be possible to muck around in the input stream, however ugly it may be. > Ruffer: There was a need for the words SAVE-INPUT and RESTORE-INPUT . SAVE-INPUT and RESTORE-INPUT were the subject of proposal that did not pass, thus they are not currently part of BASIS . They were an attempt to invent a solution to part of the ugliness described above. They are not actually an entitlement to address into the input stream; instead, they provide a convenient way to "mark your place" in the input stream, regardless of its source, and then restore that position later. SAVE/RESTORE-INPUT do provide one additional capability that you can't do in BASIS right now: With SAVE/RESTORE-INPUT , you can save a position in an input file, interpret ahead in that file, and then return to the saved position *even if you have read ahead by several lines*. As it stands right now, by saving and restoring the contents of >IN , you can only move around within the current line. The reason why this proposal failed was because on some kinds of files (e.g. Unix pipes) it is not possible to back up. There was a heated disagreement over whether or not this is a fatal flaw. Enough members thought it fatal that the proposal did not pass. > Paraphrasing Berkey: It was harder to satisfy the documentation > requirements for QUOTE-TO.SCR than to write the code. > I think it is possible to write a Forth-83 program that would automatically > calculate the documentation values, but two > key words are missing that make this prohibitively difficult. There is a new word in BASIS 12 that should make this somewhat easier. ENVIRONMENT? ( b-addr un -- false ) CORE ENVIRONMENT? ( b-addr un -- n true ) CORE "baddr un" is a string specifying the name of an environmental attribute whose value you wish to know. It returns false if that attribute is unknown, or a value under true otherwise. This can be used for things like stack depth, maximum sizes for buffers like TIB and the pictured numeric output buffer, presence or absence of extension wordsets, eye of newt, tongue of dog. The reason not to just use FIND for this is because the potential list of interesting attributes is quite large, and implementation may wish to store them on disk, rather than wasting a lot of dictionary space for a huge number of attributes which may only be used once. Very constrained systems, such as some ROM-based applications, are allowed to implement ENVIRONMENT? as 2DROP 0 , indicating "don't know" for everything. In response to a "don't know" from ENVIRONMENT? , a portable application can use a "safe" or "least common donominator" value for that attribute. Mitch Bradley