John Nagle <nagle@animats.com> writes:

| Gabriel Dos Reis wrote:
|
| > John Nagle <nagle@animats.com> writes:
|
| > |      All I want here is to make "operator[]" work just like
| > | "operator()".  That's a fix, not a research problem.
| >
| > a fix in search of problem-to-fix then? :-)
|
|
|     I'm thinking more in terms of number-crunching
| applications, where 2D matrices are useful but are
| not necessarily arrays of array objects.

I realized you stated this in a previous message (perhaps not exactly
with the words).  I would like to make myself clear: I do understand
needs for number crunching applications to be efficient (I myself have
a partly number crunching job).

However I do not feel there is anything broken, that needs to be
fixed; hence my smiley.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 16 Aug 2002 18:55:28 GMT, Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
>  news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:
>
> | On 16 Aug 2002 15:00:09 GMT, Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
> | >  news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:
> | >  [...]
> | > |  When you have a matrix type
> | > | or a two-dimensional-rectangular-array type on the other hand, then [,]
> | > | makes sense.
> | >
> | >  So does [][].
> |
> | Yes, but it doesn't mean the same thing. It implies the existence of a
> | self-contained, vector-like entity within the two-dimensional-rectangular-
> | array or the matrix.
>
>  A two-dimensional entity implies the existence of a one-dimensional
>  entity obtained by slicing.

It doesn't imply a self-contained one. It certainly doesn't imply
sub-entities in the sense of (OO-) sub-objects.

>  Those founds of currying might explain this better than I ;-)

Currying *creates* new functions. It doesn't extract existing sub-
entities. You can see [][] as forcing currying, which actually happens
to be exactly my criticism.

-- Niklas Matthies
--
Who we are and who we become depends, in part, on who we love.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:

| On Fri, 16 Aug 2002 18:55:28 GMT, Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
| >  news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:
| >
| > | On 16 Aug 2002 15:00:09 GMT, Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
| > | >  news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:
| > | >  [...]
| > | > |  When you have a matrix type
| > | > | or a two-dimensional-rectangular-array type on the other hand, then [,]
| > | > | makes sense.
| > | >
| > | >  So does [][].
| > |
| > | Yes, but it doesn't mean the same thing. It implies the existence of a
| > | self-contained, vector-like entity within the two-dimensional-rectangular-
| > | array or the matrix.
| >
| >  A two-dimensional entity implies the existence of a one-dimensional
| >  entity obtained by slicing.
|
| It doesn't imply a self-contained one.

Surely, but nothing in [][] suggest a self-contained one.
Indeed, the proxy idiom (returning rows and column slices) is well
known.

| >  Those founds of currying might explain this better than I ;-)
|
| Currying *creates* new functions.

Thanks, I /know/ _what_ currying is -- and I think everyone here knows
what it is.  Just look at the first [] as creating a new function --
and that is, in effect, what the proxy idiom does.

| It doesn't extract existing sub-entities.

It is a matter of view.

1) creating a function out of an existing one is creating sub-entities in
   my book -- more precisely, some of the pedantics here talk of
   "applications partielles"

2) Nothing in [][] suggests a sub-entity -- it just suggests an entity
   pretty much like the [x, .] does.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Niklas Matthies wrote:

> Currying *creates* new functions. It doesn't extract existing sub-
> entities. You can see [][] as forcing currying, which actually happens
> to be exactly my criticism.


     That's a good point.  Currying is an interesting
concept, but it's not one that C++ has.  It's a better
fit to a purely functional language than a procedural
one like C++.

     This discussion started me thinking about the
interaction of currying, objects, side effects, and
template instantiation.  I don't think we want to go there.

     All I want here is to make "operator[]" work just like
"operator()".  That's a fix, not a research problem.

    John Nagle
    Animats


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen (hyrosen@mail.com) writes

>> In any case the class above should be rather rare thing.
>> I even could not imagine where it should be needed at all.

HR> This attitude is the reason why most so-called proposals will
HR> be rejected out of hand. When a new feature is proposed, every
HR> possible circumstance must be accounted for, because the compiler
HR> is going to have to do *something* when it sees it. Leaving things
HR> unspecified, or hemming in a new feature with a ton of restrictions
HR> so that only the "common" case is legal are sure ways for a proposal
HR> to fail.

Sure my English could be much better than it is. Maybe I was not clear
enough. So, in no way I am proposing to leave this case unspecified or
to bundle any artificial restrictions with it. Instead I am saying that
it would be rather natural if multiple argument operator[][]... in the
case described would follow C++ `hungry' parsing rules. Though as it
was stated by Gabriel Dos Reis this could imply interleaving lexical
and semantical analysis.

HR> Allowing a comma-separated argument list for operator[] at least has
HR> a chance. Trying to assign a user-defined meaning to multiple []s is
HR> dead in the water. It's simple to specify the behavior of the former
HR> and complicated to specify the behavior of the latter.

--
Pavel

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

| Niklas Matthies wrote:
|
| > Currying *creates* new functions. It doesn't extract existing sub-
| > entities. You can see [][] as forcing currying, which actually happens
| > to be exactly my criticism.
|
|
|      That's a good point.  Currying is an interesting
| concept, but it's not one that C++ has.

Agreed.

| It's a better
| fit to a purely functional language than a procedural
| one like C++.

Certainly, it is better supported by functional languages, but that
doesn't mean non-functional languages cannot have support for it.  And
to some extent, C++ has some support for it either through the
standard binders and function objects or throught the classic
proxy-idiom.

Well, the real discussion isn't about currying.

[...]

|      All I want here is to make "operator[]" work just like
| "operator()".  That's a fix, not a research problem.

a fix in search of problem-to-fix then? :-)

--
Gabriel Dos Reis, gdr@intgerable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:

> John Nagle <nagle@animats.com> writes:

> |      All I want here is to make "operator[]" work just like
> | "operator()".  That's a fix, not a research problem.
>
> a fix in search of problem-to-fix then? :-)


    I'm thinking more in terms of number-crunching
applications, where 2D matrices are useful but are
not necessarily arrays of array objects.  They
may be PODs, or sparse, or triangular, or even
hashes.  Such objects often don't have an efficiently
realized row representation.

    John Nagle
    Animats


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
....
>      I think all the major issues have been raised.  Nobody has really
> said anything new in a while, and nobody has found a killer reason
> not to do this.  So how do I formally propose this to the C++ committee?

Well, the first step is to convince some implementor somewhere to
implement this feature as an extension the C++ language. Then, convince
a sufficiently large group of people to try out the extension, so you
can find out how well it works. Once enough people have some real-life
experience using the feature, if it still seems like a good idea, you
should then try to find a committee member to propose the idea
officially; it helps if that committee member is one of the many people
who've been trying out the idea.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

news comp.std.c++ expires-2002-09-01@nmhq.net (Niklas Matthies) wrote in
message news:<slrnal613n.sl.news comp.std.c++
expires-2002-09-01@nightrunner.nmhq.net>...
> On Tue, 6 Aug 2002 18:10:43 GMT, Gabriel Dos Reis
> <gdr@soliton.integrabl e-solutions.net> wrote:
> >  John Nagle <nagle@animats.com> writes:
>  [???]
> >  But with your proposal, we would have three possible interpretations

> >     tab[i, j]  is equiivalent to tab[(i, j)]  // #1
> >  or
> >     tab[i, j] is equivalent to tab[operator,(i, j)] // #2
> >  or
> >    tab[i, j] is not equivalent to tab[(i, j)]  // #3

> >  in the language.  If you remove #1, then you break compatibility
> >  with C and earlier C++ versions -- I don't think that breaking
> >  compattibility with C is a good thing especially when influencial
> >  people in the design of C++ are arguing for more compatibiltiy.  At
> >  least, the semantics breakage isn't a road I would want to take
> >  unless it is proven a real benefit that worths it.

> Unless there is any evidence that production code exists that uses #1
> or #2 (and there is already some evidence to the contrary), I don't
> see a problem with removing it, since it's a really obscure
> construction in current C++ coding practice.

You've got it backwards.  Unless there is proof that no production code
exists that uses #1 or #2, we really can't change their semantics.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 10 Aug 2002 11:38:06 GMT, James Kanze <kanze@gabi-soft.de> wrote:
>  news comp.std.c++ expires-2002-09-01@nmhq.net (Niklas Matthies) wrote in
>  message news:<slrnal613n.sl.news comp.std.c++
>  expires-2002-09-01@nightrunner.nmhq.net>...
> > On Tue, 6 Aug 2002 18:10:43 GMT, Gabriel Dos Reis
> > <gdr@soliton.integrabl e-solutions.net> wrote:
> > >  John Nagle <nagle@animats.com> writes:
> >  [???]
> > >  But with your proposal, we would have three possible interpretations
>
> > >     tab[i, j]  is equiivalent to tab[(i, j)]  // #1
> > >  or
> > >     tab[i, j] is equivalent to tab[operator,(i, j)] // #2
> > >  or
> > >    tab[i, j] is not equivalent to tab[(i, j)]  // #3
>
> > >  in the language.  If you remove #1, then you break compatibility
> > >  with C and earlier C++ versions -- I don't think that breaking
> > >  compattibility with C is a good thing especially when influencial
> > >  people in the design of C++ are arguing for more compatibiltiy.  At
> > >  least, the semantics breakage isn't a road I would want to take
> > >  unless it is proven a real benefit that worths it.
>
> > Unless there is any evidence that production code exists that uses #1
> > or #2 (and there is already some evidence to the contrary), I don't
> > see a problem with removing it, since it's a really obscure
> > construction in current C++ coding practice.
>
>  You've got it backwards.  Unless there is proof that no production code
>  exists that uses #1 or #2, we really can't change their semantics.

My opinion is that this is not an absolute law, and should not be.
I respect the position that no conceivable code that would be legal
under the current standard should under any circumstances ever be broken
by a future standard (which is equivalent to what you are saying, since
it is, for all practical purposes, impossible to prove what you are
asking for), and the committee members of course are free to assume that
position. Whether they will do that remains to be seen though, unless I
missed some ISO rule to the contrary...

-- Niklas Matthies
--
A mathematician is a machine for converting coffee into theorems.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Niklas Matthies wrote:

> On Sat, 10 Aug 2002 11:38:06 GMT, James Kanze <kanze@gabi-soft.de> wrote:
>> You've got it backwards.  Unless there is proof that no production code
>> exists that uses #1 or #2, we really can't change their semantics.
>>
>
> My opinion is that this is not an absolute law, and should not be.
> I respect the position that no conceivable code that would be legal
> under the current standard should under any circumstances ever be broken
> by a future standard (which is equivalent to what you are saying, since
> it is, for all practical purposes, impossible to prove what you are
> asking for), and the committee members of course are free to assume that
> position. Whether they will do that remains to be seen though, unless I
> missed some ISO rule to the contrary...


     Does the Committee have a formal position on what level of
backwards compatibility is required?

     We could actually maintain backwards compatibility by
having "operator[]" for built-in arrays use only the
value of the last operand.  That would emulate the current
semantics of the comma operator.  But that seems ugly.

     If you find something like "tab[1,2]" in existing
code, it's probably a mistake.  Do any of the major
CASE tools (Purify, etc.) report this as an error?

     John Nagle
     Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

news_comp.std.c++_expires-2002-09-01@nmhq.net (Niklas Matthies) wrote in
message
news:<slrnale8kk.r6.news_comp.std.c++_expires-2002-09-01@nightrunner.nmhq.net>...
> On Sat, 10 Aug 2002 11:38:06 GMT, James Kanze <kanze@gabi-soft.de> wrote:
> >  news comp.std.c++ expires-2002-09-01@nmhq.net (Niklas Matthies) wrote in
> >  message news:<slrnal613n.sl.news comp.std.c++
> >  expires-2002-09-01@nightrunner.nmhq.net>...
> > > On Tue, 6 Aug 2002 18:10:43 GMT, Gabriel Dos Reis
> > > <gdr@soliton.integrabl e-solutions.net> wrote:
> > > >  John Nagle <nagle@animats.com> writes:
>  [???]
> > > >  But with your proposal, we would have three possible interpretations
>
> > > >     tab[i, j]  is equiivalent to tab[(i, j)]  // #1
> > > >  or
> > > >     tab[i, j] is equivalent to tab[operator,(i, j)] // #2
> > > >  or
> > > >    tab[i, j] is not equivalent to tab[(i, j)]  // #3

> > > >  in the language.  If you remove #1, then you break
> > > >  compatibility with C and earlier C++ versions -- I don't think
> > > >  that breaking compattibility with C is a good thing especially
> > > >  when influencial people in the design of C++ are arguing for
> > > >  more compatibiltiy.  At least, the semantics breakage isn't a
> > > >  road I would want to take unless it is proven a real benefit
> > > >  that worths it.

> > > Unless there is any evidence that production code exists that uses
> > > #1 or #2 (and there is already some evidence to the contrary), I
> > > don't see a problem with removing it, since it's a really obscure
> > > construction in current C++ coding practice.

> >  You've got it backwards.  Unless there is proof that no production
> >  code exists that uses #1 or #2, we really can't change their
> >  semantics.

> My opinion is that this is not an absolute law, and should not be.

It's not an absolute law, but it does mean that unless there is some
proof, the change must have exceptionally high benefits.  At one
extreme, we have the change from new returning null, to new throwing.
This broke enormous amounts of real code, and is still causing problems
today.  But the benefits are enormous as well -- try specifying a
version of the STL where all of the functions which might allocate
memory have return codes to indicate failure.

In the case currently in question, the benefits are minor.  Real, but
minor, since there exists several perfectly acceptable work-arounds.

Realistically, what we really want is a way to overload operator[][], or
operator[][][], or ...  Or more generally, any chaining of operators: it
would be nice to be able to handle a[] = ... differently than when a[]
is an rvalue.

> I respect the position that no conceivable code that would be legal
> under the current standard should under any circumstances ever be
> broken by a future standard (which is equivalent to what you are
> saying, since it is, for all practical purposes, impossible to prove
> what you are asking for), and the committee members of course are free
> to assume that position. Whether they will do that remains to be seen
> though, unless I missed some ISO rule to the contrary...

The committee is free to define a whole new language, replacing { and }
with BEGIN and END, and who knows what all else.  The Fortran committee
actually did just that at one point.  But I don't see any consensus for
that level of change in C++.  If something can be proved seriously
broken, with no workable workaround, it will be changed, regardless of
the user code it breaks.  But if something can break user code, the
threshold will be high to accept it, and if the are simple, not to
difficult work-arounds without the change, I'd be very surprised if it
were accepted.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6651fb6.0208130308.19932c57@posting.google.com>,
kanze@gabi-soft.de (James Kanze) wrote:

>The committee is free to define a whole new language, replacing { and }
>with BEGIN and END, and who knows what all else.  The Fortran committee
>actually did just that at one point.

Or to rename C++ "Fortan"? :-)

>  But I don't see any consensus for
>that level of change in C++.

In the C++0x announcement, BS said he wanted no major changes to the C++
language. My feeling about multivariate operator[] is that it is just a
silly little detail, so from that point of view, it may slip through.

>  If something can be proved seriously
>broken, with no workable workaround, it will be changed, regardless of
>the user code it breaks.  But if something can break user code, the
>threshold will be high to accept it, and if the are simple, not to
>difficult work-arounds without the change, I'd be very surprised if it
>were accepted.

As for the multivariate operator[], the pleasant thing is that it puts it
into the same category as the other operators. -- I think that the C++0x
announcement said something about one should try to achieve C++ relying on
general principles.

In article <3D5884DC.7020208@animats.com>, John Nagle <nagle@animats.com> wrote:
>     Does the Committee have a formal position on what level of
>backwards compatibility is required?

Then, as for multivariate operator[], it will in the end be a matter of
taste whether one would want to risk braking old code. -- There certainly
appears to be no such major code, and there is an easy fix, writing a[(x,
y)] instead of a[x, y] in applicable cases.

>     We could actually maintain backwards compatibility by
>having "operator[]" for built-in arrays use only the
>value of the last operand.  That would emulate the current
>semantics of the comma operator.  But that seems ugly.

I think that the best solution would be to let multivariate operator[]
adapt the same argument syntax as operator(), with the risk of breaking
old code then. Get a compiler implementation and see how matrix libraries
benefit from it.

Then, a proposal might mention other possibilities, which invariably will
be more complex. Say like a[x, y] is interpreted as
a.operator[](operator,(x, y)) unless a.operator[](x, y) has been defined.

But such workaround makes the structure of C++ more complex, so the
question is whether there is any point making the change to the language
then.

Summing it up, the multivariate operator[] question is somewhat esoteric
-- one can live without it. So unless there are some good benefits shown
resulting from it, it will probably not be added.

Now, I think that such benefits may show up in matrix libraries: In 2D-4D,
it may help programmers in graphics, especially those that do not know
much about general C++, like students, but also those that use the
libraries a lot. Also, it may make libraries using sporadic matrices more
streamlined and easier to implement.

But then one would probably want to see that in practise, in actual libraries.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6651fb6.0208130308.19932c57@posting.google.com>, James
Kanze <kanze@gabi-soft.de> writes
>Realistically, what we really want is a way to overload operator[][], or
>operator[][][], or

and that is a proposal that I would back. Might even make it myself:)

>...  Or more generally, any chaining of operators: it
>would be nice to be able to handle a[] = ... differently than when a[]
>is an rvalue.

That becomes interesting, but can parser technology cope? But I would
also like to be able to overload operators for fundamental types when
the mixture is not that provided by the standard. E.g:

long operator / (long, int);


--
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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:

> In article <d6651fb6.0208130308.19932c57@posting.google.com>, James
> Kanze <kanze@gabi-soft.de> writes
>
>> Realistically, what we really want is a way to overload operator[][], or
>> operator[][][], or


     That creates an ambiguity if you have both "operator[]" and
"operator[][]" defined.


>> ...  Or more generally, any chaining of operators: it
>> would be nice to be able to handle a[] = ... differently than when a[]
>> is an rvalue.
>
> That becomes interesting, but can parser technology cope?


    That creates a context sensitivity in the grammar, which
is generally undesirable.  The context sensitivities we
have now (mostly involving typenames) are already trouble spots.
They're there for historical C-related reasons.

    Related to this are the occasional calls for resolving
overloads on return type, which seems neat until you
think about resolving "f(g(h(x)))" in the presence of
multiple overloads.

    The obvious syntax, "tab[i,j]" is straighforward
from a parsing standpoint.  It's a one-line change in
the grammar.

     John Nagle
     Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 13 Aug 2002 15:05:56 GMT, James Kanze <kanze@gabi-soft.de> wrote:
> news_comp.std.c++_expires-2002-09-01@nmhq.net (Niklas Matthies) wrote:
> > On Sat, 10 Aug 2002 11:38:06 GMT, James Kanze <kanze@gabi-soft.de> wrote:
> > > news comp.std.c++ expires-2002-09-01@nmhq.net (Niklas Matthies) wrote:
[...]
> > > > Unless there is any evidence that production code exists that uses
> > > > #1 or #2 (and there is already some evidence to the contrary), I
> > > > don't see a problem with removing it, since it's a really obscure
> > > > construction in current C++ coding practice.
>
> > >  You've got it backwards.  Unless there is proof that no production
> > >  code exists that uses #1 or #2, we really can't change their
> > >  semantics.
>
> > My opinion is that this is not an absolute law, and should not be.
>
>  It's not an absolute law, but it does mean that unless there is some
>  proof, the change must have exceptionally high benefits.

That's your humble opinion. If the code that would be broken is of quite
questionable nature anyway, why should exceptionally hight benefits be
needed to outweigh breaking such code?

The benefits have to be considered in relation to the harm that would be
inflicted by breaking the affected code. If the estimated harm is quite
limited, the estimated benefit need not be prodigious for the change to
be profitable.

>  Realistically, what we really want is a way to overload operator[][], or
>  operator[][][], or ...  Or more generally, any chaining of operators:

Hmm, I don't think I would really want that.
At the very least, I consider it a seperate issue.

The main objective for multi-argument operator[], as far as I am
concerned, is to streamline it with operator(). It simplifies the
language while giving more freedom. That's what _I_ really want.

-- Niklas Matthies
--
Pain is inevitable. Suffering is optional.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6651fb6.0207310652.da12b15@posting.google.com>,
kanze@gabi-soft.de (James Kanze) wrote:

>> I think that the greatness of the benefit is in the mind of the
>> programmer:
>
>The greatness of the benefit is very dependant on the cost of the
>alternatives.  I agree that matrix[i,j] is nicer than matrix(i,j).  But
>how much nicer?  Enough to risk breaking someone else's code?  Enough to
>go back on a promis?

There was a suggestion to work through some archives. Some preliminary
searches suggests that the code breaks would not be large. And code-breaks
that do occur may be easy to fix: If "operator," is overloaded, change
    a[x, y] --> a[(x, y)]
The new compilers will probably complain if "operator," has been
overloaded and is used as in a[x, y].

For those that now overload "operator," in order to be able to write a[x,
y], they should rewrite the code, because the use of user-defined
"operator," is too generally applicable in code, and therefore not safe.
Thus one should switch to a safe syntax.

>In the end, of course, it is a matter of opinion.  My opinion is that
>the standard is a promis to users: modifying it to allow them to do
>things that they couldn't do before is OK, but I need really serious
>reasons to take something away from them, even it is something that *I*
>am convinced shouldn't be used, and that I don't use myself.

I think that the reason that this topic comes up is that people want to
add a library for matrices. One such application is in graphics, which is
now in very widespread use in personal computers.

Since this might then have a very widespread usage, by people not deeply
involved in heavy math then and may use the syntax a lot, it might be
prudent to introduce a safe syntax. -- Cf., the C++0x educational
objective.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

[...]

| When I see x[n] I expect that to be element n of a container called x
| (yes I know we could interchange x and n for arrays). When I see x(n) I
| expect x to be a function called with n as its argument. Now when I see
| x(n, m) I still expect x to be a function and will be a little surprised
| that it is a container.

Except when the code is driven by application domain principles,
where for example a column is designated by [j] and a row by (i) :-)

[...]

| I believe that breaks nothing and is well within the capabilities of
| modern compiler technology. It provides consistency within C++ even if
| not exactly the format used by numerical domain specialists.

Oh well, that is fine. But then it should be argued that the proposal
is for making numerical domain specialists feel more comfortable!

That is, I'm not opposing to multivariate operator[] per se.  It is
the argumentation which seems unconvincing to me -- especially when it
is about numericists who already have their own notational conventions
:-)

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3wur942n9.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@integrable-solutions.net> wrote:
|
| >| >The general notation of a matrix isn't $m_{ij}$.
| >| >My book use $m^{ij}$, $m_i^j$, $m(i,j)$.
|
| >| So I must be right: You are using a new definition of the word "general"
| >| that I must be unaware of. :-) -- Please state your definition.
|
| >If it is the phrase "my book" that is chocking you, ...
|
| I am quite hard to chock. But the use of the word "general", I must admit,
| is chocking. :-)

Why?  Here is how it all began:

 # | I thought I gave one such principle: Admitting general type of
 # | subscripting used in math, with application to matrices.
 #
 # But, I'm questionning your general principial.  As fas as I can tell,
 # the general notation in Linear Algebra is not subscription.

It is *you* who first tried to put in "general" in the discussion.
Then the burden is on you, not me.

[...]

| But here we are focused on the more limited subject of implementing
| matrices in C++.

Excellent.  That also is my focus in your argumentation.

| >| Note that above, I used words like "commonly", because in math, one can of
| >
| >Well, I guess your "commonly" depends on how broad the inspection is
| >conducted.  If limited to an office or a university, then I won't
| >disupte it ;-)
|
| Well, I made a turn over the world, including the place where Einstein had
| a job towards the end of his life.

Then you must have been very selective ;-)

[...]

| The other system, which I gather is also "pure" math, but derives from the
| period before coordinate independent notions were invented in the 1930'es
                                                                    ^^^^^^^
| or something, is that coordinates that (with respect to a change of basis)
| transforms as basis elements are subscripted, and those that transforms as
| vectors are superscripted. This is also the system mainly used by
| physicists when describing tensors.

That allegation is certainly wrong.  See the references I gave to the
"Ricci Calculus".

[...]

| If you are interested in those syntactic/grammatic matters, you might find
| it enjoyable and interesting working with a lexer/parser generator
| combination (there is also ANTLR http://antlr.org, which I think can
| generate C++, and might be easier to use).

In my "spare" time, I do some job on C++ compiler constructions -- and
ways to extend C++ (grammar) for additional features. I read the
thesis of Terrence Parr; studied enough about lexing and parsing to
decide that they don't meet my primary interests field ;-)
I'm more interested in semantics.  This may explain that :-)

| >  My top most interest
| >in C++ is about its semantics expressivity, and its usability as a
| >practical tool. In my quest, syntax comes after semantics.
|
| Well, in math, notions (semantics) and notation (syntax) should properly
| go hand in hand.

But, most of the time I've seen people investing too much in syntax,
with no time left for semantics; that, IHMO, correponds to much ado
for nothing.

| >| If one should use as argument the fact that a certain corny syntax has
| >| been in use a long time (as the language did not admit anything else) to
| >| prevent the changes, then that argument could always be used to prevent
| >| any kinds of changes:
|
| >Oh, you're already using that argument, but in the sense of breaking
| >previous commitment: You're basing your argumentation on the fact
| >that "[]" has been The way C (and later C++) expresses subscription.
|
| >There is no reason why you'd be OK to use it to break semantics of previous
| >C++ relseases and it wouldn't be OK to use it to retain compatibility.
|
| The development principles for C++ are:

Where did you get them?  I read D&E where the creator of C++ exposes
his understanding of C++, and I can't find this:

| If the code breaks aren't too common, and the fixes not overly difficult,
| then one should break compatibility if that helps up the language.

Would you care to give references?

In D&E, Bjarne discusses syntactical issues around C and C++ [ section
2.8 is highly instructive, especially "2.8.3 The Importance of Syntax" :-)]

[...]

| As for the proposed change in the operator[], it does not look as though a
| "major change".

I guess how major is major depends on how you look at it.

[...]

| -- If I can come up with an operator precedence system that seems very
| suitable for C++, then I will report it here. But it will probably not be
| accepted, unless one can see fairly easily that it is the right thing for
| C++.

If you can provide evidences that your hypothetical system solves
major programming problems with C++, I think people will highly
consider it.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat,  3 Aug 2002 19:04:34 GMT, Kresimir Fresl <fresl@grad.hr> wrote:
>  Hans Aberg wrote:
>
>  [...]
> >>The function call isn't harder to parse (from a user point of view)
> >>than the proposed operator[] extension.
>
> > Sure it is, we*) even gave an example
> >     a(x, y) = b;
> >     a[x, y] = b;
>
>  Why is it harder to parse?

It's harder to parse because with [] you can be pretty sure that it
constitutes a subscripting/indexing operation (because of convention),
whereas with () you don't, and most people will first think of a
fucntion application when seeing () (again because of convention).

If backwards compatibily were a non-issue, one could theoretically argue
that there's no actual need for [] and therefore [] should completely
replaced with () in the language (including C-style array subscription).
In a similar spirit, one could abolish functions with more than one
argument, since when you want multiple arguments you can do the same as
is being done now for multi-dimensional arrays, namely chaining multiple
function calls (as in "x = f(1)(2)(3)"). While all this would in a sense
simplify the language syntax-wise, it places a burden on the programmer
(or anyone reading source code) because (in the first case) expressions
involving () become more ambiguous and (in the second case) functions
become more cumbersome both to implement and use. Having different
operators for different purposes eases readability and implementation,
and this is the point of proposing to generalize [] to any number of
arguments.

-- Niklas Matthies
--
Less matters that which you can take by yourself than that which others
have given to you.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Niklas Matthies wrote:

> On Sat,  3 Aug 2002 19:04:34 GMT, Kresimir Fresl <fresl@grad.hr> wrote:

>> Hans Aberg wrote:
>>
>> [...]
>>
>>>>The function call isn't harder to parse (from a user point of view)
>>>>than the proposed operator[] extension.
>>
>>>Sure it is, we*) even gave an example
>>>    a(x, y) = b;
>>>    a[x, y] = b;
>>
>> Why is it harder to parse?
>
> It's harder to parse because with [] you can be pretty sure that it
> constitutes a subscripting/indexing operation (because of convention),

As Gabriel Dos Reis said is his reply to Mr. Aberg's post:
``C++ [programmers] have been educated that [] is unary.  In
your expression, they have now to worry whether it is the una[a]ry
operator or a binary operator or use of an overloaded operator or the
comma operator.''

Furthermore, [] is currently unary operator and only unary operator
and therefore there is no `convention' of multiindexing operations
using [].

And there is also a `convention' of using [] as projection operator
(see Barton & Nackman' book):

    int a[3][3][3];
    // ...
    ... a[i] ...
    ... a[j][k] ...

> whereas with () you don't, and most people will first think of a
> fucntion application when seeing () (again because of convention).

``most people''? `Some' people, maybe even `many'...

And some people, maybe even many, will think that () is probably
function application, but that it also can be subscripting operation.

And some people, maybe even many, particularly those with FORTRAN
background, will think that () can be function application *or*
subscripting
operation.

And some people, who often use Mathematica, can, at least
for a moment, before switching between languages, think that
[] is function application.

And some people will not do any unsupported guesses without
knowing what `a', `b', `x' and `y' are. And if one reads code
trying to understand what it does, (s)he will know what `a' in `a[i]'
and `f' in `f(x)' mean.

> If backwards compatibily were a non-issue, one could theoretically argue
> that there's no actual need for [] and therefore [] should completely
> replaced with () in the language (including C-style array subscription).
> In a similar spirit, one could abolish functions with more than one
> argument, since when you want multiple arguments you can do the same as
> is being done now for multi-dimensional arrays, namely chaining multiple
> function calls (as in "x = f(1)(2)(3)"). While all this would in a sense
> simplify the language syntax-wise, it places a burden on the programmer
> (or anyone reading source code) because (in the first case) expressions
> involving () become more ambiguous

As [] can be ``the unary operator or a binary operator or use of an
overloaded operator or the comma operator'', expressions involving
[] become more ambiguous. And one can still overload () as
multiindexing operator ...

> and (in the second case) functions
> become more cumbersome both to implement and use. Having different
> operators for different purposes eases readability and implementation,
> and this is the point of proposing to generalize [] to any number of
> arguments.
>
> -- Niklas Matthies

fres



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m365ys1j4u.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| I have laid out the arguments on point after point very clearly, and I
>
>I did the same thing, by providing counter-examples and demonstrated
>the wrongness of premisses or the pitfalls in argumentations.

I never saw anything of that.

>  I'm
>sure you didn't see them because they didn't agree with you or because
>the postings didn't actually propagate to your news server.

Nope, the way it looked to me, the arguments you provided do not qualify
as "counter-examples" and so on, but merely were an expression of your own
strong preferences.

I deliberately chose your own tactics of trying to push through opinions
by labelling them as fact, to see what you feel about it: :-)

Clearly, as far as the development of the C++ language goes, there are no
logical rules by which one can demonstrate "counter-examples". So if
someone is using such terminology, it must be an exaggeration of some
sort.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<slrnakoua5.s5.news_comp.std.c++_expires-2002-09-01@nightrunner.nmhq.net>,
news_comp.std.c++_expires-2002-09-01@nmhq.net (Niklas Matthies) wrote:

>If backwards compatibily were a non-issue, one could theoretically argue
>that there's no actual need for [] and therefore [] should completely
>replaced with () in the language (including C-style array subscription).
>In a similar spirit, one could abolish functions with more than one
>argument, since when you want multiple arguments you can do the same as
>is being done now for multi-dimensional arrays, namely chaining multiple
>function calls (as in "x = f(1)(2)(3)").

This imposes an identification between Hom(A x B, C) and Hom(A, Hom(B,
C)). In C++, one might instead use a container, like std::vector, as the
single argument.

-- I want mention this latter approach, because I found it useful when
implementing a dynamic (runtime) system: Then it simplifies to require all
functions having only one argument.

With this approach, traditional C++ f(x_1, ..., x_n) would be equivalent
to f([x_1, ..., x_n]), where [x_1, ..., x_n] is a list object whose
computational order of the arguments one does not know.

This process then leads to a semantic classification of the C++
components, which can be used in the development of a runtime model. From
the point of view of this classification, C++ will merely select the
various semantic components.

Then syntax becomes less important, as one only needs to make sure that
the semantic components handshake. So, paradoxically, one can admit more
general syntaxes.

I gather that this goes much beyond the current development of the C++
language, but I find it still useful to keep this picture in 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.jamesd.demon.co.uk/csc/faq.html                       ]

On 5 Aug 2002 15:05:11 GMT, Kresimir Fresl <fresl@grad.hr> wrote:
>  Niklas Matthies wrote:
> > On Sat,  3 Aug 2002 19:04:34 GMT, Kresimir Fresl <fresl@grad.hr> wrote:
> >> Hans Aberg wrote:
> >> [...]
> >>>Sure it is, we*) even gave an example
> >>>    a(x, y) = b;
> >>>    a[x, y] = b;
> >>
> >> Why is it harder to parse?
> >
> > It's harder to parse because with [] you can be pretty sure that it
> > constitutes a subscripting/indexing operation (because of convention),
>
>  As Gabriel Dos Reis said is his reply to Mr. Aberg's post:
>  ``C++ [programmers] have been educated that [] is unary.

I have to admit that I haven't been "educated" that way. Of course I
_know_ that, as yet, [] can take only one argument, but I never found
that situation particularly natural, and still don't after over 10 years
of C and C++ programming. (Besides, [] is binary, not unary.)

>  In your expression, they have now to worry whether it is the una[a]ry
>  operator or a binary operator or use of an overloaded operator or the
>  comma operator.''

These programmers should already worry today when they encounter an
expression of the form "a[b, c]", since such code indicates that the
author most likely has tried to do something extra smart here. But
we've seen that such code is not present at all in large code bases that
have been looked at, so programmers are quite unlikely to already have
been particularly conditioned to that pattern of code. Hence I predict
that programmers won't have much trouble to unlearn that "[ , ]" doesn't
mean "obscure use of comma operator within index expression", but rather
"easy-to-read multi-argument indexing".

>  Furthermore, [] is currently unary operator and only unary operator
>  and therefore there is no `convention' of multiindexing operations
>  using [].

Not in C and C++, right. (Obviously). Still, there is uncontestably the
very strong convention that [] means indexing. Extending [] to multi-
argument indexing would very naturally bind to that convention. In my
humble opinion much stronger than the (in certain circles, appearently)
existing convention for multi-argument indexing with ().

>  And there is also a `convention' of using [] as projection operator
>  (see Barton & Nackman' book):

This convention would not be broken; [] with arguments would merely
generalize to multiple-argument projections (since projections can
involve any number of dimensions at once).

> > whereas with () you don't, and most people will first think of a
> > fucntion application when seeing () (again because of convention).
>
>  ``most people''? `Some' people, maybe even `many'...

Well, that's my belief, though of course I don't have any factual
evidence to prove it.

>  And some people, maybe even many, will think that () is probably
>  function application, but that it also can be subscripting operation.

Certainly. The problem is the "also", which makes () ambiguous.
As I pointed out, [] doesn't have this ambiguity.

>  And some people, maybe even many, particularly those with FORTRAN
>  background, will think that () can be function application *or*
>  subscripting operation.

I would think that people with FORTRAN background are a minority among
C++ programmers; I won't dispute that using [] for indexing might look
unnatural to them, but then so should single-argument-[] already.

>  And some people, who often use Mathematica, can, at least
>  for a moment, before switching between languages, think that
>  [] is function application.

Yes, but this doesn't constitute the average programmer, I dare say.

>  And some people will not do any unsupported guesses without
>  knowing what `a', `b', `x' and `y' are. And if one reads code
>  trying to understand what it does, (s)he will know what `a' in `a[i]'
>  and `f' in `f(x)' mean.

That's a poor argument. You can always figure out what some piece of
code does by inspecting all relevant source code and/or appropriate
documentation, but that doesn't mean that that's a particularly
efficient way do accomplish this, especially when syntax alone could
already strongly suggest what is being done (which [] is able to do more
than ()).

[         ]
>  As [] can be ``the unary operator or a binary operator or use of an
>  overloaded operator or the comma operator'', expressions involving
>  [] become more ambiguous.

I don't agree (see above). And I don't agree that it should be possible
to be both after multi-argument [] has been introduced. [] then would
_always_ be indexing (with any number of arguments, just as () is
function call with any number of arguments) and using the comma operator
will need extra parentheses, exactly as it already is the case with
operator() nowadays.

>  And one can still overload () as multiindexing operator ...

Yes, I didn't claim that it makes () less ambiguous. I claim that it
tallies with making the more likely guess for () to be the correct one
by being able to use [] for multi-argument indexing instead of ().

-- Niklas Matthies
--
Learn from the mistakes of others.
You can't possibly live long enough to make them all yourself.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D4EDE03.6080902@grad.hr>, Kresimir Fresl <fresl@grad.hr> wrote:

>>>>Sure it is, we*) even gave an example
>>>>    a(x, y) = b;
>>>>    a[x, y] = b;
>>>
>>> Why is it harder to parse?
>>
>> It's harder to parse because with [] you can be pretty sure that it
>> constitutes a subscripting/indexing operation (because of convention),

>As Gabriel Dos Reis said is his reply to Mr. Aberg's post:
>``C++ [programmers] have been educated that [] is unary.  In
>your expression, they have now to worry whether it is the una[a]ry
>operator or a binary operator or use of an overloaded operator or the
>comma operator.''

This line of thought is misleading, because it is simply so that
operator[] only takes one argument because of its heritage from C, and
no-one has ever been "educated" that it should be so: If you do otherwise,
the compiler will simply not accept it.

The C heritage is in fact one of the weaknesses of C++, because C lacks
the high-level structures that C++ introduces.

So as for multivariate operator[], there is no good way of making
effective use of that in C, but there is in C++ in the case of matrices by
making sure one does not have to pass over one-variable operator[].

>Furthermore, [] is currently unary operator and only unary operator
>and therefore there is no `convention' of multiindexing operations
>using [].

Right. This is why the multivariate operator[] is suggested.

>And there is also a `convention' of using [] as projection operator
>(see Barton & Nackman' book):

>    int a[3][3][3];
>    // ...
>    ... a[i] ...
>    ... a[j][k] ...

>> whereas with () you don't, and most people will first think of a
>> fucntion application when seeing () (again because of convention).

This would not be acceptable, as it will generate more than one function
call in situations where one want to ensure just one. Therefore, one
suggestion was operator[]...[], but multivariate operator[] seems simpler.

>And some people, maybe even many, will think that () is probably
>function application, but that it also can be subscripting operation.

It is, as a matter of fact, not the subscripting operator according to the
C++ paradigms. Whether individual programmers use C++ and program it
according their own developed paradigms is not really relevant. -- Also,
you still can use operator() for subscripting, even if there is a
multivariate operator[] introduced.

>And some people, maybe even many, particularly those with FORTRAN
>background, will think that () can be function application *or*
>subscripting
>operation.

>And some people, who often use Mathematica, can, at least
>for a moment, before switching between languages, think that
>[] is function application.

So what paradigms are used in other languages are not relevant as such for
the development of C++, even though such inputs are important when
determining the C++ paradigms.

>And some people will not do any unsupported guesses without
>knowing what `a', `b', `x' and `y' are. And if one reads code
>trying to understand what it does, (s)he will know what `a' in `a[i]'
>and `f' in `f(x)' mean.

It depends how one is reading the code: If one assumes that one is always
reading it linearly front to back, then those things will not matter. But
often one merely wants to jump in to check what certain parts are doing
(say in library code or something), moving outwards from this point. Under
such circumstances, an expressive syntax can help a lot in order to help
speeding up the procedure.

>As [] can be ``the unary operator or a binary operator or use of an
>overloaded operator or the comma operator'', expressions involving
>[] become more ambiguous.

This problem is no bigger than that of operator(), that is, none at all
with a proper proposal.

The biggest question was upwards compatibility, and there the problem is
with code a[x, y] where "operator," and operator[] have no semantic
connection: Clearly, if one is using "operator," in order to emulate a
multivariate operator[], then the introduction of the latter into C++
would come as a blessing.

But is is easy to change a[x, y] to a[(x, y)], and the latter is more
clear as to what the intent is.

> And one can still overload () as
>multiindexing operator ...

And you can still use operator(), even if there is a multivariate
operator[] introduced into C++. So you still can program C++ as though was
Fortran, even though clearly, it is not. :-)

But why should those that want to program C++ as though it was C++ be
forced to program it as though it was Fortran or even Mathematica, the
latter which gets a lot of complaints over its syntax, not relating well
to common math conventions conventions at all? (For this latter
Mathematica syntax issue, there was recently a long thread in the
sci.math.symbolic newsgroup, comparing it with Maple.)

  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.jamesd.demon.co.uk/csc/faq.html                       ]

On 5 Aug 2002 16:20:15 GMT, Hans Aberg <remove.haberg@matematik.su.se> wrote:
>  In article
> <slrnakoua5.s5.news_comp.std.c++_expires-2002-09-01@nightrunner.nmhq.net>,
>  news_comp.std.c++_expires-2002-09-01@nmhq.net (Niklas Matthies) wrote:
>
> >If backwards compatibily were a non-issue, one could theoretically argue
> >that there's no actual need for [] and therefore [] should completely
> >replaced with () in the language (including C-style array subscription).
> >In a similar spirit, one could abolish functions with more than one
> >argument, since when you want multiple arguments you can do the same as
> >is being done now for multi-dimensional arrays, namely chaining multiple
> >function calls (as in "x = f(1)(2)(3)").
>
>  This imposes an identification between Hom(A x B, C) and Hom(A, Hom(B,
>  C)).

I don't think that C++ functions are restricted to homomorphisms. :)

>  In C++, one might instead use a container, like std::vector, as the
>  single argument.

Right (though clumsy, and restricted to the element type of the vector),
but I wanted to draw the parallel with array subscription. If one says
that single-argument indexing is sufficient for [], the same reasoning
can be made to apply to ().

>  -- I want mention this latter approach, because I found it useful
>  when implementing a dynamic (runtime) system: Then it simplifies to
>  require all functions having only one argument.

I believe tuples would need to become first-class entities in C++, which
at the same time would allow for functions returning multiple values.
Both can of course already be simulated with structs; but a clean, easy
syntax would be crucial.

>  With this approach, traditional C++ f(x_1, ..., x_n) would be equivalent
>  to f([x_1, ..., x_n]), where [x_1, ..., x_n] is a list object whose
>  computational order of the arguments one does not know.

While I agree with making this sort of distinction, I wouldn't use []
for this. In conjunction with turning statement blocks into expressions,
I'd go for making ";" the computational-order-seperator (much like the
comma operator today) and "," the non-computationally-ordering seperator
(like in function argument lists today), where then both (x_1, ..., x_n)
and (x_1; ... ; x_n) would be expressions of type n-tuple (parameterized
with the types of x_1 ... x_n) where only the latter would impose an
order of evaluation on x_1 ... x_n.
Also, the parantheses would only be needed when precedence needs to be
inforced; hence (assuming that "," has higher precedence that ";") one
could just write "x_1, ..., x_n; y_1, ..., y_m; z_1, ..., z_k".

>  Then syntax becomes less important, as one only needs to make sure that
>  the semantic components handshake. So, paradoxically, one can admit more
>  general syntaxes.

Well, one needs to be careful; general yes, but also rich enough to be
conveniently parseable by humans.

>  I gather that this goes much beyond the current development of the C++
>  language, but I find it still useful to keep this picture in mind.

Certainly; it would require creating a new language.

-- Niklas Matthies
--
Learn from the mistakes of others.
You can't possibly live long enough to make them all yourself.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:

> 1) While those from a Fortran heritage are happy with using ( ) for
> subscripting, indexing etc. those from other areas are used to using [ ]
> for this purpose. I have not noticed anyone suggest that we should teach
> the use of ( ).


     It's worth noting that when FORTRAN was developed, in 1956,
square brackets were not widely available on printers.  Ada,
for backwards-compatibility reasons, was restricted to a
48-character set, and is, unfortunately, excessively wordy
for that reason.


> 2) What would really be convincing that change were needed was if
> someone demonstrated a real world piece of code where operator() was
> beneficially used for some other purpose in a type where multi-dimension
> subscripting was also desirable.


    See Strostrup, 22.4.6, Slice_array, the discussion of
Matrix.  Strostrup had to use what he calls "FORTRAN-style
subscripting", and at one point writes "undesirable mixed
style (but it works)" for the expression

  m[1](2) = 8;

    That's a painful construct, but that's where the
current syntax leads us.

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D4BF7CE.7000203@grad.hr>, Kresimir Fresl <fresl@grad.hr> wrote:

>>>The function call isn't harder to parse (from a user point of view)
>>>than the proposed operator[] extension.
>
>> Sure it is, we*) even gave an example
>>     a(x, y) = b;
>>     a[x, y] = b;
>
>Why is it harder to parse?

Because to those used to program according to C++ paradigms, the first one
leads one to think about functions, and functions usually do not return
references of subparts to themselves. It is of course possible to develop
a thoery where there is no ditcintion between functions and data, which I
have done (in a runtime model), but that ain't the C++ paradigm.

Some others also commented on this.

>In another message:

> > And when defining say matrix multiplication l := m*n, one might do
>that by
> > saying that
> >  (1)   $l_{ik} := sum_{j in J} m_{ij}*n_{jk}$
>[...]
> > In C++, when subscription is indicated by operator[], the corrsponding
> > formula might then read
> >     ...
> >     for (j=0; j < j1; ++j)
> > (2)    l[i, k] = m[i, j]*n[j, k];
> >
> > Here (2) is a very direct translation of (1).

>     for (j=0; j < j1; ++j)
>(3)    l(i, k) = m(i, j)*n(j, k);

>And (3) is not?

Same comment as above.

Strictly speaking, every language has its own paradigms, and it is a good
idea to program around those. So what Fortran, ALGOL, and A programmers do
are not as such important for C++, if C++ already has another paradigm.
When designing the C++ language, it is of course prudent to have a good
look at what other languages do, but C++ is still a separate language with
its own set of paradigms.

The C++ paradigm for computing array components and such is operator[],
not 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.jamesd.demon.co.uk/csc/faq.html                       ]

news_comp.std.c++_expires-2002-09-01@nmhq.net (Niklas Matthies) writes:

| On Sat,  3 Aug 2002 19:04:34 GMT, Kresimir Fresl <fresl@grad.hr> wrote:
| >  Hans Aberg wrote:
| >
| >  [...]
| > >>The function call isn't harder to parse (from a user point of view)
| > >>than the proposed operator[] extension.
| >
| > > Sure it is, we*) even gave an example
| > >     a(x, y) = b;
| > >     a[x, y] = b;
| >
| >  Why is it harder to parse?
|
| It's harder to parse because with [] you can be pretty sure that it
| constitutes a subscripting/indexing operation (because of convention),

However, in that case, [] is known to be unary operator for a C and
C++ programmer.  Now, he/she has to wonder whether he comma is
overloaded operator or a punctuator or the builtin operator.

| whereas with () you don't, and most people will first think of a
| fucntion application when seeing () (again because of convention).

Which subscription is, in the first place.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please do keep followups topical!


===================================== END OF MODERATOR'S COMMENT
In article <m3d6szlo9x.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@integrable-solutions.net> wrote:

>| I am quite hard to chock. But the use of the word "general", I must admit,
>| is chocking. :-)
>
>Why?  Here is how it all began:

> # | I thought I gave one such principle: Admitting general type of
> # | subscripting used in math, with application to matrices.
> #
> # But, I'm questionning your general principial.  As fas as I can tell,
> # the general notation in Linear Algebra is not subscription.
>
>It is *you* who first tried to put in "general" in the discussion.
>Then the burden is on you, not me.

Well, as far as I know, subscription for indicating components is the
general notation in pure math, if one is not using tensor notation. When
using tensor notation, one is using superscripting in order to indicate
contravariant transformation rules, but that is only necessary if one does
not write out the full basis elements: The modern books in differential
geometry using coordinates that I know of, in fact do not use
superscripting for tensors either.

So I really do not know of any pure math texts indicating what you are
speaking about. -- It would be interesting to get some examples of what
you are meaning (also see below).

>| Well, I made a turn over the world, including the place where Einstein had
>| a job towards the end of his life.
>
>Then you must have been very selective ;-)

Discriminating and exclusive is probably very true. If I would have
continued on that path, I would probably not sit here, replying to posts
on C++ notation. :-)

>| The other system, which I gather is also "pure" math, but derives from the
>| period before coordinate independent notions were invented in the 1930'es
                                                                     ^^^^^^^
>| or something, is that coordinates that (with respect to a change of basis)
>| transforms as basis elements are subscripted, and those that transforms as
>| vectors are superscripted. This is also the system mainly used by
>| physicists when describing tensors.

>That allegation is certainly wrong.

What allegation is wrong? That tensor notation preceded the coordinate
free notation?

>  See the references I gave to the
>"Ricci Calculus".

I do not recall any such references. If you a referring to spin-calculus,
like Penrose and others, then that is not even a verified physical theory,
and not a mainstream notational system:

The way I would handle spin in GR (General Relativity), is to explicitly
choose isotropic coordinates, in which case it, via the Clifford algebra,
reduces to ordinary tensors. One can then do away with tensor notation
altogether, while having the advantage of not making the choice of
isotropic coordinates implicit. (As you probably know, one must
demonstrate the physical significance of such choices.)

So it then falls into the statement that I said, mathematicians do invent
all kinds of notation, but it does not mean that it automatically becomes
of "general" usage in nature.

But, in order to return to the topic of the thread, the introduction of
multivariate operator[] into C++:

Are you planning to introduce such notation into C++?

>| If you are interested in those syntactic/grammatic matters, you might find
>| it enjoyable and interesting working with a lexer/parser generator
>| combination (there is also ANTLR http://antlr.org, which I think can
>| generate C++, and might be easier to use).

>In my "spare" time, I do some job on C++ compiler constructions -- and
>ways to extend C++ (grammar) for additional features. I read the
>thesis of Terrence Parr;

Is this the guy who gave rise to the expression "Parr-sing". :-)

> studied enough about lexing and parsing to
>decide that they don't meet my primary interests field ;-)
>I'm more interested in semantics.  This may explain that :-)

Well, one should not do that stuff, unless one is sure that it is right for you.

What one can do, is to feed the output into some macro program, which in
its turn translates it into say C++ code. If one then includes a language
construct for verbatim C++, then one can that easily introduce C++
language extensions.

The advantage of this approach is that one both does not need to hang out
so much in newsgroups like this one pushing very hard for ones own
favorite language constructs, while on the same time gaining inputs for
better suggestions of C++ developments.

>| Well, in math, notions (semantics) and notation (syntax) should properly
>| go hand in hand.
>
>But, most of the time I've seen people investing too much in syntax,
>with no time left for semantics; that, IHMO, correponds to much ado
>for nothing.

So then notions (semantics) and notation (syntax) are not going hand in
hand, as there is an over-emphasis on syntax. Right?

>| The development principles for C++ are:
>
>Where did you get them?  I read D&E where the creator of C++ exposes
>his understanding of C++, and I can't find this:
>
>| If the code breaks aren't too common, and the fixes not overly difficult,
>| then one should break compatibility if that helps up the language.
>
>Would you care to give references?

I learned those things by hanging out in this newsgroup, so that I cannot
immediately give an explicit reference:

I usually try to restructure these thoughts in terms of more general
principles, and I have an hunch that some this is then fed back into the
C++ development committee. -- Some parts of the C++0x announcement has
resemblance with some of the things that I wanted to see to come forth.

So if you look around, you may be extract the principle above implicitly
but not explicitly. :-)

>In D&E, Bjarne discusses syntactical issues around C and C++ [ section
>2.8 is highly instructive, especially "2.8.3 The Importance of Syntax" :-)]

Yes, that is pretty much what I am saying; this is why one should probably
introduce multivariate operator[]:

First, it helps up the expressivity of the semantics of matrices. Then,
the value of C-style adhering to one variable operator[] is probably
overestimated.

Thanks for the quote.

>| As for the proposed change in the operator[], it does not look as though a
>| "major change".
>
>I guess how major is major depends on how you look at it.

This is how one should interpret the term "major", as it is not
technically defined.

>| -- If I can come up with an operator precedence system that seems very
>| suitable for C++, then I will report it here. But it will probably not be
>| accepted, unless one can see fairly easily that it is the right thing for
>| C++.
>
>If you can provide evidences that your hypothetical system solves
>major programming problems with C++, I think people will highly
>consider it.

On the one hand, there seems to be a high craving for even more
(multicomponent) operator names. On the other other hand, the system must
be sufficiently conservative to easily slip into C++ without a problem.
This is not as easy as it sounds.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3ado41jau.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@integrable-solutions.net> wrote:

>| >The function call isn't harder to parse (from a user point of view)
>| >than the proposed operator[] extension.
>|=20
>| Sure it is, we*) even gave an example
>|     a(x, y) =3D b;
>|     a[x, y] =3D b;

>Yes, you gave an example.  But that doesn't mean it makes your
>argumentatioin right.  C++ have been educated that [] is unary.  In
>your expression, they have now to worry whether it is the unaary
>operator or a binary operator or use of an overloaded operator or the
>comma operator.

Yes, that is the idea of the proposal of a multivariate operator[].

Of course, there is no guarantee that everybody will be able to handle the
new mathematical objects introduced.

But I feel sure that anybody being able to cope with matrices will be able
to cope comfortably with
    a[x, y] = b;

>| After getting used to it, one will not realize how corny it is. Just take
>| the common computer programmer convention to write function calls with
>| extra space
>|     f (x)
>| even though all traditional typesetting and handwritten practises of math
>| in all fields says that there should be no such extra space.

>All?  Citation please.

Do you want me to cite all math literature I have encountered? :-)

I have found no example contradicting it. Even in Church's book on lambda
calculus, which is typewritten, he does not insert extra spaces in the
lambda constructs as is done in LISP-like computer languages.

>  I have here standard mathematical books that
>use =AB xf =BB or =AB fx =BB (with spaces where appropritate) which defea=
>ts your supposed universal practice.

(Sorry, I am not able to parse what you are writing here what does "=AB"
and "=BB" mean? -- Possibly you need to check the settings of your
newsreader so that it does not insert MIME'd character codes.)

Are these books in pure math and traditional (say from the first half of
20th century)? (If these books are modern, are they typeset using TeX, as
required in pure math these days?) -- It would be interesting to know,
because the practise of writing "f (x)" with an additional space between
"f" and "(x)" is widespread in computer programming.

One can of course write the argument to the left, as in "(x)f", but one
should then not write "(x) f" in typesetting. (Typeset math is rather
different than monospace text, as one always uses _some_ kind of spacing,
not only as large as a full character width space.)

I can also note that I have found no general use of "f x" as used in
functional languages. In math, that notation is only used for a limited
set of "elementary functions "sin x", "exp x", etc. Otherwise one always
writes f(x).

>But, computing is not mathematics.

This is important, of course, when designing a language like C++, one
makes use of a very limited character set. Mathematical notation can not
always readily be expressed.

But I think it is important to have good look at mathematical practises,
because these have evolved over a long time period of time, and are very
efficient.

>  And mathematical nottation does
>not rule programmer practices.

On this point, I think it is important to remember that every language has
its own paradigms. Thus, even though many different programming styles may
be possible within a language, the language development should not bother
about supporting them all, but merely focusing on its own paradigms.

>| I do not try to impose a very restricted personal usage onto others as to
>| put them in a strait-jacket.
>
>That is why you're insisting on [], with argumentation based on
>syntactical pitfalls ;-)

I am not insisting on multivariate operator[]. -- I only note that no
syntactic pitfalls in any sense that could affect its introduction into
C++ has been reported here.

It also seems fit well with the current development criteria of the
current C++ revision, especially the educational aspect.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D4EDE03.6080902@grad.hr>, Kresimir Fresl <fresl@grad.hr>
writes
>As Gabriel Dos Reis said is his reply to Mr. Aberg's post:
>``C++ [programmers] have been educated that [] is unary.  In
>your expression, they have now to worry whether it is the una[a]ry
>operator or a binary operator or use of an overloaded operator or the
>comma operator.''


The pedantry in my nature requires me to point out that [] is a binary
operator as it takes an object (usually a sequence) and an index of some
sort.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

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

[...]

| The C heritage is in fact one of the weaknesses of C++, because C lacks
| the high-level structures that C++ introduces.

The C heritage also contribute to C++ success.  I don't know however
what it would have been if it abandonned C compatibility.  Maybe it
would have been a great language used by only two people...

[...]

| But is is easy to change a[x, y] to a[(x, y)], and the latter is more
| clear as to what the intent is.

It is also easy to continue to use a(x, y) for multi-indexing.

[...]

| But why should those that want to program C++ as though it was C++ be
| forced to program it as though it was Fortran or even Mathematica, the

The same applies to people who think that there should be a mapping
between mathematical notations (which varies from people to people)
and C++ syntax :-)

Right now, the only serious argument I've seen is clearing the syntax.
But if we were going to clear the syntax, this proposal would have low
priority on my TODO list because it does break code and brings no
benefit worthing it, IMO.

--
Gabirel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article
| <slrnakoua5.s5.news_comp.std.c++_expires-2002-09-01@nightrunner.nmhq.net>,
| news_comp.std.c++_expires-2002-09-01@nmhq.net (Niklas Matthies) wrote:
|
| >If backwards compatibily were a non-issue, one could theoretically argue
| >that there's no actual need for [] and therefore [] should completely
| >replaced with () in the language (including C-style array subscription).
| >In a similar spirit, one could abolish functions with more than one
| >argument, since when you want multiple arguments you can do the same as
| >is being done now for multi-dimensional arrays, namely chaining multiple
| >function calls (as in "x = f(1)(2)(3)").
|
| This imposes an identification between Hom(A x B, C) and Hom(A, Hom(B,
| C)). In C++, one might instead use a container, like std::vector, as the
| single argument.

But that tells absolutely *nothing* about what the syntax should be!

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:

> However, in that case, [] is known to be unary operator for a C and
> C++ programmer.  Now, he/she has to wonder whether he comma is
> overloaded operator or a punctuator or the builtin operator.


     Actually, it's worse now.  Currently

 tab[i,j] is equivalent to tab[(i,j)]
     but
 tab(i,j) is not equivalent to tab((i,j))

The operator precedence of "," is DIFFERENT inside square brackets
and parentheses.  What I'm proposing makes them the same.

As for the unary/binary/pedantry issue, I'd suggest that
"operator()" and "operator[]" both be thought of as N-ary operators.

     I think all the major issues have been raised.  Nobody has really
said anything new in a while, and nobody has found a killer reason
not to do this.  So how do I formally propose this to the C++ committee?
Thanks.

     John Nagle
     Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m365ypj7uz.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| >If backwards compatibily were a non-issue, one could theoretically argue
>| >that there's no actual need for [] and therefore [] should completely
>| >replaced with () in the language (including C-style array subscription).
>| >In a similar spirit, one could abolish functions with more than one
>| >argument, since when you want multiple arguments you can do the same as
>| >is being done now for multi-dimensional arrays, namely chaining multiple
>| >function calls (as in "x = f(1)(2)(3)").

>| This imposes an identification between Hom(A x B, C) and Hom(A, Hom(B,
>| C)). In C++, one might instead use a container, like std::vector, as the
>| single argument.

>But that tells absolutely *nothing* about what the syntax should be!

Your quoting making it difficult to see what you mean:

As for the functional languages making that identification (not all do),
the identification makes it impossible to distinguish between f(x, y) and
f(x)(y), so they normally have only the latter.

Or what do you mean by "what the syntax should be"? -- From the point of
view of language construction, there are quite some possibilities one can
choose from. It is easy to require C++ that all functions should only have
exactly one argument and use a container for multivariate arguments. This
strategy is more logical for example when developing runtime models.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3ado1j7zd.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| The C heritage is in fact one of the weaknesses of C++, because C lacks
>| the high-level structures that C++ introduces.

>The C heritage also contribute to C++ success.  I don't know however
>what it would have been if it abandonned C compatibility.  Maybe it
>would have been a great language used by only two people...

I guess it is difficult to make a good pick from C before C++ has evolved
for some time. But the more C++ evolves, the more certain C heritage
components become a burden. (And for good references, you will have to
look here and there in this newsgroup; I do not remember these problems
straight off. :-) )

>| But is is easy to change a[x, y] to a[(x, y)], and the latter is more
>| clear as to what the intent is.
>
>It is also easy to continue to use a(x, y) for multi-indexing.

And it is easy for those that want to use operator() to continue do so
after a multivariate operator[] has been introduced. The latter will not
hurt unless someone wants to use "operator," on top level inside
operator[].

>| But why should those that want to program C++ as though it was C++ be
>| forced to program it as though it was Fortran or even Mathematica, the
>
>The same applies to people who think that there should be a mapping
>between mathematical notations (which varies from people to people)
>and C++ syntax :-)

Well, I never said so: The way I see it, on should study various inputs,
like heritage and other languages and math, and from that set up the C++
paradigms one see fits well into the C++ language structure.

This reasoning suggests those correspondences that I suggested, in view of
that C++ has a notion of "subscription" traced back to C arrays, and even
further back to math.

I do not think that the notation [] is very happy: For genuine
subscription, I would prefer say TeX style f_{x_1, ..., x_n}. But in C++,
[] is already there.

As some pointed out in other posts, syntax depends on the rather limited
character set available: When Unicode has been ubiquitous for some time,
computer languages will most likely take advantage of that.

As for math itself, it is very difficult to produce anything even
approaching its notational richness, as the problems with typesetting
systems like TeX/LaTeX show.

>Right now, the only serious argument I've seen is clearing the syntax.
>But if we were going to clear the syntax, this proposal would have low
>priority on my TODO list because it does break code and brings no
>benefit worthing it, IMO.

There have been many serious arguments, besides the syntactic, for example
to make sure there is just one function call, and the educational C++0x
objective, to make it easier for people working with 2D-3D modelling. So
those are very important benefits.

As for code breaking, people searching databases says there seems to be no
significant existing code broken. And changes are easy to make, making it
more clearer.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3ado1j7zd.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| The C heritage is in fact one of the weaknesses of C++, because C lacks
| >| the high-level structures that C++ introduces.
|
| >The C heritage also contribute to C++ success.  I don't know however
| >what it would have been if it abandonned C compatibility.  Maybe it
| >would have been a great language used by only two people...
|
| I guess it is difficult to make a good pick from C before C++ has evolved
| for some time. But the more C++ evolves, the more certain C heritage
| components become a burden.

That is part of living with history.  Before abandoning its roots, one
usually has to have very much good reasons :-)

[...]

| >| But is is easy to change a[x, y] to a[(x, y)], and the latter is more
| >| clear as to what the intent is.
| >
| >It is also easy to continue to use a(x, y) for multi-indexing.
|
| And it is easy for those that want to use operator() to continue do so
| after a multivariate operator[] has been introduced. The latter will not
| hurt unless someone wants to use "operator," on top level inside
| operator[].

The latter breaks existing semantics, that is what worries me.  Were
we designing C++ from scratch, my position will certainly have been
different.  Definitely.

|
| >| But why should those that want to program C++ as though it was C++ be
| >| forced to program it as though it was Fortran or even Mathematica, the
| >
| >The same applies to people who think that there should be a mapping
| >between mathematical notations (which varies from people to people)
| >and C++ syntax :-)
|
| Well, I never said so: The way I see it, on should study various inputs,
| like heritage and other languages and math, and from that set up the C++
| paradigms one see fits well into the C++ language structure.
|
| This reasoning suggests those correspondences that I suggested, in view of
| that C++ has a notion of "subscription" traced back to C arrays, and even
| further back to math.

However going to math, we see how fragile it is.

[...]

| As some pointed out in other posts, syntax depends on the rather limited
| character set available: When Unicode has been ubiquitous for some time,
| computer languages will most likely take advantage of that.

That may explains why, from time to time, I'm sympathetic for
"Generalizing Color Space Overloading" project :-)

[...]

| >Right now, the only serious argument I've seen is clearing the syntax.
| >But if we were going to clear the syntax, this proposal would have low
| >priority on my TODO list because it does break code and brings no
| >benefit worthing it, IMO.
|
| There have been many serious arguments, besides the syntactic, for example
| to make sure there is just one function call, and the educational C++0x
| objective, to make it easier for people working with 2D-3D modelling. So
| those are very important benefits.

Firstly, I must confess that I don't think that operator() makes the
job difficult.  Secondly, compatibility with C is at the heart of the
debate around possible evolutions of C++. In my view, that item has
much more importance than breaking existing semantics in the sole name
of putting [] in place of ().

| As for code breaking, people searching databases says there seems to be no
| significant existing code broken.

Well, one would question: Which data base are they considering?

--
Gabriel Dos Reis, gdr@inetgrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<slrnaljelt.2an.news_comp.std.c++_expires-2002-10-01@nightrunner.nmhq.net
 >, Niklas Matthies <news_comp.std.c++_expires-2002-10-01@nmhq.net>
writes
>>  Realistically, what we really want is a way to overload operator[][], or
>>  operator[][][], or ...  Or more generally, any chaining of operators:
>
>Hmm, I don't think I would really want that.
>At the very least, I consider it a seperate issue.
>
>The main objective for multi-argument operator[], as far as I am
>concerned, is to streamline it with operator(). It simplifies the
>language while giving more freedom. That's what _I_ really want.

Doing that for plain arrays seems a non-starter (it has a whole raft of
implications, not least that the current syntax works for dynamic
multi-dimensional arrays). I want to see a consistent syntax across
plain arrays and user defined containers. I already have to teach
newcomers the current [][]... syntax and would far prefer to be able to
stick with that syntax and allow easy overloading for user defined
containers. For me, homogenous syntax is greatly to be preferred and we
should aim to make that easy.


--
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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D596D5C.9080300@animats.com>, John Nagle
<nagle@animats.com> writes
>Francis Glassborow wrote:
>
>> In article <d6651fb6.0208130308.19932c57@posting.google.com>, James
>>Kanze <kanze@gabi-soft.de> writes
>>
>>> Realistically, what we really want is a way to overload
>>>operator[][], or
>>> operator[][][], or
>
>
>    That creates an ambiguity if you have both "operator[]" and
>"operator[][]" defined.

I disagree. Best match rules should be fairly simple. Please give me an
example of the ambiguity that you foresee.

>
>
>>> ...  Or more generally, any chaining of operators: it
>>> would be nice to be able to handle a[] = ... differently than when a[]
>>> is an rvalue.
>>  That becomes interesting, but can parser technology cope?
>
>
>   That creates a context sensitivity in the grammar, which
>is generally undesirable.  The context sensitivities we
>have now (mostly involving typenames) are already trouble spots.
>They're there for historical C-related reasons.
>
>   Related to this are the occasional calls for resolving
>overloads on return type, which seems neat until you
>think about resolving "f(g(h(x)))" in the presence of
>multiple overloads.
>
>   The obvious syntax, "tab[i,j]" is straighforward
>from a parsing standpoint.  It's a one-line change in
>the grammar.

But, unfortunately it breaks existing code which makes it very difficult
to contemplate as a change to C++.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
 > I already have to teach newcomers the current [][]... syntax
 > and would far prefer to be able to stick with that syntax and
 > allow easy overloading for user defined containers.

But that would cause ambiguity in deciding how many []s to eat up.

struct a {
 a &operator[](int a1) const { return *this; } };
 a &operator[](int a1, int a2) const { return *this; } };
};
int main() { a()[1][2][3]; }

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<remove.haberg-1308021942350001@du128-226.ppp.su-anst.tninet.se>, Hans
Aberg <remove.haberg@matematik.su.se> writes
>In the C++0x announcement, BS said he wanted no major changes to the C++
>language. My feeling about multivariate operator[] is that it is just a
>silly little detail, so from that point of view, it may slip through.

Let us be quite clear, BS is just one voice, a well respected and
influential one but the future of C++ is in the hands of WG21 and we
will determine what we believe is in the best interests of the C++
community. That is not saying that I or my colleagues are seeking
revolution but we do not all have the same views as to the rate at which
C++ should evolve.



--
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.jamesd.demon.co.uk/csc/faq.html                       ]

Randy Maddox <rmaddox@isicns.com> wrote:
>> I still fail to see the benefits over [i][j]. The argument that e.g.
>> Spirit may benefit from it applies to operator::= as well. I happen to
>> agree with the argument that we can't name just any non-alphanumeric
>> character sequence an operator.
>>

> The benefit over tab[i][j] is that this is two calls rather than one,
> i.e., tab[i] returns an object to which [j] is applied.

Nothing prevents me to write using the proposed syntax tab[i,j][k,l].
tab[i,j] might be defined as tab[i][j] (or tab [j][i]?) for built-in arrays,
but otherwise it's up to the programmer to decide which is more useful and
convenient - return a row object and use tab[i][j] or just return indi-
vidual characters and use tab[i,j]... or combine both approaches.

--
Regards, pardux

=== ICQ#38457991 === Origin: Delirium canis (c) ===

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <gK9dG5SOGaW9EwZK@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:

>>In the C++0x announcement, BS said he wanted no major changes to the C++
>>language. My feeling about multivariate operator[] is that it is just a
>>silly little detail, so from that point of view, it may slip through.

>Let us be quite clear, BS is just one voice, a well respected and
>influential one but the future of C++ is in the hands of WG21 and we
>will determine what we believe is in the best interests of the C++
>community. That is not saying that I or my colleagues are seeking
>revolution but we do not all have the same views as to the rate at which
>C++ should evolve.

So what one man tries to build up, others try to tear down? :-)

But if you want to label the introduction of a multivariate operator[] as
major, and by that, C++ has undergone major developments, that's OK with
me. :-)

Otherwise, I think that the suggestions of operator[]...[] variations are
syntactically too complex, and should be dropped in favour of the simpler
a.operator[](x_1, ..., x_n).

  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.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 14 Aug 2002 10:04:15 CST, Francis Glassborow <francis.glassborow@ntlworld.com> wrote:
> >, Niklas Matthies <news_comp.std.c++_expires-2002-10-01@nmhq.net> writes:
> >>  Realistically, what we really want is a way to overload operator[][], or
> >>  operator[][][], or ...  Or more generally, any chaining of operators:
> >
> >Hmm, I don't think I would really want that.
> >At the very least, I consider it a seperate issue.
> >
> >The main objective for multi-argument operator[], as far as I am
> >concerned, is to streamline it with operator(). It simplifies the
> >language while giving more freedom. That's what _I_ really want.
>
>  Doing that for plain arrays seems a non-starter (it has a whole raft
>  of implications, not least that the current syntax works for dynamic
>  multi-dimensional arrays).

No one wants to change plain arrays. For a moment, suppose that plain
arrays were not built-in types, but standard library templates that
choose to provide a single-argument operator[]. They _could_ also have
chosen to provide operator() (with all the implications), but they
didn't. And a multi-dimensional array type _could_ have been provided,
but it wasn't. That's fine; just leave it that way. This matter is
independent of the desire to be free to choose between operator[] and
operator() when designing a new type, the desire not to be forced to
choose operator() when you want more than one argument (or none).

>  I want to see a consistent syntax across plain arrays and user
>  defined containers.

Why? User-defined containers (can) serve different purposes, so why
should they be constrained to the syntax that serves plain arrays'
purposes?

>  I already have to teach newcomers the current [][]... syntax.
>  syntax and would far prefer to be able to stick with that syntax and
>  allow easy overloading for user defined containers.

You teach newcomers built-in arrays, multi-dimensional ones even? :)

Anyway, there's nothing wrong with [][] *in situations where* you are
actually manipulating arrays of arrays or vectors of vectors or anything
like that. [][] makes perfectly sense there. When you have a matrix type
or a two-dimensional-rectangular-array type on the other hand, then [,]
makes sense. An array of arrays is *not* a matrix, and it also is *not*
a two-dimensional array. An array of pointers to arrays is even less so.
These are different situations which naturally necessitate different
handling and should not be confused.

>  For me, homogenous syntax is greatly to be preferred and we
>  should aim to make that easy.

Certainly agreed. So why do you want to keep the inhomogeneousness that
operator() allows any number of arguments while operator[] is restricted
to exactly one argument?

-- Niklas Matthies
--
Help! The paranoids are after me!

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg wrote:

> In article <gK9dG5SOGaW9EwZK@robinton.demon.co.uk>, Francis Glassborow
> <francisG@robinton.demon.co.uk> wrote:

> But if you want to label the introduction of a multivariate operator[] as
> major, and by that, C++ has undergone major developments, that's OK with
> me. :-)
>
> Otherwise, I think that the suggestions of operator[]...[] variations are
> syntactically too complex, and should be dropped in favour of the simpler
> a.operator[](x_1, ..., x_n).


    Agreed.


    I almost view this as a cleanup.  It's inconsistent that
"operator[]" and "operator()" have subtly different
argument syntax.  The original design made sense for C,
where you couldn't define "operator[]", but once it
became user-definable in C++, it should have been
consistent with "operator()".

    The "operator[]...[]" suggestions do create an ambiguity,
in that a class with both "operator[]" and "operator[][]" is
ambiguious.  A rule to disambiguate this would result in
additional context-sensitivity in the grammar (i.e. parsing
dependent on declarations) in a way far more complex than
anything we have in the grammar now.  Right now, we only
have context sensitivity based on whether a name is a typename,
which is troublesome enough.

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen (hyrosen@mail.com) writes

>> I already have to teach newcomers the current [][]... syntax
>> and would far prefer to be able to stick with that syntax and
>> allow easy overloading for user defined containers.

HR> But that would cause ambiguity in deciding how many []s to eat up.

HR> struct a {
HR>  a &operator[](int a1) const { return *this; } };
HR>  a &operator[](int a1, int a2) const { return *this; } };
HR> };
HR> int main() { a()[1][2][3]; }

Let it follows current `hungry' C++ parsing rules. I.e. swallow
everything from left to right while sequence is constituting
valid construct. I'd expect the call above to be the same as:

  a().operator[][](1, 2).operator[](3)

In any case the class above should be rather rare thing.
I even could not imagine where it should be needed at all.

--
Pavel

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<remove.haberg-1508021244240001@du128-226.ppp.su-anst.tninet.se>, Hans
Aberg <remove.haberg@matematik.su.se> writes
>In article <gK9dG5SOGaW9EwZK@robinton.demon.co.uk>, Francis Glassborow
><francisG@robinton.demon.co.uk> wrote:
>
>>>In the C++0x announcement, BS said he wanted no major changes to the C++
>>>language. My feeling about multivariate operator[] is that it is just a
>>>silly little detail, so from that point of view, it may slip through.
>
>>Let us be quite clear, BS is just one voice, a well respected and
>>influential one but the future of C++ is in the hands of WG21 and we
>>will determine what we believe is in the best interests of the C++
>>community. That is not saying that I or my colleagues are seeking
>>revolution but we do not all have the same views as to the rate at which
>>C++ should evolve.
>
>So what one man tries to build up, others try to tear down? :-)

How do you arrive at that conclusion? We did not standardise what BS
originally created but worked at building on it (the exact antithesis of
'tearing down')
>
>But if you want to label the introduction of a multivariate operator[] as
>major, and by that, C++ has undergone major developments, that's OK with
>me. :-)

As it involves quite a few issues it is certainly not a 'silly little
detail' nor is it a major change. There are many shades of grey in the
real world.

>
>Otherwise, I think that the suggestions of operator[]...[] variations are
>syntactically too complex, and should be dropped in favour of the simpler
>a.operator[](x_1, ..., x_n).

Curious, because operator[]...[] is effectively what we currently have
(and will continue to have for arrays)

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:

[...]

|  When you have a matrix type
| or a two-dimensional-rectangular-array type on the other hand, then [,]
| makes sense.

So does [][].

| An array of arrays is *not* a matrix,

Is that a definitional statement?

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<slrnallp1e.sk.news_comp.std.c++_expires-2002-10-01@nightrunner.nmhq.net>
, Niklas Matthies <news_comp.std.c++_expires-2002-10-01@nmhq.net> writes
>You teach newcomers built-in arrays, multi-dimensional ones even? :)
Not on day 1 but at some time they need to know. In addition, vector is
not a replacement for array, it is a replacement for a dynamic array.
Sometimes a dynamic array is fine even if a static one would do but at
other times that is not the case.


>
>Anyway, there's nothing wrong with [][] *in situations where* you are
>actually manipulating arrays of arrays or vectors of vectors or anything
>like that. [][] makes perfectly sense there. When you have a matrix type
>or a two-dimensional-rectangular-array type on the other hand, then [,]
>makes sense. An array of arrays is *not* a matrix, and it also is *not*
>a two-dimensional array. An array of pointers to arrays is even less so.
>These are different situations which naturally necessitate different
>handling and should not be confused.
>
>>  For me, homogenous syntax is greatly to be preferred and we
>>  should aim to make that easy.
>
>Certainly agreed. So why do you want to keep the inhomogeneousness that
>operator() allows any number of arguments while operator[] is restricted
>to exactly one argument?

Why do you want to break code that can be found in extensively used
legacy code? The built in function operator has always had a list of
parameters, the built in index operator never has. Why the need to
change the syntax? As it would break existing code you really need some
much better argument than one based on aesthetics.


--
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.jamesd.demon.co.uk/csc/faq.html                       ]

"Pavel Kuznetsov" <pavel@despammed.com> writes:

| Hyman Rosen (hyrosen@mail.com) writes
|
| >> I already have to teach newcomers the current [][]... syntax
| >> and would far prefer to be able to stick with that syntax and
| >> allow easy overloading for user defined containers.
|
| HR> But that would cause ambiguity in deciding how many []s to eat up.
|
| HR> struct a {
| HR>  a &operator[](int a1) const { return *this; } };
| HR>  a &operator[](int a1, int a2) const { return *this; } };
| HR> };
| HR> int main() { a()[1][2][3]; }
|
| Let it follows current `hungry' C++ parsing rules.

But, the current "hungry" parsing rules apply only in phases before
semantic analysis.

[...]

But that assumes the semantics analysis phase interleaves with the
preprocessing phase!

| In any case the class above should be rather rare thing.

"Nobody knows what C++ programmers do".

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Pavel Kuznetsov wrote:
> In any case the class above should be rather rare thing.
> I even could not imagine where it should be needed at all.

This attitude is the reason why most so-called proposals will
be rejected out of hand. When a new feature is proposed, every
possible circumstance must be accounted for, because the compiler
is going to have to do *something* when it sees it. Leaving things
unspecified, or hemming in a new feature with a ton of restrictions
so that only the "common" case is legal are sure ways for a proposal
to fail.

Allowing a comma-separated argument list for operator[] at least has
a chance. Trying to assign a user-defined meaning to multiple []s is
dead in the water. It's simple to specify the behavior of the former
and complicated to specify the behavior of the latter.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> As it would break existing code you really need some
> much better argument than one based on aesthetics.

It's very easy for the compiler to detect and warn about a
problem. If it sees multiple arguments within [] for a plain
pointer or for a class type which does not have an operator[]
with the correct arity, it simply announces this, and fails
to compile the code. The solution is then to surround the
desired comma-expression with parentheses.

Given that the change is easy to detect and easy to fix,
and that the code which would require fixing is very rare,
this should be no impediment.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <u5buqsCQNNX9EwCw@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:

>>>Let us be quite clear, BS is just one voice, a well respected and
>>>influential one but the future of C++ is in the hands of WG21 and we
>>>will determine what we believe is in the best interests of the C++
>>>community.
...
>>So what one man tries to build up, others try to tear down? :-)

>How do you arrive at that conclusion?

Perhaps you put too much into the joke. :-)

>>Otherwise, I think that the suggestions of operator[]...[] variations are
>>syntactically too complex, and should be dropped in favour of the simpler
>>a.operator[](x_1, ..., x_n).
>
>Curious, because operator[]...[] is effectively what we currently have
>(and will continue to have for arrays)

Well, for arrays, iterations of [] apply to successively different
objects. Unless one is identifying Hom(A x B, C) with Hom(A, Hom(B, C)),
as in the "Currying" of some functional languages, one expects new
application of matching pairs to be applied to new objects.

So from that point of view, one expects to have each new [] apply to a new
object.

I do not follow this discussion anymore in detail, but the implementation
of a.operator[](x_1, ..., x_n) looks straightforward to me. With
operator[]...[] present, one will have to worry about interpreting
a[x_1]...[x_n] in as many ways as one can insert parenthesizes beginning
before the "a" and ending in the middle of [x_1]...[x_n]. And to this one
must add a good method to resolve ambiguities.

So, despite to that one may be used to a[x_1]...[x_n] in the case of C
arrays, I think that one should settle for a[x_1, ..., x_n] when "a" is a
class object. This will then streamline together operator[] and
operator(), based one the fact that C++ is a non-Curried language.

In general, if there is possibility of streamlining together C++'s syntax,
I think that should be done even if that departs from the old C syntax,
because as C++ is already such a complex language, at least the new C++
core will need relying on a smaller set of general principles.

It depends on how one views the C++ evolution: If it is viewed as mainly a
C compatibility language, then one can have stuff like operator[]...[] in
order to remain with the C tradition. But then one also says that the C++
new object features are not as important as the C compatibility issue.

On the other hand, if one thinks that from C++ there will eventually
emerge a new, high level C++ core, then it is better to streamline this
core, basing on a fewer number of consistent features.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:


> Why do you want to break code that can be found in extensively used
> legacy code? The built in function operator has always had a list of
> parameters, the built in index operator never has. Why the need to
> change the syntax? As it would break existing code you really need some
> much better argument than one based on aesthetics.


     Has anyone found an example in existing code yet?
We've searched a Linux distro with about 70 RPMs and the
Microsoft VC++ development libraries, and we haven't seen
a comma inside square brackets yet that was actually parsed
as C or C++.  (We've seen it in comments, and in Microsoft
IDL, but those aren't parsed by a C++ parser.)

     Clearly, it's not going to be a big problem.  And it
may be a total non-problem to change this.

     Besides, if we eventually do find a comma within
square brackets, there's a good chance we'll have found
a bug, where somebody wrote "tab[i,j]", thinking it did
the obvious thing.

    John Nagle
    Animats


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On 16 Aug 2002 15:30:01 GMT, Francis Glassborow <francis.glassborow@ntlworld.com> wrote:
[...]
>  Why do you want to break code that can be found in extensively used
>  legacy code?

If such code is actually found, I don't.

-- Niklas Matthies
--
Good judgement comes from experience,
and experience comes from bad judgement.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On 16 Aug 2002 15:00:09 GMT, Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
>  news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:
>  [...]
> |  When you have a matrix type
> | or a two-dimensional-rectangular-array type on the other hand, then [,]
> | makes sense.
>
>  So does [][].

Yes, but it doesn't mean the same thing. It implies the existence of a
self-contained, vector-like entity within the two-dimensional-rectangular-
array or the matrix. It makes accessing the actual element you want to
access a two-phase process, in situations where this doesn't make sense
neither practically nor conceptually.

> | An array of arrays is *not* a matrix,
>
>  Is that a definitional statement?

Define "definitional statement". A matrix may well be implemented using
an array of arrays. But it certainly isn't one.

-- Niklas Matthies
--
War doesn't prove who's right, just who's left.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:

| On 16 Aug 2002 15:00:09 GMT, Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
| >  news_comp.std.c++_expires-2002-10-01@nmhq.net (Niklas Matthies) writes:
| >  [...]
| > |  When you have a matrix type
| > | or a two-dimensional-rectangular-array type on the other hand, then [,]
| > | makes sense.
| >
| >  So does [][].
|
| Yes, but it doesn't mean the same thing. It implies the existence of a
| self-contained, vector-like entity within the two-dimensional-rectangular-
| array or the matrix.

A two-dimensional entity implies the existence of a one-dimensional
entity obtained by slicing.  Those founds of currying might explain
this better than I ;-)

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1029513490.611176@master.nyc.kbcfp.com>, Hyman Rosen
<hyrosen@mail.com> writes
>Francis Glassborow wrote:
>> As it would break existing code you really need some  much better
>>argument than one based on aesthetics.
>
>It's very easy for the compiler to detect and warn about a
>problem. If it sees multiple arguments within [] for a plain
>pointer or for a class type which does not have an operator[]
>with the correct arity, it simply announces this, and fails
>to compile the code. The solution is then to surround the
>desired comma-expression with parentheses.
>
>Given that the change is easy to detect and easy to fix,
>and that the code which would require fixing is very rare,
>this should be no impediment.


Sorry, that may seem a simple fix but it is the kind of thing that
causes hackles to rise in quite a few places. One feature that needs to
be noted is that a lot of code is generated and changing syntax rules
requires that code generators be rewritten, forcing such actions must
not be done lightly.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen <hyrosen@mail.com> writes:

| Francis Glassborow wrote:
| > As it would break existing code you really need some
| > much better argument than one based on aesthetics.
|
| It's very easy for the compiler to detect and warn about a
| problem.

Certainly, a compiler could be instrumented to diagnose such a
construct.  The issue really isn't the theoretical technical
feasability of the thingy.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

>> I am not insisting on introducing operator[][], but it seems
>> rather attractive to me to be able substitute int m[3][3]
>> with Matrix<int, 3, 3> without modifiyng client source code.
>> Alas, it seems that my hope is vain :-)

HA> It is better to rewrite old code with respect to a syntax
HA> that is more firm. {...}

Maybe. Given the difference between subscripting built-in
int[3][3] and say std::matrix<int,3,3>, I'd propose that
built-in `matrices' could be subscripted with [i,j] sintax too.

--
Pavel

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Pavel Kuznetsov wrote:
> Hans Aberg (remove.haberg@matematik.su.se) writes
>
>
>>>I am not insisting on introducing operator[][], but it seems
>>>rather attractive to me to be able substitute int m[3][3]
>>>with Matrix<int, 3, 3> without modifiyng client source code.
>>>Alas, it seems that my hope is vain :-)
>>
>
> HA> It is better to rewrite old code with respect to a syntax
> HA> that is more firm. {...}
>
> Maybe. Given the difference between subscripting built-in
> int[3][3] and say std::matrix<int,3,3>, I'd propose that
> built-in `matrices' could be subscripted with [i,j] sintax too.

And declared as int[3,3].

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3fzxy5g40.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| Really; so what is the "general" notation for the matrix component $m_{ij}$?
>
>The general notation of a matrix isn't $m_{ij}$.
>My book use $m^{ij}$, $m_i^j$, $m(i,j)$.

So I must be right: You are using a new definition of the word "general"
that I must be unaware of. :-) -- Please state your definition.

In math, notations like $m^{ij}$, $m_i^j$ are commonly used to indicate
tensors of different kinds (covariant/contarvariant); if a metric is
present, one further shift indices. Notation like $m(i, j)$ is, as I
indicated, commonly used as alteratives to subscription notation.

When indicating a matrix, one may write (in pseudo-TeX) say
   $m := (m_{ij))_{(i, j) in I x J}$
   $n := (n_{jk))_{(j, k) in J x K}$
And when defining say matrix multiplication l := m*n, one might do that by
saying that
 (1)   $l_{ik} := sum_{j in J} m_{ij}*n_{jk}$

Note that above, I used words like "commonly", because in math, one can of
course invent pretty much what notation one wants if prudently dictated by
semantics, so it is hard to speak about "general" notations.

In C++, when subscription is indicated by operator[], the corrsponding
formula might then read
     ...
     for (j=0; j < j1; ++j)
 (2)    l[i, k] = m[i, j]*n[j, k];
     ...

Here (2) is a very direct translation of (1).

>Following your reasoning, a more accurate extention should be
>"overloaded missing whitespace" so that we could just write m[ij] to
>match your general notation ;-).

If you would take up the quest of making your own computer languages
(right now I use Flex/Bison), you might be surprised how much is possible
in doing a notation that approaches say common math abbreviations.

But here we are dealing with C++, and the limitations are not really what
is possibly to do from the point of parsing, but what fits into the
already existing general C++ paradigms.

>From this point of view, multivariate operator[] fits well in.

C++ could do much in supplying more general syntaxes, but the language is
perhaps not ready for it yet.

>| Clearly, your suggestion of using operator() instead of operator[] is much
>| worse. :-)
>
>Worse or not, it's been used for more than a decade in C++ and for
>quite a longtime in "dedicated" programming languages like Fortran.
>Or are you implying that the designers of that notation in Fortran
>were totally ignorant of their pratice?

If one should use as argument the fact that a certain corny syntax has
been in use a long time (as the language did not admit anything else) to
prevent the changes, then that argument could always be used to prevent
any kinds of changes:

In fact, some people apply it to the language C++ itself, landing on the
conclusion that one should program in C instead. :-)

  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.jamesd.demon.co.uk/csc/faq.html                       ]

    Looking at the syntax of "operator[]" in section A.5,
under "postfix-expression" in the C++ grammar,
it's worth noting that "operator()"
and "operator[]" currently accept the same syntax, but with
different operator precedence.  With "operator[]", the
comma operator has precedence over the [] operator, while
with "operator()", the reverse is true.

    I understand the history that got us to this point.
But it's clearly an irregularity in the grammar.
When you think about it in this way, this is more of a
cleanup change.

    What I'm proposing regularizes the syntax, by using
"expression-list_opt" for both "operator[]" and
"operator()".  This gives both operators comma-separated
arguments, and requires for both that explicit uses of the
comma operator be enclosed in parentheses.

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3fzxy5g40.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| Really; so what is the "general" notation for the matrix component $m_{ij}$?
| >
| >The general notation of a matrix isn't $m_{ij}$.
| >My book use $m^{ij}$, $m_i^j$, $m(i,j)$.
|
| So I must be right: You are using a new definition of the word "general"
| that I must be unaware of. :-) -- Please state your definition.

If it is the phrase "my book" that is chocking you, then I gave
references to some of those "my book" in another message -- a follow up
to message where you were asking asking whether I did ever have a look at
covariant and contravariants.  They are fairly standard.

| In math, notations like $m^{ij}$, $m_i^j$ are commonly used to indicate
| tensors of different kinds (covariant/contarvariant); if a metric is
| present, one further shift indices. Notation like $m(i, j)$ is, as I
| indicated, commonly used as alteratives to subscription notation.

Notations like $m^{ij}$ is not only used in math to indicate tensors
of different kinds.  They're also used to indicate the values of entities
at different grids or iteration step, different point.

| When indicating a matrix, one may write (in pseudo-TeX) say
|    $m := (m_{ij))_{(i, j) in I x J}$
|    $n := (n_{jk))_{(j, k) in J x K}$

Or
   $m := (m_i^j)_{(i, j) in I x J}$
   $n := (n(j,k))_{(j, k) in J x K}$


| And when defining say matrix multiplication l := m*n, one might do that by
| saying that
|  (1)   $l_{ik} := sum_{j in J} m_{ij}*n_{jk}$
|
| Note that above, I used words like "commonly", because in math, one can of

Well, I guess your "commonly" depends on how broad the inspection is
conducted.  If limited to an office or a university, then I won't
disupte it ;-)

[...]

| >Following your reasoning, a more accurate extention should be
| >"overloaded missing whitespace" so that we could just write m[ij] to
| >match your general notation ;-).
|
| If you would take up the quest of making your own computer languages
| (right now I use Flex/Bison), you might be surprised how much is possible
| in doing a notation that approaches say common math abbreviations.

You would have certainly noticed that I'm not looking for a computer
language that matches a syntatictal pitfall :-)  My top most interest
in C++ is about its semantics expressivity, and its usability as a
practical tool. In my quest, syntax comes after semantics.

[...]

| >| Clearly, your suggestion of using operator() instead of operator[] is much
| >| worse. :-)
| >
| >Worse or not, it's been used for more than a decade in C++ and for
| >quite a longtime in "dedicated" programming languages like Fortran.
| >Or are you implying that the designers of that notation in Fortran
| >were totally ignorant of their pratice?
|
| If one should use as argument the fact that a certain corny syntax has
| been in use a long time (as the language did not admit anything else) to
| prevent the changes, then that argument could always be used to prevent
| any kinds of changes:

Oh, you're already using that argument, but in the sense of breaking
previous commitment: You're basing your argumentation on the fact
that "[]" has been The way C (and later C++) expresses subscription.

There is no reason why you'd be OK to use it to break semantics of previous
C++ relseases and it wouldn't be OK to use it to retain compatibility.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

remove.haberg@matematik.su.se (Hans Aberg) wrote in message
news:<remove.haberg-3007021928580001@du135-226.ppp.su-anst.tninet.se>...
> In article <d6651fb6.0207300514.c9e89eb@posting.google.com>,
> kanze@gabi-soft.de (James Kanze) wrote:

> >>     "tab[i,j]" is starting to look good, though.
>  ...
> >> So far, nobody has been able to find existing code it would break.

> >Which doesn't mean that there isn't any.

> >The fact that this is legal is a contract.  You can't just break it
> >like that.  If you want to break it, you have to prove two things:
> >that the amount of code which will be affected is small, that there
> >is a great benefit, and that there is no reasonable alternative
> >solution which would solve the problem.

> It sounds as three things to me, unless the laws of arithmetic have
> changed lately. :-)

There are three kinds of people in the world, those who can count, and
those who can't.:-)

> >You seem to be addressing the first point, but I don't think anyone
> >really doubts this -- the idiom is hardly one recommended by any
> >reasonable coding standards.  How great the benefit is, however, is
> >still an open question.  But the major point remains: you can always
> >use operator().  There is a reasonable alternative solution which
> >requires no changes in the standard.

> I think that the greatness of the benefit is in the mind of the
> programmer:

The greatness of the benefit is very dependant on the cost of the
alternatives.  I agree that matrix[i,j] is nicer than matrix(i,j).  But
how much nicer?  Enough to risk breaking someone else's code?  Enough to
go back on a promis?

In the end, of course, it is a matter of opinion.  My opinion is that
the standard is a promis to users: modifying it to allow them to do
things that they couldn't do before is OK, but I need really serious
reasons to take something away from them, even it is something that *I*
am convinced shouldn't be used, and that I don't use myself.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m37kja6y8h.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| That's the reason the suggestion has been added: The benefits of proper
>| syntactic expressivity, instead of having to rely on corny, hard to parse,
>| language constructs.
>
>The function call isn't harder to parse (from a user point of view)
>than the proposed operator[] extension.

Sure it is, we*) even gave an example
    a(x, y) = b;
    a[x, y] = b;

>  The function call operator
>has become part of C++ idiomatic construct.

If one uses a very corny construct, one can probably get used to it. :-)

> As such, it isn't
>certainly a corny language construct.  At leats not cornier than
>anything else in the language.

After getting used to it, one will not realize how corny it is. Just take
the common computer programmer convention to write function calls with
extra space
    f (x)
even though all traditional typesetting and handwritten practises of math
in all fields says that there should be no such extra space.

>| This seems to be a very personal opinion of yours.
>
>But then, the supposed syntatic expressivity is also a personal
>opinion of yours!

In part, of course. But I like to work through many different fields, and
I do not try to impose a very restricted personal usage onto others as to
put them in a strait-jacket.

By hanging out in the LaTeX project group, I have several times indicated
what I feel is the common usage, to which some non-mathematicians have
objected; but then other matematiocans say that they feel exactly the same
as me.

I picked these things up via interaction of a number of sources, and the
feedback have indicates that my intuitions are correct.

>| I showed some matrix
>| examples where the benefit might be quite significant.
>
>And I demonstrated that the supposed example is based on a syntatical
>pitfall.

I never saw anything of that.

>| Summing it up, it seems that adding a multivariate operator[] will
>| significantly enhance the syntactic expressivity of C++, bring it closer
>| to important mathematical constructs,
>
>However it was demonstrated that those supposed mathematical constructs
>are flawed.

Nor was this shown by anybody in this thread.

*) Not only us, but others in this thread as well. :-)

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m33cty6y44.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| >I saw and responded: Your argumentation doesn't hold.  See my followup.

>| So it then seems that I have to wait for that followup to appear. :-)

>If you still don't see it, you should alert your news server syadmin
>:-)

It seems more appropriate to ask you to somehow lay out the text:

I have laid out the arguments on point after point very clearly, and I
have not seen any valid counter-arguments from anybody in this thread.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6651fb6.0207310652.da12b15@posting.google.com>, James Kanze
<kanze@gabi-soft.de> writes
>The greatness of the benefit is very dependant on the cost of the
>alternatives.  I agree that matrix[i,j] is nicer than matrix(i,j).  But
>how much nicer?  Enough to risk breaking someone else's code?  Enough to
>go back on a promis?
>
>In the end, of course, it is a matter of opinion.  My opinion is that
>the standard is a promis to users: modifying it to allow them to do
>things that they couldn't do before is OK, but I need really serious
>reasons to take something away from them, even it is something that *I*
>am convinced shouldn't be used, and that I don't use myself.

There are two issues that I think need consideration.

1) While those from a Fortran heritage are happy with using ( ) for
subscripting, indexing etc. those from other areas are used to using [ ]
for this purpose. I have not noticed anyone suggest that we should teach
the use of ( ). Anyone who did would be questioned because it would use
a different syntax for arrays with an option for other sequence
containers. Instead we have the [ ][ ]... syntax for multiple
dimensions. (why didn't the standard's committee use ( ) instead of at
for checked indexing?)

C++ is already hard enough to read, rationalising some syntax to make it
easier and less counter intuitive has real benefits to the C++ community
in general.

When I see x[n] I expect that to be element n of a container called x
(yes I know we could interchange x and n for arrays). When I see x(n) I
expect x to be a function called with n as its argument. Now when I see
x(n, m) I still expect x to be a function and will be a little surprised
that it is a container. I can live with x[n][m] except that that has
consequences for non-array containers (actually it also has these for
arrays) because it constitutes two function calls. That causes problems
with some of the STL tools. We could fix this by allowing operator[
]...[ ] functions to be declared as member operator functions (and
possibly extending the builtin operators to include these for the
benefit of using STL on multi-dimensioned arrays)

Note that we cannot use ( , ) syntax for arrays, yet there are some
advantages to using arrays where the dimensions are known at compile
time.

I believe that breaks nothing and is well within the capabilities of
modern compiler technology. It provides consistency within C++ even if
not exactly the format used by numerical domain specialists.

I believe that providing a single uniform syntax across arrays and user
defined containers is a desirable goal.

2) What would really be convincing that change were needed was if
someone demonstrated a real world piece of code where operator() was
beneficially used for some other purpose in a type where multi-dimension
subscripting was also desirable.



--
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.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg wrote:

[...]
>>The function call isn't harder to parse (from a user point of view)
>>than the proposed operator[] extension.

> Sure it is, we*) even gave an example
>     a(x, y) = b;
>     a[x, y] = b;

Why is it harder to parse?

In another message:

 > And when defining say matrix multiplication l := m*n, one might do
that by
 > saying that
 >  (1)   $l_{ik} := sum_{j in J} m_{ij}*n_{jk}$
[...]
 > In C++, when subscription is indicated by operator[], the corrsponding
 > formula might then read
 >     ...
 >     for (j=0; j < j1; ++j)
 > (2)    l[i, k] = m[i, j]*n[j, k];
 >
 > Here (2) is a very direct translation of (1).

     for (j=0; j < j1; ++j)
(3)    l(i, k) = m(i, j)*n(j, k);

And (3) is not?

fres


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3wur942n9.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@integrable-solutions.net> wrote:

>| >The general notation of a matrix isn't $m_{ij}$.
>| >My book use $m^{ij}$, $m_i^j$, $m(i,j)$.

>| So I must be right: You are using a new definition of the word "general"
>| that I must be unaware of. :-) -- Please state your definition.

>If it is the phrase "my book" that is chocking you, ...

I am quite hard to chock. But the use of the word "general", I must admit,
is chocking. :-)

>| In math, notations like $m^{ij}$, $m_i^j$ are commonly used to indicate
>| tensors of different kinds (covariant/contarvariant); if a metric is
>| present, one further shift indices. Notation like $m(i, j)$ is, as I
>| indicated, commonly used as alteratives to subscription notation.
>
>Notations like $m^{ij}$ is not only used in math to indicate tensors
>of different kinds.  They're also used to indicate the values of entities
>at different grids or iteration step, different point.

Well, first, mathematicians invent and use all sorts of new notations,
making the story difficult even for typesetting programs like TeX/LaTeX
etc.

But here we are focused on the more limited subject of implementing
matrices in C++.

>| Note that above, I used words like "commonly", because in math, one can of
>
>Well, I guess your "commonly" depends on how broad the inspection is
>conducted.  If limited to an office or a university, then I won't
>disupte it ;-)

Well, I made a turn over the world, including the place where Einstein had
a job towards the end of his life.

The notational use for vectors and matrices I have encountered are first
the "pure" math system where one, when expanding into coordinates, they
are all subscripted. As one mainly works with coordinate independent
notation, nothing else is really needed.

The other system, which I gather is also "pure" math, but derives from the
period before coordinate independent notions were invented in the 1930'es
or something, is that coordinates that (with respect to a change of basis)
transforms as basis elements are subscripted, and those that transforms as
vectors are superscripted. This is also the system mainly used by
physicists when describing tensors.

Of course, mathematicians can invent all kinds of notation, but do you
dispute the rather major, common use of those two above mentioned systems?

As for C++, we are here in this thread mainly speaking about implementing
vectors and matrices and such, not tensors, and there is already a
standard in use, namely operator[], even though restricted to
one-dimensional indexing only (also see below about C++ language
development principles).

-- Unless you are proposing using A::operator[](std::pair<X,Y>(x, y)),
which is of course workable, but probably some bother when writing actual
code.

>| >Following your reasoning, a more accurate extention should be
>| >"overloaded missing whitespace" so that we could just write m[ij] to
>| >match your general notation ;-).

>| If you would take up the quest of making your own computer languages
>| (right now I use Flex/Bison), you might be surprised how much is possible
>| in doing a notation that approaches say common math abbreviations.

>You would have certainly noticed that I'm not looking for a computer
>language that matches a syntatictal pitfall :-)

What I try to say that much of those math shorthand are not what many
thinks to believe, syntactic shortcomings, but by experimenting I have
found that it is often perfectly possible to make a computer read those
things.

If you are interested in those syntactic/grammatic matters, you might find
it enjoyable and interesting working with a lexer/parser generator
combination (there is also ANTLR http://antlr.org, which I think can
generate C++, and might be easier to use).

>  My top most interest
>in C++ is about its semantics expressivity, and its usability as a
>practical tool. In my quest, syntax comes after semantics.

Well, in math, notions (semantics) and notation (syntax) should properly
go hand in hand.

>| If one should use as argument the fact that a certain corny syntax has
>| been in use a long time (as the language did not admit anything else) to
>| prevent the changes, then that argument could always be used to prevent
>| any kinds of changes:

>Oh, you're already using that argument, but in the sense of breaking
>previous commitment: You're basing your argumentation on the fact
>that "[]" has been The way C (and later C++) expresses subscription.

>There is no reason why you'd be OK to use it to break semantics of previous
>C++ relseases and it wouldn't be OK to use it to retain compatibility.

The development principles for C++ are:

If the code breaks aren't too common, and the fixes not overly difficult,
then one should break compatibility if that helps up the language.

But on the other hand, BS made an announcement of what kind of
developments he would want to see in C++ right now, for the development of
the next release. -- See the first article in the thread "C++0x" I think
in May last year. It says, among other things, no major changes to the C++
language itself at this point. (I think that this particular policy is
right, because C++ needs to focus on ensuring certain semantics features
can be implemented well via the language.)

As for the proposed change in the operator[], it does not look as though a
"major change". (The term "major" is not formally defined in this
context.)

And as for generalizations, sure, you could do that (say user defined
precedence systems like in Prolog or Haskell http://haskell.org). If such
more general syntactic system should be implemented in C++, I think one
would need to solve some fundamental problem in order to make the system
conservative enough and thereby safe in typical C++ usage.

-- If I can come up with an operator precedence system that seems very
suitable for C++, then I will report it here. But it will probably not be
accepted, unless one can see fairly easily that it is the right thing for
C++.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m37kja6y8h.fsf@soliton.integrable-solutions.net>, Gabriel D=
os
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|=20
| >| That's the reason the suggestion has been added: The benefits of pro=
per
| >| syntactic expressivity, instead of having to rely on corny, hard to =
parse,
| >| language constructs.
| >
| >The function call isn't harder to parse (from a user point of view)
| >than the proposed operator[] extension.
|=20
| Sure it is, we*) even gave an example
|     a(x, y) =3D b;
|     a[x, y] =3D b;

Yes, you gave an example.  But that doesn't mean it makes your
argumentatioin right.  C++ have been educated that [] is unary.  In
your expression, they have now to worry whether it is the unaary
operator or a binary operator or use of an overloaded operator or the
comma operator. =20

| >  The function call operator
| >has become part of C++ idiomatic construct.
|=20
| If one uses a very corny construct, one can probably get used to it. :-=
)

That may example the insistance on [] ;-)

| > As such, it isn't
| >certainly a corny language construct.  At leats not cornier than
| >anything else in the language.
|=20
| After getting used to it, one will not realize how corny it is. Just ta=
ke
| the common computer programmer convention to write function calls with
| extra space
|     f (x)
| even though all traditional typesetting and handwritten practises of ma=
th
| in all fields says that there should be no such extra space.

All?  Citation please.  I have here standard mathematical books that
use =AB xf =BB or =AB fx =BB (with spaces where appropritate) which defea=
ts your
supposed universal practice.

But, computing is not mathematics.  And mathematical nottation does
not rule programmer practices.

| >| This seems to be a very personal opinion of yours.
| >
| >But then, the supposed syntatic expressivity is also a personal
| >opinion of yours!
|=20
| In part, of course. But I like to work through many different fields, a=
nd
| I do not try to impose a very restricted personal usage onto others as =
to
| put them in a strait-jacket.

That is why you're insisting on [], with argumentation based on
syntactical pitfalls ;-)

--=20
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m33cty6y44.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| >I saw and responded: Your argumentation doesn't hold.  See my followup.
|
| >| So it then seems that I have to wait for that followup to appear. :-)
|
| >If you still don't see it, you should alert your news server syadmin
| >:-)
|
| It seems more appropriate to ask you to somehow lay out the text:
|
| I have laid out the arguments on point after point very clearly, and I

I did the same thing, by providing counter-examples and demonstrated
the wrongness of premisses or the pitfalls in argumentations.  I'm
sure you didn't see them because they didn't agree with you or because
the postings didn't actually propagate to your news server.

--
Gabriel Dos Reis, gdr@integrables-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle (nagle@animats.com) writes

JN>     "tab[i,j]" is starting to look good, though.  So far,
JN> nobody has been able to find existing code it would break.
{...}
JN>     Please look through any large code bases you have,
JN> and let me know if you can find anything this will break.

The only case I know is usage of overloaded comma operator
with libraries, simulating lambda-functions via template
expressions. There are several such places in code base
I can access. These could be `fixed' rather easily though.

--
Pavel

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote...
>
>     "tab[i,j]" is starting to look good, though.  So far,
> nobody has been able to find existing code it would break.
> We've scanned the code that comes with MSVC, and an
> archive of almost all free Linux RPMs, without finding
> a valid use of the comma operator inside square brackets.

Would I be correct in thinking that if compilers were changed to accept
tab[i,j] as operator[](int,int), then any existing code that is broken could
be flagged.

Would it also be true that the following built-in implementations would
fix such code?

    operator[](int i, int j) { return operator[](j); }
    operator[](int i, int j, int k) { return operator[](k); }
    // etc.

Obviously the real built-in operator would have to act as though I'd used
a template in the above.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <d6651fb6.0207300514.c9e89eb@posting.google.com>,
kanze@gabi-soft.de (James Kanze) wrote:

>>     "tab[i,j]" is starting to look good, though.
...
>> So far, nobody has been able to find existing code it would break.

>Which doesn't mean that there isn't any.

>The fact that this is legal is a contract.  You can't just break it like
>that.  If you want to break it, you have to prove two things: that the
>amount of code which will be affected is small, that there is a great
>benefit, and that there is no reasonable alternative solution which
>would solve the problem.

It sounds as three things to me, unless the laws of arithmetic have
changed lately. :-)

>You seem to be addressing the first point, but I don't think anyone
>really doubts this -- the idiom is hardly one recommended by any
>reasonable coding standards.  How great the benefit is, however, is
>still an open question.  But the major point remains: you can always use
>operator().  There is a reasonable alternative solution which requires
>no changes in the standard.

I think that the greatness of the benefit is in the mind of the programmer:

On the one hand, one can argue that no more operators should be added to
C++, as one can always use the old ones. On the other hand, I noticed that
the introduction of user defined operators have spawned great demands for
even more. -- This is the price of success, I gather.

In the case of operator[], it would be nice to be able to write
    template<class X>
    class matrix {
    public:
       typedef ... size_type;
       typedef ... reference;

       matrix(const X&);

       reference operator[](size_type, size_type);
    };
so that when working with matrices, the formulas written come out right.

-- I figure that such a "matrix" class should in reality be an adaptor
class for various different matrix representations, iterated vector
classes, sparse matrices, etc. (Just as one might add an adaptor class
"sequence" for various sequential containers like vector, list, tree etc.
in order to help them to work together more conveniently.)

In such a picture, using a[i][j] would not be correct, or even easy to
implement, because if the representation (class X above) is say a sparse
matrix m, m[i] may not make sense. And it is somewhat tricky to keep track
of the right index also for iterated vectors m[i][j] -- it is less
confusing to use m[i, j].

And writing a(i, j) in such a context would be corny relative to typical
C++ lingo, as operator[] is known as the subscription operators.

As for myself, I moved away from trying to make the C++ code itself more
expressive by using a Flex/Bison combination by which I can invent more
freer syntaxes. Still, I think that a powerful C++ syntax is very
inspiring also for those that would want to walk down that path.

Thus, I tend to think that one should try to improve on the current C++
syntax if it can be made without breaking significant upwards
compatibility concerns, and if it makes programmers more comfortable with
the new situation.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

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

[...]

| In such a picture, using a[i][j] would not be correct, or even easy to
| implement, because if the representation (class X above) is say a sparse
| matrix m, m[i] may not make sense. And it is somewhat tricky to keep track
| of the right index also for iterated vectors m[i][j] -- it is less
| confusing to use m[i, j].
|
| And writing a(i, j) in such a context would be corny relative to typical
| C++ lingo, as operator[] is known as the subscription operators.

But, then a[i, j] is equally confusing.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Hagan wrote:

> "John Nagle" <nagle@animats.com> wrote...
>
>>    "tab[i,j]" is starting to look good, though.  So far,
>>nobody has been able to find existing code it would break.
>>We've scanned the code that comes with MSVC, and an
>>archive of almost all free Linux RPMs, without finding
>>a valid use of the comma operator inside square brackets.
>>
>
> Would I be correct in thinking that if compilers were changed to accept
> tab[i,j] as operator[](int,int), then any existing code that is broken could
> be flagged?


     Yes.  Unless the array type of "tab" has an overloaded
"operator[]" with two arguments, "tab[i,j]" would produce
the usual "no defined function matches this call" error.


> Would it also be true that the following built-in implementations would
> fix such code?
>
>     operator[](int i, int j) { return operator[](j); }
>     operator[](int i, int j, int k) { return operator[](k); }
>     // etc.
>
> Obviously the real built-in operator would have to act as though I'd used
> a template in the above.


      No, because "operator[]" has to have the object being
subscripted as an argument.

     John Nagle
     Animats


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3fzy1t8ev.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| In such a picture, using a[i][j] would not be correct, or even easy to
>| implement, because if the representation (class X above) is say a sparse
>| matrix m, m[i] may not make sense. And it is somewhat tricky to keep track
>| of the right index also for iterated vectors m[i][j] -- it is less
>| confusing to use m[i, j].

>| And writing a(i, j) in such a context would be corny relative to typical
>| C++ lingo, as operator[] is known as the subscription operators.
>
>But, then a[i, j] is equally confusing.

What do you mean? -- Your reply is somewhat cryptic.

(In math matrix coordinates $m_ij$ translates to C++ m[i, j], as
operator[] is called the "subscription" operator in C++.)

  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.jamesd.demon.co.uk/csc/faq.html                       ]

"Pavel Kuznetsov" <pavel@despammed.com> wrote
> As far as I understand it is unlikely that overloading
> operator[] with multiple parameters would be permitted
> because of backward compatibility.

Backward compatibility?

Suppose the new standard did allow operator[] to overload
on multiple parameters. What compatibility problems would
this cause?

The only answer I can think of is code like this:
    a = b[c=d+5, d];
which is currently equivalent to:
    c = d+5;
    a = b[d];
except that it uses the "comma operator" to do it all in
one statement. (Probably common in "obfuscated C" contest
entries.) This code would break, but maybe it deserves to
die.

Is there any non-contrived code that does anything even
vaguely similar to this? Even on built-in arrays. Does
anyone have code that uses the comma operator anywhere
inside square brackets, without using redundant parens?
(Note that
    a = b[(c=d+5, d)];
would still work correctly.)

Note that there is precedent for allowing operators with
variable number of arguments -- not only is there operator++
(where the second argument is there for syntax only), but
there's operator new() (where any number of arbitrary
arguments can be used for any purpose).

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Subscripting in math is quite common:

Instead of f(x_1, ..., x_n), one may subscript say the first j variables
writing (using TeX pseudo-code)
 (1)    $f_{x_1, ..., x_j}(x_{j+1}, ..., x_n)$
This way, one gets a new functions named $f_{x_1, ..., x_j}$ to which the
variables $(x_{j+1}, ..., x_n)$ can be applied.

This subscripting then corresponds to the "Currying" used in functional
languages, with the difference that such functional languages often
identify Hom(X x Y, Z) with Hom(X, Hom(Y, Z)) (i.e., f(x, y) and f(x)(y)
are identified in say the type system). This latter identification,
though, is uncommon in standard working math.

If I translate this into C++, then (1) above should be written
    f[x_1, ..., x_j](x_{j+1}, ..., x_n)
Thus, one may use the C++ subscription operator to indicate the
non-functional language equivalent of "Currying":

If one needs to be able to partially apply some variables and by that
create a new runtime object, the operator[] should be used.

Then this also suggests that multivariate operator[] should be added to
C++ for such a use.

In reality, people can of course use it the way they please, but when
writing libraries and such, it is important to draw up general principles.
So then this idea might be used.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

> Would I be correct in thinking that if compilers were changed to accept
> tab[i,j] as operator[](int,int), then any existing code that is broken
could
> be flagged.
>
> Would it also be true that the following built-in implementations would
> fix such code?
>
>     operator[](int i, int j) { return operator[](j); }
>     operator[](int i, int j, int k) { return operator[](k); }
>     // etc.

No.  Such an operator would not impose correct ordering on the evaluation of
the operands.  Further, I don't believe a sequence point would be imposed.
These are primary reasons for using operator, in the first place.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

remove.haberg@matematik.su.se (Hans Aberg) wrote
> kanze@gabi-soft.de (James Kanze) wrote:
> >The fact that this is legal is a contract.  You can't just break it like
> >that.  If you want to break it, you have to prove two things: that the
> >amount of code which will be affected is small, that there is a great
> >benefit, and that there is no reasonable alternative solution which
> >would solve the problem.
>
> It sounds as three things to me, unless the laws of arithmetic have
> changed lately. :-)

A wise man once said, there are three types of people in this world:
  * Those who can count, and
  * Those who cannot count.

:-)

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article
<remove.haberg-3107021249090001@du132-226.ppp.su-anst.tninet.se>, Hans
Aberg <remove.haberg@matematik.su.se> writes
>If I translate this into C++, then (1) above should be written
>    f[x_1, ..., x_j](x_{j+1}, ..., x_n)
>Thus, one may use the C++ subscription operator to indicate the
>non-functional language equivalent of "Currying":
>
>If one needs to be able to partially apply some variables and by that
>create a new runtime object, the operator[] should be used.
>
>Then this also suggests that multivariate operator[] should be added to
>C++ for such a use.

I agree though many seem happy to borrow operator() for this purpose.
The other alternative is to overload the comma operator but that
requires that at least one operand is a udt. I know that parsing is an
arcane art, but I would think that a bit of brute power could be used to
allow a late decision as to whether the commas in a[x,y,z] are operators
or purely punctuators.

--
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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

| In article
| <remove.haberg-3107021249090001@du132-226.ppp.su-anst.tninet.se>, Hans
| Aberg <remove.haberg@matematik.su.se> writes
| >If I translate this into C++, then (1) above should be written
| >    f[x_1, ..., x_j](x_{j+1}, ..., x_n)
| >Thus, one may use the C++ subscription operator to indicate the
| >non-functional language equivalent of "Currying":
| >
| >If one needs to be able to partially apply some variables and by that
| >create a new runtime object, the operator[] should be used.
| >
| >Then this also suggests that multivariate operator[] should be added to
| >C++ for such a use.
|
| I agree though many seem happy to borrow operator() for this purpose.
| The other alternative is to overload the comma operator but that
| requires that at least one operand is a udt. I know that parsing is an
| arcane art, but I would think that a bit of brute power could be used to
| allow a late decision as to whether the commas in a[x,y,z] are operators
| or purely punctuators.

Right now, I've seen no convincing argument to the effect that adding
such an operator is not just an act of "adding a neat feature".
Overloading (binary) operator[] as proposed in this thread does not
address one the use of operator() whereby, when used in conjunction
with standard binders, one take take a slice -- either a row or a
column -- of a two dimensional array.

That leaves me under the impression that this thread is about adding a
"neat" feature without exposing a global picture of how it interacts
with the rest of language.  That is one reason of why I'm not yet
convinced it worths the effort.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3fzy1t8ev.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| In such a picture, using a[i][j] would not be correct, or even easy to
| >| implement, because if the representation (class X above) is say a sparse
| >| matrix m, m[i] may not make sense. And it is somewhat tricky to keep track
| >| of the right index also for iterated vectors m[i][j] -- it is less
| >| confusing to use m[i, j].
|
| >| And writing a(i, j) in such a context would be corny relative to typical
| >| C++ lingo, as operator[] is known as the subscription operators.
| >
| >But, then a[i, j] is equally confusing.
|
| What do you mean? -- Your reply is somewhat cryptic.

I find a[i, j] is equally "corny relative to typical C++ lingo" as
a(i, j).

| (In math matrix coordinates $m_ij$ translates to C++ m[i, j], as
| operator[] is called the "subscription" operator in C++.)

Actually, in Math $m_{i,j}$ is the value of the function $m$ at the
point $(i,j)$. As such I would expect it to translate to $m(i,j)$
using C++ function call.  Senior numerical programmers knew it ;-)

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

[...]

| If I translate this into C++, then (1) above should be written
|     f[x_1, ..., x_j](x_{j+1}, ..., x_n)
| Thus, one may use the C++ subscription operator to indicate the
| non-functional language equivalent of "Currying":
|
| If one needs to be able to partially apply some variables and by that
| create a new runtime object, the operator[] should be used.
|
| Then this also suggests that multivariate operator[] should be added to
| C++ for such a use.

Well, I can't follow how you reach that conclusion.

Talking of currying, I should point out that using the function call
operator, one can use the standard binders to operator on specific rows
or columns

    bind1st(m, i);
    bind2nd(m, j);

something that doesn't work with operator[] in any of its proposed
forms.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m33ctzrkdr.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| >If I translate this into C++, then (1) above should be written
>| >    f[x_1, ..., x_j](x_{j+1}, ..., x_n)
>| >Thus, one may use the C++ subscription operator to indicate the
>| >non-functional language equivalent of "Currying":

>| >Then this also suggests that multivariate operator[] should be added to
>| >C++ for such a use.

>| I agree though many seem happy to borrow operator() for this purpose.
>| The other alternative is to overload the comma operator but that
>| requires that at least one operand is a udt. I know that parsing is an
>| arcane art, but I would think that a bit of brute power could be used to
>| allow a late decision as to whether the commas in a[x,y,z] are operators
>| or purely punctuators.

>Right now, I've seen no convincing argument to the effect that adding
>such an operator is not just an act of "adding a neat feature".

The reason that one is using subscripting in math is not that it cannot be
done by other means, but because the notational expressivity helps to
bring out the underlying notions.

So you are, right, one component is to merely add a "nice feature" that
helps the expressivity of the code.

>Overloading (binary) operator[] as proposed in this thread does not
>address one the use of operator() whereby, when used in conjunction
>with standard binders, one take take a slice -- either a row or a
>column -- of a two dimensional array.

I am not sure what you have in your mind here: If the matrix is sparse,
then one may not be able to take a slice of columns or rows in a natural
way. One will need to implement special new classes just for those
purposes.

Take for example matrices where all non-zero elements are on the diagonal
(or, if you want to make it more complicated, where it is on Jordan normal
form or some other criteria of more scattered sparsity). Then one would
have to define
  template<class X>
  class diagonal_matrix {
    X zero_; // Just to have something the return references to.
    vector<X> diagonal_ // Elements on the diagonal;

    reference_type operator[](size_type, size_type);
   };

This class should be able to easily work together with other matrix
classes -- so therefore I think one needs an adaptor class:
    template <class X>
    class matrix {
      ...
      X& operator[](size_type, size_type);
    };

What should diagonal_matrix::operator[](size_type) return in this case? --
One then needs to create a special class diagonal_matrix_row or
diagonal_matrix_column, which can maintain the references to the correct
elements (zero_ or an element in the diagonal_ vector).

When you say that multivariate operator[] should not be added to C++   ,
have you thought through such cases, how it works with writing such code?

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <ZJgjWCCkx9R9Ew2+@robinton.demon.co.uk>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:

>>If I translate this into C++, then (1) above should be written
>>    f[x_1, ..., x_j](x_{j+1}, ..., x_n)
>>Thus, one may use the C++ subscription operator to indicate the
>>non-functional language equivalent of "Currying":
...
>>Then this also suggests that multivariate operator[] should be added to
>>C++ for such a use.

>I agree though many seem happy to borrow operator() for this purpose.
>The other alternative is to overload the comma operator but that
>requires that at least one operand is a udt. I know that parsing is an
>arcane art, but I would think that a bit of brute power could be used to
>allow a late decision as to whether the commas in a[x,y,z] are operators
>or purely punctuators.

I tend to think that the use of "operator," should be restricted (if
possible), as it leads to a rather corny syntax: It is natural to think of
the syntax (x_1, ..., x_n) as a vector, which conflicts with the semantics
of the comma.

Also note that one can make operator[] (resp. operator()) cooperate with
"operator,", by introducing operator[,] (resp. operator(,)) supplying
argument iterations: If operator[](X_1, ..., X_n) is available, then that
operator is used; if it is not, the compiler tries looks if
  X_{n-1} operator(,)(X_{n-1}, X_n)
reduce to operator[](X_1, ..., X_{n-1}) (and same for operator () &
operator(,)). -- Or something.

This way, one can implement C++ type-checked equivalents to the C ellipsis
"...".

-- This showed up in the context of the operator generalization that cover
the C++ expressions that I made. Then one ends up with a series of n-ary
operators, where n is fixed and each defined separately in each case. But
if one should cover up use of operators constructs like
  (x_1, ..., x_n)
then one needs to keep the tokens "(", ",", and ")" tied together, while
supplying a way to admit the iteration.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3ado8s4zw.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| >| In such a picture, using a[i][j] would not be correct, or even easy to
>| >| implement, because if the representation (class X above) is say a sparse
>| >| matrix m, m[i] may not make sense. And it is somewhat tricky to keep track
>| >| of the right index also for iterated vectors m[i][j] -- it is less
>| >| confusing to use m[i, j].

>| >| And writing a(i, j) in such a context would be corny relative to typical
>| >| C++ lingo, as operator[] is known as the subscription operators.

>| >But, then a[i, j] is equally confusing.

>| What do you mean? -- Your reply is somewhat cryptic.

>I find a[i, j] is equally "corny relative to typical C++ lingo" as
>a(i, j).

But then there is not much of general underlying principles to act on. :-)

>| (In math matrix coordinates $m_ij$ translates to C++ m[i, j], as
>| operator[] is called the "subscription" operator in C++.)
>
>Actually, in Math $m_{i,j}$ is the value of the function $m$ at the
>point $(i,j)$. As such I would expect it to translate to $m(i,j)$
>using C++ function call.  Senior numerical programmers knew it ;-)

This, is correct, that matrices with values are defined as simply functions
    m: I x J -> A

But matrices will use subscripting whenever it is notationally convenient.

And, C++, when naming operator[] the "subscripting operator" seems to
imitate that.

In math, one can of course switch between the pictures, functions and
subscripts. Computers, and computer languages are much less flexible, so
that one has to be more specific.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

Allan_W@my-dejanews.com (Allan W) wrote (abridged):
> A wise man once said, there are three types of people in this world:

And 10 kinds of programmer: those who think in binary, and those who
don't.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3ofcoqayl.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| If I translate this into C++, then (1) above should be written
>|     f[x_1, ..., x_j](x_{j+1}, ..., x_n)
>| Thus, one may use the C++ subscription operator to indicate the
>| non-functional language equivalent of "Currying":

>| If one needs to be able to partially apply some variables and by that
>| create a new runtime object, the operator[] should be used.

>| Then this also suggests that multivariate operator[] should be added to
>| C++ for such a use.

>Well, I can't follow how you reach that conclusion.

Isn't that your problem? :-)

One alternative is of course to remove the "subscripting" operator from
C++ altogether, say by renaming operator[] to "array indexing operator" or
something so that people don't think it should be used in order to imitate
subscripting notation.

>Talking of currying, I should point out that using the function call
>operator, one can use the standard binders to operator on specific rows
>or columns

>    bind1st(m, i);
>    bind2nd(m, j);

>something that doesn't work with operator[] in any of its proposed
>forms.

This wouldn't work on sparse matrices, I figure (see other post).

I think that one in C++ one would want top be able to avoid "automatic"
functional closures whenever possible due to the overhead it may generate
in runtime code.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

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

[...]

| >Right now, I've seen no convincing argument to the effect that adding
| >such an operator is not just an act of "adding a neat feature".
|=20
| The reason that one is using subscripting in math is not that it cannot=
 be
| done by other means, but because the notational expressivity helps to
| bring out the underlying notions.

Having been educated in a Bourbaki school, I respectfully disagree
with your statement :-) =20

Subscripting isn't more expressive than superscription.  Given that,
do you think C++ should invent an operator for superscription?

[...]

| >Overloading (binary) operator[] as proposed in this thread does not
| >address one the use of operator() whereby, when used in conjunction
| >with standard binders, one take take a slice -- either a row or a
| >column -- of a two dimensional array.=20
|=20
| I am not sure what you have in your mind here: If the matrix is sparse,
| then one may not be able to take a slice of columns or rows in a natura=
l
| way.

If your above statement were true, then I don't think using
subscription would be more natural.  But the fact is that specialist
in sparse matrices computations do use the concept of row and column.=20

Actually, the strategy with sparse matrices is different -- usually
they have structures (diagonal, bi-diagonal, sparse-hankel).  In such
situation, the general notion of subscription isn't effective and I
don't see any benefit operator[] would bring. =20

[...]

| When you say that multivariate operator[] should not be added to C++=B4=
,
| have you thought through such cases, how it works with writing such cod=
e?

1) I'm *not* saying multivariate operator[] _should not_ be added to
   C++.  Please don't put words in my mouth.

2) I think, I have a fair experience with numerical codes in C++
   (univariate and multivariate polynomial computations; matrices).
  =20
None of the current proposal of operator[] doesn't seem to make better
the code I've seen.

--=20
Gabriel Dos Reis, gdr@integrables-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3ado8s4zw.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| >| In such a picture, using a[i][j] would not be correct, or even easy to
| >| >| implement, because if the representation (class X above) is say a sparse
| >| >| matrix m, m[i] may not make sense. And it is somewhat tricky to keep track
| >| >| of the right index also for iterated vectors m[i][j] -- it is less
| >| >| confusing to use m[i, j].
|
| >| >| And writing a(i, j) in such a context would be corny relative to typical
| >| >| C++ lingo, as operator[] is known as the subscription operators.
|
| >| >But, then a[i, j] is equally confusing.
|
| >| What do you mean? -- Your reply is somewhat cryptic.
|
| >I find a[i, j] is equally "corny relative to typical C++ lingo" as
| >a(i, j).
|
| But then there is not much of general underlying principles to act on. :-)

Certainly; but none of those underlying principles are addressed by the
operator[] proposals in any form.

| >| (In math matrix coordinates $m_ij$ translates to C++ m[i, j], as
| >| operator[] is called the "subscription" operator in C++.)
| >
| >Actually, in Math $m_{i,j}$ is the value of the function $m$ at the
| >point $(i,j)$. As such I would expect it to translate to $m(i,j)$
| >using C++ function call.  Senior numerical programmers knew it ;-)
|
| This, is correct, that matrices with values are defined as simply functions
|     m: I x J -> A
|
| But matrices will use subscripting whenever it is notationally convenient.

But, that is just a form notation.  Another one, which is also common
is superscription.

For example, when you take the metric of a Riemmannian manifold,
you'll certainly notice that, in coordinates, the metric matrices is
given in superscription form.

More generally, in multilinear algebra, the coordinates of p-vectors
are given in subscription form, whereas the coordinates of p-forms are
given in superscription form.

[...]

| In math, one can of course switch between the pictures, functions and
| subscripts. Computers, and computer languages are much less flexible, so
| that one has to be more specific.

Certainly.  But then, in getting specific one should not fall into
syntactical traps.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3ofcoqayl.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| If I translate this into C++, then (1) above should be written
| >|     f[x_1, ..., x_j](x_{j+1}, ..., x_n)
| >| Thus, one may use the C++ subscription operator to indicate the
| >| non-functional language equivalent of "Currying":
|
| >| If one needs to be able to partially apply some variables and by that
| >| create a new runtime object, the operator[] should be used.
|
| >| Then this also suggests that multivariate operator[] should be added to
| >| C++ for such a use.
|
| >Well, I can't follow how you reach that conclusion.
|
| Isn't that your problem? :-)

If you can't explain and convince enough people of the benefits of
your proposal, I think it is *also* your problem.

[...]

| >Talking of currying, I should point out that using the function call
| >operator, one can use the standard binders to operator on specific rows
| >or columns
|
| >    bind1st(m, i);
| >    bind2nd(m, j);
|
| >something that doesn't work with operator[] in any of its proposed
| >forms.
|
| This wouldn't work on sparse matrices, I figure (see other post).

I saw and responded: Your argumentation doesn't hold.  See my followup.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:

> Right now, I've seen no convincing argument to the effect that adding
> such an operator is not just an act of "adding a neat feature".
> Overloading (binary) operator[] as proposed in this thread does not
> address one the use of operator() whereby, when used in conjunction
> with standard binders, one take take a slice -- either a row or a
> column -- of a two dimensional array.
>
> That leaves me under the impression that this thread is about adding a
> "neat" feature without exposing a global picture of how it interacts
> with the rest of language.  That is one reason of why I'm not yet
> convinced it worths the effort.


    I'm proposing that "operator[]" and "operator()" have the same
argument syntax.  This makes the grammar more uniform.
See A.5, "postfix-expression".

    As for semantics, if someone wants to use this to implement
functional programming, that's OK, but I don't see that as
the mainstream application.  The mainstream application is,
of course, multidimensional arrays.

    I agree that everything you can do with "operator[]" you
can potentially do with "operator()".  But, given that
C++ uses "[]" for both built-in and STL array access,
for consistency, "()" should not be used for subscripting.
This is a readability issue.  C++ programmers are used to associating
"[]" with subscripted data access.  Constructs like

  tab(i,j) = 10;

are unfamiliar to C++ programmers, even though operator overloads
can be constructed to make them valid.

    And, realistically, use of the comma operator inside square
brackets is somewhere between "extremely rare" and "extinct".

     John Nagle
     Animats


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

| Gabriel Dos Reis wrote:
|
| > Right now, I've seen no convincing argument to the effect that adding
| > such an operator is not just an act of "adding a neat feature".
| > Overloading (binary) operator[] as proposed in this thread does not
| > address one the use of operator() whereby, when used in conjunction
| > with standard binders, one take take a slice -- either a row or a
| > column -- of a two dimensional array.
| >
| > That leaves me under the impression that this thread is about adding a
| > "neat" feature without exposing a global picture of how it interacts
| > with the rest of language.  That is one reason of why I'm not yet
| > convinced it worths the effort.
|
|
|     I'm proposing that "operator[]" and "operator()" have the same
| argument syntax.  This makes the grammar more uniform.
| See A.5, "postfix-expression".

Right now, I'm seeing a syntaxe along the line

   m[i, j];

that is certainly not usable with the standard binders.

|     As for semantics, if someone wants to use this to implement
| functional programming, that's OK, but I don't see that as
| the mainstream application.  The mainstream application is,
| of course, multidimensional arrays.

Well, my view is the following:

  1) adding your proposal to the language does break C++98's and any
     previous release of C++'s semantics.

  2) I perfectly understand that the next version of C++ probably
     won't be 100% compatible with current version.  But the
     incompatibilities should, IMHO, bring benefits that worth them.

  3) Right now, I've seen no convincing argument that the proposed
     functionality would add anything that isn't already expressible
     in the language, that the proposed extension embedds into C++
     idiomatic constructs.  That is, I've not seen any benefit that
     worths the incompatibility.  I'm not saying there is none.  Just
     that none was exhibited.  And as such, I'm not convinced that the
     proposed extension worths the trouble.

|
|     I agree that everything you can do with "operator[]" you
| can potentially do with "operator()".  But, given that
| C++ uses "[]" for both built-in and STL array access,
| for consistency, "()" should not be used for subscripting.
| This is a readability issue.  C++ programmers are used to associating
| "[]" with subscripted data access.  Constructs like
|
|   tab(i,j) = 10;
|
| are unfamiliar to C++ programmers,

Are you saying that people working everyday with that construct and who
use them as part of the dayly job aren't C++ programmers?

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3znw7lc51.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| But then there is not much of general underlying principles to act on. :-)
>
>Certainly; but none of those underlying principles are addressed by the
>operator[] proposals in any form.

I thought I gave one such principle: Admitting general type of
subscripting used in math, with application to matrices.

>| This, is correct, that matrices with values are defined as simply functions
>|     m: I x J -> A
>|
>| But matrices will use subscripting whenever it is notationally convenient.
>
>But, that is just a form notation.

Well, the idea of a computer language, like C++, is to supply notation for
various computational constructs.

>  Another one, which is also common
>is superscription.
...
>More generally, in multilinear algebra, the coordinates of p-vectors
>are given in subscription form, whereas the coordinates of p-forms are
>given in superscription form.

I mentioned that contravariant/covariant tensor notation often used in say
physics in another post

Math uses many different kinds of notation, and computer languages always
come out short of that for various practical reasons.

The main thing here, though, is that C++ already has something called a
"subscription" operator. It is then unreasonable to extend it so that it
can be used to better approximate subscription notation in math, which I
gather is the origin of the 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

>> What about introducing some kind of
>> `multiple-subscripting' operator?
>>    T& operator[][](int x, int y);

HA> What about classes
HA>    class A {
HA>    public:
HA>      A& operator[](X x);
HA>      A& operator[][](X x, X y);

I'd say that such classes are extremely rare thing, if any, at least
I can not remember any of it kind, so I could live with need to write
(a[x])[y] to get a.operator[x].operator[y]. And, yes, this does
introduce the same backward compatibility problems as a[x, y].

I am not insisting on introducing operator[][], but it seems
rather attractive to me to be able substitute int m[3][3]
with Matrix<int, 3, 3> without modifiyng client source code.
Alas, it seems that my hope is vain :-)

--
Pavel

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3znw7lc51.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| But then there is not much of general underlying principles to act on. :-)
| >
| >Certainly; but none of those underlying principles are addressed by the
| >operator[] proposals in any form.
|
| I thought I gave one such principle: Admitting general type of
| subscripting used in math, with application to matrices.

But, I'm questionning your general principial.  As fas as I can tell,
the general notation in Linear Algebra is not subscription.

[...]

| The main thing here, though, is that C++ already has something called a
| "subscription" operator. It is then unreasonable to extend it so that it
| can be used to better approximate subscription notation in math, which I
| gather is the origin of the operator[]?

IMO, it becomes unreasonable when one insists on that "subscription"
operator which is only remotely connected to the "claimed
mathematical" concept whereas there already exists alternatives that
provides better mapping.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3d6t2kjk2.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>Well, my view is the following:

>  1) adding your proposal to the language does break C++98's and any
>     previous release of C++'s semantics.

This is of some concern. Therefore, I think that C++ would be better off
to isolate a new C++ high-level core separated from C.

One way to do this might be that genuine C code could be included within
syntactic brackets (like extern "C", but applying to the code as well, not
only the linkage).

C++ carries too much weight from its C heritage, so that might simplify
the future development of the languiage.

>  2) I perfectly understand that the next version of C++ probably
>     won't be 100% compatible with current version.  But the
>     incompatibilities should, IMHO, bring benefits that worth them.

That's the reason the suggestion has been added: The benefits of proper
syntactic expressivity, instead of having to rely on corny, hard to parse,
language constructs.

>  3) Right now, I've seen no convincing argument that the proposed
>     functionality would add anything that isn't already expressible
>     in the language, that the proposed extension embedds into C++
>     idiomatic constructs.  That is, I've not seen any benefit that
>     worths the incompatibility.  I'm not saying there is none.  Just
>     that none was exhibited.  And as such, I'm not convinced that the
>     proposed extension worths the trouble.

This seems to be a very personal opinion of yours. I showed some matrix
examples where the benefit might be quite significant.

>|Constructs like
>|
>|               tab(i,j) = 10;

Indeed, this looks corny. Compare with
    tab[i, j] = 10;
and one sees instantly why the multivariate operator[] ought to be added to C++.

Summing it up, it seems that adding a multivariate operator[] will
significantly enhance the syntactic expressivity of C++, bring it closer
to important mathematical constructs, and simplfy the treatment of
matrices. No convincing arguments for the opposite have been presented
here, what I have seen.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3it2vlax8.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| >| If I translate this into C++, then (1) above should be written
>| >|     f[x_1, ..., x_j](x_{j+1}, ..., x_n)
>| >| Thus, one may use the C++ subscription operator to indicate the
>| >| non-functional language equivalent of "Currying":

>| >| Then this also suggests that multivariate operator[] should be added to
>| >| C++ for such a use.

>| >Well, I can't follow how you reach that conclusion.

>| Isn't that your problem? :-)

>If you can't explain and convince enough people of the benefits of
>your proposal, I think it is *also* your problem.

Oh, so you want me to explain further -- you did not say that. :-)

Of course, there is no guarantee of success in this game. :-)

The reasoning is that as C++ has something called a subscription operator,
originating in math subscripting notation for C arrays, now that C++ has
the capability of more expressive user defined operators, it would be
prudent to enhance its capacity with respect to math notation in this
respect.

Can it be simpler?

>| >Talking of currying, I should point out that using the function call
>| >operator, one can use the standard binders to operator on specific rows
>| >or columns

>| >    bind1st(m, i);
>| >    bind2nd(m, j);

>| >something that doesn't work with operator[] in any of its proposed
>| >forms.

>| This wouldn't work on sparse matrices, I figure (see other post).

>I saw and responded: Your argumentation doesn't hold.  See my followup.

So it then seems that I have to wait for that followup to appear. :-)

Waiting... :-)

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m34refmr7m.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:
>| The reason that one is using subscripting in math is not that it cannot be
>| done by other means, but because the notational expressivity helps to
>| bring out the underlying notions.
>
>Having been educated in a Bourbaki school, I respectfully disagree
>with your statement :-) =20

Please explain what you mean, because it is the standard Bourbaki
definitions that I have in my mind (which should rely on axiomatic set
theory underneath).

I didn't know that there still is a "Bourbaki school" though: To me
Bourbaki was a very good input of the epoch, the first half of the 20th
century. I recall that one felt that the logic structure at the time of
period was fuzzy, which was a motivation for the Bourbaki group.

But Bourbaki was very careful in pointing out that absolute logical
formalism is not always helpful to the human reader. Therefore one
introduced concepts such as "abuse of notation", meaning that one is using
a notation that is formally incorrect, but easier for humans to parse.

Which brings us back at the discussion at hand: Should C++ be a
notationally minimalistic language, a view also rejected by Bourbaki that
seek to achieve perfect logical structure?

Or should C++, just as Bourbaki, try to help the human readers to parse
the code?

>Subscripting isn't more expressive than superscription.

Have you ever looked into a physics text, where subscripts and
superscripts are use to indicate covariant and contravariant tensors?

I really do not which one is the more expressive; often superscripts and
subscripts are used to denote different things.

>  Given that,
>do you think C++ should invent an operator for superscription?

As for myself, I classified multicomponent operators and studied the
implementation of a such generalized systems. If one so would want, C++
might introduce such a more general system.

As for the discussion at hand, C++ has something called a "subscripting"
operators, but its use is restricted relative to the concept of
"subscripting". We are here discussing whether to complete the already
existing subscripting operator in a natural way.

C++ does not have a superscripting operator, so that would be a larger
step, to introduce a new concept.

But as for myself, I have no opinion about what C++ should do, as I like
to experiment with much more general operator systems.

>| >Overloading (binary) operator[] as proposed in this thread does not
>| >address one the use of operator() whereby, when used in conjunction
>| >with standard binders, one take take a slice -- either a row or a
>| >column -- of a two dimensional array.=20

>| I am not sure what you have in your mind here: If the matrix is sparse,
>| then one may not be able to take a slice of columns or rows in a natural
>| way.

>If your above statement were true, then I don't think using
>subscription would be more natural.

Sure it is, one only cannot take a whole row or a whole column at the same
time. -- This is in fact impossible for ordinary C matrix arrays as well,
because either the rows or columns become scattered.

>  But the fact is that specialist
>in sparse matrices computations do use the concept of row and column.=20

Well, in an matrix::operator[](size_type i, size_type j), I figure that
the i's would be called row, and the j's columns.

But this does not mean that one can separate out a whole row or column

>Actually, the strategy with sparse matrices is different -- usually
>they have structures (diagonal, bi-diagonal, sparse-hankel).  In such
>situation, the general notion of subscription isn't effective and I
>don't see any benefit operator[] would bring.

Why shouldn't it be effective? -- I just gave an example where diagonal
matrices can have an effective matrix::operator[](size_type i, size_type
j), but not an effective matrix::operator[](size_type i).

>| When you say that multivariate operator[] should not be added to C++,
>| have you thought through such cases, how it works with writing such code?

>1) I'm *not* saying multivariate operator[] _should not_ be added to
>   C++.  Please don't put words in my mouth.

>2) I think, I have a fair experience with numerical codes in C++
>   (univariate and multivariate polynomial computations; matrices).

>None of the current proposal of operator[] doesn't seem to make better
>the code I've seen.

So what would you view as a reason for adding the multivariate operator[]
to C++?

I mean, anyone can take the view that as it is always possible to use
other C++ constructs, it is not needed. But that is not the same thing as
that other code will be more expressive and intuitive to the human users.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

Allan_W@my-dejanews.com (Allan W) wrote in message
news:<23b84d65.0207301815.6d38c3d7@posting.google.com>...
> "Pavel Kuznetsov" <pavel@despammed.com> wrote
> > As far as I understand it is unlikely that overloading operator[]
> > with multiple parameters would be permitted because of backward
> > compatibility.

> Backward compatibility?

> Suppose the new standard did allow operator[] to overload on multiple
> parameters. What compatibility problems would this cause?

> The only answer I can think of is code like this:
>     a = b[c=d+5, d];
> which is currently equivalent to:
>     c = d+5;
>     a = b[d];
> except that it uses the "comma operator" to do it all in
> one statement. (Probably common in "obfuscated C" contest
> entries.) This code would break, but maybe it deserves to
> die.

If we take the argument that we should break code that is legal, but
bad, there are a lot of changes we should make.  C explicitly kept gets,
simply because eliminating it would have meant breaking a promise.

I'd much rather see comma used as a punctuator, rather than an operator,
in [] (or anywhere else, for that matter).  But promises have been made,
and I believe in keeping them.

> Is there any non-contrived code that does anything even vaguely
> similar to this?

Who knows?  I haven't seen all of the C++ code ever written.

> Even on built-in arrays. Does
> anyone have code that uses the comma operator anywhere
> inside square brackets, without using redundant parens?
> (Note that
>     a = b[(c=d+5, d)];
> would still work correctly.)

> Note that there is precedent for allowing operators with variable
> number of arguments -- not only is there operator++ (where the second
> argument is there for syntax only), but there's operator new() (where
> any number of arbitrary arguments can be used for any purpose).

Heck, it's even there for operator().

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <aibk9s$12fpfc$1@ID-97366.news.dfncis.de>, "Pavel Kuznetsov"
<pavel@despammed.com> wrote:

>I am not insisting on introducing operator[][], but it seems
>rather attractive to me to be able substitute int m[3][3]
>with Matrix<int, 3, 3> without modifiyng client source code.
>Alas, it seems that my hope is vain :-)

It is better to rewrite old code with respect to a syntax that is more
firm. -- If your intent is to substitute int m[3][3] with std::matrix<int,
3, 3>, then it is probably better to make sure that aspects the the usage
is correct, as well ensuring that the new class std::matrix will correct
and easy to use.

And it is not difficult to make replacements
    int m[3][3]  ->  std::matrix<int, 3, 3>
    m[i][j]      ->  m[i, j]
with a good editor using say regular expressions replacements.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <m3ado6fw4e.fsf@soliton.integrable-solutions.net>, Gabriel Dos
Reis <gdr@soliton.integrable-solutions.net> wrote:

>| I thought I gave one such principle: Admitting general type of
>| subscripting used in math, with application to matrices.
>
>But, I'm questionning your general principial.  As fas as I can tell,
>the general notation in Linear Algebra is not subscription.

Really; so what is the "general" notation for the matrix component $m_{ij}$?

-- Or are you relying on a new definition of the word "general" that I am
unaware of?

>| The main thing here, though, is that C++ already has something called a
>| "subscription" operator. It is then unreasonable to extend it so that it
>| can be used to better approximate subscription notation in math, which I
>| gather is the origin of the operator[]?

>IMO, it becomes unreasonable when one insists on that "subscription"
>operator which is only remotely connected to the "claimed
>mathematical" concept whereas there already exists alternatives that
>provides better mapping.

So far you haven't given any examples of a better alternative:

Clearly, your suggestion of using operator() instead of operator[] is much
worse. :-)

BTW, what do you have quotes: "claimed mathematical"; is there a special
meaning attached to this your "concept"?

And what criteria are you using in order to distinguish between "remotely
connected" and say "strongly connected" in the context of math-C++
relations?

  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.jamesd.demon.co.uk/csc/faq.html                       ]

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

[...]

| >  2) I perfectly understand that the next version of C++ probably
| >     won't be 100% compatible with current version.  But the
| >     incompatibilities should, IMHO, bring benefits that worth them.
|
| That's the reason the suggestion has been added: The benefits of proper
| syntactic expressivity, instead of having to rely on corny, hard to parse,
| language constructs.

The function call isn't harder to parse (from a user point of view)
than the proposed operator[] extension.  The function call operator
has become part of C++ idiomatic construct. As such, it isn't
certainly a corny language construct.  At leats not cornier than
anything else in the language.

| >  3) Right now, I've seen no convincing argument that the proposed
| >     functionality would add anything that isn't already expressible
| >     in the language, that the proposed extension embedds into C++
| >     idiomatic constructs.  That is, I've not seen any benefit that
| >     worths the incompatibility.  I'm not saying there is none.  Just
| >     that none was exhibited.  And as such, I'm not convinced that the
| >     proposed extension worths the trouble.
|
| This seems to be a very personal opinion of yours.

But then, the supposed syntatic expressivity is also a personal
opinion of yours!

| I showed some matrix
| examples where the benefit might be quite significant.

And I demonstrated that the supposed example is based on a syntatical
pitfall.

[...]

| Summing it up, it seems that adding a multivariate operator[] will
| significantly enhance the syntactic expressivity of C++, bring it closer
| to important mathematical constructs,

However it was demonstrated that those supposed mathematical constructs
are flawed.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3it2vlax8.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| >| If I translate this into C++, then (1) above should be written
| >| >|     f[x_1, ..., x_j](x_{j+1}, ..., x_n)
| >| >| Thus, one may use the C++ subscription operator to indicate the
| >| >| non-functional language equivalent of "Currying":
|
| >| >| Then this also suggests that multivariate operator[] should be added to
| >| >| C++ for such a use.
|
| >| >Well, I can't follow how you reach that conclusion.
|
| >| Isn't that your problem? :-)
|
| >If you can't explain and convince enough people of the benefits of
| >your proposal, I think it is *also* your problem.
|
| Oh, so you want me to explain further -- you did not say that. :-)

Oh.  That is fine.

| Of course, there is no guarantee of success in this game. :-)
|
| The reasoning is that as C++ has something called a subscription operator,
| originating in math subscripting notation for C arrays, now that C++ has
| the capability of more expressive user defined operators, it would be
| prudent to enhance its capacity with respect to math notation in this
| respect.
|
| Can it be simpler?

no more accurate however :-(


| >| >Talking of currying, I should point out that using the function call
| >| >operator, one can use the standard binders to operator on specific rows
| >| >or columns
|
| >| >    bind1st(m, i);
| >| >    bind2nd(m, j);
|
| >| >something that doesn't work with operator[] in any of its proposed
| >| >forms.
|
| >| This wouldn't work on sparse matrices, I figure (see other post).
|
| >I saw and responded: Your argumentation doesn't hold.  See my followup.
|
| So it then seems that I have to wait for that followup to appear. :-)

If you still don't see it, you should alert your news server syadmin
:-)

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

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

| In article <m3ado6fw4e.fsf@soliton.integrable-solutions.net>, Gabriel Dos
| Reis <gdr@soliton.integrable-solutions.net> wrote:
|
| >| I thought I gave one such principle: Admitting general type of
| >| subscripting used in math, with application to matrices.
| >
| >But, I'm questionning your general principial.  As fas as I can tell,
| >the general notation in Linear Algebra is not subscription.
|
| Really; so what is the "general" notation for the matrix component $m_{ij}$?

The general notation of a matrix isn't $m_{ij}$.
My book use $m^{ij}$, $m_i^j$, $m(i,j)$.

Following your reasoning, a more accurate extention should be
"overloaded missing whitespace" so that we could just write m[ij] to
match your general notation ;-).

[...]

| >IMO, it becomes unreasonable when one insists on that "subscription"
| >operator which is only remotely connected to the "claimed
| >mathematical" concept whereas there already exists alternatives that
| >provides better mapping.
|
| So far you haven't given any examples of a better alternative:
|
| Clearly, your suggestion of using operator() instead of operator[] is much
| worse. :-)

Worse or not, it's been used for more than a decade in C++ and for
quite a longtime in "dedicated" programming languages like Fortran.
Or are you implying that the designers of that notation in Fortran
were totally ignorant of their pratice?

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hans Aberg wrote:

> In article <m3d6t2kjk2.fsf@soliton.integrable-solutions.net>, Gabriel Dos
> Reis <gdr@soliton.integrable-solutions.net> wrote:

>>|Constructs like
>>|
>>|               tab(i,j) = 10;
>>
>
> Indeed, this looks corny. Compare with
>     tab[i, j] = 10;
> and one sees instantly why the multivariate operator[] ought to be added to C++.
>
> Summing it up, it seems that adding a multivariate operator[] will
> significantly enhance the syntactic expressivity of C++, bring it closer
> to important mathematical constructs, and simplfy the treatment of
> matrices. No convincing arguments for the opposite have been presented
> here, what I have seen.


     Agreed.

     What's needed to formally propose this to the
Committee?

     John Nagle
     Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

<dmeyer@dmeyer.net> wrote in message news:ahn19m$u1j$1@jhereg.dmeyer.net...

> Worse, what if i and j aren't builtin types?  It would be kind of
> cruel to silently break existing legal code:
>
> include <iostream>
>
> struct foo
> {
>   int x;
>   foo(int y=0) : x(y) {}
>   operator int() const { return x; }
> };
>
> foo operator,(const foo& f1,const foo& f2)
> {
>   return foo(f1.x*f2.x);
> }
>
> int
> main()
> {
>   foo i(3);
>   foo j(5);
>   int a[100];
>   for (int i=0; i<100; ++i) { a[i]=i; }
>   std::cout << a[i] << ","
>             << a[j] << ","
>             << a[i,j]
>             << std::endl;
> }

Under the change being discussed, this code would no longer compile, since a
doesn't implement a two-argument form of operator[], so that's hardly a
silent change.

Changing the expression to a[(i,j)] would restore the old behavior.

-cd


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3n0sgbp62.fsf@soliton.integrable-solutions.net>...
> John Nagle <nagle@animats.com> writes:
...
> | (Might turn up some errors in existing code;
> | not everybody knows that "tab[i,j]" silently ignores the "j").
>
> Wrong.  It evaluates "i", then "j" and the value of the expression
> "i,j" is that of "j".  Nothing is silently ignored.

I agree that 'j' isn't ignored. Neither are the side-effects of 'i',
whatever those might be. However, the value of 'i' certainly is
ignored.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Jonathan Biggar wrote:

> John Nagle wrote:
>
>>    Is there any good reason why "operator[]" couldn't be
>>permitted to take more than one argument, so that
>>
>>                tab[i,j]
>>
>>would be meaningful for classes that chose to support it?
>>
>
> That would cause context-depending parsing difficulties. How you parsed
> 'tab[i,j]' (as a two dimensional indexing call, or as a one dimensional
> call and the use of the comma operator) would depend on the type of the
> variable 'tab'.


     To be specific, I'm proposing that the line in the C++ grammar
that reads

 postfix-expression:
  ...
  postfix-expression [ expression ]

should be changed to

  postfix-expression [ expression-list_opt ]

giving the operator "[]" the same argument syntax as a
function call.

     What will this break?  I've been searching code for
use of the comma operator within square brackets.
Here's the only one I've found so far,
from Microsoft's VC++ include file "header.h":

#define PROPERTY_RW(name,type, prid)                  \
         [propget, id(prid)]                           \
         HRESULT name([out, retval] type * retval);    \
                                                       \
         [propput, id(prid)]                           \
         HRESULT name([in] type name);


What do those lines "[propget, id(prid)]" do?  They look
like a C++ syntax error to me.  Is this some Microsoft extension?

     John Nagle
     Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

| Gabriel Dos Reis wrote:
|
| > Funny.  The number crunching codes I'm familiar with are written by
| > numerical folks with strong Fortran background and they use the
| > function call operator.  Actually, I think professional numerical
| > folks know how to write multidimensional subscription :-)
|
|
|      Take a look at how Numerical Recipes in C does multidimensional
| arrays.

Well, I wasn't aware we were diescussing Numerical Recipes in C.
I thaught, you were talking of number crunching codes in C++.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> | This is a construct likely to appear in
> | number-crunching inner loops.
>
> Funny.  The number crunching codes I'm familiar with are written by
> numerical folks with strong Fortran background and they use the
> function call operator.  Actually, I think professional numerical
> folks know how to write multidimensional subscription :-)

Yes, but some of us "numerical young'uns" who don't like Fortran would sure
like to use square brackets.  I support the idea of
operator[](int,int), but am aware of (some of) the implications, so I
don't expect to get it any time soon...  ;-)

--------------------------------------------------------------------------
Dave Steffen             "The reason that our people suffer in this way...
itf-taekwondo@attbi.com   is that our ancestors failed to rule wisely."
                                   -General Choi, Hong Hi

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote...
>
> #define PROPERTY_RW(name,type, prid)                  \
>          [propget, id(prid)]                           \
>          HRESULT name([out, retval] type * retval);
>
> What do those lines "[propget, id(prid)]" do?  They look
> like a C++ syntax error to me.  Is this some Microsoft extension?

It's not an extension, it's a macro that expands to IDL rather than C++.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:3D3F9FF0.7020706@animats.com...
>      What will this break?  I've been searching code for
> use of the comma operator within square brackets.
> Here's the only one I've found so far,
> from Microsoft's VC++ include file "header.h":
>
> #define PROPERTY_RW(name,type, prid)                  \
>          [propget, id(prid)]                           \
>          HRESULT name([out, retval] type * retval);    \
>                                                        \
>          [propput, id(prid)]                           \
>          HRESULT name([in] type name);
>
>
> What do those lines "[propget, id(prid)]" do?  They look
> like a C++ syntax error to me.  Is this some Microsoft extension?
>
>

Yes, those are an MS extension - attributes.  They appear only in contexts
where the normal operator[] is not allowed by the C++ grammar, so changing
the grammar as you propose would have no effect on these constructs
whatsoever.

-cd


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message
news:<3D404166.6070009@animats.com>...

> James Kanze wrote:

>  > The current approch yields code like:

> >     tab(i,j) = x ;

> > which isn't that bad.

>      If "stl::vector" overloaded "operator()" and used it for
> subscripting, that might be a plausible position.  But the STL doesn't
> do subscripting that way.

It uses the operator[] exactly the way Barton and Nackman says, as a
projection operator: given

    std::vector< std::vector< int > > array ;

array[ i ] returns the std::vector< int >.

One could argue that it should overload () as well, with a partial
specialization if the instantiation type is an std::vector.

>      If you see code that does subscripting that way, it's probably
> because it couldn't be done with square brackets.

That's certainly the initial motivation.  That, or that the programmers
were so used to Fortran it seemed more natural than []:-).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message
news:<3D406282.6010706@animats.com>...

> James Kanze wrote:

> (defense of not breaking comma operator within brackets).

> But James Kanze also wrote, in 1994, in response to some
> code that used the comma operator:

> > RESPONSE: kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425),
> > 12 Sept 94

> > If done correctly, yes.  I did it once to try it out, but have
> > abandonned it (at least in this context) as being to exoteric, and
> > resulting in code that is too difficult for a reader to understand.

:-).

I don't overload the comma operator in my code.  I don't even use the
built in comma operator, or at least so rarely that it wouldn't bother
me if it were removed from the language.  And I've certainly never used
the comma operator within [...].

Now, if you seriously believe that my style of coding is the one true
style, and that all other styles are worthless, and it doesn't matter if
we break them, then you have an argument.  As it happens, my style is
the best:-).  But I wouldn't go so far as to say that all code written
by anyone else is worthless, and that we can break it without
consideration.  And I *have* seen code which used the comma operator
within [...].  (Luckily, I didn't have to maintain it.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m34ren8zna.fsf@soliton.integrable-solutions.net>...
> John Nagle <nagle@animats.com> writes:

> [...]
>
> | My general position is that if a feature isn't used in some major, publicly
>                                                                   ^^^^^^^^
> | visible codebase, it's probably acceptable to change it.
>   ^^^^^^^

> I think your next challenge is to convince other people who care about
> C++ to adopt your general position ;-)

I think that the real question is one of cost-benefits analysis.  If we
were designing the language from scratch, I'd surely be in favor of
treating [] exactly like () (or even of not having [], and using () for
both,     la Fortran).  But we aren't.

If the benefits are large, and the amount of code affected very small,
we could consider breaking code, especially since the change would
(probably) not be silent.  And despite having seen the comma operator
once used in braces, I am fairly convinced that the amount of code
affected would be small.  On the other hand, we have an alternative
which works (using ()).  Which means that the benefits are also
extremely small.  Small enough that I can't imagine it worth breaking
*any* code, no matter how rare, and no matter how poorly written.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Carl Daniel schrieb:
> Why support one in the language and not the other?  Clearly, supporting
> multiple-argument forms of operator[] wouldn't break any existing code

is that really so?  with overloaded "operator,()" you can create
"x[a, b]" today as valid expression.  this might become
ambiguous.  apart from that this might be a way to achieve what
you want...

regards

 robert

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Esa Pulkkinen " schrieb:
> The only difference, as far as I can tell is the syntax.

well, i guess that's exactly what it's all about.  nobody would
deny that it's possible to achieve the same with some method.
however, the original poster wanted to use exactly that syntax.
:-)

regards

 robert

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

    That example seems a bit forced.

    A colleague who's into data mining of large databases
has been searching large bodies of code to see if this change would
break anything.  We'll have a report on this soon.
So far, 4 million lines of code have been searched,
and about 800 occurences of commas within square brackets
have been found.  But they all appear to be in comments.
Details of the search next week.

    So I don't think this will be a high-impact change.
This is do-able.

     John Nagle
     Animats

Carl Daniel wrote:

> <dmeyer@dmeyer.net> wrote in message news:ahn19m$u1j$1@jhereg.dmeyer.net...
>
>
>>Worse, what if i and j aren't builtin types?  It would be kind of
>>cruel to silently break existing legal code:
>>
>>include <iostream>
>>
>>struct foo
>>{
>>  int x;
>>  foo(int y=0) : x(y) {}
>>  operator int() const { return x; }
>>};
>>
>>foo operator,(const foo& f1,const foo& f2)
>>{
>>  return foo(f1.x*f2.x);
>>}
>>
>>int
>>main()
>>{
>>  foo i(3);
>>  foo j(5);
>>  int a[100];
>>  for (int i=0; i<100; ++i) { a[i]=i; }
>>  std::cout << a[i] << ","
>>            << a[j] << ","
>>            << a[i,j]
>>            << std::endl;
>>}
>>
>
> Under the change being discussed, this code would no longer compile, since a
> doesn't implement a two-argument form of operator[], so that's hardly a
> silent change.
>
> Changing the expression to a[(i,j)] would restore the old behavior.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle (nagle@animats.com) writes

JN> tab[i,j]

As far as I understand it is unlikely that overloading
operator[] with multiple parameters would be permitted
because of backward compatibility.

What about introducing some kind of
`multiple-subscripting' operator?

  template<class T>
  class Matrix
  {
  public:
    ...
    T& operator[][](int x, int y);
    ...
  };
  ...
  Matrix<float> m;
  ...
  m[1][3] = 10; // would invoke operator[][](1, 3)

--
Pavel

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <ahtk7u$vf7h0$1@ID-97366.news.dfncis.de>, "Pavel Kuznetsov"
<pavel@despammed.com> wrote:

>John Nagle (nagle@animats.com) writes
>
>JN> tab[i,j]
>
>As far as I understand it is unlikely that overloading
>operator[] with multiple parameters would be permitted
>because of backward compatibility.

This needs not be unlikely, if such occurances in already existing code is
relatively rare, and if it is easy to fix old code in the cases it does
occur. Which it is -- just replace it with tab[(i,j)], which has a very
logical look from the mathematical point of view. A regular expression
search should be able to catch most cases.

>What about introducing some kind of
>`multiple-subscripting' operator?
>
>  template<class T>
>  class Matrix
>  {
>  public:
>    ...
>    T& operator[][](int x, int y);
>    ...
>  };
>  ...
>  Matrix<float> m;
>  ...
>  m[1][3] = 10; // would invoke operator[][](1, 3)

What about classes
   class A {
   public:
     A& operator[](X x);
     A& operator[][](X x, X y);
     ...
   };
Then one will have to write
    A a; X x, y;
    (a[x])[y];
if one wants to indicate that the first operator[] should be used. Then it
would better to be able to write a[x][y] for that.

So I think one should check whether a[x, y] is common in current code; if
not, one can introduce the operator[](X_1, ..., X_n).

  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.jamesd.demon.co.uk/csc/faq.html                       ]

    That has worse compatibility problems.  A type with
both "operator[]" and "operator[][]" would be ambiguous.

    "tab[i,j]" is starting to look good, though.  So far,
nobody has been able to find existing code it would break.
We've scanned the code that comes with MSVC, and an
archive of almost all free Linux RPMs, without finding
a valid use of the comma operator inside square brackets.

    Please look through any large code bases you have,
and let me know if you can find anything this will break.
Thanks.

    John Nagle
    Animats

Pavel Kuznetsov wrote:

> John Nagle (nagle@animats.com) writes
>
> JN> tab[i,j]
>
> As far as I understand it is unlikely that overloading
> operator[] with multiple parameters would be permitted
> because of backward compatibility.
>
> What about introducing some kind of
> `multiple-subscripting' operator?
>
>   template<class T>
>   class Matrix
>   {
>   public:
>     ...
>     T& operator[][](int x, int y);
>     ...
>   };
>   ...
>   Matrix<float> m;
>   ...
>   m[1][3] = 10; // would invoke operator[][](1, 3)
>
> --
> Pavel
>
> ---
> [ 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.jamesd.demon.co.uk/csc/faq.html                       ]
>
>

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Robert Klemme wrote:

> is that really so?  with overloaded "operator,()" you can create
> "x[a, b]" today as valid expression.  this might become
> ambiguous.  apart from that this might be a way to achieve what
> you want...


     The problem is that "operator,()" only sees the subscript
types, not the array type.  Writing, say

 std::pair<int,int> operator,(int i, int j)
 { return(std::pair<int,int>(i,j)); }

to encapsulate pairs of subscripts is plausible, but isn't allowed.
At least one operator argument must be a class type.  C++
doesn't let you overload the built-in operators for built-in
types, which is probably a good decision, even though it
does preclude some ingenious constructs.

If this were allowed, it would overload ALL uses of the comma operator
on integral types, not just ones within square brackets.  That
would have higher impact than what I've proposed.

    John Nagle
    Animats



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle schrieb:
> to encapsulate pairs of subscripts is plausible, but isn't allowed.
> At least one operator argument must be a class type.  C++
> doesn't let you overload the built-in operators for built-in
> types, which is probably a good decision, even though it
> does preclude some ingenious constructs.

a possible solution could be along these lines:

class Idx {
public: Idx(const int i) : ind(i){}
        operator int() const { return ind; }
private: int ind;
}

typedef std::vector<int> MultiDimensionIndex;

MultiDimensionIndex& operator,(const Idx& lead, const int next) {
  MultiDimensionIndex result;

  result.add(lead);
  result.add(next);

  return result;
}

MultiDimensionIndex& operator,(const MultiDimensionIndex& lead,
const int next) {
  lead.add(nex);
  return lead;
}


// usage
Idx(10), 3, 4, 5

not too nice really...

> If this were allowed, it would overload ALL uses of the comma operator
> on integral types, not just ones within square brackets.  That
> would have higher impact than what I've proposed.

yep.

regards

 robert

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message
news:<3D436415.9050302@animats.com>...

>     "tab[i,j]" is starting to look good, though.

Really.

> So far, nobody has been able to find existing code it would break.

Which doesn't mean that there isn't any.

The fact that this is legal is a contract.  You can't just break it like
that.  If you want to break it, you have to prove two things: that the
amount of code which will be affected is small, that there is a great
benefit, and that there is no reasonable alternative solution which
would solve the problem.

You seem to be addressing the first point, but I don't think anyone
really doubts this -- the idiom is hardly one recommended by any
reasonable coding standards.  How great the benefit is, however, is
still an open question.  But the major point remains: you can always use
operator().  There is a reasonable alternative solution which requires
no changes in the standard.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

    Is there any good reason why "operator[]" couldn't be
permitted to take more than one argument, so that

  tab[i,j]

would be meaningful for classes that chose to support it?

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:3D3CBF8C.5000604@animats.com...
>     Is there any good reason why "operator[]" couldn't be
> permitted to take more than one argument, so that
>
> tab[i,j]
>
> would be meaningful for classes that chose to support it?
>

One reason (maybe not the most important) is that you can use:

tab[i][j]

It works for C style arrays. It should work for a multidimensional
container, designed to support indexing on multiple dimensions.

Catalin Pitis


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>     Is there any good reason why "operator[]" couldn't be
> permitted to take more than one argument, so that
>
>                 tab[i,j]
>
> would be meaningful for classes that chose to support it?
>
>                                 John Nagle
>                                 Animats

Why bother when you can use the call operator ??
tab(i,j)
is it really that different ??

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 24 Jul 2002, John Nagle wrote:

>     Is there any good reason why "operator[]" couldn't be
> permitted to take more than one argument, so that
>
>   tab[i,j]

(Unfortunately I don't have the standard handy, so someone correct me if
I am wrong).

One difficulty with this is that it is already legal C++.  The expression
i,j invokes the comma operator, which discards i and returns j.  The
language would need to be changed so that the region between [ ] is
another area where , is a separator instead of an operator.  While I doubt
that there is all that much code that depends on a comma operator in the
middle of [ ], somebody out there probably has code that depends on it.

>
> would be meaningful for classes that chose to support it?
>
>     John Nagle
>     Animats
>
> ---
> [ 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.jamesd.demon.co.uk/csc/faq.html                       ]
>
>

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:
>     Is there any good reason why "operator[]" couldn't be
> permitted to take more than one argument, so that
>
>   tab[i,j]
>
> would be meaningful for classes that chose to support it?

The comma operator is one reason. The 'i,j' in that context already
has a well-defined meaning (evaluate i, then ignore its value, then
evaluate j and return its value). And the effect you want can be
obtained with either using tab[i][j] or a method (lookup(i,j)). The
only difference, as far as I can tell is the syntax.
--
 Esa Pulkkinen

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D3CBF8C.5000604@animats.com>, John Nagle <nagle@animats.com> wrote:

>    Is there any good reason why "operator[]" couldn't be
>permitted to take more than one argument, so that
>
>                tab[i,j]
>
>would be meaningful for classes that chose to support it?

I think that BS said somewhere that the reason for not allowing it was
because it did not fit into the traditional use of subscripting.

But if you mean any syntactic reasons, I do not think there are any such
problems:

I worked on a wast generalization, where one can define ones own
multi-component operators with precedence (including "?:" "[]" etc then),
and the problem is not so much how to implement such a system, but how to
resolve ambiguities that may result if parts of code using different
syntactic conventions should be worked together.

Specifically, there is a problem with making name overloading by argument
type and operator precedence working together: If one cannot determine
operator precedence before one has determined its argument type, things
get complicated, because then one cannot determine which operator it is.
Instead one will have to search through all valid operator
precedence/argument type combinations for an expressions, and indicate an
ambiguity if there is more than one solution. (I think this can be
resolved by a Prolog type of program.)

There is also a problem if one wants to admit not a totally ordered
precedence set, but only relations indicated by a partially ordered set,
because it turns out that there is no good way to reduce such graph to
easily searchable numbers (a table would quickly f   grow too large). So
then one probably ends u searching this precedence graph using Tarjan's
SCC (strongly connected component) algorithm for each lookup, which knocks
onto some additional overhead.

But even if those somewhat problematic features are avoided, one can still
do wast operator generalizations for C++ expressions only.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

"Vincent Finn" <1@2.com.cos.agilent.com> wrote in message
news:3D3EBC5F.2F0CDBBC@2.com...
> John Nagle wrote:
>
> >     Is there any good reason why "operator[]" couldn't be
> > permitted to take more than one argument, so that
> >
> >                 tab[i,j]
> >
> > would be meaningful for classes that chose to support it?
> >
> >                                 John Nagle
> >                                 Animats
>
> Why bother when you can use the call operator ??
> tab(i,j)
> is it really that different ??

Why support one in the language and not the other?  Clearly, supporting
multiple-argument forms of operator[] wouldn't break any existing code.  I
wouldn't even speculate how much trouble it'd cause in the grammar (maybe
not much?).

I think it'd be a good addition, personally.  Especially when you consider
the interesting meta-languages, like Spirit and Phoenix (see
spirit.sourceforge.net) that have been developed in C++.  Having
multi-argument operator [] provides another dimension of extensibility.

-cd

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Esa Pulkkinen wrote:

> John Nagle <nagle@animats.com> writes:
>
>>    Is there any good reason why "operator[]" couldn't be
>>permitted to take more than one argument, so that
>>
>>  tab[i,j]
>>
>>would be meaningful for classes that chose to support it?
>>
>
> The comma operator is one reason. The 'i,j' in that context already
> has a well-defined meaning (evaluate i, then ignore its value, then
> evaluate j and return its value).


    We need a syntax expert here:

 tab(i,j)

doesn't invoke the comma operator.  Why doesn't it?
Strostrup 6.2.2 says it doesn't, but doesn't say why.
Does similar treatment for [] cause syntactical problems?

    If you need the comma operator, you can force it with
extra parentheses:

 tab((i,j))

is a one-argument call.  And if [] is interpreted as allowing
multiple arguments, old code that uses the comma operator
within brackets (if any exists) will just produce an undefined
function call error under the new rule.  So it won't break
existing code.  (Might turn up some errors in existing code;
not everybody knows that "tab[i,j]" silently ignores the "j").

    John Nagle
    Animats


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Carl Daniel wrote:

>>John Nagle wrote:

>>>    Is there any good reason why "operator[]" couldn't be
>>>permitted to take more than one argument, so that
>>>                tab[i,j]
>>>would be meaningful for classes that chose to support it?

> I think it'd be a good addition, personally.  Especially when you consider
> the interesting meta-languages, like Spirit and Phoenix (see
> spirit.sourceforge.net) that have been developed in C++.  Having
> multi-argument operator [] provides another dimension of extensibility.


    That's a nice bit of support.

    My main argument for it is that the current approach yields
code like

  tab.at(i,j) = x;

which is a clunky way to weite an assignment.

     The array-of-arrays model is really a bit of C legacy.
Many data structures don't map into that model.  The underlying
data structure may be a tree, a hash, or even a database.

     John Nagle
     Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message news:<3D3CBF8C.5000604@animats.com>...
> Is there any good reason why "operator[]" couldn't be
> permitted to take more than one argument, so that
>
>   tab[i,j]
>
> would be meaningful for classes that chose to support it?
>
>     John Nagle
>     Animats
>

In addition to the other solutions offered, one argument is not
necessarily the same thing as one value.  You could always use
something like, for example,

    tab[std::pair(i, j)]

Randy.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in news:3D3EF4FE.2020703@animats.com:

> Esa Pulkkinen wrote:
>
>> John Nagle <nagle@animats.com> writes:
>>
>>>    Is there any good reason why "operator[]" couldn't be
>>>permitted to take more than one argument, so that
>>>
>>>          tab[i,j]
>>>
>>>would be meaningful for classes that chose to support it?
>>>
>>
>> The comma operator is one reason. The 'i,j' in that context already
>> has a well-defined meaning (evaluate i, then ignore its value, then
>> evaluate j and return its value).
>
>
>     We need a syntax expert here:
>
>      tab(i,j)
>
> doesn't invoke the comma operator.  Why doesn't it?

Because it doesn't in C. operator(), the function call operator, uses
the normal C call syntax where , separates arguments. In operator[], it
doesn't because there is no equivalent C form to mimick. C's "operator[]"
is purely binary.

>     If you need the comma operator, you can force it with
> extra parentheses:
>
>      tab((i,j))
>
> is a one-argument call.  And if [] is interpreted as allowing
> multiple arguments, old code that uses the comma operator
> within brackets (if any exists) will just produce an undefined
> function call error under the new rule.

No, it won't if operator[] is overloaded for 1 and 2 arguments.
tab[i,j] called operator[](int) and now will call
operator[](int,int). True, tab[(i,j)] is the trivial workaround
which could probably be applied mechanically. If a , is found
between [] without a pair of ( ) or < > surrounding the , add
the ( ) adjacent to the [ ].

I still fail to see the benefits over [i][j]. The argument that e.g.
Spirit may benefit from it applies to operator::= as well. I happen to
agree with the argument that we can't name just any non-alphanumeric
character sequence an operator.

Regards,
--
Michiel Salters

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

According to Esa Pulkkinen <esa.pulkkinen> <esa.pulkkinen>:
>
> John Nagle <nagle@animats.com> writes:
> >     Is there any good reason why "operator[]" couldn't be
> > permitted to take more than one argument, so that
> >
> >   tab[i,j]
> >
> > would be meaningful for classes that chose to support it?
>
> The comma operator is one reason. The 'i,j' in that context already
> has a well-defined meaning (evaluate i, then ignore its value, then
> evaluate j and return its value). And the effect you want can be
> obtained with either using tab[i][j] or a method (lookup(i,j)). The
> only difference, as far as I can tell is the syntax.

Worse, what if i and j aren't builtin types?  It would be kind of
cruel to silently break existing legal code:

include <iostream>

struct foo
{
  int x;
  foo(int y=0) : x(y) {}
  operator int() const { return x; }
};

foo operator,(const foo& f1,const foo& f2)
{
  return foo(f1.x*f2.x);
}

int
main()
{
  foo i(3);
  foo j(5);
  int a[100];
  for (int i=0; i<100; ++i) { a[i]=i; }
  std::cout << a[i] << ","
            << a[j] << ","
            << a[i,j]
            << std::endl;
}

--
Dave Meyer
dmeyer@dmeyer.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel Salters wrote:


> I still fail to see the benefits over [i][j].


    The problem is that there are multidimensional
subscripted objects for which returning an entire row
is either expensive or not meaningful.  If you
write "tab[i][j]", somehow "tab" has to be able
to return "tab[i]".  If the underlying representation
is a tree, hash, database, or sparse array, that's hard.

    The array-of-arrays concept doesn't generalize.
It exposes the underlying representation.  That
made sense for C, but not C++.

    John Nagle
    Animats





---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>
>     Is there any good reason why "operator[]" couldn't be
> permitted to take more than one argument, so that
>
>                 tab[i,j]
>
> would be meaningful for classes that chose to support it?

That would cause context-depending parsing difficulties. How you parsed
'tab[i,j]' (as a two dimensional indexing call, or as a one dimensional
call and the use of the comma operator) would depend on the type of the
variable 'tab'.

The C++ grammar has places where parsing is dependant on whether an
identifier names a type or not, but I don't believe there are any cases
where parsing depends on which particular type an identifier names.

--
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 24 Jul 2002 18:10:03 GMT, Carl Daniel <cpdaniel@pacbell.net> wrote:
>  "Vincent Finn" <1@2.com.cos.agilent.com> wrote in message
>  news:3D3EBC5F.2F0CDBBC@2.com...
> > John Nagle wrote:
> >
> > >     Is there any good reason why "operator[]" couldn't be
> > > permitted to take more than one argument, so that
> > >
> > >                 tab[i,j]
> > >
> > > would be meaningful for classes that chose to support it?
> > >
> > >                                 John Nagle
> > >                                 Animats
> >
> > Why bother when you can use the call operator ??
> > tab(i,j)
> > is it really that different ??
>
>  Why support one in the language and not the other?  Clearly, supporting
>  multiple-argument forms of operator[] wouldn't break any existing code.

That's not completely accurate. The above syntax is already valid today,
only that the "," is interpreted as the comma operator, and not as an
argument list seperator. If you are going to disallow the former
interpretation, then this can break existing code.

-- Niklas Matthies
--
Drive carefully; 90% of the people in the world are caused by accidents.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

     You could, but are compilers smart enough to optimize
that down?  This is a construct likely to appear in
number-crunching inner loops.

     John Nagle
     Animats


> In addition to the other solutions offered, one argument is not
> necessarily the same thing as one value.  You could always use
> something like, for example,
>
>     tab[std::pair(i, j)]
>

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:3D3F1252.3090706@animats.com...
> Michiel Salters wrote:
>
>
> > I still fail to see the benefits over [i][j].
>
>
>     The problem is that there are multidimensional
> subscripted objects for which returning an entire row
> is either expensive or not meaningful.  If you
> write "tab[i][j]", somehow "tab" has to be able
> to return "tab[i]".  If the underlying representation
> is a tree, hash, database, or sparse array, that's hard.

Why is it hard?  All it has to do is return a proxy object which stores the
first index.  All of the work of indexing into the object can be postponed
until the call of operator[] in the proxy object.  You can implement the
work directly in the operator[] or just call a member function of the tab
object.  This can all be inlined so that there is no more overhead than a
call to something like tab.at(i,j).

>     The array-of-arrays concept doesn't generalize.
> It exposes the underlying representation.  That
> made sense for C, but not C++.

I don't understand.  How does it expose the underlying implementation?

class foo {
  class proxy {
    int i;
    foo *p;
  public:
    proxy(foo *p_, int i_) : p(p_), i(i_) {}
    int& operator[](int j) { return p->at(i,j); }
    const int& operator[](int j) const {
      return (const_cast<const foo*>(p))->at(i,j);
    }
  };
  friend class proxy;

  int& at(int i, int j) {...}
  const int& at(int i, int j) const {...}

public:
  proxy operator[](int i) { return proxy(this,i); }
  const proxy operator[](int i) const { return
proxy(const_cast<foo*>(this),i); }
};

Am I missing something?



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> writes:

[...]

| Clearly, supporting
| multiple-argument forms of operator[] wouldn't break any existing code.

I think such a strong statement should be supported by a demonstration.

This issue was debated to death in the past with apparently no
definitive conclusion.

As to whether it wouldn't break any existing code, I will just point
out that compound-expressions are supported by the language, so some
care must be exercised in that area.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 24 Jul 2002 dmeyer@dmeyer.net wrote:

> According to Esa Pulkkinen <esa.pulkkinen> <esa.pulkkinen>:
> >
> > John Nagle <nagle@animats.com> writes:
> > >     Is there any good reason why "operator[]" couldn't be
> > > permitted to take more than one argument, so that
> > >
> > >   tab[i,j]
> > >
> > > would be meaningful for classes that chose to support it?
> >
> > The comma operator is one reason. The 'i,j' in that context already
> > has a well-defined meaning (evaluate i, then ignore its value, then
> > evaluate j and return its value). And the effect you want can be
> > obtained with either using tab[i][j] or a method (lookup(i,j)). The
> > only difference, as far as I can tell is the syntax.
>
> Worse, what if i and j aren't builtin types?  It would be kind of
> cruel to silently break existing legal code:
>

<example showing overloaded operator , snipped>

As a matter of fact, if you are willing to overload operator ,(), you can
even do something like this

struct my_twod_array {
   struct twod_access_proxy {
      int i_, j_;
   };
   value_type operator[](const twod_access_proxy & proxy) {
     return at(proxy.i_, proxy,j_);
   }
   //...many details omitted
};

struct idx {
  int val_;
  idx(int val) : val_(val) {}

  my_twod_array::twod_access_proxy operator,(idx j) {
     my_twod_array::twod_access_proxy proxy;
     proxy.i_ = val_;
     proxy.j_ = j.val_;
     return proxy;
  }

};

int main() {
   my_twod_array mine;
   idx i = 4, j=5;
   mine[i,j];
}

What you give up is that your array indexes can no longer be integers,
since at least one operand to an overload of operator,() must be of class
or enumeration type.

It would work great if you were using strings as your array indexes,
though.

Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

| Esa Pulkkinen wrote:
|
| > John Nagle <nagle@animats.com> writes:
| >
| >>    Is there any good reason why "operator[]" couldn't be
| >>permitted to take more than one argument, so that
| >>
| >>  tab[i,j]
| >>
| >>would be meaningful for classes that chose to support it?
| >>
| >
| > The comma operator is one reason. The 'i,j' in that context already
| > has a well-defined meaning (evaluate i, then ignore its value, then
| > evaluate j and return its value).
|
|
|     We need a syntax expert here:
|
|  tab(i,j)
|
| doesn't invoke the comma operator.

Shall it?

[...]

| Does similar treatment for [] cause syntactical problems?

Yes:  C++ is an evolutive language which means, there are legacy codes
(both C and C++) one has to be aware of.

|     If you need the comma operator, you can force it with
| extra parentheses:
|
|  tab((i,j))
|
| is a one-argument call.  And if [] is interpreted as allowing
| multiple arguments, old code that uses the comma operator
| within brackets (if any exists) will just produce an undefined
| function call error under the new rule.  So it won't break
| existing code.

If it used to compile and work and no longer compiles nor works, then
it is broken.  Period.

| (Might turn up some errors in existing code;
| not everybody knows that "tab[i,j]" silently ignores the "j").

Wrong.  It evaluates "i", then "j" and the value of the expression
"i,j" is that of "j".  Nothing is silently ignored.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

|      You could, but are compilers smart enough to optimize
| that down?

When written appropritely, yes, compilers can dramatically reduce the
abstraction penalty nearly to zero.  Optimizers are getting smarter
these days.

| This is a construct likely to appear in
| number-crunching inner loops.

Funny.  The number crunching codes I'm familiar with are written by
numerical folks with strong Fortran background and they use the
function call operator.  Actually, I think professional numerical
folks know how to write multidimensional subscription :-)

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel Salters <Michiel.Salters@cmg.nl> wrote in message news:<Xns9255DF489F93Amsalterscistron@62.216.30.38>...
> John Nagle <nagle@animats.com> wrote in news:3D3EF4FE.2020703@animats.com:
>
> > Esa Pulkkinen wrote:
> >
> >> John Nagle <nagle@animats.com> writes:
> >>
> I still fail to see the benefits over [i][j]. The argument that e.g.
> Spirit may benefit from it applies to operator::= as well. I happen to
> agree with the argument that we can't name just any non-alphanumeric
> character sequence an operator.
>

The benefit over tab[i][j] is that this is two calls rather than one,
i.e., tab[i] returns an object to which [j] is applied.

Randy.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<DBz%8.16965$qh3.67512589@newssvr13.news.prodigy.com>...
>
> "Vincent Finn" <1@2.com.cos.agilent.com> wrote in message
> news:3D3EBC5F.2F0CDBBC@2.com...
> > John Nagle wrote:
> >
> > >     Is there any good reason why "operator[]" couldn't be
> > > permitted to take more than one argument, so that
> > >
> > >                 tab[i,j]
> > >
> > > would be meaningful for classes that chose to support it?
> > >
> > >                                 John Nagle
> > >                                 Animats
> >
> > Why bother when you can use the call operator ??
> > tab(i,j)
> > is it really that different ??
>
> Why support one in the language and not the other?  Clearly, supporting
> multiple-argument forms of operator[] wouldn't break any existing code.  I
> wouldn't even speculate how much trouble it'd cause in the grammar (maybe
> not much?).

It would be a fairly signficant change to have ',' recognised as an
argument seperator rather than as a comma operator in that context.
Currently, operator overloads have no affect on how an expression is
parsed, only on how it's evaluated.

Supporting this form wouldn't break any existing code. However, actually
using this form could break some existing code. Consider a template which
contains code assumes that a ',' inside a subscript will be evaluated as
a comma operator. If you instantiate that template for a type with a
two-argument operator[], then the instantiation could break.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Aaagh! I started using a different news server on May 12th. As far as
I can tell, none of my messages have propagated outside my own news
server since then. My new news server's sysadmin doesn't understand
how to set up moderated newsgroups. I guess I'm going to have to start
using Google to post my messages. I'm going to re-post a few of my
most recent messages. I apologize to those few people who actually are
on the same newsserver with me, who are going to end up seeing double
posts.

John Nagle <nagle@animats.com> wrote in message news:<3D3CBF8C.5000604@animats.com>...
> Is there any good reason why "operator[]" couldn't be
> permitted to take more than one argument, so that
>
>   tab[i,j]
>
> would be meaningful for classes that chose to support it?

Yes, because operator overloads are never supposed to change how the
code is parsed, only how the parse tree is evaluated. As it stands,
tab[i,j] is parsed as tab[(i,j)]; that is, (i,j) is parsed as a comma
expression, the value of which is used as the right operand of a
subscript expression. The comma is parsed as an argument seperator
(rather than as a comma operator) only in function call expressions.
Expressions that result in operator overload functions being called
are
not generally, in themselves, function call expressions (except when
it's the fucntion call operator which is being overloaded).

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:8b42afac.0207250527.654abf74@posting.google.com...
> John Nagle <nagle@animats.com> wrote in message
news:<3D3CBF8C.5000604@animats.com>...
> > Is there any good reason why "operator[]" couldn't be
> > permitted to take more than one argument, so that
> >
> > tab[i,j]
> >
> > would be meaningful for classes that chose to support it?
>
> Yes, because operator overloads are never supposed to change how the
> code is parsed, only how the parse tree is evaluated. As it stands,
> tab[i,j] is parsed as tab[(i,j)]; that is, (i,j) is parsed as a comma
> expression, the value of which is used as the right operand of a
> subscript expression. The comma is parsed as an argument seperator
> (rather than as a comma operator) only in function call expressions.
> Expressions that result in operator overload functions being called
> are
> not generally, in themselves, function call expressions (except when
> it's the fucntion call operator which is being overloaded).

My thinking in agreeing with John's proposal was to change the grammar so
that , inside [] is parsed as an argument separator, not the comma operator.
This _would_ cause code which uses the (IMO _highly_ questionable) form
a[i,j] to cease to compile, requiring that it be re-written as a[(i,j)].

IMO, a language chage which causes an obscure and (probably) very little
used construct to become invalid, with a simple work-around, is an
acceptable change in terms of it's impact on the existing body of code.

I agree 1000% with your analysis that if , only represents an argument
separator when used in operator[] of a class which supports a multi-argument
overload, that the result would be a parsing disaster.

-cd


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Gabriel Dos Reis wrote:

> Funny.  The number crunching codes I'm familiar with are written by
> numerical folks with strong Fortran background and they use the
> function call operator.  Actually, I think professional numerical
> folks know how to write multidimensional subscription :-)


     Take a look at how Numerical Recipes in C does multidimensional
arrays.  That's painful.

     John Nagle
     Animats


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Carl Daniel wrote:

> My thinking in agreeing with John's proposal was to change the grammar so
> that , inside [] is parsed as an argument separator, not the comma operator.
> This _would_ cause code which uses the (IMO _highly_ questionable) form
> a[i,j] to cease to compile, requiring that it be re-written as a[(i,j)].


     Agreed,

     The syntax change required is in A.5, Expressions, in
"postfix-expression:"  Currently, the syntax for square bracketed
expressions reads

 postfix-expression [ expression ]

I propose changing it to

 postfix-expression [ expression-list_opt ]

so that it uses the same syntax as function call arguments.


> IMO, a language chage which causes an obscure and (probably) very little
> used construct to become invalid, with a simple work-around, is an
> acceptable change in terms of it's impact on the existing body of code.


     I've been searching source code for instances of bracketed
expressions which
contain a comma operator.  I've found one so far, in an old Microsoft
macro, which I posted in a separate message.  Can anyone else find any?
My general position is that if a feature isn't used in some major, publicly
visible codebase, it's probably acceptable to change it.

     So if you think this change would break existing code, find some
existing code it will break.


     John Nagle

     Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> wrote in message
news:<DBz%8.16965$qh3.67512589@newssvr13.news.prodigy.com>...
> "Vincent Finn" <1@2.com.cos.agilent.com> wrote in message
> news:3D3EBC5F.2F0CDBBC@2.com...
> > John Nagle wrote:

> > >     Is there any good reason why "operator[]" couldn't be
> > > permitted to take more than one argument, so that

> > >                 tab[i,j]

> > > would be meaningful for classes that chose to support it?

> > Why bother when you can use the call operator ??
> > tab(i,j)
> > is it really that different ??

> Why support one in the language and not the other?  Clearly,
> supporting multiple-argument forms of operator[] wouldn't break any
> existing code.

Clearly allowing multiple arguments for operator[] generally will break
some code.  How much I don't know, but I have definitly seen code that
it would break.

If it were to be allowed, it could only be allowed for cases where the
operator[] involved was a user defined operator, and a version with
multiple parameters was declared.

> I wouldn't even speculate how much trouble it'd cause in the grammar
> (maybe not much?).

Well, it would mean that the choice of whether the comma was a parameter
separator or an operator would depend on the results of function
overload resolution (and that both cases would have to be considered
during function overload resolution).

In the end, I like the explination of Barton and Nackman.  In C++,
operator[] is the projection operator -- it returns a projection in one
less dimension.  The indexing operator is (), the same as in Fortran:-).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message
news:<3D3EF6A2.70505@animats.com>...
> Carl Daniel wrote:

> >>John Nagle wrote:

> >>>    Is there any good reason why "operator[]" couldn't be
> >>>permitted to take more than one argument, so that
> >>>                tab[i,j]
> >>>would be meaningful for classes that chose to support it?

> > I think it'd be a good addition, personally.  Especially when you
> > consider the interesting meta-languages, like Spirit and Phoenix
> > (see spirit.sourceforge.net) that have been developed in C++.
> > Having multi-argument operator [] provides another dimension of
> > extensibility.

>     That's a nice bit of support.

>     My main argument for it is that the current approach yields
> code like

>   tab.at(i,j) = x;

> which is a clunky way to weite an assignment.

The current approch yields code like:

    tab(i,j) = x ;

which isn't that bad.  And it isn't too difficult to define the
operators so that you can write:

    tab[i][j] = x ;

>      The array-of-arrays model is really a bit of C legacy.  Many data
> structures don't map into that model.  The underlying data structure
> may be a tree, a hash, or even a database.

So.  There is nothing in tab[i][j] in itself which implies an array of
arrays.  The expression tab[i] returns a project of tab, with one less
dimension.  Formally, that projection can be any subset of tab.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote in message
news:<3D3EF4FE.2020703@animats.com>...
> Esa Pulkkinen wrote:

> > John Nagle <nagle@animats.com> writes:

> >>    Is there any good reason why "operator[]" couldn't be permitted
> >>to take more than one argument, so that

> >>  tab[i,j]

> >>would be meaningful for classes that chose to support it?

> > The comma operator is one reason. The 'i,j' in that context already
> > has a well-defined meaning (evaluate i, then ignore its value, then
> > evaluate j and return its value).

>     We need a syntax expert here:

>  tab(i,j)

> doesn't invoke the comma operator.  Why doesn't it?

Because the standard says it doesn't.

Basically, if the comma can be interpreted as punctuation, it is.  It is
only the comma operator when it cannot be anything else.

> Strostrup 6.2.2 says it doesn't, but doesn't say why.  Does similar
> treatment for [] cause syntactical problems?

Not really.  If the syntax said that you could put a list in the [],
outer level commas would be punctuation and not operators.

The problem is history, and the way [] works.  If we were designing a
language from scratch, there are a lot of things we could do.  (Create a
declaration syntax without ambiguities, for example:-).)  Probably, the
equivalence between a[b] and *(a+b) would not be part of the new
language.  And why not: we could also allow multiple indexes.

But C++ wasn't designed from scratch: compatibility with C was an
important criteria.  (And C wasn't designed from scratch -- B was
extended as was thought necessary.)

That's life.  C compatibility has its costs.  It is probably also one of
the reasons, if not THE reason, that C++ is so popular.

Today, of course, we have the constraint of compatibility with the
current version of C++; a constraint probably even more important than
compatibility with C at present.

>     If you need the comma operator, you can force it with
> extra parentheses:

>  tab((i,j))

> is a one-argument call.  And if [] is interpreted as allowing multiple
> arguments, old code that uses the comma operator within brackets (if
> any exists) will just produce an undefined function call error under
> the new rule.  So it won't break existing code.

The code compiled and worked.  Now it doesn't.  That's what I call
breaking code.

>  (Might turn up some errors in existing code; not everybody knows that
> "tab[i,j]" silently ignores the "j").

No, but most old C programmers do know that it ignores the results of i
(but not the side effects).  The current trend is to use hairy templates
to make code unreadable, but back when we didn't have hairy templates,
fancy tricks with the comma operator were not uncommon.  You gotta do
something to show off your knowledge of the language (and there just
aren't that many subtleties in C to do it with).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

[...]

| My general position is that if a feature isn't used in some major, publicly
                                                                     ^^^^^^^^
| visible codebase, it's probably acceptable to change it.
  ^^^^^^^

I think your next challenge is to convince other people who care about
C++ to adopt your general position ;-)

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3D403523.6070109@animats.com>, John Nagle <nagle@animats.com> wrote:
>     I've been searching source code for instances of bracketed
>expressions which
>contain a comma operator.  I've found one so far, in an old Microsoft
>macro, which I posted in a separate message.  Can anyone else find any?
>My general position is that if a feature isn't used in some major, publicly
>visible codebase, it's probably acceptable to change it.
>
>     So if you think this change would break existing code, find some
>existing code it will break.

One way to ensure backwards compatibility might be to decide that
    A a; X x; Y y;
    a[x, y];
parses as a.A::operator[](X, Y) if that has been defined, but otherwise it
parses as a[(x, y)], i.e., a.A::operator[]((X, Y)).

But the mixture is rather un-intuitive. So if not much code is broken, I
think it is better to require that old a[x, y] occurrences must be
rewritten as a[(x, y)]. -- As John Nagle points out, it is fairly easy to
search old code for all occurrences of [x, y], and replace it at need with
[(x, y)].

Then one can freely allow A::operator[](X_1, ..., X_n) to be defined.

As for the ",", the reason for adding it seems to be that then can write
  for (x = 1, y = 1; ...) ...
But are there any other reasons for admitting it? -- After all, it is
quite confusing that in C/C++ (x, y) does not mean a vector of two
components.

And if one should have an "operator," why not an "operator;"? -- After
all, it is quite common to write matrices as [a, b; c, d], etc.

  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.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:

 > The current approch yields code like:
>
>     tab(i,j) = x ;
>
> which isn't that bad.


     If "stl::vector" overloaded "operator()" and used it
for subscripting, that might be a plausible position.  But the
STL doesn't do subscripting that way.

     If you see code that does subscripting that way,
it's probably because it couldn't be done
with square brackets.

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:

(defense of not breaking comma operator within brackets).

But James Kanze also wrote, in 1994, in response to some
code that used the comma operator:

> RESPONSE: kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425), 12 Sept 94
>
> If done correctly, yes.  I did it once to try it out, but have
> abandonned it (at least in this context) as being to exoteric, and
> resulting in code that is too difficult for a reader to understand.


(Cite: http://cpptips.hyperformix.com/cpptips/operator,)

    John Nagle
    Animats



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

|      If you see code that does subscripting that way,
| it's probably because it couldn't be done
| with square brackets.

Or, the people who wrote are used to that form.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

| Michiel Salters wrote:
|
|
| > I still fail to see the benefits over [i][j].
|
|
|     The problem is that there are multidimensional
| subscripted objects for which returning an entire row
| is either expensive or not meaningful.

Is there any need to return an *entire* row?

| If you
| write "tab[i][j]", somehow "tab" has to be able
| to return "tab[i]".

Or it may just return a proxy, not the real row.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]