[Grace-core] Constructors

[James Noble]

Hi Kim & Andrew

just back home now - about 24 hours door to door
from the hotel in Salt Lake City...

> James wrote in comments on the ArrayListClass in Grace:
>
> "I am concerned about the make*CD names. If we find ourselves doing  
> that a lot, then, well, that's not very graceful."
>
> My response:
>
> We decided to outlaw overloading, presumably for constructors as  
> well as for methods.  If that is the case then if we want to allow  
> multiple constructors in a class we either have to be able to give  
> them different names or use default parameters (which, while less  
> flexible, handles all of the constructors of the ArrayListClass).

yes and yes. And I still think that's the right decision.
But I also wanted to push on it a bit.

> Do you see any other alternatives?  ... and if not, would you rather  
> suffer with multiple names of constructors or admit overloading (or  
> did I totally misunderstand your comment?).

No: you didn't misunderstand my comment! 	
Perhaps all that is needed here is a better choice of names - writing  
out "Capacity" and "Delta"
(although I can already hear Andrew saying the second one should be   
makeArrayListCapacity( n : Number ) Delta ( d : delta )



> We could add a while loop, but I have a slight preference for "loop"  
> with exits

I think I do too, and while can be defined in terms of loop of course   
- very easily in Grace

method while(test : ()=>Boolean) do (body : ()=>())
   loop
     if test->() then exit
     body->()

(Hmm, I like that so much, It's a very good argument for loop/exit in  
the language
  and while no further down than the standard library)

other things to decide:
  * keyword for method declarations. Andrew likes "method" rather than  
"def" (I think?)
     because, as he says: "they're methods. this way we don't have to  
say to students "def' declares methods"
  * symbol for calling blocks.  I quite like ->() (or =>() but that  
might be ambiguous!)
    but -> is useful as a user-defined operator (e.g. for pairs in a  
hashtable) "a"->65.
     another option is ".()" which would give:

method while(test : ()=>Boolean) do (body : ()=>())
   loop
     if test.() then exit
     body.()

   ".()"   comes from one of the Java Lambda proposals

> (and I can live with "if (...) then exit" rather than "exit if ..."  
> even though I believe the latter has the advantage of making the  
> exits more visible.

OK good. Yes I agree about making exits more visible, but I lean on  
the side of the uniform syntax,
and also working inside match branches.

> I welcome a discussion on inner classes.  I worry about going all  
> the way to family polymorphism here (even though I have my own  
> statically typed proposal for such a system).


yes, we should have that discussion!
I'm currently pro, partly because i like them, they can do many other  
things :-)
but also because we currently have completely unrestricted lambda  
bindings,
so our object literals should (arguably) follow the same rules as  
lambdas.
that gets you so close, I think, that you may as well go the rest of  
the way.

James