Well, it's certainly open to discussion :)  I'd think it best to count the first indent as just part of method definition.  So to get a block inside a method, you'd have to add *another* indentation, like this:

	myMethod
		| x y z |
			x := 1
			y := 2
			z := 3


This syntax also works out fine for storing a block into a variable:

	myMethod
		| b x y |
		b :=
			x := 1
			y := 2
		^b

It doesn't *look* real nice, but the fact that it's different is surely a big contributor.

Unfortunately, as you point out, it's tricky to send a message directly to a block.  Hadn't thought about that one...  Tough tough tough....  Maybe it would be worth living without this ability, just to have a syntax that is easier to scan through?  You can always store the block into a variable and send messages to the variable, after all.  And it doesn't seem surprising that a more rigid syntax would disable off a few things that you could do in the free-form syntax.

Well, I for one am not yet convinced, but it still seems like a neat idea.  For languages with lots of control structure, like Python, the code comes out looking *really* elegant.  But is it useful in a language like Smalltalk, where blocks are so important and where there is next to nil syntax?

Lex


"Jarvis, Robert P." <Jarvisb at timken.com> wrote:
> Given your "indentation as block" rules, would
> 
> 	myMethod
> 		| x y z |
> 
> 		x := 1.
> 		y := 2.
> 		z := 3.
> 
> 		^z
> 
> written in your new syntax be equivalent to
> 
> 	myMethod
> 		| x y z |
> 
> 		[ x := 1.
> 		  y := 2.
> 		  z := 3 ].
> 
> 	^z
> 
> (which answers nil) or
> 
> 	myMethod
> 		| x y z |
> 
> 		[ x := 1.
> 		  y := 2.
> 		  z := 3 ] value.
> 
> 	^z
> 
> (which answers 3) written in the current syntax?
> 
> Bob Jarvis
> The Timken Company
> 
> > -----Original Message-----
> > From:	Lex Spoon [SMTP:lex at cc.gatech.edu]
> > Sent:	Wednesday, August 11, 1999 1:08 AM
> > To:	squeak at cs.uiuc.edu
> > Subject:	Re: Eliminating assignments and variable syntax (accessors)
> > 
> > Stefan Matthias Aust <sma at netsurf.de> wrote:
> > > [Indentation as statement continuation]
> > > 
> > > >There is the remaining problem of blocks.  Maybe allow blocks with 
> > > >one statement to be inlined, and force blocks with multiple statements 
> > > >to have a line per statement?
> > > 
> > > I don't see problems for a parser here.  When it detects a [, it knows
> > that
> > > it has to look for a ].  You can both write the block in one line or in
> > the
> > > next line - even not indented as the parser knows that there's still
> > > something missing. Now if the block contains more than one statement,
> > you
> > > have to insert new lines.  
> > > 
> > > A statement like
> > > 
> > > true ifTrue: [false]
> > > 
> > > would be possible as for example
> > > 
> > > true
> > >   ifTrue: [false]
> > > 
> > > or even
> > > 
> > > true
> > >   ifTrue:
> > >     [false]
> > > 
> > 
> > 
> > Okay, but it doesn't seem fully in the spirit of syntax-via-indentation.
> > After all, one of the main places python uses indentation is to note the
> > start and end of a block, right?
> > 
> > So it might be cool to be able to do something like this:
> > 
> > 	x<3 
> > 		ifTrue:
> > 			y := y + 1
> > 		ifFalse:
> > 			z := z + 1
> > 
> > 
> > But this doesn't look perfect, either--it takes 5 lines when 3 or even 1
> > would do.  So, maybe allow the [ ] syntax for blocks that are only one
> > statement long?
> > 
> > 	x < 3
> > 		ifTrue: [ y := y + 1 ]
> > 		ifFalse:
> > 			z := z + 1.
> > 			m := m * m.
> > 
> > 
> > Lex