[Grace-core] Transparent Colours - Family Polymorphism in Grace?

[James Noble]

>> this version does, in svn as colours3. The only important 
>> difference is the inner object constructor "inherits Colour.r(red) g(green) b(blue)"
>> i.e. names the super-inner class explicitly, rather than saying e.g.
>> rather than "outer.super.r(red) g(green) b(blue)" or something...
> 
> Is that the "right" thing to say.  It does seem quite horrible. 

well it depends what "outer" and "super" mean.

The current spec doesn't mention "outer" and doesn't define  "super" terribly well
--- it says the next method that would have been found.   In this example, that's
ambiguous: there is the rgb method in "outer" and then the rgb method in "outer.super"
(or "super.outer") And the one in "outer.super" is the one we want.   In the current version of the spec,
naming that object directly, and doing a normal r()g()b() 	request to Colour, is the best we can manage.

In Newspeak, I think that super & outer pick one "direction" for the send and work only in that direction.
in Self, the "inherits" declaration has a name (it's a field) and you can use that name to tie down the direction.

As Andrew has suggested earlier, O'CAML & Scala allow objects to be given an internal name (alias to "self" / "this")
and requests using that name are counted as super/outer requests.  I'm coming around to that idea, modulo syntax,
and the more difficult question of whether the names are optional or not.


other issues:

>> (and yes, the extra parens in the "red" etc methods do look horrid)
> 
> Minigrace doesn't require them in the method requests where the arguments are numbers, but does when the arguments are identifiers.

yes I know - at Portland we came at the "delimited argument rule" requiring arguments to be delimited.
We could argue that numbers are delimited and add them to the list.   I still prefer e.g. 
  r(r') g(g') b(b')  
to 
 r r' g g' b b'  
in terms of making clear what is going on, but
 r 1 g 1 b 1 
mostly seem self-evident, and a little better than
 r(1) g(1) b(1)

> It does require them in the method headers.    

I'm happy with that (for now) - although (please don't lynch me!) -
I've also been thinking about Andrew's earlier suggestion of 
explicit tuples - mostly on the grounds that a naive implementation
of the existing request protocol would be so slow we couldn't make it 
any worse...

> The indentation in your example is wrong. So it shouldn't compile.  But it does.  Getting the compiler to check indentation is quite important, at least until that task is handed off to an IDE.  (It's also hellishly difficult, in my experience!  I interposed another level of grammar.)

hmm, the main bug I noticed was "asString" and "renderOn" in the inner TransparentColour object
were off-by-one - is there anything else?

At least in terms of choosing when (and when not) to "insert semicolons"
minigrace does a pretty good job...

James

>> 
>> def Colour = object {
>> 
>> method r(red') g(green') b(blue') {
>>    return object {
>>      def r = red'
>>      def g = green'
>>      def b = blue'
>>      method asString {"Colour r:{r} g:{g} b:{b}"}
>>      method renderOn(c) {print "Rendering as a Colour: {asString}"}
>>    }
>> }
>> 
>> method red    { r(1) g(0) b(0) }
>> method green  { r(0) g(1) b(0) }
>> method blue   { r(0) g(0) b(1) }
>> method yellow { r(0) g(1) b(1) }
>> method white  { r(1) g(1) b(1) }
>> method black  { r(0) g(0) b(0) }
>> method midGrey { r(0.5) g(0.5) b(0.5) }
>> }
>> 
>> 
>> def TransparentColour = object  {
>> inherits Colour
>> 
>> method r (red) g (green) b (blue) {
>>  return r(red) g(green) b(blue) alpha(1)
>>  } 
>> 
>> method r(red) g(green) b(blue) alpha(t) {
>>  return object {
>>     inherits Colour.r(red) g(green) b(blue)
>>     def alpha = t
>>     method asString {"Transparent {super.asString} alpha:{alpha}"}
>>       method renderOn(c) {
>>               if (alpha == 1) then 
>>                       {super.renderOn(c)} 
>>               else
>>                       {print "Rendering as a TransparentColour: {asString}"}
>>       }               
>>  } 
>> }
>> }
>> 
>> 
>> print (Colour.yellow)
>> print (TransparentColour.yellow)
>> 
>> 
> 
>