Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Puzzle? What Puzzle? Message-ID: <12511@sdcc6.ucsd.edu> Date: 2 Sep 90 07:56:59 GMT Organization: University of California, San Diego Lines: 145 Dennis Ruffer writes, > The point is that there are many ways to skin a cat. Just because > you have done something one way all your life does not mean that is > the only way to do it. I don't think that Dennis Ruffer's perception that Forth users are resisting a better way of doing things is an accurate assessment of the current state of affairs. Most of the Forth users I've met are highly intelligent and discriminating people. They are certainly capable of appreciating a better way of doing things -- even it if means changing their old habits. We've established that most users will need to do considerable rewriting to have existing code comply with the proposed ANSI Standard. And we've established that tools that they have used in the past will not be available -- so it is just a matter of learning about what newer and better tools the ANSI team has provided. >> 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. > Again, I say, YES IT DOES! If the previous example where you got at > least two acceptable solutions did not convince you, then PLEASE, hit > us with another one. I, for one, would be glad to take a wack at > solving another puzzle. Please distinguish between general mechanisms and an ad hoc method for handing a special case. What's missing here is someone who can fill in the dots at the end of the following statement: "You used to create control structures, in-line data handlers, etc. by storing addresses in the dictionary, using your access to the IP, etc. -- now, under the proposed ANSI Standard, you will be able to accomplish the same things in the following way: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . " THE CODE I SUBMITTED WAS NOT A PUZZLE -- it was an example of work-a- day code: the kind of thing that you do on the fly. In some areas of application for Forth it is precisely the ability that Forth provides to modify the language that makes Forth important. If( .. )If is an extremely simple example of a user-defined control construct. I am happy that an extremely competent professional programmer on the ANSI Team was able to come up with a method that *may* work for just this simple special case. When he then says "Whew, that was a great puzzle -- and now it's Miller Time", it does not inspire confidence in the existence of general mechanisms for handling the whole class of situations. > For example setting SP0 to increase the return stack depth just is > not possible when the return stack is implemented in hardware such as > on most Forth CPUs. Thus, some other mechanism must be provided. > On those machines, it is not possible to address into the return > stack so the best that the standard can do is allow you to find out > how big it is. To do more would prevent those systems from > complying with the standard. I think this is an example of the kind of thinking that is crippling the standardization effort. Recursion is not one of these funny little things that only strange people want to do. It is a very common way of expressing many algorithms. Most modern computer languages offer it. The existence of the word RECURSE does not mean that you can really do recursion. (If Mitch Bradley does not have as many customers clamoring for recursion as he does for catch and throw, it is because it has probably never occured to his customers that Forth doesn't support recursion.) Here is the situation: In most versions of Forth, the size of the return stack can be temporarily extended -- to permit the running of recursive algorithms when desired -- but the mechanism has not been standardized. On a special class of Forths (those on Forth machines) there are inherent reasons why the size of the return stack cannot be altered. What do we do? Do we recognize that Forth machines have been designed for a special type of computing -- but that it is desirable to provide this option (and you might as well throw in SP0 etc) when possible. OR Do we say that because a special class of machines is not suited for recursion, Forth in general will not be suited for recursion. The ANS-Forth approach to language standardization is to choose the second alternative. The effect of dragging everything down to the lowest common denominator is to spread limitations rather than accentuate strengths. If the Forth machines are, in fact, a special class of machines that have their own rules I see nothing that inherently prevents a Standard from specifying a different form of behavior for this special class. >> ARE USERS ALLOWED TO ASK QUESTIONS YET? > > Of course John! .... I was reacting to the fact that a reply to my questions about how (or whether) things could be done was titled "ANS BASHING". -------------------- I regard making language standards as a problem-solving situation. There are certain assumptions that have governed this attempt which need to be examined. We have a situation now in which even staunch supporters of the effort admit that the results are unsatisfactory -- but are shrugging their shoulders saying "that's the real world for you". It may be that the unsatisfactory results so far indicate that the problem can't be solved using the current approach and assumptions. Perhaps these assumptions should be reexamined (like the one that says that the ANSI Standard must sit on top of existing implementations -- rather than be a foundational core common to all implementations.) I also feel that there are certain things that must be dealt with (and should have been dealt with before the effort began) --- first and foremost is why people would want to use Forth at all. [We must ask whether we are in danger of eliminating from Forth precisely those qualities which would lead someone to pick it in preference to other languages.] Even comments like this are not "bashing" -- they try be constructive. Quite honestly, I'm not responding to attempts to wave the flag and convince us that, as patriots, we should accept a weak standard -- that those who ask questions about what has been done so far are "bashing". John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093