Why so few binary method selectors?

Andrew C. Greenberg werdna at gate.net
Mon Mar 22 06:54:32 UTC 1999


Joachim writes:

> Is it correct that you can use at: only for numeric indices? I'd like to
> use it for keys as well...

Yes, the truth of which follows from the truth of:

	(Smalltalk at: #Collection ) allSelectors includes: #at:

All of this discussion about the virtues of certain "natural" 
syntactic sugar has led me to question the virtue of "natural" 
special notations.  What distinguishes binary operators for 
mathematics from [.] or @ for indexing and from dot notation for 
selection is not that the former is more "natural" than the latter, a 
question of degree and aesthetic dispute, but that the former is 
actually INDISPENSABLE for a practical expression language including 
operations on numbers.

The virtue of binary mathematical operators seems, to me, different 
in kind, not merely in degree, from the other syntactic notations 
upon which some insist here.  Rather than make the standard one of 
arguing for "naturalness," as the criteria for adopting a syntax 
change from Smalltalk's elemental simplicity, perhaps a more 
conservative policy is called for:

The numbers notation was a major concession, but an essential one. 
The language remained impractical without it (although one could 
conceive of surviving if truly forced to write (1 plus: 2) times: 3). 
Perhaps no change should be made unless it met that hefty criteria: 
Unless the new notation adds a meaningful functionality not present 
beforehand, or unless the new notation is necessary to  make the 
language practical, perhaps no changes should be made to the 
fundamental elemental syntax.

I raise this more to test the idea than to advocate it.  It just 
seems to me that noone has really said the obvious truth: special 
notation for arithmetic is almost sui generis, and probably necessary 
to keep the underlying language from failing the giggle test.  Can 
the same be said for "@" and [.] for indexing, or "." for selection?





More information about the Squeak-dev mailing list