Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: What are the existing standards? Message-ID: <1841.UUL1.3#5129@willett.pgh.pa.us> Date: 10 Oct 90 01:19:17 GMT Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 116 Category 10, Topic 1 Message 14 Mon Oct 08, 1990 D.RUFFER [Dennis] at 23:39 EDT Re: B.RODRIGUEZ2 [Brad] > there are four ways (or more) to standardize a word: > > 1. use the existing meaning of a word > 2. when more than one meaning is in common usage, enforce one of > the existing meanings of a word > 3. change the meaning of a word > 4. change the meaning and name of a word #1 is used if there are no conflicts in the various implementations. #2 is rarely (if ever) used since it would imply a favoritism to one implementation over another. #3 is not possible when what you want is the functionality (or both functionalities) of the original word. #4 has been done where the original functionality could no longer be accomplished in all implementations or better techniques have been discovered (i.e. POSTPONE). We each have our own priorities, and I have to admit that IMHO #4 is superior to both #3 and #2. In fact, you forgot #5: 5. change the name of both conflicting functions. This is what happened with NOT. We now have 0= and INVERT to handle whichever version your system happened to implement. > Gee, I guess we can just paste a sheet reading > s/NOT/INVERT/ > s/COMPILE/POSTPONE/ > etc. > inside the front cover of all the Forth books in print, and the > conversion process for reading is automatic. Right? (Pardon my > sarcasm.) When you have books in print that describe specific implementations and those implementations conflict, how can you fix them? In all the discussions about the scope of the TC mission, I have never heard the concern for following what some book says Forth does. I have only heard those comments here, and even here, I have never heard any resolution to the fact that the books have contradictiory meanings for some words. If the TC is supposed to standardize a book, which one should it promote. I can hear the comment now, that "Starting Forth" is the overwhelming choice, but even it covers at least 3 different implementations. The TC understands that it is changing things that we hold dear, but it has no other choice if it is going to get concensus from the diversity that has come to represent Forth. Understand that the TC is composed of the people in the Forth industry that have the highest stake in its survival. These are the people who have made the commitment to resolving the diversity that has hurt their businesses, and these are the people who will be hurt the most if their efforts fail. >> ENVIRONMENT? is the only way to enforce the documentation of >> system specific settings. > I beg to differ. What is section 5 "..Requirements,...Compliance > and Labeling" for? Just how many Forth 83 standard systems have you seen that meet its labeling requirements? Even if all the systems you have seen included this documentation, can you program read that piece of paper so that it can adjust itself to work within the resources that it has available? With ENVIRONMENT? it can. Although it still doesn't prevent someone from merely doing the default, it does establish minimums for that default behaviour that your program can be implemented to live with. > What constitutes "major"? 200 users is the TC's definition of a vendor. > How long is "quite a while"? How many years does it take for something to be termed useable? > Which two systems, and how many people use them? Mitch Bradleys I know has something very similar, and I seem to remember that Don Colburn said it used a very similar technique. There were also other TC members who said that they have used similar techniques in there systems. > Do two systems constitute a significant cross-section of the > Forth community? Every member of the TC agreed that an error recovery method was needed and that the existing ABORT method was not adequate. Under that guidance, do you have a better suggestion? >> How many systems have you seen, and what percentage of the >> implementations do you think that represents? > More than two. Last time I checked I have around twenty Forth > implementations kicking around here, for about eight or nine > different CPUs. Plus maybe a dozen more which I've acquired but > not used yet...Is that enough? Am I qualified to comment, now? Pretty impressive! I suggest that you study them all and see if you can come up with better compromises than what the people who are responsible for implementing those systems can do. Then come to the TC meetings and impress them with your insight. I apologize for the sarcasm, but I am really tired of hearing comments about how far the TC members are missing the mark. They are doing as good as they can, and all of them are working very hard at establishing a compromise from what we all have done to Forth. You all have equal oportunity to submit your thoughts, and the TC must answer every one. You can either choose to help the process by submitting positive comments and suggestions and accepting their best judgements, or you can hinder the effort by degrading their efforts or dwelling on their past judgments. It is your choice. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp