[Grace-core] Decisions from yesterday's phone conference

[James Noble]

> Given that Grace is intended to be used for teaching, I have to wonder whether leaving so much of the interpretation of what something means to its context is such a good idea.

OK... 

> When we(1) moved from Pascal to Java, one thing that caught us by surprise was the
> students seemed to struggle with the concept of a "type". We(2) speculated that this might
> have been partly due to the fact that Pascal has the "type" keyword, and Java doesn't,
> meaning students were not being constantly reminded as to what a type was in Java.

yep! sounds reasonable to me.  
One of the reasons we call variables "var" and constants "const" ... 

> As far as I know, no one followed up on this (I'm not even sure if we mentioned this point
> specifically in the papers we wrote on using Java for teaching). The fact that Java classes were used in the context of types didn't seem to be sufficient to get the point across.

yep. seems right. 

> we(1) - I was at VUW at the time
> we(2) - Some subset of those teaching Java, probably Robert Biddle, Peter Andreae, myself
> 
> The thing that probably most annoys me about C++ is not the things people usually complain about, but the fact that a lot of what happens in C++ depends on its context, and sometimes you have to look at a lot of the context to determine what will happen (e.g, default constructors of different kinds, overloading of operators).

right. That's certainly something I found irritating. And also in Perl (i.e. meaning depending on the context of the return type) 

> The more of the context that needs to be examined, the more effort it is to understand the code. For those learning the language (especially if they are learning programming), they might not even know what context they need to examine, so increasing the difficulty. This is especially true if even simple questions (eg. "is this a method?" "does this method return a value?") require looking at more context.

right.  So one of our rules (guidlines? principles? decisions?)
is that it should be possible to parse Grace code without any static type information. 
This is important to allow dynamic typing, but it's also a useful principle in and of itself.

Scala doesn't do this; nor, I think, does Haskell: you may need to know the arity of functions,
(or the precedence of operators) to know how to parse.  Grace shouldn't be like that.

> So I would argue for always including parens for any mention of a method, and always indicating what gets returned (if anything).

right - the question is: how do we indicate "nothing".

DUH. and I realised I missed a case in my previous email:  we have *two* cases in Grace:
 - returning nothing, vs returning a dynamic type.   I was going to say this meant we should
 have an explict name for returing Nothing,  but you could always e.g. distinguish m ->   (dynanic return type) 
from m (no return type).   Statically or dynamically, anything that tries to return something
without even a (dynamic) return type should laise an error.  

> And generally, whenever the question of choice of syntax comes up, I would argue for the decision that provides the most information about what's going on.

So the key problem with () on methods is that we're currently going with "uniform syntax" - like Self, Eiffel, Scala etc,
there is one namespace for both methods and variables --- variables are accessed by method requests. 
There are good SE reasons for going this way, and it keeps the language smaller, I think, than the other option.

The flip side is that *everything* in Grace is a method request.   control flow, operators,
variable access, object creation, oh and things that directly invoke, well, methods.
(*  hmm: perhaps that means the method request terminology isn't the best:
because lots of the things that can be requested aren't methods)

Given that, writing e.g.  ((x()*x()) + (y()*y())).SquareRoot 
seems rather less pleasant - and no easier to parse or understand than
( (x * x) + (y * y) ).squareRoot 

in some cases, though, even with an argument, we're hoping to elide parens: 
basically around a single literal:

print "Hello World" 

while {true} do {print "Hello World"} 


> Sure it will mean more typing, but with IDEs these days, that shouldn't be an issue.

well yes, but we also are trying to avoid incantations - "public static void main" being the key -
stuff people have to type - or get the IDE to insert - that doesn't seem to offer any value.
There is a real design tension here! 
Having methods private by default (but needing a "public") keyword is one of the most obvious;
Having the "const" keyword be longer than the "var" keyword is - for me - another, because
better code should be shorter.

> Just my 10c (that being the smallest coin we(3) have these days :-)


no, it's all good points, even if we don't end up going down that way - 
I think we're trying to follow those design goals, even if (sometimes) the choices are different.

cheers

James