Getting double semi as sequencer harvested.

On Sep 13, 2007, at 15:38 , Klaus D. Witzel wrote:

>> Suppose you sending #doInParralell message to some unknown block
>> (which contents is unknown at compile time).
>
> ... have a Smalltalk example of aBlock which contents is unknown at  
> compile time?

Huh? That's the rule rather than the exception, isn't it? We're  
passing blocks around all the time, and e.g., #do: does not know at  
compile time what block will be passed in.

Anyway, I can see the point of those who think that if "[...]"  
produces an unadorned BlockClosure then a generic implementation of  
#values is impossible. However, who says that the compiler must  
discard the original list of statements when creating the  
BlockClosure? It could well be retained and made use of in  
BlockClosure>>values or other interesting extensions.

- Bert -

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

assoc := 'nasty' -> [ 1. 2. 3 ].
assoc value values  "should return an Array with 1, 2, 3"

Paolo

On 13-Sep-07, at 5:36 AM, Igor Stasenko wrote:

> I don't see how [...] values can be implemented without modifying VM.
Nothing to do with the VM. All that the #value[:] prim(s) do is make  
a context, point to the start of the code in the block and proceed  
from there.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Klingon Code Warrior:- 2) "My program has just dumped Stova Core!"

On Thu, 13 Sep 2007 16:38:27 +0200, Bert Freudenberg rote:

Sure. But every block is, when declared, usually seen by the compiler.  
Just asked for an example for resolving a confusion.

> Anyway, I can see the point of those who think that if "[...]" produces  
> an unadorned BlockClosure then a generic implementation of #values is  
> impossible. However, who says that the compiler must discard the  
> original list of statements when creating the BlockClosure? It could  
> well be retained and made use of in BlockClosure>>values or other  
> interesting extensions.

Sort of #reflectiveMethod (which does cacheing) from Marcus :)

/Klaus

> - Bert -
>
>
>
>

Igor Stasenko wrote:
> I don't see how [...] values can be implemented without modifying VM.
> You need to call some primitive to activate a block and execute
> statements.
Yes, exactly as I suggested.

> Of course, having a source(or parse tree) , you can parse
> it and then convert each statement in separate block and execute them
> one by one. Then you don't need to modify VM code.
Yes, you could do it that way, as Paolo and others including myself have
thought of.

> But speed ...
>  
That is always an issue to be considered.
> Also, some use patterns don't fit the purpose and can lead to errors
> and undefined behavior.
>  
Well, anyone can make spagetti of out any feature in a language.
As always you need to be congnizant of what features you are using and why.

All the best,

Peter

On 9/13/07, Damien Pollet <[hidden email]> wrote:
>
> The metaprogramming job of macros is already done by the tools:
> browser, refactorings, etc
>
> Macros in Lisp use the same syntax as functions. When you look at a
> Lisp expression, you can't know which evaluation rules apply without
> looking at the library. Some s-exprs are syntax, evaluated at
> compile-time, some other are calls evaluated at runtime. It works in
> the Lisp realm, but it doesn't fit in Smalltalk.

That's not necessarily the case.  In Smalltalk the macros can be made
to stand out (e.g. ##("macro") ).  And the big thing I see that would
be nice to have macros is for language extentions.  Instead of having
this surprising { } syntax extension we could have #{ } and the
convention that # is the place you put language extensions.

On 13/09/2007, Jason Johnson <[hidden email]> wrote:
By "It" I was referring to macro- and function-call having the same
undiscernable syntax. In Smalltalk you can guess what something is
just by its lexical structure.

> That's not necessarily the case.  In Smalltalk the macros can be made
> to stand out (e.g. ##("macro") ).  And the big thing I see that would
> be nice to have macros is for language extentions.  Instead of having
> this surprising { } syntax extension we could have #{ } and the
> convention that # is the place you put language extensions.

Agreed, if macros are to be done in Smalltalk this is the way I prefer.

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

Hi,

Paolo Bonzini wrote: 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. 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.
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.
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.
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

Jason Johnson wrote:
> I personally wouldn't want to see Smalltalk get things like the
> implicit self, splitting us further from other Smalltalks and even
> ourselves as we split into the "implicit self" versus "explicit self"
> groups as C++ did, only to decide explicit self was best practices
> after years of fighting about it.
>
>  

"The shoe." No. "The Gourd." ... repeat forever ...

;-)

Paolo Bonzini wrote: Hi,

I most certainly am open to learning from Randal Schwartz or Larry Wall
(the inventor of Perl) anytime that they are willing to teach or simply
converse. While I don't like twisted syntax it obviously works for the
Perl people (and many others).

I'm certainly open to learning even from you Paolo. ;--)

I only picked on Perl for coining the pejorative "perlification" since
it's pretty bad and I know it a bit better than other languages, and
I've already written some articles about it. Oops a quick google search
finds that I didn't coin the phrase, as others beat me to it, so there
must be something to it after all out in the wider culture. It's good to
know that it's not just Smalltalkers who are averse to Perl.

At least APL went out full hog and introduced it's own symbols, some if
not all drawn from Math. That's also what Mathematical has done. Oh
well, they can have their cryptic zoos all they want.

Smalltalk's big idea is messaging based upon unary, binary and keyword
syntax. It's best to maximize the potential out of that paradigm before
adding crufty goo. That is, in my humble view as someone who's used
Smalltalk professionally for 23+ years now.

Cheers,

Peter

On Thu, 13 Sep 2007 14:22:56 -0700, Peter William Lount  
<[hidden email]> wrote:

You've got it all wrong. It's a reminder that we need to think of things  
NOT of the body, but of the face and head.

C++ has so many issues of its own (it has all the issues, doesn't it?)  
that it's not necessarily a very good place from which to draw experience  
for Smalltalk.

I'm sorry, I don't get you.

On 9/13/07, Peter William Lount <[hidden email]> 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.  Parallel
execution would be implemented on top of an *array of blocks*, for example.

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 ])


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.

Jason Johnson wrote: Hi,

It's a reference to the Monty Python movie "The Life Of Brian" (a parody
set in the time of Jesus) wherein Brian ends up with a two groups of
cult followers, one worshiping the gourd that he drank from and another
worshiping the shoe that he wore. It's a comment on "implicit self" v.s.
"explicit self". Quite a funny movie too.

"Monty Python's Life of Brian is a 1979 comedy written and performed by
the Monty Python comedy team. It tells the story of Brian Cohen (played
by Graham Chapman), a young man born on the same night and the same
street as Jesus Christ."
http://en.wikipedia.org/wiki/Monty_Python's_Life_of_Brian

Cheers,

Peter

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.


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.


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.


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.
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.
Yes, perfectly true and desired. This is part of the more expressive future.
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?
That's a good start. Cool. Oh, extensions to primitives by VW.
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

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/article1779771.ece?

All the best,

peter

On 14/09/2007, Peter William Lount <[hidden email]> 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, Damien Pollet <[hidden email]> wrote: 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
>
>


--
Best regards,
Igor Stasenko AKA sig.

> > 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
type less, do more [ | ] http://typo.cdlm.fasmz.org

On 9/13/07, Peter William Lount <[hidden email]> 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)?

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. :)