osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/06/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Wed, 6 Mar 85 Volume 4 : Issue 4
Today's Topics:
\e (2 msgs)
\l
ranges in case labels (2 msgs)
----------------------------------------------------------------------
Date: Tue, 5 Mar 85 00:51:59 est
From: ihnp4!seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: \e
To: ihnp4!homxa!osd7
Much as I would like to have '\e' as ESC in C (and I may even have
munged it into some C compilers in the past), I don't think it really
belongs in standard C. Whereas '\t', '\f', '\r', et al. all have
interpretations as cursor motions in the host character set, '\e'
tends to represent the special escape character for the ANSI standard
escape codes. This is, in fact, '\033'. To let it change to the Escape
character in some obscure character set such as TTS-6 or EBCDIC would
break just those programs that the feature is meant to support.
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
------------------------------
Date: 04 Mar 85 11:55:33 N (Mon)
From: ihnp4!seismo!mcvax!guido
Subject: \e
To: homxa!osd7
After having heard a few viewpoints on \e in strings, the conclusion should
be obvious: \e does not belong in C. When I first saw it proposed, it looked
good (even Mark Horton thought so). But in fact, putting \e in the language
only encourages putting terminal dependencies in programs that should use
curses or termcap. Packages *implementing* a curses-like driver usually
benefit from the encapsulation that an explicit #define ESC 033 provides.
As I see it, there are the following possible uses for the ASCII ESC character
(in order of perceived importance):
1. As first character of a multi-character 'escape sequence' sent
to a character-oriented peripheral (most often a terminal).
This is utterly non-portable (not even to another terminal
connected to the same computer).
2. As input character from the keyboard; on many terminals, ESC
has little function but a prominent place on the keyboard,
so programs needing yet another special key tend to use ESC
for all sorts of special functions (examples: vi; Emacs; TOPS-like
command completion; even many IBM-PC programs use it). On modern
terminals, function keys often also send sequences starting with
ESC, conflicting with the above use. Here it is probably advisable
not to 'hardwire' the character used but to allow the user to choose
a character (sequence). Anyway, ESC should occur only once in the
whole program.
3. Like 1 but sent to another, cooperating program (often via a pipe).
Here there is no reason why some character built into the language
should be picked (one could argue that a character which is
guaranteed to have no other meaning would be nice; however, ESC
already has too many meanings for this purpose...). Both programs
should #include a file which #defines the ESCape character used.
(I don't even know if there are real examples of this...)
--
Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
guido@mcvax.UUCP
------------------------------
Date: 4 Mar 85 23:59:54 CST (Mon)
From: ihnp4!utzoo!henry
Subject: \l
To: ihnp4!cbosgd!std-c
Note one consideration: if, as John McNamee suggests, we simply
define C in terms of the standard character set -- ASCII (well, ISO if
you're going to be fussy) -- then we do not need \l, because \n is
definitely that character. If you look at the ASCII standard, you'll
find words along the lines of "if there is a single newline character,
it shall be LF, which is then called `newline'". The C environment
quite definitely assumes that this convention is being used, in which
case the pure linefeed function does not exist. The use of code 012
for the newline function is not a Bell Labs eccentricity, it is (one
option of) an international standard.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Tue, 5 Mar 85 02:01 EST
From: Paul Schauble <ucbvax!Schauble@MIT-MULTICS.ARPA>
Subject: ranges in case labels
To: cbosgd!std-c@BERKELEY
I think what y'all are aiming at is a construct that is used in several
other languages, a different kind of case statement:
DO CASE
CASE expression1
statement
statement
CASE expression2
statement
statement
ENDCASE
When run, the system evaluates expression1, then expression2, etc. For
the first TRUE found, it executes the following statements, then
continues after the ENDCASE. Sometimes the language provides an
OTHERWISE or DEFAULT, other times you just say CASE .TRUE.
Note that the expressions can be any logical expressions.
This is very useful, and I miss it in C. However, I don't think that
adding it is within the charter of the standard committee. At the
moment, I'd rather work on getting rid of six character externals.
(Speaking of which....A while back I proposed a hashing method that
would require no changes to the loader, minimal changes to the compiler,
and removes the restriction. I've seen several flames, but none has
shot the method down. I still think that this proposal removes the need
to specify 6 character externals. Can anyone supply a good reason why
not??)
[
The proposed hashing method did not appear in mod.std.c, so I don't
have record of it. Perhaps you mailed to INFO-C directly. An
interesting proposal was sent to mod.std.c by Ken Arnold.
Only objections related to debuggers. It's all in the archives.
-- Mod --
]
------------------------------
Date: Tue, 5 Mar 85 17:56:30 pst
From: fortune!wdl1!wunder
Subject: ranges in case labels
To: fortune!cbosgd!std-c
As I remember, switches already do exactly this in Mesa. Perhaps
someone from Xerox could speak from experience? They should have a
good feel for the utility of the thing, and the ease of implementation.
Also, the PL/1 SELECT can either be a simple case, or a sort of
guarded command thingy, where each case has its own logical expression
(the first true one is the branch taken). I used that once to switch
on variable length opcodes in a machine simulator, but it wasn't
really necessary. I masked the word down in each compare, but a
second level of branching would have worked just fine.
walter underwood
UUCP: fortune!wdl1!wunder
ARPA: wunder@FORD-WDL1
Phone: (415) 852-4769
------------------------------
End of mod.std.c Digest - Wed, 6 Mar 85 08:04:11 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.