franka@mmintl.UUCP (Frank Adams) (03/29/88)
[I have cross-posted this from comp.lang.c++ to comp.lang.c, comp.lang.ada, and comp.lang.misc, with followups directed to comp.lang.misc. Responses relating to one of these languages in particular should be directed to the appropriate place.] In article <2249424b:4311@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >I'll state this as a more general proposed rule for the 'what should we hack >into C++ next' game: > > OPTIMIZATION HINTS SHOULD BE PROPOSED AS OPTIONAL PRAGMAS, IF AT ALL I have trouble with pragmas. The problem is not, perhaps, intrinsic; but it is very much in evidence in every language where I have seen them. The problem is that each vendor is allowed to define their own pragmas, with no guarantee that someone else won't use the same pragma for something entirely different. If pragmas are going to be used, they should be as much part of the language standard as the syntax. A vendor may choose to follow or ignore whatever pragmas they choose to; but *if* a pragma is not ignored, it should be used as specified. To expedite the introduction of new pragmas, there should be a central repository of pragma definitions. Compiler writers should be able to define a new pragma, and within a few weeks have it officially recorded in the repository. The name may not be the one requested, but the functionality should be. (A review committee to go over the pragma and suggest improvements is a tempting idea, but should not be permitted to slow down the process.) -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
John_M@spectrix.UUCP (John Macdonald) (04/01/88)
In article <2789@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >[...] > >In article <2249424b:4311@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >>I'll state this as a more general proposed rule for the 'what should we hack >>into C++ next' game: >> >> OPTIMIZATION HINTS SHOULD BE PROPOSED AS OPTIONAL PRAGMAS, IF AT ALL > >I have trouble with pragmas. The problem is not, perhaps, intrinsic; but it >is very much in evidence in every language where I have seen them. The >problem is that each vendor is allowed to define their own pragmas, with no >guarantee that someone else won't use the same pragma for something entirely >different. > >If pragmas are going to be used, they should be as much part of the language >standard as the syntax. A vendor may choose to follow or ignore whatever >pragmas they choose to; but *if* a pragma is not ignored, it should be used >as specified. > >To expedite the introduction of new pragmas, there should be a central >repository of pragma definitions. Compiler writers should be able to define >a new pragma, and within a few weeks have it officially recorded in the >repository. The name may not be the one requested, but the functionality >should be. (A review committee to go over the pragma and suggest >improvements is a tempting idea, but should not be permitted to slow down >the process.) You can have it both ways, if the syntax of pragma is chosen carefully. Allow statements of the two forms: pragma <std-type> <rest of statement> pragma specific <compiler> <comp-type> <rest of statement> Where <std-type> is a "standard optional extension" that is defined by the language standard-setting body. Compiler-specific extensions are also allowed, but must be explicitly marked as such using the second format. A compiler can then choose to implement or ignore pragmas defined by other compilers (just as they can implement or ignore "standard" pragmas). If a specific pragma is supported by many other compilers, then it is a strong candidate for inclusion as a standard pragma in the next revision of the language. An additional benefit is that anyone who uses a non-standard pragma is forced to be aware that they are doing something that is not portable. Many people only read the manual for the implementation that they use, and often are not aware of whether a language feature in their implementation is part of the standard language. This could reduce the number difficulty of porting a program that was coded for local use and later discovered to be of wider utility. -- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
franka@mmintl.UUCP (Frank Adams) (04/05/88)
In article <530@spectrix.UUCP> jmm@spectrix.UUCP (John Macdonald) writes: > pragma <std-type> <rest of statement> > > pragma specific <compiler> <comp-type> <rest of statement> I like it! Now, as long as the compiler writers can all choose distinct names for their compilers ... -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
mouse@mcgill-vision.UUCP (der Mouse) (04/17/88)
>>> OPTIMIZATION HINTS SHOULD BE PROPOSED AS OPTIONAL PRAGMAS, IF AT ALL >> I have trouble with pragmas. [...] The problem is that each vendor >> is allowed to define their own pragmas, with no guarantee that >> someone else won't use the same pragma for something entirely >> different. This is the price you pay for using pragmas. Each vendor must be free to define their own pragmas, for they may be doing something different from what anyone else is doing. >> If pragmas are going to be used, they should be as much part of the >> language standard as the syntax. A vendor may choose to follow or >> ignore whatever pragmas they choose to; but *if* a pragma is not >> ignored, it should be used as specified. The problem with this is that it requires the standards committee to think of everything that a programmer may conceivably want to tell an optimizer, without knowing anything about the optimizer. I have no confidence whatever in anyone's ability to guess what vendor X will want to do in the way of optimization tomorrow. The whole point of pragma is that it allows compilers an escape route to let them do things we haven't thought of. The moment you try to formalize what's allowed in a pragma and what isn't, you lose this benefit. > You can have it both ways, if the syntax of pragma is chosen > carefully. Allow statements of the two forms: > pragma <std-type> <rest of statement> > pragma specific <compiler> <comp-type> <rest of statement> > Where <std-type> is a "standard optional extension" that is defined > by the language standard-setting body. This is not too unreasonable, though I would prefer to have two different keywords rather than overloading "pragma". > An additional benefit is that anyone who uses a non-standard pragma > is forced to be aware that they are doing something that is not > portable. As "pragma" is currently defined, this is true for anyone using a pragma at all. So this is a non-point. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu