From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5d375e920909030815n74e481f4yad9814f478db5a78@mail.gmail.com> References: <09650C1A-A4C8-4030-81D6-9AC8913970A2@kix.in> <5d375e920909020532p1c3bd46l75d89db4f224301e@mail.gmail.com> <9ab217670909020720x6642f30fmaf855420f3d99c7b@mail.gmail.com> <5d375e920909030815n74e481f4yad9814f478db5a78@mail.gmail.com> Date: Thu, 3 Sep 2009 08:44:35 -0700 Message-ID: <3e1162e60909030844r8760a8fu1b27d6e60965ecfb@mail.gmail.com> From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd75480af5f740472ae429d Subject: Re: [9fans] "Blocks" in C Topicbox-Message-UUID: 616a6b9a-ead5-11e9-9d60-3106f5b1d025 --000e0cd75480af5f740472ae429d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 3, 2009 at 8:15 AM, Uriel wrote: > On Wed, Sep 2, 2009 at 4:20 PM, Devon H. O'Dell > wrote: > > 2009/9/2 Uriel : > >> On Wed, Sep 2, 2009 at 10:04 AM, Anant Narayanan wrote: > >>> Mac OS 10.6 introduced a new C compiler frontend (clang), which added > >>> support for "blocks" in C [1]. Blocks basically add closures and > anonymous > >>> functions to C (and it's derivatives). Full details with examples are > in the > >>> linked article. I think the feature is quite elegant and might be > useful in > >>> cases where you want map/reduce like functionality in C. > >> > >> Er., I might be more dumb than usual, but why on earth would you > >> need/want this garbage to get map/reduce functionality in C? > >> > >> To me it seems the typical "lets come up with some cute 'feature' and > >> then we will figure out how to hype ourselves all the way to hell". > > > > I don't see why you'd particularly need / want this in C, but the > > argument here seems silly given that you've stressed your affinity to > > other languages that implement closures / anonymous functions. > > My affinity is to language that display *conceptual integrity*. > > > > In any case, implementing closures in C isn't too difficult, and if > > you want to return a function, just return a pointer to it. > > Exactly, I still fail to understand the point of this "feature", > function points have worked fine for ages, but then I never understood > any religion, and that is what Apple seems to be all about. > The blocks aren't interesting at all by themselves, I totally agree with that. However what they do to let you write a function inline, that can be pushed to another function, to be executed on a concurrent FIFO, is where the real power comes out. I'm not 100% sure why the heck they did it this way, which is totally different from any other version of concurrent programming setup I've seen, except maybe that Apple likes to "think different"? I'm not sure I think this stuff is "insanely great" though. I'm planning to try using it before judging it further though. Dave > > Peace > > uriel > > --000e0cd75480af5f740472ae429d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 3, 2009 at 8:15 AM, Uriel <uriel99@gmail.com<= /a>> wrote:
On Wed, Sep 2, 2009 at 4:20 PM, Devon H. O'Dell<devon.odell@gmail.com> wrote:=
> 2009/9/2 Uriel <uriel99@gmail.= com>:
>> On Wed, Sep 2, 2009 at 10:04 AM, Anant Narayanan<anant@kix.in> wrote:
>>> Mac OS 10.6 introduced a new C compiler frontend (clang), whic= h added
>>> support for "blocks" in C [1]. Blocks basically add = closures and anonymous
>>> functions to C (and it's derivatives). Full details with e= xamples are in the
>>> linked article. I think the feature is quite elegant and might= be useful in
>>> cases where you want map/reduce like functionality in C.
>>
>> Er., I might be more dumb than usual, but why on earth would you >> need/want this garbage to get map/reduce functionality in C?
>>
>> To me it seems the typical "lets come up with some cute '= feature' and
>> then we will figure out how to hype ourselves all the way to hell&= quot;.
>
> I don't see why you'd particularly need / want this in C, but = the
> argument here seems silly given that you've stressed your affinity= to
> other languages that implement closures / anonymous functions.

My affinity is to language that display *conceptual integrity*.


> In any case, implementing closures in C isn't too difficult, and i= f
> you want to return a function, just return a pointer to it.

Exactly, I still fail to understand the point of this "feature&q= uot;,
function points have worked fine for ages, but then I never understood
any religion, and that is what Apple seems to be all about.

The blocks aren't interesting at all by themselves= , I totally agree with that. =A0However what they do to let you write a fun= ction inline, that can be pushed to another function, to be executed on a c= oncurrent FIFO, is where the real power comes out.

I'm not 100% sure why the heck they did it this way= , which is totally different from any other version of concurrent programmi= ng setup I've seen, except maybe that Apple likes to "think differ= ent"?

I'm not sure I think this stuff is "insanely g= reat" though. =A0I'm planning to try using it before judging it fu= rther though.

Dave
=A0

Peace

uriel


--000e0cd75480af5f740472ae429d--