I've become interested in programming with Objective C and was wondering
if anyone could suggest any good starting points, compilers and IDEs
for either Windows or Linux.
Thanks in advance, Tom

From:	Chris Dutton
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sat, 06 Nov 2004 01:04:53 GMT

Tom wrote:
> I've become interested in programming with Objective C and was wondering
> if anyone could suggest any good starting points, compilers and IDEs
> for either Windows or Linux.

Well, Objective-C, for better or worse, revolves around Apple these
days, and Apple uses GCC plus their own Xcode IDE. Now you can't use
Xcode under Windows or Linux, but you can take a look at the GNUStep tools.

You can probably make it work under Windows, but Linux is probably the
more "natural" of the two platforms for this kind of work.

http://www.gnustep.org/

From:	Noé Falzon
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sun, 07 Nov 2004 16:04:43 +0100

Chris Dutton wrote:

> but you can take a look at the GNUStep tools.

But, isn't GNUStep an API ?
They also provide an IDE ?

Noé
--
"From the age of Big Brother, from the age of the thought police, from a
dead man... greetings" -- George Orwell -- 1984

Veuiller retirer NO SPAM HERE de mon adresse.
Please remove NO SPAM HERE from my address.

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	7 Nov 2004 16:44:32 GMT

In article <418e38ec$0$6054$626a14ce@news.free.fr>,
Noé Falzon wrote:
>Chris Dutton wrote:
>
>> but you can take a look at the GNUStep tools.
>
>But, isn't GNUStep an API ?

GNUStep is an implementation of the OpenStep specification, and generally
following the continued development of those APIs in Cocoa - but it aims
to omplement a complete OpenStep environment, including things like
workspace management, development tools, etc.

>They also provide an IDE ?

As I wrote in a sibling article to this one:

And indeed, on Linux/Unix, GNUStep has its own development tools:

* ProjectCenter as the general development environment

* Gorm for User Interface modelling

>Noé

Best wishes,

// Christian Brunschen

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	6 Nov 2004 11:12:03 GMT

In article ,
Chris Dutton wrote:
>Tom wrote:
>> I've become interested in programming with Objective C and was wondering
>> if anyone could suggest any good starting points, compilers and IDEs
>> for either Windows or Linux.
>
>Well, Objective-C, for better or worse, revolves around Apple these
>days, and Apple uses GCC plus their own Xcode IDE. Now you can't use
>Xcode under Windows or Linux, but you can take a look at the GNUStep tools.
>
>You can probably make it work under Windows, but Linux is probably the
>more "natural" of the two platforms for this kind of work.

Unix in general is a better match for gcc, but that's hardly surprising.
And indeed, on Linux/Unix, GNUStep has its own development tools:

* ProjectCenter as the general development environment

* Gorm for User Interface modelling

On Windows, GNUstep-Base is available for download and working:

and GNUStep-GUI is in progress. Screenshots have been posted, still with
glitches but basically working; see this messge on the gnuste-discuss
mailing list:

>http://www.gnustep.org/

I can only concur: Go to the above URL, and all will be revealed. :)

// Christian Brunschen

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Fri, 05 Nov 2004 19:04:14 GMT

Tom wrote:
> I've become interested in programming with Objective C and was wondering
> if anyone could suggest any good starting points, compilers and IDEs
> for either Windows or Linux.
> Thanks in advance, Tom

There's a package for Linux and MS Windows (Microsoft Visual C) on

http://users.pandora.be/stes/compiler.html

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	6 Nov 2004 12:50:02 GMT

In article ,
David Stes wrote:
>Tom wrote:
>> I've become interested in programming with Objective C and was wondering
>> if anyone could suggest any good starting points, compilers and IDEs
>> for either Windows or Linux.
>> Thanks in advance, Tom
>
>There's a package for Linux and MS Windows (Microsoft Visual C) on
>
> http://users.pandora.be/stes/compiler.html

Unfortunately, the compiler available from that website only implements a
fairly old version of the Objective-C language, missing some important
features like Categories and Protocols.

The Gnu compiler, gcc, with the GNUstep libraries and tools would be a
much better starting point.

Best wishes,

// Christian Brunschen

From:	bazad
Subject:	Re: Compilers and IDEs for Objective C
Date:	06 Nov 2004 11:06:43 -0800

cb@df.lth.se (Christian Brunschen) writes:

> In article ,
> David Stes wrote:
> >
> >There's a package for Linux and MS Windows (Microsoft Visual C) on
> >
> > http://users.pandora.be/stes/compiler.html
>
> Unfortunately, the compiler available from that website only implements a
> fairly old version of the Objective-C language, missing some important
> features like Categories and Protocols.

> The Gnu compiler, gcc, with the GNUstep libraries and tools would be a
> much better starting point.

What about closures support? I think it is a nice feature in
smalltalk. Does gcc support them?

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	6 Nov 2004 20:28:25 GMT

In article <1099768035.S1emWhQZHqTA4fryB/2rQQ@teranews>,
bazad wrote:
>cb@df.lth.se (Christian Brunschen) writes:
>What about closures support? I think it is a nice feature in
>smalltalk. Does gcc support them?

Closures are a feature of Smalltalk, but not a feature of Objective-C. In
general, because C puts its activation records strictly on the stack,
proper closures are almost impossible to support in any C-based language,
such as Objective-C. You'll find for instance that Brad Cox's suggested
'Action Expressions' were explicitly *not* closures: They would receive a
copy of any variables in the scope where they were defined, but they
would not actually be able to referece back to the originals.

POC implements 'Blocks' which _try_ to be closures, but aren't really. But
then again, most of the things for which Smalltalk uses blocks can be
achieved in different, possibly even better, ways without them. The
obvious things like flow control structures are part of the language in
Objective-C, rather than messaes sent booleans or blocks, with forther
blocks as parameters. Iterating over collections can be expressed very
powerfully with higher-order messaging, where the basic building-block of
the Objective-C language - messaging - is leveraged to offer what is
needed in a way which I, frankly, think is more elegant that using blocks
would be.

And when using gcc, you can always declare inner functions within your
methods and pass those around.

Best wishes,

// Christian Brunschen

From:	Michael Ash
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sat, 06 Nov 2004 17:09:00 -0600

Christian Brunschen wrote:
>
> And when using gcc, you can always declare inner functions within your
> methods and pass those around.

I should point out that, while gcc's inner functions can refer to
variables in the enclosing function, it's not very reliable. Specifically,
this is handled by constructing a trampoline on the stack, which requires
an executable stack. I've experienced crashes related to this on Mac OS X,
and in general it seems to be something that you shouldn't use in a
production application. Inner functions that don't refer to variables in
the outer function are fine, but not terribly interesting.

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Thu, 11 Nov 2004 07:57:22 GMT

Christian Brunschen wrote:
>
> Closures are a feature of Smalltalk, but not a feature of Objective-C.

Objective-C adds features of Smalltalk to C.

Blocks are an Objective-C feature (but it is still lacking in the old Apple
implementation, which dates back to 1988 or so, and since then was unchanged).

> 'Action Expressions' were explicitly *not* closures: They would receive a
> copy of any variables in the scope where they were defined, but they
> would not actually be able to referece back to the originals.

Consider the following example:

i = 0;
[someObjects do: { :each | i++; }];
printf("%i\n",i);

What this does is :

it sets 'i' to 0
it iterates over the contents of 'someObjects'
for 'each' member of the collection 'someObjects' it evaluates a Block
the Block is { :each | i++; }
the -do: message takes as argument a Block
the Block increments i++
the final printf() prints out the number of objects in 'someObjects'.

Obviously you want the final printf() to print out the number of
objects in 'someObjects'.

The wrong semantics (that you advocate) is that the printf() would print 0.

This indicates that you have a misunderstanding of what Blocks are, and how
you use them in Objective-C programming.

From:	Glenn Andreas
Subject:	Re: Compilers and IDEs for Objective C
Date:	Thu, 11 Nov 2004 08:19:10 -0600

In article ,
David Stes wrote:

> Christian Brunschen wrote:
> >
> > Closures are a feature of Smalltalk, but not a feature of Objective-C.
>
> Objective-C adds features of Smalltalk to C.
>
> Blocks are an Objective-C feature (but it is still lacking in the old Apple
> implementation, which dates back to 1988 or so, and since then was unchanged).
>

You mean besides adding categories, exceptions, etc... which have not
yet been implemented in POC.

> > 'Action Expressions' were explicitly *not* closures: They would receive a
> > copy of any variables in the scope where they were defined, but they
> > would not actually be able to referece back to the originals.
>
> Consider the following example:
>
> i = 0;
> [someObjects do: { :each | i++; }];
> printf("%i\n",i);
>
> What this does is :
>
> it sets 'i' to 0
> it iterates over the contents of 'someObjects'
> for 'each' member of the collection 'someObjects' it evaluates a Block
> the Block is { :each | i++; }
> the -do: message takes as argument a Block
> the Block increments i++
> the final printf() prints out the number of objects in 'someObjects'.
>
> Obviously you want the final printf() to print out the number of
> objects in 'someObjects'.
>
> The wrong semantics (that you advocate) is that the printf() would print 0.
>
> This indicates that you have a misunderstanding of what Blocks are, and how
> you use them in Objective-C programming.
>

So are you stating that POC-Blocks are closures? Because if you are,
then you have a misunderstanding of what a closure is.

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Thu, 11 Nov 2004 17:28:59 GMT

Glenn Andreas wrote:
>>
>> i = 0;
>> [someObjects do: { :each | i++; }];
>> printf("%i\n",i);
>>
>> The wrong semantics (that you advocate) is that the printf() would print 0.
>
> So are you stating that POC-Blocks are closures?

I'm stating that the above code should print the number of objects
in "someObjects", and not 0, if the "someObjects" collection is non-empty.

In other words, obviously the Block must have the enclosing locals in scope.
It does this by copying the enclosing frame into the Block, as opposed to
referencing the stack. The enclosing frame is modified to reference the copy
that was copied into the Block, of course.

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	13 Nov 2004 21:19:54 GMT

In article ,
David Stes wrote:
>Christian Brunschen wrote:
>>
>> Closures are a feature of Smalltalk, but not a feature of Objective-C.
>
>Objective-C adds features of Smalltalk to C.

Objective-C adds *some* *selected* features from Smalltalk, to C -
specifically, the object model with messaging between objects.

>Blocks are an Objective-C feature

No, they are not. Neither PPI/Stepstone nor NeXT/Apple have ever released
a compiler that includes such a feature - and PPIStepstone and NeXT/Apple
are the only authoritative sources for the Objective-C language. Only
Devid Stes' own 'POC' implements 'Blocks' as he suggests them.

>(but it is still lacking in the old Apple
>implementation, which dates back to 1988 or so, and since then was unchanged).

Apple's implementation - which, these days, is the authoritative reference
implementation - has, since 1988, gained a number of things - like
Categories, Protcols, optional static typing, exceptions, etc. *All* of
these features are missing from POC. While I haven't personally verified
this, I believe that Metrowerks' CodeWarrior and IBM's XLC, both of which
also offer Objective-C support, also follow the features in the language
as defined by Apple.

>> 'Action Expressions' were explicitly *not* closures: They would receive a
>> copy of any variables in the scope where they were defined, but they
>> would not actually be able to referece back to the originals.
>
>Consider the following example:
>
> i = 0;
> [someObjects do: { :each | i++; }];
> printf("%i\n",i);
>
>What this does is :
>
> it sets 'i' to 0
> it iterates over the contents of 'someObjects'
> for 'each' member of the collection 'someObjects' it evaluates a Block
> the Block is { :each | i++; }
> the -do: message takes as argument a Block
> the Block increments i++
> the final printf() prints out the number of objects in 'someObjects'.
>
>Obviously you want the final printf() to print out the number of
>objects in 'someObjects'.

This is 'obvious' only because the code is written to expect that
behaviour. Using code that expects a certain behaviour as a justification
for that behaviour is a circular argument.

>The wrong semantics (that you advocate) is that the printf() would print 0.

Oh, I am not *advicating* any particular semantics. I am simply pointing
out that the closest thing to having a Block-like facility in Objective-C
was when Brad Cox suggested 'Action Expressions' in his Task Master paper
- but that Action Expressions have semantics which explicitly and
specifically *differ* in this respect, in particular that Action
Expressions were explicitly *not* closures.

>This indicates that you have a misunderstanding of what Blocks are, and how
>you use them in Objective-C programming.

I am perfectly familiar with closures in different languages, including
Smalltalk. However, David Stes' apparent failure to differentiate between
the semantics of Action Expressions and those of Blocks, only speaks for
his own understanding of the matter.

Best wishes,

// Christian Brunschen

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sun, 14 Nov 2004 12:16:20 GMT

Christian Brunschen wrote:
>
>>> 'Action Expressions' were explicitly *not* closures: They would receive a
>>> copy of any variables in the scope where they were defined, but they
>>> would not actually be able to referece back to the originals.

But this is precisely the difference with "inner functions".

"inner functions" refer to the variables on the stack from the calling function.

A Block (or Action Expression) has its copy of these variables and it is doing
exactly the opposite of inner functions : the calling function is modified to
reference the copy that is copied into the Block, and that exists as long as
the Block object exists. Instead of referencing the frame on the stack, the
calling function is referencing the copy in the Block or Action Expression.

This means that Blocks, unlike inner functions, can function even if the
calling or creating function has exited.

>>Consider the following example:
>>
>> i = 0;
>> [someObjects do: { :each | i++; }];
>> printf("%i\n",i);
>
>>The wrong semantics (that you advocate) is that the printf() would print 0.
>
> Oh, I am not *advicating* any particular semantics.

If "someObjects" is non-empty, what would you want the printf() to print ?

I am sure that people who use Blocks or inner functions will agree that the
above example should print the number of objects in the collection.

The "inner function" mechanism would achieve this by referencing the local
"i" on the stack;

A "Block" achieves the same thing by having it own storage space (copy) for
the variable "i" and the calling function is modified to reference that copy.

From:	Glenn Andreas
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sun, 14 Nov 2004 09:04:16 -0600

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sun, 14 Nov 2004 16:40:25 GMT

Glenn Andreas wrote:
>
> Were blocks true closures, this would work. They aren't - they are
> "partial" closures which give the illusion of being closures

You have completely failed to understand the "hybrid" nature of Objective-C.

You think Objective-C is not "fully" object-oriented because not everything
is an object in objc. Objective-C uses objects and classes as an encapsulation
technology to be used in conjuction with traditional C technology.

By your (false) argument, you would claim that Objective-C does not have "true"
instance variables.

Objective-C has, according to you, probably instance variables that give you
the illusion of being instance variables, while not being "true" instance vars
and only "partial" instance variables.

If you have an instance variable "myIvar" and you set it to "p" a pointer,
you have a potentially dangling reference, yes.

That doesn't change anything about Objective-C having instance variables,
and even class variables in some of the more powerful recent implementations.

From:	Glenn Andreas
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sun, 14 Nov 2004 11:11:07 -0600

In article ,
David Stes wrote:

> Glenn Andreas wrote:
> >
> > Were blocks true closures, this would work. They aren't - they are
> > "partial" closures which give the illusion of being closures
>
> You have completely failed to understand the "hybrid" nature of Objective-C.

You have completely failed to read and understand the post.

> You think Objective-C is not "fully" object-oriented because not everything
> is an object in objc. Objective-C uses objects and classes as an
> encapsulation
> technology to be used in conjuction with traditional C technology.

I most certainly said nothing like that - my entire point was that
Blocks are _not_ closures (and gave examples why they aren't), and it is
nearly impossible for them to be closures, given the underlying C base.

Perhaps you do not understand the term "closure"?

>
> By your (false) argument, you would claim that Objective-C does not have
> "true"
> instance variables.

I did not, nor would I.

> Objective-C has, according to you, probably instance variables that give you
> the illusion of being instance variables, while not being "true" instance
> vars
> and only "partial" instance variables.

I never said anything like that, please stop trying to claim I've said
stuff that I haven't.

The bottom line is that Blocks are _not_ closures, and you shouldn't
attempt to treat them as such because there will be bugs that you will
encounter into if you do.

Blocks do encapsulate the portions of immediate stack frame, but that
does not make them closures.

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sun, 14 Nov 2004 19:52:16 GMT

Glenn Andreas wrote:
>
> it is nearly impossible for them to be closures, given the underlying C base.

This is exactly the "Objective-C is not fully object-oriented" argument.

You incorrectly use the terms "full" and "partial", because of lack of
understanding on what role classes, messaging and Blocks play in Objective-C.

Yes, you have discovered that not everything is an instance in Objective-C.

It seems to be something new for you.

You have discovered that there is something like "char *" in Objective-C,
and that not everything is a String.

In the following example, you can write:

- foo:(char *)x
{
foo = x;
return self;
}

Does this imply, following your logic, that "foo" is only a "partial" instance
variable ?

Is it not "fully" object-oriented, because it holds a (potentially) void
reference to a character string ?

From:	Glenn Andreas
Subject:	Re: Compilers and IDEs for Objective C
Date:	Sun, 14 Nov 2004 16:05:20 -0600

In article ,
David Stes wrote:

> Glenn Andreas wrote:
> >
> > it is nearly impossible for them to be closures, given the underlying C
> > base.
>
> This is exactly the "Objective-C is not fully object-oriented" argument.
>

No, it's entirely about Blocks not being closures, not about anything
else. They aren't, and for a number of reasons (and not just the
underlying C implementation issues, though that's the easiest to
demonstrate, though there are also issues with recursively calling a
Block as well), it would be difficult to implement them to be true
closures (early versions of Smalltalk blocks weren't true closures
either if that will make you feel any better).

So either you agree about Blocks not being closures and you're either
inventing arguments where they don't exist, or your still think that
Blocks are closures.

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Mon, 15 Nov 2004 07:26:14 GMT

Glenn Andreas wrote:
>
> though there are also issues with recursively calling a Block as well

Blocks can use other Blocks.

d = [OrdCltn with:3,a,b,c];
e = [OrdCltn with:3,d,d,d]

i = 0;
[e do: { :each | [each do: { :s | i++; }]; };
printf("%i\n",i);

If you have a collection of collections, say, as the above 'e' object,
it will print out 3 x 3 = 9 .

The entire point is here that (i) obviously the inner Block must be able
to reference the frame of the enclosing (outer) Block and from the calling
function and (ii) it does this not by referencing (like an inner function
would) but by *COPYING* the enclosing frame into heap-allocated memory in
the Block. This is exactly the point that Christian keeps bringing up all
the time from the Action Expression paper, but which he fails to understand.

He keeps repeating, you have to make a *COPY* of the frame, and this is exactly
what BLOCKS do (as opposed to inner functions).

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	15 Nov 2004 14:13:45 GMT

From:	Glenn Andreas
Subject:	Re: Compilers and IDEs for Objective C
Date:	Mon, 15 Nov 2004 09:12:26 -0600

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	15 Nov 2004 12:41:02 GMT

In article ,
David Stes wrote:
>Glenn Andreas wrote:
>>
>> though there are also issues with recursively calling a Block as well
>
> Blocks can use other Blocks.
>
> d = [OrdCltn with:3,a,b,c];
> e = [OrdCltn with:3,d,d,d]
>
> i = 0;
> [e do: { :each | [each do: { :s | i++; }]; };
> printf("%i\n",i);
>
> If you have a collection of collections, say, as the above 'e' object,
>it will print out 3 x 3 = 9 .
>
> The entire point is here that (i) obviously the inner Block must be able
>to reference the frame of the enclosing (outer) Block and from the calling
>function and (ii) it does this not by referencing (like an inner function
>would) but by *COPYING* the enclosing frame into heap-allocated memory in
>the Block. This is exactly the point that Christian keeps bringing up all
>the time from the Action Expression paper, but which he fails to understand.
>
>He keeps repeating, you have to make a *COPY* of the frame,

I am actually saying no such thing. All I have done is pointed out

a) what Action Expressions do
b) what POC-Blocks do
c) the differences between them and the semantics they offer

>and this is exactly
>what BLOCKS do (as opposed to inner functions).

There are in fact *four* different sets of semantics here in this
discussion:

1) 'inner function' semantics
An 'inner function' simply references any variables that are lexically
declared in an enclosing scope. Thus, if the enclosing scope goes away
(such as, if a pointer to an inner function has been stored somewhere and
it being invoked after its declaring function has exited), interesting
errors happen because the inner function's references to the stack will
identify data that isn't what it expects it to be.

2) 'Action Expression' semantics
An 'Action Expression' receives its own copy of any variables that it
references that live in a lexically enclosing scope and that might go
away, such as stack-allocated variables. This copy is initialised with
whatever the value of the original stack-allocated variable is at the time
that the Action Expression is created, but after that the two have no
connection whatsoever. In particular, any assignments done within the
Action Expression will only affect the Action Expression's local copy, and
*not* the original.

3) POC Block semantics
A POC Block attempts to offer a limited form of closure. Any references to
variables on the stack are problematic, since those will go away with the
stack frame in question. Thus, POC *moves* any such variables from the
stack into the heap, and *all* references to those variables now have to
go through pointers to the variables' new location on the heap; this
includes references from the declaring lexical scope. POC uses reference
counting to ensure that these heap-moved variables stay around as long as
either the declaring scope or any of the Blocks created in it are still
alive. The variables on the heap are initialised at the same time they
would have been if they had still been on the stack. Because the BLock(s)
and the declaring scope all share the same variable on the heap through
their pointer(s) to it, any change made to the variable is visible to all
its users. This, however, only covers the static lexical environment, and
not the full dynamic environment in which Blocks are created.

4) 'Full Closure' semantics
In a Full Closure setting, the Closure can reference not just the static
environment in which it was declared, but the entire *dynamic* environment
in which it was created; so, not only of the function or method where the
Closure was declared and created, but also of the function or method that
*invoked* that function or method, and so on. This can be vital to ensure
the correct operation, as Glenn Andreas demonstrated in this very thread,
in .

Now, to contrast the difference between POC Block semantics and Action
Expression semantics - and let's make this *really* simple. If what POC's
Blocks do is exactly the same as what Action Expressions do, then they
should behave identically, correct? Let'sput this to a simple test. First,
let's refresh our memory of the semantics of POC's Blocks and of Action
expressions, respectively.

David Stes writes about Blocks and their semantics:

Consider the following example:

i = 0;
[someObjects do: { :each | i++; }];
printf("%i\n",i);

What this does is :

it sets 'i' to 0
it iterates over the contents of 'someObjects'
for 'each' member of the collection 'someObjects' it evaluates a Block
the Block is { :each | i++; }
the -do: message takes as argument a Block
the Block increments i++
the final printf() prints out the number of objects in 'someObjects'.

Obviously you want the final printf() to print out the number of
objects in 'someObjects'.

The wrong semantics (that you advocate) is that the printf() would print
0.

In other words, obviously the Block must have the enclosing locals in
scope. It does this by copying the enclosing frame into the Block, as
opposed to referencing the stack. The enclosing frame is modified to
reference the copy that was copied into the Block, of course.

Brad Cox writes about Action Expressions and their semantics:

Objective-C actions have a key restriction that is not present with
Smalltalk blocks. The code inside a action accesses copies of the
variables that it references in the enclosing scope. These copies are made
when the action is instantiated, not when it is invoked, as is the case
with Smalltalk Blocks. The copies are stored as indexed instance variables
inside the Action object and not in the enclosing scope (foo's stack
frame).

When the underlying C function is invoked, these variables are exported to
the function via a structure pointer, as can be seen in the following
example. For example, the aGlobal, aFormal, and aLocal variables in this
example are copied when the action is created (i.e. just before bar is
called), not when the deferred computation is invoked (inside bar).
Objective-C action expressions do not share memory with their enclosing
scope, they cannot export changes to the enclosing scope as in Smalltalk.
Changes to action variables is ineffective, since the change affects a
copy, not the original.

Now let's look at a short snippet of code, and see how it behaves if it
matches the semantics as described by the respective quotes above:

{
int i = 1;
id foo = { i++; printf("i = %d\n", i); };
[foo value];
printf("i = %d\n", i);
}

According to the semantics that David Stes describes, this should print
i = 2;
i = 2;

However, according to the semantics Brad Cox describes, this should print
i = 2;
i = 1;
because 'Objective-C action expressions do not share memory with their
enclosing scope, they cannot export changes to the enclosing scope as in
Smalltalk. Changes to the action variables is[sic] ineffective, since the
change affects a copy, not the original'.

The above clearly demonstrates that POC-Blocks and Action Expressions
behave differently. Thus, what POC does with Block is *not* 'exactly the
same' as what Brad Cox describes that Action Expressions do in the Task
Master paper.

So in summary:

1) Inner functions reference the stack, and are thus explicitly useless
outside their lexically enclosing function if they reference anything on
the stack. However they perform as designed as long as you keep the
necessary stack fram in scope.

2) Action Expressions can be passed around freely, regardless of what the
stack underneath them does, because they carry with them each their own
local variable, which was initialized at the time of the Action
Expression's creation, but is otherwise completely separate. They do *not*
claim to implement closures, and as such are not expected to act like
them.

3) POC Blocks *try* and even *claim* to implement closure semantics, but
only close over the enclosing lexical scope, and thus actually *fail* to
do what they claim to do

4) Full closures of course do it all, properly, in languages like
Smalltalk - but are inherently assentially impossible to do in a C-based
language such as Objective-C. Smalltalk keeps its activation records in
the heap and not on the stack, so it can keep any of them around as needed
to satisfy the requirements of any Blocks.

And we *still* come back to the point that POC's Blocks are *not* a
feature of the Objective-C language, but only an *incompatible*,
experimental extension of the POC compiler.

Best wishes,

// Christian Brunschen

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	15 Nov 2004 11:26:46 GMT

In article ,
David Stes wrote:
>Christian Brunschen wrote:
>>
>>>> 'Action Expressions' were explicitly *not* closures: They would receive a
>>>> copy of any variables in the scope where they were defined, but they
>>>> would not actually be able to referece back to the originals.
>
>But this is precisely the difference with "inner functions".
>
>"inner functions" refer to the variables on the stack from the calling
>function.
>
>A Block (or Action Expression) has its copy of these variables and it is doing
>exactly the opposite of inner functions : the calling function is modified to
>reference the copy that is copied into the Block, and that exists as long as
>the Block object exists. Instead of referencing the frame on the stack, the
>calling function is referencing the copy in the Block or Action Expression.

There is a disctinct and vital importance between Brad Cox's Action
Expressions, and David Stes' POC-Blocks:

Action Expressions do receive a *copy* of any variable that they reference
that is allocated on the stack. Changing such a variable inside an Action
Expression only affects the Action Expressions copy, not the original
variable.

POC-Blocks, however, *change* any stack-allocated variables into
*heap*-allocated ones, and the Block gets a *reference* to them; and the
original declaring scope is changed to also access that variable through
a reference. Thus, changing the variable will always modify it in a shared
location, so that the Block and anything else that reference it will see
the same value.

Consider the code snippet:

{
int i = 1;
id foo = { i++; printf("inside: i = %d\n", i); };
[foo value];
printf("outside: i = %d\n", i);
}

If 'foo' is an _Action Expression_, that will print

inside: i = 2
outside: i = 1

whereas if 'foo' is a POC-Block, that will print

inside: i = 2
outside: i = 2

Yes, POC-Blocks exhibit a behaviour that in this respect is liek that of
Smalltalk BLocks or even actual proper closures, but Action Expressions
explicitly *do not* exhibit that behaviour, according to Brad Cox's 'Task
Master' paper.

>This means that Blocks, unlike inner functions, can function even if the
>calling or creating function has exited.

Action Expressions, too, function after the enclosing function has
terminated. They just exhibit different semantics.

>>>Consider the following example:
>>>
>>> i = 0;
>>> [someObjects do: { :each | i++; }];
>>> printf("%i\n",i);
>>
>>>The wrong semantics (that you advocate) is that the printf() would print 0.
>>
>> Oh, I am not *advicating* any particular semantics.
>
>If "someObjects" is non-empty, what would you want the printf() to print ?

According to the Action Expression semantics, the above would print '0'.

Just to say this clearly again: I am not *advocating* any particular
semantics. I am simply pointing out that the semantics that POC exhibits
are *not* the same as the semantics proposed by Brad Cox; that the
semantics indeed differ in important and significant ways. And I believe
this has now been quite clearly demonstrated.

>I am sure that people who use Blocks or inner functions will agree that the
>above example should print the number of objects in the collection.

It is one option, but it is not the only valid one by any means. The
semantics exhibited by Action Expressions are also valid. And as long as
the semantics are well-defined and well-known, then the above code-snippet
could simply be used as an example of what *not* to do.

>The "inner function" mechanism would achieve this by referencing the local
>"i" on the stack;

>A "Block" achieves the same thing by having it own storage space (copy) for
>the variable "i" and the calling function is modified to reference that copy.

A POC-Block does not get its own copy, and David Stes should know that -
after all, he wrote POC. The existance of a POC-Block means that the
original variable is moved from the stack onto the heap, and _that_
variable is then referenced both by the function that originally declared
the variable on the stack, and by any POC-Blocks referencing it. This
'copy' is made not when the POC-Block is created, but when the original
stack-allocated variable would have been allocated on the stack. There
will, in other words, be one 'copy' for each invocation of the declaring
scope in question.

With an Action Expression, however, it is each *Action Expression* that
gets its own copy, and that copy is made at the time of creation of the
Action Expression - the original stack-allocated variable remains
untouched, still allocated on the stack. There will end up being as many
copies of that stack-allocated variable, as actual Action Expressions get
created that lexically reference the variable in question.

One may wonder why one would choose the apparently less powerful semantics
of Action Expressions over those of POC-Blocks? After all, being able to
update variables declared outside the Block / ActionExpression in such a
way that updates will propagate to the declaring scope of that variable,
is a useful thing.

I beleive the answer lies in the cost, complexity and other consequences
of implementing those semantics.

The Action Expression semantics are very simple and straightforward to
implement: When an Action Expression is created, it simply gets its own
local variables declared to match the ones it references, and the values
at the time of the Action Expression's creation are copied in. The Action
Expression then continues on its merry way. There is very little overhead
in the creation of the Action Expression, and no code other than the
Action Expression itself it touched.

As has been explained, the declaration of a POC-Block in a function means
that any stack-allocated variables are moved onto the heap, and any
references to them (whether from the declaring scope or from the Block)
*have* to go through pointers. This means that by simply declaring a
POC-Block inside a function, a lot of code *outside* the POC-Block itself
will get rewritten - and it will be written in such a way that it becomes
*slower*, _even if the POC-Block is never actually allocated_. In other
words, quite a lot of overhead, and code gets affected that one wouldn't
at first glance _expect_ to be affected.

Action Expressions are a very much more light-weight construct, which
meshes well into the existing infrastructure of the Objective-C
programming languages; POC-Blocks are much more heavy-weight, and they
alter the semantics and performance of code that doesn't appear to be
touched in and of itself.

Either way, the main point remains: Blocks as implemented by POC have
never been a feature of the Objective-C language. And while POC-Blocks are
in many ways similar to Action Expressions as described in the Task Master
paper, they are also in some important respects _different_, and thus are
*not* the same thing.

Best wishes,

// Christian Brunschen

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Mon, 15 Nov 2004 17:02:56 GMT

Christian Brunschen wrote:
>
> Yes, POC-Blocks exhibit a behaviour that in this respect is like that of
> Smalltalk BLocks or even actual proper closures

This is what I was saying.

Actually Objective-C Blocks are definitely rather powerful, compared to
Blocks in e.g. SELF where they are more limited.

The semantics of Objective-C Blocks are definitely something that somebody
who works with modern Smalltalk, can live with.

> A POC-Block does not get its own copy, and David Stes should know that -
> after all, he wrote POC.

The situation is not so different from "instance variables".

You write something like:

myIvar = somevalue;

but this is actually translated by the precompiler to a by-reference assignment.

So what actually "looks" like a simple local variable (myIvar) is in fact a
reference to heap allocated memory.

The same is true for variables being used by Blocks: they look like simple
local variables, but they are in fact references to a copy that is managed by
the Block class (Block instance).

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	15 Nov 2004 19:35:13 GMT

In article <4j5md.24081$ee5.1276037@phobos.telenet-ops.be>,
David Stes wrote:
>Christian Brunschen wrote:
>>
>> Yes, POC-Blocks exhibit a behaviour that in this respect is like that of
>> Smalltalk BLocks or even actual proper closures
>
>This is what I was saying.

Except that David Stes fails to listen to the *differences* between POC's
Blocks and actual full closures.

>Actually Objective-C Blocks are definitely rather powerful, compared to
>Blocks in e.g. SELF where they are more limited.

but they are still not full closures, and as the example from Glen Andreas
gives an example of, there are simple situations where using POC's Blocks
will trivially break, precisely because they are not full closures.

>The semantics of Objective-C Blocks are definitely something that somebody
>who works with modern Smalltalk, can live with.

Smalltalk needs blocks for its basic control structures; Objective-C
doesn't. Smalltalk's blocks are full closures; POC-Blocks aren't. those
are just some of the differences.

Everything that one can do with Blocks in Smalltalk can be done in
another way without using Blocks in Objective-C. For instance, iterating
over collections can be done using higher-order messaging, which leverages
the power messaging mechanism that Objective-C has (and shares with
Smalltalk).

>> A POC-Block does not get its own copy, and David Stes should know that -
>> after all, he wrote POC.
>
>The situation is not so different from "instance variables".

There are some significant differences, which David Stes conveniently
overlooks.

>You write something like:
>
> myIvar = somevalue;
>
>but this is actually translated by the precompiler to a by-reference
>assignment.

However, instance variables are only referenced like that inside of
Objective-C methods, where the object that the method is invoked on is
already explicitly treated in a special way. Also, other variables inside
a method are treated just as they always have been in C. POC's Blocks
require the modification of variables referenced by a POC-Block even if
the code is an otherwise completely normal C function, so POC-Blocks
require messing with xcode that arguably should be left untouched. So
while there is a similarity, there are also clear and important
differences.

>So what actually "looks" like a simple local variable (myIvar) is in fact a
>reference to heap allocated memory.

This is the case specifically for instance variables, yes - but POC-Blocks
require that other variables which by rights should be on the stack, get
moved off the stack onto the heap.

>The same is true for variables being used by Blocks: they look like simple
>local variables, but they are in fact references to a copy that is managed by
>the Block class (Block instance).

One big difference is that instance variables are declared in a way that
makes it explicit that they are being treated differently from normal
stack-allocated variables - after all, instance variables are declared as
part of the declaraion of the class. However, POC-Blocks affect how
varaibles are allocated that are _not_, at the site of their declaration,
in any way indicated to be special: they are affected by the POC-Block
which is declared somewhere else entirely, and even then they're not
explicitly mentioned as being in any way special.

But, as usual, with all David Stes' trying to focus on a few things aside
from the main issue, it all comes back to one thing: Blocks, as
implemented by POC, are not now and never have been a feature of the
Objective-C language. The closest thing to Blocks that came from an
authoritative source for Objective-C were Brad Cox's Action Expressions,
but those exhibit different semantics from POC-Blocks, and even Action
Expressions never made it into the language outside of Brad Cox's
research.

Best wishes,

// Christian Brunschen

From:	bazad
Subject:	Re: Compilers and IDEs for Objective C
Date:	18 Nov 2004 09:36:56 -0800

cb@df.lth.se (Christian Brunschen) writes:

> Everything that one can do with Blocks in Smalltalk can be done in
> another way without using Blocks in Objective-C. For instance, iterating
> over collections can be done using higher-order messaging, which leverages
> the power messaging mechanism that Objective-C has (and shares with
> Smalltalk).

What does "iterating over collection can be done using higher-order
messaging" mean?

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	18 Nov 2004 18:34:47 GMT

In article <1100799381.sJG+DGU5kFjOrb82bcUDEQ@teranews>,
bazad wrote:
>cb@df.lth.se (Christian Brunschen) writes:
>
>> Everything that one can do with Blocks in Smalltalk can be done in
>> another way without using Blocks in Objective-C. For instance, iterating
>> over collections can be done using higher-order messaging, which leverages
>> the power messaging mechanism that Objective-C has (and shares with
>> Smalltalk).
>
>What does "iterating over collection can be done using higher-order
>messaging" mean?

It means, 'If you want to iterate over a collection, you can use
Higher-Order Messaging to do that'.

To learn more about Higher-Order Messaging, You can take a look at
, with a nice presentation at
, and there's an
article at MacDevCenter at
.

Best wishes,

// Christian Brunschen

From:	Glenn Andreas
Subject:	Re: Compilers and IDEs for Objective C
Date:	Mon, 15 Nov 2004 13:11:32 -0600

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Mon, 15 Nov 2004 20:18:07 GMT

Glenn Andreas wrote:
>
> SELF blocks are more powerful than POC Blocks...

I disagree.

In Objective-C, Blocks do not need to be evaluated in LIFO order.

From:	Glenn Andreas
Subject:	Re: Compilers and IDEs for Objective C
Date:	Mon, 15 Nov 2004 15:20:02 -0600

In article <3a8md.24529$nb3.1215545@phobos.telenet-ops.be>,
David Stes wrote:

> Glenn Andreas wrote:
> >
> > SELF blocks are more powerful than POC Blocks...
>
> I disagree.
>
> In Objective-C, Blocks do not need to be evaluated in LIFO order.
>

Can you explain what you mean by this? Perhaps an example?

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	16 Nov 2004 11:40:49 GMT

In article ,
Glenn Andreas wrote:
>In article <3a8md.24529$nb3.1215545@phobos.telenet-ops.be>,
> David Stes wrote:
>
>> Glenn Andreas wrote:
>> >
>> > SELF blocks are more powerful than POC Blocks...
>>
>> I disagree.
>>
>> In Objective-C, Blocks do not need to be evaluated in LIFO order.
>>
>
>Can you explain what you mean by this? Perhaps an example?

In Self, Activation objects are, just as C's activation records, handled
in strict LIFO (Last-In, First-Out) order. Blocks in Self can not be used
after the Activation in which they were created has gone away.

In other words, you can't, in Self, have a method that creates a Block and
returns it - the Block can't be executed outside the method that created
it, and that is gone once the method returns.

This is well-documented in, for instance, the Self Programmer's Reference
Manual,
,
section 2.1.7 on page 6.

However, this shows us another important things: Self manages fine
*without* passing Blocks outside the scope where the Block is created.
This matches very nicely with what we already know in Objective-C, which
*also* does fine without such Blocks.

Best wishes,

// Christian Brunschen

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Tue, 23 Nov 2004 17:06:20 GMT

Christian Brunschen wrote:
>
> In other words, you can't, in Self, have a method that creates a Block and
> returns it - the Block can't be executed outside the method that created
> it, and that is gone once the method returns.

With Objective-C Blocks, this is of course possible.

I would not dare to claim that Objective-C Blocks are as powerful as Smalltalk
Blocks, just as Objective-C messaging has some limitations compared to
Smalltalk messages, but Objective-C Blocks are pretty powerful.

I'm sure that any Smalltalk programmer who wants to use C, and therefore
investigates Objective-C, as a Smalltalk "on top of C", will love ObjC Blocks.

Objective-C Blocks allow Objective-C programmers to deal with "compound
statements" (the stuff between curly braces) as if they are Objective-C
instances (of class Block), and this supports the usual -do:, -keysDo: etc
messages.

> However, this shows us another important things: Self manages fine
> *without* passing Blocks outside the scope where the Block is created.
> This matches very nicely with what we already know in Objective-C, which
> *also* does fine without such Blocks.

Any innovation will be opposed by people who want to stick with the old order.

It's not because other implementations are stuck in 1987, that Objective-C as
a whole should remain deprived of Blocks.

POC is continuously improved with new Objective-C features, in the spirit of
Smalltalk.

From:	James Weatherley
Subject:	Re: Compilers and IDEs for Objective C
Date:	Wed, 24 Nov 2004 09:24:55 -0000

In article ,
stes@D5E02B1D.kabel.telenet.be says...
> Any innovation will be opposed by people who want to stick with the old order.
>

Speaking from personal experience there?

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Wed, 24 Nov 2004 19:43:51 GMT

James Weatherley wrote:
> In article ,
> stes@D5E02B1D.kabel.telenet.be says...
>> Any innovation will be opposed by people who want to stick with the old order.
>
> Speaking from personal experience there?

Some C programmers, when they see Objective-C messaging, seem to be afraid of
this innovation of messaging.

Now, some Objective-C programmers, when they see Objective-C Blocks, which
is a relatively new feature, added in 1998 for the first time (in POC), some
Objective-C programmers react to this innovation (modelled after Smalltalk)
in the same way.

Yes, there will always be conservatives, and there are innovators.

On the one hand you have the old and lousy Apple Objective-C implementation,
which is like the dinosaurus of the Objective-C world.

To these prehistoric Objective-C users, Objective-C blocks with the -do:
message and advanced features such as turning compound statements into
instances of a class, seems radical and so innovative that they do not
understand it ...

From:	Christian Brunschen
Subject:	Re: Compilers and IDEs for Objective C
Date:	24 Nov 2004 22:42:10 GMT

In article ,
David Stes wrote:
>James Weatherley wrote:
>> In article ,
>> stes@D5E02B1D.kabel.telenet.be says...
>>> Any innovation will be opposed by people who want to stick with the
>old order.
>>
>> Speaking from personal experience there?
>
>Some C programmers, when they see Objective-C messaging, seem to be afraid of
>this innovation of messaging.
>
>Now, some Objective-C programmers, when they see Objective-C Blocks, which
>is a relatively new feature, added in 1998 for the first time (in POC), some
>Objective-C programmers react to this innovation (modelled after Smalltalk)
>in the same way.

Of course, some other Objective-C programmers have seen that there are
other even better ways to achieve most of the things that Blocks might be
used for; ways which leverage existing langiage infrastructure and fit
well within the established framework of the language. Ways like
Higher-Order Messaging, or the creation of protocols and classes that
implement those protocols, etc.

>Yes, there will always be conservatives, and there are innovators.

True. However the irony is that David Stes considers himself to be an
'innovator' in this context, when in fact he is not only conservative but
borders on being a luddite.

>On the one hand you have the old and lousy Apple Objective-C implementation,
>which is like the dinosaurus of the Objective-C world.

'old'? The gcc Objective-C compiler is being actively developed and
improved; fairly recently, support for Objective-C exceptions and
synchronization were added. NeXT/Apple have continuously been updating and
improving not just the compiler, but also the Objective-C language itself.

Of course, David Stes' complaints might be more reasonable if his own POC
was not itself an example of an 'old, lousy' compiler. For instance, POC
*still* doesn't implement Categories or Protocols, both of which have been
part of the Objective-C language for *years*. And the 'advanced' features
that POC implements - i.e., the incompaticle POC-specific extensions - are
done badly: POC's Blocks try to be closures and fail, POC's Block-based
attempt at exception handling doesn't implement exception handling
semantics correctly, its 'inline cache' (for speeding up message lookups
when the receiver's class remains the same between message-sends) is
not thread-safe ... the list goes on and on. Frankly, David Stes is not in
a position to make claims about other compilersare in any way 'old' or
'lousy', especially in comparison with his own POC.

>To these prehistoric Objective-C users, Objective-C blocks with the -do:
>message and advanced features such as turning compound statements into
>instances of a class, seems radical and so innovative that they do not
>understand it ...

The opposite is true, in fact. Those Objective-C developers who reject
Blocks generally do so knowing fully well what Blocks are, how they could
be used, and what other ways of achieving the same effects there are - and
deciding on the basis of that knowledge that Blocks don't offer sufficient
advantages over the other tools thay already have in their toolchest.

Also, Blocks are not 'radical' in any way, shape or form. Blocks have been
around in Smalltalk for absolute ages, and of course anonymous functions
(lambda expressions) have been in LISP for even longer; they are a
construct that is well-known, tried and tested - and in the context of
Objective-C, in the presence of other constructs, they simply don't offer
any compelling reason for inclusion, in particular in light of the
difficulties of getting closures to work in *any* C-based language in the
first place.

Best wishes,

// Christian Brunschen

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Thu, 25 Nov 2004 22:10:49 GMT

Christian Brunschen wrote:
>
> The opposite is true, in fact. Those Objective-C developers who reject
> Blocks generally do so knowing fully well what Blocks are.

The discussion on Self Blocks and Objective-C Blocks indicates to me that
there is rather total incompetence on this issue with "those Objc developers".

If you claim that Self Blocks are "true" closures while Objective-C Blocks are
not, you simply do not know what you're talking about.

I think some Apple bigots simply do not like Objective-C Blocks, because
Apple objective-c lacks Blocks.

Apple Objective-C lacks garbage collections and Blocks (closures) and therefore
Apple bigots will start argueing that Blocks and garbage collection are not
really interesting features (which is of course a nonsensical argument).

From:	Dr. Scott Steinman
Subject:	Re: Compilers and IDEs for Objective C
Date:	Fri, 26 Nov 2004 05:00:56 GMT

In article , David Stes
wrote:

> I think some Apple bigots simply do not like Objective-C Blocks, because
> Apple objective-c lacks Blocks.
>
> Apple Objective-C lacks garbage collections and Blocks (closures) and
> therefore
> Apple bigots will start argueing that Blocks and garbage collection are not
> really interesting features (which is of course a nonsensical argument).

I think some POC bigots simply do not like Apple, because POC
Objective-C lacks everything that Apple has added to Objective-C since
10 years ago.

POC Objective-C lacks Categories and Protocols and exception handling,
etc., therefore POC bigots will start argueing that Categories and
Protocols are not really interesting features (which is of course a
nonsensical argument).

Yes, yes, this is in jest, but one cannot cry "bigot" without examining
one's own bias as well. David, garbage collection is a good idea, but
not in every situation. Apple decided that for distributed objects, it
is not appropriate. This is not stupid or nonsensical -- it simply part
determining the costs and benefits of language features for the tasks
you need to accomplish. Likewise, blocks have some good uses. However,
you have been blindly ignoring the benefits of categories and protocols
in the same way that you occuse others of ignoring blocks and garbage
collection.

David, a word of advice: After many years of working on POC, you had
the opportunity to become a respected "sage" of the Objective-C
community. Instead, you have squandered this opportunity to vent
hateful diaribes against anybody who uses Cocoa. Your rants do not
advance the the cause of Objective-C on any platform -- they only
diminish people's opinions of you and ultimately make them stop
listening to you. This doesn't hurt you, it hurts the whole community,
because the wisdom you can still offer is ignored bey those tired of
separating it from your rants. If you would just give up your
Apple-bashing crusade, and simply help people with Objective-C
questions, you might gain their respect again.

Dr. Scott Steinman

From:	David Stes
Subject:	Re: Compilers and IDEs for Objective C
Date:	Fri, 26 Nov 2004 06:30:23 GMT

Dr. Scott Steinman wrote:
>
> David, garbage collection is a good idea, but
> not in every situation.

Scott, I feel pity for you.

You don't have the option of using garbage collection in a particular
situation, since you don't have a compiler switch to turn it on (or off)
in a particular situation.

You may gain my respect once you have the opt