ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/02/90)
Category 10, Topic 1
Message 12 Sun Sep 30, 1990
D.RUFFER [Dennis] at 23:50 EDT
Brad, there are two ways (or more) to "break" code. One way is to change the
meaning of a word that is in general use. In the case of NOT, it was broken
in 83 and to enforce either of the accepted practices would fall under this
method. The ANS TC is very much against this type of thing. The other way to
"break" code is to change the name of a valuable function where there is
disagreement over the usages of the "old" names. Generally, these "breakages"
can be fixed by a simple search and replace. This method is acceptable to the
TC and thus we have:
NOT (83 method) -> INVERT
NOT (79 method) -> 0=
COMPILE -> POSTPONE
[COMPILE] -> POSTPONE
VOCABULARY -> WORDLIST (maybe, still on burning issues)
POSTPONE is merely a re-naming of two very confusing operators. ENVIRONMENT?
is the only way to enforce the documentation of system specific settings.
CATCH/THROW have been in practice in at least two major systems for quite a
while. I don't know the history of (LOCALS) so I can't comment.
This has become a very diverse language, and it shouldn't come as a shock to
anyone that the ANS standard will bring in things that may be new to us.
However, new in our eyes does not mean that it has not been implemented other
people's systems. I've said it before, and I guess I will say it many times
again. How many systems have you seen, and what percentage of the
implementations do you think that represents?
DaR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/09/90)
Category 10, Topic 1
Message 13 Sun Oct 07, 1990
B.RODRIGUEZ2 [Brad] at 21:29 EDT
Dennis, 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
Somehow the TC has developed the idea that #4 is superior to #3. In my
priorities #3 is superior to #4. (The TC also rates #4 superior to #2, and I
have problems with that, too.)
The TC's attitude toward renaming is rather cavalier. 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.)
> 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? (I have a more detailed objection to ENVIRONMENT? which I'll
be sending to the TC shortly.)
> CATCH/THROW have been in practice in at least two major systems
> for quite a while.
What constitutes "major"?
How long is "quite a while"?
Which two systems, and how many people use them?
Do two systems constitute a significant cross-section of the Forth community?
> 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. Plus
documentation for polyForth, which I've used but don't own. Included among
that multitude are fig-Forth and F83, to which I suspect the majority of
Forths in use today can trace their lineage. Is that enough? Am I qualified
to comment, now?
> ...the ANS standard will bring in things that may be new to us.
I have yet to hear a more horrifying statement from a member of the TC.
When, exactly, did this become an R&D project?
I apologize if my tone is becoming more harsh. Since its inception I have
gone from being a supporter of X3J14, to a cautiously- supporting critic. Now
I'm starting to feel like Dr. Frankenstein's laboratory assistant -- what
monster have I helped (however indirectly) to create?
- Brad
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/10/90)
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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/10/90)
Category 10, Topic 1 Message 15 Tue Oct 09, 1990 GARY-S at 06:49 EDT Dennis - Perhaps you, and many grow tired of the complaints, but I would hope you also agree constructive criticism should be part of the process. I personally would feel much better if someone representing the TC were to acknowledge remarks like those made by Glen Haydon and Dick Miller (in on-line GEnie conferences, transcripts available in Library 1 and via FNEAS) gave them cause for reflection and/or modification of the BASIS draft process. These two, like members of the TC - and Brad, are respected members of the Forth community and I would be extremely disheartened to discover legitimate voices were being treated in a cavalier manner. I don't think any of the remarks here are being ignored or treated in a trivial manner and I would hope your sarcasm doesn't prevent others from offering thoughtful opinions on how they think the future standard bearer for Forth should be constructed. Gary ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
dwp@willett.pgh.pa.us (Doug Philips) (10/11/90)
In <1842.UUL1.3#5129@willett.pgh.pa.us>, GARY-S writes: > > These two [Glen Haydon, Dick Miller], like members of the TC - and Brad, > are respected members of the Forth community and I would be extremely > disheartened to discover legitimate voices were being treated in a > cavalier manner. > > I don't think any of the remarks here are being ignored or treated in > a trivial manner and I would hope your sarcasm doesn't prevent others > from offering thoughtful opinions on how they think the future standard > bearer for Forth should be constructed. > Gary These comments are all based on my understanding of the ANS process, gleaned from both the X3J11 and X3J14 efforts. If I am wrong, I would appreciate being corrected. That said... I think the real issue that hasn't been explicitly addressed here is just how feedback should get to the TC. As I understand it, ANSI has very specific rules about how the TC must establish the consensus ANSI requires before bestowing its sanction and proclaiming a standard. Those rules don't require the TC to comb the streets and respond to every griping malcontent that speaks ill of its efforts. I think that the TC has realized that an electronic presence is important. I am glad to see them making the BASIS available electronicly. I am glad to see that Dennis is forwarding ForthNet material to the committee. What I am disheartened to hear is that significant "movers and shakers" would rather gripe about the standards effort than submit real input. I've seen the ANSI forms. They aren't that hard to fill out. Some people have even posted their material to the net, in addition to sending it to the TC. I seriously question someone who would rather gripe than try to improve things and I can guess at several reasons why they might do that. However, since I do not know the specifics of any of the cases Gary refers to, I won't comment on them. Instead I'll say what *my* overriding inhibitor is: I don't know what proposals (the content, not just the title) have been submitted to the TC and what the decisions on them were. Lists of proposals by title in the minutes helps me none at all, and I suspect that they aren't supposed to. I think it would be very helpful if as part of the BASIS, the TC would publish the proposals, their disposition, and a succinct account of how the reasoning that lead to that disposition. I would think that quoting/citing such a document would be the ideal way to respond to inquiries such a "the TC broke BAR," or "why do you need feature FOO?" I would think that such documents would pay back in saved time several times more than would be spent to create them, especially when the BASIS evolves into a dpANS. On the other hand, maybe not. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/11/90)
Category 10, Topic 1 Message 16 Tue Oct 09, 1990 D.RUFFER [Dennis] at 22:15 EDT Re: GARY-S > Perhaps you, and many grow tired of the complaints, but I would > hope you also agree constructive criticism should be part of the > process. "Constructive" criticism is indeed welcome, and I hope I have done nothing to discourage it. However, can not take all the comments I have heard as being constructive. > I personally would feel much better if someone representing the TC > were to acknowledge remarks like those made by Glen Haydon and > Dick Miller I too wish this was an "official" channel to the TC, but we lost that battle a long time ago. As it stands now, I try to do my best to relay the information to the TC Chair, and she does dilligently read everything I give her, and occasionally responds. However, this IS NOT and official channel and I hope no one takes it as such. The official channel is paper proposals, and those are distributed to and voted on by the entire TC. I'm sorry for the tone of my previous posting. My patience is wearing very thin at the moment. I apologize and will attempt to hold my personal feelings a little closer in check in the future. 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Category 10, Topic 1 Message 18 Thu Oct 11, 1990 D.RUFFER [Dennis] at 23:16 EDT Re: dwp@willett.pgh.pa.us (Doug Philips) > I think it would be very helpful if as part of the BASIS, the TC > would publish the proposals, their disposition, and a succinct > account of how the reasoning that lead to that disposition. Are you volunteering to type them all in Doug (90% are in hand written form or significantly modified within the TC)? We are having enough trouble getting just the BASIS done (which I have to upload yet tonight :-). IMHO, it is unreasonable to put an even greater burden on the TC's efforts. However, if someone feels ambitious, I'm pretty sure the TC would not have any problem with it. 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/15/90)
Category 10, Topic 1 Message 19 Sun Oct 14, 1990 B.RODRIGUEZ2 [Brad] at 17:11 EDT Wow, a wealth of response. I'll reply to Dennis, and trust that this reply will cover the issues everyone else raised. I'll grant that other people's -- and consequently the TC's -- priorities are different from mine. But I think it's important to review them periodically, both to see how valid they are, and to see how closely the TC is sticking to them. Most notably: I'm starting to see the ANSI effort as divided into two camps, not on the "fat" vs. "thin" issue, but on the issue of the purpose of having an ANSI standard. Group A wants the standard to reflect what Forth _is_, while Group B wants the standard to reflect what Forth _ought_to_be_. The former wants an ANSI Forth in order to standardize the language; the latter wants it in order to market the language. I think we need a clear statement of position here, if not from the ANSI team, at least from its members. I trust that it has become obvious that I'm in Group A, and I'm afraid that Group B is beginning to dominate. > When you have books in print that describe specific implementations > and those implementations conflict, how can you fix them? The point I was making is that even when all previous implementations _agreed_, the ANSI team has changed things. Further comments on ENVIRONMENT? I will submit to the TC. On CATCH/THROW: > Mitch Bradleys I know has something very similar, and I seem to > remember that Don Colburn said it used a very similar technique. Thank you, you've made my point. People have done _similar_ things. (The same is true of local variables.) But the implementation proposed by the ANSI TC has, to my knowledge, been used only by Mitch Bradley. There are two reasons why it's necessary to have a long field trial before adopting a new idea into the standard. The first reason -- the reason everyone focuses on -- is to determine if the idea is implementable. The second, neglected, but equally important, reason is to determine if the idea is _useful_. By this I mean widely applicable, useful to a broad spectrum of Forth programmers in a variety of applications. Even minor variations in the implementation details can radically affect the usefulness of a construct. (Consider +1 vs. -1 for "true," or the 79- vs. 83- Standard LEAVE.) Only time can establish usefulness, and this is why I say it's too soon to adopt CATCH and THROW into an American National Standard. BTW, I've done something similar myself. (Check out sigForth Vol.1 No.2.) Interestingly enough, my system handled a problem that CATCH and THROW cannot. But this problem may have been specific to my application, so my system may not be the best thing to standardize upon. (Please note that I haven't submitted it to the TC.) > Do you have a better suggestion? Sure. Postpone it until a future edition of the standard. In the meantime, get the Forth community to try it -- and other systems; at least three more have been invented -- out. (Remember the great CASE contest?) > 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. Sorry, I neglected to mention that I implemented two of those myself. I'm implementing three more right now. Patronizing comments avail you naught. > You can either choose to help the process by submitting positive > comments and suggestions...or you can hinder the effort by > degrading their efforts or dwelling on their past judgments. Allow me to point out that I began sending positive suggestions to the TC _long_ before I began carping in this semi-public forum. (Some of them, incredibly, were accepted.) I am _still_ sending formal proposals to the TC, and IMHO I have been instrumental in getting some of the other dissatisfied Southern Ontario Forthers to do likewise. BUT...the TC's debates are rarely published -- only their decisions, in a cryptic set of minutes in which the proposals are identified only by title (not by author). I as a "submittor" am not informed of when my proposal is going to be decided, or even what number it has been assigned. Like many interested parties, I can rarely afford to attend one ANSI meeting, let alone all of them. So, by definition, the only way we can discuss the TC's decisions is after the fact, in forums such as this. If this is a "hindrance", well, public debate always is. - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/16/90)
Category 10, Topic 1 Message 20 Mon Oct 15, 1990 D.RUFFER [Dennis] at 02:02 EDT Re: B.RODRIGUEZ2 [Brad] > I'll grant that other people's -- and consequently the TC's -- > priorities are different from mine. But I think it's important > to review them periodically, both to see how valid they are, and > to see how closely the TC is sticking to them. Agreed Brad, and that is why this latest scope of work that I posted to the library is the results of their latest review of their priorities. I highly recommend you, and everyone else, check it out to see what they consider their priorities to be. > I think we need a clear statement of position here Read SCOPE.ARC in the library! [See a previous ForthNet post for this file. -dwp] I agree with your analysis of the two camps that have formed around the ANSI standard. I'm not sure how their scope of work answers your question about which camp is going to "win", but it at least shows how they weigh their decisions. Now, they will all admit that they have been very loose about the enforcement of their scope of work, but I can also tell you that they are resolved to stick closer to it from now on. IMHO, since the ANSI efforts were started as a way to make Forth more acceptable to the vendor's clients, I can see a strong tendancy to your Group B (i.e. making Forth what it _ought_to_be_). However, again IMHO, if they can "fix" some of the more glaring deficenties that I say more power to them. (*** IMHO ***) > The point I was making is that even when all previous > implementations _agreed_, the ANSI team has changed things. Can you give me an example Brad? I don't see where that has happened? > But the implementation proposed by the ANSI TC has, to my > knowledge, been used only by Mitch Bradley. At the risk of making you even more sure that you are "right", I should mention that the ANS CATCH and THROW are not exactly what Mitch uses, but is a reasonable compromise that will work on most systems. I can see your resistance to the concept, but are you willing to continue having Forth laughed at for its lack of error recovery? Some members of the TC are unwilling to accept a standard that does not address this issue (and I applaud them). Mitch came forward with what looks like a reasonable way to resolve this burning issue. Sure it is too soon, and possibly inappropriate to add this new feature to Forth. However, either the issue is resolved, or we will not have a standard. It's as simple as that. > Even minor variations in the implementation details can radically > affect the usefulness of a construct. (Consider +1 vs. -1 for > "true," or the 79- vs. 83-Standard LEAVE.) I'm sorry, I can not group the changes you mention in the 83 Standard as "minor". They have major impact to applications. I could argue that CATCH & THROW will not have the same impact, since ABORT" will still work the same, but I will concede that I do not know that to be fact yet. It is too early, but it is also, unfortunately, too late. WE NEED AN ANSI STANDARD! Without some kind of error recovery mechanism, there are those on the TC who will not vote for it. Result = no standard. > (Remember the great CASE contest?) Notice there is no CASE construction in ANS Forth. <smile> > BUT...the TC's debates are rarely published -- only their > decisions Are there any volunteers who would record the debates and publish them? I'm sure the TC would gladely add it to the minutes, but they are all to busy arguing to write anything down. All that is recorded IS the final decisions. If you have not been to any of their meetings, then it is hard for me to explain it. After you have been to one, usually there is no arguement. > If this is a "hindrance", well, public debate always is. The TC is not in the "public debate" mode yet. That happens as soon as they can agree among themselves on the "draft proposed ANS standard" (dpANS). They are accepting proposals from the public to help them form this document and in a sincere attempt to resolve public debate before they publish the dpANS. Once they publish it, we enter the "public comment" phase, and they will have to respond to EVERY comment. If it appears as if the document does not represent the industry, they will have to start over. However, their goal is to get the dpANS publish next year. To do this, there needs to be some serious compromises in the next meetings. I suspect that if anything like CATCH & THROW is too debateable, it will be pulled. Their primary emphasis now is on the remaining "burning issues" which you will find in the latest minutes (MINUTES.13). Anything else, either new features or resurections of past resolutions, will be given little consideration. This is not to say that they will not listen to a compelling arguement. It is just that they are all tired and over taxed. They have been at it for three years already, and they are all eager to get the dpANS published. Anything that is not directed to that goal is not going to gain much favor any more. 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/16/90)
Category 10, Topic 1 Message 21 Mon Oct 15, 1990 B.RODRIGUEZ2 [Brad] at 07:25 EDT Ah, how fortunate that my restless night allows me to respond so promptly... > Read SCOPE.ARC in the library! I downloaded it in the same session when I uploaded my last comments. Now I have to arrange to email it to someone who can process .RTF files, and for him to send me hardcopy... :-) >> The point I was making is that even when all previous >> implementations _agreed_, the ANSI team has changed things. > Can you give me an example Brad? Offhand? How about WORDLIST for VOCABULARY, and ADDITIONS for DEFINITIONS? (I realize that search orders vary from implementation to implementation, but the acts of declaring and invoking a vocabulary are remarkably constant across Forth standards.) I would argue that CHAR is an example, although I realize ASCII was never formally adopted anywhere -- it was just a widely accepted informal standard. (A pity those aren't recognized more often.) > ...are you willing to continue having Forth laughed at for its > lack of error recovery? Really? Can you tell me who's been doing this laughing, and why C and Pascal were never objects of their ridicule? I've heard Forth criticized for many reasons, but this was _never_ one of them. > Some members of the TC are unwilling to accept a standard that > does not address this issue... ...either the issue is resolved, > or we will not have a standard. It's as simple as that. Sounds to me like some members of the TC are indulging in a little extortion. "Give me what I want, or I'll torpedo this standard!" Is this the model of behavior you wish to promote? Are these the kind of people who should decide a national standard? >> Even minor variations in the implementation details can radically >> affect the usefulness of a construct. [Examples] > I'm sorry, I can not group the changes you mention in the 83 > Standard as "minor". They have major impact to applications. Sorry, Dennis, I should have put "minor" in quotes originally. This is exactly the point I was trying to make -- seemingly trivial details in an implementation can have major applications impact. Only I wasn't referring just to the problem of updating old applications code; I was saying that even in _brand_new_ constructs, little things make a big difference, and these are hard to see without experience. If you were designing a new language, would you make "true" -1 or +1? What would you have done if you hadn't experienced both in the Forth community? > Are there any volunteers who would record the debates...? Oh, I can imagine what a TC meeting is like -- I've been involved in similar efforts. I was just saying that, so long as TC meetings are conducted and reported as they have been, the only option many of us have is to protest and criticize their decisions after the fact. BTW, I note that the proposal/comment form is no longer included in the BASIS distribution, and hasn't been for some time now. Had I not pestered Martin Tracy at a FORML conference, I wouldn't know how to submit a proposal to the TC. Just a thought. The "proposal log", a useful innovation which appeared briefly around BASIS10, is now gone too. *Sigh* > The TC is not in the "public debate" mode yet. Then why this category on GEnie? :-) Seriously, if you don't get the debate accomplished now, you'll be in for a REALLY rough ride later, when the dpANS is officially published for comment. Which you already know. > ...their goal is to get the dpANS publish next year. IMHO, had there been fewer people who were hot to get their pet ideas into the standard, this could have been accomplished sooner. Shucks, I was reasonably happy with BASIS8. (Or was it BASIS6? :-) ) > Anything else, either new features or resurections of past > resolutions, will be given little consideration. Does this mean it's too late to comment on BASIS12? According to MINUTES.13, the BASIS12 document has been officially adopted now. Although no one saw it but the TC. (Grumble.) - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)
Category 10, Topic 1 Message 22 Mon Oct 15, 1990 D.RUFFER [Dennis] at 23:46 EDT Re: B.RODRIGUEZ2 [Brad] > > Can you give me an example Brad? > > Offhand? How about WORDLIST for VOCABULARY, and ADDITIONS for > DEFINITIONS? I know you have seen polyFORTH. How can you say that it declares vocabularies in any way similar to any other Forth? Some implementations don't even have vocabularies. I guess I just haven't seen the commonality that you are alluding to. > I would argue that CHAR is an example, although I realize ASCII > was never formally adopted anywhere -- it was just a widely > accepted informal standard. (A pity those aren't recognized more > often.) ASCII is only the standard in America (e.g. the A in ASCII). ANS Forth is attempting to be more international, and thus has settled on the IRV character set. What would they say? ASCII defines an IRV character? <yuck> > > lack of error recovery? > Really? Can you tell me who's been doing this laughing, and why > C and Pascal were never objects of their ridicule? I don't know about Pascal, but even C has the "setjump" concepts. Even BASIC has ON ERROR procedures. I am very surprised that you have never heard people laugh at our "?" error message (it is the only one we've got :-). Maybe we have just been talking to different people. > Are these the kind of people who should decide a national > standard? I don't know! I didn't "elect" them. Nobody did, but they have proved their "value" by putting up the time and expense of participation. Thus, they are the ones who get to decide. > If you were designing a new language, would you make "true" -1 or > +1? What would you have done if you hadn't experienced both in > the Forth community? Personally, I saw nothing wrong with saying that true was non-zero. That way an implementation could choose whatever they needed for efficiency. However, programmers are lazy, and standards are weak. Thus you get people multiplying boolians because AND works on bits and others insisting that true must have all bits on so that AND works. What to do...what to do? In other languages, boolians are not confused with bits. A strongly typed language would not have this problem. Usually, it doesn't even matter if a logical flag is implemented with 1 or 0 bits representing the true state. The logical tests know the difference. However, Forth does not type its operators, and AND can be used as a logical operator or as a bit mask. Historically, we have agreed that 0 is false and we have a strong desire that AND works in both modes. Thus true must be -1, but the conversion was still painful. Personally, I rejoiced when the 83 standard "fixed" this problem, and I will rejoice again, if the problems with error recovery can be "fixed" by ANS Forth. > BTW, I note that the proposal/comment form is no longer included > in the BASIS distribution, and hasn't been for some time now. Do you think the form has changed? It has not! The same one that appear in the original BASIS documents, that appeared in Forth Dimensions, that is even available here on GEnie (I forget the file name right now) still works today. I don't know why it was removed, but it sure makes sense. > The "proposal log", a useful innovation which appeared briefly > around BASIS10, is now gone too. *Sigh* The proposals affecting the current version are still included. The full list is much too lengthy to distribute and means nothing without the actual text of the proposals. > Does this mean it's too late to comment on BASIS12? BASIS 12 is obsolete as of the last meeting. Proposals should now be directed at BASIS 13 which is available now. > According to MINUTES.13, the BASIS12 document has been officially > adopted now. adopted and changed! 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)
Category 10, Topic 1 Message 23 Thu Oct 18, 1990 JETHOMAS at 23:38 CDT >> The point I was making is that even when all previous >> implementations _agreed_, the ANSI team has changed things. > Can you give me an example Brad? I don't see where that has > happened? >> But the implementation proposed by the ANSI TC has, to my >> knowledge, been used only by Mitch Bradley. > At the risk of making you even more sure that you are "right", I > should mention that the ANS CATCH and THROW are not exactly what > Mitch uses, but is a reasonable compromise that will work on most > systems. From my perspective, the MAIN thing we should expect of ANSI TC is that they not 'put new wine into old bottles'. If the approach is new, then it needs a new name. If major vendors use the same name differently, then make a new name for the old function! They should minimise the exclusion of existing code. It looks like they've been doing a very good job by this criterion. Beyond that, I don't see how we can be too doctrinaire and still have a standard. Various people have a veto. Assuming they're all rational people of good will, we still face a collection of good but incompatible ideas. We don't want a 'PL/I' standard that requires every idea that sounds good. We do want a set of tools that work well with each other. Trying to get that means sometimes going with existing practice, and sometimes using something new. Sometimes a new approach will be required to break a deadlock. Then other new methods become supremely practical given the presence of the first. Any rigid formula for deciding what's acceptable is bound to fail. If they can produce a flexible system, then all the existing Forths should be writeable in it, and even small applications could become 'standard' at less than twice the size. 8- ) You have to at least think you're good at this sort of thing to pay much attention to Forth. But Forth programmers tend to do it by keeping a whole module inside one head. How would a committee of Forth programmers come up with a good system? It would help if they were all very fast programmers who could adapt to new styles quickly. Then they could sort-of try out new things to get a feel for them. I'd expect the ones who were best at this would tend to get their way, provided they could also communicate their ideas well. I'd expect Forth programmers to be better than usual at adapting the language to the problem, but perhaps not so consistent about explaining it.... I predict that there WILL be an ANSI standard. The people who really need one will accept one that's less than perfect. The people who don't need one can ignore it easier than going to some trouble to block it and get the others angry at them. It will be interesting to see what we get. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/28/90)
Category 10, Topic 1 Message 28 Sat Oct 27, 1990 B.RODRIGUEZ2 [Brad] at 17:40 EDT Response to Dennis Ruffer (and others making similar points): > How can you say that it [polyFORTH] declares vocabularies in any > way similar to any other Forth? In the same way that fig-Forth VARIABLE is similar to '83 VARIABLE: they differ only in the presence of a numeric argument. Every Forth that I have seen (many, but certainly not all!) declares vocabularies with either VOCABULARY name or nnn VOCABULARY name where 'nnn' is implementation-defined. I maintain that this is insufficient reason to concoct a new name. Obviously, the TC feels otherwise. (As noted in an earlier message.) > ...people laugh at our "?" error message... You're confusing compile-time errors with run-time exceptions. Yes, I've heard gripes about Forth's compiler diagnostics, but CATCH and THROW aren't required for this -- they are for run-time exception handling. > The same one [proposal form] that appear in the original BASIS > documents....still works today. Yes, *I* know that, but I've met people who just saw their first BASIS document and aren't on GEnie. *They* need the form. Response to Mitch Bradley... >> ...and why C and Pascal were never objects of their ridicule? > C has error recovery (setjmp()/longjmp()), and a great many > significant C programs use it. The operative word was "never". My original K&R "The C Programming Language" makes no mention of error recovery; yet somehow C survived its early years and now prospers. > a) It is difficult to unilaterally engage in this kind of > extortion. Hmmm. Not according to TC members I've talked to; on several occasions I was told that some iffy proposal or other was adopted because some single individual stonewalled and threatened to kill the whole process. (I regret not writing down those stories, so I could tell you precisely which issues.) Of course, it's possible that said individuals were BSing me in order to hide their own complicity in something I found odious, which would imply that they are unwilling to publicly defend their private actions. > So far, my "pet ideas" have been in the form of OPTIONAL extensions > that other successful languages have had for many years, and which > Forth needs... Mitch, I couldn't agree more that Forth NEEDS these extensions. I disagree with your means, not your ends. I continue to hold that the A.N.Standard is *not* the place for R&D. If we need a vehicle for improving the language, let's create one for that express purpose, instead of pressing X3J14 into this role. Reply to UNBCIC@BRFAPESP.BITNET (who is this really?): >> Does this mean it's too late to comment on BASIS12? > ?? THIS I didn't understand. What, then, I have, that's supposed > to be BASIS 12 text? What you have is no doubt BASIS12. BASIS12 is the result of X3J14 meeting #12, and it is circulated for comment following that meeting; these comments are then considered at meeting #13, at which BASIS12 officially expires and is no longer valid. Meeting #13 has already taken place, which means your document is obsolete and BASIS13 is what we're supposed to be commenting on, before meeting #14 takes place on November 6th. (Someone correct me if this is inaccurate.) In practical terms, much of BASIS12 still exists in BASIS13; only the section numbers have changed. What I wanted to know was, if the TC receives comments on November 6th that refer to the officially- expired BASIS12, will they consider these comments, or will they get tossed without reading? - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/30/90)
Category 10, Topic 1 Message 29 Sun Oct 28, 1990 D.RUFFER [Dennis] at 23:30 EST Re: B.RODRIGUEZ2 [Brad] > What I wanted to know was, if the TC receives comments on > November 6th that refer to the officially- expired BASIS12, will > they consider these comments, or will they get tossed without > reading? I do not recommend submitting comments, but proposals are always welcome. If you are unable to confirm that it is still applicable to the current BASIS document, then I suggest that you might try to contact a TC member (contact information is in the beginning of each BASIS document). If that is also not possible, then submit the proposal anyway and let the TC sort it out. 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