Making blocks more like methods [was: Re: FW: Why #DoIt?]

Dan Ingalls Dan.Ingalls at disney.com
Fri Apr 21 20:13:26 UTC 2000


"Stephen Pair" <spair at advantive.com> wrote...
>Alternatively, we could adopt a syntax for blocks that makes them look more
>like methods:
>
>[ someMethod: p1
>	| t1 |
>	t1 _ self doSomething.
>	^t1
>]
>
>In this case the selector for the block would simply be ignored.  The
>important point is that the difference between a block and a method (syntax
>aside) lies entirely in the context in which it is executed.

This would be my preference.  In designing the block syntax, we tried as much as possible to make blocks look like anonymous methods -- the colon before the parameters stands in place of the elided keywords.

I have frequently thought of including actual keywords for their value as documentation.  For instance I sometimes forget what the order of parameters is and write 
	myCollection withIndexDo: [:i :thing | self doStuffWith: thing and: i].
Wouldn't it be nice if the programmer's advisor filled this in with:
	myCollection withIndexDo: [element: i index: thing | self doStuffWith: thing and: i].
...so that I would know to fix it.

We chose not to require this syntax, because it is a lot to type and, worse, because it requires you to know the code for, eg, withIndexDo:, where this would be declared.

Whether or not we move toward protocols, or interfaces, being a real part of Squeak (I think we will), it would be pretty easy to add a declarative form to the syntax such that methods that took blocks as arguments were declared as, eg, 

	SequenceableCollection>>
	doWithIndex: block [element:index:]
		...code body...

This would enable the programmer's assistant to perform fill in the pattern as suggested above.  Note that we already *try* to communicate this information by naming the block variable, eg, elementAndIndexBlock but the information never gets to the user until he is tracking down an error and reads the implementor-side code.

It would be quite simple to add the declarative construct as an option, and to make the corresponding sender-side pattern optional as well.  (It would, of course, cause an incompatibility with other Smalltalks ... until the ANSI committee adopted it and all others were forced to conform to Squeak ;-).

	- Dan






More information about the Squeak-dev mailing list