In article <Cuz8DM.77v@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:
>
>> [D]igraphs are at best problematic because any programmer who is
>> in the unenviable position of *having* to use them will still be
>> unable to do such simple things as including files whose names
>> happen to contain any of the characters `[', `]', `{', or `}'.
>
>It seems quite likely to me that a programmer who _has_ to use
>bigraphs because of system limitations won't encounter files with
>those characters in their names.

I guess you folks over on your side of the Big Pond don't tend to work
in hetrogeneous networked environments, eh?

>If he does, he'll have to use trigraphs, as in all strings.

In other words digraphs are only (at best) a partial solution to the
(postulated, but still undemonstrated) ``problem'' anyway, eh?

--

-- 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 <rfgCvG47t.DFw@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
> In article <Cuz8DM.77v@cwi.nl> olaf@cwi.nl (Olaf Weber) writes:

>> It seems quite likely to me that a programmer who _has_ to use
>> digraphs because of system limitations won't encounter files with
>> [`[', `]', `{', or `{'] in their names.

> I guess you folks over on your side of the Big Pond don't tend to work
> in hetrogeneous networked environments, eh?

Reality check: if you _have_ to use digraphs because your system lacks
those characters, _every_ program on that system will have trouble
asking for files whose names contain them.  Usually a naming
convention is introduced in the environment that avoids those
characters, and the C/C++ programmer can use the same convention for
include files.

>> If he does, he'll have to use trigraphs, as in all strings.

> In other words digraphs are only (at best) a partial solution to the
> (postulated, but still undemonstrated) ``problem'' anyway, eh?

As 19.2.4 of the ARM puts it: "The trigraph support in 16.2 is still
available and necessary for putting missing characters such as { into
strings and character constants."  So it was well known that they are
not a complete solution.

With respect to their usefulness, it seems to be limited to "legacy"
equipment, often mainframes.  The members of the standards committees
(C as well as C++) are in a better position than most of us (including
me) to decide whether there is enough of a problem to warrant the
introduction of digraphs.  When it came to the vote in mid-1991,
digraphs were accepted.

If you are so dead-set angainst digraphs, I can only suggest that you
try and find the minutes of the meetings in which they were discussed
to see if your objections were addressed.  If they were not, you can
then try to re-open the discussion in the C and C++ committees.

By the way, how about the introduction of `not' and `not_eq' for `!'
and `!='?  These were added because some EBCDIC variants lack the
exclamation mark.  Are these "evil" too?

-- Olaf Weber

>>For the second time: who of you actively codes using trigraphs or
>>seriously intends to use digraphs, should they become available?

>I also asked this here about 2 weeks ago. No one so far has mailed me
>that he/she is personally interested in having digraphs in the standard.
>It seems to be a quite theoretical problem that is to be solved ... ;-)

I now have found one (1) person who _used_ to use trigraphs.

The perhaps more interesting count: grand total of current multigraph
users located is still holding at 0ul.

Even when accounting for only a small certaing percentage of C++
programmers reading comp.std.c++, those having "digraph" in their
KILL files and those too busy to say "yup, we need digraphs" --
the actual need for this stuff doesn't seem overwhelming.

Sadly, the standard committee seems to be buying the line that
there are millions of non-US programmers desperate for this feature.
So it goes.
         ++sja

In article <33n3evE41m@uni-erlangen.de>,
Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de> wrote:
>sja@gamma.hut.fi (Sakari Jalovaara) writes:
>
>>For the second time: who of you actively codes using trigraphs or
>>seriously intends to use digraphs, should they become available?
>
>>(I asked this the first time here three days ago.  Total number of people
>>so far who actually need multigraphs: 0.)
>
>I also asked this here about 2 weeks ago. No one so far has mailed me
>that he/she is personally interested in having digraphs in the standard.
>It seems to be a quite theoretical problem that is to be solved ... ;-)
>

I don't care either way about digraphs, but this argument wouldn't convince
me. Wouldn't people who have free access to computers that connect to
internet (and in particular this news group) be precisely the people who
would need digraphs the least?

It might be more informative it ask this question in a non-english newsgroup
and monitor the response. Try de.comp.lang.c++


>Markus
>
>---
>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>

Take care
    Robert

--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/

In article <KANZE.94Aug16202253@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
>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...

First rule of C++ implementation/standardization:

 Nothing is cheap and nothing is simple.  (Admitedly, this is more
 true for standardization than it is for implementation, but anyway,
 in both cases it is true.)

Second rule of C++ implementation/standardization:

 Everything interacts with everything else.

I think I can illustrate BOTH of these rules simultaneously by noting that
when I posted what SHOULD HAVE BEEN a rather simple question regarding
digraphs to one of the X3J16/WG21 newsgroups (i.e. `In what translation
phase are they processed into their equivalents?') a lengthy discussion
ensued... which, of course, took up the time of many members (and thus
took time away from the job of standardizing the parts of the language
that are actually useful).

I'd like to also say that (as far as I'm concerned) this is very much still
an open issue.  (I don't think a single actual C++ implementor responded
to my query, perhaps because, wisely, none of them had even looked at
implementing digraphs yet.)

The phase during which things like `bitand' and 'bitor' are supposed to be
translated is also another open issue (in my opinion).  (And this will also
require some precious committee time to settle... time taken away from
clarifying such fundamental and rudimentary things as built-in operators,
let alone all of the other critical things, like templates and namespaces,
sequence points, etc., etc., etc.)

--

-- 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 <rfgCuprqK.85w@netcom.com> rfg@netcom.com (Ronald
F. Guilmette) writes:

|> In article <KANZE.94Aug16202253@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
|> >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...

|> First rule of C++ implementation/standardization:

|>  Nothing is cheap and nothing is simple.  (Admitedly, this is more
|>  true for standardization than it is for implementation, but anyway,
|>  in both cases it is true.)

Regretfully true, at least with regards to the standardization.  In
this case, however, let's cleverly let the C standardization people do
the work, and just integrate their solutions.  (Not free, but easier
than having to do it ourselves.  Sort of like code re-use.)

|> Second rule of C++ implementation/standardization:

|>  Everything interacts with everything else.

|> I think I can illustrate BOTH of these rules simultaneously by noting that
|> when I posted what SHOULD HAVE BEEN a rather simple question regarding
|> digraphs to one of the X3J16/WG21 newsgroups (i.e. `In what translation
|> phase are they processed into their equivalents?') a lengthy discussion
|> ensued... which, of course, took up the time of many members (and thus
|> took time away from the job of standardizing the parts of the language
|> that are actually useful).

I must have missed this.  (I'm missing a lot at present.)  The answer
would seem simple: they *aren't* processed into their equivalents;
they are tokens in their own right.  (Or have I misunderstood.  I will
admit that I have not looked at them in detail.)
--
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 <KANZE.94Aug18214209@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
>|> Second rule of C++ implementation/standardization:
>
>|>  Everything interacts with everything else.
>
>|> I think I can illustrate BOTH of these rules simultaneously by noting that
>|> when I posted what SHOULD HAVE BEEN a rather simple question regarding
>|> digraphs to one of the X3J16/WG21 newsgroups (i.e. `In what translation
>|> phase are they processed into their equivalents?') a lengthy discussion
>|> ensued... which, of course, took up the time of many members (and thus
>|> took time away from the job of standardizing the parts of the language
>|> that are actually useful).
>
>I must have missed this.  (I'm missing a lot at present.)  The answer
>would seem simple: they *aren't* processed into their equivalents;
>they are tokens in their own right.  (Or have I misunderstood.

I think perhaps you have.

>I will admit that I have not looked at them in detail.)

Join the club.  I don't think ANYONE has.

--

-- 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 -

How about a show of hands: who actively codes using trigraphs or
seriously intends to use digraphs, should they become available?

If you don't mind telling, it would be interesting to know:
what kind of a terminal do you use?

There are thousands of readers here - there must be lots of you who
need multigraphs, right?
         ++sja

In article <rfgCutpIJ.EuF@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>In article <KANZE.94Aug18214209@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
>>|> Second rule of C++ implementation/standardization:
>>
>>|>  Everything interacts with everything else.
>>
>>|> I think I can illustrate BOTH of these rules simultaneously by noting that
>>|> when I posted what SHOULD HAVE BEEN a rather simple question regarding
>>|> digraphs to one of the X3J16/WG21 newsgroups (i.e. `In what translation
>>|> phase are they processed into their equivalents?') a lengthy discussion
>>|> ensued... which, of course, took up the time of many members (and thus
>>|> took time away from the job of standardizing the parts of the language
>>|> that are actually useful).
>>
>>I must have missed this.  (I'm missing a lot at present.)  The answer
>>would seem simple: they *aren't* processed into their equivalents;
>>they are tokens in their own right.  (Or have I misunderstood.
>
>I think perhaps you have.
>
>>I will admit that I have not looked at them in detail.)
>
>Join the club.  I don't think ANYONE has.
>

 Section 2.4 of the latest working paper says the following:

 In translation phase 3 (2.1) the digraphs are recognized as
 preprocessing tokens. Then in translation phase 7 the digraphs
 and the additional indentifiers listed below are converted into
 tokens identical to those from the corresponding primary
 representations, as shown in Table 2.

In article <CuuFCA.4HH@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>>>I will admit that I have not looked at them in detail.)
>>
>>Join the club.  I don't think ANYONE has.
>>
>
> Section 2.4 of the latest working paper says the following:
>
> In translation phase 3 (2.1) the digraphs are recognized as
> preprocessing tokens. Then in translation phase 7 the digraphs
> and the additional indentifiers listed below are converted into
> tokens identical to those from the corresponding primary
> representations, as shown in Table 2.

Thanks Pete.  Now please tell me the ``standard'' interpretation of:

 #include "<:"

Is that supposed to include a file called `<:' or a file called `{'?

Given that the conversion from <: to { doesn't happen until phase 7
(well after preprocessing) it seems that digraphs cannot really be
used in preprocessing directives (such as #includes, etc.).

If that is true, then it seems that digraphs aren't that useful after
all, because all those left-handed Latvians will *still* need keyboards
(and screens) which allow them to enter the characters `{', `}', `[', and
`]' in order to type preprocessing directives.

Consider also the standard interpretation of:

 #if 1 and 3

Again, given that the translation (from `and' to `&&') doesn't happen until
phase 7, well after preprocessing, it seems that the above directive MUST
be treated (by ALL conformant compilers) as being equivalent to:

 #if 1 0 3

which is a syntax error.

So much for digraphs!  It seems that there are cases where those poor
left-handed Latvians will be forced to type && after all. :-(  If *that*
is true, then what do all these digraphs and new keywords allow people
to do that they couldn't already do?  Nothing as far as I can tell.
So why pollute the language with them?  Just to keep implementors busy?

--

-- 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 <rfgCuvL4M.F9u@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

...
> Thanks Pete.  Now please tell me the ``standard'' interpretation of:
>
>  #include "<:"

...

> Consider also the standard interpretation of:
>
>  #if 1 and 3
>

...


> -- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------


I'll interpret this as a complaint about the preprocessor rather than
a castigation of digraphs.  If rfg didn't need to depend on the
preprocessor, neither of the aforementioned problems would be such.  I
don't think the problems presented above are the only preprocessor
difficulties, are they?


Joe Wilson
<A HREF="http://www.cis.ufl.edu/~jnw/">jnw@cis.ufl.edu</A>

In article <rfgCuvL4M.F9u@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>In article <CuuFCA.4HH@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>>>>I will admit that I have not looked at them in detail.)
>>>
>>>Join the club.  I don't think ANYONE has.
>>>
>>
>> Section 2.4 of the latest working paper says the following:
>>
>> In translation phase 3 (2.1) the digraphs are recognized as
>> preprocessing tokens. Then in translation phase 7 the digraphs
>> and the additional indentifiers listed below are converted into
>> tokens identical to those from the corresponding primary
>> representations, as shown in Table 2.
>
>Thanks Pete.  Now please tell me the ``standard'' interpretation of:
>
> #include "<:"
>
>Is that supposed to include a file called `<:' or a file called `{'?
>

Section 16.2 in my copy of the working paper is quite clear:

 A #include directive shall identify a header or source file that
 can be processed by the implementation.

 ....

 A preprocessing directive of the form

  # include "q-char-sequence" new-line

 causes the replacement of that directive by the entire contents
 of the soure file identified by the specified sequence between
 the " delimiters. The named source file is searched for IN AN
 IMPLEMENTATION-DEFINED MANNER. [emphasis added]

Now, before you point out that q-char-sequence is not defined, let me remind
everyone that the working paper is not yet complete. That means that there
are things missing from it.
 -- Pete

In article <rfgCuvL4M.F9u@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>
>Given that the conversion from <: to { doesn't happen until phase 7
>(well after preprocessing) it seems that digraphs cannot really be
>used in preprocessing directives (such as #includes, etc.).
>
>If that is true, then it seems that digraphs aren't that useful after
>all, because all those left-handed Latvians will *still* need keyboards
>(and screens) which allow them to enter the characters `{', `}', `[', and
>`]' in order to type preprocessing directives.
>

 My apologies for missing the joke. You're absolutely right: on a
system on which it's hard to create files with names that include characters
like '{', '}', etc., it's also hard to refer to such files in a #include
directive.
 -- Pete

In article <JNW.94Aug21150546@aviator.cis.ufl.edu> jnw@aviator.cis.ufl.edu (Joseph N. Wilson) writes:
[...]
>I'll interpret this as a complaint about the preprocessor rather than
>a castigation of digraphs.  If rfg didn't need to depend on the
>preprocessor, neither of the aforementioned problems would be such.  I
>don't think the problems presented above are the only preprocessor
>difficulties, are they?

So what?  If the the C (and now C++ :-) preprocessor hasn't been eliminated
by mandate from C++ then it's 'problems' and, more specifically to this
particular debate, any problems introduced into the language proper that
create 'problems' with preprocessing *are* problems in the language.  Since
the preprocessing *is* very definitely part of the C language standard
that the C++ working draft sucked in then I don't see how you can come
have such a cavalier attitude about this.  Oh well...

Take care,
 John

P.S. My opinions are strictly my own.

In article <JNW.94Aug21150546@aviator.cis.ufl.edu> jnw@aviator.cis.ufl.edu (Joseph N. Wilson) writes:
>In article <rfgCuvL4M.F9u@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> Thanks Pete.  Now please tell me the ``standard'' interpretation of:
>>
>>  #include "<:"
>>
>> Consider also the standard interpretation of:
>>
>>  #if 1 and 3
>
>I'll interpret this as a complaint about the preprocessor rather than
>a castigation of digraphs.

It's a free country, you can interpret it any way you like.  But my point
related to the draft C++ standard, not to any one implementation or to
specific uses which I (or anyone else) might make of such an implementation.

>If rfg didn't need to depend on the
>preprocessor, neither of the aforementioned problems would be such.

Wrong.  Even if NO ONE ever again uses the preprocessor for anything,
the C++ standard still needs to accurately specify the requirements which
``conforming'' C++ implementations must fulfill.

>I don't think the problems presented above are the only preprocessor
>difficulties, are they?

If you know of some others, I'm all ears.

--

-- 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 <Cuy3Ep.335@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>In article <rfgCuvL4M.F9u@netcom.com>,
>Ronald F. Guilmette <rfg@netcom.com> wrote:
>>In article <CuuFCA.4HH@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>>> In translation phase 3 (2.1) the digraphs are recognized as
>>> preprocessing tokens. Then in translation phase 7 the digraphs
>>> and the additional indentifiers listed below are converted into
>>> tokens identical to those from the corresponding primary
>>> representations, as shown in Table 2.
>>
>>Thanks Pete.  Now please tell me the ``standard'' interpretation of:
>>
>> #include "<:"
>>
>>Is that supposed to include a file called `<:' or a file called `{'?
>>
>...
> A preprocessing directive of the form
>
>  # include "q-char-sequence" new-line
>
> causes the replacement of that directive by the entire contents
> of the soure file identified by the specified sequence between
> the " delimiters. The named source file is searched for IN AN
> IMPLEMENTATION-DEFINED MANNER. [emphasis added]

Pete, you are just side-stepping the real issue.

Yes, the draft standard say that the logical association of some string with
a particular file in the file system is ``implementation-defined''.  But I'm
not even talking about that.

The question I asked is an altogether different one.  I haven't asked about
the logical associations between filenames and actual files.  I have only
asked a question about the filename itself, independent from its logical
connection to some entity in the filesystem.

Just to make sure it's clear this time, I'll restate my question.  Given:

 #include "<:"

what is the (string) *name* of the file to be included?

Based upon the original quotation (on top, above) the filename must be "<:"
rather than "{" because #include filenames are only seen during translation
phase 4.  So the mapping of <: to { which is supposed to occur in phase 7
has not taken place yet when the filename part of the #include directive
is isolated (by the implementation).  Now you *might* argue that the under-
lying operating system itself will helpfully (and magically) change any
system call like `open("<:",...)' to `open("{", ...)', and that this is
therefore a non-issue, but until someone shows me an implementation where
the operating system does that, I have to base my opinions on reality
(rather than fantasy) and assume that (as they are now specified in the
current working paper) digraphs are at best problematic because any pro-
grammer who is in the unenviable position of *having* to use them will
still be unable to do such simple things as including files whose names
happen to contain any of the characters `[', `]', `{', or `}'.

--

-- 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 <Cuy3oE.39L@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>In article <rfgCuvL4M.F9u@netcom.com>, Ronald F. Guilmette wrote:
>>
>>Given that the conversion from <: to { doesn't happen until phase 7
>>(well after preprocessing) it seems that digraphs cannot really be
>>used in preprocessing directives (such as #includes, etc.).
>>
>>If that is true, then it seems that digraphs aren't that useful after
>>all, because all those left-handed Latvians will *still* need keyboards
>>(and screens) which allow them to enter the characters `{', `}', `[', and
>>`]' in order to type preprocessing directives.
>>
>
> My apologies for missing the joke. You're absolutely right: on a
>system on which it's hard to create files with names that include characters
>like '{', '}', etc., it's also hard to refer to such files in a #include
>directive.

This *is* a problem with the way digraphs are specified, and I don't know
why you think it is a joke.  Is the concept of networks of dissimilar machines,
all connected together, and sharing common filesystems also a joke?

--

-- 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 -

> And before Ron starts talking about the left-handed Latvians (not to
> mention the other 420 million people who normally use non-US
> keyboards), note that this is the way we would also have to type in
> the filename when specifying it to the OS.

I have used non-US keyboards since 1981.  I am typing this on a
non-US keyboard right now at work.  My current home computer has
a non-US keyboard.

I have never needed nor wanted trigraphs or digraphs.

There are SO much easier, cost-effective, reliable ways to deal
with this without burdening every C/C++ compiler in the world with
multigraph silliness.
         ++sja

>>>>> "RFG" == Ronald F Guilmette <rfg@netcom.com> writes:

RFG> Based upon the original quotation (on top, above) the
RFG> filename must be "<:" rather than "{" because #include
RFG> filenames are only seen during translation phase 4.  So the
RFG> mapping of <: to { which is supposed to occur in phase 7 has
RFG> not taken place yet when the filename part of the #include
RFG> directive is isolated (by the implementation).  Now you
RFG> *might* argue that the under- lying operating system itself
RFG> will helpfully (and magically) change any system call like
RFG> `open("<:",...)' to `open("{", ...)', and that this is
RFG> therefore a non-issue, but until someone shows me an
RFG> implementation where the operating system does that, I have
RFG> to base my opinions on reality (rather than fantasy) and
RFG> assume that (as they are now specified in the current working
RFG> paper) digraphs are at best problematic because any pro-
RFG> grammer who is in the unenviable position of *having* to use
RFG> them will still be unable to do such simple things as
RFG> including files whose names happen to contain any of the
RFG> characters `[', `]', `{', or `}'.


There is at least one operating system (well, sort-of :), that doesn't
allow filenames with such characters.  Some OS's cannot distinguish
between upper- and lowercase letters.  What does the standard say
about this?  What is a proper/conforming filename?  I mean, your point
is moot if such filenames aren't allowed anyway.


--
Achim Gratz
-+==##{([***Murphy is always right***])}##==+-
E-Mail: gratz@ite.inf.tu-dresden.de
Phone:  +49 351 4575 - 325

In article <GRATZ.94Aug24183931@ite123.inf.tu-dresden.de>,
Achim Gratz <gratz@ite123.inf.tu-dresden.de> wrote:
>>>>>> "RFG" == Ronald F Guilmette <rfg@netcom.com> writes:
>RFG> ...including files whose names happen to contain any of the
>RFG> characters `[', `]', `{', or `}'.
>There is at least one operating system (well, sort-of :), that doesn't
>allow filenames with such characters.

There is at least one widespread operating system which requires them (VMS
filenames use "[]" to indicate directory structure). Does DEC provide digraphs
in its command interpreter?
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com

>>>>> "S" == Steven Correll <sjc@netcom.com> writes:

S> There is at least one widespread operating system which requires
S> them (VMS filenames use "[]" to indicate directory structure). Does
S> DEC provide digraphs in its command interpreter?

No, they provided alternative characters:

 <directory.path>foo.bar

if I remember correctly.

    -- Dag

sja@gamma.hut.fi (Sakari Jalovaara) writes:

>For the second time: who of you actively codes using trigraphs or
>seriously intends to use digraphs, should they become available?

>(I asked this the first time here three days ago.  Total number of people
>so far who actually need multigraphs: 0.)

I also asked this here about 2 weeks ago. No one so far has mailed me
that he/she is personally interested in having digraphs in the standard.
It seems to be a quite theoretical problem that is to be solved ... ;-)

Markus

---
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>