[Grace-core] Binding symbol and egality symbol

[Andrew P. Black]

On 9 Nov 2010, at 13:35, Michael Kölling wrote:

> (That then gets into conflict with using = for let definitions -- I would favour dropping the distinction between = for let and := for var. That's a detail where language design detail hits through to the detriment of usability. It's technically sensible, and provides little useful purpose in practice.)

In Emerald, we used the same symbol for binding constants and binding variables.  We started out with different symbols, but eventually came to the conclusion that this was wrong.

IIRC, the argument went something like this.  In the semantics, we have names and values, values always being objects.  Names are bound to values; both const and var declarations do this.  The binding is the same.   The distinction is not in the nature of the binding, but whether the name can be re-bound: const names can't be re-=bound, and var names can.  We indicated that by using the keywords const and var; it was not only unnecessary, but also wrong, to use a different binding symbol.

(Note that this semantic story has an environment but not a store; mutable object subsume the store.)  

> What I would like to see, though, is a differentiation between interface (documentation) comments and internal (implementation) comments.

I'm supposed to be drafting a blog post on comments.  My intention is to propose making method comments special.  We already have annotations for pre-and post-conditions; I would like to add to them a plain text description of the action of the method.  

The reason for this is pragmatic.  My proposal is that the end-of-line comment syntax apply to the last whole syntactic construct that ends on the same line as the comment.  So:

	s := (u * t) + (0.5 * a * t.squared)	     //  s is the distance travelled in time t

	s := (u * t)	+				    //   u * t is the distance that would be travelled if there were no acceleration
	(0.5 * a * t.squared)			    //   0.5 * a * t.squared is the added distance due to the acceleration a

This seems both simple and reasonable, but it doesn't work well for methods, since method comments should not be at the end of the method, but immediately after the header (where the parameters are in scope) — this is also where the pre-and post-conditions should go, for the same reason.

It's also pedagogically motivated: I want to encourage students to write method comments, but not to write inline comments to explain their code.  Instead, I tell them to fix the code so that it does not need commenting!

	Andrew


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20101110/a21d530b/attachment.html>