gnu@hoptoad.uucp (John Gilmore) (01/26/88)
I too have read the 'Revised "noalias" words' from Dave Prosser, and
still think it's a bad idea. While there might be a place in ANSI C
for things that can't be explained clearly in a paragraph, there should
be no place for things that can't be explained clearly in a page.
And no place at all for things where the three people who claim to
understand it are unable to explain it, over a protracted period,
to the rest of us. (Or are those three people going to write *all*
the ANSI C compilers?)
In particular, the words used do not make clear what the difference is
between a "virtual object" and an "actual object", nor do they describe
how C operators (such as =, *, or +) operate differently on virtual
objects versus actual objects. It also seems to be confused between
lvalues and handles -- or maybe I am. It spends most of a page telling
us that the handles in an expression come from the identifiers that are
in the expression. It seems to indicate that the handle in the lvalue
*(foo = x) is from foo, not from x. (It might be right!) It says that
pending values must be synchronized when "the storage of the object
declared by the noalias handle" is not guaranteed to exist any more.
However, neither handles nor lvalues ever declare objects. It seems to
imply that not only can a given real object have multiple virtual
objects associated with it, but a single *handle* to a real object can
end up having several virtual objects, some of which might have pending
stores and thus different values ("If one or more of the virtual
objects of a noalias handle..."). How it decides which one to give you
when you reference the lvalue that started all this is problematic at
best. The whole definition seems to be tied to function calls as a
kind of sequence point that is "more important" than other sequence
points; in fact, the only things required by the whole three pages
occur at function calls and returns (the rest is all optional). And
"The behavior of a program that depends on a specific implementation
choice [of virtual versus actual objects] is undefined"...if they
thought this sentence made it clear that strcpy() of overlapping areas
in the same array is "undefined", but nonoverlapping areas in the same
array is "defined", I wish they would explain just how.
I could go on but it should be clear that the wording is
incomprehensible. If you thought the standard was unreadable before,
this is a step in the wrong direction.
I think if Cray or somebody wants to vectorize C, they should make a
nonstandard version of C and try it for a few years, not mangle our
almost-standard with this kind of unexplored randomness.
Here's an interesting exchange between Richard Stallman, who had to
understand the draft standard to implement it, and Dave Prosser, who
seems to be editing it. They were discussing a problem that I
encountered where the shiny new ANSI CPP rules about recursive macro
definitions broke some useful, existing code that nests macro names in
arguments to other macros and expands them inside by putting
parentheses and arguments after them. This worked in 90% of the
cases but one particular combination made it fail. (What broke was Sun's
latest RasterOp implementation, BTW, quite an impressive piece of work.)
RMS:
> Why don't you pass the problem on to your friends on the committee?
> At least you can enjoy their consternation.
>
> On second thought, please don't. The current spec may not be clean,
> but at least it was implementable. Who knows what they would come up
> with next?
Dave:
> I don't know in what spirit the last paragraph was intended, but
> thanks for the humor. At least you see that the current specification
> can be implemented without real problems. I seem to regularly handle
> calls trying to understand the current draft and complaints that it
> is totally unimplementable! I guess I'll save this concern for a
> rainy day, or a inspiration...
RMS:
> Having implemented the current draft, I agree nearly completely with those
> callers. It is not impossible to implement, but it is difficult,
> and it is very difficult to figure out exactly what is to be implemented.
> I'm not surprised people think it is unimplementable.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
"Watch me change my world..." -- Liquid Theatregwyn@brl-smoke.ARPA (Doug Gwyn ) (01/26/88)
In article <3932@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >And no place at all for things where the three people who claim to >understand it are unable to explain it, over a protracted period, >to the rest of us. I don't think that's really a valid criterion; if you apply it as stated, virtually everything in C wouldn't belong in the Standard, judging by the misinformation in this newsgroup and elsewhere from people who claim to understand things. It is also not a fair criterion; for example, I was trying to explain the concept minimally, just as a follow-up to my announcement about changes voted in at the last meeting. I don't actually like "noalias" much, although (partly as Response Document editor) I feel obliged to defend the X3J11 Committee's position. Hence I'm not the best proponent of this feature. It is also possible that don't really understand "noalias" or that I'm just not good at explaining things. It is even possible that "the rest of you" aren't very good at understanding things! :-) Having said all that, I'll agree that it does appear to me that the additional utility of having "noalias" is perhaps not worth the effort of specifying it fully and accurately or of understanding the specification. It certainly is more intricate than almost any other concept in the proposed Standard. The issue of difficulty in implementing the specifications correctly doesn't bother me much. It is unlikely that there are more than a few hundred people in the world who could reasonably be expected to produce a high-quality C implementation anyway, and most of the ones who will be (or are) attempting to implement the ANSI C specifications either are on the Committee or have sufficient contacts with Committee members who can answer questions about some of the subtler points. If you can suggest improvements in any of the wording in the proposed Standard, I would urge that they be sent in as comments during the next formal public review period, which should start soon. It would help to make the final Standard as intelligible as possible. (Even stating that you find some topic confusing, unclear, or ambiguous would be helpful.)
pardo@june.cs.washington.edu (David Keppel) (01/26/88)
[ difficulty of implementing 'noalias' at the last minute ] Back to an older suggestion: it might be easier (and better defined ?-) (politically, not technically) to define pragma() behavior than noalias noalias char *cp; vs. pragma(noalias) char *cp; While the latter is certainly more verbose, I think that it changes the language less, and of course it can be taken out (in existing C compilers, for backwards compatability) for _all_ pragmas with #define pragma(x) Or if "pragma" is already taken, consider "hint", which accurately describes what's going on . . . ;-D on (Well it sure *sounded* sound at the time) Pardo
henry@utzoo.uucp (Henry Spencer) (01/26/88)
> ... most of the ones who will > be (or are) attempting to implement the ANSI C specifications either are > on the Committee or have sufficient contacts with Committee members who > can answer questions about some of the subtler points. I understand this position but don't sympathize. If the content is complete and unambiguous but so poorly phrased that it is necessary to consult with a Committee member to understand it, then the document is inappropriate as a standard. If the content is incomplete or ambiguous, which I would say is the case, then things get much worse. Are the words of a Committee member to be considered official? If not, then we have the situation where asking different people might get different answers -- the standard is ambiguous, pure and simple, and there is no way for an implementor to be happy with it. If the words ARE official, then an individual Committee member is essentially issuing revisions to the standard by private mail! I don't know about ANSI, but IEEE strictly forbids anything of the sort, on the grounds that standards are made by a consensus process followed by open publication and revisions should be made the same way. (This is not just a question of preferred behavior; the rule was made to head off major legal dangers.) Doug, please check ANSI's rules; I strongly suspect that this appeal to consultation with committee members cannot be used as an official excuse. > If you can suggest improvements in any of the wording in the proposed > Standard, I would urge that they be sent in as comments during the next > formal public review period, which should start soon. It would help to > make the final Standard as intelligible as possible. (Even stating that > you find some topic confusing, unclear, or ambiguous would be helpful.) Unless a miracle happens, my formal comments during the public review will state that "noalias" is confusing, unclear, ambiguous, and a clear case of inappropriate invention of unproven features by the Committee, and that the correct way to improve the wording of the proposed Standard is to delete "noalias" completely, since there is NO simple, clear, well-proven way of solving the admittedly-serious aliasing problem. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
karl@haddock.ISC.COM (Karl Heuer) (01/27/88)
In article <6723@agate.BERKELEY.EDU> mwm@eris.UUCP (Mike (My watch has windows) Meyer) writes: >[Rather than using "noalias", whose addition will likely cause another review >period,] I'd suggest going back to something suggested here earlier - let >"register" do the job. Arghh! It's not bad enough that "static" and "break" have two meanings each? If, as you suggest, the addition of "register arrays" is sufficient to allow vector optimizations, then the same suggestion with "noalias" replacing "register" will also suffice -- and will not overload the keyword. Whether this countersuggestion is equivalent to the current proposed "noalias" (in the intersection of the languages defined by both) is anybody's guess. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
jal@oliveb.olivetti.com (Benjamin G. Golding) (01/28/88)
In article <583@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > I have tried several times to read the description of 'noalias' that > was posted here. I couldn't. Maybe it's just me, [...] No, it's not just you - I am having just as much trouble. I consider myself an average C programmer (some people will disagree with this) and I tend to find myself writing less new code and maintaining more that written by others; I seem to remember reading that this is what most programmers do ("The Psychology of Computer Programming" by Weinberg). What I am worried about is changing someone else's code where they have used "noalias" and inadvertantly creating a heck of a lot of trouble for myself. When I add this to the fact that I am unlikely to ever use this "feature," it just doesn't seem worth a damn thing. If you want to do vectorisation, do it properly - don't just tag it onto an existing language and lumber its users with the complexity. Ben Golding. Olivetti (Ivrea). ...!oliveb!icodap!taylor
wendt@arizona.edu (Alan Lee Wendt) (01/28/88)
In article <7181@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > > The issue of difficulty in implementing the specifications correctly > doesn't bother me much. It is unlikely that there are more than a few > hundred people in the world who could reasonably be expected to produce > a high-quality C implementation anyway, and most of the ones who will > be (or are) attempting to implement the ANSI C specifications either are > on the Committee or have sufficient contacts with Committee members who > can answer questions about some of the subtler points. The issue is "difficulty of understanding the specifications", not "difficulty of implementing them". Right now the only people who need to understand the specs are the implementors. If the above paragraph were correct, there would only have been a few hundred volumes of K&R or Harbison/Steele sold in the world, because only the implementors would be interested in understanding the specification. Specifications are not just for implementors. If the spec is confusing Stallman, it will eventually confuse anybody who tries to use the language. Can I get the phone numbers of some of the members of the committee, so that if my program blows up, I can call them up to check on my use of "noalias"? Alan Wendt
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/30/88)
In article <1988Jan26.123817.5188@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >If the content is complete >and unambiguous but so poorly phrased that it is necessary to consult with >a Committee member to understand it, then the document is inappropriate as >a standard. If the content is incomplete or ambiguous, which I would say >is the case, then things get much worse. I agree with what you say. I was trying to address the issue of how tricky it can be to get the implementation right, even if the specs were clear. >I strongly suspect that this appeal to consultation with committee >members cannot be used as an official excuse. Of course not; I wasn't trying to offer it as an official excuse, just as one rebuttal to the difficulty-of-implementation issue (which is not necessarily a problem that needs fixing). By the way, after there is an official published standard, the X3J11 technical committee continues to meet (less often), to respond to requests for clarification and interpretation of the standard. >the correct way to improve the wording of the proposed Standard is to >delete "noalias" completely, since there is NO simple, clear, well-proven >way of solving the admittedly-serious aliasing problem. That may indeed be a correct observation, in which case the committee needs to be persuaded that it is, after which they'll have to decide how to fix it (which may be your proposal or some other).
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/30/88)
In article <13826@oliveb.olivetti.com> jal@oliveb.olivetti.com (Benjamin G. Golding) writes: >What I am worried about is ... >... it just doesn't seem worth a damn thing. ... Your objection seemed quite reasonable, and I hope you'll flesh it out a bit and send it in as a formal public comment.