🚀 go-pugleaf

In article <1016@zinn.MV.COM> mjv@objects.mv.com (Michael J. Vilot) writes:
>...there seems to be sincere desire to do better than trigraphs as a way to
>satisfy the legitimate needs of national character sets.

I would have hoped that X3J16 would not be re-hashing all the dumb ideas
that X3J11 carefully considered and carefully rejected for good reasons.
However, given that Bjarne was one of the handful of people pushing this
specific dumb idea, I suppose I should have expected it...

The right answer to national character sets is ISO Latin 1 or equivalent,
not ridiculous contortions in language syntax that *every* compiler
*everywhere* then has to be able to parse.  Trigraphs were a mistake.

Remind me to submit a proposal to X3J16 to change C++ so that it can be
typed using only the intersection of a Model 26 keypunch and an ASR-33.

>The availability of templates and exceptions has a substantial impact on how I
>design libraries in C++.  I would hope that the library portion of the C++ 
>standard would make the best use of the language.  Yet we have little ``prior
>art'' in libraries using these features ...

Hmm.  Now that is a sticky problem.  I fear the obvious answer is to try to
produce upward-compatible extensions, so that existing code works but newer
code can take advantage of the new facilities.  Awkward.  See what you get
when you start adding language features? :-) :-) :-)

This sort of thing actually did come up a little bit in the C library, for
example in the type of the parameter to ctime().  X3J11 opted not to mess
with historical practice.  But they weren't facing a problem anywhere
near the size of this one.
-- 
"I'm not sure it's possible            | Henry Spencer at U of Toronto Zoology
to explain how X works."               |  henry@zoo.toronto.edu   utzoo!henry

In article <1990Nov23.211727.2802@zoo.toronto.edu> henry@zoo.toronto.edu
(Henry Spencer) writes:
> In article <1016@zinn.MV.COM> mjv@objects.mv.com (Michael J. Vilot) writes:
> >...there seems to be sincere desire to do better than trigraphs as a way to
> >satisfy the legitimate needs of national character sets.
> 
> I would have hoped that X3J16 would not be re-hashing all the dumb ideas
> that X3J11 carefully considered and carefully rejected for good reasons.
> However, given that Bjarne was one of the handful of people pushing this
> specific dumb idea, I suppose I should have expected it...
> 
> The right answer to national character sets is ISO Latin 1 or equivalent,
> not ridiculous contortions in language syntax that *every* compiler
> *everywhere* then has to be able to parse.  Trigraphs were a mistake.

Yes.  Strange, isn't it, that the Danes are so in love with seven-bit
character sets?  We've seen it in C, we're seeing it in POSIX.  Looks as
though it's making trouble in C++.

I'm sorry if that sounds like an ethnic slur, but, as Henry says,
equipment which talks using an 8-bit character set such as ISO Latin 1
is an obvious (minimum) requirement for program development.  Any
software shop which shackles its staff to inadequate hardware deserves
every bit of productivity that it fails to get out of them.  Those who
suggest that the standards community should spend its time on
grandfathering in support for coded character sets already superseded
because of their clear inadequacies stand in grave danger of fashioning
standards for the past, not for the future.  While there might have
been a case for doing this with C, a language which, beacuse of the
time of its development, had a number of dependencies on a particular
seven-bit coded character set (ASCII), it seems to me to be
counter-productive to expend much effort on providing support for
variants of that old character set in a new language -- C++.


I hope that was clear.  Now let me muddy it a bit.  While I can see no
reason for the development of C++ software to be carried out on
inadequate hardware, it may be that the resulting programs have to
support an installed base of inadequate hardware.  Such is life.  I'm
talking about cross-development tools running on new hardware, but
churning out binary code for old.  No reason why the problem
shouldn't be solved that way.  Hell, it's not a new idea.  (Whereas
trigraphs were -- and a poor one, at that.)  How long has COBOL had an
environment division?  Not that anybody uses it much, I'll grant you.
But then, like trigraphs, maybe it just seemed a good idea at the time...
-- 
Dominic Dunlop

domo> I'm sorry if that sounds like an ethnic slur, but, as Henry says,
domo> equipment which talks using an 8-bit character set such as ISO Latin 1
domo> is an obvious (minimum) requirement for program development.  Any
domo> software shop which shackles its staff to inadequate hardware deserves
domo> every bit of productivity that it fails to get out of them.

I dunno... Maybe trigraphs were a good idea, they are not too hard to
implement in a compiler, but they are absolutely *miserable* to use.  Maybe
the idea was to make using them hurt so much that people would upgrade their
obsolete systems? :-):-):-)
--
======================================================================
domain: tahorsley@csd.harris.com       USMail: Tom Horsley
  uucp: ...!uunet!hcx1!tahorsley               511 Kingbird Circle
                                               Delray Beach, FL  33444
+==== Censorship is the only form of Obscenity ======================+
|     (Wait, I forgot government tobacco subsidies...)               |
+====================================================================+

>>>>> On 23 Nov 90 21:17:27 GMT, henry@zoo.toronto.edu (Henry Spencer) said:

Henry> The right answer to national character sets is ISO Latin 1 or
Henry> equivalent, not ridiculous contortions in language syntax that *every*
Henry> compiler *everywhere* then has to be able to parse.  Trigraphs were a
Henry> mistake.

Simple question (I think):

Does ISO Latin 1 address oriental languages like Kanji?  (Come to think of it,
does trigraphs?)
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
uunet!cimshop!davidm				Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <1990Nov25.161506.9659@tsa.co.uk> domo@tsa.co.uk (Dominic Dunlop) writes:
>In article <1990Nov23.211727.2802@zoo.toronto.edu> henry@zoo.toronto.edu
>(Henry Spencer) writes:
>> I would have hoped that X3J16 would not be re-hashing all the dumb ideas...
>> The right answer to national character sets is ISO Latin 1 or equivalent,
>
>equipment which talks using an 8-bit character set such as ISO Latin 1
>is an obvious (minimum) requirement for program development.

Do you have an ISO Latin 1 keyboard?  Do you suggest I could use one?

ISO Latin 1 solves some of the output problems (ever considered why
it's called ISO Latin *1*?), but it does not solve the input problem.

I believe the current proposal by Bjarne Stroustrup has important
merits by combining readability and writability, compared to
trigraphs. I also know several people that prefer kerywords like
'or' instead of '|' even though they have a US keyboard.

Dag Michael Br\"uck (who has his own problems, as you can see)
--
Department of Automatic Control		E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118				Phone:	+46 46-108779
S-221 00 Lund, SWEDEN			Fax:    +46 46-138118

In article <CIMSHOP!DAVIDM.90Nov26181052@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>Henry> The right answer to national character sets is ISO Latin 1 or
>Henry> equivalent...
>
>Does ISO Latin 1 address oriental languages like Kanji?  (Come to think of it,
>does trigraphs?)

Neither addresses the issue at all.  ISO Latin 1 and its friends deal fairly
well with the small-alphabet languages -- ISO Latin 1 in particular gets very
nearly all the Roman-alphabet languages, although it has to punt to its
siblings for Greek or Cyrillic alphabets -- but they're 8-bit character sets
that haven't a prayer of coping with the large-alphabet languages.  Trigraphs
are just a minimal way of writing C entirely in the ISO 7-bit character set
(of which ASCII and most other 7-bit codes are supersets).

The syntactic perversions that the Danes are pushing don't deal with the
matter either, by the way.  All they do is make trigraphs a bit less ugly.
X3J11 didn't think this was worth the trouble, and neither do I.
-- 
"The average pointer, statistically,    |Henry Spencer at U of Toronto Zoology
points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu   utzoo!henry

Perhaps one should support ISO 2022 for switching between the 8859 (ISO latin) character sets as well?

-- 
     ____       ____    ____    ____   ____   birger@ii.uib.no
    /   /   /  /   /   /   /   /      /   /   
   /   /   /  /   /   /   /   /      /   /    Birger A. Wathne
  /---    /  /---    /  __   /---   /---      Blekenberg 14
 /    /  /  /    /  /    /  /      /    /     N-5037 SOLHEIMSVIK
/____/  /  /    /  /____/  /____  /    /      tlf: +47-5-20 00 62

In article <1990Nov27.143307.8086@lth.se> dag@control.lth.se (Dag Bruck) writes:
>Do you have an ISO Latin 1 keyboard?  Do you suggest I could use one?
>ISO Latin 1 solves some of the output problems (ever considered why
>it's called ISO Latin *1*?), but it does not solve the input problem.

Of course not.  Neither does ASCII or any other character set.  In all
cases, there has to be some sort of mapping between the 60-odd keys of
your keyboard and the rather larger internal character set.  Furthermore,
this mapping has to be locale-specific to some degree, since the set of
most-commonly-needed characters will vary.

I don't understand why you want your programming language to try to
solve the problem of keyboard mappings.

>I believe the current proposal by Bjarne Stroustrup has important
>merits by combining readability and writability, compared to
>trigraphs...

Nobody advocates using trigraphs as a way of writing programs; they are
strictly a data-interchange format.  Please find a real argument, not
this strawman.

> I also know several people that prefer kerywords like
>'or' instead of '|' even though they have a US keyboard.

sed 's/ or /|/g'

does it without any changes to the language, if you really care so little
about the readability of the text to your successors (who will be expecting
programs written in C).
-- 
"The average pointer, statistically,    |Henry Spencer at U of Toronto Zoology
points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu   utzoo!henry

tom@ssd.csd.harris.com (Tom Horsley) writes:

>Maybe trigraphs were a good idea, they are not too hard to
>implement in a compiler, but they are absolutely *miserable* to use.

Trigraphs are not all that easy to implement efficiently, either; they
really do slow down the compiler.  The scanner, which dominates compiler
front-end time, requires 3-character lookahead, not to mention
complicating the interpretation of end-of-line for finding the ends of
macros.  Our original straightforward implementation of trigraphs
caused a 15% slowdown of the compiler front end.  We spent quite a bit
of time finding an efficient way to handle them, and reduced the
overhead to about 5%.  Please note this affects every program ever
compiled, even ones which contain no trigraphs.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com

>>>>> Regarding Re: design by committee (was: templates and exceptions in g++?); steve@taumet.com (Stephen Clamage) adds:

steve> Our original straightforward implementation of trigraphs
steve> caused a 15% slowdown of the compiler front end.  We spent quite a bit
steve> of time finding an efficient way to handle them, and reduced the
steve> overhead to about 5%.  Please note this affects every program ever
steve> compiled, even ones which contain no trigraphs.

I don't want to sound too insulting here, but I would say you have a seriously
flawed design. I worked on a ANSI C scanner as a sort of academic exercise
while trying to fully understand the way the macro processor works, and my
scanner has no additional overhead to speak of even if you do use trigraphs.

The key to making this work fast is recognizing that you have to examine
each character in the buffer to classify it as you go along anyway. I used a
<ctype.h>-like array that marked "interesting" characters and embedded the
check in a getc()-like macro. The macro normally returns the next character
using inline code, but if an interesting character shows up it calls a
subroutine to do additional processing.  A '\0' character is interesting
because I might have to re-fill the buffer, A '\\' character is interesting
because it might be followed by a newline and both of them will have to be
squeezed out (remember that a backslash followed by a newline has always
been a special sequence you had to check for even before question-mark
question-mark came along - the overhead for tri-graphs is no worse than
this).  With tri-graphs, '?' is now also an interesting character.  Sticking
an extra check for the ?? tri-graph sequence in the subroutine that is only
invoked when an interesting character comes along does not cost that much
extra (unless you have a LOT of question marks in your source code). The
tricky part is making sure you go ahead and fill the buffer if you are
within 4 characters of the end and handling the case of a line terminated by
??/ followed by a newline.

When I do find something like a tri-graph or a \ newline, I squeeze them out
and replace them with what really belongs there. The routine knows where the
current token starts in the buffer, so it just shifts it right to take up
the slack, then it returns the proper character and scanning continues
normally. This allows me to handle the phases of translation which process
tri-graphs and backslash newlines transparently in the GetNextCharacter
macro while I am also busting up the source into tokens.  I can also leave
the tokens in the input buffer without wasting the time copying them around
unless I have to do something like squeeze out a trigraph.
--
======================================================================
domain: tahorsley@csd.harris.com       USMail: Tom Horsley
  uucp: ...!uunet!hcx1!tahorsley               511 Kingbird Circle
                                               Delray Beach, FL  33444
+==== Censorship is the only form of Obscenity ======================+
|     (Wait, I forgot government tobacco subsidies...)               |
+====================================================================+

With respect to Japanese character sets :

There are four character sets used in Japan :

	Kanji : 2000+ common characters, plus more uncommon ones. Most adults
	can read and write Kanji. Every "character" stands for a complete
	word or concept.

	Hiragana (sp?) : about 150 characters, I think. Used to phonetically
	spell out words that are native to the Japanese language.

	Katakana : again, about 150 characters. Used to phonetically spell
	out words that have been imported into Japanese from foriegn languages.

	Most young children know the two kana character sets, as do most
	adults of course. Once you've learned to write in katakana and hiragana
	you can write like a third grader. Few adult Japanese would wish to.

	Kanji symbols are derived the Chinese alphabet. Katakana and Hiragana
	are simplifications of Kanji symbols.

	"Romanji" : the Roman alphabet. I'm not sure when, who, et cetera.

doconnor@titania.srg.UUCP (Dennis O'Connor x4982 room 6-230N) writes:


>With respect to Japanese character sets :

>There are four character sets used in Japan :

>	Kanji : 2000+ common characters, plus more uncommon ones. Most adults
>	can read and write Kanji. Every "character" stands for a complete
>	word or concept.

>	Hiragana (sp?) : about 150 characters, I think. Used to phonetically
>	spell out words that are native to the Japanese language.

>	Katakana : again, about 150 characters. Used to phonetically spell
>	out words that have been imported into Japanese from foriegn languages.

The character sets I have seen has 86 katakana and 83 hiragana characters.
But then I am talking about "encoded character sets" like 8859-1 etc,
not the "character set repertoire" which is an abstract kind of guy.

There are to my knowledge several encoded character sets in usage in Japan today, including:

    X0201: an 8 bit character set including almost all of ASCII
           (except backslash which is a Yen sign) and the katakana
           characters.
    X0208: a 16 (14) bit character set consisting of matematical
           characters, latin, hiragana, katakana, cyrillic and greek
           and some box drawing characters, then the large section
           of kanji characters which are ordered in two parts,
           the more common ones in pronounciation order (Japanese 
           order!) and then the less frequent ones in radical/stroke
           order. Some 6500 kanji characters are included.

    X0212: A new 16 (14) bit character set with a lot of the latin, 
           cyrillic, greek and kanji characters not in X0208.

    X0201, X0208 and X0212 are published by JIS - the Japanese
    standards institute, but it seems like the 16 bit sets are
    not widely implemented, maybe because that demands a quite big 
    character set.

    Shift-JIS: 8/16 bits character set which is used on PCs.
           Normal ASCII characters are just in 8 bits, and some 
           katakana characters are also in just 8 bits. Then some
           of the characters are used as escape sequences to provide
           about 3000 kanji characters.

    EUC:   Enhanced UNIX Code: This is the above character sets
           and others encoded with ISO 2022 techniques.
           So it is possible to shift in and out between several
           character sets.

Keld Simonsen