Hi,

Paolo Bonzini wrote:
> peter wrote:
>> 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".
Well, I gather I take that as a retraction on your part, although I 
still consider any hint or suggestion that I'm acting like a troll to be 
an ad hominem attack and completely inappropriate.
>
> (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.)
I thought it relevant to clarify the explanation. I also don't take 
false accusations and ad hominem attacks lightly. They need to be seen 
in the full light of day as an attempt to stifle discussion and 
communication.

I apologize in advance for the length of this message - I'm also 
attempting to summarize some of the insights that I've seen as a way 
forward for Smalltalk, and ZokuScript.
>
>> 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, 
Great, then it's clear that you understand what I'm talking about.

> but I agree with Damien that I would *not* call it a block.  
Why not? Because curly braces are implemented as a fixed kind of macro 
in Squeak? If that's the case then you're stuck with a preconception 
that is limiting your thinking.

Of course it's still a Block. It's not the block that's changing anyhow, 
the Block is simply the best place for this since it fits within the 
messaging paradigm so well. It's the Smalltalk evaluator that's being 
adjusted to evaluate the statements.

Block is simply the most convenient place, and the most logical place, 
and the most elegant place, and the most beautiful place to add this to 
Smalltalk WITHOUT adding new syntax characters to the language.

Besides with the collecting-evaluator being placed on Block you have the 
best of both worlds, deferred execution and a choice of evaluators.

N-CORE PARALLEL FUTURE
In fact someone already thought of a third evaluator for Blocks, for 
evaluating the statements in parallel! This is an enhancement that a 
number of languages are doing to enable statement or expression level 
parallelism on multi-core processors. With chips like the Tile64 in the 
pipe slated for delivery later this year the reality is that N-core 
chips where N is very large are on the immediate horizon. They plan to 
take N to over 1,000 with their current design approach within a few 
years, starting with 36 and 120 next year. One very interesting aspect 
of the Tile Processor design is that each core is networked with the 
others in what they call an iMesh, basically a flexible and fast network 
connections some of which are dedicated between cores. They claim 
impressive results with their design in that it costs less to transmit a 
message between two cores than it takes to store to memory. This changes 
everything in how we understand multi-core processing.

> The definition of statement is blurred away after compilation.  
In current implementations of Smalltalk.

> 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
Yes, one could do it that way however it's not as flexible since you're 
making the block with a "<lambda>" marker of some kind. What is the 
"<lambda>" statement doing in there precisely. Primitives don't 
currently work that way so you are suggesting further syntax changes 
too. How would that work?

>
> 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!
Ok, how do you see "asLambda" working? What do you mean by "asLambda"? 
How do you see the result of #asLambda being different from a block?

>
> However, this beg the question: is it worth it?  In my opinion, no.  
As is clear, we disagree.

> 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).
Add a new collecting-evaluator without the need to change the syntax.

>
> (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).
I wasn't aware of that. Sounds icky.


>> 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.  
That is a very ridiculous statement, is nonsense and counter productive 
and is another ad hominem attack. Part of the reason for posting to this 
group and others is to get the thoughts of other people engaged. If 
people followed your high expectation then nobody would post anything if 
it wasn't fully developed and implementable.

> 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.
Please don't impose your high expectations upon me in a negative way as 
it is inappropriate. Certainly I welcome a commitment to excellence 
expressed in positive terms that moves the discussion forward. Thank you.

>
> 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.
Then wouldn't it be better to say that my example had a mistake in it 
rather than making false accusations in the form of an ad hominem attack?

Yes, you are correct that there is a mistake in the example and in my 
rush with the posting that day I didn't see it. I apologize for that. 
Thanks for pointing it. At this time I'll abandon that example, as I 
need to think about what I was attempting to illustrate there in depth.

The actual take home point is that the values from evaluating a Block 
should be able to be placed into any kind of collection that the user 
specifies or into any stream as well. For example,  #valuesInSet and 
#valuesInto: aSet would enable this parameterization. A convenience 
message on block to take the values and add them to the stream is also 
of value (sorry about the unintended pun). Maybe a better name might be 
#valuesOn:.
    [ a. b. c ] valuesOn: aStream

Note that this level of parameterization with Blocks isn't possible with 
the curly braces syntax and could only likely be achieved by contorting 
Smalltalk further towards syntax nightmares and perlification. The curly 
braces are a fixed syntax that imposes a solution that only fits some 
situations and is inherently not extensible.

FIRST PRINCIPLE: MESSAGES
The principle that I am applying comes from Alan Kay. He says that 
messaging is the BIG IDEA not objects. When I think about enhancements 
to Smalltalk I attempt to find a way through the looking glass (from the 
perspective) of "MESSAGING" to accomplish the enhancement.

The design rule is easy to express: messages over syntax.

In this case Block is the appropriate object on which to implement the 
message, #values. Sending a message to Block achieves being true to 
Alan's vision of messaging since the feature/capability is added via 
messages instead of by altering the syntax of the language. Clearly the 
curly braces implementation of the collecting-evaluator violates the 
first principle of messaging by (1) not using messaging and (2) by 
changing the syntax to accomplish the goal. Clearly in this case a 
messaging based implementation is truer to Smalltalk than a syntax 
implementation.

PRINCIPLE OF EXTENSIBILITY
One of the fantastic properties of messages is that they are extensible! 
First principle: messaging; second principle: objects; third principle: 
extensibility now and in the future by the user.

A majority of the beauty of Smalltalk comes from messaging and it's 
unary, binary and keyword syntax. Failing to add features within this 
context when it's possible moves the language off it's base of elegance, 
beauty and simplicity into a dark future. I have clearly shown that it's 
possible to add a new collecting-evaluator to the Smalltalk language via 
blocks at the language level. Implementation follows from this and may 
take a bit of work but it'll be worth it to preserve and maximize the 
power of messaging.

In fact the collecting enhancement to blocks is but one of the many that 
I've come up with for ZokuScript. A number of them can be implemented in 
Smalltalk keeping Smalltalk Smalltalk. A number of then can't and they 
are some of the reasons for ZokuScript.

UNIFICATION OF BLOCKS AND METHODS
One of the other enhancements that would work for Smalltalk and 
ZokuScript is the unification of Block and Method syntaxes. Since they 
are almost the same now this can be done while remaining compatible with 
existing Smalltalk programs. The advantages are many. I'm working on a 
short paper about it that I will publish. One advantage is the 
"depreciation" of the "legacy source code chunk format". In it's place 
regular code that is used in Smalltalk methods. For example in a 
workspace or a file one could write this once Blocks and Methods are 
unified.

[
     Object subclass: #Person.

    Person
        addInstanceVariable: #firstName;
        addInstanceVariable: #middleName;
        addInstanceVariable: #lastName.

    "Block form."
    Person addInstanceMethod: [firstName: aString | firstName := aString ].

    "Same method as the line above, in method form this time."
    Person addInstanceMethod: [
        firstName: aString
            firstName := aString
    ].
  
    "Yes, the intent is to be able to do this flexibly storing the block 
first and even using it as needed if you want."
    aBlock := [middleName: aString | middleName := aString ].
    Person addInstanceMethod: aBlock.

    "Yes, the intent is to be able to do this as well."
    aBlock := [:aString | lastName := aString ].
    Person addInstanceMethod: aBlock named: #lastName:.

    Person addInstanceMethod: [
        fullName
            ^ (
                    firstName asStringOrEmptyStringIfNil, Character cr 
asString,
                    middleName asStringOrEmptyStringIfNil, Character cr 
asString,
                    lastName asStringOrEmptyStringIfNil
             ) trimBlanks.

] fileInWithinTransaction.

No more need for legacy Smalltalk chunk format with it's weird syntax - 
it can now be depreciated! Part of moving a language forward is deleting 
that which isn't needed anymore. It turns out that by unifying Block and 
Method syntax we can simplify the language and eliminate unneeded 
syntax! This again meets the first principle expressed by Alan Kay that 
messages are above all the big idea. By replacing the syntax based chunk 
format with a new source code format that uses messages and the main 
Smalltalk syntax we fulfill the first principle of messaging.

There are other benefits to the unification of Block and Method syntax.

One could for example always store and manipulate the Block-Method and 
decide later at runtime if it's going to be used as a Block or added to 
a class as a method on the instance side or the class side. The 
important aspect of this is that various object models can now be 
supported directly in standard Smalltalk syntax with just minor 
modifications that don't add new weird syntax but that unifies two 
branches (Blocks and Methods) at the source code level into one. Other 
object models include but are not limited to: prototype based, 
class-instance, class-instance+prototype, and whatever you can imagine 
and implement.

Yes, at runtime Blocks and Methods are implemented differently and there 
is little need, that I can see, to change that. This change takes place 
at the source code level for the most part.

Yes, a "conversion" between Block and Method needs to take place. Yes, 
it's possible not all Blocks may be able to be converted and vice versa; 
that's what exceptions are for. (I'd have to think that one through in 
detail).

>
> In the remainder of the thread, your stating that {...} needs support 
> in the VM, 
That is the approach that I'm taking to implement it, with, if needed, 
the alternative of generating code on the fly to capture the statement 
results as being obvious.

> and your presenting SOAR as an alternative to bytecodes 
I was simply expressing the fact that alternatives to bytes codes have 
been thought about for a long time.

> (when it should be clear that a hypotetical alternative to bytecodes 
> should allow *more* reflection, not less as is the case for native code!),
Maybe it's clear to you. If that's the case you could express that in a 
positive light. You also assumed that it wasn't clear to me. In fact I 
have worked on an alternative to byte codes that generates native code 
and that improves reflection. I didn't see any need to express that in 
the particular posting as it's a topic of it's own and the focus of this 
thread was to show an example of moving Smalltalk towards a PERL style 
of solution with syntax gone wild verses a solution of moving Smalltalk 
forward without adding any new syntax at all! - just an addition to the 
core evaluator which provides a powerful new semantic when needed. It 
worked too, for someone came up with a third evaluator. It worked too 
since we've deepened the discussion on how one might implement as 
Blocks, and how one might not want to do it. To me the discussion has 
moved forward.

> was too close to being gratuitous trolling.
You have a strange view of the world where you think you can falsely 
accuse people with just what you perceive rather than asking deeper 
questions to probe their intentions. In my view and experience, you are 
being much to easy to ascribe negative intentions to people. By even 
suggesting someone is a troll or acting like a troll you are attacking 
them which is an ad hominem attack against the person - a very limited 
form of argument which also has the impact of attempting, intentional or 
otherwise, to sway the groups opinion against the person. I invite you 
to elevate your level of arguments by self-censoring the word "troll" 
from your vocabulary - that is if you really are interested in deepening 
dialog with people in a creative field such as inventing the future.

>
>> 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.
The defensive attitude is strictly in response to an unwarranted person 
offensive attack by yourself. Regardless of the group I'm in I always 
address ad hominem attacks by clearly stating what the attacker said 
that was a personal attack and by asking them to cease such silliness. 
Obviously you have a feisty attitude indicated by your accusations;  I 
can work with you even if you don't adapt by asking questions before 
making seriously negative judgments about someone's intentions.

>
>> "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? :-)
Ok, yes English is wonderful that way, which is why I tend to probe 
deeper before making accusations when my brain suggests any negative 
intention might be present.

> I think that sometimes one needs to look "out of the box", 
Obviously that's what I am doing.

> and it happens too often that this is limited to features while other 
> things (including syntax) are taken too much for granted.  
I am simply presenting the concern that enhancements to the core of 
Smalltalk, the language syntax, must be made very carefully least we end 
up with a mangled language like Perl where one must be a master of 
syntax memorization and gymnastics. We do want more people to adopt 
Smalltalk like languages don't we? While some of you might like that 
sort of twisted mental contortions I prefer to have an elegant language 
that is very clear about what is going on and that has a uniform syntax 
that makes sense and is elegant, simple and beautiful. Yes, those are 
technical terms; for an in depth discussion on them this article is 
excellent: 
http://bradapp.blogspot.com/2006/05/simple-aint-easy-myths-and.html.

> But a language is a tool, 
Yes.

> not a religion:
You are the one who brought up the religion issue not me.
> 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".
That is exactly what I've been doing for five years now working on 
extending Smalltalk and taking Smalltalk to a whole new level. I have an 
in the box solution: use existing smalltalk and develop ZokuTalk. I have 
an out of the box solution: develop a new language deeply inspired by 
Smalltalk, Lisp, Erlang, Audition, Forth, and many more. If I was only 
thinking inside the box I'd not have stepped out of it to create 
ZokuScript. I respect Smalltalk and some of the enhancements not only 
take it to a whole new level but also make it into a new system and as 
such I make that distinction.

> 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), 
Oh great, the wonderful world of types. Sigh. Yes, I know that they are 
needed for interfacing to other systems. Types, sigh.

> or you can see the similarity with a primitive and extend <primitive: 
> ...> into the pragma syntax that's seen in most modern Smalltalks.  
Extending primitives is interesting. IBM Visual Age has a nice way of 
allowing the calling of pretty much any DLL function making integration 
with the rest of the multi-verse straightforward. They also have 
objectified much of the interface as well. If I'm not mistaken Cincom 
also did some recent work in this area too.

Maybe we could collect together all "extensions" or "variants" from all 
the Smalltalk versions into one place for easy reference? Who'd be up to 
helping with that?

> 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.
Or just $16r1000. Why bother with "<" and ">"?

>
> (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.
I'd like to hear more from you on your thoughts for the evolution of 
Smalltalk.

Yes, evolution of Smalltalk might not mean perlification however it sure 
looks like a great many of you fail to recognize that the introduction 
of a weak one-feature only macro capability for quick initialization 
using curly braces is a step towards a syntax mess and thus 
perlification of Smalltalk. Please keep Smalltalk pure to the big idea 
of messages followed by objects and extensibility, even if it's really 
really hard to do. Thanks.

All the best,

Peter