[Grace-core] Query on built-in objects

[Andrew P. Black]

On 18 Jun 2012, at 23:46 , James Noble wrote:

> In this case the "no implicit conversions" rule is breached,
> I guess, because we don't have to write " {foo.asString} "

I don't think that this breaches the rule at all.  We have to define the meaning of the { } string interp. notation.
I think that it means: "evaluate the expression within the braces, then request the asString method from the resulting object: call the answer mid.
The whole interpolated string has value left ++ mid ++ right, where left is the string preceding the left brace, and right is the string following the left brace.
  
> 
> I guess there is also "print" which could be considered as doing an implicit conversion?

No, I don' think so.   Grace's top-level print method is defined as 

	method print (arg:Object} { arg.printOn(defaultOutputStream) }

so it's up each object to define a suitable printOn method for itself.  (DefaultOutputStream should be another method of the top-level Grace object).


> Although this also goes to the "protocol of all objects" - if every object has an asString
> or toString method, then I guess print could be defined as being in the type
> { asString -> String }.  

By the above, print should have type { printOn (OutputStream) -> None }

> At a tangent, I think it's good that we don't have to teach String/Sequence concatenation
> on day one:   after all "{a}{b}" will do a + b when both are strings - and (especially printing)
> code looks much more straightforward with interpolations.

a ++ b, I think you meant to say.  Yes, I agree that the use of interpolations for printing messages is really useful for novices.

> 
> At a further tangent:
> - perhaps print should just take a string, not a {asString -> string} and rely on the implicit conversion in the String constructor/literal.

No implicit conversions!

> - but for that to work, you'd want static checking on messages to "self" even if no others

No special rules (unless we have a special syntax to get them, like the string interpolation syntax).

Moreover, I think that what I outlined above is simpler.  However, I think that over time we will want asDebugString as well as asString, and perhaps

	method inspect (arg:Object} { arg.asDebugString.printOn(defaultOutputStream) }

		Andrew