In article <3ADC597C.DAF5EF5@dollywood.itp.tuwien.ac.at>, Christopher
Eltschka <celtschk@dollywood.itp.tuwien.ac.at> wrote:
>Hans Aberg wrote:
>... (Following Feynman, in
>> physics "<" is called a "bra" and ">" a "ket".)
>
><OT>No, in physics, <...| is a bra, and |...> is a ket.</OT>

Right; I realized that after the post. (In math, they are called Hilbert
space vectors.)

But the terminology is just an abbreviation of "bracket" for "<" and ">",
so it seems appropriate anyhow.

In article
<remove.haberg-1704011132050001@du137-226.ppp.su-anst.tninet.se>,
remove.haberg@matematik.su.se (Hans Aberg) wrote:
>But what does the standard say? That is, is it indicated somewhere whether
>">>" and "<<" are context free symbols, so that those character
>combination cannot be used in template arguments.

In article <3ADC6D3F.42B80E74@sun.com>, Steve Clamage
<stephen.clamage@sun.com> wrote:
>Section 2.4 of the standard says that a token is the longest sequence
>of characters that could possibly constitute a token.

John Hickin pointed out to me in an email that it is described in the part
about tokenizing, 2.4:3,5 Preprocessing tokens.

>Other language designs are possible, and alternatives were discussed
>within the C++ committee, but that is the C++ rule.

My guess is that the choice is made in order to simplify the description
and implementation of the language.

I working now with Flex & Bison, and it is otherwise fairly easy to
introduce context dependent tokenizing using so called Flex "start
conditions".

With this approach it is not necessary for example, to make use of context
independent key-words, which blocks the use that particular character
combination in all situations. For example, by allowing context
dependencies, one can allow say
  class false;
because the keyword "false" would not be expected to appear except in
other types of expressions.

And one could allow
  list<list<int>> ls;
because ">>" context where it semantically can be confused with operator>>.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:

> With this approach it is not necessary for example, to make use of context
> independent key-words, which blocks the use that particular character
> combination in all situations. For example, by allowing context
> dependencies, one can allow say
>   class false;
> because the keyword "false" would not be expected to appear except in
> other types of expressions.

Maybe C++ isn't complicated enough, and lacks some uglyness.

> And one could allow
>   list<list<int>> ls;
> because ">>" context where it semantically can be confused with operator>>.

But you *can* have >> in this context (template arguments).

Clearly templates are too simple, and miss some other rule
that adds nothing in term of expressive power.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1804011156220001@du134-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>I working now with Flex & Bison, and it is otherwise fairly easy to
>introduce context dependent tokenizing using so called Flex "start
>conditions".

I doubt that this would work in C++ unless you have a tokeniser that can
look ahead for an unspecified number of characters because forward
context also matters in this case.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <n$VsTeBOps36EwPW@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>I working now with Flex & Bison, and it is otherwise fairly easy to
>>introduce context dependent tokenizing using so called Flex "start
>>conditions".
>
>I doubt that this would work in C++ unless you have a tokeniser that can
>look ahead for an unspecified number of characters because forward
>context also matters in this case.

In this case it is fairly easy: If it is a template definition, once one
finds the word "template", one can set the token context for scanning
template arguments. For scanning expressions, once a name has been read,
the lookup table will tell if it is a template, and one can set token
context accordingly. When the token arguments clause has been identified,
one sets back the token context.

What is the forward context that you have in your mind?

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1904012006470001@du141-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>In this case it is fairly easy: If it is a template definition, once one
>finds the word "template", one can set the token context for scanning
>template arguments. For scanning expressions, once a name has been read,
>the lookup table will tell if it is a template, and one can set token
>context accordingly. When the token arguments clause has been identified,
>one sets back the token context.

You cannot do it that simply >> is a legal and potentially usable token
in the context of a template. You need to parse the complete expression
to determine whether >> is actually >> or a double > which is why the
standard specifies that >> is never a double > template closure. In the
real world parsers must behave reasonably in the presence of erroneous
code which is why C++ generally limits itself to single character look
ahead for tokenisers and no look-ahead context for parsing, i.e. a token
is exactly what it appears to be.

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3ADC4548.CA2FC230@acm.org>, James Dennett <jdennett@acm.org>
writes
>This is covered, I think, by the phases of compilation.
>Tokenization occurs early, and >> is a single token.

We even considered if we could reinterpret this token in context to
allow it to be parsed as a double template closure, however counter
examples demonstrated that that is not viable, so we have the present
rule.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9g+akIAimz36EwcY@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>In this case it is fairly easy: If it is a template definition, once one
>>finds the word "template", one can set the token context for scanning
>>template arguments. For scanning expressions, once a name has been read,
>>the lookup table will tell if it is a template, and one can set token
>>context accordingly. When the token arguments clause has been identified,
>>one sets back the token context.
>
>You cannot do it that simply >> is a legal and potentially usable token
>in the context of a template.

If one do what I suggest, >> would not be a legal token in the context of
a template argument. -- The standard would have to be changed, in order to
admit context dependent tokens.

(C++ already contains context dependent scanning in the preprocessor
language constructs
  #include <...>
  #include "..."
Within <...> and "..." one should not scan for tokens in the normal way,
but only characters. So, one would not add anything in essence new, but
merely expanding on already existing features.)

You say that >> is potentially usable token in the context of template
arguments. What kind of situations do you have in your mind?

Here is an example: Let f be a template function producing (say) a
reference to an istream, and we want to read a double form that stream.
Then it is easy to admit
   double x;
   f<list<list>>>>x;
and to toke parse it as
   f<list<list> > >> x;
as follows: When the name "f" is encountered, it is discovered that it is
a template (or possibly when the first "<" is encountered). Then the
template argument scanning mode is turned on, making ">>" to be parsed as
two ">". When the final template argument closing ">" is encountered, the
usual token scanning mode is turned on again.

This rule, as I wrote it, will screw up say an int template argument with
a bit shift g<5>>2>, if such expressions now are allowed. So one would
have to think a little about that.

But I still do not see what forward context you have in your mind. --
Perhaps the problem is that the preprocessor language, and not the C++
language proper is making the tokenizing; is that what you have your mind?

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-2004011115250001@du132-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>If one do what I suggest, >> would not be a legal token in the context of
>a template argument.

Exactly, and that would not be acceptable. People have code that would
be broken by such a change, which is basically what I have been saying
all along.

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <wlvJ1UAZsG46Ew1C@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>If one do what I suggest, >> would not be a legal token in the context of
>>a template argument.
>
>Exactly, and that would not be acceptable. People have code that would
>be broken by such a change, which is basically what I have been saying
>all along.

The problem with new versions is not whether old code is broken, but how
much and how significant that old code is.

And you gave no examples or other descriptions of what you have in your
mind. So it is hard to figure out workarounds.

My guess is that one probably has committed oneself in C++ to context-free
token parsing, so it is for that reason difficult to alter that.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Thu, 19 Apr 2001 19:16:45 GMT, Francis Glassborow <francis.glassborow@ntl=
world.com> pisze:

> You cannot do it that simply >> is a legal and potentially usable token
> in the context of a template.

But > is too.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <slrn9e0og2.4d7.qrczak@qrnik.zagroda>, qrczak@knm.org.pl
(Marcin 'Qrczak' Kowalczyk) wrote:

>Thu, 19 Apr 2001 19:16:45 GMT, Francis Glassborow <francis.glassborow@ntl=
>world.com> pisze:
>
>> You cannot do it that simply >> is a legal and potentially usable token
>> in the context of a template.
>
>But > is too.

Yes, this one is already broken, if a template f has int (or bool) as
argument, and one wants to write
  f<5>3>6;
Then one must write f<(5>3)>6 or f<5>(3>6).

Also, with context dependent parsing is not difficult to require
parenthesises in expressions like
  f<g<(5>>3)>>;
so that within (...) token parsing is normal.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> In article <wlvJ1UAZsG46Ew1C@ntlworld.com>, Francis Glassborow
> <francisG@robinton.demon.co.uk> wrote:
> >>If one do what I suggest, >> would not be a legal token in the context of
> >>a template argument.
> >
> >Exactly, and that would not be acceptable. People have code that would
> >be broken by such a change, which is basically what I have been saying
> >all along.
>
> The problem with new versions is not whether old code is broken, but how
> much and how significant that old code is.

No. Unless there's a strong need for it, language changes that break any
previously legal code should be avoided. It's impossible to review the
entire body of C++ code, to gauge how many programs would be effected.
The safest course is to assume that anything which is legal might have
been done, somewhere, and that someone is depending upon it. I don't
think there is a strong need for this change. There's nothing
particularly difficult about writing "> >" rather than ">>". It's even
arguably more readable with the extra space.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3AE21FE8.91075E53@wizard.net>, "James Kuyper Jr."
<kuyper@wizard.net> wrote:
>> The problem with new versions is not whether old code is broken, but how
>> much and how significant that old code is.
>
>No. Unless there's a strong need for it, language changes that break any
>previously legal code should be avoided.

It seems me that you are saying the same thing as I do.

> It's impossible to review the
>entire body of C++ code, to gauge how many programs would be effected.

Have you checked the appendixes in the C++ standard about changes, what
they break and how much? :-)

>The safest course is to assume that anything which is legal might have
>been done, somewhere, and that someone is depending upon it.

In my own experience, code picked down to a new platform must be fixed up
somehow. The question is not whether it has to be fixed up, but how much.

The same thing applies older C++ code compiled with a fairly C++ standard
compliant compiler.

In general, one wants a quick fix for the older code to be available. If
the code is useful, then it is probably better to rewrite it at some point
for the new standard.

> I don't
>think there is a strong need for this change.

But that's another matter: I have not yet discussed whether this change is
desirable, only that such changes with context

> There's nothing
>particularly difficult about writing "> >" rather than ">>". It's even
>arguably more readable with the extra space.

I think you are speaking about personal taste, here. If you find "> >"
easier to read rather than ">>", it is probably because you are not used
to it.

The normal typesetting rule, though, is to not have any extra space there.

But computer folks have invented their own rules: For example, in all
mathematical typesetting, one writes "f(x)" with no space between the "f"
and the "(", but in compute code, the style "f (x)" is quite common,
despite it being wrong relative the rest of the world that uses
mathematics.

In part this is due to the fact that one only has the symbols of the
measly ASCII at disposal. It is not possible to properly distinguish ">"
as "greater" from it as being a right bracket. Often, it is necessary to
insert spaces where it shouldn't in order to make it possible for the
limited parsers to parse it, instead of make life easy for humans. It will
better up when Unicode becomes available; then one should be able to
design much better computer language syntaxes.

But, returning to C++, both of
  list<list<int> >
  f (x)
looks like hell to me. But in math, one gets used to reading different
notational styles. It is possible to live with it.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> In article <3AE21FE8.91075E53@wizard.net>, "James Kuyper Jr."
> <kuyper@wizard.net> wrote:
...
> > There's nothing
> >particularly difficult about writing "> >" rather than ">>". It's even
> >arguably more readable with the extra space.
>
> I think you are speaking about personal taste, here. If you find "> >"
> easier to read rather than ">>", it is probably because you are not used
> to it.
[Complicated explanation of mathematical notation and printing
conventions]

No, it's nothing as complicated as the reason you suggest - it's simply
because the space helps make it clearer which item is contained in
which. Consider the following three lines, all legal, all identical in
terms of the actual consequences of executing them:

 c=2 * a+3 * b; //1
 c=2*a+3*b; //2
 c = 2*a + 3*b; //3

I find the third form a lot easier to read than the first two. The lack
of spacing around "*", and the spacing around "+", help clarify the fact
that the "*" expressions are sub-expressions of the "+" expression. It's
the same principle with the template parameters.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3AE4B7A1.ED10553C@wizard.net>, "James Kuyper Jr."
<kuyper@wizard.net> wrote:
>> I think you are speaking about personal taste, here. If you find "> >"
>> easier to read rather than ">>", it is probably because you are not used
>> to it.
>[Complicated explanation of mathematical notation and printing
>conventions]
>
>No, it's nothing as complicated as the reason you suggest - it's simply
>because the space helps make it clearer which item is contained in
>which.

Well, but you suggest to put in space where it normally shouldn't be there.

> Consider the following three lines, all legal, all identical in
>terms of the actual consequences of executing them:
>
>        c=2 * a+3 * b;  //1
>        c=2*a+3*b;      //2
>        c = 2*a + 3*b;  //3
>
>I find the third form a lot easier to read than the first two. The lack
>of spacing around "*", and the spacing around "+", help clarify the fact
>that the "*" expressions are sub-expressions of the "+" expression.

As a matter of fact, I have used different variations of spacing allowing
the principles varying from context to context to context, in the past.

For example
  for (i=1; i<=i1; ++i) ...
or
  for (i = 1; i <= i1; ++i) ...

> It's
>the same principle with the template parameters.

There is no general principle that putting in space helps the reading. In
the example above
  for ( i = 1 ; i <= i1 ; ++ i ) ...
does not improve the reading. In the past, one might have had the need of
techniques grouping the closing brackets so one gets the right count, but
nowadays one simply uses an editor that matches them for you.

Thus, for the template arguments, the typographically correct way is
    list<list<int>>
and nothing else.

-- It is another story that C++ was designed to not admit it. But the
reason for designing it so was not to improve reading, that is quite
clear.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <vllmor70dh.fsf@telgt.cs.uu.nl>, Ren    van Oostrum
<rene+gnus@cs.uu.nl> wrote:
>  Hans Aberg> The normal typesetting rule, though, is to not have any
>  Hans Aberg> extra space there.
>
>Do you have a reference for this "normal typesetting rule", especially
>to the part that refers to the closing brackets of nested template
>arguments?

Your comment is somewhat confusing, because template arguments are
something specific to C++, and such code is normally not typeset, but
often is typed with a monospace font. The template arguments mimics
"<...>" brackets, which are used in math notation. The brackets theselves
are not present in the input character set used by C++; instead one uses
the inequality signs.

In the seventies, I read texts describing such rules, but I have forgotten
which. People on the TeX newsgroups and LaTeX lists surely know about such
references. There are books describing it, and they are not entirely
consistent on all features.

As for computer languages, I noticed that in books from the eighties, code
was often typeset normally, not with a monospace font.

Somehow, there has been a shift in favor for the use of a mono-space
fonts, probably because it is hard to get a good column alignment
otherwise. With Unicode present, and/or better editors, that much change
back to normality again (without monospace fonts).

But this mono-space font fad seems to influence the design of computer
languages, including C++ then.

But look into any math or physics book with brackets to check if the
typeset it as "< a , b >" or "<a, b>". Even the famous lambda calculus has
no computer language spaces in math (for example Church's original book):
It is "(lxf)", l = lambda, and not with the extra spaces used in LISP,
Scheme, etc.

>  Hans Aberg> But, returning to C++, both of
>  Hans Aberg>   list<list<int> >
>  Hans Aberg>   f (x)
>  Hans Aberg> looks like hell to me.
>
>To me too. I prefer to write them as follows:
>
>  list< list< int > >
>  f( x )
>
>Nicely symmetric, sufficient whitespace to distinguish the important
>parts, and it doesn't upset the compiler.

This looks even worse to me.

>  Hans Aberg> But in math, one gets used to reading different
>  Hans Aberg> notational styles. It is possible to live with it.
>
>s/math/C\+\+/

If you refer to TeX here, its style of writing math is not very good. --
In fact some people try to produce a better math authoring language.

We risk of getting off topic here, but the connection with the development
of the C++ standard is probably this:

I am aware of these heated discussions about style and computer languages
designed trying to enforce it. It is a fact though, that from the point of
view of typesetting math and relating topics, one is often very off from
the very start in these discussion.

It may have to do with the limited character set available.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

When using nested template arguments, one can write either
  list<vector<int>> lv;
or
  list<vector<int> > lv;
The difference being in the ">>" or "> >" kets. (Following Feynman, in
physics "<" is called a "bra" and ">" a "ket".)

The former variation my compiler rejects, because it is confused with
operator>>(), so I must use the latter.

But what does the standard say? That is, is it indicated somewhere whether
">>" and "<<" are context free symbols, so that those character
combination cannot be used in template arguments.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> When using nested template arguments, one can write either
>   list<vector<int>> lv;
> or
>   list<vector<int> > lv;
> The difference being in the ">>" or "> >" kets. (Following Feynman, in
> physics "<" is called a "bra" and ">" a "ket".)

<OT>No, in physics, <...| is a bra, and |...> is a ket.</OT>

> The former variation my compiler rejects, because it is confused with
> operator>>(), so I must use the latter.

More exactly, the lexer (which only knows about tokens, not about
operators) sees two consecutive '>' not separated by whitespace,
and according to the rule that tokens are as long as possible,
it generates the token FAST_FORWARD, not the two tokens PLAY PLAY
(I supposedly don't use the meanings they have in C++).
The lexer doesn't know anything about the program construct the
letters are part of. According to the lexer, the text could as
well be no program at all, the the resulting token stream could
be passed to a video recorder control program (which then does
what my artifical token naming says). Of course, a sensible
programmer of a C++ compiler would rather use names like
SHIFT_RIGHT and GREATER for the tokens.

The parser only gets those tokens (and doesn't care from which
letters they came, indeed, it doesn't know it). So (re-using the
names from above), it knows that a template type has the
(very much simplified) production rule
  TemplateType = NAME REVERSE_PLAY Type PLAY | ...
and the production rule of Type is (again simplified)
  Type = TemplateType | KEYWORD("int") | ...

Now, if you give the compiler the code
  list<vector<int> > lv;
the lexer generates the tokens
  NAME("list") REVERSE_PLAY NAME("vector") REVERSE_PLAY KEYWORD("int")
  PLAY PLAY NAME("lv") TERMINATOR
and the parser sees that the beginning can be parsed as
  TemplateType
    -> NAME("list") REVERSE_PLAY Type PLAY
    -> NAME("list") REVERSE_PLAY TemplateType PLAY
    -> NAME("list") REVERSE_PLAY NAME("vector") REVERSE_PLAY Type
       PLAY PLAY
    -> NAME("list") REVERSE_PLAY NAME("vector") REVERSE_PLAY
       KEYWORD("int") PLAY PLAY

But if you write
  list<vector<int>> lv;
the parser will produce
  NAME("list") REVERSE_PLAY NAME("vector") REVERSE_PLAY KEYWORD("int")
  FAST_FORWARD NAME("lv") TERMINATOR
And the compiler cannot find any production rule which uses
FAST_FORWARD at this place.

>
> But what does the standard say? That is, is it indicated somewhere whether
> ">>" and "<<" are context free symbols, so that those character
> combination cannot be used in template arguments.

The standard says the program is tokenized quite early (even the
preprocessor is working on tokens, not on text). Also, the
standard doesn't say that a nested template may be terminated
with a shift right token. Therefore the compiler rightfully
rejects your first line.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1704011132050001@du137-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>When using nested template arguments, one can write either
>  list<vector<int>> lv;

No, they can't write this.

>or
>  list<vector<int> > lv;
>The difference being in the ">>" or "> >" kets. (Following Feynman, in
>physics "<" is called a "bra" and ">" a "ket".)
>
>The former variation my compiler rejects, because it is confused with
>operator>>(), so I must use the latter.

Correct, you can't write it.

>But what does the standard say? That is, is it indicated somewhere whether
>">>" and "<<" are context free symbols, so that those character
>combination cannot be used in template arguments.

I don't have the section handy, but it definitely lays out that
the first form will be an error.  This is a well know issue.
Check out http://www.comeaucomputing.com/techtalk/templates/#shiftshift
--
Greg Comeau                 Comeau C/C++ 4.2.45.2 "it's so close"
ONLINE COMPILER ==>         http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo!       NEW: Try out our C99 mode!
comeau@comeaucomputing.com  http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

>>>>> On Tue Apr 17, Hans writes:

> But what does the standard say? That is, is it indicated somewhere
> whether ">>" and "<<" are context free symbols, so that those
> character combination cannot be used in template arguments.

The C++ scanner is greedy, and so >> will always mean the right shift
operator, and will never be interpreted as two greater than symbols,
even where such an interpretation is the only one that makes sense.

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

| When using nested template arguments, one can write either
|   list<vector<int>> lv;

No, you can't and you don't want to write the above.

| But what does the standard say? That is, is it indicated somewhere whether
| ">>" and "<<" are context free symbols, so that those character
| combination cannot be used in template arguments.

"<<" is always a single token.  Same for ">>".

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> When using nested template arguments, one can write either
>   list<vector<int>> lv;
> or
>   list<vector<int> > lv;
> The difference being in the ">>" or "> >" kets. (Following Feynman, in
> physics "<" is called a "bra" and ">" a "ket".)
>
> The former variation my compiler rejects, because it is confused with
> operator>>(), so I must use the latter.
>
> But what does the standard say? That is, is it indicated somewhere whether
> ">>" and "<<" are context free symbols, so that those character
> combination cannot be used in template arguments.

This is covered, I think, by the phases of compilation.
Tokenization occurs early, and >> is a single token.
The grammar is defined (as seems to be conventional)
in terms of tokens, and the >> token has no connection
with templates.  While it might be possible (though
not trivial) to hack the grammar to allow >> where
> > ought to be legal, a better solution given our
current position would be to make compilers give
more helpful error messages.

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> When using nested template arguments, one can write either
>   list<vector<int>> lv;
> or
>   list<vector<int> > lv;
> The difference being in the ">>" or "> >" kets. (Following Feynman, in
> physics "<" is called a "bra" and ">" a "ket".)
>
> The former variation my compiler rejects, because it is confused with
> operator>>(), so I must use the latter.

Your compiler is not confused; it is following the rules in the C++
standard.

Section 2.4 of the standard says that a token is the longest sequence
of characters that could possibly constitute a token. Given the character
sequence:
 list<vector<int>>
we have this decomposition into tokens:
 list < vector < int >>
which is a syntax error.

Other language designs are possible, and alternatives were discussed
within the C++ committee, but that is the C++ rule.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]