ir230@sdcc6.ucsd.edu (john wavrik) (09/02/90)
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
dwp@willett.pgh.pa.us (Doug Philips) (09/06/90)
In <12511@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes: [Since its been a while, I'm quoting more of this than I usually would. -dwp] > 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. If there are some machines on which you cannot extend the return stack, then doing so makes a program not portable. How not portable depends on the number of restrictive machines. I don't have any figures, but apparently the TC feels that there are enough of them to make this an issue. I see nothing wrong with making this an environmental dependancy in your program. I'm not sure how to handle the extended wordset (were I to propose one). It seems kind of silly to propose an extended wordset for one word ( CHANGESTACKSIZE ), but equally silly to have a catchall wordset instead. -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]
peter@ficc.ferranti.com (Peter da Silva) (09/07/90)
In article <1677.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: > propose one). It seems kind of silly to propose an extended wordset for > one word ( CHANGESTACKSIZE ), but equally silly to have a catchall wordset > instead. Why? What's wrong with: "The following words may not be implementable on all hardware. If implemented, they shall have the following semantics." This wordset can contain CHANGESTACKSIZE, CHANGEHEAPSIZE, ALLOCATEHEAP, and so on. I'm sure you can think of lots more. Even if the resulting code won't run on Forth machines, it will run on more conventional machines and be portable between them. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
dwpst@unix.cis.pitt.edu (Douglas W Philips) (09/08/90)
In article <R8Q5TW2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Why? What's wrong with: > > "The following words may not be implementable on all hardware. > If implemented, they shall have the following semantics." > >This wordset can contain CHANGESTACKSIZE, CHANGEHEAPSIZE, ALLOCATEHEAP, >and so on. I'm sure you can think of lots more. Even if the resulting >code won't run on Forth machines, it will run on more conventional machines >and be portable between them. Are you saying its an all or nothing proposition? What if you could change heap sizes but not stack sizes? Would that qualify as compliance with the specification for the "catch-all" wordset? If you allow piecemeal compliance how does the program tell whice pieces are in place? Yes, I can think of ways to do it, but not terribly clean or esthetic ones. -Doug --- Preferred: dwp@willett.pgh.pa.us. Other: uunet!willett!dwp
peter@ficc.ferranti.com (Peter da Silva) (09/08/90)
In article <36062@unix.cis.pitt.edu> dwpst@unix.cis.pitt.edu (Douglas W Philips) writes: > >This wordset can contain CHANGESTACKSIZE, CHANGEHEAPSIZE, ALLOCATEHEAP, > >and so on. I'm sure you can think of lots more. Even if the resulting > >code won't run on Forth machines, it will run on more conventional machines > >and be portable between them. > Are you saying its an all or nothing proposition? No. This wordset would not be guaranteed to be implemented to any degree on any implementation. All this would do would be to specify what the semantics of these words would be when present. > If you allow piecemeal compliance how does the program tell which pieces > are in place? You'll say "132 load" and it'll come back with "CHANGESTACKSIZE?". > Yes, I can think of ways to do it, but not terribly clean or > esthetic ones. If you don't do it the results will be even less esthetic. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com