[Grace-core] In praise of consistency

[Andrew P. Black]

On 18 May 2012, at 16:09 , Kim Bruce wrote:

> I keep wondering whether we should fall back on the Smalltalk convention/rule of requiring a colon at the end of the segments of the method name as that would help disambiguate some of these cases (and Smalltalk programmers seem to have little trouble with this -- is that true Andrew?).


Yes, it's true — once they have learned to parse it with their eyes.  Until then, the Smalltalk message send syntax is mysterious, and a source of confusion.  The reason, I think, is that (at least in my classes), it is different from what the students are used to, not that it is inherently difficult.  None of my students have ever seen Algol 58.

Michael, I agree with what you are saying when you say that we need a way of disambiguating, say,

	x<y.sin

which might mean x < (y.sin) or (x<y).sin

I also agree totally that we should NOT disambiguate this on the basis that booleans don't understand <.

I am inuring that the way to do disambiguation this is with a few, simple, consistent rules.  One rule we should have, I think, is that unary requests with . bind more tightly than binary operator symbols.  This is based on the idea is that appearance should dictate semantics.

The point of my proviso email was simply that putting parenthesis around things that are already atomic doesn't disambiguate at all.  

My suggestion of using [ and ] and Kim's suggestion of using : to indicate that an argument is coming _would_ disambiguate.  But I can't see doing that for binary operator symbols.

Moreover, you are right that in

	print "hello".reversed on output.mainStream

reversed could take an argument, so it might mean

	print ["hello".reversed [on [output.mainStream ] ] ]

I was merely saying that writing parens around the "hello".reversed doesn't help: the expression

	print [("hello".reversed) [on [output.mainStream ] ] ]

is still perfectly meaningful to the average programmer.  (It's not meaningful to us, because we are language lawyers and we know that we don't do currying and that method requests without arguments are not objects.  But this would be a surprise to someone who has been programming in Haskell or O'Caml).

I also agree entirely that 

	print "hello" ++ world

and

 	length "hello" + total

have to parse in the same way.

Hence, I propose simple rules that say things like

	(0) expressions within parenthesis association most tightly
	(1) message requests with . bind next most highly
	(2) Binary operator symbols come next
	(3) juxtaposition for parameterization binds more loosely
	(4) mix-fix method names extend as far to the right as possible
	(5) within a precedence level, association is left to right.

Under such rules, both of the above would mean

	print ("hello" ++ world)
	length ("hello" + total)

and if the programmer wanted the other thing, she would have to write

	(print "hello") ++ world
	(length "hello") + total

Putting "hello" in parens is quite valid, but does nothing to disambiguate or change the interpretation from one to another — UNLESS
we give parens two entirely different meanings.	

I also agree that

>  if x<y then
> is syntactically identical to:
>  sin x < cos y

but you are wrong when you say that

> and which way you interpret it depends on what you think the terms mean.

On the contrary, I would interpret the < as binding most tightly in both cases, so they mean

	if (x < y) then
	sin (x < cos) y

and if I want the other interpretation I would have to write

	(if x) < (y then)
	(sin x) < (cos y)

Again, we can put parens around x and y all we want, but since x and y are already atomic expressions, that will have no effect on the parse  — UNLESS we give parens two entirely different meanings.

I would be open to simplifying the above rules even further, perhaps eliminating the distinction between binary operators and juxtaposition.   I willingly admit that I do find it hard to see all of the consequences.

	Andrew