rbutterworth@watmath.UUCP (Ray Butterworth) (12/17/86)
In article <5458@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > >The standard should specify the internal representations > >for the predefined escape sequences for implementations that use the > >USASCII or Latin 1 alphabets, > So long as we don't mandate ASCII/ISO character sets, this is > infeasible. > > >Page 91, line 46ff. Note that, in a Latin 1 environment, the ispunct() and > >isspace() functions should test for the non-breaking space at 0xA0. > No particular character set is required, so we can't make such > remarks in the standard itself. Perhaps the Rationale should > give such examples. > > A lot of proposals for new features have been rejected in an > attempt to keep the size of the language and its environment > relatively small. (This attempt hasn't been totally successful, > but it's certainly a worthwhile goal.) Therefore, please don't > interpret failure to adopt a suggestion as necessarily implying > that there is something wrong with the idea, although often > there is (in which case the response should point out what). One of my biggest gripes with the proposed standard is the things it deliberately doesn't describe. Certainly there are many things that are totally inappropriate for some machines, and the standard should not mandate their existence, but there is no reason that the standard can't at least say something about them. Let's take a trivial example. The committee has refused to define "\e" as the string escape sequence for the ASCII character ESC on the grounds that many implementations (i.e. IBM) won't be using ASCII and so this would be impossible for them to implement. That is certainly true. But it's no reason for not putting into the standard something of the form "for implementations using the ASCII character set, '\e' will be the ESC character". Similarly the standard could define appropriate escapes for other common character sets such as Latin 1. There are many such instances where something that would be useful in some implementations has been omitted from the standard because it cannot reasonably be required in all implementations. This means that each individual implementation that wants such a feature is going to have to invent its own method (as the standard allows), and that many of these implementations will be needlessly different. I would really like to see, either directly in the document itself, or as an appendix, descriptions of such non-required extensions. The Rationale is not the place for it (I don't believe that the Rationale will be published as an official part of the final standard will it?). Since they are optional features, this won't affect those compilers that can't reasonably implement them, but for the others it will greatly simplify things and make programs that much more portable (isn't that what this standard is supposed to be for in the first place?).
barmar@mit-eddie.MIT.EDU (Barry Margolin) (12/18/86)
The way I have seen non-required features handled in other ANSI
standards is in an annex (their word for appendix, it seems) containing
additional recommendations that are not part of the standard. For
example, in the ANSI standard for keyboards, the official standard only
specifies the location of the keys for printing characters, the space
bar, the return key, and the control and shift modifiers. The annex
recommends that if you provide a way to type control characters, that
you use at least a specified set of key combinations (Control-2 for
0/00, Control-A thru Control-Z for 0/01 thru 1/10, Control-3 thru
Control-7 for 1/11 thru 1/15, Control-8 for 7/15), although you are not
restricted from using additional key assignments (unfortunately, some
terminal manufacturers didn't notice this last clause, and don't allow
the use of Control-[ thru Control-_, for example).
Putting things in the Rationale may also be acceptable. The Rationale
is normally included as an annex in the standard. You can learn alot
from Rationales, by the way; in the ASCII standard, for example, the
Rationale explains that it was a goal that each of A-Z, a-z, and 0-9 be
contiguous and ordered. The new 8-bit character sets, unfortunately,
are forced to drop the idea of making all the alphabetic characters
contiguous (it was more important that USASCII be a subset).
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmar