[Grace-core] On numbers and objects

[Michael Kölling]

On 9 Nov 2010, at 17:20, Andrew P. Black wrote:

>> I think the equality operator needs to be some version of = or == - probably ==
> 
> I thought that the whole point of using egal was that it was DIFFERENT from pointer equality, which is what most old timers will think when they see ==.   Maybe I'm missing your idea.   Perhaps a blog post on equality is in order?

I would strongly favour =.

Event though it is different from pointer equality, the whole point is that this is Grace's definition of *equality*. There should not be equality AND egal -- equality should BE egal.

And I think it's time to clean up the == nonsense.

(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.)


>> for comments, we can choose: // /* is more accepted in the C/Java world (Python uses #)
>> The other consideration is whether we'd rather have || or // for an operator
> 
> I don't really care what we use for comments -- and I don't see the need for two kinds, either.  I imagine that I will be writing and reading comments in an IDE, which will render them in grey italics in balloons on hover, so the ASCII symbol will be irrelevant to me.  So, on reflection, || is a nice operator, and we should save it for that.

I agree. We certainly don't need block comments. In Java, all sensible people write a block comment like this:

/**
 *
 *
 *
 */

i.e. with a marker in each line, so that you still see that you're in a comment even when the top and/or bottom is out of view.

We should mark each comment line as a comment, so we need only to-the-end-of-line comments. And applying block comments becomes an IDE function, not a language construct.

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

mik