Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c,comp.std.internat
Subject: Re: What is a byte
Message-ID: <26863@sun.uucp>
Date: Sun, 30-Aug-87 18:06:36 EDT
Article-I.D.: sun.26863
Posted: Sun Aug 30 18:06:36 1987
Date-Received: Mon, 31-Aug-87 05:38:06 EDT
References: <218@astra.necisa.oz> <142700010@tiger.UUCP> <2792@phri.UUCP> <866@mcgill-vision.UUCP>
Sender: news@sun.uucp
Lines: 55
Xref: utgpu comp.lang.c:3891 comp.std.internat:190

> Why do we all assume that C must be twisted and bent to fit the
> international environment?

Gee, *I* don't assume that.  Making the language support comments in foreign
languages doesn't seem too hard; with some more work (and cooperating linkers -
I suspect the UNIX linker can handle 8-bit characters in symbol names) you
could even have it support object names in foreign languages (but then again, a
hell of a lot of object names are in a foreign language NOW; quick, in what
natural language is "strpbrk" a word?).  It might even be possible to support
*keywords* in foreign languages - I'm told there are compilers for some
languages that do this - but the trouble with C is that a lot of "keywords" are
routine names, and it'd be kind of a pain to put N different translations of
"exit" into the C library.

As for making programs written in the language support foreign languages,
there are no massive changes to C required here, either.  Most of the support
can be done in library routines.  It is not *required* that "char" be increased
in size beyond one byte to support other languages, nor would it be *required*
that "strcmp" understand the collation rules for all languages.

> Are there *no* computer languages designed by Japanese for a Japanese
> environment (or Chinese or Arabic or Hindi or etc)?

Not that I know of.  There may be some, but I suspect they are VERY minor
languages.

> Perhaps it is time for one.

The trouble is that "one" wouldn't be enough!  You'd need languages for
Japanese *and* Chinese *and* Korean *and* Arabic *and* Hebrew *and* Hindi
*and*... if the languages were really designed for *that particular* language's
environment.

If this were the *only* way to write programs that can handle those languages,
you would have to write the same program N times over for all those
environments.  If you wanted your system to be sold in all those different
environments, you would either have to supply compilers for *all* those
languages or make the compiler suite be something selected on a per-country
basis.  I can't see how this would do anything other than impose costs that far
outweigh the putative benefits of such a scheme.

> (Not that I have anything against extending C to such an environment; I
> like C too.  But it's beginning to look as though the result of such
> attempts "ain't C", to coin a phrase.)

No, the "ain't C" phrase is properly applied only when something contradicts
some C standard, or perhaps when it grossly violates assumptions made by
reasonable C programmers.  There may be some problems with changing the mapping
between "char"s and bytes (problems caused by C's unfortunate conflation of the
notion of "byte", "very small integral type", and "character" into the type
"char" - they should have been separate types), but I see no contradiction or
gross violation in the internationalization proposals I've seen.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com