ir230@sdcc6.ucsd.edu (john wavrik) (08/26/90)
Lee Brotzman writes, > If you are using a PC, you should be able to at least get a feel > for ANS Forth by using Martin Tracy's Zen Forth. The last I heard, > Martin was keeping Zen in step with each BASIS to provide a testbed > like you suggest. (I have not been keeping up with Zen for the last > year or so, so I can't say whether it is still "pre-ANSI- > compliant"). > Of course, you can't directly test portability by implementing on > only one system, but, if your Forth-83 code runs in Zen with little > or no change, it's a fair bet that porting between ANS systems will > work. Thanks for the tip, Lee. I had hoped that Martin Tracy (or someone) would keep doing this -- but apparently it stopped a few meetings ago. I was given a copy of Tracy's BASIS10 version -- and this was instrumental in starting my concern about the path that the ANSI Standards were taking. I first tried some of my research code and, when I had problems, picked examples from my courses written very carefully (as textbook examples) to adhere to Forth-83 standards. It soon became clear that even simple examples ran into trouble. I think that it is a safe bet that anyone who wants to have existing code run on proposed ANSI systems will have to do quite a bit of rewriting. THIS IS PROBABLY TRUE OF ANY NEW STANDARD. My only question at this point is whether the rewriting is feasible or justified: (1) Will the new standard allow us to do the things we currently do?; (2) Will it be enough of an improvement over current standards to justify the effort? I started asking questions about this and have, so far, received mixed responses. I should make clear (as I have done several times in the past) that I firmly believe that a good Standard is essential for the survival of Forth. What I am now trying to discover (by asking questions) is whether the proposed ANSI Standard in its current form has arrived at that state. Is it really directed at making sure that significant programs can be written portably? Is it really directed at defining the Forth language as well as our current understanding allows it to be defined? Have words names and actions been chosen to facilitate programming -- or are we being stuck with clumsy compromises? etc. ---- Mitch Bradley writes, > Subject: ANS bashing >> 1. Can the return stack be extended to make recursion viable? >> 2. Is there a Standard mechanism for deferred execution? >> 3. Can the user control compilation enough to define a simple control-flow structure? >> I would like to thank for Mitch Bradley for replying. As he has shown, >> the answer is a discouraging NO on all points. > I object to this analysis. The answer to (1) is indeed no, but I > disagree entirely with 2 and 3. flame on: I object to the title (ANS bashing). Those of us not in a position to be members of the ANSI Team should be able to make inquiries about the progress of the effort without being made to feel that we are casting aspersions. There are many of us in the "user community" who have a vested interest in seeing a truly excellent ANSI Standard for Forth. If the process of examination turns up gaps or defects this should be regarded as a contribution to the improvement of the proposed Standard. Those who follow this newsgroup have been treated to accounts of the politics and pettiness that have plagued the effort -- and have had a strong supporter try to excuse it all by saying "welcome to the real world". I think most of us will be willing to excuse the unfortunate aspects of the process as long as the end result is good. Inquiries of the "can the proposed Standard do this?" variety should be regarded as natural and normal questions at this stage. Attempts by those outside the Team to pin down what can and cannot be done should be welcomed -- they are an essential part of the process. It does not bode well that attempts to pin things down are greeted as "bashing" and "negativism". If you can't handle questions from friends, God knows what you will do when your enemies ask! Lots of us are expected to explain and show that what we have to offer is good -- people don't just accept our personal assurances. You may not like this "I'm from Missouri" attitude -- but welcome to the real world. [To non-US readers: "I'm from Missouri, you have to show me" is a popular expression. It isn't clear why, of all the 50 states, people from Missouri should be more insistent on concrete evidence than others. I have no idea where this expression comes from -- I just know it is older than my grandfather (who was not from Missouri but who used it every time he felt that I hadn't given enough evidence to support a claim I was making).] flame off; --------- 1) Many algorithms are expressed recursively. The return stack is so shallow on many Forth systems that serious algorithms will not run. In traditional Forth systems, the parameter stack is below the return stack and the initial value of the stack pointer is contained in a variable, so simply doing -2000 SP0 +! increases the return stack size by 2000 bytes. (It may generate an error message -- but the system will then work with increased return stack.) Some manuever of this sort is necessary for any serious recursive programming. Since it came up in some recent work, asking if this is handled by the proposed Standard was natural. The answer is no. 2) The program also used deferred execution. Many mechanisms and names for vectored execution have appeared in Forth systems. Vectored execution was one of the topics listed in the TC document posted by Jack Brown. It was natural to ask if some agreement was reached on a mechanism for vectored execution. The answer is no. 3) > Dr. Wavrik's objection to my (string-based) ANS implementation of > his simple control structure was based upon a misunderstanding > of the implementation. The claim that my implementation stores > strings in the dictionary for later evaluation is false. Here I agree that I misunderstood, and since have looked up the BASIS glossary entry for EVALUATE (a word which did not exist in previous standards). EVALUATE ( addr u -- ) Save the current input stream specification. Set the input stream to point to the text string specified by addr u. The input stream is set by altering BLK, TIB, #TIB, and >IN. When the input stream is exhausted, restore the prior input stream specification. This is Mitch's code: : IF( 0 >R \ count the number of IFs used BEGIN BL WORD DUP COUNT " )IF" $= <> WHILE COUNT EVALUATE POSTPONE IF BL WORD COUNT EVALUATE POSTPONE ELSE R> 1+ >R REPEAT DROP R> 0 DO POSTPONE THEN LOOP ; IMMEDIATE This is to be used in the form IF( c1 e1 ... ck ek )IF IF( is IMMEDIATE, so it is now executing. The first BL WORD will extract c1 from the input. Since the comparison fails we go to WHILE and have the address and count for c1 on the stack. EVALUATE should now evaluate this string -- i.e. execute the condition c1 -- rather than compile it into the dictionary. Similarly the next BL WORD COUNT EVALUATE would execute e1. So now, I don't understand why this works at all. On the other hand, Dennis Ruffer writes, > : )IF ; > : IF( 0 >R \ count the number of IFs used > BEGIN >IN @ ' ['] )IF = NOT > WHILE >IN ! POSTPONE POSTPONE POSTPONE IF > POSTPONE POSTPONE POSTPONE ELSE > R> 1+ >R > REPEAT DROP > R> 0 DO POSTPONE THEN LOOP ; IMMEDIATE > Wouldn't that accomplish your same objectives? Other than being > more careful about how you write applications, I think most of what > you can do now is possible with ANS Forth. Some thought may have to > go into ways to make things portable, but the point is that it is > possible. In spite of the peculiar appearance, this may work. One reason for hedging concerns what POSTPONE does. I am assuming from its usage that it is an alias for [COMPILE] which, in F83, is just defined as : [COMPILE] ' , ; IMMEDIATE Since my original definition used ' , the above will work if POSTPONE is replace by [COMPILE]. The BASIS copy I have, however, just says that POSTPONE <name> "Postpones the compilation action of <name>". Is it clear that the above will work on every ANS system? The other reason for hedging is the use of >IN to reread the input stream. I recall some discussion a while back in which Ray Duncan objected (if memory serves) to using >IN in this way. Is this use of >IN completely in compliance? My third point was, > 3. Can the user control compilation enough to > define a simple control-flow structure? If the two questions raised about Dennis Ruffer's definition are satisfied then this will be an acceptable answer for this particular control-flow structure -- but the task was handled in such an ad hoc manner that it isn't clear what tools are available in general. Circumstantial evidence suggests that there is no general mechanism for compilation control (if there were one, someone would have used it to answer my question) -- so there is still a question about the degree to which users can affect compilation. The answer here is a tentative perhaps. -------------- After reading through these glossary entries in the BASIS copy I have, I raise the following question for the ANSI Team: ARE GLOSSARY DESCRIPTIONS SUFFICIENTLY CLEAR AND UNAMB- IGUOUS? Would two people who implement a word based on the glossary description produce words that execute in the same way under all conditions? -------------- > Other than being > more careful about how you write applications, I think most of what > you can do now is possible with ANS Forth. Some thought may have to > go into ways to make things portable, but the point is that it is > possible. This is something that many of us hope is true. We are willing and waiting to be convinced. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
dwp@willett.pgh.pa.us (Doug Philips) (08/29/90)
In <12413@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: > > I think that it is a safe bet that anyone who wants to have existing > code run on proposed ANSI systems will have to do quite a bit of > rewriting. THIS IS PROBABLY TRUE OF ANY NEW STANDARD. My only > question at this point is whether the rewriting is feasible or > justified: (1) Will the new standard allow us to do the things we > currently do?; (2) Will it be enough of an improvement over current > standards to justify the effort? I started asking questions about > this and have, so far, received mixed responses. I'm curious to know what the things were that you couldn't do with ZEN1_10. > I should make clear (as I have done several times in the past) that I > firmly believe that a good Standard is essential for the survival of > Forth. What I am now trying to discover (by asking questions) is > whether the proposed ANSI Standard in its current form has arrived at > that state. Is it really directed at making sure that significant > programs can be written portably? Is it really directed at defining > the Forth language as well as our current understanding allows it to > be defined? Have words names and actions been chosen to facilitate > programming -- or are we being stuck with clumsy compromises? etc. I would think you wouldn't even need to ask that question. As has been stated several times in the past, the ANS standard is NOT supposed to break new ground. It is supposed to condense and solidify what has already been proven. I think you need to be asking instead: Is the ANS charter compatable with what I want out of a standards process? If you are interested in making a brave new Forth, the ANS process is not for you. > world". I think most of us will be willing to excuse the unfortunate > aspects of the process as long as the end result is good. Inquiries of > the "can the proposed Standard do this?" variety should be regarded as > natural and normal questions at this stage. Attempts by those outside > the Team to pin down what can and cannot be done should be welcomed -- > they are an essential part of the process. Since I don't recall seeing a reply to this along these lines: X3J14 has broke with ANS tradition by making a machine readable copy of the BASIS documents available. Perhaps it would behoove them to set up an email address for the submission of proposals? I congratulate Mitch Bradley on his heroic efforts in explaining the current BASIS and its politics and history. I think that perhaps the TC should consider what will happen if he burns out and stops doing that. In particular, the can has been opened and the worms won't go back in. How much that may matter on the TC can decide for themselves. > If the two questions raised about Dennis Ruffer's definition are > satisfied then this will be an acceptable answer for this particular > control-flow structure -- but the task was handled in such an ad hoc > manner that it isn't clear what tools are available in general. Please tell us how we can tell if the tools are available in general. What kind of solution would you find acceptable? You state at the end of your message "we are willing and waiting to be convinced." I'm curious as to what the ANS charter says about how much effort the TC has to/should put into "education and explication of" the Basis/dpANS" documents. Does ANS expect that the TC is to carry the light to the masses, or do they expect the TC to provide a haven and known place for finding the light? (Or something different?) -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]