From: Bakul Shah <bakul+plan9@bitblocks.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] "Blocks" in C
Date: Wed, 2 Sep 2009 10:51:21 -0700 [thread overview]
Message-ID: <20090902175121.390BA5B3E@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Wed, 02 Sep 2009 08:20:52 PDT." <1251904852.16936.3250.camel@work.SFBay.Sun.COM>
On Wed, 02 Sep 2009 08:20:52 PDT Roman V Shaposhnik <rvs@sun.com> wrote:
> On Wed, 2009-09-02 at 10:04 +0200, 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).
>
> They are NOT closures in my book. They lack lexical scoping. A true
> closure makes the following possible (using JavaScript to stay closer
> to C syntax):
> function outer() {
> var outer_var = 1;
> return function () {
> outer_var = { simply: "a different object" }
> }
> }
>From reading the URL you cited, it seems you can't return a
block from a function but you can sort of achieve the same
effect by declaring a global `block variable' and assigning a
block to it -- now you can use this block var elsewhere.
int (^ugly)();
int outer() {
__block int outer_var = 1;
ugly = ^{ outer_var = 42; }
}
Presumably __block says outer_var is allocated on heap so now
it can live beyond the life of a particular invocation of
outer(). outer_var will have to be freed when ugly is
assigned to a different block. So it seems GC is a
requirement now. The original C features were "just right"
to keep the compiler simple and still provide a lot of
expressive power. IMHO GC doesn't fit that model.
Because of the heap allocation, most likely you won't get a
proper closure. For instance, in Scheme
(define (counter)
(let ((x 0))
(lambda () (set! x (+ x 1)) x)))
(define c1 (counter))
(c1) => 1
(c1) => 2
(define c2 (counter))
(c2) => 1
(c1) => 3
etc.
Thus on every invocation of the counter function you get a
fresh counter x and c1 and c2 increment their own copy of x
independently. With blocks you'd render the above as
something like:
typedef int(^ctr_t)();
int counter(ctr_t*c) {
__block int x = 0;
*c = ^{ return ++x; }
}
ctr_t c1, c2;
void foo()
{
counter(&c1); // presumably taking address of a block var is allowed
printf("%d\n", c1());
printf("%d\n", c1());
counter(&c2);
printf("%d\n", c2());
printf("%d\n", c1());
}
I bet you'd get 1 2 3 4, and not 1 2 1 3. If they do get this
right, they'd have to allocate a fresh x on every invocation
of counter and this will add to the memory garbage. Now their
GC problem is even worse! And I haven't even used
concurrency so far!
They very carefully delineate what you can and can not do
with lexically scoped variables etc. but the model is far
more complex.
> > How much effort would it be to support a feature similar to blocks in
> > 8c (and family)? What are your thoughts on the idea in general?
>
> Personally I think you'd be better off exploring a connection that a
> language called Lua has to C. In the immortal words of Casablanca it
> just could be "the begging of a beautiful friendship".
Amen! Or kill one's prejudice against parens (talk to your
parens!) and use Scheme which is about as simple as it can
get.
next prev parent reply other threads:[~2009-09-02 17:51 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-02 8:04 Anant Narayanan
2009-09-02 9:43 ` Francisco J Ballesteros
2009-09-02 11:00 ` Philippe Anel
2009-09-02 11:13 ` Charles Forsyth
2009-09-03 9:52 ` Greg Comeau
2009-09-02 11:40 ` Eris Discordia
2009-09-02 12:32 ` Uriel
2009-09-02 14:20 ` Devon H. O'Dell
2009-09-03 9:52 ` Greg Comeau
2009-09-03 10:48 ` Akshat Kumar
2009-09-03 11:25 ` Charles Forsyth
2009-09-03 13:59 ` Greg Comeau
2009-09-03 15:15 ` Uriel
2009-09-03 15:44 ` David Leimbach
2009-09-03 16:01 ` Roman V Shaposhnik
2009-09-04 9:15 ` Greg Comeau
2009-09-04 16:49 ` Roman Shaposhnik
2009-09-03 16:02 ` erik quanstrom
2009-09-03 18:56 ` David Leimbach
2009-09-03 18:58 ` erik quanstrom
2009-09-03 19:13 ` David Leimbach
2009-09-03 19:36 ` erik quanstrom
2009-09-03 19:50 ` David Leimbach
2009-09-03 20:30 ` Iruata Souza
2009-09-06 22:35 ` Uriel
2009-09-07 0:41 ` David Leimbach
2009-09-03 21:08 ` Roman V Shaposhnik
2009-09-03 21:35 ` erik quanstrom
2009-09-03 21:45 ` David Leimbach
2009-09-03 21:49 ` David Leimbach
2009-09-03 21:51 ` David Leimbach
2009-09-03 22:36 ` Roman V Shaposhnik
2009-09-04 9:16 ` Greg Comeau
2009-09-03 22:10 ` Daniel Lyons
2009-09-03 22:07 ` Daniel Lyons
2009-09-04 9:15 ` Greg Comeau
2009-09-04 3:21 ` Anant Narayanan
2009-09-04 3:52 ` erik quanstrom
2009-09-04 4:18 ` David Leimbach
2009-09-04 4:44 ` erik quanstrom
2009-09-04 5:31 ` David Leimbach
2009-09-04 5:35 ` David Leimbach
2009-09-04 7:11 ` Bakul Shah
2009-09-04 7:47 ` David Leimbach
2009-09-04 14:41 ` Bakul Shah
2009-09-04 15:04 ` David Leimbach
2009-09-04 15:58 ` Bakul Shah
2009-09-04 12:14 ` erik quanstrom
2009-09-04 13:52 ` David Leimbach
2009-09-04 13:59 ` matt
2009-09-04 14:20 ` erik quanstrom
2009-09-04 14:56 ` David Leimbach
2009-09-06 23:03 ` Uriel
2009-09-07 0:45 ` David Leimbach
2009-09-04 16:50 ` Roman Shaposhnik
2009-09-04 6:45 ` Bakul Shah
2009-09-04 16:44 ` Roman Shaposhnik
2009-09-04 16:58 ` Iruata Souza
2009-09-04 17:09 ` Roman Shaposhnik
2009-09-04 17:42 ` erik quanstrom
2009-09-04 18:34 ` erik quanstrom
2009-09-04 21:54 ` Roman V Shaposhnik
2009-09-07 9:06 ` Greg Comeau
2009-09-07 9:05 ` Greg Comeau
2009-09-07 9:40 ` Uriel
2009-09-08 15:31 ` David Leimbach
2009-09-08 15:44 ` Uriel
2009-09-08 16:40 ` Bakul Shah
2009-09-11 18:15 ` Iruata Souza
2009-09-11 18:46 ` David Leimbach
2009-09-11 20:36 ` Roman V Shaposhnik
2009-09-11 21:28 ` David Leimbach
2009-09-14 16:07 ` Lawrence E. Bakst
2009-09-12 11:08 ` Anant Narayanan
2009-09-13 19:03 ` David Leimbach
2009-09-17 1:54 ` Lawrence E. Bakst
2009-09-17 8:43 ` Charles Forsyth
2009-09-17 9:12 ` Daniel Lyons
2009-09-17 15:56 ` David Leimbach
2009-09-17 17:38 ` Jack Norton
2009-09-17 20:23 ` Anant Narayanan
2009-09-17 20:26 ` erik quanstrom
2009-09-17 20:31 ` Anant Narayanan
2009-09-17 20:47 ` Akshat Kumar
2009-09-17 21:02 ` erik quanstrom
2009-09-17 22:26 ` Steve Simon
2009-09-17 22:32 ` Roman V Shaposhnik
2009-09-18 2:05 ` Daniel Lyons
2009-09-18 9:30 ` Charles Forsyth
2009-09-18 11:41 ` erik quanstrom
2009-09-17 21:03 ` Uriel
2009-09-03 9:52 ` Greg Comeau
2009-09-02 14:08 ` Rodolfo (kix)
2009-09-03 9:52 ` Greg Comeau
[not found] ` <C56117D7BD9A097270529AAE@192.168.1.2>
2009-09-02 15:07 ` David Leimbach
2009-09-02 15:26 ` Roman V Shaposhnik
2009-09-02 15:45 ` David Leimbach
2009-09-03 15:32 ` Uriel
2009-09-03 15:49 ` Roman V Shaposhnik
2009-09-03 15:54 ` erik quanstrom
2009-09-03 16:20 ` Roman V Shaposhnik
2009-09-03 16:44 ` erik quanstrom
2009-09-04 1:05 ` Roman V Shaposhnik
2009-09-04 1:30 ` Russ Cox
2009-09-04 1:32 ` erik quanstrom
2009-09-03 21:54 ` James Tomaschke
2009-09-06 22:26 ` Uriel
2009-09-04 9:04 ` Greg Comeau
2009-09-02 15:20 ` Roman V Shaposhnik
2009-09-02 17:51 ` Bakul Shah [this message]
2009-09-04 1:35 drivers
2009-09-04 1:52 ` erik quanstrom
2009-09-17 9:19 Andrew Simmons
2009-09-17 14:45 ` LiteStar numnums
2009-09-17 17:24 ` Daniel Lyons
2009-09-18 15:50 drivers
2009-09-18 15:56 ` erik quanstrom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090902175121.390BA5B3E@mail.bitblocks.com \
--to=bakul+plan9@bitblocks.com \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).