Paolo Bonzini wrote:
What does the Squeak Compiler convert curly braced code into?
Sending #new: and #at:put:
Certainly in another version of Smalltalk there will be two evaluators: one that returns the value of the last statement as normal, plus one that stores the results of each statement as it's evaluated into a collection.
You don't know what you're speaking about. Ergo, you're a troll.
Paolo
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 peter@smalltalk.org
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.)
- 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.
- 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,
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.
- 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.
- 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
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.
No, because I see a Block as a single indivisible evaluation. Parallel execution would be implemented on top of an *array of blocks*, for example.
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?
It would make a "single statement" block, and it is (conjectured to be) needed to avoid infinite recursion (notice that BlockClosure>>#value uses blocks). In these two cases it is not necessary, because the blocks I'm marking are also single-statement. But it is not necessarily true that all the blocks involved in the implementation of blocks are single statement.
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?
#asLambda would coalesce all the statements into a single indivisible block-as-we-know-it-in-current-Smalltalk.
[ a. b. c ] valuesOn: aStream
Note that this level of parameterization with Blocks isn't possible with the curly braces syntax
Sure it is. Not that I'd endorse it.
Array>>#valuesOn: aStream nextPutAll: (self collect: [ :each | each value ])
[ Object subclass: #Person.
Person addInstanceVariable: #firstName; addInstanceVariable: #middleName; addInstanceVariable: #lastName.
"Block form." Person addInstanceMethod: [firstName: aString | firstName := aString ].
Not so easy. How do you guarantee that "firstName" is in scope when the block is compiled? You would have to store a parse tree for the method, or something like that, and so far so good. But much worse, you would have to turn *each* and *every* undefined variable appearing in a block from a compile-time error to a run-time error a la #doesNotUnderstand:.
Because...
"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.
... there is no guarantee that a block will end up #value'd rather than #addInstanceMethod:'ed to a class that does not even exist.
"Yes, the intent is to be able to do this as well." aBlock := [:aString | lastName := aString ]. Person addInstanceMethod: aBlock named: #lastName:.
Same here: you could also do
Animal addInstanceMethod: aBlock named: #lastName: someCollection do: aBlock
and both of these would be errors. So, you cannot verify undefined variables of blocks until run-time.
No more need for legacy Smalltalk chunk format with it's weird syntax - it can now be depreciated!
Indeed, but you can also do that with a declarative syntax as is implemented in Stef's Sapphire or in GST 3.0 betas.
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!
Are you still sure after my objection above?
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.
They are more similar than you'd think. The main difference is in how they are activated, not in how they are stored.
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).
That might be more or less the same problem I hinted at above.
Yes, those are technical terms; for an in depth discussion on them this article is excellent:
Thanks, I'm reading it.
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?
AFAIK, these are
{...} RHS (GNU, Squeak) {...} LHS (old Squeak only?) #{...} (GNU, VW) namespaces (GNU, VW, VA, ST/X) #[...] (all?) ##(...) (GNU, VA, Dolphin) pragmas (many but with different implementation details)
Sorry for snipping so much of the rest, it was useful to understand your POV but it is not something that I can "answer" or "object to"; just a note:
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 ">"?
Because $8r40 is weird but valid Smalltalk (sends r1000 to the character 8), while $<8r40> would be the same as the space character (ASCII 32). Anyway, you see, this is a syntax extension. :-)
Paolo.
Paolo Bonzini wrote:
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.
No, because I see a Block as a single indivisible evaluation.
Your statement above reveals that you have a fixed notion of what you see a Block is. With the collecting-evaluator the block is still a single indivisible evaluation, it just collects up the results of it's work.
Parallel execution is really a different subject entirely than what curly braces and blocks with a collecting-evaluator do. Besides, parallel execution is valid too, but you don't see it that way as indicated from your own statement about how you see blocks.
Parallel execution would be implemented on top of an *array of blocks*, for example.
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?
It would make a "single statement" block, and it is (conjectured to be) needed to avoid infinite recursion (notice that BlockClosure>>#value uses blocks). In these two cases it is not necessary, because the blocks I'm marking are also single-statement. But it is not necessarily true that all the blocks involved in the implementation of blocks are single statement.
There are many issues involved in parallelizing blocks for N-Core processors, especially N-Core processors where the communications cost is lower than the memory storage costs. The point however, wasn't an in depth analysis of that, the point was that altering the core evaluator in Smalltalk so that there are two, with the collecting-evaluator, is powerful; and when that thought was expressed a third evaluator option opened up allowing for yet another option. I'm not saying that I'd implement it as an evaluator but the point is that people are thinking about what it means to have other evaluators. I'd likely implement the parallelism as a block statement splitter operation the splits the statements in a block so that the following would occur.
[a. b. c] forkStatementsInParallel.
The above would get converted into three blocks that are executed as separate threads/processes and then the results would be joined and the result of "c" returned. There are of course many options needed thus there would be many methods in this protocol, including collecting the results of all the forked statements. Naturally you'd also want to be able to access, assign and otherwise control the processes and synchronize them. This really is a complex area due to the concurrency issues and needs a bit of research and will require some deep thought - fortunately lots of work has been done in this area and there are excellent papers out there.
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?
#asLambda would coalesce all the statements into a single indivisible block-as-we-know-it-in-current-Smalltalk.
Oh maybe you mean that a list of blocks within a block would be merged into one. Well that is a useful operation but why obscure it with weird cryptic and misleading terminology such as #asLambda from functional languages, why not something more clear such as #mergeBlocks, or #mergeTopLevelBlocks? I'd want many options in such a protocol, including split blocks top level statements into separate blocks and fork them to run on different processor nodes. I fully support block manipulation methods as being very useful in certain circumstances.
With the "<lamda>" tagging of blocks used in your examples you've clearly altered Smalltalk syntax in a dramatic way, yet you've not answered any questions about it. Please explain why the lambda tag is there.
[ a. b. c ] valuesOn: aStream
Note that this level of parameterization with Blocks isn't possible with the curly braces syntax
Sure it is. Not that I'd endorse it.
Array>>#valuesOn: aStream nextPutAll: (self collect: [ :each | each value ])
I sit corrected. As I said, I can learn from you. Yes, since the curly braces are simply an initialization macro the underlying collection object can receive messages. I suppose that is a useful side effect of the curly braces, however they still are a new syntax when one isn't needed to get the job done.
[ Object subclass: #Person.
Person addInstanceVariable: #firstName; addInstanceVariable: #middleName; addInstanceVariable: #lastName.
"Block form." Person addInstanceMethod: [firstName: aString | firstName := aString ].
Not so easy.
Yes, so very easy.
How do you guarantee that "firstName" is in scope when the block is compiled?
Why would you? Smalltalk is a dynamic language. Besides it's not different than what happens when filing in code now anyhow, at least no different at the language level. You define a class with it's variables and then load the methods. Sure, the evaluator needs to be a bit more flexible than existing code if it needs to be, but that is the nature of progress. Change happens. Adapt or fall behind or take a different path. It's your choice.
You would have to store a parse tree for the method, or something like that, and so far so good.
Yes.
But much worse, you would have to turn *each* and *every* undefined variable appearing in a block from a compile-time error to a run-time error a la #doesNotUnderstand:.
Nope.
Because...
"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.
... there is no guarantee that a block will end up #value'd rather than #addInstanceMethod:'ed to a class that does not even exist.
Yes, perfectly true and desired. This is part of the more expressive future.
"Yes, the intent is to be able to do this as well." aBlock := [:aString | lastName := aString ]. Person addInstanceMethod: aBlock named: #lastName:.
Same here: you could also do
Animal addInstanceMethod: aBlock named: #lastName: someCollection do: aBlockand both of these would be errors. So, you cannot verify undefined variables of blocks until run-time.
Well, the case with variables isn't an issue when they are defined in the context of an existing method for the class. So we can rule out many situations right there. For the rest, moving into the future isn't easy for the critic as it takes vision to make the great leaps. Yes, you raise valid points. There are solutions.
No more need for legacy Smalltalk chunk format with it's weird syntax
- it can now be depreciated!
Indeed,
Thank you for the one sorta positive word about the notion. Man, some critics are really tough.
but you can also do that with a declarative syntax as is implemented in Stef's Sapphire or in GST 3.0 betas.
ALL META OPERATIONS CAN BE DONE WITH STANDARD SMALLTALK SYNTAX Adding the variables to the class in my examples is a declarative statement! It's just expressed in the language of messaging itself! Why invent other languages or special syntaxes when we have a perfectly good syntax with unary, binary and keyword messages? There is not need for a special declaration syntax, none; not when it can be done with message syntax. You just have to adjust your thinking and how it's implemented. I invite you to open your mind to new possibilities beyond the horizon of the critic within who knows very well how it's done now; engage the visionary who sees a new possibility and creates the future.
All meta operations can be done with standard Smalltalk syntax of unary, binary and keyword syntax messages! There is almost zero need to use any new syntaxes to do the job when Smalltalk style messaging syntax is the most potent syntax.
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!
Are you still sure after my objection above?
Yes, if the legacy chunk format can be replaced with a messaging based version, then yes, I'm still sure. See the crucial section above and welcome to the future of language design where meta and normal operations are unified in one elegant syntax using Smalltalk style messaging.
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.
They are more similar than you'd think. The main difference is in how they are activated, not in how they are stored.
That is what I'm referring to, in 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).
That might be more or less the same problem I hinted at above.
yes.
Yes, those are technical terms; for an in depth discussion on them this article is excellent:
Thanks, I'm reading it.
What are your thoughts on it?
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?
AFAIK, these are
{...} RHS (GNU, Squeak) {...} LHS (old Squeak only?) #{...} (GNU, VW) namespaces (GNU, VW, VA, ST/X) #[...] (all?) ##(...) (GNU, VA, Dolphin) pragmas (many but with different implementation details)
That's a good start. Cool. Oh, extensions to primitives by VW.
Sorry for snipping so much of the rest, it was useful to understand your POV but it is not something that I can "answer" or "object to"; just a note:
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 ">"?
Because $8r40 is weird but valid Smalltalk (sends r1000 to the character 8), while $<8r40> would be the same as the space character (ASCII 32). Anyway, you see, this is a syntax extension. :-)
Well, you raise some valid points. However, I really like the $16r1000 format for creating the character (not the message send). In a way Smalltalk has an anomaly in that numbers can be confusing. Why should 16r1000 work in one context as a number but not in another? So, while it might be a minor syntax change it doesn't add new weird syntax, (e.g. "<16r1000>"), it just corrects a minor issue in the existing EBNF of the language so that numbers are uniformly interpreted the same in the context of creating a character with the "$" syntax (and other places as needed). I'll look into this deeper.
All the best,
Peter
On 14/09/2007, Peter William Lount peter@smalltalk.org wrote:
Person addInstanceMethod: [firstName: aString | firstName := aString ].
Not so easy.
Yes, so very easy.
How do you guarantee that "firstName" is in scope when the block is compiled?
Why would you? Smalltalk is a dynamic language.
Maybe but Smalltalk also has lexical scoping, and here firstName seems to need some kind of dynamic scope. IMHO that's counter-intuitive. The semantics of Smalltalk were made to be simple, better to keep them so.
When we brainstormed on Sapphire's syntax, I proposed to add a new literal for parsed-but-not-yet-compiled-syntax. You would then pass those objects to reflective methods in charge of installing that code in the system (and thus resolving variables and such). IMHO it's better to clearly distinguish between program text and actual system behavior.
BTW I was also pushing for using an executable form for fileins: filing in a file would be the same making a "do it" on the file's contents, installing code in the system while the doit runs. Now I'm really not sure it's a good idea compared to a declarative syntax that allows tools to manipulate the code as an abstract structure without installing it.
On 14/09/2007, Damien Pollet damien.pollet@gmail.com wrote:
On 14/09/2007, Peter William Lount peter@smalltalk.org wrote:
Person addInstanceMethod: [firstName: aString | firstName := aString ].
Not so easy.
Yes, so very easy.
How do you guarantee that "firstName" is in scope when the block is compiled?
Why would you? Smalltalk is a dynamic language.
Maybe but Smalltalk also has lexical scoping, and here firstName seems to need some kind of dynamic scope. IMHO that's counter-intuitive. The semantics of Smalltalk were made to be simple, better to keep them so.
When we brainstormed on Sapphire's syntax, I proposed to add a new literal for parsed-but-not-yet-compiled-syntax. You would then pass those objects to reflective methods in charge of installing that code in the system (and thus resolving variables and such). IMHO it's better to clearly distinguish between program text and actual system behavior.
BTW I was also pushing for using an executable form for fileins: filing in a file would be the same making a "do it" on the file's contents, installing code in the system while the doit runs. Now I'm really not sure it's a good idea compared to a declarative syntax that allows tools to manipulate the code as an abstract structure without installing it.
Yes, i often, before installing changeset browsing it, looking that it don't replaces my own methods by occasion e.t.c.
P.S. LOL, i'm just found myself pressing cmd-s in browser and wondering why it's not sending mail :)
-- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org
To be honest, I don't think it matters what the format is. It could just as well be XML. I think if we have a really good, Smalltalk neutral revision system all "file in" work could be done with that tool exclusively. At that point all dependency problems, etc. are the job of the RCS.
On 9/14/07, Damien Pollet damien.pollet@gmail.com wrote:
On 14/09/2007, Peter William Lount peter@smalltalk.org wrote:
Person addInstanceMethod: [firstName: aString | firstName := aString ].
Not so easy.
Yes, so very easy.
How do you guarantee that "firstName" is in scope when the block is compiled?
Why would you? Smalltalk is a dynamic language.
Maybe but Smalltalk also has lexical scoping, and here firstName seems to need some kind of dynamic scope. IMHO that's counter-intuitive. The semantics of Smalltalk were made to be simple, better to keep them so.
When we brainstormed on Sapphire's syntax, I proposed to add a new literal for parsed-but-not-yet-compiled-syntax. You would then pass those objects to reflective methods in charge of installing that code in the system (and thus resolving variables and such). IMHO it's better to clearly distinguish between program text and actual system behavior.
BTW I was also pushing for using an executable form for fileins: filing in a file would be the same making a "do it" on the file's contents, installing code in the system while the doit runs. Now I'm really not sure it's a good idea compared to a declarative syntax that allows tools to manipulate the code as an abstract structure without installing it.
-- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org
On 14/09/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
To be honest, I don't think it matters what the format is. It could
The point was, it has to be a format, not a program :)
just as well be XML. I think if we have a really good, Smalltalk neutral revision system all "file in" work could be done with that tool exclusively. At that point all dependency problems, etc. are the job of the RCS.
On 9/14/07, Damien Pollet damien.pollet@gmail.com wrote:
On 14/09/2007, Peter William Lount peter@smalltalk.org wrote:
Person addInstanceMethod: [firstName: aString | firstName := aString ].
Not so easy.
Yes, so very easy.
How do you guarantee that "firstName" is in scope when the block is compiled?
Why would you? Smalltalk is a dynamic language.
Maybe but Smalltalk also has lexical scoping, and here firstName seems to need some kind of dynamic scope. IMHO that's counter-intuitive. The semantics of Smalltalk were made to be simple, better to keep them so.
When we brainstormed on Sapphire's syntax, I proposed to add a new literal for parsed-but-not-yet-compiled-syntax. You would then pass those objects to reflective methods in charge of installing that code in the system (and thus resolving variables and such). IMHO it's better to clearly distinguish between program text and actual system behavior.
BTW I was also pushing for using an executable form for fileins: filing in a file would be the same making a "do it" on the file's contents, installing code in the system while the doit runs. Now I'm really not sure it's a good idea compared to a declarative syntax that allows tools to manipulate the code as an abstract structure without installing it.
-- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org
Hi,
Jason Johnson wrote:
To be honest, I don't think it matters what the format is. It could just as well be XML. I think if we have a really good, Smalltalk neutral revision system all "file in" work could be done with that tool exclusively. At that point all dependency problems, etc. are the job of the RCS.
The take home point is to eliminate alternative syntaxes for new capabilities. The alternative capability should be placed in the library.
Yes it may be fine to have a standard XML exchange format for those that like XML as that would be in the "library" and not in the language itself.
However, it's vitally important to have a Smalltalk based format that is expressed fully with pure message based syntax. I've shown that that is not just possible but desirable.
On 9/14/07, Damien Pollet damien.pollet@gmail.com wrote:
On 14/09/2007, Peter William Lount peter@smalltalk.org wrote:
Person addInstanceMethod: [firstName: aString | firstName := aString ].
Not so easy.
Yes, so very easy.
How do you guarantee that "firstName" is in scope when the block is compiled?
Why would you? Smalltalk is a dynamic language.
Maybe but Smalltalk also has lexical scoping, and here firstName seems to need some kind of dynamic scope. IMHO that's counter-intuitive. The semantics of Smalltalk were made to be simple, better to keep them so.
Obviously the reference to "firstName" in the example above would need to be tagged as needing resolution: what is it? a parameter? a instance variable reference? a reference to an enclosing method? What scoping context does it belong to? That doesn't need to be determined at compile time! It can be determined and resolved at "construction" time when the block is added to a class. It can be resolved at runtime. If it can't be resolved obviously a #unresolvedVariableReference error would need to be generated.
When we brainstormed on Sapphire's syntax, I proposed to add a new literal for parsed-but-not-yet-compiled-syntax. You would then pass those objects to reflective methods in charge of installing that code in the system (and thus resolving variables and such).
Sounds interesting. Can you provide examples?
IMHO it's better to clearly distinguish between program text and actual system behavior.
Yes, but it's best to NOT have two or more different syntaxes! Both program text and system behavior configuration can be implemented with ONE unified message based syntax using unary, binary and keyword messages.
As a matter of programming style the two concerns can be kept separate if needed. The IDE can even provide "code review" warnings. This code review "suggestions" and "warnings" is a highly successful approach at a major Smalltalk installation.
People want to put all kinds of new syntaxes into Smalltalk. Don't forget that we have one of the most powerful development environments on the planet (and as far as we currently know, in the universe ;--)! Almost all of the syntax enhancements that people suggest are better in the library and the IDE. Let's put them there!
BTW I was also pushing for using an executable form for fileins: filing in a file would be the same making a "do it" on the file's contents, installing code in the system while the doit runs.
That is essentially what I've show can easily be done while using Smalltalk. Filein's become do its. Certainly for a standard file in format the language syntax and messages used in the filein need to be standardized in a library for file ins. I would suggest that that library be under an open BSD+D license so that all the vendors can make use of it freely.
Now I'm really not sure it's a good idea compared to a declarative syntax that allows tools to manipulate the code as an abstract structure without installing it.
It's way better to use the existing messaging syntax than a special declarative "syntax". The "declarations" can be made within the existing Smalltalk message passing syntax of unary, binary and keyword syntaxes. This has the benefit of eliminating the need for other syntax forms and enables the extensibility of the declarative system itself! All, I repeat, ALL META DATA and META OPERATIONS can be achieved with message syntax!
Damien Pollet type less, do more [ | ]
Nice signature statement.
All the best,
Peter
but you can also do that with a declarative syntax as is implemented in Stef's Sapphire or in GST 3.0 betas.
ALL META OPERATIONS CAN BE DONE WITH STANDARD SMALLTALK SYNTAX Adding the variables to the class in my examples is a declarative statement! It's just expressed in the language of messaging itself! Why
Then it's a different language that happens to use the same grammar. Confusing.
To be declarative, your language for "changesets" should only accept messages like #addInstanceVariable: you mention. I suppose it would have messages for declaring packages , protocols etc. But since the grammar is the same, users will be tempted to insert chunks of imperative Smalltalk in places. What do you do then? ignore them and only consider the declarative messages you know about? then you're not using the semantics of Smalltalk.
All meta operations can be done with standard Smalltalk syntax of unary, binary and keyword syntax messages!
Sure, they are. But those messages exist to implement tools like the compiler, not to declaratively describe code.
There is almost zero need to use any new syntaxes to do the job when Smalltalk style messaging syntax is the most potent syntax.
I don't get why you're so obsessed with reusing (abusing?) the existing textual grammar of Smalltalk, which is incomplete since it only covers method patterns and bodies.
We do currently have a "syntax" for declaring packages and classes and protocols, in the form of the Browser's graphical interface, but it's obviously not practical to scan screenshots of the browser to file-in code. So we're searching for a textual, declarative alternative.
Damien Pollet wrote:
but you can also do that with a declarative syntax as is implemented in Stef's Sapphire or in GST 3.0 betas.
ALL META OPERATIONS CAN BE DONE WITH STANDARD SMALLTALK SYNTAX Adding the variables to the class in my examples is a declarative statement! It's just expressed in the language of messaging itself! Why
Then it's a different language that happens to use the same grammar. Confusing.
No, it seems that you didn't understand. It's just the same as standard smalltalk class definitions - in fact you could simply use those messages if you wanted (I don't like them since the variable names are just in a string but whatever).
It's no different than what chunk format does now and has done since the beginning of Smalltalk time anyhow.
Again it's how you evaluate the block isn't it! So, this is our fourth block evaluator!
1) Normal Smalltalk statement evaluator returning last result. 2) Collecting results from statements evaluator that returns a collection of the results of all statements. 3) Forking statements in parallel and rejoining them evaluator for specifying parallelism (for N-Core processors). 4) "File In" format evaluator that supports mixed declarations and regular smalltalk programs. (This evaluator may actually not be needed as it likely can simply be part of (1), (2) and (3) above, but it's here for clarity of thought).
The list grows step by step. The future is taking shape.
To be declarative, your language for "changesets" should only accept messages like #addInstanceVariable: you mention. I suppose it would have messages for declaring packages , protocols etc.
Yes, that would all need to be standardized to ensure portability. But that's easy since it's in the library of objects! If the library is made open source with a true-free source license such as BSD then all the vendors can use it without any complications. There could be an additional clause that those that use it would need to adhere to the Smalltalk File In Standard and process for adding new features.
But since the grammar is the same, users will be tempted to insert chunks of imperative Smalltalk in places. What do you do then?
Execute the imperative code. The two can be mixed at will.
ignore them and only consider the declarative messages you know about? then you're not using the semantics of Smalltalk.
No, the semantics of Smalltalk stay the same, or essentially the same. When you change classes at runtime in smalltalk it's no different than what I'm suggesting. In fact Smalltalk heads towards a more pure smalltalk than ever before in terms of it maximizing the big idea of message passing and message passing syntax.
All meta operations can be done with standard Smalltalk syntax of unary, binary and keyword syntax messages!
Sure, they are. But those messages exist to implement tools like the compiler, not to declaratively describe code.
Why not? It's not just elegant it's making use of the power of messaging. The big idea in Smalltalk is messaging.
All META operations, such as declarations can be done with message passing. It's simple. It's elegant and it's Smalltalk's way.
There is almost zero need to use any new syntaxes to do the job when Smalltalk style messaging syntax is the most potent syntax.
I don't get why you're so obsessed with reusing (abusing?) the existing textual grammar of Smalltalk, which is incomplete since it only covers method patterns and bodies.
The same syntax can cover anything that needs to be expressed including ALL meta data of the virtual machine. The same syntax can be extended - in the library - to express other programming paradigms and data-structure organizations other than objects and classes. All types of object models are expressible. The message passing syntax of Smalltalk in combination with an object library are a potent concept that is highly expressive. Think about it for a while. I have.
We do currently have a "syntax" for declaring packages and classes and protocols, in the form of the Browser's graphical interface, but it's obviously not practical to scan screenshots of the browser to file-in code. So we're searching for a textual, declarative alternative.
The textual declarative alternative is here. I've described it. It can handle any kind of declaration that you need. It is extensible, once implemented, via a standard object library. It's based upon message passing syntax, so it exists as first class objects in Smalltalk's world.
I can answer all questions about it. If I can't answer a question this is a very smart group and solutions are within reach.
The point is that the declaration is expressed in existing message passing syntax. The "declarations" are objects that assist the compiler in it's job. They are new objects that would be added when and if needed.
All the best,
Peter
On 9/13/07, Peter William Lount peter@smalltalk.org wrote:
(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.
How is publishing a private email someone sends you without warning as use for an attack not a means of damaging their credibility in the conversation (and therefor stifling them)?
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.
This is quite interesting indeed. I just can't see the cache dancing Intel is doing being able to scale much further.
[ Object subclass: #Person.
"<snip>"
] fileInWithinTransaction.
If we came up with a nice replacement for chunk format that would probably be a good thing, though Craig may solve it another way.
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!
I agree that it's very important to limit new syntax for the language. C++ failed to do this and has fallen out of favor, Java has started down this dead end of ever increasing complexity and as you point out Perl was pretty much always unnecessarily complex.
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.
Well, I personally try to ask the person before going off the handle (though not always ;), but if the person truly is trolling then they will lie so the questions don't help at all.
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.
You must be no fun at parties then. ;) In some theoretical vacuum every idea must stand on it's own merits whether it came from Einstein or the world's dumbest person. But from a practicality stand point this just wastes too much time. And saying someone is using ad hominem attacks is casting a negative light on that person, weakening their positions in the discussion and is therefor ad hominem itself', even if true.
Of course you can say it's ok if they truly were using an ad hominem attack, but according to logic all ideas must stand on their own merits, no? So even someone with bad behavior shouldn't be thrown in a negative light so that he isn't taken seriously. ;)
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.
Yes, this is quite important to keep in mind imo. Contrary to what Mr. Schwartz said earlier in the thread, when the language is complex it complicates everything built on top of it. If the language is simple then only the complicated problems are complicated, and even then the solution is sometimes simple (as it should be).
I am reliving this reality once again with a "perl to python" conversion at work. Despite python's warts, every single program I have converted so far has been much shorter and at the same time more clear.
Also note that his statement that "having to learn tons of libraries before being able to do anything" is not valid either. Think about "hello world", the first program you learn in most languages. In C, C++, C#, Java, Smalltalk, Lisp, etc., this is done with a library, while in the scripting languages it's usually built in, but what's the impact of this? Nothing, the beginner doesn't care if print is built in or not, it's no harder to use in either case. But if it's in a library he can enhance it later.
Oh great, the wonderful world of types. Sigh. Yes, I know that they are needed for interfacing to other systems. Types, sigh.
Don't be so down on types just because of languages with broken type systems. :) Though I do find programming in a late bound, interactive system like Smalltalk much much faster. A language with a really good type system like Haskell forces a lot of thinking and designing up front before you actually write code. In Smalltalk it's more like clay. :)
"Jason" == Jason Johnson jason.johnson.081@gmail.com writes:
Jason> How is publishing a private email someone sends you without warning as Jason> use for an attack not a means of damaging their credibility in the Jason> conversation (and therefor stifling them)?
It is also arguably a violation of copyright, and could be actionable.
Randal L. Schwartz wrote:
"Jason" == Jason Johnson jason.johnson.081@gmail.com writes:
Jason> How is publishing a private email someone sends you without warning as Jason> use for an attack not a means of damaging their credibility in the Jason> conversation (and therefor stifling them)?
It is also arguably a violation of copyright, and could be actionable.
Hi,
Nonsense, it's valid fair use. Learn copyright law.
Cheers,
Peter
"Peter" == Peter William Lount peter@smalltalk.org writes:
Peter> Nonsense, it's valid fair use. Learn copyright law.
Nonsense, there's caselaw that says that letters sent from person A to B were owned by A, because B wanted to publish them when A became famous.
I forget the specifics, but it's been decided.
That is why I said *arguable*. I don't think anyone's argued the email case, but the physical mail case has precedent.
Don't wave "fair use" so broadly. It really isn't that broad.
Could you take this off-list, please? Or at least flag as off-topic?
Thanks,
- Bert -
On Sep 14, 2007, at 21:03 , Randal L. Schwartz wrote:
"Peter" == Peter William Lount peter@smalltalk.org writes:
Peter> Nonsense, it's valid fair use. Learn copyright law.
Nonsense, there's caselaw that says that letters sent from person A to B were owned by A, because B wanted to publish them when A became famous.
I forget the specifics, but it's been decided.
That is why I said *arguable*. I don't think anyone's argued the email case, but the physical mail case has precedent.
Don't wave "fair use" so broadly. It really isn't that broad.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Randal L. Schwartz wrote:
"Peter" == Peter William Lount peter@smalltalk.org writes:
Peter> Nonsense, it's valid fair use. Learn copyright law.
Nonsense, there's caselaw that says that letters sent from person A to B were owned by A, because B wanted to publish them when A became famous.
I forget the specifics, but it's been decided.
That is why I said *arguable*. I don't think anyone's argued the email case, but the physical mail case has precedent.
Don't wave "fair use" so broadly. It really isn't that broad.
Note: the subject heading was "Re: Fear and loathing of the "perification" of Smalltalk".
Hi,
Fair use applies in this situation.
There are also other laws other than copyright to consider. In British Columbia, where I am located, a party to a conversation may make it public if it's in defense of their person as my posting clearly was. End of story.
Also I didn't retaliate with any personal attack. I simply stated the facts of what was said and asked the person to stop their attacks, which seems to have occurred as the subsequent email-posting exchange shows. Furthermore, out of a desire to have positive conversions subsequently follow, I provided suggestions of how to ask appropriate questions rather than initiate ad hominem attacks.
I suppose that you support ad hominem attacks upon the person even if they are sent privately to attempt to influence, "bully" or "inflame" someone's behavior in a negative way with false accusations?
How would you have handled it in a way that would positively influence the person's initiating the ad hominem person attack?
All the best,
Peter William Lount peter@smalltalk.org
Since this is an off topic thread, I'd like to know something Mr. Lount about your assembly programming and Gemstone Warrior. I played that game in the 80's on an Apple here in Southern Ontario (Oakville). I now own a Commodore 64 and a copy of Jim Butterfield's book on machine language. (He just past away in June.)
I want to know if the chip you wrote assembler for was a 6502, as Apple's had used that chip in the Apple 2 line. And whether you learned from Butterfield's book. If not, with what books and for what chip did you learn assembler?
Chris Cunnington Toronto
hi Chris,
Hi Chris,
Chris Cunnington wrote:
Since this is an off topic thread, I'd like to know something Mr. Lount about your assembly programming and Gemstone Warrior. I played that game in the 80's on an Apple here in Southern Ontario (Oakville).
Very cool.
I now own a Commodore 64 and a copy of Jim Butterfield's book on machine language. (He just past away in June.)
I want to know if the chip you wrote assembler for was a 6502, as Apple's had used that chip in the Apple 2 line.
Yes, the chip was a 6502. The one that shipped in the Apple. Later on - as in much later on - I installed a zip chip that took the processor speed up from 1mhz (yes, one megahertz) to a wopping 10mhz! Wow, ten times faster and Gemstone wasn't even playable!
And whether you learned from Butterfield's book. If not, with what books and for what chip did you learn assembler
I don't recall which book the "Butterfield" book is. I have a whole box of Apple ][ books in storage. I'd have to look at them. The book was a green instruction set manual possibly published by MOS themselves or someone like Osborne (who was the O'Reily books of that era). I have a lot of Apple two magazines. I also worked full time selling Apple ][ systems for up to $14,000 a pop (with printers and VisiCalc to be sure). (Ah, those days are long gone though!) The game was also ported to the C64 and Atari 800 by my team. Those were slightly different 6502 chips and obviously different graphics hardware too.
In the following years I've studied many instruction sets. After a while they are essentially the except in the pesky details of getting it right with whatever processor you happen to be working on at the time. The biggest differences are in the number of registers, the control registers, the processor bit width (8, 16, 32, 64, etc...), and their different syntaxes. Nowadays there are many more instructions especially on the X86 lines. Recently I'm looking at MIPS again since I'm interested in the Tile64 processors.
Are you planning on working with 6502? Or other assembly langauges? What are you working on if I may ask?
Cheers,
peter
Thank you very much for replying. Well, I'm newish to computers and programming. I'm surrounded at the computer clubs I attend here in Toronto such as Unix Unanimous, The Toronto Linux Users Group, The Beach Outings Club (my Smalltalk club) by people who have been programming forever.
I'm also a member of the Toronto PET Users Group, which has been going since 1979. That's PET as in Personal Electronic Transactor from 1977 and Commodore. Next week I'll be going to TPUG to attend a discussion about Demo programming. That's in the Demoscene, which is mainly Europeans writing video demonstrations and SID chip music on their Commodore 64's and Amigas. Wild, really, that they do that.
I mentioned Jim Butterfield, because I wasn't programming in the early 1980s, and I know he's famous amongst people here in Toronto and, obviously, at TPUG, so I assumed you'd heard of him. A bit of a stretch, I guess.
So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The Art of Assembly Language" for the 80x86 set. The point of this is that I've gotten into a large topic -- computer programming -- and I keep trying to see it from different points of view. Assembly seems to me another great, bottom up way to learn about this stuff. Being surrounded by people who know so much more can be anxiety producing, so I'm climbing the learning curve, and I favour the historical approach, thus the interest in old computers, Commodore, and such.
I liked playing Gemstone Warrior. Actually all my brothers and sister did.
Commodore 64. Still Ready.
Cheers,
Chris Cunnington
Chris Cunnington wrote:
Thank you very much for replying. Well, I'm newish to computers and programming. I'm surrounded at the computer clubs I attend here in Toronto such as Unix Unanimous, The Toronto Linux Users Group, The Beach Outings Club (my Smalltalk club) by people who have been programming forever.
I'm also a member of the Toronto PET Users Group, which has been going since 1979. That's PET as in Personal Electronic Transactor from 1977 and Commodore. Next week I'll be going to TPUG to attend a discussion about Demo programming. That's in the Demoscene, which is mainly Europeans writing video demonstrations and SID chip music on their Commodore 64's and Amigas. Wild, really, that they do that.
I mentioned Jim Butterfield, because I wasn't programming in the early 1980s, and I know he's famous amongst people here in Toronto and, obviously, at TPUG, so I assumed you'd heard of him. A bit of a stretch, I guess.
So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The Art of Assembly Language" for the 80x86 set. The point of this is that I've gotten into a large topic -- computer programming -- and I keep trying to see it from different points of view. Assembly seems to me another great, bottom up way to learn about this stuff. Being surrounded by people who know so much more can be anxiety producing, so I'm climbing the learning curve, and I favour the historical approach, thus the interest in old computers, Commodore, and such.
I liked playing Gemstone Warrior. Actually all my brothers and sister did.
Commodore 64. Still Ready.
Cheers,
Chris Cunnington
Hi,
Thanks, I'll let Trouba know that you liked the game and that we talked about it. He and I designed the game together. I did the programming and he did the graphics.
Assembly language is a great way to learn computing. Once you learn that then you know it's much harder for people to pass off nonsense by you. You comprehend the details much better.
If you can program 6502 then you can program any processor out there. You may wish to start learning with the latest version of the X86 processor family though. Learning that could be better for your career - assuming that's a direction in your life.
I learned assembly before pretty much any other language. I learned 32 bit Interdata assembly before I learned Basic! My favorite languages are Assembly Language, Smalltalk and ZokuScript. That green 6502 book I mentioned is very well worn indeed.
To me Smalltalk has become the new assembly language.
That's why I'm building ZokuScript - it's the a higher level language that builds upon the concepts of languages like Smalltalk, Lisp, Erlang, Assembly, Forth, Io, Self, Slang, etc....
While performing an exhaustive search through the possible spaces in the universe of language syntaxes I've come across some enhancements that work naturally for Smalltalk while keeping true to the first principles of messaging passing syntax, everything is an object including ALL meta data and meta operations.
I'm contributing those discoveries to the Smalltalk community in the hopes that some of them will be adopted. All of the discoveries and ideas that I've presented, plus many more, are going into the ZokuScript language since the applications and systems that I'm building require certain linguistic capabilities not easily expressible in existing languages without a lot of work.
I encourage you to continue your efforts with assembly language.
Cheers,
Peter
On Fri, 14 Sep 2007 17:50:06 -0400, Chris Cunnington cunnington@sympatico.ca wrote:
So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The Art of Assembly Language" for the 80x86 set. The point of this is that I've gotten into a large topic -- computer programming -- and I keep trying to see it from different points of view. Assembly seems to me another great, bottom up way to learn about this stuff. Being surrounded by people who know so much more can be anxiety producing, so I'm climbing the learning curve, and I favour the historical approach, thus the interest in old computers, Commodore, and such.
I started programming on a Commodore PET, in 6502 assembler. After a year or two, my parents bought me an Apple //c, which had a 65c02 (extended instruction set over the 6502). I spent many years writing a lot of 6502 assembler on that computer, and if you look through a pile of COMPUTE or Nibble magazines, you might find a couple articles with code that I had published back in the mid-80's.
About 10 years ago, I got a hankering to do this kind of low level on-the-metal programming, but doing stuff on a 64 or Apple 2 just wasn't going to cut it. About that time I decided to get into robotics and embedded programming on 8-bit RISC microcontrollers, which feels a lot like programming a 6502.
In 1998 I wrote a really simple compiler that translated pseudo-Smalltalk code into PIC assembler to run on a PIC. The PIC I was using at the time had 68 bytes of RAM and 1024 words of program FLASH, and I was able to control a servo, talk to an LCD, and a few other things with PIC/Smalltalk.
http://www.huv.com/uSeeker/smalltalk/pic.html
Anyways, the point being you can still get the same "feel" as programming on those old systems with nice new 8-bit RISC microcontrollers like the PIC or the AVR (my current favourite).
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
I spent many years writing a lot of 6502 assembler on that computer, and if you look through a pile of COMPUTE or Nibble magazines, you might find a couple articles with code that I had published back in the mid-80's.
You wrote "Hi-Res Graphics Aid Routines" in issue #71 in April of 1986. I know people who have sets of this magazine in the original. And I'll look out for a copy at World of Commodore on Dec. 1 in Etobicoke.
I'm definitely going to have to take a look at your Microseeker PIC/Smalltalk page. The PET was the first computer I ever saw and touched back in grade six.
Thanks!
Chris Cunnington
Hello Chris,
CC> So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The CC> Art of Assembly Language" for the 80x86 set. The point of this is that I've
6502 had a nice and simple assembler so I think this is a good processor to start. You can also try 6800 Family.
Imho stay a way from the 8080 Family if you can. They are much like "Is it possible to ...?" "Yes in principle but..." things. Lots and lots of special conditions to remember. Imho this unnecessarily hides the insights to be gained from programming hardware in assembly.
If you plan to program on an 8 Bit system Assembly and Forth go together well. If you plan to program on a PC and run the code on the 8 bitter follow John's suggestion of Atmel microcontrollers or similar. They have a "reasonable" assembly language (think RISC vs. CISC) and a cross compiler running under Eclipse or some IDE.
Cheers
Herbert mailto:herbertkoenig@gmx.net
El 9/14/07 6:50 PM, "Chris Cunnington" cunnington@sympatico.ca escribió:
Thank you very much for replying. Well, I'm newish to computers and programming. I'm surrounded at the computer clubs I attend here in Toronto such as Unix Unanimous, The Toronto Linux Users Group, The Beach Outings Club (my Smalltalk club) by people who have been programming forever.
I'm also a member of the Toronto PET Users Group, which has been going since 1979. That's PET as in Personal Electronic Transactor from 1977 and Commodore. Next week I'll be going to TPUG to attend a discussion about Demo programming. That's in the Demoscene, which is mainly Europeans writing video demonstrations and SID chip music on their Commodore 64's and Amigas. Wild, really, that they do that.
I mentioned Jim Butterfield, because I wasn't programming in the early 1980s, and I know he's famous amongst people here in Toronto and, obviously, at TPUG, so I assumed you'd heard of him. A bit of a stretch, I guess.
So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The Art of Assembly Language" for the 80x86 set. The point of this is that I've gotten into a large topic -- computer programming -- and I keep trying to see it from different points of view. Assembly seems to me another great, bottom up way to learn about this stuff. Being surrounded by people who know so much more can be anxiety producing, so I'm climbing the learning curve, and I favour the historical approach, thus the interest in old computers, Commodore, and such.
I liked playing Gemstone Warrior. Actually all my brothers and sister did.
Commodore 64. Still Ready.
Cheers,
Chris Cunnington
I miss the first mail but see the replies. I was a 6502 and Apple II fan. Maybe you wish know is possible to have Apple II inside Squeak, I attach the files. And I have a odd proposal to you.. What if we build a Morphic simulator of the 6502 chip ? Kind a educational project ... Could be useful to some, I think.
Edgar
On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
I miss the first mail but see the replies. I was a 6502 and Apple II fan.
Wow, so many 6502 fans. 6502 was my first assembler. Basic + ASM where needed was how I did most of my projects.
Anyone remember "shape tables"?
Blake wrote:
On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
I miss the first mail but see the replies. I was a 6502 and Apple II fan.
Wow, so many 6502 fans. 6502 was my first assembler. Basic + ASM where needed was how I did most of my projects.
My first was 6809. Close enough. I even made a computer with that CPU. Yes, with my own hands, back in year 1982, when I was in second year of secondary school. That were times! 3KB of RAM, only persistence was 512K EPROM, programming directly in machine hex codes, ...
Now, back to Squeak ...
Best regards Janko
Blake wrote:
On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
I miss the first mail but see the replies. I was a 6502 and Apple II fan.
Wow, so many 6502 fans. 6502 was my first assembler. Basic + ASM where needed was how I did most of my projects.
Anyone remember "shape tables"?
Hi,
Ah yes, shape tables!
Gemstone Warrior didn't use shape tables as you know them. It did have tables for it's graphics though. I was inspired by Smalltalk, which I had read about but hadn't gotten my hands onto quite yet, when I wrote Gemstone Warrior. All the objects the user could manipulate were inspired by Smalltalk's notion of objects at the UI level.
While there was a Smalltalk for the Apple ][, Rosettastone Smalltalk, Gemstone Warrior was only partially objects. I was working on a object-message system for a subsequent game on the Apple ][ but by that time the IBM PC dominated the market and the Mac was coming into it's own with success. Sigh...
Each of the Tile 64 Processors is thousands of more times more powerful than that old 6502 based Apple ][ system. I can imagine what Gemstone Warrior would be like on it! Fully object oriented, fully message oriented, fully 4-D (3D+Time)!
If you really want a chip to play with as a hobby with potential for future success play with the Tile 64 chip!
Smalltalk on the Tile 64 chip will be hot! When will it happen?
Cheers,
Peter
CC'ed to the hardware list
On Sat, Sep 15, 2007 at 02:26:47PM -0700, Peter William Lount wrote:
Each of the Tile 64 Processors is thousands of more times more powerful than that old 6502 based Apple ][ system. I can imagine what Gemstone Warrior would be like on it! Fully object oriented, fully message oriented, fully 4-D (3D+Time)!
If you really want a chip to play with as a hobby with potential for future success play with the Tile 64 chip!
Smalltalk on the Tile 64 chip will be hot! When will it happen?
Jecel Assumpcao Jr. is working on a quite similar project. He is putting Neo Smalltalk [1] on a 9-core Plurion [2] processor. He has said he will follow this up with a port of Spoon. More information can be found on his hardware Swiki [3].
I'll be working with him on this project as part of my graduate studies.
[1]. Neo Smalltalk: http://www.merlintec.com:8080/software http://wiki.squeak.org/squeak/5637
[2]. A very out-of-date description of Plurion architecture: http://www.merlintec.com/download/plurion.pdf
A description of the actual processor being used: http://www.merlintec.com:8080/hardware/32
[3]. Jecel's hardware Swiki: http://www.merlintec.com:8080/hardware
Matthew Fulmer wrote on Sat, 15 Sep 2007 15:03:52 -0700
On Sat, Sep 15, 2007 at 02:26:47PM -0700, Peter William Lount wrote:
Each of the Tile 64 Processors is thousands of more times more powerful than that old 6502 based Apple ][ system. I can imagine what Gemstone Warrior would be like on it! Fully object oriented, fully message oriented, fully 4-D (3D+Time)!
If you really want a chip to play with as a hobby with potential for future success play with the Tile 64 chip!
Smalltalk on the Tile 64 chip will be hot! When will it happen?
Note that this is a pretty expensive chip (around $500 in large quantities). There are some cheaper (but with memory limitations that might make them hard to use for Smalltalk) processor arrays:
http://www.intellasys.net/ http://www.parallax.com/propeller/index.asp
Some more expensive alternatives:
http://www.streamprocessors.com/ http://www.cradle.com/ http://www.stretchinc.com/
Here are some FPGA-like processor arrays pretty much in the spirit of RAW (the MIT project where the Tile 64 comes from):
http://www.ambric.com/ http://www.mathstar.com/ http://www.brightscale.com/ http://www.picochip.com/
Jecel Assumpcao Jr. is working on a quite similar project. He is putting Neo Smalltalk [1] on a 9-core Plurion [2] processor. He has said he will follow this up with a port of Spoon. More information can be found on his hardware Swiki [3].
I'll be working with him on this project as part of my graduate studies.
As soon as I finish a text I am writing (plan for master's thesis work - has nifty things like compiling Smalltalk into hardware objects. Sadly, it is in Portuguese), I will start working on this implementation. The idea is to make this development as open as possible, with a public version control system, a bug tracker and a blog. This would be a good thing to implement in Seaside but perhaps I should start out with existing solutions to get results faster?
It would be interesting if people could look at the (extremely bare, sorry) description of the instruction set (Matthew gave the link in his email, but here it is again - http://www.merlintec.com:8080/hardware/32) and give their opinions. This is a RISC design, not a bytecoded stack machine like I had previously been doing. The idea here is to play nice with the C world (very important for Squeak, not as much for my own Smalltalk) while still being a good learning experience for someone digging deeper and deeper (starting with eToys, for example, then Smalltalk-80 code, then meta stuff and so on) until they get to the hardware level.
If I can get 9 cores running at 240MHz on my ML401 development board then we will have a very reasonable view of what future Smalltalk computers will be like.
-- Jecel
On 15-Sep-07, at 1:44 PM, Blake wrote:
On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
I miss the first mail but see the replies. I was a 6502 and Apple II fan.
Wow, so many 6502 fans.
6502 fans designed the original ARM; look what happened to that - it's everywhere. Most of us are likely to have at least 4 or 5 ARMs in our home.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Wise as the world is flat.
On Sat, 15 Sep 2007 18:52:27 -0700, tim Rowledge tim@rowledge.org wrote:
On 15-Sep-07, at 1:44 PM, Blake wrote:
On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
I miss the first mail but see the replies. I was a 6502 and Apple II fan.
Wow, so many 6502 fans.
6502 fans designed the original ARM; look what happened to that - it's everywhere. Most of us are likely to have at least 4 or 5 ARMs in our home.
I did not know that!
http://en.wikipedia.org/wiki/ARM_architecture
But it's quite int'resting.
On 15-Sep-07, at 10:19 PM, Blake wrote:
I did not know that!
http://en.wikipedia.org/wiki/ARM_architecture
But it's quite int'resting.
Note the 'shipped 2.45 billion units'. In 2006. Gulp. And to think that people tried to tell us that it would never get anywhere...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Wibble" said Pooh the stress beginning to show.
Note: the subject heading was "Re: Fear and loathing of the "perification" of Smalltalk".
Hi,
General thoughts.
Maybe those making ad hominem personal attacks need to consider the wider ramifications of their accusations before making them. That is being responsible. There are consequences to the person(s) initiating an ad hominem attacks that some of you might not realize.
The new standard of conduct - just don't accuse people of being a "troll" or X in the first place for it's an ad hominem personal attack; furthermore it is designed to stifle opinion and suppress free speech. Do you want your free speech abridged? No, then don't try to suppress others.
People have the right to defend their person and this right even allows them to make private communications public! The best option is to simply ask appropriate on topic questions without attacking people. If unsure of their intent, simply ask them what their intent is.
I'm done with this if you are.
All the best,
Peter
"Peter" == Peter William Lount peter@smalltalk.org writes:
Peter> People have the right to defend their person and this right even allows Peter> them to make private communications public!
Not in violation of federal law. I don't care how you feel. You don't get to violate the law no matter how you "feel".
Randal L. Schwartz wrote:
"Peter" == Peter William Lount peter@smalltalk.org writes:
Peter> People have the right to defend their person and this right even allows Peter> them to make private communications public!
Not in violation of federal law. I don't care how you feel. You don't get to violate the law no matter how you "feel".
Hi Mr. Schwartz,
As you know good sir I believe you are mistaken. I was well within the rights of a citizen of Canada to defend one's person.
I've moved on and I think the group has as well. Thank you good sir.
All the best,
Peter
What what does the rest of the group think about what happened?
The way I personally saw it was: One person leans over to another one and wispers in his ear "hey man, are you trolling with this or something?" and the person smiles, walks over to CNN and repeats everything the person said and gives their scathing rebuttal.
In my opinion, I don't see any grounds for it being an issue of "self defense" because no threat was made, and no slander was done sinse it was sent to the person in private.
I find it questional behavior. If the person has been sending this sort of thing over and over then I can see giving a warning of "hey, if you send me another message I'm forwarding it to the mail list to let others know what you're doing", but to do it instantly at the first very minor offense (it's questionable in my mind if it was an offense at all) seems quite over the top to me.
Ironically, such behavior is more likely to "bully" and scare people away from talking to you in general, which is what ad hominem is all about, no? :)
On 9/15/07, Peter William Lount peter@smalltalk.org wrote:
Randal L. Schwartz wrote:
> "Peter" == Peter William Lount peter@smalltalk.org writes: >
Peter> People have the right to defend their person and this right even allows Peter> them to make private communications public!
Not in violation of federal law. I don't care how you feel. You don't get to violate the law no matter how you "feel".
Hi Mr. Schwartz,
As you know good sir I believe you are mistaken. I was well within the rights of a citizen of Canada to defend one's person.
I've moved on and I think the group has as well. Thank you good sir.
All the best,
Peter
Hi,
Jason Johnson wrote:
What what does the rest of the group think about what happened?
The way I personally saw it was: One person leans over to another one and wispers in his ear "hey man, are you trolling with this or something?"
That is a distortion of the facts. Read what he said. He said that I was a "troll". That is entirely different.
Had he said what you are suggesting I'd likely have simply said that he was mistaken, and might even have done so to him privately.
and the person smiles, walks over to CNN and repeats everything the person said and gives their scathing rebuttal.
It is a factual rebuttal to their ad hominem personal attack. If I had conducted a "scathing rebuttal" it wouldn't have been fit to show even on CNN!
In my opinion, I don't see any grounds for it being an issue of "self defense" because no threat was made, and no slander was done sinse it was sent to the person in private.
I find it questional behavior.
Then it sounds like you support ad hominem attacks.
If the person has been sending this sort of thing over and over then I can see giving a warning of "hey, if you send me another message I'm forwarding it to the mail list to let others know what you're doing", but to do it instantly at the first very minor offense (it's questionable in my mind if it was an offense at all) seems quite over the top to me.
I have a zero tolerance to ad hominem attacks especially online. I shout out that when I'm being bullied so that the bully will stop. If that fails to work there are often other remedies.
Ironically, such behavior is more likely to "bully" and scare people away from talking to you in general, which is what ad hominem is all about, no? :)
Nonsense. If you don't use ad hominem personal attacks there is nothing to fear. The record shows that.
Ad hominem personal attacks are simply inappropriate behavior in technical groups and in most of life. They are simply unwise and rarely justified (and in those rare cases only when they have factual basis behind them).
Basically you are saying that one can't defend oneself from them giving the bullies a pass. The person who did the ad hominem personal attack is the one responsible for any consequences. The victim is guilty of speaking up in your eyes. Dam the person attacked and give a pass to the bully making ad hominem personal attacks.
Coming to the attackers defense would be appropriate IF I had called him names, or misrepresented the facts. That isn't the case. I was professional pointing out the personal attack, asking for it to stop which he did as the record of our subsequent conversations show, and offering suggestions on how to avoid ad hominem personal attacks.
Saying that one shouldn't defend against bullies is just plain wrong leaving the person attacked without a means to defend themselves. Society recognizes this and permits the exceptions to privacy that I've indicated numerous times.
Your main objection seems to be what society allows. Your main objection seems to be that someone can't defend themselves when attacked. Too bad. I stand for the right of everyone to defend themselves when bullied and when attacked personally with ad hominem attacks such as being called a troll.
All the best,
Peter
Dear all,
what about opening one or two new squeakfoundation.org mailing lists devoted to the discussion of (a) rhetoric and (b) legal issues related to personal rights?
Michael
And perhaps one for (c) sarcasm?
:-) Josh
On Sep 16, 2007, at 2:29 PM, Michael Haupt wrote:
Dear all,
what about opening one or two new squeakfoundation.org mailing lists devoted to the discussion of (a) rhetoric and (b) legal issues related to personal rights?
Michael
Nah, that belongs on-list.
- Bert -
On Sep 16, 2007, at 23:51 , Joshua Gargus wrote:
And perhaps one for (c) sarcasm?
:-) Josh
On Sep 16, 2007, at 2:29 PM, Michael Haupt wrote:
Dear all,
what about opening one or two new squeakfoundation.org mailing lists devoted to the discussion of (a) rhetoric and (b) legal issues related to personal rights?
Michael
...absolutely.
Michael
On 9/16/07, Bert Freudenberg bert@freudenbergs.de wrote:
Nah, that belongs on-list.
- Bert -
On Sep 16, 2007, at 23:51 , Joshua Gargus wrote:
And perhaps one for (c) sarcasm?
:-) Josh
On Sep 16, 2007, at 2:29 PM, Michael Haupt wrote:
Dear all,
what about opening one or two new squeakfoundation.org mailing lists devoted to the discussion of (a) rhetoric and (b) legal issues related to personal rights?
Michael
Ah, yes, and please open one, where we can discuss how to care to my pet.
On 17/09/2007, Bert Freudenberg bert@freudenbergs.de wrote:
Nah, that belongs on-list.
- Bert -
On Sep 16, 2007, at 23:51 , Joshua Gargus wrote:
And perhaps one for (c) sarcasm?
:-) Josh
On Sep 16, 2007, at 2:29 PM, Michael Haupt wrote:
Dear all,
what about opening one or two new squeakfoundation.org mailing lists devoted to the discussion of (a) rhetoric and (b) legal issues related to personal rights?
Michael
I vote that one more post from either instigator on this thread results both parties being unsubscribed.
Squeak is a nice congenial place. Flamage is not welcome, nor is retaliation for same - I don't care who started what.
End of thread. (I can dream, can't I?)
On Sep 16, 2007, at 2:51 PM, Joshua Gargus wrote:
And perhaps one for (c) sarcasm?
:-) Josh
On Sep 16, 2007, at 2:29 PM, Michael Haupt wrote:
Dear all,
what about opening one or two new squeakfoundation.org mailing lists devoted to the discussion of (a) rhetoric and (b) legal issues related to personal rights?
Michael
*PRIVATE*
Nick Alexander wrote:
On 16-Sep-07, at 3:57 PM, Todd Blanchard wrote:
I vote that one more post from either instigator on this thread results both parties being unsubscribed.
+1.
Nick
Hi Nick,
That would be unfair censorship sir.
My responses in defense are not flamage sir. If you consider it "flamage" then, I submit, that you are in a very direct way supporting online bullying by people who make ad hominem personal attacks and leaving no recourse for those who were attacked to defend themselves. Group awareness of actual personal attacks helps to stop said attacks from occurring in the first place.
I have attempted to end the discussion, however, uninvolved people keep making false and misleading statements and even potentially liableous statements. These outrageous statements do need to be addressed for the record. I have asked them to cease the comments (or to email me directly) but they keep making them publicly.
Now that the direct attacks have stopped (hopefully it stays that way), the sarcasm has started. Oh well, I guess people support the bully after all. It's a strange society we live in where the victim in these matters is punished or treated indifferently by people.
It's also interesting to note that none of these others making statements was involved in the conversation between myself and the person who made an ad hominem attack against me sir, so I don't know what they have to do with it. Really it's not their business especially since the person who made the attack moved on without further personal attacks.
I know that not all agree with defending themselves against those bullies who attack others with personal attacks.
I hope that you never have to deal with people who personally attack you online.
I too can hope to dream that people don't initiate personal attacks in the first place. Especially completely unprovoked and unfounded attacks as in this case. However, I would fully come to your support and assist you in every way I could to defend yourself from such personal attacks.
By the way, I did change the subject heading so people could avoid the posting if they so wished. A little step towards keeping the noise level down.
I personally apologize to you for the distraction it may have caused.
All the best and I look foward to your contributions to Squeak and Smalltalk.
All the best,
Peter
+1
Dat
From: ncalexander@gmail.com Date: Sun, 16 Sep 2007 17:07:02 -0700 To: squeak-dev@lists.squeakfoundation.org Subject: Re: responding to ad hominem person attacks
On 16-Sep-07, at 3:57 PM, Todd Blanchard wrote:
I vote that one more post from either instigator on this thread results both parties being unsubscribed.
+1.
Nick
_________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.a...
I thought this was a mailing list for developers.
Please take this to a mailing list where it is appropriate.
On 15 Sep 2007, at 15 September/08:37, Randal L. Schwartz wrote:
"Peter" == Peter William Lount peter@smalltalk.org writes:
Peter> People have the right to defend their person and this right even allows Peter> them to make private communications public!
Not in violation of federal law. I don't care how you feel. You don't get to violate the law no matter how you "feel".
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
On 9/15/07, Peter William Lount peter@smalltalk.org wrote:
Randal L. Schwartz wrote:
> "Peter" == Peter William Lount peter@smalltalk.org writes:
There are also other laws other than copyright to consider. In British Columbia, where I am located, a party to a conversation may make it public if it's in defense of their person as my posting clearly was. End of story.
...
Also I didn't retaliate with any personal attack. I simply stated the
facts of what was said and asked the person to stop their attacks, which seems to have occurred as the subsequent email-posting exchange shows. Furthermore, out of a desire to have positive conversions subsequently follow, I provided suggestions of how to ask appropriate questions rather than initiate ad hominem attacks.
I suppose that you support ad hominem attacks upon the person even if they are sent privately to attempt to influence, "bully" or "inflame" someone's behavior in a negative way with false accusations?
How would you have handled it in a way that would positively influence the person's initiating the ad hominem person attack?
All the best,
Peter William Lount peter@smalltalk.org
How is telling someone in private that they are being trollish, an ad hominem?
How to handle this in a bad way? Let me think. How about try and make them lose face publicly? Expose their private email, and add some 'facts.' Tell them they have to follow some of the laws of your home country. Help teach them how to ask 'appropriate questions', so I don't have to do this to them again. :)) I create new code of conduct for the group. Don't talk about X. So nobody feels suppressed. Oh, and of course, I'm defending your free speech rights. I published your private email, didn't I? </irony>
Some of the things that jumped out to me.
Libel: Any false or malicious written or printed statement that __publicly__ ridicules someone or damages their reputation.
So I'm thinking he isn't the one that damaged your reputation.
To the group: Due to the nature of Jason Shoemaker's comments I must reply putting this on the record. I apologize as I really do want to put this to rest. Thank you.
----
Hi Jason Shoemaker,
Sigh. I really can't believe that you'd post what you posted good sir. Unbelievable. You have opened yourself to possible liable action good sir. Unbelievable. Please stop that forthwith. Thank you.
Please respond to this posting and thread privately per the request of others in the group. Thank you.
Sigh.
Jason Shoemaker wrote:
On 9/15/07, *Peter William Lount* <peter@smalltalk.org mailto:peter@smalltalk.org> wrote:
Randal L. Schwartz wrote: >>>>>> "Peter" == Peter William Lount <peter@smalltalk.org <mailto:peter@smalltalk.org>> writes: There are also other laws other than copyright to consider. In British Columbia, where I am located, a party to a conversation may make it public if it's in defense of their person as my posting clearly was. End of story....
Also I didn't retaliate with any personal attack. I simply stated the facts of what was said and asked the person to stop their attacks, which seems to have occurred as the subsequent email-posting exchange shows. Furthermore, out of a desire to have positive conversions subsequently follow, I provided suggestions of how to ask appropriate questions rather than initiate ad hominem attacks. I suppose that you support ad hominem attacks upon the person even if they are sent privately to attempt to influence, "bully" or "inflame" someone's behavior in a negative way with false accusations? How would you have handled it in a way that would positively influence the person's initiating the ad hominem person attack? All the best, Peter William Lount peter@smalltalk.org <mailto:peter@smalltalk.org>How is telling someone in private that they are being trollish, an ad hominem?
Telling some one that they are being trollish is an ad hominem personal attack under all circumstances. It's a dramatic negative statement about the person, it's intended impact is to stifle discussion and free speech. It is bullying plain and simply. Often the rest of the group will then moderate the person's comments down or remove them from the group. I felt personally attacked in this case. I felt bullied. It was heightened by the fact that the person and I had a long standing positive history spanning many years with a good cooperative feeling. To be called a troll was deeply offensive to me.
How to handle this in a bad way? Let me think.
I submit to you good sir that you are handling this very badly indeed. As I will show your posting is highly incendiary and likely so on purpose. I ask you to cease such negative comments in public.
How about try and make them lose face publicly?
That wasn't my intention. My intention is to stop ad hominem personal attacks cold before they continue. In my experience people who use ad hominem personal attacks continue to do so unless it's addressed immediately with the actual facts of the matter.
If a person who makes ad hominem attacks looses face in public that is a consequence of their making ad hominem personal attacks. They need to take responsibility for the fact that they made a personal attack and deal with any consequences.
I hold no malice or ill will towards the person. I have said my peace, the point was taken, he adapted, he moved on as indicated by no more personal attacks in our dialog since, and as far as I'm concerned the matter is settled. It's some of you who haven't moved on yet. Please move on. Thank you.
Expose their private email, and add some 'facts.'
Now your tone suggests that the facts were concocted. My statements of the facts are entirely accurate.
When attacked you are permitted to reveal relevant private conversations that you are a party too. That is the law.
Yes, I will expose people attacking me. I will expose when I'm bullied. It's known as self defense. Spreading the word about it helps the attacks to stop.
Tell them they have to follow some of the laws of your home country.
Now you are distorting the situation good sir. If fact I assert that it is very possible that you are deliberately distorting the facts of this in an attempt to harm my reputation. I ask you to cease such nonsense.
I never said I that the law compelled me somehow to reveal what happened. That's pure nonsense and you know it. I simply stated that there are laws (in many countries) that allow one to defend oneself by disclosing relevant private communications when one is a party to the conversation.
So it's important to be careful who you personally attack for your private communications may become public. It's also important to not liable people in public sir. The best policy is to not attack people.
Help teach them how to ask 'appropriate questions', so I don't have to do this to them again. :))
Yes, he assumed that because the example I'd written had a mistake in it that I must therefor be a troll rather than simply pointing out the mistake and asking me to clarify.
He made an insulting personal attack by calling me a troll. That was his action. He is responsible for the consequences of attacking someone personally. I'm not going to sit around and take personal attacks. I will shout about it loud and clear. Personal attacks are unacceptable in most areas of life. I freely shout it out.
Yes, it's loud. If you don't like that that is too bad. If others don't like that it is too bad. Don't make personal attacks and you won't have to deal with the consequences of them.
There is no substantial difference if the attack is private or public. The person who is attacked is the one who feels the negative consequences immediately. They are the one who feels suppressed! The attacked is the one who is being bullied by the attacker. It is a very unpleasant experience good sir. I will not stand it by being quiet. I will speak up and attempt to stop the bullying in an appropriate professional manner within the law and without making an ad hominem attack upon their person in return. I never called him any names or said anything about his person except for the facts of what he said to me. That is being professional about the matter.
I create new code of conduct for the group.
It's the code of conduct that society permits in many countries so it's not a new code of conduct at all.
The most common situation it's seen in is in journalism when the journalist reveals private communications or interviews where the journalist was a party to the conversation or communication.
It's also used in cases of liable to defend oneself against people who are attempting to defame a person.
It also happens when people are mugged in a back alley and then tell others what happened to them, what was said, etc...
Besides, you are also assuming that he intended the communication to be private which may or may not be the case. It wasn't marked so. It had the same exact subject heading as the other messages. Often people hit "reply" rather than "reply to all". People where doing that throughout the particular thread in question - multiple times. That is a fact. If he had really wanted it to be private he could easily have marked it so in the subject and in the body of the message itself to clearly show his intention.
However, in our society one doesn't have an expectation of privacy when one makes ad hominem personal attacks upon someone even in private. Sorry.
Don't talk about X.
***** Others have asked that this off topic discussion be taken elsewhere, I'm simply attempting to respect those voices. *****
However, I will discuss this with as many of you as there are since it is unacceptable to have ad hominem personal attacks in a technical discussion. I'd prefer to put this to rest though. Please no more public emails. Send them privately thank you.
I will also defend myself from statements that are untrue, liableous or malicious. As I am compelled to do with your posting Jason Shoemaker.
In fact calling someone a troll is telling them that you don't want to hear about X. That X is heretical and can't be talked about. That the particular viewpoint about X is not allowed. Being called a troll is insulting as well. It is often intended as an insult too. That is in part why calling someone a troll is an ad hominem personal attack.
Saying that you were personally attacked by someone is in no way an attempt to suppress anything except the personal attacks. It's that simple.
Calling someone a troll is simply unwise. Don't do it.
So nobody feels suppressed.
How did you feel suppressed good sir? Are you not saying anything relevant to the topic of this group, Squeak and Smalltalk, as a result? I doubt you are suppressed in any way what so ever as is evident from your posting.
Don't make ad hominem personal attacks, false statements, malicious statements or liableous statements and you won't suffer the consequences of your actions in that regard.
It isn't my intention to suppress anyone. My intention is to respond appropriately and sternly with full resolve to all ad hominem personal attacks with (1) the facts, (2) a request to have the person stop the personal attacks and, (3) to offer alternatives for them to show that there are ways to move forward without personal attacks. That is being professional. That is a high standard of conduct that respects all involved, and yes, even the person who made the ad hominem personal attack in the first place.
The person in question continued onward with the discussion without further personal attacks so it seems to me that no one was suppressed good sir. All that was suppressed in that thread were personal ad hominem attacks from what is evident. That is a good thing. Very good.
Now if we can keep this thread civil we'd be doing fine. Actually if we can put this to rest we'll be doing better. Please put this to rest. Thank you.
Since you weren't a party to that conversation how on earth are you impacted? You're not! Unless you make a practice of attempting to influence your arguments with ad hominem personal attacks. They yes, I can see how one would be suppressed or might feel suppressed. That's a good thing though that improves the quality of the discussion. Isn't it? If you support the use of ad hominem personal attacks then I can see that it's a bad thing.
It's simply wise to keep things professional.
Oh, and of course, I'm defending your free speech rights. I published your private email, didn't I?
It's not in defense of free speech that gives one the right to publish a private email. It's in defense of one's person that gives one the right to publish relevant private conversations that one is a party to. It's a crucially important distinction that the law provides in many jurisdictions around the world. Why? The facts are important when one is attacked, more important that any privacy or other issues.
</irony>
Some of the things that jumped out to me.
Libel: Any false or malicious written or printed statement that __publicly__ ridicules someone or damages their reputation.
Libel, that is what your posting is bordering on good sir since you sent it to the wider group publicly written as it was. Clearly your statements are false and misleading as regards to the facts of what occurred. Clearly I can easily interpret them as malicious and liable. Please stop that forthwith.
So I'm thinking he isn't the one that damaged your reputation.
If people don't like someone standing up to bullies who use ad hominem personal attacks as a tool in discussions then that's too bad. I am a strident defender of a high quality of discussion without making ad hominem personal attacks. I will defend any personal attacks by informing the group that they occurred, ask the person to stop, and offer suggestions for alternatives to using ad hominem personal attacks as that is a professional approach, a socially accepted practice, a legally sound strategy and it's also respectful to the person who made the personal attack.
Clearly by now good sir it's clear that you posting is an attempt to damage my reputation. I would ask you to cease from doing so further.
I clearly understand the meaning of the point you are attempting to make however you proceed upon false premises as I've outlined above. If your intent is malicious then it's you are that are open to liable. Conduct yourself accordingly good sir.
Others in this group have asked that we take this off line. Please respect their wishes. I am attempting to do so. In the future please send your emails to me privately. Caution however, all ad hominem personal attacks against me will be published at my discretion so just don't go that way. I welcome all respectful conversations. I hope that everyone is now done with this. If you are not yet done please send private emails, thank you.
All the best,
Peter William Lount
cc. Legal Council.
Am Donnerstag, 13. September 2007 22:00:55 schrieb Peter William Lount:
Hi,
Hi, first I want to say, that I'm thinking of the same ideas that you think of and I really like the [a. b. c.] values idea.
[ 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 ].
However, you indeed change the syntax of blocks for merging block syntax with method syntax when you say
[firstName: aString | firstName := aString ].
aren't you? at least as far as I know ST80... ;) . I would prefer something like this:
Person addInstanceMethod: [ :aString | firstName := aString ] named: #firstName:
I personally like to see a Block as a simple collection of statements. That it is internally compiled to some bytecode sequence _not_ necessarily representing the different statement borders is just an optimization for the sake of speed. Howerver, instead of byte code I'm dreaming of some kind of AST... Be aware, that you can represent any tree data structure with a sequential array resulting in just another form of "byte code". ;)
All the best,
Peter
Regards, Martin
Am Freitag, 14. September 2007 21:01:54 schrieb Martin Beck:
Person addInstanceMethod: [ :aString | firstName := aString ] named: #firstName:
Ah, I just see, you already stated the #named: variant. Those who can read are clearly in advantage... ;)
Regards, Martin
Martin Beck wrote:
Am Freitag, 14. September 2007 21:01:54 schrieb Martin Beck:
Person addInstanceMethod: [ :aString | firstName := aString ] named: #firstName:
Ah, I just see, you already stated the #named: variant. Those who can read are clearly in advantage... ;)
Hi,
;--) I like your sense of humour too!
Cheers,
Peter
Hi Martin,
Martin Beck wrote:
Am Donnerstag, 13. September 2007 22:00:55 schrieb Peter William Lount:
Hi,
Hi, first I want to say, that I'm thinking of the same ideas that you think of and I really like the [a. b. c.] values idea.
Excellent. Birds of a feather flock together!
[ 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 ].However, you indeed change the syntax of blocks for merging block syntax with method syntax when you say
[firstName: aString | firstName := aString ].
aren't you?
Yes, the syntax adjusts towards a unification of Blocks and Methods. This sort of minor syntax change is acceptable since it moves Smalltalk towards a more powerful future with capabilities that are essential in competing with other languages and in expressing new programs eloquently. This sort of change has happened with blocks when variables were added to them and other minor changes by different vendors to blocks over the years. Syntax that adds new characters such as "{" and "}" needs to be very seriously considered especially when it's adding capabilities in fixed ways that aren't extensible and that violate the message passing paradigm.
at least as far as I know ST80... ;) . I would prefer something like this:
Person addInstanceMethod: [ :aString | firstName := aString ] named: #firstName:
Yes, that is valid and possible in a unified block and method syntax.
I personally like to see a Block as a simple collection of statements.
Yes, that's a very powerful perspective. It's a hierarchical collection of statements in the more general form.
That it is internally compiled to some bytecode sequence _not_ necessarily representing the different statement borders is just an optimization for the sake of speed. Howerver, instead of byte code I'm dreaming of some kind of AST... Be aware, that you can represent any tree data structure with a sequential array resulting in just another form of "byte code". ;)
Yes, the whole issue regarding statement boundaries not being present in existing Smalltalk byte codes or natively compiled code is strictly a code optimization. If statements boundaries are needed then they need to be compiled in for code that needs it even if that code needs to be compiled and optimized on the fly. The Self Language has done this very effectively having five or six different versions for a method (or just as easily a block).
It's nice to move the discussion forward with someone who gets it for a change.
All the best,
Peter
Am Freitag, 14. September 2007 21:44:48 schrieb Peter William Lount:
Hi Peter,
However, you indeed change the syntax of blocks for merging block syntax with method syntax when you say
[firstName: aString | firstName := aString ].
aren't you?
Yes, the syntax adjusts towards a unification of Blocks and Methods.
Ok, but in my opinion, it is not necessary to adjust the syntax to achieve this unification. I'd rather interprete a Method as a named Block. Your syntax change does early binding of a name to an implementing Block, which we don't want in Smalltalk... :) The current block syntax does - as you stated, too - already incorporate the features needed in a method, like temps and arguments. So all you need, is to bind a Block to a class und a special method name (which has to have the same arg count). While running the VM/compiled code, the context decides, whether the block is evaluated in a normal way, e.g. a home context and correctly interpreting the return etc., or whether it is evaluated in a method context. So we are at your differant evaluators again. ;)
I personally like to see a Block as a simple collection of statements.
Yes, that's a very powerful perspective. It's a hierarchical collection of statements in the more general form.
A hierarchical collection which could be called Abstract Syntax Tree, hehe. Not to convince you (which is not needed ;) ), but just to add my 2 cents: We all know, that in a standard Smalltalk VM a Block is simple compiled code, which can evaluated resulting in a single value. However, if you try to explain such lambdas, closures (or any other name you might think of) to Smalltalk newbies, especially those from C/C++/Java backgrounds, you end up in saying to them: "A Block is source code you can save in a variable and execute it later". I don't want to discuss, whether that is right or wrong, but I think it helps them to understand a little bit of what is really meant. That differs from the former statement, that it says "source code". And source code is a (hierarchical) collection of statements, even in Smalltalk - at least to some extent. I think the newbie way of thinking of blocks is indeed the more natural one, than viewing it from the VM implementation side.
It's nice to move the discussion forward with someone who gets it for a change.
Thanks. If I remember correctly Ian Piumarta does (somehow) similiar things with his Id Smalltalk variant. I believe, he adds blocks to classes as named methods, too. So I've got these ideas from him... *g*
All the best,
Peter
Best regards, Martin
Hi,
Martin Beck wrote:
Am Freitag, 14. September 2007 21:44:48 schrieb Peter William Lount:
Hi Peter,
However, you indeed change the syntax of blocks for merging block syntax with method syntax when you say
[firstName: aString | firstName := aString ].
aren't you?
Yes, the syntax adjusts towards a unification of Blocks and Methods.
Ok, but in my opinion, it is not necessary to adjust the syntax to achieve this unification. I'd rather interprete a Method as a named Block.
With the change that I suggest it can use either format. It's the most general approach.
Your syntax change does early binding of a name to an implementing Block, which we don't want in Smalltalk... :)
Please explain further, I didn't get your meaning.
The current block syntax does - as you stated, too - already incorporate the features needed in a method, like temps and arguments. So all you need, is to bind a Block to a class und a special method name (which has to have the same arg count).
Yes, and resolve any "variable names" that need to be tied down to a scoping context. Either at the point the block is attached to a class (or traits node) or at the point when a block is evaluated as a block.
While running the VM/compiled code, the context decides, whether the block is evaluated in a normal way, e.g. a home context and correctly interpreting the return etc., or whether it is evaluated in a method context. So we are at your differant evaluators again. ;)
Well I'm not sure that we'd need a new evaluator for that, but that's an interesting idea. Let me think on that some more.
I personally like to see a Block as a simple collection of statements.
Yes, that's a very powerful perspective. It's a hierarchical collection of statements in the more general form.
A hierarchical collection which could be called Abstract Syntax Tree, hehe.
;-) Yes.
Not to convince you (which is not needed ;) ), but just to add my 2 cents: We all know, that in a standard Smalltalk VM a Block is simple compiled code, which can [be] evaluated resulting in a single value. However, if you try to explain such lambdas, closures (or any other name you might think of) to Smalltalk newbies, especially those from C/C++/Java backgrounds, you end up in saying to them: "A Block is source code you can save in a variable and execute it later". I don't want to discuss, whether that is right or wrong, but I think it helps them to understand a little bit of what is really meant.
I find that it's a very effective approach of explaining it to people. At least it's a great place to get start explaining Smalltalk blocks to them.
That differs from the former statement, that it says "source code". And source code is a (hierarchical) collection of statements, even in Smalltalk - at least to some extent.
Yes.
I think the newbie way of thinking of blocks is indeed the more natural one, than viewing it from the VM implementation side.
Yes. It's also the way to think about them at the language level. The VM is the implementation level and often it's job is to hide much of the details of the inner workings from the user and the language itself. That is why I prefer giving the language priority in driving the design over the concerns of the virtual machine implementation issues (if at all possible).
It's nice to move the discussion forward with someone who gets it for a change.
Thanks.
Your welcome.
If I remember correctly Ian Piumarta does (somehow) similiar things with his Id Smalltalk variant.
Yes, Ian's work is really amazing.
I believe, he adds blocks to classes as named methods, too. So I've got these ideas from him... *g*
I did share my thoughts on the unification of Blocks and Methods with Alan Kay and Dan Ingalls a few years back; as well I've mentioned it at OOPSLA and in private conversations with various people. Alan or Dan may have mentioned it to Ian or I might have mentioned it to Ian at OOPSLA (I don't recall if I spoke with him there). Or maybe others thought of it before. We have to ask Alan, Dan and Ian about their coming to the idea. After telling Allen Wirfs-Brock about it a few years back he said he'd come across that idea before but that it seemed that no one did anything with it. So I don't claim ownership of the idea (other than co-originating it) but I do promote it vigorously since I see it's value. It's also not a big leap to make as Block and Method syntax is almost the same - the big leap is seeing it's value.
Part of it's elegance is that it's such a minor change to make the unification happen and that it has such a powerful new dimension opening impact!
If a change is required in syntax and it doesn't open a whole new dimension of extensibility as a result then chop it out. It's like Tilera's "kill design rule" for their N-Core chips (Tile64 or TileN) where a N% increase in surface area of the chip must increase performance by an equal N%! I apply a similar set of "design kill rules" for syntax changes to Smalltalk and ZokuScript. If it's not message based using existing syntax then I ask "how can it be made to work with messages?" - this was the line of thinking that lead me to see that all meta data and meta operations can be accomplished with the existing unary, binary and keyword messaging syntax. That was a breakthrough! It also means that almost all changes in syntax are not needed as most changes are attempts to add meta data or operations. The problem with new syntaxes is that they break the notion of one uniform messaging syntax and make the world much harder. This makes advanced topics such as code analysis and code rewriting much more difficult and cumbersome since multiple syntax forms are involved and they may not have bidirectional transformations available when being converted this way and back that way.
I see the elegance and beauty of a unified block and method syntax for Smalltalk and ZokuScript such that I'm promoting it in the Smalltalk community. Certainly it will end up in ZokuScript as it's an essential building block for the future that I see for Smalltalk like or Smalltalk inspired systems.
If we as designers of a computer language (or other software programs) fail to bring the principles of elegance, beauty and simplicity to the language (or program) design and the design process then how can we expect our products to be powerful or users to be elegant, use beauty and simplicity in their expressions with our languages and tools we make?
All the best,
peter
Re: unification of blocks and methods (procedures).
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc.
But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...)
Cheers,
Alan
At 03:11 PM 9/14/2007, Peter William Lount wrote:
Hi,
Martin Beck wrote:
Am Freitag, 14. September 2007 21:44:48 schrieb Peter William Lount:
Hi Peter,
However, you indeed change the syntax of blocks for merging block syntax with method syntax when you say
[firstName: aString | firstName := aString ].
aren't you?
Yes, the syntax adjusts towards a unification of Blocks and Methods.
Ok, but in my opinion, it is not necessary to adjust the syntax to achieve this unification. I'd rather interprete a Method as a named Block.
With the change that I suggest it can use either format. It's the most general approach.
Your syntax change does early binding of a name to an implementing Block, which we don't want in Smalltalk... :)
Please explain further, I didn't get your meaning.
The current block syntax does - as you stated, too - already incorporate the features needed in a method, like temps and arguments. So all you need, is to bind a Block to a class und a special method name (which has to have the same arg count).
Yes, and resolve any "variable names" that need to be tied down to a scoping context. Either at the point the block is attached to a class (or traits node) or at the point when a block is evaluated as a block.
While running the VM/compiled code, the context decides, whether the block is evaluated in a normal way, e.g. a home context and correctly interpreting the return etc., or whether it is evaluated in a method context. So we are at your differant evaluators again. ;)
Well I'm not sure that we'd need a new evaluator for that, but that's an interesting idea. Let me think on that some more.
I personally like to see a Block as a simple collection of statements.
Yes, that's a very powerful perspective. It's a hierarchical collection of statements in the more general form.
A hierarchical collection which could be called Abstract Syntax Tree, hehe.
;-) Yes.
Not to convince you (which is not needed ;) ), but just to add my 2 cents: We all know, that in a standard Smalltalk VM a Block is simple compiled code, which can [be] evaluated resulting in a single value. However, if you try to explain such lambdas, closures (or any other name you might think of) to Smalltalk newbies, especially those from C/C++/Java backgrounds, you end up in saying to them: "A Block is source code you can save in a variable and execute it later". I don't want to discuss, whether that is right or wrong, but I think it helps them to understand a little bit of what is really meant.
I find that it's a very effective approach of explaining it to people. At least it's a great place to get start explaining Smalltalk blocks to them.
That differs from the former statement, that it says "source code". And source code is a (hierarchical) collection of statements, even in Smalltalk - at least to some extent.
Yes.
I think the newbie way of thinking of blocks is indeed the more natural one, than viewing it from the VM implementation side.
Yes. It's also the way to think about them at the language level. The VM is the implementation level and often it's job is to hide much of the details of the inner workings from the user and the language itself. That is why I prefer giving the language priority in driving the design over the concerns of the virtual machine implementation issues (if at all possible).
It's nice to move the discussion forward with someone who gets it for a change.
Thanks.
Your welcome.
If I remember correctly Ian Piumarta does (somehow) similiar things with his Id Smalltalk variant.
Yes, Ian's work is really amazing.
I believe, he adds blocks to classes as named methods, too. So I've got these ideas from him... *g*
I did share my thoughts on the unification of Blocks and Methods with Alan Kay and Dan Ingalls a few years back; as well I've mentioned it at OOPSLA and in private conversations with various people. Alan or Dan may have mentioned it to Ian or I might have mentioned it to Ian at OOPSLA (I don't recall if I spoke with him there). Or maybe others thought of it before. We have to ask Alan, Dan and Ian about their coming to the idea. After telling Allen Wirfs-Brock about it a few years back he said he'd come across that idea before but that it seemed that no one did anything with it. So I don't claim ownership of the idea (other than co-originating it) but I do promote it vigorously since I see it's value. It's also not a big leap to make as Block and Method syntax is almost the same - the big leap is seeing it's value.
Part of it's elegance is that it's such a minor change to make the unification happen and that it has such a powerful new dimension opening impact!
If a change is required in syntax and it doesn't open a whole new dimension of extensibility as a result then chop it out. It's like Tilera's "kill design rule" for their N-Core chips (Tile64 or TileN) where a N% increase in surface area of the chip must increase performance by an equal N%! I apply a similar set of "design kill rules" for syntax changes to Smalltalk and ZokuScript. If it's not message based using existing syntax then I ask "how can it be made to work with messages?" - this was the line of thinking that lead me to see that all meta data and meta operations can be accomplished with the existing unary, binary and keyword messaging syntax. That was a breakthrough! It also means that almost all changes in syntax are not needed as most changes are attempts to add meta data or operations. The problem with new syntaxes is that they break the notion of one uniform messaging syntax and make the world much harder. This makes advanced topics such as code analysis and code rewriting much more difficult and cumbersome since multiple syntax forms are involved and they may not have bidirectional transformations available when being converted this way and back that way.
I see the elegance and beauty of a unified block and method syntax for Smalltalk and ZokuScript such that I'm promoting it in the Smalltalk community. Certainly it will end up in ZokuScript as it's an essential building block for the future that I see for Smalltalk like or Smalltalk inspired systems.
If we as designers of a computer language (or other software programs) fail to bring the principles of elegance, beauty and simplicity to the language (or program) design and the design process then how can we expect our products to be powerful or users to be elegant, use beauty and simplicity in their expressions with our languages and tools we make?
All the best,
peter
Alan Kay wrote:
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc.
But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...)
Cheers,
Alan
Hi Alan,
That's an interesting history lineage. Thank you.
Are you saying that those systems had blocks and methods with the same syntax?
I suppose you'd have to add Lisp to that list since Lisp functions and Lisp lambda's are pretty much the same thing, lists.
You've mentioned that you don't like Blocks before. I've never understood why. Certainly they do violate encapsulation since they can be passed around and who knows where they'll end up (or even what they do when you get one).
Is it that you don't like the use of the levels of nesting in the syntax provide by "[" and "]" that mark the block of code? What would replace them? Is it even possible for a linear one dimensional text grammar to do that I wonder?
I'm glad that you added Blocks to Smalltalk-80 since they enable an amazingly huge domain of extensibility of the language flow control structures. That makes them worthwhile.
It does seem that you were aiming at something else though. Have you written about that? What are your thoughts on what you're aiming for?
I often find myself arguing for the creating of objects rather than using blocks (and collections and dictionaries) in many professional situations. People who get blocks sometimes rely on them way too much and it obfuscates the code - anyone can write spaghetti code. As soon as you are trying to do more than one different thing in a block or have more than one data/object value to manage it's often better for an object instead of a block. Often methods would be better off as their own independent objects for similar reasons.
A nice aspect of Blocks is that they are extensible and that they have a very easy protocol, #value, #value:, etc... for working with them. Objects can even take on the block protocol at times pretending to be a Block by implmementing value. That's how my SortCriteria (aka Sort Critter) objects work within SortedCollections (http://www.smalltalk.org/components/SortCriteria.html).
All the best,
Peter
On Sep 14, 2007, at 3:51 PM, Alan Kay wrote:
Re: unification of blocks and methods (procedures).
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc.
But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...)
I am glad I am not completely alone in my dislike of, or shall we say: discomfort with blocks.
Of course, if you are going to have blocks, then unifying the two concepts is quite obviously a good thing (IMHO). A block is just an unattached/anonymous method body and a method just a block with a name that's attached to a class. However, with that unified view it becomes immediately obvious that there is something wrong with blocks. After all, we don't directly call methods in other cases, that's early binding and a Bad Thing. Instead we send messages to objects. How does not naming the method body make this type of early binding and leaking implementation better?
On the other hand, having blocks is vastly superior to not having any useful higher order mechanism, and blocks are extremely powerful. Possibly too powerful, one of those "better old things" (lambda/ anonymous functions) that is so useful and powerful that it stops us looking for the actual "new" thing.
Marcel
p.s.: your message about the Internet being an OO system didn't reach me, I only just saw it on the list archives. I obviously(?) agree wholeheartedly, it is an OO system, but one that is quite different from Smalltalk. And the way to make things gel is probably not to try to "extend the image" (distributed Smalltalk, NetMorphs [as cool as they are], CORBA, SOAP), but rather to bring "the net" into "the image" in a deep way. Well, it probably wouldn't be an image as we think of it.
On Sep 14, 2007, at 3:51 PM, Alan Kay wrote:
Re: unification of blocks and methods (procedures).
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc.
But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...)
On Sep 16, 2007, at 2:52 AM, Marcel Weiher responded:
A block is just an unattached/anonymous method body and a method just a block with a name that's attached to a class. However, with that unified view it becomes immediately obvious that there is something wrong with blocks. After all, we don't directly call methods in other cases, that's early binding and a Bad Thing. Instead we send messages to objects. How does not naming the method body make this type of early binding and leaking implementation better?
That's not quite true. In Smalltalk, blocks *are* objects, and it's not possible to directly "call" a block. Instead, you send the message #value to it. This isn't early binding, because there are other things that respond to #value - MessageSends, for example, or Seaside's Continuations. Heck, Object provides a trivial implementation too.
I see what Alan was getting at about violating encapsulation: if you create a block that can access an object's internal state, then use it as a method of some *other* object, you end up with two objects that are quite intertwined, a sort of quantum entanglement between objects. I've done some neat stuff with that in Javascript, but I do agree that it dilutes the strict purity of object orientation that one finds in Smalltalk.
This is a bit strange, but I'm coming around to the idea that one of Smalltalk's greatest strengths is actually its block syntax. It'd be pretty tough to find a lighter-weight syntax for a closure. Even Lisp requires you to type out L-A-M-B-D-A, although the pain can be mitigated with macros. Ruby comes close, but {} doesn't actually create a real object. Javascript would be soooo much better if you didn't have to type out "function(){}" to create a closure. The lightness of Smalltalk blocks is what makes gems like #ifTrue:ifFalse: not only possible but practical.
Alan, can you elaborate on what you mean by "super time bombs?"
Colin
At 02:35 AM 9/17/2007, Colin Putney wrote:
Alan, can you elaborate on what you mean by "super time bombs?"
Sure. I simply meant that a block containing an assignment to the internal state of an object can be passed around willy nilly to other objects and some random time in the future can be sent value and presto! you've cause a side effect on the internal state of the object that will be very hard to track down if it's a bug.
That seems really bad (and is not scalable). It is like using getters and setters instead of goals, but worse. Neither of these would be what I would call real object-oriented design, which would emphasize the separations between insides and outsides, between goals and methods, between asking and telling.
Cheers,
Alan
On Sep 14, 2007, at 3:51 PM, Alan Kay wrote:
Re: unification of blocks and methods (procedures).
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc.
But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...)
On Sep 16, 2007, at 2:52 AM, Marcel Weiher responded:
A block is just an unattached/anonymous method body and a method just a block with a name that's attached to a class. However, with that unified view it becomes immediately obvious that there is something wrong with blocks. After all, we don't directly call methods in other cases, that's early binding and a Bad Thing. Instead we send messages to objects. How does not naming the method body make this type of early binding and leaking implementation better?
That's not quite true. In Smalltalk, blocks *are* objects, and it's not possible to directly "call" a block. Instead, you send the message #value to it. This isn't early binding, because there are other things that respond to #value - MessageSends, for example, or Seaside's Continuations. Heck, Object provides a trivial implementation too.
I see what Alan was getting at about violating encapsulation: if you create a block that can access an object's internal state, then use it as a method of some *other* object, you end up with two objects that are quite intertwined, a sort of quantum entanglement between objects. I've done some neat stuff with that in Javascript, but I do agree that it dilutes the strict purity of object orientation that one finds in Smalltalk.
This is a bit strange, but I'm coming around to the idea that one of Smalltalk's greatest strengths is actually its block syntax. It'd be pretty tough to find a lighter-weight syntax for a closure. Even Lisp requires you to type out L-A-M-B-D-A, although the pain can be mitigated with macros. Ruby comes close, but {} doesn't actually create a real object. Javascript would be soooo much better if you didn't have to type out "function(){}" to create a closure. The lightness of Smalltalk blocks is what makes gems like #ifTrue:ifFalse: not only possible but practical.
Alan, can you elaborate on what you mean by "super time bombs?"
Colin
"Alan" == Alan Kay alan.kay@vpri.org writes:
Alan> Sure. I simply meant that a block containing an assignment to the Alan> internal state of an object can be passed around willy nilly to other Alan> objects and some random time in the future can be sent value and presto! Alan> you've cause a side effect on the internal state of the object that will Alan> be very hard to track down if it's a bug.
But that's no different from some other object holding a reference to your object, then invoking a named method at a random time.
Putting dangerous things into a named method is no better or worse than putting dangerous things into a closure/block. You are still in control about the damage that can be caused "from the outside".
In fact, I'd go so far as to argue that a closure is nothing more than an unnamed method, and should be treated with the same care and feeding as named methods.
But, then again, the compiler could enforce rejecting access to the instance variables (direct state) of the "owner" of the home context. Still, I see what Alan means. Similar to being bitten by modifying a literal string...
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Randal L. Schwartz Sent: 18 September 2007 6:06 pm To: Alan Kay Cc: The general-purpose Squeak developers list Subject: Re: Blocks (Re: Fear and loathing of the "perification" ofSmalltalk)
"Alan" == Alan Kay alan.kay@vpri.org writes:
Alan> Sure. I simply meant that a block containing an assignment to the Alan> internal state of an object can be passed around willy nilly to Alan> other objects and some random time in the future can be sent value Alan> and presto! you've cause a side effect on the internal state of Alan> the object that will be very hard to track down if it's a bug.
But that's no different from some other object holding a reference to your object, then invoking a named method at a random time.
Putting dangerous things into a named method is no better or worse than putting dangerous things into a closure/block. You are still in control about the damage that can be caused "from the outside".
In fact, I'd go so far as to argue that a closure is nothing more than an unnamed method, and should be treated with the same care and feeding as named methods.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
On Sep 17, 2007, at 2:35 AM, Colin Putney wrote:
A block is just an unattached/anonymous method body and a method just a block with a name that's attached to a class. However, with that unified view it becomes immediately obvious that there is something wrong with blocks. After all, we don't directly call methods in other cases, that's early binding and a Bad Thing. Instead we send messages to objects. How does not naming the method body make this type of early binding and leaking implementation better?
That's not quite true. In Smalltalk, blocks *are* objects,
They "are" objects only in a very trivial way, just as much and as little as method bodies.
and it's not possible to directly "call" a block. Instead, you send the message #value to it.
That's just another implementation detail. Notice how #value does not carry the intension of what you are trying to do, it is a completely generic message. Your intension is not encoded in the message, it is supplied solely by the implementation ( = method body ) you've provided in the block itself.
Marcel
On 17-Sep-07, at 2:35 AM, Colin Putney wrote:
I see what Alan was getting at about violating encapsulation: if you create a block that can access an object's internal state, then use it as a method of some *other* object, you end up with two objects that are quite intertwined, a sort of quantum entanglement between objects.
Actually I'd like to suggest another way of looking at that; you can only get the 'encapsulation violation' by compiling the block originally within the class you are violating. Passing a block out to some other object is really nothing more than handing out permission; it's making the other object into a "friend with privileges".
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- ALOHA OY - Love; greetings; farewell; from such a pain you should never know
Hi,
Colin Putney wrote:
On Sep 14, 2007, at 3:51 PM, Alan Kay wrote:
Re: unification of blocks and methods (procedures).
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc.
Alan means, correct me if I'm mistaken, that the notion of code blocks, Lambda like closures wasn't present. What alternatives were discovered? Then and since?
I suspect that what is not meant by Alan's comment, again correct this for accuracy, is the notion of a unified Smalltalk Block and Method Syntax as was suggested.
But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...)
Alan, that must have been an interesting debate within the group. By external objects would they perchance have any difference from Object?
In a way you almost want an interaction using a entirely different contextual mechanism that pulses a constraint network depending on the objects and methods involved. A non-messaging contextual paradigm, of course expressed in unary, binary and keword message passing syntax [UBKMPS].
On Sep 16, 2007, at 2:52 AM, Marcel Weiher responded:
A block is just an unattached/anonymous method body and a method just a block with a name that's attached to a class. However, with that unified view it becomes immediately obvious that there is something wrong with blocks. After all, we don't directly call methods in other cases, that's early binding and a Bad Thing. Instead we send messages to objects. How does not naming the method body make this type of early binding and leaking implementation better?
Hmmm... Early Binding = Bad Thinking a Thing.
In a way you want a simulation of some sorts that performs Late Binding in the method contexts dynamically on the fly for a deterministic outcome each time it's run. Non-linear indeed.
That's not quite true. In Smalltalk, blocks *are* objects, and it's not possible to directly "call" a block. Instead, you send the message #value to it. This isn't early binding, because there are other things that respond to #value - MessageSends, for example, or Seaside's Continuations. Heck, Object provides a trivial implementation too.
A difference in view point enables dual understanding of all known perspectives.
I see what Alan was getting at about violating encapsulation: if you create a block that can access an object's internal state, then use it as a method of some *other* object, you end up with two objects that are quite intertwined, a sort of quantum entanglement between objects. I've done some neat stuff with that in Javascript, but I do agree that it dilutes the strict purity of object orientation that one finds in Smalltalk.
A isue with blocks is that they are imperative. How about using the Declaratives written in [UBKMPS] form instead of the imperative words that normally show in a Block's square brackets?
The Knights of the Square Brackets can figure this one out quickly. The peasants picking from the aromatic plants might catch up eventually with our help.
This is a bit strange, but I'm coming around to the idea that one of Smalltalk's greatest strengths is actually its block syntax.
Yes, Block Syntax, "[ ]", is as important as the notions of messaging and objects in it's own right. Unified Method and Block Syntax orders of magnitude more so.
Imagine Blocks can be evaluated ANY WAY that YOU THE PROGRAMMER+USER decide at runtime deferred to realization in your specific use case scenarios. Block evaluators, a few of which were recently present in an prior thread last week are normal things that you can extend Smalltalk or ZokuScript with just by writing using unary, binary and keyword message passing syntax that we know so well. Think about it. Write some examples. Visualize how this would change your coding of programs and the programs themselves could be so much more less brittle. Pragmatically how to implement these visualizations in realistic ways? What critiques are there from the perspectives of existing implementations?
This achieves what at least one language designer aims for: a opening for a whole new dimension for extensions by everyone with ease {and their great ideas} over time as the extensions unfold in unpredictable ways in the years to come. Who imagined that Block>>#values would come to the forefront as a new dimension? New dimensions of openings for extensions in the library using standard unary, binary and keyword message passing syntax are where the future comes from. From this authors perspective, that is, and maybe yours.
It'd be pretty tough to find a lighter-weight syntax for a closure.
[ | ]
Even Lisp requires you to type out L-A-M-B-D-A, although the pain can be mitigated with macros. Ruby comes close, but {} doesn't actually create a real object. Javascript would be soooo much better if you didn't have to type out "function(){}" to create a closure. The lightness of Smalltalk blocks is what makes gems like #ifTrue:ifFalse: not only possible but practical.
ifNil:ifNotNil:
Alan, can you elaborate on what you mean by "super time bombs?"
Aspects of existing blocks that blow applications out of the water or at least do so through increasing complexity via a magnification effect often disproportionate to ones ability to comprehend the full operations of the program as it crashed or produced it's operative results in the real world.
Something like that maybe?
In summary, using Unary, Binary and Keyword Message Passing Syntax [UBKMPS] is an essential way to make the evaluators of Blocks unlimited.
All meta operations in UBKMPS make this possible using what you already know.
All the best,
Peter William Lount peter@smalltalk.org
ps. Each node in the Tile 64 Processor can see the same network traffic at roughly the same instant assuming network multi-casting. What applications for this can you think of? Parallel operations play into this inquiry.
On 9/16/07, Marcel Weiher marcel@metaobject.com wrote:
On the other hand, having blocks is vastly superior to not having any useful higher order mechanism, and blocks are extremely powerful. Possibly too powerful, one of those "better old things" (lambda/ anonymous functions) that is so useful and powerful that it stops us looking for the actual "new" thing.
For me personally, what makes Smalltalk so powerful is that it's OO beautifully mixed with functional programming. If you take away blocks you take this away. I would like to see some other solution that would preserve the perceived lost encapsulation while having the same power.
Hi,
Am Samstag, 15. September 2007 00:11:29 schrieb Peter William Lount:
Your syntax change does early binding of a name to an implementing Block, which we don't want in Smalltalk... :)
Please explain further, I didn't get your meaning.
Okay, it was a small ironic joke: Dynamic Languages do late binding, as we all know. However, you want to assign names to a block directly, meaning early binding. ;) I think, I would get rid of the method syntax in any textual class representation like file outs. But, if needed, one can automatically visualize the block/method-source code in the "old" method syntax in the browser. Meaning, if you load a method, its underlying block is converted to method syntax and when you save it, the source code is converted back to a usual block and binded to the class. This is visual stuff which can be done by the system browsers. The compiler doesn't need to know. However, these are only some thinkings, perhaps I should get my hands back on some coding to see whether they have any value :)
[... cut ... ]
Fully ACK. :)
Regards, Martin
Hi,
Paolo Bonzini wrote:
"common sign that your love for a language has been corrupted into religion".
To quote Richard Dawkin's: "No, please, do not mistake passion, which can change its mind, for fundamentalism, which never will. Passion for passion, an evangelical Christian and I may be evenly matched. But we are not equally fundamentalist. The true scientist, however passionately he may “believe”, in evolution [or a certain computer language or feature therein] for example, knows exactly what would change his mind: evidence! The fundamentalist knows that nothing will." http://www.timesonline.co.uk/tol/comment/columnists/guest_contributors/artic...
All the best,
peter
On Fri, 14 Sep 2007 05:58:31 -0700, Peter William Lount peter@smalltalk.org wrote:
To quote Richard Dawkin's: "No, please, do not mistake passion, which can change its mind, for fundamentalism, which never will. Passion for passion, an evangelical Christian and I may be evenly matched. But we are not equally fundamentalist. The true scientist, however passionately he may “believe”, in evolution [or a certain computer language or feature therein] for example, knows exactly what would change his mind: evidence! The fundamentalist knows that nothing will." http://www.timesonline.co.uk/tol/comment/columnists/guest_contributors/artic...
Everyone who believes that Dawkins is more likely to change his mind than any average fundamentalist, raise your hand.
On 14-Sep-07, at 5:55 PM, Blake wrote:
On Fri, 14 Sep 2007 05:58:31 -0700, Peter William Lount peter@smalltalk.org wrote:
To quote Richard Dawkin's: "No, please, do not mistake passion, which can change its mind, for fundamentalism, which never will. Passion for passion, an evangelical Christian and I may be evenly matched. But we are not equally fundamentalist. The true scientist, however passionately he may “believe”, in evolution [or a certain computer language or feature therein] for example, knows exactly what would change his mind: evidence! The fundamentalist knows that nothing will." http://www.timesonline.co.uk/tol/comment/columnists/ guest_contributors/article1779771.ece?
Everyone who believes that Dawkins is more likely to change his mind than any average fundamentalist, raise your hand.
Me. Dawkins is a serious scientist. If there is any plausible evidence found contradicting his position on evolution then he would change his mind. A fundamentalist places faith in some revealed magic above all else, facts be damned, logic ignored, reason forgotten.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: YVR: Branch to Vancouver
On Sep 15, 2007, at 2:55 , Blake wrote:
On Fri, 14 Sep 2007 05:58:31 -0700, Peter William Lount peter@smalltalk.org wrote:
To quote Richard Dawkin's: "No, please, do not mistake passion, which can change its mind, for fundamentalism, which never will. Passion for passion, an evangelical Christian and I may be evenly matched. But we are not equally fundamentalist. The true scientist, however passionately he may “believe”, in evolution [or a certain computer language or feature therein] for example, knows exactly what would change his mind: evidence! The fundamentalist knows that nothing will." http://www.timesonline.co.uk/tol/comment/columnists/ guest_contributors/article1779771.ece?
Everyone who believes that Dawkins is more likely to change his mind than any average fundamentalist, raise your hand.
Folks, please. "Smalltalk" in the title of this thread refers to the programming language of that name.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Bert Freudenberg -
Blake -
Chris Cunnington -
Colin Putney -
Damien Pollet -
Dat Nguyen -
Edgar J. De Cleene -
Gary Chambers -
Herbert König -
Igor Stasenko -
Janko Mivšek -
Jason Johnson -
Jason Shoemaker -
Jecel Assumpcao Jr -
Jon Hylands -
Joshua Gargus -
Marcel Weiher -
Martin Beck -
Matthew Fulmer -
merlyn＠stonehenge.com -
Michael Haupt -
Nick Alexander -
Paolo Bonzini -
Paolo Bonzini -
Peter William Lount -
Roel Wuyts -
tim Rowledge -
Todd Blanchard