[M3devel] blue sky proposal :)

[Dragiša Durić]

On Sat, 2008-03-22 at 12:26 -0400, Tony Hosking wrote:
> Messing with VM protection mechanisms *will* impact performance, both  
> to set things up and to maintain.  For example, the GC needs to write  
> to those pages as it operates, so you are going to put extra work on  
> the GC.  Yuck!

  Ok.

> 
> Here is the germ of an alternative idea -- let add a READONLY  
> declaration, with enforcement by the compiler.   Should READONLY be a  
> property of types?  i.e.,
> 
> READONLY RECORD f: T;  g: T; END (* records of this type can never be  
> modified (i.e., f, g can only be initialized in a constructor) *)

  Constructor, or better - in "owning" module. It would be one exporting
interface where READONLY something is declared.

  Idea is - ADT. External users can work only through strict interfaces.
IMPLEMENTATION owner is responsible for these interfaces, and also one
who can access these fields. 

  Any "friends" mechanism would be witness of bad initial design. If
some new module needs really bad to write to these fields, I would
propose library level private INTERFACE where methods writing to fields
are exported. Need to write to such fields is much rarer than need to
read - this way we speed up what we use most.

> 
> Or should READONLY be a property of designators?  i.e.,
> 
> RECORD READONLY f: T; g: T END (* READONLY fields can never be  
> modified (i.e., f cannot be modified, but g can be modified) *)

  I think this is better. This way we can use compiler instead of
methods that only return value of some private field.

> This needs fleshing out.  For example, if READONLY attaches to types,  
> then what are the assignment rules for non-readonly and readonly?   
> More complicated still, what are the subtype rules?

  And again, designators are better. Readonly fields are readonly to
clients. Subtype is client. Above mentioned exception in reserve for
real needs.
  
> 
> Food for thought...
> 
> On Mar 22, 2008, at 9:17 AM, Dragiša Durić wrote:
> 
> > Now that VM mechanism is fully obsoleted by Mr. Hoskings GC... Why  
> > would
> > not we make something like this...
> >
> > <* READONLY object *>  - to move object to VM protected pages of  
> > traced
> > heap, so we can have RuntimeError.E when some code tries to write into
> > object
> >
> > <* WRITEABLE object *> - to return it back to normal traced heap pages
> >
> > Pragmas... Can be ignored by non-compatible compiler, and totally are
> > not changing language semantics. They just offer great debugging tool
> > and help us define/enforce some static properties of our structures.
> >
> > This, of course, is something for GC people to do...  As I see current
> > situation (as deep as I went into it) it will not affect performance  
> > at
> > all, and it will (IMHO) help straighten GC code even more :).
> >
> > dd
> > -- 
> > Dragiša Durić <dragisha at m3w.org>
> 
-- 
Dragiša Durić <dragisha at m3w.org>