[Grace-core] Language Questions, and A little bit of the String library

[Andrew P. Black]

On 25 May 2011, at 11:30 , Kim Bruce wrote:

>> This was not in my code, as far as I know.  We had decided pretty definitely NOT to provide any _automatic_ coercions in Grace.   
>> We could make the implementation of ++ on String make the asString request to its argument.     We could also define ++ on the Grace ( Any?) object, thusly
>> 
>> 	method ++ other:Any {
>> 		self.asString ++ other.asString }
>> 
>> I'm not sure whether any of this is a good idea.  It does make output code less messy.
> 
> I think that it is a tremendous convenience to have "asString" added whenever in a context that expects a string.  I agree that implicit coercions are dangerous (we're having some ambiguity issues with dropping "()" on parameterless functions, sigh!), but this one might be worth including.

As I see it, this is purely a matter of library design, and requires no language feature.

>> I know what the "right answer" is, but this is probably worth some detailed discussion.   We have said that efficiency is not important, but I think that we still want arrays to be constant time!  It would be nice to have a  better answer than Java.
> 
> Java screwed up in the design of arrays -- they certainly admit that now -- and they did it consciously, but for very bad reasons.  I'll be interested to hear about your "right answer".

Sorry, that was a typo!  I meant to type: I DON'T know what the "right answer" is.  I wish that I did.

> Finally, should we add my students (and other implementers) to grace-core or should we set up another list for that?  There is a lot going on in these discussions that they need to know about.

I thought that they were in grace-core.  I'll check.

Finally, why we all agree that we want simplicity, we have not agreed on what that means.  Each of us, including me, invokes simplicity when it suits us, with the appropriate meaning.
Doe it mean simplicity of the typical program, or simplicity of the language?  (I'm assuming that we are all agreed that it does not mean simplicity of implementation, so this is not a "worse id better" argument).

	Andrew



	Andrew