ir230@sdcc6.ucsd.edu (john wavrik) (01/27/91)
Mitch Bradley writes, > The claim that ANS Forth is like a house with no bathroom is > overstated. The choice of "bathroom" to describe the problem I have in mind was intentional. Bathrooms are something we assume are somewhere in a house even if we don't see them. We would be shocked to discover they are not there. I've often been taken on a "house tour" during a party. We get to see the dining room and its antique furniture; the deck with its spectacular ocean view; and the kitchen with its whizzy new multi- tasking microwave oven. We don't see any bathrooms, but we just assume that they're behind some of the closed doors we passed. Our impression of the house is much more favorable than it would be if we knew that the house had no bathrooms -- but this possibility never occurs to us. We just assume their existence. My choice of metaphor was to suggest something important whose lack you fail to notice -- not because it is concealed -- but because you just assume it is there. I'm reluctant to specify exactly what I have in mind -- because there may be several things of this nature which haven't occured to me (there are assumptions I may not have thought to question but which may be uncovered by others). On the other hand, I don't want to be secretive -- so let me tell you what I was doing. By way of background: I'm basically a professional user of Forth. I use it because, in my field, conventional languages pose a problem which Charles Moore managed to brilliantly solve. I teach it because I've found it the quickest way to get mathematics students to understand some basic issues about computers, computer languages, and how they work. Since I'm a user of Forth, I've changed implementations only when necessary (usually because I changed platforms). So far this has involved just getting a copy of an implementation for Forth on the new machine. Since I want my code to be useful for a long time, and be of use to others, I write conservative Forth. (At one point I was using 4 implementations -- including both 16-bit and 32-bit machines -- and wrote code that would run on all.) I use assembly language heavily for speed -- but have high level equivalents for portability. I sometimes use machine dependent features (e.g. access to non-code segments on 80x86), but these are localized in a few selected words. When I looked at BASIS14, as I started to do when I recently received it, I was looking for the following things: 1. What changes will be needed in my current code? 2. What changes will be needed in my instructional materials? 3. Have any features I need been eliminated? 4. Will the proposed ANSI-Standard solve the portability problem? 5. Will I finally be able to teach Forth without having to deal with "Forth trivia" [like how the 1979 version of ' (tic) differs from the 1983 version and why]? 6. Has portability been restored to the point where it will be possible to produce college level texts? Portability explained: (i) Will someone who writes and tests an application on (Standard) implementation A be sure that it will run correctly on (Standard) implementation B [without having a copy of B]. (We are assuming significant applications). (ii) Is the language specification clear and complete enough so that portability of code as above will extended to any version of Forth, present or future, implemented in compilance with the Standards document. (iii) Can writers produce books explaining Forth (or using Forth in courses in data structures, algorithms, instrumentation and control, embedded systems, etc) which apply to all Standard versions -- without getting in to the differences between ABC-Forth and XYZ-Forth. As mentioned above, I do not collect versions of Forth, but portability is a major concern -- so I often scan my code to make sure that I have not used a non-Standard word without supplying a definition. [Guy Kelly even has a "non-Standard word" warning feature built in to his Forth]. What I did: I decided to find out where things stood by comparing the words in the proposed Standard with those in Forth-83 and those in my system. I then planned to use an (automated) scan of some of my source code to identify places where I used words not in the proposed Standard -- and then to see if I could find substitutes (to make sure that the functionality was preserved). I was gratified to see that a lot of my favorite words seemed to be in the proposed Standard. It soon became obvious that I couldn't do this kind of comparison by eye -- I'd have to type in the words from BASIS to automate the comparison with Forth-83, F83, and my existing code. So I started typing... WHAT'S WRONG WITH THIS PICTURE? If you can't immediately see what's wrong with this picture, you are probably making the same assumptions that I did. Had I relied just on my 11 year experience with Forth, I would not have even realized that I was making assumptions (just like believing a house has bathrooms somewhere even when I don't see them). All I can tell you is that the idea that by comparing words you can answer the questions above depends on some hidden assumptions. I was only led to question the assumptions because of my participation in the USENET discussions during the past year. Many of the people involved in the USENET dialog seem to be making the same assumptions I did. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
wmb@MITCH.ENG.SUN.COM (01/27/91)
Please, people, can we get specific? If there are specific problems, let's get them out in the open where we can address them. All of Basis 14 has been subject to close scrutiny by somewhere between 20 and 40 rather competent Forth programmers, and has been implemented by at least 2 different people. That certainly doesn't mean it is flawless, but it does lead me to believe that it's probably not horribly broken. (Specific, verifyable evidence to the contrary will be most carefully considered; I personally volunteer to "carry the banner" for any such issue that is brought to my attention). At this point, there's just nothing I or anybody else can do with vague, unspecified worries, nor with philosophical "soapboxes". The time for philosophy has passed. Basis is going to dpANS soon, and whether you like it or not, and whether or not it passes and becomes an official standard, it *will* be very influential. So, working on that assumption, it behooves us to find and fix as many specific problems as we can find. I would further suggest that, from a practical standpoint, that we agree to concentrate on "incremental modifications", rather than profound changes. All the profound decisions have already been argued about for 4.5 years, and the die has been cast (at some point, you just have to make a decision and go with it, and that point has passed). So, my challenge to the ForthNet community is this: find something objectively wrong with Basis, support your claim with facts, submit a proposal, and I will do my best to get the issue resolved. (Oh, one more suggestion: proposals of the form "it would be nice to have word X" (where word X can be easily implemented in terms of existing words) don't have much chance these days, in part due to a widespread desire to minimize the size of the standard. However, very careful consideration is given to proposals to the effect that: "there is no way to do `x', and `x' is important because ...") Mitch Bradley, wmb@Eng.Sun.COM