Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!sdcc6!ir230
From: ir230@sdcc6.ucsd.edu (john wavrik)
Newsgroups: comp.lang.forth
Subject: Re: Some Code
Message-ID: <5289@sdcc6.ucsd.edu>
Date: 21 Nov 89 16:45:13 GMT
References: <5187@sdcc6.ucsd.edu> <6396@tekgvs.LABS.TEK.COM>
Organization: University of California, San Diego
Lines: 90



Tom Almy writes,
# In article <5187@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes:
# ...
# >This solution is for F-83:
# >VARIABLE OSTATE      ' : @ CONSTANT DOCOL                 
# ... (lots of code)
# >These words are interesting because they bring up a point: they do not
# >involve assembly language, but they involve a knowledge of how traditional
# >Forth is implemented.

> Which brings up a sore point about any of these. This code, and most of
> the "interesting" stuff that gets published, is very non-portable. What
> is a "traditionally implemented Forth" anyway? And how many implementations
> are traditional?

I suspect the code is just "non-portable" not "very non-portable". It is so 
short and simple, it might be interesting to see how this must be changed for 
direct threaded, jsr threaded, etc. (with some explanation of what changes 
were made and why they are needed). ANYONE INTERESTED, PLEASE POST. 

> It's sad but true -- to get the best results with Forth you have to
> throw portability out the window.

That's only because we've made some bad decisions about what constitutes
the language -- but fortunately we have a chance to rectify these mistakes.

I think that the use of implementation details in Forth is the subject of 
dishonest controversy. Those who feel that knowledge of the implementation 
should not be part of the Standard are usually the first to pull things off 
the return stack, relink the dictionary, and do all sorts of other "illegal" 
things as soon as you ask them how they would add local variables (or some 
other such thing) to a system. The problem of introducing unnamed code 
fragments was posed at the San Diego Chapter of FIG by Bob La Quey and all the 
solutions presented were of the character of the one I presented in my article.
It would be interesting to see someone come up with a way of doing this that 
is entirely "standard".

I guess we should mention that most of us write very little code which 
directly uses the implementation -- but that (1) it does account for some
fairly powerful results and (2) it is portable in that it does not depend on 
the host processor [The code I submitted will run on all but one of the Forth 
implementations I have on everything from an Apple II to a VAX (if I allow 
for the changed meaning of tic).

> That's not to say that this posting is "bad". Far from it. The problem, if 
> indeed there is one, is that this sort of program plays around with the 
> internals of Forth, and the internals are decidedly non-standard. 
> Unfortunately, if these details were to become part of the standard then it 
> would inhibit better implementations.

Please let's distinguish things like the use of assembly language or features 
of the host processor from "the internals of Forth". A Standard COULD be 
proposed in which implementation details are specified (the FIG model was of 
this type) and then these details WOULD be standard (and portable). A 
decision to declare such programming "non-standard" is made by a committee of 
human beings, not forced on us by our computers. It's quite a reasonable idea 
to take a look at that decision to see if the reduction in power of the 
language is a price worth paying for baptizing a variety of deviant 
implementations. 

If you give people a "compiler" that they can modify, guess what they will do.
There is no problem with someone producing a private version of Forth that 
they feel is "better" for them -- and many people do just that. It is quite 
likely that some of the most important applications of Forth in the past 10 
years have been written using "non-standard" versions of Forth. I don't think 
that Standards inhibit people from experimenting with the language. The issue 
is more what can be done powerfully and portably. You do not add power to a 
language by removing some of its features and declaring them to be "decidedly 
non-standard". 

Forth has been in existence for about 20 years -- readily available for about 
10. During that period of time, we may have learned some things about how to 
improve its implementation. (I think a good case can be made that as much time 
and effort have been spent in experimenting with the language's implementation 
as in actually doing something with the language.) At this point we should 
take stock of what we have learned and embody that in a new Standard. If it is 
decided that direct threaded code actually produces major performance 
advantages over indirect threaded code, then the new Standard should specify 
direct threaded code. If we decide that floored division is preferable, then 
the new Standard should specify that. Instead we have a situation in which a 
vocal group says we should drive on the left side of the road, an equally 
vocal group which says we should drive on the right -- and a Standards team 
which declares the issue to be "implementation dependent". 

                                                  John J Wavrik 
             jjwavrik@ucsd.edu                    Dept of Math  C-012 
                                                  Univ of Calif - San Diego 
                                                  La Jolla, CA  92093