Fear and loathing of the "perification" of Smalltalk

Peter William Lount peter at smalltalk.org
Fri Sep 14 18:51:59 UTC 2007


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 at gmail.com> wrote:
>   
>> On 14/09/2007, Peter William Lount <peter at 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




More information about the Squeak-dev mailing list