How about Smalltalk-2000?

Warren Postma wpostma at ztr.com
Wed Feb 16 16:56:54 UTC 2000


>Present a syntax that you like better, and that is capable of expressing
all of 
>the current language.  You don't have to be able to compile it, or even to 
>generate it automatically, you just have to present 5 or 10 methods both
ways so 
>it is clear how it handles each aspect of our current semantics.

Hmm. 

Using a small number of idioms is good. 

Using TOO SMALL a number of idioms just makes life harder for me, the
would-be Smalltalk developer. 

Sure, you can get comfy with ST-80's syntax, or if not comfy, at least numb.

I had a perfect quote about this, which basically said that computers don't
get easier to use over time; advanced users and developers just get better
"callous buildup" from the millions of times they have done the wrong thing,
landed hard, and had to live with the unpleasant results. I can't find it
now. Doh!



Here are Two Interesting Possibilities:


1. Add another entire syntax on top of the current ST80 VM.

Python is the most clean and readable language I've ever seen. It's probably
easier for a C programmer to adjust to Python than smalltalk.

Just as JPython uses the Java VM but no Java syntax, make SPython, a plug in
language on top of the Smalltalk VM.  I dislike Java because it tries too
hard to look consistent with C++ superficially while working nothing like
C++ under the surface. Python's syntax is fitting for a dynamically typed
garbage collected VM, and therefore I find it easier to intuit what should
happen from Python code than from Java.  This is not the problem with
Smalltalk though.  Smalltalk's syntax makes it perfectly clear that what is
really happening everywhere is that messages are being sent between objects.
The problem with smalltalk is that "everything is an object" and "everything
is a message" even if I don't want it to be. So Python lets me write things
procedurally, and then let the little Nanite VM objects do their thing based
on the script I wrote.

[ I don't like this entirely because Python already has a nice VM to run in
(the JVM) and the JVM is already more widely ported than the Smalltalk VM.
So I actually think alternative 2 is better. ]

			---------------------


2. Spruce Up the basic Smalltalk language:

i. Subtract nothing from Smalltalk's syntax. That would break too much
stuff. 
   Add nothing to break existing Smalltalk syntax.

ii. Add Singleton as a base VM object. Enforce Singleton-ness in the VM.

ii. The following objects are singleton instances.
    You could make them all come from base class FlowControlStatements
    which inherits from Singleton.  These globals are instantiated by 
    the VMat startup. You can't instantiate them, or delete them, but you 
    CAN subclass them:

		repeat
		for
		while
		if 
		switch

	I am not entirely sure how you would work their syntax, but here is
a 
	rough idea, by someone who knows Smalltalk very poorly right now:

	repeat count: 100 do:
		[  "code here" ]
	else:
		[ "borrow the else clause from python. if you break out of a
loop, you go into the else clause" ].

     
	repeat until: Y>X do:
		[  "code here" ]
	else:
		[ "borrow the else clause from python. if you break out of a
loop, you go into the else clause" ].

	
 	for i from: 1 to: 10  <step: X> do:
			[i|  
				if (somethingFailed) then:
					break.	
			]
		else:
			[ "borrow the else clause from python. if you break
out of a loop, you go into the else clause" ].


 	for item in: Collection do:
			[item|  
				if (somethingFailed) then:
					break.
			]
		else:
			[ "borrow the else clause from python. if you break
out of a loop, you go into the else clause" ].


	while (i< 10) do:
			[i| "code here' ]
		else:
			[ "borrow the else clause from python. if you break
out of a loop, you go into the else clause" ]


	if X then:
		[ "code here" ]
		 else:
		[ "code here" ].

	" switch <  <expression1> <block1>  <expression2> <block2>
<expression3> <block3>  "
	switch 
	(  Y  [ "code here" ]
	   Z  [ "code here" ]
	)
 	else: [ "code here" ].  
	
	
iii.  Add operator overloading which maps back to the traditional Smalltalk

	messages:

	A[5] 			  	"syntactically equivalent to A at:5"
	A[5][6] 		  	"Array of arrays"
	A[0:5] := B[6:11]   	"copy a slice of B to A"
	A["Test"] := "Value"	"Associative array syntax"

	If [ appears right after an instance name, it is the array lookup
	operator. If it appears after a "message:" construct then it's a
block.

	C = D+E		  	"My own objects can be added and subtracted"
	E = "Hello"  * 5	  	" C is now HelloHelloHelloHelloHello
"
	F = "Hello " + "World"	" Add strings together "

	An example of a place this is already done is the "5 at 10" operator
for 
	points.  Can Smalltalk programmers control this, or is this feature 
	"hardcoded" into the VM?


iv.	Object to string operator:
		`Object`

v.	Formatting strings with the <string>%<array> operator:
		"number= %d string=%s" % ( 80 "test" )

vi. 	"Lift" all the other good idioms from Python.


Voila, Smalltalk-2000, a dialect of Smalltalk-80 that acknowledges that
Smalltalk has finally developed an alternative to the most unreadable part
of Smalltalk-80 syntax.
	

Warren





More information about the Squeak-dev mailing list