Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!cmcl2!brl-adm!adm!dsill@NSWC-OAS.arpa
From: dsill@NSWC-OAS.arpa (Dave Sill)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language
Message-ID: <12073@brl-adm.ARPA>
Date: 2 Mar 88 15:14:06 GMT
Sender: news@brl-adm.ARPA
Lines: 60

>In article <12059@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
>>The time is ripe for a more flexible "Code for Information
>>Interchange".  How many more years/decades will we be forced to make
>>do with a lousy 95 symbols: all predefined, most vastly overloaded?
>
>ISO extended the character set several years ago.  It has also been
>extended (in more than one way) to accommodate Kanji characters.

Yes, I've read the ISO standards you refer to (ISO 646, ISO 2022, ISO
2375, ISO 6429), they're sitting on my desk right now.  ISO 646 is
like ASCII, except that it allows the construction of "composite
graphic characters".  This is great, the sequence "=<CR>/", for
example, could be displayed as a "not-equal" symbol.  Unfortunately,
ISO 646 doesn't say what these composite characters look like, so it
could be displayed as a ham sandwich, or as an equals sign with the
first character of the line replaced with a /.  Real useful.

ISO 2022 covers extensions to ISO 646 using alternate graphical
character sets, escape sequences, and 8-bit codes.  But it says
nothing about what a given pattern looks like in a given character
set.  It does, however, maintain interchangeability between 7-bit and
8-bit standard and extended environments, which is A Good Thing.

ISO 2375 is a procedure for registering ISO 2022 escape sequences.
This seems like a step in the right direction.  Too bad they don't
have such a procedure for the alternate graphical character sets.

ISO 6429 contains control functions for display devices.  It's
interesting to note that although this standard has been available
since '83, only one vendor that I'm aware of claims conformance
(Canon, in their laser printers.  If there are others you're aware of,
I'd like to know).  Not exactly overwhelming acceptance.

The real problem, though, is not so much in the code itself as it is
in the display devices, terminals, keyboards, et cetera, that are used
to enter and display these characters.  Even if the ISO standards
defined the code for a right-pointing-arrow, what key or key-
combination would have to be used to enter one?  How could it be
displayed?

>C source can be in EBCDIC (for example); it seems inappropriate to
>require either a specific character code "standard",

So you're saying we can't extend the set of graphical characters we
use in languages because someone might not have the characters
available?  What about trigraphs, or a similar mechanism?

>or an even
>larger set of characters than it already uses, given the amount of
>trouble with this we've already had.

The trouble is not that we have too many characters available, it's
that we have too few!  For example, if we had a left-pointing-arrow
character that could be used for assignment, the whole == versus =
problem would not exist.

=========
The opinions expressed above are mine.

"The limits of my language mean the limits of my world."
					-- Ludwig Wittgenstein