Re: Blocks in g++ ?

Re: Blocks in g++ ?

[Thomas Steffen]

Per Bothner <bothner@pacbell.net> wrote:
    Per> It is worth pointing out that blocks, if implemented as
    Per> lexical closures as is the de facto Smalltalk standard, are
    Per> much more powerful than Gcc's nested functions, since the
    Per> latter do *not* create proper closures. 

yes, that's what i thought. afaik you can't pass nested functions as
parameters to unrelated calls (in a foreign context), where you can
pass closures. 

the other difference is syntax, two closures (even with parameters) in 
one line is possible and might even make sense. but you don't wont to
declare two functions (or even classes) within one line...

    Per> (Creating closures is probably not practical unless you have
    Per> garbage collection.)

that would explain why i have found only one case of closures in a
compiler (one of the objective-C compilers, not gcc). could you
explain why? 

i know that closures are probably difficult to support. but i could
imagine that you can pass the definition context (stack frame) just
like you pass 'this' to every method. so you could access the two
different contexts. and the problem of nested closures could be solved 
much the same way as for nested functions or nested classes. what am i 
missing?

           "Thomas Steffen" <for_replies_only@iname.com>
-- 
We regret to announce that Windows 2000 wont be ready before 1901.

Re: Blocks in g++ ?

[Joern Rennecke]

> yes, that's what i thought. afaik you can't pass nested functions as
> parameters to unrelated calls (in a foreign context), where you can
> pass closures. 

You can.
What you can't do is store a pointer to a nested function and use it after
the function it was nested in has returned.

Re: Blocks in g++ ?

[Thomas Steffen]

>>>>> "Joern" == Joern Rennecke <amylaar@cygnus.co.uk> writes:

    >> yes, that's what i thought. afaik you can't pass nested
    >> functions as parameters to unrelated calls (in a foreign
    >> context), where you can pass closures.

oops. i ment you CAN pass, of course. so...

    Joern> You can.  What you can't do is store a pointer to a nested
    Joern> function and use it after the function it was nested in has
    Joern> returned.

indeed, i hadn't thought about that (neither about that use nor it's
infeasibility). it would be nice for GUI programming of course, so you 
could write all those eventhandlers/callbacks very easily. 

still, even if the closure is only available during the nested
function call, it would be useful for a lot of things... 

	    "Thomas Steffen" <for_replies_only@iname.com>
-- 
linux, linuctis - f, das beste Betriebssystem ;-) [Tobi in doc]

Re: Blocks in g++ ?

[Per Bothner]

"Thomas Steffen" <for_replies_only@iname.com> writes:

> Per Bothner <bothner@pacbell.net> wrote:
>     Per> (Creating closures is probably not practical unless you have
>     Per> garbage collection.)
> 
> that would explain why i have found only one case of closures in a
> compiler (one of the objective-C compilers, not gcc). could you
> explain why? 

Closures are objects.  (You can simulate objects using closures and
vice versa, fairly painlessly.)  The problems is how to reclaim the
memory used by a closure if you are passing around a reference to
a closure object.  I suppose you might be able to do it with reference
counting.  But that means C++ has to know when it needs to adjust
closure references, which means it needs to know whetheer a pointer
is a reference to a closure or a pointer to a regular function.

I guess with some cleverness one would work out something that
works.  I don't know of anyone having done so, though.  Perhaps
its a cultural thing:  People who want closures also want full
gcc, so it seems pointless to implement closures without gc.

Might make a nice Master's thesis project, though, or an useful
research paper.
--
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: Blocks in g++ ?

[Ross Smith]

Per Bothner wrote:
> 
> Closures are objects.  (You can simulate objects using closures and
> vice versa, fairly painlessly.)  The problems is how to reclaim the
> memory used by a closure if you are passing around a reference to
> a closure object.

Why is this a problem? That is: If closures are objects, why is memory
management more difficult for closures than it is for any other kind of
object? I mean, C and C++ have had pointers since the year dot. Every
programmer has learned how to manage memory. What's different about
closures?

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  I know you're desperate, I really sympathise
  I see the morbid horror flicker in your eyes
  But rest assured I'm gonna help to ease your pain
  I'm gonna put a thousand tiny implants in your brain     [Motorhead]

Re: Blocks in g++ ?

[Thomas Steffen]

>>>>> "Per" == Per Bothner <bothner@pacbell.net> writes:

    Per> "Thomas Steffen" <for_replies_only@iname.com> writes:

    Per> (Creating closures is probably not practical unless you have
    Per> garbage collection.)

...

    Per> Closures are objects.  (You can simulate objects using
    Per> closures and vice versa, fairly painlessly.)  The problems is
    Per> how to reclaim the memory used by a closure if you are
    Per> passing around a reference to a closure object. 

yes, i see. but i think we are actually talking about 2 separate types 
of closures:

a) closures with access to the initial environment (in which they were 
   *defined* and passed as an argument). these are useful for user
   defined control structures, symmetric calls for starting and ending 
   something (you just pass the stuff in between as a closure) etc.
   these closures can live only for the duration of the call to which
   they are an argument. so destruction is no problem, they behave
   just like automatic variables. they would need some weird stack
   frame manipulation though (like nested functions).

b) long life closures. these can be hooks or call-back stuff, useful
   for GUI programming and similar things. they have to live longer
   than the scope of their name, so destruction is a problem. but it
   is no more a problem than with any other C++ object. these closures 
   can be represented by object (they are some sort of anonymous
   classes, like you can do them in Java, right?). 

imho you can't have both at the same time, at least not in any usual
environment (you can in tcl...). but i was interested in variant
a). just a short example what you could do with it:

   file("somefile.tmp", [ :file | fprintf(file,"sometext"); ] );

(this is imagining a smalltalk like syntax for blocks). function file()
would create a file(handle) and pass it as the only parameter to the
block. after the execution, the file would be closed. 

what do you gain? you don't have to declare the file handle, you will
allways close it after you have used it, the block could be repeated
if something fails... and it is short, very short. 

even if it is not used in the example, the access to all variable in
the scope is of vital importance for these kind of blocks. and this is
exactly what you can't do with objects (well, maybe you could, but it
is akward), and what is giving me headache if i think about an
implementation. because the block is actually called somewhere in
function file, but it should have access the automatic variables
somewhere else.

    Per> Might make a nice Master's thesis project, though, or an
    Per> useful research paper.  --

yes, would be really nice. unfortunately, i'm not in computer
science...

    Per> Perhaps its a cultural thing: People who want closures also
    Per> want full gcc, so it seems pointless to implement closures
    Per> without gc.

could be, *i* don't like gc either... BTW, is there a reasonable way
to do reference counting in C++? so you don't need gc, but don't have
to worry about destruction objects either?


		    Thomas <t.steffen@tu-harburg.de>

      (C) Copyright 1999 by Thomas Steffen, not to be forwarded
-- 
linux, linuctis - f, das beste Betriebssystem ;-) [Tobi in doc]

Re: Blocks in g++ ?

[Bruce Stephens]

Thomas Steffen <t.steffen@tu-harburg.de> writes:

> b) long life closures. these can be hooks or call-back stuff, useful
>    for GUI programming and similar things. they have to live longer
>    than the scope of their name, so destruction is a problem. but it
>    is no more a problem than with any other C++ object. these closures 
>    can be represented by object (they are some sort of anonymous
>    classes, like you can do them in Java, right?). 
> 
> imho you can't have both at the same time, at least not in any usual
> environment (you can in tcl...). but i was interested in variant
> a). just a short example what you could do with it:

Scheme might be a better example.  Closures are one thing that Tcl
lacks, unfortunately.

Re: Blocks in g++ ?

[Martin Uecker]

On Sat, Jun 12, 1999 at 05:55:40PM +0200, Thomas Steffen wrote:

[...]

> a). just a short example what you could do with it:
> 
>    file("somefile.tmp", [ :file | fprintf(file,"sometext"); ] );
> 
> (this is imagining a smalltalk like syntax for blocks). function file()
> would create a file(handle) and pass it as the only parameter to the
> block. after the execution, the file would be closed. 

In GNU-C you can do something like this:

#define closure(rtype, args, code) \
({ \
	rtype __closure args { return code; } \
	&__closure; \
})

...

foo A[N];

qsort(N, closure(int, (int i, int j), compare_foo(A[i], A[j])),
         closure(void, (int i, int j), SWAP(A[i], A[j])));

[...] 

> could be, *i* don't like gc either... BTW, is there a reasonable way
> to do reference counting in C++? so you don't need gc, but don't have
> to worry about destruction objects either?

www.faqs.org -> C++ FAQ

Martin

Re: Blocks in g++ ?

[Martin Uecker]

On Sat, Jun 12, 1999 at 05:55:40PM +0200, Thomas Steffen wrote:

[...]

> a). just a short example what you could do with it:
> 
>    file("somefile.tmp", [ :file | fprintf(file,"sometext"); ] );
> 
> (this is imagining a smalltalk like syntax for blocks). function file()
> would create a file(handle) and pass it as the only parameter to the
> block. after the execution, the file would be closed. 

In GNU-C you can do something like this:

#define closure(rtype, args, code) \
({ \
	rtype __closure args { return code; } \
	&__closure; \
})

...

foo A[N];

qsort(N, closure(int, (int i, int j), compare_foo(A[i], A[j])),
         closure(void, (int i, int j), SWAP(A[i], A[j])));

[...] 

> could be, *i* don't like gc either... BTW, is there a reasonable way
> to do reference counting in C++? so you don't need gc, but don't have
> to worry about destruction objects either?

www.faqs.org -> C++ FAQ

Martin

Re: Blocks in g++ ?

[Thomas Steffen]

Per Bothner <bothner@pacbell.net> wrote:
    Per> It is worth pointing out that blocks, if implemented as
    Per> lexical closures as is the de facto Smalltalk standard, are
    Per> much more powerful than Gcc's nested functions, since the
    Per> latter do *not* create proper closures. 

yes, that's what i thought. afaik you can't pass nested functions as
parameters to unrelated calls (in a foreign context), where you can
pass closures. 

the other difference is syntax, two closures (even with parameters) in 
one line is possible and might even make sense. but you don't wont to
declare two functions (or even classes) within one line...

    Per> (Creating closures is probably not practical unless you have
    Per> garbage collection.)

that would explain why i have found only one case of closures in a
compiler (one of the objective-C compilers, not gcc). could you
explain why? 

i know that closures are probably difficult to support. but i could
imagine that you can pass the definition context (stack frame) just
like you pass 'this' to every method. so you could access the two
different contexts. and the problem of nested closures could be solved 
much the same way as for nested functions or nested classes. what am i 
missing?

           "Thomas Steffen" <for_replies_only@iname.com>
-- 
We regret to announce that Windows 2000 wont be ready before 1901.

Re: Blocks in g++ ?

[Bruce Stephens]

Thomas Steffen <t.steffen@tu-harburg.de> writes:

> b) long life closures. these can be hooks or call-back stuff, useful
>    for GUI programming and similar things. they have to live longer
>    than the scope of their name, so destruction is a problem. but it
>    is no more a problem than with any other C++ object. these closures 
>    can be represented by object (they are some sort of anonymous
>    classes, like you can do them in Java, right?). 
> 
> imho you can't have both at the same time, at least not in any usual
> environment (you can in tcl...). but i was interested in variant
> a). just a short example what you could do with it:

Scheme might be a better example.  Closures are one thing that Tcl
lacks, unfortunately.

Re: Blocks in g++ ?

[Ross Smith]

Per Bothner wrote:
> 
> Closures are objects.  (You can simulate objects using closures and
> vice versa, fairly painlessly.)  The problems is how to reclaim the
> memory used by a closure if you are passing around a reference to
> a closure object.

Why is this a problem? That is: If closures are objects, why is memory
management more difficult for closures than it is for any other kind of
object? I mean, C and C++ have had pointers since the year dot. Every
programmer has learned how to manage memory. What's different about
closures?

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  I know you're desperate, I really sympathise
  I see the morbid horror flicker in your eyes
  But rest assured I'm gonna help to ease your pain
  I'm gonna put a thousand tiny implants in your brain     [Motorhead]

Re: Blocks in g++ ?

[Per Bothner]

"Thomas Steffen" <for_replies_only@iname.com> writes:

> Per Bothner <bothner@pacbell.net> wrote:
>     Per> (Creating closures is probably not practical unless you have
>     Per> garbage collection.)
> 
> that would explain why i have found only one case of closures in a
> compiler (one of the objective-C compilers, not gcc). could you
> explain why? 

Closures are objects.  (You can simulate objects using closures and
vice versa, fairly painlessly.)  The problems is how to reclaim the
memory used by a closure if you are passing around a reference to
a closure object.  I suppose you might be able to do it with reference
counting.  But that means C++ has to know when it needs to adjust
closure references, which means it needs to know whetheer a pointer
is a reference to a closure or a pointer to a regular function.

I guess with some cleverness one would work out something that
works.  I don't know of anyone having done so, though.  Perhaps
its a cultural thing:  People who want closures also want full
gcc, so it seems pointless to implement closures without gc.

Might make a nice Master's thesis project, though, or an useful
research paper.
--
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: Blocks in g++ ?

[Joern Rennecke]

> yes, that's what i thought. afaik you can't pass nested functions as
> parameters to unrelated calls (in a foreign context), where you can
> pass closures. 

You can.
What you can't do is store a pointer to a nested function and use it after
the function it was nested in has returned.

Re: Blocks in g++ ?

[Thomas Steffen]

>>>>> "Joern" == Joern Rennecke <amylaar@cygnus.co.uk> writes:

    >> yes, that's what i thought. afaik you can't pass nested
    >> functions as parameters to unrelated calls (in a foreign
    >> context), where you can pass closures.

oops. i ment you CAN pass, of course. so...

    Joern> You can.  What you can't do is store a pointer to a nested
    Joern> function and use it after the function it was nested in has
    Joern> returned.

indeed, i hadn't thought about that (neither about that use nor it's
infeasibility). it would be nice for GUI programming of course, so you 
could write all those eventhandlers/callbacks very easily. 

still, even if the closure is only available during the nested
function call, it would be useful for a lot of things... 

	    "Thomas Steffen" <for_replies_only@iname.com>
-- 
linux, linuctis - f, das beste Betriebssystem ;-) [Tobi in doc]

Re: Blocks in g++ ?

[Thomas Steffen]

>>>>> "Per" == Per Bothner <bothner@pacbell.net> writes:

    Per> "Thomas Steffen" <for_replies_only@iname.com> writes:

    Per> (Creating closures is probably not practical unless you have
    Per> garbage collection.)

...

    Per> Closures are objects.  (You can simulate objects using
    Per> closures and vice versa, fairly painlessly.)  The problems is
    Per> how to reclaim the memory used by a closure if you are
    Per> passing around a reference to a closure object. 

yes, i see. but i think we are actually talking about 2 separate types 
of closures:

a) closures with access to the initial environment (in which they were 
   *defined* and passed as an argument). these are useful for user
   defined control structures, symmetric calls for starting and ending 
   something (you just pass the stuff in between as a closure) etc.
   these closures can live only for the duration of the call to which
   they are an argument. so destruction is no problem, they behave
   just like automatic variables. they would need some weird stack
   frame manipulation though (like nested functions).

b) long life closures. these can be hooks or call-back stuff, useful
   for GUI programming and similar things. they have to live longer
   than the scope of their name, so destruction is a problem. but it
   is no more a problem than with any other C++ object. these closures 
   can be represented by object (they are some sort of anonymous
   classes, like you can do them in Java, right?). 

imho you can't have both at the same time, at least not in any usual
environment (you can in tcl...). but i was interested in variant
a). just a short example what you could do with it:

   file("somefile.tmp", [ :file | fprintf(file,"sometext"); ] );

(this is imagining a smalltalk like syntax for blocks). function file()
would create a file(handle) and pass it as the only parameter to the
block. after the execution, the file would be closed. 

what do you gain? you don't have to declare the file handle, you will
allways close it after you have used it, the block could be repeated
if something fails... and it is short, very short. 

even if it is not used in the example, the access to all variable in
the scope is of vital importance for these kind of blocks. and this is
exactly what you can't do with objects (well, maybe you could, but it
is akward), and what is giving me headache if i think about an
implementation. because the block is actually called somewhere in
function file, but it should have access the automatic variables
somewhere else.

    Per> Might make a nice Master's thesis project, though, or an
    Per> useful research paper.  --

yes, would be really nice. unfortunately, i'm not in computer
science...

    Per> Perhaps its a cultural thing: People who want closures also
    Per> want full gcc, so it seems pointless to implement closures
    Per> without gc.

could be, *i* don't like gc either... BTW, is there a reasonable way
to do reference counting in C++? so you don't need gc, but don't have
to worry about destruction objects either?


		    Thomas <t.steffen@tu-harburg.de>

      (C) Copyright 1999 by Thomas Steffen, not to be forwarded
-- 
linux, linuctis - f, das beste Betriebssystem ;-) [Tobi in doc]

Re: Blocks in g++ ?

[Thomas Steffen]

Martin Uecker <muecker@mayn.de> wrote:

    Martin> In GNU-C you can do something like this:
...
    Martin> qsort(N, closure(int, (int i, int j), compare_foo(A[i], A[j])),
    Martin>          closure(void, (int i, int j), SWAP(A[i], A[j])));

i didn't know that, is it documented anywhere? sounds a bit like what
i'm trying to achive. do you have access to the automatic variables
defined around the call to qsort? does it work for g++?

thanks very much for the hint...

                "Thomas Steffen" <for_replies_only@iname.com> 
-- 
We regret to announce that Windows 2000 wont be ready before 1901.

Re: Blocks in g++ ?

[Joern Rennecke]

> argument to a function. the special bit about blocks is that they are
> executed by the called function, but they are parsed in the context of 
> where they are defined. so you have access to local variables etc...

Look in extend.texi for 'Nested Functions' .

Re: Blocks in g++ ?

[Per Bothner]

Joern Rennecke <amylaar@cygnus.co.uk> writes:
> > argument to a function. the special bit about blocks is that they are
> > executed by the called function, but they are parsed in the context of 
> > where they are defined. so you have access to local variables etc...
> 
> Look in extend.texi for 'Nested Functions' .

It is worth pointing out that blocks, if implemented as lexical closures
as is the de facto Smalltalk standard, are much more powerful than Gcc's
nested functions, since the latter do *not* create proper closures.
(Creating closures is probably not practical unless you have garbage
collection.)
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: Blocks in g++ ?

[Bruce Stephens]

Per Bothner <bothner@pacbell.net> writes:

> It is worth pointing out that blocks, if implemented as lexical
> closures as is the de facto Smalltalk standard, are much more
> powerful than Gcc's nested functions, since the latter do *not*
> create proper closures.  (Creating closures is probably not
> practical unless you have garbage collection.)

And anyway, g++ doesn't have nested functions, as far as I can see.

How about function objects (like those in what used to be called STL)?
They provide something a bit like blocks, although not quite the same.

Blocks in g++ ?

[Thomas Steffen]

hi,

would it be possible to add block support to g++? i mean blocks in
the smalltalk sense, ala:

        if sometest then: [ doa ] else: [ dob ] 

so blocks are a bit like anonymous functions that can be given as an
argument to a function. the special bit about blocks is that they are
executed by the called function, but they are parsed in the context of 
where they are defined. so you have access to local variables etc...

i guess this could make an implementation quite akward, seems like
some fiddling with the stack point or similar is necessary. 

still, blocks are the one feature from smalltalk that i am really
missing in other languages. it is a simple solution to a lot of simple 
problems. these include user defined control structures, matching
begin_something and end_something functions, short callbacks etc.
 
please send me a copy if you post a reply.

           "Thomas Steffen" <for_replies_only@iname.com>
-- 
We regret to announce that Windows 2000 wont be ready before 1901.

Re: Blocks in g++ ?

[Thomas Steffen]

Martin Uecker <muecker@mayn.de> wrote:

    Martin> In GNU-C you can do something like this:
...
    Martin> qsort(N, closure(int, (int i, int j), compare_foo(A[i], A[j])),
    Martin>          closure(void, (int i, int j), SWAP(A[i], A[j])));

i didn't know that, is it documented anywhere? sounds a bit like what
i'm trying to achive. do you have access to the automatic variables
defined around the call to qsort? does it work for g++?

thanks very much for the hint...

                "Thomas Steffen" <for_replies_only@iname.com> 
-- 
We regret to announce that Windows 2000 wont be ready before 1901.

Re: Blocks in g++ ?

[Bruce Stephens]

Per Bothner <bothner@pacbell.net> writes:

> It is worth pointing out that blocks, if implemented as lexical
> closures as is the de facto Smalltalk standard, are much more
> powerful than Gcc's nested functions, since the latter do *not*
> create proper closures.  (Creating closures is probably not
> practical unless you have garbage collection.)

And anyway, g++ doesn't have nested functions, as far as I can see.

How about function objects (like those in what used to be called STL)?
They provide something a bit like blocks, although not quite the same.

Re: Blocks in g++ ?

[Per Bothner]

Joern Rennecke <amylaar@cygnus.co.uk> writes:
> > argument to a function. the special bit about blocks is that they are
> > executed by the called function, but they are parsed in the context of 
> > where they are defined. so you have access to local variables etc...
> 
> Look in extend.texi for 'Nested Functions' .

It is worth pointing out that blocks, if implemented as lexical closures
as is the de facto Smalltalk standard, are much more powerful than Gcc's
nested functions, since the latter do *not* create proper closures.
(Creating closures is probably not practical unless you have garbage
collection.)
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: Blocks in g++ ?

[Joern Rennecke]

> argument to a function. the special bit about blocks is that they are
> executed by the called function, but they are parsed in the context of 
> where they are defined. so you have access to local variables etc...

Look in extend.texi for 'Nested Functions' .

Blocks in g++ ?

[Thomas Steffen]

hi,

would it be possible to add block support to g++? i mean blocks in
the smalltalk sense, ala:

        if sometest then: [ doa ] else: [ dob ] 

so blocks are a bit like anonymous functions that can be given as an
argument to a function. the special bit about blocks is that they are
executed by the called function, but they are parsed in the context of 
where they are defined. so you have access to local variables etc...

i guess this could make an implementation quite akward, seems like
some fiddling with the stack point or similar is necessary. 

still, blocks are the one feature from smalltalk that i am really
missing in other languages. it is a simple solution to a lot of simple 
problems. these include user defined control structures, matching
begin_something and end_something functions, short callbacks etc.
 
please send me a copy if you post a reply.

           "Thomas Steffen" <for_replies_only@iname.com>
-- 
We regret to announce that Windows 2000 wont be ready before 1901.