Flush bits from standard

[Rem@IMSSS]

As somebody said, the semantics of bit attributes on characters is dependent
on the implementation, therefore no portable program can be written to
effectively use them. (Probably same is true of font attributes.)
In general, when a feature can't effectively be used by portable programs,
it shouldn't be considered part of the portable standard. The only exception
would be something like OPEN which is so absolutely essential to all
implementations that it's inconceivable an implementation wouldn't provide
it, and many parts of its description CAN be standardized. But in the main,
something that can't be effectively used by portable programs shouldn't
be in CLtL.

Somebody complained about the need to store arbitrary keystrokes in characters.
I don't see how this is an argument for portable bit attributes. The keyboards
on each machine are different, and thus different numbers of bit attributes
will be needed on each machine, and their semantics will be different too.
(What one machine calls META will be called EDIT on another, one machine
will have a mouse-interrupt bit while another won't. How can a program be
written to insist that HYPER-META-Q is the command for quitting a failing
grammar production in an interactive natural-language-parser program,
if my machine never heard of HYPER and doesn't have enough bits to represent
all the different commands even by juggling them around? VM/CMS doesn't even
have CONTROL or META bits, but has more than 128 basic keys on the keyboard
(treating "a" and shift-"a" i.e. "A" as different, treating <PA2> and
alt-<PA2> i.e. <fieldmark> as different, treating <PF3> and shift-<PF3>
i.e. <PF15> as different).) I vote for stripping bit&font attributes out
of the language, but would accept carefully making them as vague as possible
(just like namestrings and pathnames for OPEN) and documenting just the
hook in the manual, saying the details are implementation dependent,
so nobody will try to write portable code using the attributes directly,
but rather will put the attribute-hacking code in a separate system-dependent
file/module.

The manual should of course everywhere distinguish between where it exactly
specifies the semantics and where it merely specifies the syntax and
general idea of semantics but leaves the detailed semantics up to the
implementation, with the latter kept to the minimum.
<Opinion of REM, currently PSL programmer>
-------