In article <DAG.94Aug17114745@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:
>On the issue of digraphs and terminals:
>
> So the issue is not just whether systems are capable of displaying
> particular characters at all, but whether they can do it conveniently.
>
>I think most people have overlooked that the main problem is not the
>displayed character set -- it's the keyboard.

Dag, I think that you are simply wrong.

I started this thread talking about digraphs and keyboards.

(Being the parochial American that I am, I had always *assumed* that
the *real* issue which prompted digraphs had to do with keyboards.)

It wasn't until one of your fellow Europeans corrected me (and told me
that the *real* issue had to do with display screens) that I tried to
point out that either way, there is absolutely ZERO hard data which
would tend to support the belief that either the presence or absence
of digraphs in the language would make any difference whatsoever, other
than to a vanishingly small percentage of the people who will ever
read *or* write C++ code.

(Well, I misspoke.  The presence of digraphs in the standard *will*,
of course, also make a difference to all the unfortunate implementors,
documentors, authors, and lecturers who will now be saddled with the
job of covering *this* kitchen sink also.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <32tb7bINN6si@marble.summit.novell.com>, jls@summit.novell.com (-mlc-+Schilling J.) writes:

> Don't IBM mainframe compilers support substitution digraphs where necessary?
> A decade ago the IBM 370 Pascal compiler supported (. and .) for [ and ],
> (* and *) for { and }, and @ for ^ (if I remember correctly).  It uglified
> the code, but there was never a need to hex edit or write the code on a
> different platform.

Those digraphs and substitutions are part of ISO Pascal.

-- Olaf Weber

In article <rfgCupr1x.6xn@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:

> In article <DAG.94Aug17114745@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:

>> On the issue of digraphs and terminals:

>> [ ark@tempel.research.att.com (Andrew Koenig) writes: ]

>>> So the issue is not just whether systems are capable of displaying
>>> particular characters at all, but whether they can do it conveniently.

>> I think most people have overlooked that the main problem is not the
>> displayed character set -- it's the keyboard.

> Dag, I think that you are simply wrong.

> I started this thread talking about digraphs and keyboards.

And how: this is what you said <rfgCttp3t.1rs@netcom.com>

: Then there's the ultimate example of ``design by INTERNATIONAL committee''
: in this era of PC (political correctness) where the entire planet has to
: bend over backwards just to prove that we're not prejudiced against lazy
: left-handed Latvians.  I'm speaking (of course) about digraphs.  Aren't
: you just so relieved to know that left-handed Latvians won't be forced to
: occasionally use their right-hands to hit certain keys (or to hit three
: keys rather than two) when typing C++ programs?  I sure am.

> (Being the parochial American that I am, I had always *assumed* that
> the *real* issue which prompted digraphs had to do with keyboards.)

> It wasn't until one of your fellow Europeans corrected me (and told me
> that the *real* issue had to do with display screens) that I tried to
> point out that either way, there is absolutely ZERO hard data which
> would tend to support the belief that either the presence or absence
> of digraphs in the language would make any difference whatsoever, other
> than to a vanishingly small percentage of the people who will ever
> read *or* write C++ code.

Exactly who came up with screens being the main problem?  Having read
what Bjarne Stroustrup wrote on the issue (in the ARM and D&E, and the
EUUG Notices article), I assumed that the problem had to do with ISO
646 fonts.

My point was that readability of code is very important.  While it
would be unpleasant, I can accept having to use `control-meta-bang' or
`??!' to get a `|', provided that I do get a `|' on the screen, rather
than `   ' or `??!'.

The problem is that many national ISO 646 fonts don't have characters
that are needed to display C++ programs without bigraphs.  This means
that they are not available on both keyboard and screen.  This is why
your dig at "lazy left-handed Latvians" was decidedly unfair.  It has
since been mentioned that the same holds for some EBCDIC variants (no
`!') and for certain terminals (3270 compatible, no `['and `]').  This
means that the problem occurs even in the USA.

To me, the most interesting aspect of the debate has been the reactions
of several people who should be beneficiaries of the proposal: they
clearly indicate that the problem has largely ceased to exist.

> (Well, I misspoke.  The presence of digraphs in the standard *will*,
> of course, also make a difference to all the unfortunate implementors,
> documentors, authors, and lecturers who will now be saddled with the
> job of covering *this* kitchen sink also.)

The trouble for authors and lecturers consists of little more than:
"Oh, by the way, you can write these symbols also like this."

Far more troublesome is what <rfgCuprqK.85w@netcom.com> implies: that
implementors don't yet know how to handle bigraphs, and that the
standard doesn't provide guidance that should be there.

So we have an (apparently simple) feature introduced in June 1991 that
is still not implemented in most (any?) compilers, and by now rapidly
becoming obsolete because most of the equipment it was meant for has
fallen out of use.  It would not suprise me that if bigraphs make it
into the Standard many compilers won't support them regardless, and
that they'd be removed at the first revision.

To sum it up: trigraphs did too little, bigraphs are too late.

-- Olaf Weber

In article <DAG.94Aug17114745@bellman.control.lth.se>
dag@control.lth.se (Dag Bruck) writes:

|> On the issue of digraphs and terminals:

|>  So the issue is not just whether systems are capable of displaying
|>  particular characters at all, but whether they can do it conveniently.

|> I think most people have overlooked that the main problem is not the
|> displayed character set -- it's the keyboard.

Good point.  I'd forgotten that.

|> Even if my display (PC, workstation or terminal) can easily change
|> character sets and mappings between codes and glyphs, the keyboard is
|> much harder to swap.  I usually have to choose between a US keyboard
|> without national characters (which is convenient for writing C++), or
|> a Swedish keyboard (which obviously is more convenient for writing
|> Swedish -- I do that too occasionally).  Either gives access to
|> "magic" characters by various Alt-sequences.

In principal, you can map the keyboard differently in different
windows under X.  I've yet to succeed (under Solaris 2.2, maybe
someone from SunSoft knows the answer).  On a PC (at least on my
Compaq), there is a command to change the keyboard encodings; I use my
PC exclusively for correspondance, and am constantly switching between
French and German, as it is impossible to type one language with the
keyboard set for the other.  And since I use the MKS Korn shell,
rather than the standard MS-DOS command interpreter, I generally
switch to the US key layout anytime I have to issue more than one or
two commands in the shell.

Of course, when you do this, the key engraving no longer corresponds
to the characters.  A good motivation to learn touch typing.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <rfgCupr1x.6xn@netcom.com> rfg@netcom.com (Ronald
F. Guilmette) writes:

|> (Well, I misspoke.  The presence of digraphs in the standard *will*,
|> of course, also make a difference to all the unfortunate implementors,
|> documentors, authors, and lecturers who will now be saddled with the
|> job of covering *this* kitchen sink also.)

Hmmm...  For the implementors, it shouldn't represent more than about
a quarter of an hours extra work, supposing modern compiler
technology.  As for the documentors, authors and lecturers, they will
no doubt handle it like they did trigraphs, and ignore it
completely:-).

The cost *is* minimal.  Until Dag reminded me about the keyboards, I
thought that the win was even smaller.  Now I am not so sure.  I
believe that some Scandinavian countries have laws requiring specific
keyboard layouts, on ergonomic grounds.  If this is true, it would
mean that it is illegal to have a machine with a keyboard having the
{,},[, etc. in any convenient location.

Even without the legal aspect, it is difficult to imagine a keyboard
that had *all* of the necessary keys for both the local langauge(s)
and C++ in convenient locations.

I have not personally had problems, because most modern machines have
software programmable keyboards, and I touch type (on German, French
and US keyboards, at least).  I also use English language messages for
most of my personal tools, and have separate message files for any
software that I might deliver.  So I never have to mix C++ and the
local language in the same file, and can leave the editor and change
the keyboard layout when I change files.  But I'm not sure my
experience is universal here.  The computer science curriculums of
most European universities does not include a course in touch typing
on a US keyboard.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <32tb7bINN6si@marble.summit.novell.com>,
-mlc-+Schilling J. <jls@summit.novell.com> wrote:
>
>Don't IBM mainframe compilers support substitution digraphs where necessary?
>A decade ago the IBM 370 Pascal compiler supported (. and .) for [ and ],
>(* and *) for { and }, and @ for ^ (if I remember correctly).  It uglified
>the code, but there was never a need to hex edit or write the code on a
>different platform.
>
>--
>Jonathan Schilling
>Novell, UNIX Systems Group (UNIX System Laboratories)
>jls@summit.novell.com

I'd rather write code on another platform as long as the transfer was easy
enough.  I'd rather never have to see (. for [ if I don't have to, and
coding on a UNIX box and ftp'ing the files was better (for me) than having
to look at that crap.  Of course, I tried to write portably so that I could
compile on the UNIX box first, but as it turned out, the IBM compiler wasn't
really ANSI conformant.

Stephen Gevers
sg3235@shelob.sbc.com

In article <KANZE.94Aug18213659@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
>In article <rfgCupr1x.6xn@netcom.com> rfg@netcom.com (Ronald
>F. Guilmette) writes:
>
>|> (Well, I misspoke.  The presence of digraphs in the standard *will*,
>|> of course, also make a difference to all the unfortunate implementors,
>|> documentors, authors, and lecturers who will now be saddled with the
>|> job of covering *this* kitchen sink also.)
>
>Hmmm...  For the implementors, it shouldn't represent more than about
>a quarter of an hours extra work...

Phrases come to mind like `Talk is cheap' and `That's easy for you to
say.'

I think you are ommiting one important thing from your calculations James,
i.e. how long it takes to figure out what translation phase these things
are supposed to be processed in.

If you really think it'll only take 15 minutes for you to implement it,
then how about hacking digraphs into the GNU g++ compiler.  (I'm sure the
Cygnus boys would thank you for it.)  Go ahead.  I'll wait online while
you do it....

(tick tick tick)

Done yet?

:-)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

>>>>> "James" == James Kanze US/ESC 60/3/164 #71425
>>>>> <kanze@us-es.sel.de> writes:

James> I believe that some Scandinavian countries have laws requiring
James> specific keyboard layouts, on ergonomic grounds.

I don't think such a law exists in Denmark.  If it does, everybody
(including this state university) ignores it.

James> The computer science curriculums of most European universities
James> does not include a course in touch typing on a US keyboard.

If the university has US keyboards, digraphs are of no help.

In article <CuH8K1.L5s@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig) writes:
>In article <rfgCuGw0p.n1D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> What percentage of the world's total population of CRT screens are currently
>> unable to display the characters which C++ diagraphs act as replacements for?
>
>That's the wrong question.  The right question is:
>
> Is there any country where a significant fraction of the
> CRT screens are currently unable to display the characters
> substituted by C++ digraphs?
>
>I believe the answer to that question is yes...

OK.  Let's just pretend for a moment that I buy that assertion.  (I don't
really, and I still think my ORIGINAL question is the important one, but
since no one seems to have an answer for *that* question, we might as well
press on.)

What country (or countries) are you talking about and what ``significant
fraction'' of CRT screens are involved?

Has ANYBODY got any real hard data on this whole topic, or is it all just
smoke, mirrors, and personal (potentially biased) opinions?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

ark@tempel.research.att.com (Andrew Koenig) writes:

>There is another issue that is probably even more important, and that is
>that on a very large number of European computer systems, the characters
>that we see as { } | ~ and a few others display as *letters*.  Yes,
>it is possible to get those systems to display { } etc. but only by
>special pleading.  So the issue is not just whether systems are capable
>of displaying particular characters at all, but whether they can do it
>conveniently.

Your argument was surely true in the years 1965 - 1983, but tell me:

  a) Which hardware has been produced in the past 10 years
     with the properties you described and which is used in
     programming environments?

  b) Which computer hardware is used more than 12 years?

  c) Do programmers (not end users that never see C code) use anything
     else than PCs or modern Workstations with ISO 8859-1 fonts since
     1990?

  d) Is the number of digraph users expected to be larger than
     about 1/1000 of all C users?

  e) When will digraphs for lowercase letters be introduced in
     C? In many countries, telex terminals have been used for
     programming in the 1960s, and these don't support lowercase
     letters. ISO should also take this very seriously! ;-)

>ISO takes problems like this very seriously.

Committees that work on the 100% consens principle and not on the 99%
consens principle tend to produce standards that are pretty far from
real live, especially in such complex areas like information technology.
Remember OSI protocols? :-)

>> Am I being an `ugly american' just because I think that there should have
>> been a real problem before *all* C++ compiler implementors, most C++ CASE
>> tool vendors, many C++ book authors, and many C++ teachers and students
>> should have been burdened with this ``solution''?

I don't think so and normally as an internationalization nut I'm pretty
sensitive to US-centric views. But this isn't one.

>In the eyes of the people who will benefit from digraphs, you
>are being at least as troublesome as they are in yours.

Is there anyone here reading this who has considered the fact that
C uses all ASCII/ISO 646 IRV characters a personal daily real live problem
after say Jan 1, 1994?

Sorry, but I haven't been convinced yet that such an anachronism
like support of the ISO 646 least common subset is worth to be
introduced in 1995. I had hoped that we are currently migrating from
ISO 8859-1 and the DOS charset to 16-bit Unicode instead.

Markus
(living in a country, were terminals
without {}[]^~|\ were VERY popular until
the early 1980s when CP/M was my favorite
operating system. Yes, some peoples still
have these in their private museums. ;-)

---
Markus Kuhn, Computer Science student -- University of Erlangen,
Internet Mail: <mskuhn@cip.informatik.uni-erlangen.de> - Germany
WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>

I would say that a significant number of terminals in the
United states are unable to display the complete C
language character set.

If you have worked with an IBM (or compatible) mainframe,
it is likely that you used a 3270 compatible terminal. Most
of these terminals do not include "[" or "]" in their
character set.

In article <32oj3o$bc0@fsgi01.fnal.gov> b91926@fsgi01.fnal.gov (David
Sachs) writes:

|> I would say that a significant number of terminals in the
|> United states are unable to display the complete C
|> language character set.

|> If you have worked with an IBM (or compatible) mainframe,
|> it is likely that you used a 3270 compatible terminal. Most
|> of these terminals do not include "[" or "]" in their
|> character set.

But are 3270 terminals actually being used to edit C++ text?  (I pity
the programmer if they are.)
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <32lgmuE8nv@uni-erlangen.de>
mskuhn@cip.informatik.uni-erlangen.de (Markus Kuhn) writes:

|> ark@tempel.research.att.com (Andrew Koenig) writes:

|> >There is another issue that is probably even more important, and that is
|> >that on a very large number of European computer systems, the characters
|> >that we see as { } | ~ and a few others display as *letters*.  Yes,
|> >it is possible to get those systems to display { } etc. but only by
|> >special pleading.  So the issue is not just whether systems are capable
|> >of displaying particular characters at all, but whether they can do it
|> >conveniently.

While I basically agree with your argument, in the interests of
accuracy:

|> Your argument was surely true in the years 1965 - 1983, but tell me:

|>   a) Which hardware has been produced in the past 10 years
|>      with the properties you described and which is used in
|>      programming environments?

At least one major German computer manufacturer was manufacturing
terminals with the 7 bit local variant of ISO 646 as late as 1988, and
using them for program development.  (On the other hand, when I
visited friends there about three years ago, I don't remember seeing
very many of them around.)

|>   b) Which computer hardware is used more than 12 years?

|>   c) Do programmers (not end users that never see C code) use anything
|>      else than PCs or modern Workstations with ISO 8859-1 fonts since
|>      1990?

This is the real question.  Although I think 1990 is perhaps a bit
early, given the speed things are going, the question should be: will
there be any programmers using anything other than PCs or workstations
in the year 2000?

(What about Mac's?  I suppose people develope code on them.  What
codeset do they use?)

    [...  ]
|> >> Am I being an `ugly american' just because I think that there should have
|> >> been a real problem before *all* C++ compiler implementors, most C++ CASE
|> >> tool vendors, many C++ book authors, and many C++ teachers and students
|> >> should have been burdened with this ``solution''?

|> I don't think so and normally as an internationalization nut I'm pretty
|> sensitive to US-centric views. But this isn't one.

|> >In the eyes of the people who will benefit from digraphs, you
|> >are being at least as troublesome as they are in yours.

|> Is there anyone here reading this who has considered the fact that
|> C uses all ASCII/ISO 646 IRV characters a personal daily real live problem
|> after say Jan 1, 1994?

|> Sorry, but I haven't been convinced yet that such an anachronism
|> like support of the ISO 646 least common subset is worth to be
|> introduced in 1995. I had hoped that we are currently migrating from
|> ISO 8859-1 and the DOS charset to 16-bit Unicode instead.

|> ---
|> Markus Kuhn, Computer Science student -- University of Erlangen,
|> Internet Mail: <mskuhn@cip.informatik.uni-erlangen.de> - Germany
|> WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>

I've intentionally left the .sig, to point out the domain.  I think it
interesting (or curious) to note that much of the criticism of
digraphs comes from the very people they are supposed to help.  I
might add that I am a passionate supporter of internationalization;
see my .sig to see why.

I think digraphs were a very good idea when they were proposed (1989).
I wish I had had them then (or even a few years earlier).
Regretfully, they didn't get implemented then.  Today, I really
couldn't care.  (They don't bring much, but from what I understand
about compiler construction, they are probably the cheapest extension
on the list.  If the standards committee really wants to help us, then
standardize an iostream equivalent to the X/Open positional parameters
in printf.  Or at least, do something to make such an extension
possible.

--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

On the issue of digraphs and terminals:

 So the issue is not just whether systems are capable of displaying
 particular characters at all, but whether they can do it conveniently.

I think most people have overlooked that the main problem is not the
displayed character set -- it's the keyboard.

Even if my display (PC, workstation or terminal) can easily change
character sets and mappings between codes and glyphs, the keyboard is
much harder to swap.  I usually have to choose between a US keyboard
without national characters (which is convenient for writing C++), or
a Swedish keyboard (which obviously is more convenient for writing
Swedish -- I do that too occasionally).  Either gives access to
"magic" characters by various Alt-sequences.

There are also "mixed" keyboards which are equally inconvenient for
both camps.  People familiar with APL keyboards will know the problem.
As a matter of fact, the keyboard of the Swedish Toshiba T5100 I'm
sitting in front of now supports both, including Alt-sequences, plus
an additional numeric keypad mode.  The distribution is as follows:

 # Symobls/key  # Keys

  1  18
  2  11
  3   5
  4  10
  5   2
  6   1

counting only the main keyboard, not the function keys.  It natuarally
supports the corresponding character sets, but I must reboot to swap
(I think).
     -- Dag

In article <KANZE.94Aug16200937@slsvhdt.us-es.sel.de>,
James Kanze US/ESC 60/3/164 #71425 <kanze@us-es.sel.de> wrote:
>In article <32oj3o$bc0@fsgi01.fnal.gov> b91926@fsgi01.fnal.gov (David
>Sachs) writes:
>
>|> If you have worked with an IBM (or compatible) mainframe,
>|> it is likely that you used a 3270 compatible terminal. Most
>|> of these terminals do not include "[" or "]" in their
>|> character set.
>
>But are 3270 terminals actually being used to edit C++ text?  (I pity
>the programmer if they are.)
>--
>James Kanze                                  email: kanze@lts.sel.alcatel.de
>GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
>Conseils en informatique industrielle --
>                              -- Beratung in industrieller Datenverarbeitung

I have had to do some programming in MVS.  Because of the problem described
above ( and the fact that we have ftp capability on our mainframe ), I did
my editting on a UNIX machine and transfered the source to the mainframe.
There were some minor situations where all that transfering seemed to be
a bit extreme..so I put the "[" and "]" chars in using the hex editor!
The only problem with that is that those chars don't shift when the 3270
terminal is in insert mode.

We don't yet have a C++ compiler for MVS because there isn't enough demand
for C++ among mainframe coders that would warrant the huge cost associated
with mainframe purchases.

Stephen Gevers
sg3235@shelob.sbc.com

In article <32t34o$m3@ritz.cec.wustl.edu> sg3235@shelob.sbc.com writes:
:>In article <32oj3o$bc0@fsgi01.fnal.gov> b91926@fsgi01.fnal.gov (David
:>Sachs) writes:
:>
:>|> If you have worked with an IBM (or compatible) mainframe,
:>|> it is likely that you used a 3270 compatible terminal. Most
:>|> of these terminals do not include "[" or "]" in their
:>|> character set.
:>
:I have had to do some programming in MVS.  [...]
:There were some minor situations where all that transfering seemed to be
:a bit extreme..so I put the "[" and "]" chars in using the hex editor!
:The only problem with that is that those chars don't shift when the 3270
:terminal is in insert mode.

Don't IBM mainframe compilers support substitution digraphs where necessary?
A decade ago the IBM 370 Pascal compiler supported (. and .) for [ and ],
(* and *) for { and }, and @ for ^ (if I remember correctly).  It uglified
the code, but there was never a need to hex edit or write the code on a
different platform.

--
Jonathan Schilling
Novell, UNIX Systems Group (UNIX System Laboratories)
jls@summit.novell.com

In article <CuB8GB.960@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:
rfg> Oh yes, and before I forget.  I do have just one other small question...
rfg>
rfg> Since you have made a point of stressing ``readability'' (as the motivation
rfg> for diagraphs), I'm curious...  What percentage of the world's total popu-
rfg> lation of CRT screens are currently unable to display the characters which
rfg> C++ diagraphs act as replacements for?
>
>Since a CRT will display whatever the signal it is fed dictates, 100%
>should be able to display those characters.

That is a very clever evasion, but I'm still waiting for an answer.

What percentage of the world's total population of CRT screens are currently
unable to display the characters which C++ diagraphs act as replacements for?

If the percentage is zero (or very very close to zero) then that would
tend to support the view that diagraphs are utterly pointless, and that
there were put into the language strictly for political reasons (because
someone felt the need to make a political statement) and not because they
solved any actual (technical) problem.

So where are the proponents of diagraphs now?  Where are their statistics
to prove that diagraphs are needed?

Am I being an `ugly american' just because I think that there should have
been a real problem before *all* C++ compiler implementors, most C++ CASE
tool vendors, many C++ book authors, and many C++ teachers and students
should have been burdened with this ``solution''?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

The real problem is tying C (or Ada) to any specific character set. In these
days of modern times we like to think ASCII is the only character set, and
that characters are always eight-bits. Algol 60 and 68 sidestepped this
issue by letting the implementor map symbols into a specific character set.
It's simple to write a fsm to translate one implementation into another.

comp.std.c++?? Yuch. This language is way overdefined.
--
Dan Qualye/Ludwig von Plutonium in '96! | smryan@netcom.com PO Box 1563
A President we deserve.                 |             Cupertino, California
A Vice-President he deserves.           | (xxx)xxx-xxxx               95013

In article <rfgCuGw0p.n1D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> What percentage of the world's total population of CRT screens are currently
> unable to display the characters which C++ diagraphs act as replacements for?

That's the wrong question.  The right question is:

 Is there any country where a significant fraction of the
 CRT screens are currently unable to display the characters
 substituted by C++ digraphs?

I believe the answer to that question is yes.  Indeed, for precistly that
reason, the C and C++ committees spent quite a bit of time in shuttle
diplomacy so that both languages would use the same set of digraphs.

There is another issue that is probably even more important, and that is
that on a very large number of European computer systems, the characters
that we see as { } | ~ and a few others display as *letters*.  Yes,
it is possible to get those systems to display { } etc. but only by
special pleading.  So the issue is not just whether systems are capable
of displaying particular characters at all, but whether they can do it
conveniently.

ISO takes problems like this very seriously.

> Am I being an `ugly american' just because I think that there should have
> been a real problem before *all* C++ compiler implementors, most C++ CASE
> tool vendors, many C++ book authors, and many C++ teachers and students
> should have been burdened with this ``solution''?

In the eyes of the people who will benefit from digraphs, you
are being at least as troublesome as they are in yours.
--
    --Andrew Koenig
      ark@research.att.com

>>>>> "Andrew" == Andrew Koenig <ark@tempel.research.att.com> writes:

Andrew> Is there any country where a significant fraction of the
Andrew> CRT screens are currently unable to display the characters
Andrew> substituted by C++ digraphs?

This is still not the right question, there are two problems:

- We should only count platforms used for programming.

- The current fraction is less interesting than the expected fraction
  at the time when (if ever) C++ compilers supporting digraphs become
  installed on those platforms.

We should also consider:

- What fraction of the programmers on those platforms will actually
  use digraphs, knowing that it will make their code less readable for
  people on other platforms, or even their own platform after their
  next hardware or os upgrade?

BOGUS ANALYSIS AHEAD, press `n' now to skip...


Under the assumption that made-up numbers are better than no numbers,
here is an answer to the question:

- Sweden is the country where the national 7-bit character set is most
  common (they are the only ones using it on Usenet).

- There are 80.000 Swedish programmers (1% of the population).

- In 1989, 20% of the programmers used platforms with the national
  7-bit character set as standard (all PC's counted as 8-bit).

- Since 1990, the fraction of programmers using the national 7-bit
  character set has been cut into half every year.  (Well, it _has_
  decreased dramatically the last couple of years).

- It will typically take 5 years before these programmers get a C++
  compiler (The compilers aren't available yet, and these people are
  not generally at the cutting edge of the technology).

- Half of these programmers will start using digraphs (Who cares if
  other people can read your code?)

Applying these number, we get that 0.01% of the Swedish programmers (8
persons) use digraphs, for an average of 2 years each.

This is, incidentally, far less than the number of left-handed Latvian
programmers.