ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/06/90)
Category 10, Topic 30 Message 88 Sun Aug 05, 1990 R.BERKEY [Robert] at 06:42 PDT ---------------------------------------------------------------------- ANSI X3J14 Forth Technical Proposal Page 1 of 1 ---------------------------------------------------------------------- Title: One's- and Two's-Complement ALUs Related Proposals: Keyword(s): Proposal (X) Forth Word(s): Comment ( ) ---------------------------------------------------------------------- Abstract: Policy statement for ALUs covered by BASIS. ------------------ Discussion: Removing a bit pattern for zero as was passed in Melbourne, on behalf of a generalized concept of ALUs, is useless to today's programmers, and radically impacts upward compatibility. Without the corresponding analysis and proposals for separating the number concept of "zero" from the flag concept of "false", the BASIS document is rendered inconsistent. For example, IF is currently a word without a clear meaning. Given Forth's lack of penetration into the "sign-magnitude market", specifications for sign-magnitude ALUs are untestable. Without the experience of actual needs, or evidence of such need, the specifications may or may not serve a useful purpose. But nothing in BASIS prevents Forth from being brought up on a sign-magnitude machine. Further, such concepts adversely impact useful programming and upward compatibility. _The_ _fundamental working concept that the conventional Forth number space is_ _circular, is demonstrated in BASIS in the definition of WITHIN and the_ _specification concerning overflow, as well as in previous standards._ The inclusion of one's-complement-ALUs considerations is also outside the scope of ordinary Forth programming. However, the inclusion of one's-complement ALUs with two's-complement ALUs, which are both circular number spaces, is less radical than the inclusion of sign-magnitude, etc., ALUs; there is existing practice in the field; and one of the committee's members is able to represent the one's complement needs. This proposal, among other things, mitigates the potential for oversights in BASIS in specification involving one's complement ALUs, specification which is needed by standard programs. By defaulting to two's complement in the absence of a label that ideas from other ALUs are involved, such labeling serves the purpose of communication of programming ideas: this is consistent with current literature. ------------------- Proposal: It is the policy of the committee to primarily consider only one's and two's complement architectures. The various labeling for "standard programs" will provide labeling for one's complement as a special case. --------------------------------------------------------------------- Submitted by: Robert Berkey Date: 90-08-05 Address: 47000 Warm Springs Blvd. #253 Ph: (415) 659-1334 Fremont, CA 94539 Msgs: GEnie R.BERKEY ANSI X3J14 Forth Standards Committee 111 N. Sepulveda Blvd., Suite 300, Manhattan Beach, CA 90266 --------------------------------------------------------------------- ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 10, Topic 30 Message 89 Fri Aug 31, 1990 D.RUFFER [Dennis] at 13:14 EDT From Elizabeth Rather, Chair, ANS X3J14 Technical Committee: This is addressed to those who have been commenting extensively on our work on UseNet and related boards. We very much appreciate your interest. I have circulated copies of many of your comments in the TC. I'd like to take the opportunity to try to clarify a few things. I understand that many of you share our goal to have a "perfect" standard. Unfortunately, you don't all agree as to the definition of "perfect", and neither do all members of the TC. There are at least five widely shared definitions: 1. A rich standard that includes all common words plus many extensions so that anything I might want to do is encompassed. I need to be able to count on all my favorite words being supported by all Forth systems in order to be able to write complex, interesting programs portably. Program size isn't an issue, since all systems have many megabytes of memory nowadays. 2. A lean, mean standard that specifies a minimum wordset whose availability I can rely on, but isn't encumbered with so many general-purpose capabilities that systems are too big to run in a 16- bit address space with room for useful programs. I'm happy to assume the responsibility for adding those extensions I need. 3. FORTH-83, with minor fixups like 32-bit system support. 4. FORTH-79, with minor fixups like 32-bit system support. 5. No standard. Who are you to tell me what to do? Only the last group can be easily satisfied, by acknowledging their right to ignore whatever standard we pass. Most of our time is spent working out compromises between the other four viewpoints. These compromises are developed over hours of work, and like all compromises they can be expected to make everyone somewhat unhappy. But it's important for you to realize just how hard we're trying to find solutions that will be as satisfactory as possible to as many people as possible. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
peter@ficc.ferranti.com (Peter da Silva) (09/05/90)
> There are at least five widely shared definitions: > 1. A rich standard ... > 2. A lean, mean standard ... > 3. FORTH-83, with minor fixups like 32-bit system support. > 4. FORTH-79, with minor fixups like 32-bit system support. > 5. No standard. Who are you to tell me what to do? You missed one... 6. Fig-FORTH. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/06/91)
Date: 02-03-91 (09:45) Number: 1028 of 1028 (Echo)
To: GARY SMITH Refer#: 1024
From: RAY DUNCAN Read: NO
Subj: WHAT SHOULD THE STANDARD Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
>SET-ORDER can be done portably in ANS FORTH
Only if everyone implements *ALL* the extension word sets. In our own
case, I can definitely promise you that LMI will *NOT* implement the
extension words that it considers brain-damaged, which definitely
includes ALSO and ONLY.
NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
<<<>>>
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/09/91)
To: RAY DUNCAN Refer#: 1028 From: JACK WOEHR Read: NO Subj: WHAT SHOULD THE STANDARD Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) -> >SET-ORDER can be done portably in ANS FORTH -> -> Only if everyone implements *ALL* the extension word sets. In our -> own case, I can definitely promise you that LMI will *NOT* implement -> the extension words that it considers brain-damaged, which definitely -> includes ALSO and ONLY. Uh .. I think them hummers (ONLY/ALSO) is gone these days. Also, I doubt if you would have to implement DOUBLE EXT or FILE EXT or FLOAT to get SET-ORDER up and running! Ray, you used to be Assistant Grand BooHoo of this effort, you should take another look at BASIS and think long and hard about lending your prestigious name to pushing this thing thru, esp. now as it looks like we are going for dpANS toot sweet. =jax= "they only broke my ROM systems a *teensy* bit :-)" ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/18/91)
Category 10, Topic 30 Message 97 Sat Feb 16, 1991 B.RODRIGUEZ2 [Brad] at 16:23 EST From Mitch Bradley: > The problem with criteria, either "necessary" or "sufficient", > is that there is no mechanism for either consistently applying > or enforcing them. I couldn't have said it better myself! However, this is not a problem with criteria per se -- it's a problem with the TC. Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You cannot Reply to the author using email. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, whatever). Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
esj@harvee.UUCP (Eric S Johansson) (02/20/91)
In article <2363.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: > > Category 10, Topic 30 > Message 97 Sat Feb 16, 1991 > B.RODRIGUEZ2 [Brad] at 16:23 EST > > From Mitch Bradley: > > > The problem with criteria, either "necessary" or "sufficient", > > is that there is no mechanism for either consistently applying > > or enforcing them. > > I couldn't have said it better myself! However, this is not a problem with > criteria per se -- it's a problem with the TC. > How can you claim this is a problem with the TC? "necessary" and "sufficient" are ambigious terms. For example, would you go into an auto mechanics shop, hand him (or her) your car and say "do what ever is necessary and send me the bill." I think not (otherwise I want to be your auto mechanic :-) When ever any organization is working with ambigious criteria, you get inconsistent results. This is true for contracts, standards, agreements, or any situation where group sez "we will do this" and does not define "this". --- eric -- ... ^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp * * a juggling fool AT&T (617) 577-4068 (w) o HAM ka1eec \_/ CSNET johansson%hydra@polaroid.com or hydra!johansson@polaroid.com source of the public's fear of the unknown since 1956
jerry@TALOS.UUCP (Jerry Gitomer) (02/20/91)
esj@harvee.UUCP (Eric S Johansson) writes: :In article <2363.UUL1.3#5129@willett.pgh.pa.us: ForthNet@willett.pgh.pa.us :(ForthNet articles from GEnie) writes: :: :: Category 10, Topic 30 :: Message 97 Sat Feb 16, 1991 :: B.RODRIGUEZ2 [Brad] at 16:23 EST :: :: From Mitch Bradley: :: :: : The problem with criteria, either "necessary" or "sufficient", :: : is that there is no mechanism for either consistently applying :: : or enforcing them. :: :: I couldn't have said it better myself! However, this is not a problem with :: criteria per se -- it's a problem with the TC. :: :How can you claim this is a problem with the TC? "necessary" and "sufficient" :are ambigious terms. For example, would you go into an auto :mechanics shop, hand him (or her) your car and say "do what ever is :necessary and send me the bill." I think not (otherwise I want to be :your auto mechanic :-) Unfortunately, twice I have had to hand my body to surgeons and say "do whatever is necessary and send my insurance company the bill" :-( :When ever any organization is working with ambigious criteria, you :get inconsistent results. This is true for contracts, :standards, agreements, or any situation where group sez "we will do this" :and does not define "this". The TC, like any other standards group, represents a multitude of interests. As a result ambiguous criteria cannot be avoided and the resulting standard tends to be the least offensive compromise. No one likes it, but without a strong defacto standard supported by an industry giant, we shouldn't anticipate anything "better". -- Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA I am apolitical, have no resources, and speak only for myself. Ma Bell (703)683-9090 (UUCP: ...{uupsi,vrdxhq}!pbs!npri6!jerry
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/27/91)
Category 10, Topic 30 Message 111 Mon Feb 25, 1991 GARY-S at 06:23 EST Subject: Strings In Message: <9102222024.AA15755@ucbvax.Berkeley.EDU> wmb@MITCH.ENG.SUN.COM writes: >I suspect that if fstrings were proposed, the minimalists would scream >bloody murder. and rightfully so. fstrings has absolutely no place in the controlled word set. as ancillary baggage - fine. add a refrigerator if you want, but don't try to weigh down the core with personal gadgets. __ _ Gary Smith * ... uunet!ddi1!lrark!glsrk!gars * / _' _ _ (_' P. O. Drawer 7680 * GEnie Forth RT & Unix RT SysOp * /__/ (_|_/ '._) Little Rock,AR 72217 * voice phone : 501-227-7817 * --------------- - U. S. A. - * group 3 fax : 501-228-9374 * ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)
Category 10, Topic 30 Message 113 Sat Mar 02, 1991 GARY-S at 06:23 EST In article <9102271415.AA28047@ucbvax.Berkeley.EDU> daemon@ucbvax.BERKELEY.EDU writes: >> and rightfully so. fstrings has absolutely no place in the controlled >> word set. as ancillary baggage - fine. add a refrigerator if you want, >> but don't try to weigh down the core with personal gadgets. > >Not in my wildest dreams would I have proposed to put fstrings in the >CORE wordset, and I doubt that anyone else would have proposed it either. > >Extended STRINGS wordset, maybe, but not CORE. > >Would the minimalists have been right to scream bloody murder under those >conditions? Mitch, we've known each other long enough, well enough that you know I would never presume to speak for _all_ minimalists (or all 'any group'). My personal response is in line two of my original reply above. Gary gars@glsrk ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)
Category 10, Topic 30 Message 114 Sat Mar 02, 1991 B.RODRIGUEZ2 [Brad] at 22:24 EST > ...any situation where group sez "we will do this" and does not > define "this". Non sequitur, Eric. It is precisely a definition of "this", namely, the necessary conditions, that I am asking for. - Brad ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/07/91)
Category 10, Topic 30 Message 120 Sun Apr 07, 1991 B.RODRIGUEZ2 [Brad] at 11:50 EDT From William J. Bouma: > What do you consider a "small machine" these days? ...I consider > any machine with less than 4M RAM to small to be worth using... "Small machine" (Brad's definition): any machine with a 64K or smaller address space. Not all of us use '386s and 68000s. Nothing I've done commercially in the last 3 years has required more than 32K. - Brad Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/11/91)
Category 10, Topic 30 Message 35 Wed Apr 10, 1991 ELLIOTT.C at 13:59 EDT [ If anyone would like a copy of one/more/all of these files, please drop me a note at one of the addresses at the end of this message. All binary files are UUencoded. Files are then split (if necessary) into mailer-acceptable sized pieces and then mailed to you. In order for me to answer your request, you must: Include the line containing the file name. (so I know what you want.) Include your email address in the _body_ of the message. You _must_ include an address *relative to* the InterNet or well known UseNet site. -dwp] Messages up to Nov. '89 have been uploaded to library 10 as st21189.arc ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/16/91)
Category 10, Topic 30
Message 40 Sun Apr 14, 1991
B.RODRIGUEZ2 [Brad] at 17:27 EDT
Well, I would hardly claim to be a spokesman for the "minimalist" camp --
indeed, most of us who have been branded "minimalists" don't even accept that
dichotomy. I, for instance, accept floating-point and files....does that make
me a minimalist? I'm quite happy with DEFER, as it meets my personal criteria
for a standard word. (Which reminds me, I was supposed to post those here.
Later.)
I am, however, sympathetic to the arguments a) DEFER can be portably defined
in ANS Forth, so it's not essential in the Standard, and b) DEFER shouldn't be
in the CORE wordset. As one of the people who is _not_ programming Forth on
32-bit monsters, I am very sensitive to the size of both the core and
extension wordsets.
- Brad
Brad Rodriguez | brad%candice@maccs.uucp (God willing)
B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca
| bradford@maccs.dcss.mcmaster.ca (archaic)
"Yes, sonny, I remember when memory was measured in 'K'..."
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/24/91)
Category 10, Topic 30 Message 43 Sun Apr 21, 1991 B.RODRIGUEZ2 [Brad] at 21:50 EDT As promised long ago, here is the text of proposal TP90-889 (defeated), "Criteria for acceptance of new words." --------------------------------------------------------------------- Add the following text to the Standard, and use these criteria in TC deliberations: In order for a word to be adopted as a Forth standard, it must demonstrate general acceptance, useful functionality, and implementability. To establish general acceptance and usefulness, the exact word must have been in use for at least one year in each of six or more major Forth systems ("major" being defined as having 200 or more users). These six systems must include Forths for at least one 32-bit, one 16-bit, and one 8-bit processor. Successful implementations must be demonstrated for at least one subroutine- threaded, one direct-threaded, and one indirect-threaded Forth system. Proposed words which do not satisfy these criteria shall be deemed "experimental." --------------------------------------------------------------------- One clarification: when this was presented in Detroit, I indicated that the phrase "the exact word" did not apply to word NAMES, but only to function, stack effect, argument values, side effects, etc. (I've recently thought to add the requirement that the six implementations must be done by at least three different people, but the above is what was proposed, and I'll stand by it.) These are, In My Humble Opinion, very "light" criteria. (The Boston group proposed a five-year period.) The intent is a) to ensure that new ideas can be implemented in all Forth environments (e.g., subroutine-threaded), and b) that new ideas be tried out before being adopted. And yet there are entire sections of X3J14 which can't even meet this feeble test! A more damning indictment of X3J14 is that the TC rejected the VERY IDEA of ANY such criteria, with ANY numbers inserted in the blanks. * * * I was once taught a very useful test for intellectual honesty, to see if an opponent is open to argument or persuasion: ask him "What would it take to change your mind on this subject?" The above is my answer to that question -- show me six major systems for one year, and I'll quit carping about local variables and exception handling. But when I asked that question of the TC members, several replied "Nothing" -- which was proof that I was wasting my time. Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
REEVES@SLACVM.SLAC.STANFORD.EDU (Terry Reeves) (05/01/91)
In article <2669.UUL1.3#5129@willett.pgh.pa.us>, Brad Rodriguez writes > >These are, In My Humble Opinion, very "light" criteria. (The Boston group >proposed a five-year period.) The intent is a) to ensure that new ideas can >be implemented in all Forth environments (e.g., subroutine-threaded), and b) >that new ideas be tried out before being adopted. And yet there are entire >sections of X3J14 which can't even meet this feeble test! > In my nowhere near humble opinion (I'm a high energy physicist. My ego is as huge as the distances I probe are small.), the criteria proposed are not light. In fact, I would see them as very stifling. My first quick reading of the proposal seems to say that only those words which are already standard across a major portion of the Forth community can be standardized. This would not only require that all of the necessary systems implement the same ideas, but that they implement them in almost exactly the same way. Since I am most definitely not a minimalist, and I want the standard to address as many issues as possible, I would reject the proposal almost out of hand. Terry P.S. I would also note that it might prevent some of the useful compromises that have taken place, i.e. WORDLIST and floored vs. symmetric division. Disclaimer: The above are my own opinions. The are not necessarily related to the official policies of SLAC, Stanford University, the Dept. of Energy, or the U.S. government.
S47852EF@ETSUACAD.BITNET (05/02/91)
>In my nowhere near humble opinion (I'm a high energy physicist. My ego is as >huge as the distances I probe are small.), the criteria proposed are not >light. In fact, I would see them as very stifling. My first quick reading of >the proposal seems to say that only those words which are already standard >across a major portion of the Forth community can be standardized. This would >not only require that all of the necessary systems implement the same ideas, >but that they implement them in almost exactly the same way. Since I am most >definitely not a minimalist, and I want the standard to address as many issues >as possible, I would reject the proposal almost out of hand. I don't know about that- look at all the C implementations (And they *DO* differ amongst each other and can still claim ANSI portability!); they all have concrete ideas of what the syntax should be and what should it basically do. Yet, they implement it differently- why should this be any different in Forth? It isn't. Therefore, these criteria aren't as heavy as you make them but not as light as Brad makes them- they are STILL reasonable. >P.S. I would also note that it might prevent some of the useful compromises > that have taken place, i.e. WORDLIST and floored vs. symmetric division. In your example, WORDLIST is the only thing that wouldn't have made it- floored and symmetrical division has been around and implemented over most of the entire existance of the language and therefore would pass the criteria. (I.e. You could have both in the language and DEFERed (Or, it's equivalent) the '/' operator and assigned it the PFA of the form you want to use... And we have had one or the other since atleast 1983-84 when the 83 standard came out!) Frank
Mitch.Bradley@ENG.SUN.COM (05/02/91)
> To establish general acceptance and usefulness, the exact word must have > been in use for at least one year in each of six or more major Forth systems > "the exact word" does not apply to word NAMES, but only to function, > stack effect, argument values, side effects, etc. This would effectively prevent ANY new words from making it into the standard. Counterexamples are solicited. Please be prepared to defend your claim by citing the 6 major systems. To impose this requirement on the committee would prevent any progress from being made. Mitch.Bradley@Eng.Sun.COM
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/06/91)
Category 10, Topic 30 Message 50 Sun May 05, 1991 B.RODRIGUEZ2 [Brad] at 10:09 EDT All I can say is, the Forth community must be a lot smaller than I thought it was. (Someone once told me that there were about 150 Forth vendors.) With the exception of the subroutine-threaded implementation -- and that was a concession to the STC contingent that I was sure the TC would approve -- any Forth usage from polyForth could meet these criteria. Or anything from LMI Forth. Or from MPE. In fact, the big weakness of my proposed criteria is that they allow all six model systems to come from a single vendor. Specific examples? ONLY/ALSO. TO. Conditional compilation. FOR...NEXT. Probably file systems (although I'm not familiar with industry practice here). Probably much of floating point (ditto). Almost certainly you could find two or three strings packages to meet these criteria. And given the number of vendors on the TC, it should take no more than 12 months and a fraction to meet this requirement for the most fevered products of the TC's imagination. Why is no one willing to do this? The burden of proof is on the positive, in philosophy and in jurisprudence....but evidently not in standards-making. Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
Mitch.Bradley@Eng.Sun.COM (05/08/91)
> All I can say is, the Forth community must be a lot smaller than I thought > it was. (Someone once told me that there were about 150 Forth vendors.) In the early phases of the standards effort, the TC sent out hundreds of copies of a questionnaire. They tried to send it to every vendor they could locate. The questionnaire was fairly detailed, asking for information about product's compliance and areas of noncompliance with existing standards, areas where the standard should be improved, and other things. It also asked for copies of product manuals so the TC could learn details of these implementations. The response was underwhelming. The TC got very few responses back. > In fact, the big weakness of my proposed criteria is > that they allow all six model systems to come from a single vendor. I presume that citing 6 systems from the same vendor would not satisfy the spirit of your requirement. If so, then this criterion would be useless; I could justify anything I wanted based on different versions of Forthmacs. > Specific examples? > ONLY/ALSO. Maybe, but there are serious problems with the semantics of VOCABULARY and differences in the implementation of SEAL . Also, in order to make the ALSO/ONLY wordset complete, you need PREVIOUS, which probably wouldn't "make the cut", and you also need some way to save and restore the search order, which wouldn't make the cut. > TO. Maybe. It depends on how strictly you construe the "no semantic differences" requirement. Also, TO is only useful in the context of VALUE , which might not satisfy the requirement, and with locals, which definitely would not satisfy the semantic requirement. > Conditional compilation. Semantic differences exist. > FOR...NEXT. I doubt it. > Probably file systems I'm quite certain that it would not have been possible to achieve a coherent, useful file system wordset based upon your proposed criteria. > Probably much of floating point (ditto). Yes, I expect that much of the floating point wordset would have passed. But what about the rest? A wordset with gaping holes is crippled. > Almost certainly you could find two > or three strings packages to meet these criteria. Perhaps. The only example of a strings package that would come close is FSTRINGS, and I don't know of any Forth systems that come with it. > And given the number of vendors on the TC, it should take no more than 12 > months and a fraction to meet this requirement for the most fevered products > of the TC's imagination. Why is no one willing to do this? There are 4 significant vendors represented on the TC: FORTH, Inc (polyFORTH), Creative Solutions (MacForth), Bradley Forthware (Forthmacs), Vesta (some ROM Forths) LMI (UR/Forth) used to be represented. In addition, we know pretty much about F83, F-PC, and MVP Forth from manuals and personal experience. There is very little agreement between the products of these vendors in terms of detailed semantics of extension packages. > The burden of proof is on the positive, in philosophy and in > jurisprudence....but evidently not in standards-making. Philosophers can invent their own data. In jurisprudence, what it really comes down to is what the jury votes. The ANS Forth committee relies on judgment, debate, and voting to make its decisions. Mitch.Bradley@Eng.Sun.COM