In article <m3ae47uqzf.fsf@gnu.org>, John Wiegley  <johnw@gnu.org> wrote:
>>>>>> On Sun May 20, Eugene writes:
>> Doesn't it in fact mean that the language is dead? (BTW, I don't
>> think so).
>
>That, or perhaps we should consider taking away at the same time as we
>add.  Given the complexity of a recent discussion over what "A::B ::C"
>really means, it seems to me that constantly adding new features to
>the core language is an untenable proposition.  Most of Bjarne's
>presentation on C++0x focused on standardizing library extensions,
>something I am heartily in favor of.

One could offer this same grim picture of the C++ library too.
But when all is said and done, what's clear is that there are
still missing facilities.  I want to prefer lib solutions to them
over core ones when possible, but will certainly keep an open
mind for those cases where that's not best.  Certainly we shouldn't
add every lib suggestion either, so some sense of being conservative
needs to always be there.
--
Greg Comeau                 Comeau C/C++ 4.2.45.2
ONLINE COMPILER ==>         http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo!       NEW: Try out our C99 mode!
comeau@comeaucomputing.com  http://www.comeaucomputing.com

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

Mon, 21 May 2001 18:50:31 GMT, Carl Daniel <carl@pixami.com> pisze:

> My recollection is that the reasons for not adding local functions
> were not technical, but ideological: the feeling was that local
> functions promoted a programming style which C++ wanted to
> de-emphasize (functional decomposition).

But C++ uses that style in the part of standard library coming from
STL, and tries to emulate closures with function objects, with looks
really bad.

I don't believe that there are no technical reasons: each closure of
the same interface can have different representation (depending on the
form of the local environment), so it's hard to express them in C++
types which are quite low-level.

If C++ had garbage collection, algebraic types and function closures,
I would consider using it from time to time :-)

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

>>>>> On Sat May 19, Carl writes:

> Yet more ideas...

> 1. Introduction of a new class of types "pointer to bound function"
>    (i.e. the result of operator ->* and operator .*).

This is pretty much what a "closure" is.

> 2. Local functions (note that a local function is a function bound
>    to an implicit object - the stack frame of it's parent function).

> Having 1 and 2 leads quite naturally into...

> 3. Anonymous local functions - lambdas

> I just have to work on a Perl program for a little while to remind
> me how useful closures are.  While I wouldn't want the overhead of
> Perl-like closures, anonymous local functions would be oh so handy -
> things like std::for_each and it's kin would then actually be
> useful!

If one were to look at the current complexity of name lookup, name
resolution, template name binding, etc., I think people would run
screaming from any suggestion whatsoever to complicate the namespace
issues of functions.  What about overloading rules?  What about
visibility?  How would you declare a local function as a friend?  What
about a template that is instantiated in view of a local function?
What is their linkage?  Can a pointer be passed to another translation
units and still be expected to work?

There is a time when a language doesn't need any more features, and
it's better just to create another language.  There are so many
special cases within the text of the Standard right now, that it would
be like adding a weight to a precariously balanced, intricate
structure, with thousands of other people standing in line behind you,
all wanting to add weights of their own.

John

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

Sun, 20 May 2001 10:45:56 GMT John Wiegley                      :
>There is a time when a language doesn't need any more features, and
>it's better just to create another language.  There are so many
>special cases within the text of the Standard right now, that it would
>be like adding a weight to a precariously balanced, intricate
>structure, with thousands of other people standing in line behind you,
>all wanting to add weights of their own.

Doesn't it in fact mean that the language is dead? (BTW, I don't think so).

--
jk

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

"John Wiegley" <johnw@gnu.org> wrote in message
news:m3wv7dw0cu.fsf@gnu.org...
> >>>>> On Sat May 19, Carl writes:
> > 2. Local functions (note that a local function is a function bound
> >    to an implicit object - the stack frame of it's parent function).

I like this one.  Right now you can do this using an inline function as a
member of a class.  But there are severe limits to this (ie not all
functions can be inline)

Greg


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

>>>>> On Sun May 20, Eugene writes:

> Doesn't it in fact mean that the language is dead? (BTW, I don't
> think so).

That, or perhaps we should consider taking away at the same time as we
add.  Given the complexity of a recent discussion over what "A::B ::C"
really means, it seems to me that constantly adding new features to
the core language is an untenable proposition.  Most of Bjarne's
presentation on C++0x focused on standardizing library extensions,
something I am heartily in favor of.

John

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

"John Wiegley" <johnw@gnu.org> wrote in message
news:m3wv7dw0cu.fsf@gnu.org...
>
> >>>>> On Sat May 19, Carl writes:
>
> > Yet more ideas...
>
> > 1. Introduction of a new class of types "pointer to bound function"
> >    (i.e. the result of operator ->* and operator .*).
>
> This is pretty much what a "closure" is.

Pretty much, yes.  The Perl concept of a closure includes more than this,
however in the Perl closures can hold references to variables defined in the
enclosing scope even after that scope has been exited.  This is possible in
Perl since local variables aren't stored on the CPU stack like they are (at
least usually) in C++.  Rather, local variables are allocated in "heap"
memory which is referenced by the stack frame.  A Perl closure holds a
reference to that memory as well.  Having such a facility in C++ would be
too costly and (I think) would seriously violate the "you don't pay for what
you don't use" rule out of necessity.

>
> > 2. Local functions (note that a local function is a function bound
> >    to an implicit object - the stack frame of it's parent function).
>
> > Having 1 and 2 leads quite naturally into...
>
> > 3. Anonymous local functions - lambdas
>
> > I just have to work on a Perl program for a little while to remind
> > me how useful closures are.  While I wouldn't want the overhead of
> > Perl-like closures, anonymous local functions would be oh so handy -
> > things like std::for_each and it's kin would then actually be
> > useful!
>
> If one were to look at the current complexity of name lookup, name
> resolution, template name binding, etc., I think people would run
> screaming from any suggestion whatsoever to complicate the namespace
> issues of functions.  What about overloading rules?  What about
> visibility?  How would you declare a local function as a friend?  What
> about a template that is instantiated in view of a local function?
> What is their linkage?  Can a pointer be passed to another translation
> units and still be expected to work?
>

I don't think this would seriously complicate the name lookup, resolution,
etc rules because what I'm proposing is a new class of types with their own
set of rules and NO IMPLICIT CONVERSIONS.  From a name lookup standpoint
they should be no harder to implement than ordinary pointers-to-functions.
Local functions do enter into name lookup, but since I'm not proposing any
new mechamisms for defining scope, I don't think the rules would need to be
changed at all.

Overloading rules are not relevant - I'm not proposing a new way of
constructing functions (such as partial function template specialization -
which definitely would interact with overloading).  Just as there is no
overloading of function pointer types, there'd be no overloading of
bound-function pointer types.

Visibility is also orthogonal - what I'm proposing are new types, not new
scope constructs, and instances of the new types would fall under the same
visibility rules as functions/variables of any other types.

Local functions could be friends only to local classes defiined in the same
outer function.  In that context, the friend declaration would be unchanged
from it's current form.

If local functions and bound functions were unified, both
pointer-to-local-function and pointer-to-bound-function could both be used
as template arguments without issue.  Without unification,
pointer-to-bound-function could still be used as a template parameter, but
pointer-to-local-function couldn't be.

Linkage - same as ordinary functions.  Passed to another translation unit &
expected to work?  Yes - since we're defining a new type, the type system
would have to ensure that they're compatible across compilation units.

This is all off the top of my head - I'm sure there are holes in it.  Given
the existence of languages like Pascal which provide local functions,
however, I cannot imagine that there are any insurmountable problems with
supporing them.  Indeed, in D&E, Dr. Stroustrup discusses local functions &
why they we not added (there was a serious proposal to do so).  My
recollection is that the reasons for not adding local functions were not
technical, but ideological: the feeling was that local functions promoted a
programming style which C++ wanted to de-emphasize (functional
decomposition).  With the current trend towards C++ supporting many
paradigms - including functional programming, I think it's time to re-visit
that decision.

-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.research.att.com/~austern/csc/faq.html                ]

Yet more ideas...

1. Introduction of a new class of types "pointer to bound function" (i.e.
the result of operator ->* and operator .*).
2. Local functions (note that a local function is a function bound to an
implicit object - the stack frame of it's parent function).

Having 1 and 2 leads quite naturally into...

3. Anonymous local functions - lambdas

I just have to work on a Perl program for a little while to remind me how
useful closures are.  While I wouldn't want the overhead of Perl-like
closures, anonymous local functions would be oh so handy - things like
std::for_each and it's kin would then actually be useful!

-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.research.att.com/~austern/csc/faq.html                ]