koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/14/90)
I had a conversation with a Peter Lee of CMU this week about the ANS Forth Standard effort. Peter is a professor in the School of CS in the advanced programming language group. He was also one of my dissertation advisers, and has a fair idea of what Forth is about. I told Peter about the floored/symmetric/truncated division issue. He told me that the ML functional programming language specified symmetric division in the standard. However, the first implementation used truncated division for speed, because "they realized that having any other division as the default was *stupid*". ML is not supposed to be a particularly fast language, either. This comment comes from a professional semanticist and language designer. Apparently, now (several years later) some folks have complained enough that implementations are starting to default to symmetric division (after much resistance the purists, of whom there are many in CS, won out). I told him about the problem caused when the 83 Forth Standard changed definitions of existing words (e.g. NOT). He was amused. I then told him about the compromise method of using new names for functions with conflicting widespread usage. He just laughed and shook his head. Some folks are worried about how Forth will be judged when outsiders see the new standard. My brief interaction with Peter indicates that perhaps there is some merit to their concern. One way to solve this would be to find a few non-Forthers to review the standard in its penultimate form. This should include both engineers and computer scientists who are *not* Forth experts. I can probably talk Peter into a 1- or 2-hour review. Can anyone else recruit people from their organizations? Will folks on X3J14 listen if we go to this trouble? Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior scientist at Harris Semiconductor, and adjunct professor at CMU. I don't speak for them, and they don't speak for me.
dwp@willett.UUCP (Doug Philips) (07/15/90)
In <9899@pt.cs.cmu.edu>, koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: > I told Peter about the floored/symmetric/truncated division > issue. He told me that the ML functional programming language > specified symmetric division in the standard. However, the > first implementation used truncated division for speed, > because "they realized that having any other division as > the default was *stupid*". ML is not supposed to be a particularly > fast language, either. This comment comes from a professional > semanticist and language designer. Apparently, now (several > years later) some folks have complained enough that > implementations are starting to default to symmetric > division (after much resistance the purists, of whom there > are many in CS, won out). I don't get a sense of your point here, are you saying that the "purists" are stupidly getting their way, or, that it was stupid to worry about some efficiency issue in this one place in an otherwise inefficient language anyway and the purists are finally getting things straightened out? > I told him about the problem caused when the 83 Forth Standard > changed definitions of existing words (e.g. NOT). He was > amused. I then told him about the compromise method of > using new names for functions with conflicting widespread > usage. He just laughed and shook his head. Are you implying that his laughter was due to the inappropriateness of the solution or was due to an understanding of the predicament the standards committee was in? > Some folks are worried about how Forth will be judged when > outsiders see the new standard. My brief interaction with > Peter indicates that perhaps there is some merit to their > concern. One way to solve this would be to find a few > non-Forthers to review the standard in its penultimate form. > This should include both engineers and computer scientists > who are *not* Forth experts. I can probably talk Peter into > a 1- or 2-hour review. Can anyone else recruit people from > their organizations? Will folks on X3J14 listen if we > go to this trouble? Should you go to that trouble? Depends on what kind of information you're going to solicit and what you think should be done with it. You don't say that here. Is the review to contain a capsule history that EXPLAINS why each part is the way it is, or are you just going to present it out of context? How are you going to factor for the people who have no inkling of what Forth is (applies to some degree to Peter since you present him as being a non-Forther, albeit, perhaps sympathetic)? "Forth, what a joke, its nothing like <X :- {Algol,C, Simula,Lisp,SmallTalk,ML,Eiffel,...}>" Maybe you should get PostScript programmers to review it: "Gack, pure postfix is obviously the way to go, remove CREATE, VARIABLE, CONSTANT or make them truly postfix"...Obviously I'm being facetious here, but there is an issue which you haven't mentioned: how are you, in the space of 1-2 hours, going to be able to communicate an understanding of Forth philosophy sufficient for the outsider to evaluate the standard fairly *and* actually get to the evaluation of the standard part. I don't mean to say that I think your idea is unworkable, but I do see several difficulties with it. In particular, most of the complaints about the 30-sided wrenches have nothing to do with Forth and everything to do with the political process of reaching a consensus. I don't suppose you even asked Peter what he would have done instead (and why)? This political issue isn't unique to Forth. Perhaps the popular myth of the independant Forth programmer is true enough to the extent to which it engenders separatism instead of cooperation, thus magnifying the problem? Maybe you should include in your list of outsiders some people that have gone through the standards process for other languages? To start a slightly different thread: Has anyone on the TC consulted with anyone from previous ANSI efforts to learn whatever lessons of consensus making might already have already been learned? Does ANSI not provide any political/human-factors assistence to its groups? Are Forth programmers to head strong to actually consider such assistance/advice even if it were available? Does anyone else see that the problems with / and NOT are purely political and that they reflect upon Forth itself only because they reflect upon Forth programmers/vendors/TC-members? (guilt by association?) -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/16/90)
>> [ML implementors] ... "...realized that having any other division as >> the default was *stupid*". >I don't get a sense of your point here, are you saying that >the "purists" are stupidly getting their way, or, that it was stupid >to worry about some efficiency issue in this one place in an otherwise >inefficient language anyway and the purists are finally getting things >straightened out? Peter apparently thought that the default division should be the fastest one (the one supported by hardware), with other divisions called out with special function names, even in a generally inefficient language. He doesn't seem to agree with the purists. My discussion with him was brief, and I haven't had a session with him where I have dug in deep for reasoning. >> [Discussion of NOT and function renaming to as a compromise] >Are you implying that his laughter was due to the inappropriateness >of the solution or was due to an understanding of the predicament the >standards committee was in? It was probably a mixture of seeing the mess the 79/83 function changing caused, the fact that words currently in use will be left floating, and an appreciation for the politics at work within the standards committee. The point is that he reacted with amusement at the situation/solution instead of with a comment such as "that sounds like a reasonable course of action". >> One way to solve this would be to find a few >> non-Forthers to review the standard in its penultimate form.... > ... Is the review to contain a capsule history >that EXPLAINS why each part is the way it is, or are you just going >to present it out of context? How are you going to factor for the >people who have no inkling of what Forth is (applies to some degree >to Peter since you present him as being a non-Forther, albeit, perhaps >sympathetic)? > ... how are you, in the space of 1-2 hours, >going to be able to communicate an understanding of Forth philosophy >sufficient for the outsider to evaluate the standard fairly *and* >actually get to the evaluation of the standard part. The point is one that I believe John Wavrick has been making. (Please forgive me, John, if I don't get it quite the way you have been putting it.) An important function of the standard is to show that the language is mature and ready for consideration by folks who have been waiting on the sidelines for any number of reasons. If they pick up a copy of the standard (and perhaps Starting Forth) and *perceive* it as hopelessly compromised, or otherwise faulty, that is probably the last they (or many people they advise) will think of Forth. If the Standard has no capsule history, they won't see one. Just giving someone a Basis document with little/no support is the relevant context for this sort of review. If they follow the usual reviewing process, they will probably form their first impression in an hour or two, then either throw it away or get down to serious study. Therefore, it is vital to get feedback about the "feel" of the document before we commit to it and invite world-wide scrutiny. What I am suggesting is that we get a few intentionally uneducated reviewers to tell us what they think of the document as a trial run. The document must stand on its own merit. Dealing with prejudices/ ignorances of readers is part of the game. The politics of reaching consensus in X3J14 are of little concern to a potential new user trying to decide if the language is useful. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior scientist at Harris Semiconductor, and adjunct professor at CMU. I don't speak for them, and they don't speak for me.
koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/16/90)
> Phil - IF you do go to that much trouble, we will be happy to make > the GEnie Forth Real-Time Conference facility available for this > discussion. ... I would also recommend distribution to the X3J14 > committee members. Thanks for your kind offer. I would probably structure the "experiment" in two stages. The first stage would be simply to record the observations of the external reviewer. This would actually be the key result, and should be disseminated in an appropriate manner. The second stage would be to pick selected external reviewers for further discussion (perhaps on a Real-Time Conference) to elucidate problem areas. My question about whether the X3J14 committee as a whole would listen is: would a bona fide CS expert/language designer giving constructive criticism result in corrective changes to the standard, or just be dismissed with a comment such as "he just doesn't understand?" How about an application engineer who actually has to use it? It probably is not worth his time or mine unless there is enough interest that we actually get requests to do this. Also, if we can't dig up at least 3-5 reviewers, there clearly is not enough interest in the community to bother with this (and our sample will be too small to be convincing). Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior scientist at Harris Semiconductor, and adjunct professor at CMU. I don't speak for them, and they don't speak for me.
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/18/90)
In <9912@pt.cs.cmu.edu>, koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: > > It was probably a mixture of seeing the mess the 79/83 function > changing caused, the fact that words currently in use will be left > floating, and an appreciation for the politics at work > within the standards committee. The point is that he reacted > with amusement at the situation/solution instead of with > a comment such as "that sounds like a reasonable course of action". I wonder if there is the unstated assumption of the existance of a reasonable course of action is realistic. On of PJ Plauger's Computer Language columns early this year talked about the lessons learned from the X3J11 process. One of those lessons was to divide the kinds of behaviour into different bins: Strictly-specified, implementation-defined, and undefined (there may have been one or two more, I'm doing this from memory). The value of explicitly allocating things to those catagories is in the information conveyed. If everything is "undefined" or "implementation- defined" then you gain little. However, those catagories don't have to be empty either. Its useful to know what to avoid. I still wonder if existing practice and the ANSI constraints leave room for what would traditionally be considered "reasonable course of action". > it.) An important function of the standard is to show that the > language is mature and ready for consideration by folks who have > been waiting on the sidelines for any number of reasons. If they > pick up a copy of the standard (and perhaps Starting Forth) and > *perceive* it as hopelessly compromised, or otherwise faulty, that is > probably the last they (or many people they advise) will think of Forth. I suppose we have different ideas about what "hopelessly compromised" means. It seems to me like you'll not do much better with the conflicting goals of "don't break existing code and the existing code is contradictory" and "get everyone to reach a consensus". I had asked someone (I think Dennis Ruffer) a while ago why ANSI was approached at this particular time. I get the feeling from your posts that the ANSI standard should be a formal approval of an existing wide-spread de facto standard. Clearly this isn't the case. I also get the feeling that you feel the constraints on the standard, as dictated by ANSI, are sabotaging the effort? -Doug ----- 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