Getting double semi as sequencer harvested.

On Fri, 07 Sep 2007 02:25:09 -0700, Jason Johnson  
<[hidden email]> wrote:

> Aha.  In text it can be really hard to detect unless you're suggesting
> something insane like eating children. :)  Perhaps you thought you
> were doing just that here, but with the crazy suggestions lately I
> don't know what to expect.

Well, the cues I forwarded were using words like "abomination" but, yeah,  
given the tone of some threads, it probably wasn't over the top enough.  
It's almost like we're discussing politics here.

> I'm sorry, I don't understand what you mean by this.  Why should an
> object's code need to reference it's own context?  Do you mean "why
> should it need to explicitly state 'self'"?

That is what I mean.

> And by "If it's too hard for YOU too keep track of your object's
> context" do you mean I should remember if what methods my object/class
> has?

I'm just saying if that the removal of "self" renders your code  
incomprehensible, you have bigger problems than anything that removing  
"self" would create.

>>         Tim is the one who used the word "tasteless" to describe a  
>> situation where one doesn't constantly need to explicitly reference the  
>> current
>> context.
>
> Hrm, you mean he doesn't like it unless you constantly reference the
> current context?  Is that in this thread somewhere?

Quoth Mr. Rowledge: "Having a special case that lets you leave out the  
recipient if it is 'self' would be clunky, confusing and tasteless."

> Clear to you.  To me it's uniform and consistent.  Traits I value
> highly in this world of mediocre to down-right appalling language
> designs.

That's an argument to have with Andreas.<s>

> But in self it's uniform, no?  In self it's all just slots so
> accessing a method looks the same as accessing a local variable.  In
> that language I wouldn't expect to use self to call local methods.

To me, that would be consistent: Access variables and methods identically,  
without knowing which you're doing unless you're at the level where it has  
to matter.

> So do you prefer the self language?  Instead of trying to turn
> Smalltalk into Self, it might be more rewarding to get a group trying
> to bring Self back on track.

No, not particularly. Or I should say, I don't know it well enough to have  
a preference. I consider a lot of the distinctions between Self and  
Smalltalk trifles compared to the suggestions of meta-language constructs.  
I once modeled a language after Smalltalk which had meta-language syntax  
(and what you might call "sub-language" syntax, with the idea that the  
language could sort-of assemble itself). It was horrible, needless to say,  
so I'm intrigued to see it done well.

An important thing to consider with implicit self is that since

       (self self) = self

it is very easy (and occasionally important) to be able to mix an
explicit self prefix in code where it helps, with places where it is
much clearer to omit it.

Cheers,

Alan

---------

At 01:58 AM 9/7/2007, Blake wrote:

On 9/7/07, Blake <[hidden email]> wrote:
> On Fri, 07 Sep 2007 02:25:09 -0700, Jason Johnson
> <[hidden email]> wrote:
>
> Well, the cues I forwarded were using words like "abomination" but, yeah,
> given the tone of some threads, it probably wasn't over the top enough.
> It's almost like we're discussing politics here.

:)

> I'm just saying if that the removal of "self" renders your code
> incomprehensible, you have bigger problems than anything that removing
> "self" would create.

It doesn't render it incomprehensible.  I have programmed a lot in C++
and I with implicit "this" always.  But Smalltalk syntax is
wonderfully regular and consistant.  It "feels" right that I can
always know that if a message is being sent the receiver will be to
the left of it.  Even if it's self.

Trust me, when "programming in the large" with the languages that have
the options of implicit self/this you will be expected not to use it.
In fact I think most places would say instance vars need to be
prepended with an "m_" and other nonsense like that.  We don't need
that in Smalltalk because due to the simplicity/regularity of the
language it's never ambiguous when you are accessing an instance
variable.

> That's an argument to have with Andreas.<s>

Heh, I should have used the word "Characteristics". :)

> To me, that would be consistent: Access variables and methods identically,
> without knowing which you're doing unless you're at the level where it has
> to matter.

But you're not accessing methods in either case.  In Smalltalk you're
sending a message somewhere or you are assigning a variable.  In Self
you are basically only ever sending a message.

Self has a better argument for making "self" implicit but at the cost
of syntax.  For example, the requirement on keyword selectors
(describe on the very wikipedia entry you pasted).  But in Smalltalk
message passing and variable access are not at all the same, so they
should look different.

Blake wrote:
>> Clear to you.  To me it's uniform and consistent.  Traits I value
>> highly in this world of mediocre to down-right appalling language
>> designs.
>
> That's an argument to have with Andreas.<s>

Not sure why. I have no objection to uniformity and consistency in
programming languages.

Cheers,
   - Andreas

"***Traits*** I value highly in this world of mediocre to down-right
appalling language designs."

Probably a misread.

Alan Kay wrote:
> An important thing to consider with implicit self is that since
>
>       (self self) = self
>

Oh, Laws of Form's first axiom... how convenient! :)

Andres.

On 9/8/07, Andreas Raab <[hidden email]> wrote:
>
> Not sure why. I have no objection to uniformity and consistency in
> programming languages.
>
> Cheers,
>    - Andreas

He was playing on the fact that I used the word "Traits".  Which is
why I responded that I should have used a word like "Characteristics".

Jason Johnson wrote: Hi Jason,

Here is a paper on Smalltalk without byte codes, although a bit dated.
You'll need to be a member of ACM to download it.
http://portal.acm.org/citation.cfm?id=28708&coll=GUIDE&dl=ACM&CFID=34496579&CFTOKEN=35186959

"We have implemented Smalltalk-80 on an instruction-level simulator for
a RISC microcomputer called SOAR. Measurements suggest that even a
conventional computer can provide high performance for Smalltalk-80 by
abandoning the 'Smalltalk Virtual Machine' in favor of compiling
Smalltalk directly to SOAR machine code, linearizing the activation
records on the machine stack, eliminating the object table, and
replacing reference counting with a new technique called Generation
Scavenging. In order to implement these techniques, we had to find new
ways of hashing objects, accessing often-used objects, invoking blocks,
referencing activation records, managing activation record stacks, and
converting the virtual machine images."

I've seen other papers as well on this topic. Byte codes are but one way
to do things.

Cheers,

Peter

Ah right.  Yes, I knew of some Smalltalks that compile straight to
assembler, but since a VM was mentioned, I thought there was some new
idea or believed to be some new idea.

On 9/10/07, Peter William Lount <[hidden email]> wrote:

Mathieu Suen wrote: Hi Mth,

This pdf article on Lisp has a good explanation of closures.
www.ibm.com/developerworks/java/library/j-cb02067-a4.pdf

You can easily see that they are both a chunk of code and a list. It's
an important feature in ZokuScript for blocks to be code and a
manipulatable list like object: a merging of some of lisp with smalltalk
style syntax.

Cheers,

Peter

(My first post to squeak-dev, I think).

>    "Same as using curly braces but importantly NO syntax changes needed!"
>    list := [a. b. c] objects.

I don't buy this.  You simplified the syntax, and you have added
complexity to the compiler.  Because no, you cannot implement this in
pure Smalltalk (unlike ifTrue:ifFalse: or ifNil:ifNotNil:).  Making up
Smalltalk-like syntax that does not have anything to do with Smalltalk,
is one of the most common mistakes I've seen, and the most common sign
that your love for a language has been corrupted into religion.

>    "More flexible version that lets you collect the evaluated results
>    into an arbitary collection of your own choosing."
>    [a. b. c] addObjectsTo: aCollection.

If you want, you can modify the compiler so that

    aCollection addAll: {a. b. c}

becomes

    aCollection add: a; add: b; add: c.

>    "Wow, even into a stream."
>    [
>        1 to: 1000 do: [:count | count random ]
>    ] streamObjectsInto: aStreamOfRandomIntegers

???  Before proposing something, please ensure that it is implementable.

This would add just "1" to the stream if it parallels to

      aStreamOfRandomIntegers nextPutAll: {
          1 to: 1000 do: [:count | count random ] }

I prefer to add a tiny bit of complexity to the parser, than to add
compiler special cases that get out of control much more easily than new
syntax.

In GNU Smalltalk, there are two common use cases for {...} that are not
easily replaceable:

     aStream nextPutAll: ('%1 (%2)' % { self name. self age })

     Dictionary from: { 'Sun'->'Sunday'. 'Mon'->'Monday' "etc" }

Paolo

Paolo Bonzini wrote: Ok, it's fine with me that you don't buy this. That's means we have
different opinions about it which is excellent in my view. Difference
can often foster innovation and advancement. Time will tell if it does
in this case.

I never said it can be implemented in "pure Smalltalk". In fact I
explicitly stated that a "new statement evaluator" in addition to the
existing one would be needed.

Ah, it's not making up Smalltalk-like syntax! How do you think that it
is? In fact adding curly braces to Squeak changed Smalltalk and could
force all other versions of Smalltalk to adapt, which would be making up
new syntax for Smalltalk and putting pressure on the other dialects to
adopt it.

How is it a mistake to have Blocks do the job instead of curly braces?

It seems to me that the curly braces are a mistake since they are really
a "macro" capability but limited to a single form of macro, the creation
of an array for easy initialization! Why not have additional macro
capability - a generic macro capability? Why not let blocks do the job?

Now, I know that you and others will raise the specter that you can't
implement this notion with blocks since given your ideas of how to
implement it it wouldn't be efficient and would mangle the virtual
machine. Well, I've heard this and maybe it's time to mangle the virtual
machine for Smalltalk up a bit! Time for some innovation! Nothing like
stirring the pot to get it either.

Ok, "common mistakes" and "common sign that your love for a language has
been corrupted into religion". I have no idea what you are going on
about here, but it's bordering on an ad hominem personal attack. If
that's not it's intent please explain it in less incendiary terms. Yes,
I do have affinity for Smalltalk, and yet I find myself designing and
implementing a language inspired by it; so while I might casually say
that I love Smalltalk I also say that it needs improvement and it needs
to catch up with some features in icky languages such as, ick,
JavaScript; and it needs to be shaped to support the kind of
applications that I want to build with it. No other language that I know
of, and I've looked at a huge number of computer languages, can do the
job so I'm taking Smalltalk further than it's ever been taken before.

What? Why?

Besides, your statement is just silly for a number of reasons. First off
it's just silly to ensure that. Secondly what makes you think that it's
not implementable? Just because you can't see it? Come on, get creative.
Finally, please don't place limits or restrictions upon me, thank you. These could easily be done with the Block version that I've explained.
See the other recent posting by me on this for details on the new
statement collecting evaluator for Smalltalk.

These two example show how clean this is in Smalltalk using existing
syntax and the new evaluator for blocks.

    aStream nextPutAll: ('%1 (%2)' % [ self name. self age ] values )

    Dictionary from: [ 'Sun'->'Sunday'. 'Mon'->'Monday' "etc" ] values


The future can be created in steps or in giant leaps. The notion of
adding a new evaluator to Smalltalk that collects the results of
statements is but one of many new things that can be done with blocks.
Reusing exisitng syntax in a way that integrates into the message
passing and object paradigms of Smalltalk just makes sense to me as it
keeps the syntax as pure and clean as possible. It keeps the language to
the original spirit of message passing and elegance, simplicity and
beauty. As soon as you sacrifice the language design to implementation
issues by adding icky special purpose syntax for each new capability or
feature you've already taken the road to "perlification".

The choice isn't always easy to make. Beauty and elegance are very
important. The insights into the unique unary, binary and keyword
message sending syntax was an impressive leap forward in the creation of
Smalltalk. Let's not pollute it for the sake of making life easy for
compiler writers and virtual machine implementors.

All the best,

Peter William Lount
[hidden email]

Paolo Bonzini wrote:
Hi Paolo,

Eh? What? You're calling me a troll? If that's the case that's just
silly and very inappropriate since you are deeply mistaken. You know me
Paolo, we've had interactions over the years, and I'm quite surprised
that you'd stoop to person an hominem attacks by calling me a troll.
Besides I don't follow the logic of how on earth you could interpret
what I wrote in the series of postings under the subject 'Fear and
loathing of the "perification" of Smalltalk'.

Maybe you didn't understand what I meant. If that's the case I apologize
for your misunderstanding as my posting mustn't have been clear - I'll
attempt to communicate what I meant again.

------
Two Evaluators For Smalltalk Like Languages
1) You'd have to agree that the normal Smalltalk evaluator simply
returns the object from the last statement in a sequence of statements?
Right? For example, the value of the following block is the value of
"c", whatever that is: "[ a. b. c ] value". Let's assume that the
variables are defined in the method or are instance variables.

2) You'd have to agree that it would be possible for a NEW evaluator to
return a collection containing the values of ALL the statements in a
sequence of statements? Right? For example, the value of the following
block is the collection with elements "#(a b c)": "[ a. b. c] values".
Note that the message "values" and not "value" was sent to the block.
The "values" message asks the block to evaluate itself "collecting" up
the objects from each statement and place them into a collection; by
default an ordered collection would be a good choice since the number of
objects wouldn't be known at run time.

So, assuming that you understood the two above paragraphs then you'd
have to agree that (2) is a valid option or alternative to (1). As such
you'd have to agree that I do know what I'm talking about, since it's
clearly explained in the above two paragraphs. Simply put Blocks can do
the job that curly braces do leaving curly braces out of Smalltalk
syntax and available for a far better purpose.

While I now recall someone telling me that squeak did implement the
curly braces as a quick compiler hack a couple years back (that just
generates other Smalltalk code like a macro would in many other
languages), I'd forgotten that during the recent conversations until
reminded about it. That was my failing for sure, but not a significant
one and certainly one that's not relevant to the fact that the second
option for the existing evaluator would be valid and useful in Smalltalk
or a language inspired by Smalltalk such as ZokuScript.

The other version of Smalltalk that I was referring to is the one that
I'm working on, ZokuTalk and the language inspired by Smalltalk,
ZokuScript. ZokuTalk is intended to be as close as possible to
Smalltalk-80 style languages such as Cincom Smalltalk, IBM VisualAge or
Squeak Smalltalk; that's to support code portability. ZokuScript is
meant to take Smalltalk to a whole new level. ZokuTalk will be rewritten
into ZokuScript on the fly at compile time or at runtime and then that
ZokuScript will be compiled into native code. No byte codes to mess
things up.*
------
*
So Paolo, maybe you'd have to admit that there could possibly be a
chance that I might know what I'm talking about. The next time before
you accuse someone of being a troll - which is a highly aggressive ad
hominem personal attack and an attempt to stifle free speech and the
discussion - you'd have the courtesy of asking what the person meant so
that they can explain it to you. Just because you don't understand
something that someone says doesn't mean that they are a troll with some
devious purpose that you imagine. Also, because someone doesn't hold
your point of view that doesn't mean that they are a troll either - it
just means that they have a different point of view.

I hope that I've shown with the above two paragraphs that an alternative
evaluator for Smalltalk added to blocks can be in fact made to work at
the language level. How to implement it is certainly a question. I
simply don't think that implementing it with curly braces is the way to
go since that adds, in my view, unnecessary syntax when we could use
Blocks with a second "collecting" evaluator for the statements. There
are many smart implementors in this list and elsewhere who can figure
out the best way to implement blocks in this manner.

All the best,

Peter William Lount
[hidden email]

> Eh? What? You're calling me a troll? If that's the case that's just
> silly and very inappropriate since you are deeply mistaken. You know me
> Paolo, we've had interactions over the years, and I'm quite surprised
> that you'd stoop to person an hominem attacks by calling me a troll.

Exactly because I knew you, I was as surprised by your messages;
sometimes one can be a troll without realizing it.  I should probably
have said "you're acting as a troll".

(Besides, that message was posted off-list for a reason.  Now that it's
made public, I'll try to sum up my arguments in a single message.)

> 1) You'd have to agree that the normal Smalltalk evaluator simply
> returns the object from the last statement in a sequence of statements?
> Right? For example, the value of the following block is the value of
> "c", whatever that is: "[ a. b. c ] value". Let's assume that the
> variables are defined in the method or are instance variables.

So far so good.

> 2) You'd have to agree that it would be possible for a NEW evaluator to
> return a collection containing the values of ALL the statements in a
> sequence of statements?

Yes, but I agree with Damien that I would *not* call it a block.  The
definition of statement is blurred away after compilation.  In principle
it would be possible to compile a block to an array of statements, each
of them being a lambda:

      (Array new: 3)
           at: 1 put: [<lambda> 1];
           at: 2 put: [<lambda> 2];
           at: 3 put: [<lambda> 3];

(more on the syntax extension later).  Then, you could indeed implement
#value/#values like this:

   BlockClosure>>#value
       ^self blocksForEachStatement inject: nil into:
           [ <lambda> :old :each | each value ]

   BlockClosure>>#values
       ^self blocksForEachStatement collect: [ <lambda> :each | each value ]

   LambdaBlockClosure>>#value
       <primitive: ...>

   LambdaBlockClosure>>#values
       ^Array with: self value

I will even make a bold statement about performance; you could implement
#value via a BlockClosure>>#asLambda method and cache its result; then
the result would probably not even be much slower than the current state
of things!

However, this beg the question: is it worth it?  In my opinion, no.  It
would be probably like one or two weeks of work to add the necessary
support (the VM does not need to be changed, if I thought it right).
The syntax still needs to be changed, or you risk infinite recursion
(those <lambda> markers in the source code were there for a reason).
So, overall, the amount of thought in designing your extension exceeds
the amount of thought in designing curly braces (and I don't see a way
to design the extension cleanly without a syntax extension too).

(In addition, in older versions of Squeak curly braces were allowed on
the LHS of the assignment too; I don't remember if this is still there
or was removed.  This kind of tuple assignment is quite elegant and
useful even though it may apply only in relatively few cases).

> So, assuming that you understood the two above paragraphs then you'd
> have to agree that (2) is a valid option or alternative to (1). As such
> you'd have to agree that I do know what I'm talking about, since it's
> clearly explained in the above two paragraphs. Simply put Blocks can do
> the job that curly braces do leaving curly braces out of Smalltalk
> syntax and available for a far better purpose.

I'd say that you really knew what you were talking about, if you came up
with something like the sketch I did above.  I have high expectations on
any message that talks about the implementation of the language
(probably because I have better skills there than in OO design), and
they were missed too often in the course of this thread.

Boasting the power of your proposed extension in this example:

>>    [
>>        1 to: 1000 do: [:count | count random ]
>>    ] streamObjectsInto: aStreamOfRandomIntegers

(which only includes one statement, i.e. the send of #to:do:) was for me
the sign that you hadn't put the necessary thought into your message,
especially compared to the boldness of the message itself.

In the remainder of the thread, your stating that {...} needs support in
the VM, and your presenting SOAR as an alternative to bytecodes (when it
should be clear that a hypotetical alternative to bytecodes should allow
*more* reflection, not less as is the case for native code!), was too
close to being gratuitous trolling.

> Now, I know that you and others will raise the specter that you can't
> implement this notion with blocks since given your ideas of how to
> implement it it wouldn't be efficient and would mangle the virtual
> machine. Well, I've heard this and maybe it's time to mangle the virtual
> machine for Smalltalk up a bit! Time for some innovation! Nothing like
> stirring the pot to get it either.

I will concede you this.  However, give time to think on it since, as
you said, squeak-dev has some clever people in it.  A defensive attitude
  and an enormous thread is not needed to stir the pot.

> "common sign that your love for a language
> has been corrupted into religion".

"Your" was meant to be impersonal (don't you love ambiguous grammars?
:-)  I think that sometimes one needs to look "out of the box", and it
happens too often that this is limited to features while other things
(including syntax) are taken too much for granted.  But a language is a
tool, not a religion: if one feels a need and the language cannot
express it well, it might be good to look at the same time "in the box"
and "out of the box".  I can give you examples.

One is foreign function interface; you can define external functions
either with a "magical" method that you send to the class and does
everything (like "Integer class define: #getPid as: 'int getpid (void)'"
for example), or you can see the similarity with a primitive and extend
<primitive: ...> into the pragma syntax that's seen in most modern
Smalltalks.  The second example is Unicode; you can force everybody to
write "16r1000 asCharacter" (which is also less efficient than $A) or
try to find a simple extension to the syntax, for example $<16r1000>
could be an idea.

(On the other hand, there are surely cases where the existing
abstractions are more than enough, and there's no need to introduce new
ones: continuations and generators are an example).

My opinion is that part of what is blocking evolution of Smalltalk is
the lack of "looking out of the box".  Evolution does not mean
perlification; on the contrary, if Randal Schwartz is in this mailing
list we might have something to learn from him and Perl.

Paolo

Hi Peter,

on Thu, 13 Sep 2007 10:03:58 +0200, you wrote:
[...big snip..]

>     Dictionary from: [ 'Sun'->'Sunday'. 'Mon'->'Monday' "etc" ] values

Ahh, sending #values to aBlock, that's quite an interesting direction. And  
easy to implement, either in Compiler or Reflectivity. And usefull when  
doing Adrian's collective behavior :)

If nobody else claims to have invented that, I'll record that under your  
name.

/Klaus

>
> All the best,
>
> Peter William Lount
> [hidden email]
>

>>     Dictionary from: [ 'Sun'->'Sunday'. 'Mon'->'Monday' "etc" ] values
>
> Ahh, sending #values to aBlock, that's quite an interesting direction.
> And easy to implement, either in Compiler or Reflectivity.

In reflectivity, maybe.  In Compiler, not if you want it to work through
multiple levels of indirection (i.e. making #values an instance method
on BlockClosure).

Paolo

Hi Paolo,

on Thu, 13 Sep 2007 11:31:00 +0200, you wrote:

>
Peter wrote:
>>>     Dictionary from: [ 'Sun'->'Sunday'. 'Mon'->'Monday' "etc" ] values
Klaus wrote:
>>  Ahh, sending #values to aBlock, that's quite an interesting direction.  
>> And easy to implement, either in Compiler or Reflectivity.
>
> In reflectivity, maybe.  In Compiler, not if you want it to work through  
> multiple levels of indirection (i.e. making #values an instance method  
> on BlockClosure).

A replacement for current {} which also could be decyphered by Decompiler  
shouldn't be a problem for current {} accepting compiler.

And having BlockClosure>>#values as well, as an option, wouldn't harm  
during development+test of #values (and perhaps later too).

It depends on "just" goals.

/Klaus

> Paolo
>
>

I don't see how [...] values can be implemented without modifying VM.
You need to call some primitive to activate a block and execute
statements. Of course, having a source(or parse tree) , you can parse
it and then convert each statement in separate block and execute them
one by one. Then you don't need to modify VM code. But speed ...

Also, some use patterns don't fit the purpose and can lead to errors
and undefined behavior.
Consider following:

block := [ | temp |    temp := 1.   temp:= temp+1.   temp ].

and somewhere later:

result := block doInParralell

Suppose you sending #doInParralell message to some unknown block
(which contents is unknown at compile time). It's very interesting
what results will be.

On 13/09/2007, Igor Stasenko <[hidden email]> wrote:
> Suppose you sending #doInParralell message to some unknown block
> (which contents is unknown at compile time). It's very interesting
> what results will be.

Well, broken code breaks, where's the problem with that :)

My problem is that blocks will still be mostly used for sequential
code, callbacks, etc. Nothing indicates that a given block is or isn't
intended for parallel execution. I'd prefer to keep square bracket
blocks what they are now (lambdas) and use a different syntax for the
collection-of-statements blocks proposed by Peter (they should even be
collection-of-expressions rather than -of-statements)

As for macros, there are two points:

The metaprogramming job of macros is already done by the tools:
browser, refactorings, etc

Macros in Lisp use the same syntax as functions. When you look at a
Lisp expression, you can't know which evaluation rules apply without
looking at the library. Some s-exprs are syntax, evaluated at
compile-time, some other are calls evaluated at runtime. It works in
the Lisp realm, but it doesn't fit in Smalltalk. In Smalltalk,
parentheses mean "evaluated the usual way, once and now", square
brackets mean "evaluated the usual way, but it's not said when nor how
many times", and if we want "syntactic shortcut" then it should use a
separate notation.

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

Hi Igor,

on Thu, 13 Sep 2007 14:36:11 +0200, you wrote:

> I don't see how [...] values can be implemented without modifying VM.
> You need to call some primitive to activate a block and execute
> statements. Of course, having a source(or parse tree) , you can parse
> it and then convert each statement in separate block and execute them
> one by one. Then you don't need to modify VM code. But speed ...

What you describe is the implementation of {} sans VM mod, it's inlined by  
the current compiler, and also the Decompiler knows how to decypher that.

> Also, some use patterns don't fit the purpose and can lead to errors
> and undefined behavior.
> Consider following:
>
> block := [ | temp |    temp := 1.   temp:= temp+1.   temp ].
>
> and somewhere later:
>
> result := block doInParralell

... which is not the same as #values above and the latter can always be  
inlined, no?

> Suppose you sending #doInParralell message to some unknown block
> (which contents is unknown at compile time).

... have a Smalltalk example of aBlock which contents is unknown at  
compile time?

/Klaus

> It's very interesting
> what results will be.
>