apple blocks extension

apple blocks extension

[Vincent R.]

Hi,

I just was curious to know if closures in apple gcc(called blocks from
what I read) is
also in mainline.
What is the status about this extension ?

Thanks

Re: apple blocks extension

[Steven Bosscher]

On Tue, Sep 15, 2009 at 3:28 PM, Vincent R. <forumer@smartmobili.com> wrote:
> Hi,
>
> I just was curious to know if closures in apple gcc(called blocks from
> what I read) is
> also in mainline.
> What is the status about this extension ?

Hi,

The status is that there is no status, unfortunately (it's an
interesting extension...).

This extension is not presently implemented in the FSF GCC.
AFAIU there is no reason to believe Apple will contribute patches to
implement it.

Is there even a formal spec for the language extension?

Ciao!
Steven

Re: apple blocks extension

[Dave Korn]

Steven Bosscher wrote:

> Is there even a formal spec for the language extension?

  I think it's http://clang.llvm.org/docs/BlockLanguageSpec.txt as that's the
one they've referred to in their white paper (wg14/n1370).  It's not written
in your typical standardese as yet, though, from what I could find.

    cheers,
      DaveK

Re: apple blocks extension

[Tristan Gingold]

On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote:
>
> Hi,
>
> The status is that there is no status, unfortunately (it's an
> interesting extension...).
>
> This extension is not presently implemented in the FSF GCC.
> AFAIU there is no reason to believe Apple will contribute patches to
> implement it.

I think you may (are allowed to) port it from Apple GCC sources.

Tristan.

Re: apple blocks extension

[Vincent R.]

On Tue, 15 Sep 2009 16:03:35 +0200, Tristan Gingold <gingold@adacore.com>
wrote:
> On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote:
>>
>> Hi,
>>
>> The status is that there is no status, unfortunately (it's an
>> interesting extension...).
>>
>> This extension is not presently implemented in the FSF GCC.
>> AFAIU there is no reason to believe Apple will contribute patches to
>> implement it.
> 
> I think you may (are allowed to) port it from Apple GCC sources.

I don't have time nor skills but I think it's an interesting feature and I
wouldn't like clang
to be the only compiler to have it. Besides if gcc implements it too it
would make a kind of standard...
But maybe true C programmers find that it's nothing more than a syntaxic
sugar but I would answer that C
is just syntaxic sugar for ASM ;-)

Re: apple blocks extension

[Richard Henderson]

On 09/15/2009 08:28 AM, Vincent R. wrote:
> I just was curious to know if closures in apple gcc(called blocks from
> what I read) is
> also in mainline.
> What is the status about this extension ?

It is unlikely that this will ever be brought into GCC, since
it appears to be largely identical to the C++0x Lambda feature.

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf


r~

Re: apple blocks extension

[Ed Smith-Rowland]

Richard Henderson wrote:
> On 09/15/2009 08:28 AM, Vincent R. wrote:
>> I just was curious to know if closures in apple gcc(called blocks from
>> what I read) is
>> also in mainline.
>> What is the status about this extension ?
>
> It is unlikely that this will ever be brought into GCC, since
> it appears to be largely identical to the C++0x Lambda feature.
>
>  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf
>
>
> r~
>
I agree that it is superfluous for C++ at this stage but it might be 
nice for Objective-C (regular C) although Objective-C++ will then have 
to be taught how to deal with it somehow anyway.

OTOH, with lambdas it might be more easy to put this in.*  It is 
probably just a special case of lambdas.  We'd have to find out which 
one of course.  I think syntactically it shouldn't be too bad.**

In general, and this has come up before, there are other things in 
Objective-C 2.0 that we don't have.  IIRC the Apple trees left behind 
are a little old and not in good shape.  What are the licensing issues 
for borrowing from LLVM leaving aside the technical issues?

ed

* Or not.  I think C++ lambdas are implemented as a little class of some 
type which might make C mad.

** I was noticing that C++ lambdas and Obj-C message passing syntax 
collides a little.

Re: apple blocks extension

[Chris Lattner]

On Sep 15, 2009, at 9:04 AM, Richard Henderson wrote:

> On 09/15/2009 08:28 AM, Vincent R. wrote:
>> I just was curious to know if closures in apple gcc(called blocks  
>> from
>> what I read) is
>> also in mainline.
>> What is the status about this extension ?
>
> It is unlikely that this will ever be brought into GCC, since
> it appears to be largely identical to the C++0x Lambda feature.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf

There are major differences between lambdas and blocks, though they  
serve a superficially similar purpose.  If you are interested, there  
is a ton of discussion online.  Here are the two biggest differences:


The first difference is that every instance of a lambda gives you a  
value of a new (anonymous) type, which makes them mostly only useful  
with templates.  Blocks literals give values of a predictable type,  
which means that you can pass them around to non-templates.  This is  
also why they "work" in C.  Yes, I know that there are various adaptor  
classes that can be used with C++ lambdas to help work around this,  
but this is in inherent part of blocks.


The second major feature of Blocks vs c++ lambdas is that they can be  
"copied onto the heap".  This allows things like "Grand Central  
Dispatch" to work: you can write code that executes blocks  
asynchronously or on other threads/work queues (after the function  
containing the block has returned).  A simple example is:

void print_on_different_thread(int X) {
   run_asynch(^{
       printf("Hi %d\n", X);
   });
}

With lambdas, the closure would be go out of scope when  
print_on_different_thread returns, but blocks allows "run_asynch" to  
extend the lifetime of the block.

Blocks and Lambdas have intentionally different syntax, allowing them  
to coexist peacefully in the same compiler / language.  They are also  
superficially similar to nested functions, but have other sets of  
benefits.  For example, blocks don't require executable stacks etc.

-Chris

Re: apple blocks extension

[Ian Lance Taylor]

Ed Smith-Rowland <3dw4rd@verizon.net> writes:

> In general, and this has come up before, there are other things in
> Objective-C 2.0 that we don't have.  IIRC the Apple trees left behind
> are a little old and not in good shape.  What are the licensing issues
> for borrowing from LLVM leaving aside the technical issues?

There is no issue with looking at LLVM or Apple's version of gcc and
reimplementing the ideas in gcc.

Actual code copying depends upon the copyright status of the Apple code.
Although Apple has chosen to stop contributing to the FSF, they have
signed a perpetual copyright assignment for changes to several FSF
programs.  So it seems to me that any changes that Apple makes to gcc
(or gdb, emacs, etc.) can simply be brought over by any interested
party.

I don't know how this interacts with changes to LLVM.  However, it is
fairly unlikely that those changes could be copied directly anyhow.

Ian

Re: apple blocks extension

[Michael Meissner]

On Tue, Sep 15, 2009 at 04:03:35PM +0200, Tristan Gingold wrote:
> 
> On Sep 15, 2009, at 3:46 PM, Steven Bosscher wrote:
> >
> >Hi,
> >
> >The status is that there is no status, unfortunately (it's an
> >interesting extension...).
> >
> >This extension is not presently implemented in the FSF GCC.
> >AFAIU there is no reason to believe Apple will contribute patches to
> >implement it.
> 
> I think you may (are allowed to) port it from Apple GCC sources.

If you are not the copyright owner of the sources, I doubt the FSF would allow
it to be checked into GCC.  However, a reimplementation from scratch would be
doable.

Like everything else in the free software world, it depends on the motavations
of the people contributing the code.  To paraphrase president Kennedy, ask not
what GCC can do for you, ask what you can do for GCC?

So roll up your sleeves and get coding, or convince other people (and their
managers) that it is a good thing to do.  I suspect there are people starting
to think about it, and perhaps the interested parties need to organize to scope
out the work.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com

Re: apple blocks extension

[Mark Mitchell]

Ian Lance Taylor wrote:

> programs.  So it seems to me that any changes that Apple makes to gcc
> (or gdb, emacs, etc.) can simply be brought over by any interested
> party.

I'd certainly check with the FSF before betting on that.  ISTR that some
copyright assignments have a "contribution" step; simple publication may
not be sufficient.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: apple blocks extension

[Ian Lance Taylor]

Mark Mitchell <mark@codesourcery.com> writes:

> Ian Lance Taylor wrote:
>
>> programs.  So it seems to me that any changes that Apple makes to gcc
>> (or gdb, emacs, etc.) can simply be brought over by any interested
>> party.
>
> I'd certainly check with the FSF before betting on that.  ISTR that some
> copyright assignments have a "contribution" step; simple publication may
> not be sufficient.

True, though Apple's entry in the copyright file says "assigns past and
future changes" (I checked before the above e-mail).  Certainly checking
with the FSF is a good idea.

Ian

Re: apple blocks extension

[Vincent R.]

On Wed, 16 Sep 2009 09:20:58 -0700, Ian Lance Taylor <iant@google.com>
wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
>> Ian Lance Taylor wrote:
>>
>>> programs.  So it seems to me that any changes that Apple makes to gcc
>>> (or gdb, emacs, etc.) can simply be brought over by any interested
>>> party.
>>
>> I'd certainly check with the FSF before betting on that.  ISTR that
some
>> copyright assignments have a "contribution" step; simple publication
may
>> not be sufficient.
> 
> True, though Apple's entry in the copyright file says "assigns past and
> future changes" (I checked before the above e-mail).  Certainly checking
> with the FSF is a good idea.
> 
> Ian

While we are discussing apple extension, is there a list of apple specific
extension about 
C and objective compiler ? 

Re: apple blocks extension

[Chris Lattner]

On Sep 16, 2009, at 11:12 AM, Vincent R. wrote:
>> True, though Apple's entry in the copyright file says "assigns past  
>> and
>> future changes" (I checked before the above e-mail).  Certainly  
>> checking
>> with the FSF is a good idea.
>>
>> Ian
>
> While we are discussing apple extension, is there a list of apple  
> specific
> extension about
> C and objective compiler ?

There isn't anything good, but some information is available here:
http://clang.llvm.org/docs/LanguageExtensions.html

-Chris

Re: apple blocks extension

[Dave Korn]

Chris Lattner wrote:
> On Sep 16, 2009, at 11:12 AM, Vincent R. wrote:
>> While we are discussing apple extension, is there a list of apple 
>> specific extension about C and objective compiler ?
> 
> There isn't anything good, but some information is available here: 
> http://clang.llvm.org/docs/LanguageExtensions.html
> 
> -Chris

  See also Garst, "Apple's extensions to C", submitted to WG14:

http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1370.pdf

    cheers,
      DaveK

Re: apple blocks extension

[Linda A. Walsh]

Ian Lance Taylor wrote:
> Mark Mitchell writes "I'd certainly check with the FSF 
> > before betting on that. "
> True, though Apple's entry in the copyright file says "assigns past and
> future changes" (I checked before the above e-mail).  Certainly checking
> with the FSF is a good idea.
---
	Conceptually, it's not 'rocket science'  It's just providing some allocated memory to a procedure that it uses as it's memory, (versus memory on stack that goes away when function returns) whenever it is called and for as long as the function stays "active" (hasn't explicitly released it's allocated memory).  Perl has had similar things and nearly an entire book(Higher Order Perl, M.J. Dominus) was written about their use (it's a really good book, in my opinion -- it's not really perl specific (though everything is in perl), but I found it provided me with a fairly good understanding of closures as used with named or anonymous functions.  I believe the mention it's taken from lisp's lambda operator that did much the same.

-l

Re: apple blocks extension

[Linda A. Walsh]

Chris Lattner wrote:

> The first difference is that every instance of a lambda gives you a
> value of a new (anonymous) type, which makes them mostly only useful
> with templates. 

---
    Ahh..didn't know that.  That certainly would make them less useful
in a general sense.  I've only been exposed to the 'definable-value, returned'
variety as being the main type used and talked about in the 'higher order perl'
(higher order, that instead of working on data, you have functions working
on other functions that that may work on the data (or call other functions,
I suppose! ;-)).  

    Seems like a good way to provide automatically compatibility
layers for data marshaling so that other layers don't have to know about 
what's really in the lower layers, ala an OSI network model.

Re: apple blocks extension

[Jason Merrill]

On 09/15/2009 12:35 PM, Chris Lattner wrote:
> The second major feature of Blocks vs c++ lambdas is that they can be
> "copied onto the heap". This allows things like "Grand Central Dispatch"
> to work: you can write code that executes blocks asynchronously or on
> other threads/work queues (after the function containing the block has
> returned). A simple example is:
>
> void print_on_different_thread(int X) {
>   run_asynch(^{
>     printf("Hi %d\n", X);
>   });
> }
>
> With lambdas, the closure would be go out of scope when
> print_on_different_thread returns, but blocks allows "run_asynch" to
> extend the lifetime of the block.

The lambda equivalent would be

void print_on_different_thread(int X) {
   run_asynch([=]{
     printf("Hi %d\n", X);
   });
}

since X is captured by copy, run_asynch can do whatever it wants with 
the closure and not worry about the original X going away.

The only difference between blocks and lambdas here seems to be where 
you decide to copy the locals off the stack.

Jason

Re: apple blocks extension

[Chris Lattner]

On Sep 24, 2009, at 7:57 AM, Jason Merrill wrote:

> On 09/15/2009 12:35 PM, Chris Lattner wrote:
>> The second major feature of Blocks vs c++ lambdas is that they can be
>> "copied onto the heap". This allows things like "Grand Central  
>> Dispatch"
>> to work: you can write code that executes blocks asynchronously or on
>> other threads/work queues (after the function containing the block  
>> has
>> returned). A simple example is:
>>
>> void print_on_different_thread(int X) {
>>  run_asynch(^{
>>    printf("Hi %d\n", X);
>>  });
>> }
>>
>> With lambdas, the closure would be go out of scope when
>> print_on_different_thread returns, but blocks allows "run_asynch" to
>> extend the lifetime of the block.
>
> The lambda equivalent would be
>
> void print_on_different_thread(int X) {
>  run_asynch([=]{
>    printf("Hi %d\n", X);
>  });
> }
>
> since X is captured by copy, run_asynch can do whatever it wants  
> with the closure and not worry about the original X going away.
>
> The only difference between blocks and lambdas here seems to be  
> where you decide to copy the locals off the stack.

Can the lambda (containing X) be copied and put onto a queue?  What is  
its type?

-Chris

Re: apple blocks extension

[Jason Merrill]

On 09/24/2009 11:22 AM, Chris Lattner wrote:
> Can the lambda (containing X) be copied and put onto a queue? What is
> its type?

As you said, the lambda has a unique anonymous type.  If you want to put 
multiple lambdas into a container, you can use std::function as the 
element type.

Jason

Re: apple blocks extension

[Jason Merrill]

On 09/24/2009 11:22 AM, Chris Lattner wrote:
> Can the lambda (containing X) be copied and put onto a queue? What is
> its type?

As you said, the lambda has a unique anonymous type.  If you want to put 
multiple lambdas into a container, you can use std::function as the 
element type.

Jason

Re: apple blocks extension

[Vincent R.]

On Thu, 24 Sep 2009 12:53:04 -0400, Jason Merrill <jason@redhat.com>
wrote:
> On 09/24/2009 11:22 AM, Chris Lattner wrote:
>> Can the lambda (containing X) be copied and put onto a queue? What is
>> its type?
> 
> As you said, the lambda has a unique anonymous type.  If you want to put

> multiple lambdas into a container, you can use std::function as the 
> element type.
> 
> Jason

There was a discussion about rights to report blocks implementation into
gcc trunk,
what does FSF think about this ? Is it allowed ?