[Vm-dev] Questions related to immutability in Cog

[Eliot Miranda]

Hi Ben,

On Mon, Nov 16, 2015 at 3:05 PM, Ben Coman <btc at openinworld.com> wrote:

>
> On Tue, Nov 17, 2015 at 1:05 AM, Clément Bera <bera.clement at gmail.com>
> wrote:
> >
> > Hi all,
> >
> > I am willing to have this done because I need it for the sista
> production version (I need the literals not to be able to be become).
> >
> > So my questions are:
> > - Is Sebastian or someone going to do this ? Else I will try to find a
> student for next summer or do it myself.
> > - We agreed that what we build is a write barrier and not immutability.
> Hence, how should I call the methods marking the object as non writable ?
> #markAsNonWritable, #markAsWritable, #isWritable ? The call back selector
> for instance variables will remain #attemptToWrite: value atIndex: index.
>
> Why not be explicit... #markWriteBarrier, #clearWriteBarrier ?
> Could still have #isWritable, or maybe #hasWriteBarrier or some variation ?
>

Yuck. I could live with beReadOnly, beWriteable, isReadOnly.  But
hasWriteBarrier or some such, no.  Personally I like isImmutable,
beImmutable, but if folks want to reserve that for a deeper concept then
fine.  BTW, for compatibility with VisualWorks I'd like the exception
raised when an attempt is made to write to a read-only object to be
called NoModificationError.



> cheer -ben
>
> >
> > If I do it or supervise someone to do it, the first version will be a VM
> compilation option because there will be performance loss with this feature
> due to inst var stores and at:put: being slowed (we expect 5% overhead).
> >
> > The scheme works for all objects but contexts. I think for contexts I
> will just forbid to mark them as non writable for now. In the future we
> could divorce and discard the frame, mark the context as non writeable, and
> returns across stack page would handle differently returns to non writable
> contexts (for example we could ask the image to interpret them). I guess it
> could make sense in some cases.
> > Best,
> >
> > Clement
> >
> >
> >
> > 2015-11-11 15:30 GMT-03:00 tim Rowledge <tim at rowledge.org>:
> >>
> >>
> >>
> >> > On 11-11-2015, at 7:47 AM, Chris Cunningham <cunningham.cb at gmail.com>
> wrote:
> >> >
> >> >  immutablity - an immutable bitblit?
> >>
> >> exactly what I was thinking :-)
> >>
> >> A couple of other immutability thoughts;
> >> copying an imm. (I refuse to type it out every time) object - the copy
> primitive would need to clear the imm. bit unless we declare that a copy is
> also imm. In which case only ST code copying could be used to make non-imm.
> copies.
> >> we’re SOL anytime any external prim or call is passed the guts of an
> imm. object.
> >>
> >> tim
> >> --
> >> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> >> A hacker does for love what others would not do for money.
> >>
> >>
> >
> >
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151117/d9ace17e/attachment.htm