ir230@sdcc6.ucsd.edu (john wavrik) (08/28/90)
ARE USERS ALLOWED TO ASK QUESTIONS YET? >> It was natural to ask if some agreement was reached on a mechanism for >> vectored execution. The answer is no. >The answer is that there is a simple, portable, reasonably efficient way >of implementing vectored execution in terms of ANS Forth words. >Many people claim that is sufficient rationale for not adding additional >words to the standard. Those people who are interested in a small >standard use this argument frequently. >If you couldn't reasonably define vectored execution in terms of the >standard, then that would be a strong argument for adding the capability. >But you can. Vectored execution is essentially the only mechanism we have in Forth for changing the action of pre-defined works. If an application uses EMIT and we would like the output re-directed we must change the action of the previously defined EMIT. The common way of doing this is to vector EMIT. EMIT is often trapped to allow users to redirect output KEY is commonly vectored to allow users to intercept input (perhaps to create keyboard macros, to make "hot keys", etc.). ABORT is oftened vectored to allow users to put in error handlers. Using vectored execution in critical system words increases the flexibility of the system. Most of the Forth systems do this, but they use different mechanisms and different words. My question was whether agreement was reached on the mechanisms and words used for vectoring execution (so that this flexible control over system functions would be portable in the proposed Standard)? The fact that we are being told that the new Standard supplies VARIABLE and EXECUTE does answer the question indirectly: NO the vendors have not agreed on a mechanism for vectoring the basic system words (i.e. redirection of output, error trapping, etc. will not be portable). ------------ >Dennis Ruffer's POSTPONE solution works too. So the answer to >question 3 is definitely "can do". Sometimes one tries to get general information by asking a specific question. The general question in this case has to do with what control the proposed Standard offers the user over compilation. The specific question concerned a simple user-defined control structure. Dennis Ruffer's code will work (provided that POSTPOSE is equivalent to ' , in all systems; and that one can move around in the input stream by storing things in the variable >IN). The code is ad hoc, however. My example in F83 showed how this is done using ' and , (and illustrated how compilation can be affected by a mechanism which allows the storing of execution addresses in the dictionary). [All of the standard control structures in traditional Forth are implemented by just this mechanism.] What I was after is whether the proposed Standard has general portable mechanisms for controlling compilation -- which can be used to define control structures, for example. The answer, again, seems to be NO (at least, no one mentioned them in the process of answering the specific question). ------------- It would seem quite appropriate, before the ANSI Team wraps up its work, to submit their work in progress for testing. People, like myself, who use Forth professionally, will want to know "Can I (or how will I be able to) do in the proposed Standard what I currently do in my work now?" In my case, the sense that the ANSI team feels its work is almost complete led me to be conscious of what techniques I was using as I recently solved a problem posed by Wil Baden [The answer proved interesting enough that I'm thinking of writing it up in one form or another.]. The three questions I asked were not the result of an effort to stump the ANSI team -- they were inspired by typical end- user code. 1. How is recursion provided for (not just having RECURSE, but making sure there is enough return stack)? In this case I started using a recursive approach to Wil's problem (and had to extended the return stack to test it) -- I eventually settled for a camoflaged recursion (like one must do in FORTRAN). 2. Was agreement reached about vectored execution? I used a utility (for F83) that I wrote to redirect output to a file. It uses a hot patch into (print) [but could have used the vectoring of EMIT]. I was reminded of other applications where I intercepted KEY and ABORT. "Vectored Execution" was on the TC sheet posted by Jack Brown -- so I thought I'd ask. 3. Mechanisms for compilation control? It's not too unusual to write programs that affect compilation. The little control structure I produced was an effort to impress Wil Baden with how nice the coding of the algorithm could be made to look. I remember Wil being concerned about the building of new control structures from the Standard ones -- so I thought I'd ask what progress has been made. (To other users: check your work for places you've used , [COMPILE] COMPILE AND IMMEDIATE it may be that you, too, have taken for granted certain capabilites of Forth that should be asked about) I feel somewhat embarrased at feeling obliged to explain in detail why I asked my questions. I just thought it a natural and normal thing to do at this stage of the game. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093