mat@mole-end.matawan.nj.us wrote:
: In article <CMu29G.MBB@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max Skaller) writes:
: > In article <rfgCMsyo1.6s4@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
:
: >  The issue is how to change the language definition.
: > My proposal is simple: In a template < context, >> means
: > close off two levels of nesting, unless its written
: > inside brackets like: ( a>>b ), all existing compilers
: > know how to do this sort of thing, because its the same
: > way that comma , is handled, say in a function call.

: I presume that you want >>> to represent a triple-closure, >>>> a
: quadruple closure, etc.?
:
: >  So: Its EASY to implement >>. It is, as Ron
: > says A MATTER OF LANGUAGE DEFINITION. And that, for better
: > or worse, is A MATTER OF VOTES.

: >  I note the Editor Andrew Koenig has an editorial
: > box in the current WP asking:
:
: >  "Should we bless the >> hack?"

: My answer is a resounding _NO_.  The `,' hack involves using lexical/
: syntactic context to determine which `comma' the comma represents AFTER
: the input is tokenized.  Likewise the use of the context to determine
: whether the angle bracket is an operator or a template-argument delimiter.

: This proposed hack uses lexical and syntactic context to alter the
: tokenization process itself.  The subtlety of bugs that result from
: it will be painful indeed--everything to do with templates has effects
: three or four arms-lengths away.
:
: >  By default, the answer is NO.
: > If you want the answer to be YES, complain to your nearest
: > ANSI or ISO delegate.

: The safest thing is to leave this as it is and require the programmer to
: use the whitespace he ought to have used in the first place.
: --
:  (This man's opinions are his own.)
:  From mole-end    Mark Terribile
:  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
:  (Training and consulting in C, C++, UNIX, etc.)

In article <CMu29G.MBB@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max Skaller) writes:
> In article <rfgCMsyo1.6s4@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

>  The issue is how to change the language definition.
> My proposal is simple: In a template < context, >> means
> close off two levels of nesting, unless its written
> inside brackets like: ( a>>b ), all existing compilers
> know how to do this sort of thing, because its the same
> way that comma , is handled, say in a function call.

I presume that you want >>> to represent a triple-closure, >>>> a
quadruple closure, etc.?

>  So: Its EASY to implement >>. It is, as Ron
> says A MATTER OF LANGUAGE DEFINITION. And that, for better
> or worse, is A MATTER OF VOTES.

>  I note the Editor Andrew Koenig has an editorial
> box in the current WP asking:

>  "Should we bless the >> hack?"

My answer is a resounding _NO_.  The `,' hack involves using lexical/
syntactic context to determine which `comma' the comma represents AFTER
the input is tokenized.  Likewise the use of the context to determine
whether the angle bracket is an operator or a template-argument delimiter.

This proposed hack uses lexical and syntactic context to alter the
tokenization process itself.  The subtlety of bugs that result from
it will be painful indeed--everything to do with templates has effects
three or four arms-lengths away.

>  By default, the answer is NO.
> If you want the answer to be YES, complain to your nearest
> ANSI or ISO delegate.

The safest thing is to leave this as it is and require the programmer to
use the whitespace he ought to have used in the first place.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

In article <CMu0F3.3BL@world.std.com> miket@world.std.com (Michael Trachtman) writes:
>Ronald F. Guilmette (rfg@netcom.com) wrote:
>  [crunch]...
>
>: In short, it is unwise to suggest that the problems relating to >> in
>: template instantiations are in any way a function of the lazyness of
>:    foo<bar<x>>
>: then I'm sorry to have to tell you that you are in for a very very long
>: wait indeed.  If you wish to understand why, I would suggest a good
>: compiler class or a good compiler book.  (The red dragon book's treatment
>: of CFGs is probably as good a place to start as any.)
>

>My guess is that the problem is with the lexigraphical phase. Currently,
>most parsers use lex or something like that to split the input stream into
>tokens. Now, lex has a simple rule on how it disambiguates the rules
>
>'>'      return  SYM_GT
>'>>'     return  SYM_2GT
>
>and the rule is that it tries to find the ***longest*** string that
>matches some pattern.
>
>The problem with : foo <bar < x >>
>
>is that lex returns the sequence of symbols:
>
>    SYM_TOKEN SYM_LT SYM_TOKEN SYM_LT SYM_TOKEN SYM_GT2
>

 So what? The grammar can handle that easily.

 temp-id:
  temp-name < temp-arg >
  temp-name < temp-name < temp-arg >>

is a simplified, unambiguous grammar that handles it.


>This could probably be fixed, by putting alot of interaction
>between the Yacc part of the parsing and the LEX part of the token
>recognition. Or by writing a more complex grammar.

 It doesnt look at all complex to me: see above.

>I hope I am right in these comments, and that I have not said
>something totally wrong. And that I have not muddied the waters even
>further.

 There is NO PROBLEM interpreting >> as closing
two levels of nesting with simple parsers and lexers.

 The issue is entirely as RFG stated: its a matter
of language definition whether we WANT to do it or not.
If we WANT it, compiler writers WILL provide it.

 Anyone that can get multiple inheritrance with virtual
bases, pointer to members, and overload resolution right,
along with type deduction for template functions, can surely
get trivia like >> correct.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CMv8H2.E6J@tempel.research.att.com>, ark@tempel.research.att.com (Andrew Koenig) writes:
> In article <rfgCMsyo1.6s4@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

[on the  List<List<int>>  `problem']

> > The case of >> would be particularly difficult (and perhaps even im-
> > possible) to handle (either for a human *or* a program), ...

> Actually, it's quite easy to implement if you like lexical hacks.  ...

> The committee debated adopting a solution of this form early on and
> rejected it as being too hackish.  I suspect that if someone were to
> introduce it again, it would stand a better chance of passing now than
> it did originally.  ...

Frankly, I consider this `problem' a blessing ... people use too little
whitespace in their code as it is.

If you compare the typesetting practices for math text and for ordinary
text, you find that math text gets much more whitespace around
`punctuation' than ordinary text.  Program text for C++ is closer to
math text than it is to natural language text, and ought to be treated
the same way.

My advice to Andy, Bjarne, Dag, John Max, and the rest: let this one be!
C++ will be a better (-written) language for it.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

Doesn't this approach introduce a new (although probably rare)
pathology?  Consider

 #define BUFSIZ 1024

 template <int i> class Foo { ... }
 template <class T> class Bar { ... }

 main()
 {
     Bar<Foo<BUFSIZ>>  2> x;
     ...
 }

In article <CMv8H2.E6J@tempel.research.att.com>, ark@tempel.research.att.com (Andrew Koenig) writes:

> Actually, [distinguishing ">>" from "> >" in template argument lists is]
> quite easy to implement if you like lexical hacks.
> Indeed, Niklaus Wirth's Algol W compiler had a similar hack to distinguish
> between commas in argument lists and other commas.
>
> The basic idea is as follows.  It is already necessary to know during
> parsing whether each identifier represents a template name.  That means
> that it is easy to keep track during parsing of whether or not you are
> directly inside a template argument list: just count < > { } ( ) pairs.
> This can all be done as an adjunct to normal parsing.
>
> The hack, then, is that when you encounter >> when directly inside a template
> argument list, rewrite it to > > real fast before the parser sees it.
>

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

> >The proponents and opponents of the proposal stated their arguments,
> >the committee voted, and the vote defeated the proposal.

> Exactly.  Did I suggest that anything other that that happened?

> The decision was made on the basis of votes cast.  Isn't that what politics
> is all about?

No, actually, it's not--at least not the way I think most people would use
the word today.  Politics is about trying to be sure that the result of
a vote has as little as possible to do with what's fair or just.

> >Calling that `good old-fashioned politics' robs the phrase of all meaning.

> I think not.

> The problem here seems to be one of misunderstanding which can (perhaps)
> mostly be traced to the fact the ever since Watergate (and perhaps well
> before that) most people attach a very negative connotation to the word
> ``politics''... and it's gotten to the point where ``politics'' is almost
> a dirty word in our society today.

Exactly.  I can't imagine you were unaware of that connotation when
you used the word.

> >There were, for example, no parliamentary maneuvers to try to settle the
> >matter without a vote; nor do I know of any hidden deals, extortion,
> >or other such unsavory practices.

> See what I mean?  Juts saying the word ``politics'' seems to conjure up
> images of envelopes bulging with money being passed beneath some table
> somewhere!

Right you are.

> I  never suggested that anything even remotely like ``hidden deals'',
> ``extortion'', or ``unsavory practices'' practices took place.  (And
> I think that Andrew has projected a whole lot of his own feelings about
> the word ``politics'' into what I actually said.)

Well, no -- I've projected a whole lot of your feelings,
as you just pointed out.

> What I *did* say was that the decision was a poltical one, rather than
> an engineering one.  I believe that if the decision had been made strictly
> on the basis of good ``engineering'' the outcome would have been different.
> That's all I ever meant to say (or imply).

No, what you said was that the decision was `the result of good
old-fashioned politics.'  You did not merely say that it was a political
decision, nor did you even say how such a decision could ever be anything
*but* a political one.  After all, it comes down to a judgement call
as to whether it's better to annoy one group of people or another;
there isn't really an objective engineering measure that applies.

> >If you don't like the fact that the committee acts through a democratic
> >process...

> Well, I don't claim to have a better alternative at the moment, but no,
> I don't particularly like it, especially when that processes produces
> results which are obviously more messy (both for implementors *and* for
> users) than what I (and others) can plainly see *could have been*
> accomplished had things been decided in some other way.

I see.  You don't like democracy.  I rest my case.
--
    --Andrew Koenig
      ark@research.att.com

Hello everyone!

 I am trying to pass a template class as an instantiation
parameter to another template class and it wouldnt compile..Is it allowed
at all.. Lippman book doesnt talk about it at all..
I know that I can pass class as a paramter to template class but I am
not sure if I can pass an instantiated template class as a paramter..
 Here is an example of what I am trying to do.

template <class Type>
class A
{
public:
 A();
 ~A()
 Type &getx();
 void setx(Type &);
private:
 Type x;
};

template <class info_type>
class B
{
public:
 B();
 ~B();
 info_type gety();
 void sety(info_type &);
private:
 info_type &;
};

Now in main()
main()
{
 A<B<int>> a;
//it says syntax error here.. along with a whole bunch other errors
// which I think are a result of this one
}


 I'd appreciate any help in this !!
thanks,
Murali

In a recent article mmediko@hubcap.clemson.edu (Medikonda Muralidhar) writes:
> A<B<int>> a;

Medikonda -

Because of a bug in the definition of the language you have to put a
space between the two >>'s. The bug exists in order to make compiler-
writers' lives easier.

garry

------
Garry Wiegand -- garry@ithaca.com

In article <2lt6mu$12n@autodesk.autodesk.com> garry@autodesk.com (Garry Wiegand) writes:
>In a recent article mmediko@hubcap.clemson.edu (Medikonda Muralidhar) writes:
>> A<B<int>> a;
>
>Medikonda -
>
>Because of a bug in the definition of the language you have to put a
>space between the two >>'s. The bug exists in order to make compiler-
>writers' lives easier.

This is simply untrue.

The ``bug'' in the language (as you call it) exists because some
people in the standardization committee insisted that the delimiters for
template formal argument lists be '<' and '>', even though there were a
number of other viable alternatives... e.g. `(' and `)', `[' and `]',
`{' and `}' which would have caused less problems (because unlike the
`<' and `>' delimiters which we are now saddled with, the alternatives
have no special lexical significance when two of them appear in row).

In short, this example of poor language design was brought to you courtesy
of good old fashioned politics, and not for any defensible reason having
to do with implementation complexity and/or simplicity.

Oh yes!  And lest I forget (and be chastized later for forgetting) I really
should say that at least one of the reasons why the committee stuck us
with `<' and `>' was that they felt that they should ``standardize existing
practice''.  (I'm not making this up!)  And of course we all know that
the standardization of existing practice has always been the committee's
highest priority goal, and that they have rarely, if ever, strayed from
doing only that.  :-)

--

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

> In short, this example of poor language design was brought to you courtesy
> of good old fashioned politics, and not for any defensible reason having
> to do with implementation complexity and/or simplicity.

There was a proposal formally brought before the committee to make the
template delimiters ( and ) instead of the < and > that appeared in the
base document the committee had already adopted.

The proponents and opponents of the proposal stated their arguments,
the committee voted, and the vote defeated the proposal.

Calling that `good old-fashioned politics' robs the phrase of all meaning.
There were, for example, no parliamentary maneuvers to try to settle the
matter without a vote; nor do I know of any hidden deals, extortion,
or other such unsavory practices.

If you don't like the fact that the committee acts through a democratic
process, that is certainly your privilege, but that isn't about to
change and objecting to it just wastes time.
--
    --Andrew Koenig
      ark@research.att.com

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

> Oh yes!  And lest I forget (and be chastized later for forgetting) I really
> should say that at least one of the reasons why the committee stuck us
> with `<' and `>' was that they felt that they should ``standardize existing
> practice''.  (I'm not making this up!)  And of course we all know that
> the standardization of existing practice has always been the committee's
> highest priority goal, and that they have rarely, if ever, strayed from
> doing only that.  :-)

The committee has only rarely changed anything that is clearly stated
in the ARM, which at their very first meeting they voted to accept
as one of their base documents.  Standardizing existing practice has
never been the committee's highest priority goal, though remaining consistent
with existing practice has been pretty high on the list.
--
    --Andrew Koenig
      ark@research.att.com

In a recent article Ronald F. Guilmette writes:
>In a recent article garry@autodesk.com (Garry Wiegand) writes:
>>> A<B<int>> a;
>>Because of a bug in the definition of the language you have to put a
>>space between the two >>'s. The bug exists in order to make compiler-
>>writers' lives easier.
>
>This is simply untrue.
>
>The ``bug'' in the language (as you call it) exists because some
>people in the standardization committee insisted that the delimiters for
>template formal argument lists be '<' and '>', even though there were a
>number of other viable alternatives... e.g. `(' and `)', `[' and `]',

Ron -

Well, I see your point. If one takes the delimiters as <> then the
required blank is a feature implemented for the sake of the compiler
writers. On the other hand if the delimiters had been chosen to be
() or [] then no compiler-writer work-around would have been needed,
since there is no operator)) or operator]]. But in that world what about:

     new Foo[20]
   new Foo(20) ?

The meaning of these expressions would vary (dramatically) depending
on whether Foo was a []/() templated class. This also could be
pretty confusing/surprising to the beginners. Now if you had said to
use squiggly braces ("new Foo{20}") everything works out, no
ambiguities or compiler problems at all.

But seriously, all we can hope for at this late date is to get >> fixed
sometime.

garry

--
Garry Wiegand --- garry@ithaca.com --- Ithaca Software, Alameda, California

In article <CMu0F3.3BL@world.std.com> miket@world.std.com (Michael
Trachtman) writes:

|> E.g. once we saw the symbol "foo", then we know that we are looking at
|> a template. Thus all further '<', and '>' must be template symbols
|> rather than arithmetic operators. So, as soon as we know that we
|> are looking at a template name (by a symbol table lookup), then we
|> could have lex switch, and not recognize '>>' as a separate token
|> anymore.

 template< int i > class X ...

 X< 8 >> 1 > x ;

It isn't that simple.  In the above, '>>' is a right shift operator.

This is (I think) what Ron was referring to when he mentioned infinite
lookahead.  (The type 'X< 5 >> 1 >' in the above example could be used
to instantiate another template, ie: nested.)  While there are already
cases in C++ where backtracking (ie: infinite look-ahead) is
necessary, none of them cause a change in the token break-up of the
line.

This cannot be handled by somehow informing the scanner of right hand
context; you need left hand context as well.

Although I have not done a full analysis of it, I suspect that John
Skaller's suggestion of detecting the case in the parser would also
result in (yet) another case requiring backtracking.
--
James Kanze                       email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <2lt6mu$12n@autodesk.autodesk.com> garry@autodesk.com (Garry Wiegand) writes:
>In a recent article mmediko@hubcap.clemson.edu (Medikonda Muralidhar) writes:
>> A<B<int>> a;
>
>Medikonda -
>
>Because of a bug in the definition of the language you have to put a
>space between the two >>'s. The bug exists in order to make compiler-
>writers' lives easier.


 Well, complain LOUD. Supporting >> is on the
issues list, but its a low priority. By default, >> is
a shift operator. A VOTE is required to change that.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <2m2vtj$424@autodesk.autodesk.com> garry@autodesk.com (Garry Wiegand) writes:
>In a recent article Ronald F. Guilmette writes:
>>In a recent article garry@autodesk.com (Garry Wiegand) writes:
>>>> A<B<int>> a;
>>>Because of a bug in the definition of the language you have to put a
>>>space between the two >>'s. The bug exists in order to make compiler-
>>>writers' lives easier.
>>
>>This is simply untrue.
>>
>>The ``bug'' in the language (as you call it) exists because some
>>people in the standardization committee insisted that the delimiters for
>>template formal argument lists be '<' and '>', even though there were a
>>number of other viable alternatives... e.g. `(' and `)', `[' and `]',
>
>Ron -
>
>Well, I see your point. If one takes the delimiters as <> then the
>required blank is a feature implemented for the sake of the compiler
>writers.

You've just tried to restate the same falacy again.  Did you expect it
to become somehow less false if you said it again?

The fact that users must put a blank between >>'s when instantiating
template instances with template instances is *not* in any sense merely
a consession to the postulated lazyness of compiler implementors.  It is
a *requirement* imposed by the language itself, and by the very real
concerns of implementors *not* to have to implement *additional* kinds
of potentially infinite lookahead (followed by potentially infinite
backtracking) other than what is already required to solve the (highly
unfortunate) declaration/expression ambiguity botch described on page
93 of the ARM.

As Tom Pennello (and others) have noted, these types of ambiguities do
a disservice, not just to the implementors, but also to the end-users of
programming languages.  If it is difficult for a carefully crafted
*program* to syntactically (or lexically) disambiguate some valid sentence
of the language, what hope do mere mortals have when reading (often
poorly documented and poorly formatted) code written by others who
have long since departed for other assignments?

The case of >> would be particularly difficult (and perhaps even im-
possible) to handle (either for a human *or* a program), even using
potentially infinite forward lookahead, because in this case, not
only would syntactic disambiguation have to be delayed until some
arbitrary amount of forward lookahead made that disambiguation possible,
but worse, in this case even *lexing* would have to be delayed until
some indefinite amount of right context had been processed.

In short, it is unwise to suggest that the problems relating to >> in
template instantiations are in any way a function of the lazyness of
implementors.  They are not.  These problems are serious ones, but they
spring from the language definition itself, and not merely from any
unwillingness on the part of implementors of C++ to tackle difficult
problems.

>On the other hand if the delimiters had been chosen to be
>() or [] then no compiler-writer work-around would have been needed,
>since there is no operator)) or operator]]. But in that world what about:
>
>     new Foo[20]
>   new Foo(20) ?
>
>The meaning of these expressions would vary (dramatically) depending
>on whether Foo was a []/() templated class. This also could be
>pretty confusing/surprising to the beginners. Now if you had said to
>use squiggly braces ("new Foo{20}") everything works out...

I believe that I *did* also mention curley braces (as one of the al-
ternatives) in my original posting, but I see that you managed to
elide that portion of my earlier response.

>But seriously, all we can hope for at this late date is to get >> fixed
>sometime.

But seriously, if you think that you will someday be able to instantiate
a template with a template instantiation as a parameter like:

   foo<bar<x>>

then I'm sorry to have to tell you that you are in for a very very long
wait indeed.  If you wish to understand why, I would suggest a good
compiler class or a good compiler book.  (The red dragon book's treatment
of CFGs is probably as good a place to start as any.)

--

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

Ronald F. Guilmette (rfg@netcom.com) wrote:
  [crunch]...
: potentially infinite forward lookahead, because in this case, not
: only would syntactic disambiguation have to be delayed until some
: arbitrary amount of forward lookahead made that disambiguation possible,
: but worse, in this case even *lexing* would have to be delayed until
: some indefinite amount of right context had been processed.

: In short, it is unwise to suggest that the problems relating to >> in
: template instantiations are in any way a function of the lazyness of
: implementors.  They are not.  These problems are serious ones, but they
: spring from the language definition itself, and not merely from any
: unwillingness on the part of implementors of C++ to tackle difficult
: problems.

   more crunch...

: But seriously, if you think that you will someday be able to instantiate
: a template with a template instantiation as a parameter like:

:    foo<bar<x>>

: then I'm sorry to have to tell you that you are in for a very very long
: wait indeed.  If you wish to understand why, I would suggest a good
: compiler class or a good compiler book.  (The red dragon book's treatment
: of CFGs is probably as good a place to start as any.)

I suspect that the problem is not the CFG aspect of it. If that were the case
we would have problems with
              foo < bar < x > >
also. Since '<', '<<', '>', '>>' are all operators and all have problems
with multiple meanings (both operators and template name delimiters).

My guess is that the problem is with the lexigraphical phase. Currently,
most parsers use lex or something like that to split the input stream into
tokens. Now, lex has a simple rule on how it disambiguates the rules

'>'      return  SYM_GT
'>>'     return  SYM_2GT

and the rule is that it tries to find the ***longest*** string that
matches some pattern.

The problem with : foo <bar < x >>

is that lex returns the sequence of symbols:

    SYM_TOKEN SYM_LT SYM_TOKEN SYM_LT SYM_TOKEN SYM_GT2

instead of:

    SYM_TOKEN SYM_LT SYM_TOKEN SYM_LT SYM_TOKEN SYM_GT SYM_GT

the two >> get scrunched into one token.

The grammar rules (e.g. YACC) which look for templates,
are looking for a SYM_GT rather than a SYM_GT2.

This could probably be fixed, by putting alot of interaction
between the Yacc part of the parsing and the LEX part of the token
recognition. Or by writing a more complex grammar.


E.g. once we saw the symbol "foo", then we know that we are looking at
a template. Thus all further '<', and '>' must be template symbols
rather than arithmetic operators. So, as soon as we know that we
are looking at a template name (by a symbol table lookup), then we
could have lex switch, and not recognize '>>' as a separate token
anymore.


I hope I am right in these comments, and that I have not said
something totally wrong. And that I have not muddied the waters even
further.

Mike

In article <rfgCMsyo1.6s4@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <2m2vtj$424@autodesk.autodesk.com> garry@autodesk.com (Garry Wiegand) writes:
>>Ron -
>>
>>Well, I see your point. If one takes the delimiters as <> then the
>>required blank is a feature implemented for the sake of the compiler
>>writers.
>
>You've just tried to restate the same falacy again.  Did you expect it
>to become somehow less false if you said it again?
>
>The fact that users must put a blank between >>'s when instantiating
>template instances with template instances is *not* in any sense merely
>a consession to the postulated lazyness of compiler implementors.  It is
>a *requirement* imposed by the language itself,

 True.

>and by the very real
>concerns of implementors *not* to have to implement *additional* kinds
>of potentially infinite lookahead (followed by potentially infinite
>backtracking) other than what is already required to solve the (highly
>unfortunate) declaration/expression ambiguity botch described on page
>93 of the ARM.
>

 This is not realy true. Implementing >> correctly
is easy, no infinite lookahead is required, neither is
any change to current lexers required.

 The issue is how to change the language definition.
My proposal is simple: In a template < context, >> means
close off two levels of nesting, unless its written
inside brackets like: ( a>>b ), all existing compilers
know how to do this sort of thing, because its the same
way that comma , is handled, say in a function call.

 So: Its EASY to implement >>. It is, as Ron
says A MATTER OF LANGUAGE DEFINITION. And that, for better
or worse, is A MATTER OF VOTES.

 I note the Editor Andrew Koenig has an editorial
box in the current WP asking:

 "Should we bless the >> hack?"

 By default, the answer is NO.
If you want the answer to be YES, complain to your nearest
ANSI or ISO delegate.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

>>>>> rfg@netcom.com (Ronald F. Guilmette) said:

[On the ">>" ambiguity in template instantiations.]

>> ....  If it is difficult for a carefully crafted
>> *program* to syntactically (or lexically) disambiguate some valid sentence
>> of the language, what hope do mere mortals have when reading (often
>> poorly documented and poorly formatted) code written by others who
>> have long since departed for other assignments?

This is a case where humans are much better parsers than computers.
People have no problems understanding what ">>" means in

 Array<Map<int, int>> a;

and how that is different from ">>" in

 i = k >> 2;

The reason of course is that humans are context-sensitive parsers and
do top-down parsing to the lexical level.

Not even Ron Guilmette can claim that this is an essential problem in
C++, in particular compared to everything else he has pointed out in
this newsgroup on previous occasions.  Save your bullets, Ron :-)


     -- Dag


PS.  I don't understand why this is a serious parsing problem.  I
would write my grammar to accept either ">" or ">>" as the terminator
of a template argument list, and then if we get ">>" just check that
the nesting level is >1, in which case I treat it as a ">" and push
back a second ">" on the input stream.  It's a hack, but a simple one.
Yeah, I know, life isn't always that simple.

In article <CMo7C1.849@tempel.research.att.com> ark@tempel.research.att.com (Andrew Koenig) writes:
>In article <rfgCMLEpq.B1@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>
>> In short, this example of poor language design was brought to you courtesy
>> of good old fashioned politics, and not for any defensible reason having
>> to do with implementation complexity and/or simplicity.
>
>There was a proposal formally brought before the committee to make the
>template delimiters ( and ) instead of the < and > that appeared in the
>base document the committee had already adopted.
>
>The proponents and opponents of the proposal stated their arguments,
>the committee voted, and the vote defeated the proposal.

Exactly.  Did I suggest that anything other that that happened?

The decision was made on the basis of votes cast.  Isn't that what politics
is all about?

>Calling that `good old-fashioned politics' robs the phrase of all meaning.

I think not.

The problem here seems to be one of misunderstanding which can (perhaps)
mostly be traced to the fact the ever since Watergate (and perhaps well
before that) most people attach a very negative connotation to the word
``politics''... and it's gotten to the point where ``politics'' is almost
a dirty word in our society today.

>There were, for example, no parliamentary maneuvers to try to settle the
>matter without a vote; nor do I know of any hidden deals, extortion,
>or other such unsavory practices.

See what I mean?  Juts saying the word ``politics'' seems to conjure up
images of envelopes bulging with money being passed beneath some table
somewhere!

I never suggested that anything even remotely like ``hidden deals'',
``extortion'', or ``unsavory practices'' practices took place.  (And
I think that Andrew has projected a whole lot of his own feelings about
the word ``politics'' into what I actually said.)

What I *did* say was that the decision was a poltical one, rather than
an engineering one.  I believe that if the decision had been made strictly
on the basis of good ``engineering'' the outcome would have been different.
That's all I ever meant to say (or imply).

>If you don't like the fact that the committee acts through a democratic
>process...

Well, I don't claim to have a better alternative at the moment, but no,
I don't particularly like it, especially when that processes produces
results which are obviously more messy (both for implementors *and* for
users) than what I (and others) can plainly see *could have been*
accomplished had things been decided in some other way.

> that is certainly your privilege...

(Actually, in this country, it is generally refered to as a `right', not
a `privledge'.)

--

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

> The case of >> would be particularly difficult (and perhaps even im-
> possible) to handle (either for a human *or* a program), even using
> potentially infinite forward lookahead, because in this case, not
> only would syntactic disambiguation have to be delayed until some
> arbitrary amount of forward lookahead made that disambiguation possible,
> but worse, in this case even *lexing* would have to be delayed until
> some indefinite amount of right context had been processed.

Actually, it's quite easy to implement if you like lexical hacks.
Indeed, Niklaus Wirth's Algol W compiler had a similar hack to distinguish
between commas in argument lists and other commas.

The basic idea is as follows.  It is already necessary to know during
parsing whether each identifier represents a template name.  That means
that it is easy to keep track during parsing of whether or not you are
directly inside a template argument list: just count < > { } ( ) pairs.
This can all be done as an adjunct to normal parsing.

The hack, then, is that when you encounter >> when directly inside a template
argument list, rewrite it to > > real fast before the parser sees it.

The committee debated adopting a solution of this form early on and
rejected it as being too hackish.  I suspect that if someone were to
introduce it again, it would stand a better chance of passing now than
it did originally.  Indeed, Bjarne commented in the `Design and Evolution'
book:

 I have ... heard so many complaints about

  List<List<int>> a;

 that I am sorely tempted to apply some glorious hack to make
 the problem go away.  I find it more painful to listen to complaints
 from users than to listen from complaints from language lawyers.

and I suspect a number of committee members now feel the same way.
--
    --Andrew Koenig
      ark@research.att.com