Fear and loathing of the "perification" of Smalltalk

Peter William Lount peter at smalltalk.org
Fri Sep 14 19:30:51 UTC 2007


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





More information about the Squeak-dev mailing list