[Grace-core] The Raw and the Cooked - Was Re: Considering Traits as Objects in Grace

[Michael Homer]

On Sat, Mar 9, 2013 at 6:47 AM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
> So here goes.  The idea is objects when they are first created are *raw*.  Raw objects are basically
> nothing but a singularity, a "naked identity".  Any message sent to a raw object, even an attempt
> to get a hashcode or test for == *fails with a dynamic error*. pretty much like "doesNotUnderstand"
> because basic raw objects don't have any methods.  A Raw singularity (aka a placeholder) is created
> at the start of an object constructor and bound to "self" in that constructor.  This means object
> constructors can only see lexical bindings, *not* methods from the objects being defined or
> any superclasses of that object.   (Except see note below!)    But you can *register* the self of
> an object under construction, and you can make blocks that refer to it and register them -
> but any attempt to use the block or registered self will fail while the object is raw.
I'm not sure which note this was referring to. There is an argument
for methods being treated as lexically bound at this point as well -
but then why not inherited methods too, which brings you back to the
start.
> At some point the raw object becomes cooked, becomes initialized. This could be specified
> explicitly, (some reflexive "cook" operation) but I'd rather have it implicit: an raw object
> that has had some state added to it becomes cooked when it first recieves a message request.
> So once you've had fields added, if you then get a message, you're now cooked, and that
> message goes ahead OK.   The catch with cooked objects is that they cannot now have
> their structure changed - because that change would now be observable.
Does this mean you can have methods called *before* state is added
somehow? In the current design there is also no such thing as fields -
everything is lexically scoped.
> This is where inheritance aka trait composition comes in.  Assuming for now we stick
> with the "inherits other" syntax --- how I imagine this working is as a *merge* of
> two (or more) *raw* objects, merging their fields, methods *and identities*.   This
> merge could be a simple override as now, it could be fancier if we really want to
> go to the full trait algebra. The details of that aren't important - the key point that the
> we only merge raw objects, and we merge their identities (think the Union-Find algorithm).
> Because identities of raw objects are so opaque they cannot even be compared,
> it is never visible that they were once distinct, or that their structure has changed.
The merge itself seems like it will be (dynamically) pretty
complicated to arrange, although possible.
> So what to people think (not just Andrew!)?
> Looking at existing Grace code, are the restrictions on raw objects too strong?
> How much code would this break?    Is that a good or a bad thing?
>
> And break code it will:   my parser combinators, for one example: we want to write
>
> def foo = rule { xx }
> def bar = rule { yy }
> def baz = foo | bar     // if foo and bar are raw or placeholders, can't request "|" on foo.  oops.
Why not? Surely that just cooks foo, which is an object that is
already fully initialised. It's only a problem if you want to inherit
foo later on, which you don't. You may have to treat it statically as
though it cooks bar as well, but it doesn't and the same applies
anyway.
> note 2  inheriting from imported objects   -  imports (and dialect objects) would usually
> come in as cooked. if we wanted to extend a module, however, we could just pervert
> the import system one again, and do e.g.
>
> import  "raw:StaticGrace"  as rawStaticGrace
>
> which would bring in the object as raw. Each such import would bring in a *new* raw instance.
> Then you can inherit from that raw instances as you like.
This feels like a bit too much of a hack.
> note 4 - structurally static breaks the story that the repl is just inside a normal grace object.
> Repls where you can incrementally define variables etc aren't structurally static.  SO we'd
> have to cheat for repls.  I'm not sure about top-level modules / scripts - would they still
> work, or not?
Only if your program never actually does anything, or only calls
methods on imported objects. At the least, stopping you from calling
your own methods breaks the model there.
-Michael