Mon, 14 May 2001 14:18:45 GMT, Al Grant <tnarga@arm.REVERSE-NAME.com> pis=
ze:

> Adding local functions with access to outer function scope
> to C++ would not be trivial.  There are runtime environment
> issues, it's not just a compiler change.

And this is precisely why they are useful. Function closures are not
just syntax for writing function definitions inside other functions,
but a way to express arbitrary computations as objects.

C++ doesn't support this programming style at all. Its function objects
are clumsy, hard to write, with types mirroring the implementation
and not just the interface, and thus inability to use differently
implemented function objects interchangeably (unless I derive them from
a common class with a virtual function, which is yet more painful),
without genericity wrt. the number of parameters and with inefficient
copying by value.

It will never work well without garbage collection. A function closure
referring to an object must keep it alive, and in general it's not
statically known when the object is not referred to anymore.

Unfortunately C++ is so complex and widespread that I have no hope
that this language would be ever improved (except minor tweaks).

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

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

In article <slrn.pl.9gcg21.ubd.qrczak@qrnik.zagroda>, "Marcin 'Qrczak'
Kowalczyk" <qrczak@knm.org.pl> wrote:
>> Adding local functions with access to outer function scope
>> to C++ would not be trivial.  There are runtime environment
>> issues, it's not just a compiler change.
>
>And this is precisely why they are useful. Function closures are not
>just syntax for writing function definitions inside other functions,
>but a way to express arbitrary computations as objects.
>
>C++ doesn't support this programming style at all.
...
>It will never work well without garbage collection. A function closure
>referring to an object must keep it alive, and in general it's not
>statically known when the object is not referred to anymore.

I looks as though the hooks for writing a conservative GC will be added to C++.

As for the function closures, one must first come up with a good way to
implement that people can agree on. I figure computer science has not
moved that far on this question for it to mature enough that it can be
added to C++.

But if C++ is changed so it is possible to implement a conservative GC in
an effective manner, then that gives room for starting to implement
function closures.

Besides, it is not all that difficult to implement a function closure in
C++: I use a class "object" that maintains a polymorphic to a class
hierarchy, derivations of a class "object_root". If these classes has an
evaluator, then that results in a function cover.

The problem is that there are several different ways to implement this:
One may make use of unboxed and boxed elements. In the picture above, the
unboxed elements would not be pointers, but (if not using a handle) a
member of the class "object" that is copied. If the object should be able
to mutate, or allow for memory moving, then the class "object" must point
to a handle class which maintains the polymorphic pointer to the
"object_root" class.

So I have used several variations of this, depending on the application.

But with a GC in hand, it seems me possible to add some library classes
that makes it easy to add such polymorphy.

If it should happen at already the next standard, then I would first want
to have a C++ compiler with a GC library, and then sit down and experiment
with it, order to see what polymorphy classes are possible.

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

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

In article <9djo56$j11$1@news.vol.cz>, Mirek Fidler says...

[ OP is probably Heinz Huber ]

>>> SQL * Select(SOMECOLUMN).From(SOMETABLE).Where(KEY >= low && KEY <= high);

>> In order to stay more within SQL, you could change that to:
>> (KEY >= low).And(KEY <= high)
>> In SQL && has no meaning AFAIK.

>> Or if defining new operators makes it into the language, you could also
>> define an operator AND.
>
> Why ? && is well readable, and even people that never heard anything
> about our library (like you) code can understand what above example means.
>
>Mirek

If you really want to spell it out, you can already write
...Where (KEY >= low and KEY <=high)

because the standard says that "and" is another spelling for &&.
You can define operator and, and use && or vice versa.
(2.5 ALternative tokens).

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

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

Mirek Fidler wrote:
>
> > && bar(y)" no longer short-circuits, resulting in much confusion.  I'd
> like
> > to take Scott Meyer's advice on never overloading &&/||/, and push it into
> > the language itself, and prohibit overloading them.
>
>     I would hate you for that. We use operator overloading to construct SQL
> statements - something that seems little bit nasty first, but is VERY
> comfortable in fact. You would cancel our ability to write
>
> SQL * Select(SOMECOLUMN).From(SOMETABLE).Where(KEY >= low && KEY <= high);
>
>     Please do not suggest further restrictions on language. C++ is not
> language for begginer programmers, it is language to get things done.

In order to stay more within SQL, you could change that to:
(KEY >= low).And(KEY <= high)

In SQL && has no meaning AFAIK.


Or if defining new operators makes it into the language, you could also define
an operator AND.

Regards,
Heinz

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

Al Grant wrote:
>
> "Christopher Eltschka" <celtschk@dollywood.itp.tuwien.ac.at> wrote in
> message news:3AF9AEC6.7020B797@dollywood.itp.tuwien.ac.at...
> > Al Grant wrote:
> > > Because the closure value may reference the caller's
> > > environment this effectively forces the called functions
> > > to be inline.
> >
> > Why? In Pascal, nested functions can use the environment of
> > their surrounding function
>
> Yes, but that adds complexity to the implementation.
> By making it a requirement that functions are inlined
> you make this just a source transformation - somewhere
> in between macros and inline functions.  In fact it's
> really a macro but with forced CSE on those arguments
> which are duplicated but not designated as closures.

Adding complexity to the implementation should IMHO not
be a major point in reasoning about a feature, unless the
needed techniques aren't yet well established. One cannot
say that about local function implementations.

Also think of the size impact on code due to forced inlining.
You don't want a feature that no one uses because it does
code bloat.

And finally, the compiler should not demand inlining at all.
It should only describe the _semantics_, not the implementation.

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

> > > && bar(y)" no longer short-circuits, resulting in much confusion.  I'd
> > like
> > > to take Scott Meyer's advice on never overloading &&/||/, and push it
into
> > > the language itself, and prohibit overloading them.
> >
> >     I would hate you for that. We use operator overloading to construct
SQL
> > statements - something that seems little bit nasty first, but is VERY
> > comfortable in fact. You would cancel our ability to write
> >
> > SQL * Select(SOMECOLUMN).From(SOMETABLE).Where(KEY >= low && KEY <=
high);
> >
> >     Please do not suggest further restrictions on language. C++ is not
> > language for begginer programmers, it is language to get things done.
>
> In order to stay more within SQL, you could change that to:
> (KEY >= low).And(KEY <= high)
>
> In SQL && has no meaning AFAIK.

    Does it matter ? Your suggestion would just add some unneeded
parenthesis, and further it would remove operator precedence.

> Or if defining new operators makes it into the language, you could also
define
> an operator AND.

    Why ? && is well readable, and even people that never heard anything
about our library (like you) code can understand what above example means.

Mirek



======================================= MODERATOR'S COMMENT:
 This appears to be drifting away from discussion of
the C++ Standard; please do ensure that any follow-ups do
not drift any further.

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

Phil Edwards <pedwards@dmapub.dma.org> wrote...
>
> I feel that overloading &&/||/, is questionable practice; others like
> [Mirek Fidler] feel that it's useful.  Removing that practice would
> certainly /not/ turn C++ into a beginner's language.

I suggested this a month or two back. Someone replied to the effect
that you can write expression templates which overload &&/||, and that
these can be written to preserve the short-circuit. I think the facility
is one of those features that is dangerous in hands of a novice and
invaluable in the hands of an expert.

Aside: A lot of the things that people want to ban, or change, should
show up as compiler warnings, or in LINT. With the paranoia turned
right up, C++ is quite safe. It's certainly safer than C, and has very
few features that could trip up a novice which the compiler couldn't
warn about.


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

"Christopher Eltschka" <celtschk@dollywood.itp.tuwien.ac.at> wrote in
message news:3AFBD9B5.9E3B1B56@dollywood.itp.tuwien.ac.at...
> Al Grant wrote:
> > Yes, but that adds complexity to the implementation.
>
> Adding complexity to the implementation should IMHO not
> be a major point in reasoning about a feature, unless the
> needed techniques aren't yet well established. One cannot
> say that about local function implementations.

The techniques are well established and the overheads are
known, and they were known in 1970, which was why BCPL
had the "no access to outer function scope" rule for
local functions and why C had no local functions at all.
Adding local functions with access to outer function scope
to C++ would not be trivial.  There are runtime environment
issues, it's not just a compiler change.

> Also think of the size impact on code due to forced inlining.
> You don't want a feature that no one uses because it does
> code bloat.

But the bloat is predictable.  It's no worse than macros.
Programmers object far more to hidden bloat, e.g. from
exception handling, unwanted initialisations etc.

> And finally, the compiler should not demand inlining at all.
> It should only describe the _semantics_, not the implementation.

Agreed.  Compilers are free to factor code into functions
even when the programmer explicitly writes it inline.
My point is that functions which use these features should
have the semantics of inline functions (easiest way is
just to require that the programmer mark them inline).
That way, there is no obligation to invent a mechanism for
referring to outer scopes of local functions.



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

Al Grant wrote:
>
> "Phil Edwards" <pedwards@dmapub.dma.org> wrote in message
> news:200105081905.PAA11977@dmapub.dma.org...
> > The idea of adding arbitrary operators has been brought up since operator
> > overloading was introduced.  The problem is that you also have to describe
> > (in your program) the order of evaluation and precedence
>
> Defining precedence is not a problem, Algol 68 did it.
>
> Order of evaluation is not a problem specific to operators.
> What is needed is an efficient way to create closures.
> So for example:
>
>   int andif(int a, closure<int> b)
>   {
>     if (a)
>       return b();
>     else
>       return 0;
>   }
>
>   template<class T> T ifsquare(int n, closure<T> a)
>   {
>     if (n != 0)
>     {
>       T temp = a();
>       return temp * temp;
>     }
>   }
>
> Because the closure value may reference the caller's
> environment this effectively forces the called functions
> to be inline.

Why? In Pascal, nested functions can use the environment of
their surrounding function, yet can be passed as arguments
to other functions.
A closure which _only_ can be passed as parameter (and not
be stored in a function pointer or returned from a function)
could safely be implemented as anonymous nested function
in the calling scope.

[...]

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

"Christopher Eltschka" <celtschk@dollywood.itp.tuwien.ac.at> wrote in
message news:3AF9AEC6.7020B797@dollywood.itp.tuwien.ac.at...
> Al Grant wrote:
> > Because the closure value may reference the caller's
> > environment this effectively forces the called functions
> > to be inline.
>
> Why? In Pascal, nested functions can use the environment of
> their surrounding function

Yes, but that adds complexity to the implementation.
By making it a requirement that functions are inlined
you make this just a source transformation - somewhere
in between macros and inline functions.  In fact it's
really a macro but with forced CSE on those arguments
which are duplicated but not designated as closures.





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

Hi,

Radoslav Getov wrote:
> double operator x (vector a, vector b)
> {
>     return a.x * b.x + a.y * b.y;
> }
>
> vector a, b;
>
> double c = a * b,
>            d = a x b;
>
> looks nice, doesn't it?

I hope, your font prints '*' as '*'. Sometimes '*' might look more like
'x'.


Best regards
Olaf Krzikalla

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

In article <9dasrm$2ad$3@news.vol.cz> you write:
> > && bar(y)" no longer short-circuits, resulting in much confusion.  I'd
> like
> > to take Scott Meyer's advice on never overloading &&/||/, and push it into
> > the language itself, and prohibit overloading them.
>
>     I would hate you for that. We use operator overloading to construct SQL
> statements - something that seems little bit nasty first, but is VERY
> comfortable in fact. You would cancel our ability to write
>
> SQL * Select(SOMECOLUMN).From(SOMETABLE).Where(KEY >= low && KEY <= high);

Interesting.  This definitely forms an argument in the debate over
readability of statements containing overloaded operators, but I don't
know whether it's for or against.  :-)  It makes sense to me because I
understand some SQL...


>     Please do not suggest further restrictions on language. C++ is not
> language for begginer programmers, it is language to get things done.

I will continue to suggest whatever tweaks I feel would make a better C++.
One of C++'s improvements over C (in my opinion) was prohibiting things which
some felt were questionable and others felt were useful, like implicit int.
Those restrictions don't mean that C++ became a "beginner's language"
compared to C.

I feel that overloading &&/||/, is questionable practice; others like
yourself feel that it's useful.  Removing that practice would certainly
/not/ turn C++ into a beginner's language.


Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

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

> && bar(y)" no longer short-circuits, resulting in much confusion.  I'd
like
> to take Scott Meyer's advice on never overloading &&/||/, and push it into
> the language itself, and prohibit overloading them.

    I would hate you for that. We use operator overloading to construct SQL
statements - something that seems little bit nasty first, but is VERY
comfortable in fact. You would cancel our ability to write

SQL * Select(SOMECOLUMN).From(SOMETABLE).Where(KEY >= low && KEY <= high);

    Please do not suggest further restrictions on language. C++ is not
language for begginer programmers, it is language to get things done.

Mirek


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

"Phil Edwards" <pedwards@dmapub.dma.org> wrote in message
news:200105081905.PAA11977@dmapub.dma.org...
> The idea of adding arbitrary operators has been brought up since operator
> overloading was introduced.  The problem is that you also have to describe
> (in your program) the order of evaluation and precedence

Defining precedence is not a problem, Algol 68 did it.

Order of evaluation is not a problem specific to operators.
What is needed is an efficient way to create closures.
So for example:

  int andif(int a, closure<int> b)
  {
    if (a)
      return b();
    else
      return 0;
  }

  template<class T> T ifsquare(int n, closure<T> a)
  {
    if (n != 0)
    {
      T temp = a();
      return temp * temp;
    }
  }

Because the closure value may reference the caller's
environment this effectively forces the called functions
to be inline.

You could use operator() as a way to force evaluation
when passing the closure to other functions.



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

"Phil Edwards" <pedwards@dmapub.dma.org> wrote in message
news:200105081905.PAA11977@dmapub.dma.org...

[snip]

> So what's the semantics of
>
>     a = foo + bar roll qux - baz;
>
> What happens first?
>
> The idea of adding arbitrary operators has been brought up since operator
> overloading was introduced.  The problem is that you also have to describe
> (in your program) the order of evaluation and precedence, or if you don't
> want to allow that level of flexibility in the language, you have to
> have them all default to the same, and nobody will ever agree on what's a
> "reasonable" default.
>
> Operator overloading already has the problem that the semantics are
changed
> to function-call semantics, e.g., if you overload operator&& then "foo(x)
> && bar(y)" no longer short-circuits, resulting in much confusion.  I'd
like
> to take Scott Meyer's advice on never overloading &&/||/, and push it into
> the language itself, and prohibit overloading them.
>
[snip]

If named operators are considered just an alias for function calls (it looks
to me to make most sense), and funciton calls have *higher* precedence than
the operators, I would suggest it is the same as:
   foo + (bar roll qux) - baz
or
   foo + roll (bar, qux) - baz

Farther, a couple of examples:

--------------
bool in (int item, const std::set <int>& set)
{
    return set.find (item) != set.end();
}

Compare:

if (5 in set)
  ...

versus whichever you prefer:

if (set.find(5) != set.end())
if (in (5,set))
if (contains (set, 5))

----------
struct vector
{
      double x, y;
};

double operator * (vector a, vector b)
{
    return a.x * b.y - b.x * a.y;
}

double operator x (vector a, vector b)
{
    return a.x * b.x + a.y * b.y;
}

vector a, b;

double c = a * b,
           d = a x b;

looks nice, doesn't it?

--------

Radoslav Getov



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

In article <tfgeppjoa8brf4@corp.supernews.com> you write:
>
> Named operators? I.e.
>
> X operator roll (const Y& a, const Z& b)
> {
> .... // whatever
> };
>
> X a;
> Y b;
> Z c;
>
> a = b roll c;

So what's the semantics of

    a = foo + bar roll qux - baz;

What happens first?

The idea of adding arbitrary operators has been brought up since operator
overloading was introduced.  The problem is that you also have to describe
(in your program) the order of evaluation and precedence, or if you don't
want to allow that level of flexibility in the language, you have to
have them all default to the same, and nobody will ever agree on what's a
"reasonable" default.

Operator overloading already has the problem that the semantics are changed
to function-call semantics, e.g., if you overload operator&& then "foo(x)
&& bar(y)" no longer short-circuits, resulting in much confusion.  I'd like
to take Scott Meyer's advice on never overloading &&/||/, and push it into
the language itself, and prohibit overloading them.


Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

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

Phil Edwards wrote:

> [ ... snip ... ]
>
> Operator overloading already has the problem that the semantics are changed
> to function-call semantics, e.g., if you overload operator&& then "foo(x)
> && bar(y)" no longer short-circuits, resulting in much confusion.  I'd like
> to take Scott Meyer's advice on never overloading &&/||/, and push it into
> the language itself, and prohibit overloading them.

The best argument I heard for allowing overloading of && and
|| was their use in expression templates, where the overloaded
versions can still (mostly) have the expected short-cut
semantics.

-- James Dennett

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