[Vm-dev] Re: [Pharo-dev] thisContext usecases

[Eliot Miranda]

On Tue, Jul 9, 2013 at 11:29 PM, Frank Shearar <frank.shearar at gmail.com>wrote:

>
> On 9 July 2013 23:03, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> On 9 July 2013 10:15, Clément Bera <bera.clement at gmail.com> wrote:
> >> > Hello pharoers,
> >> >
> >> > Recently I have been looking at the Pharo thisContext capabilities,
> in order
> >> > to perhaps one day in the far future edit its implementation with the
> Pharo
> >> > dev team. Nothing is planned or confirmed, it is just to discuss.
> >> >
> >> > A context has instances variables (method closureOrNil receiver stackp
> >> > sender pc) and holds the arguments and temporaries.
> >> >
> >> > Now I'd like to know what context's state do we modify, and what
> states are
> >> > just internal representations ?
> >> >
> >> > For example, it seems that you can do 'thisContext receiver: #foo',
> but you
> >> > cannot with Cog.
> >> >
> >> > SomeClass>>foo
> >> > thisContext receiver: #foo.
> >> > ^ self
> >> >
> >> > In workspace, evaluating:
> >> > 1 to: 5 do: [:i | Transcript show: SomeClass new foo ]
> >> >
> >> > Transcript result (with Cog):
> >> > foo
> >> > foo
> >> > a SomeClass
> >> > a SomeClass
> >> > a SomeClass
> >> >
> >> > Transcript result (with Stack or Vanilla):
> >> > foo
> >> > foo
> >> > foo
> >> > foo
> >> > foo
> >> >
> >> > Now as no one has ever complained, I guess this feature is not used.
> >> >
> >> > As far as I know, the real use cases of the context seems to be:
> >> > - setting and gettings temporaries
> >> > - setting and getting the sender of a context
> >> > - setting and getting the pc
> >> > - getting method, closureOrNil, receiver, stackp, arguments but NOT
> setting
> >> > them
> >> >
> >> > Now setting the sender of a context seems to be used only in two
> cases:
> >> > - continuations (as seaside continuations)
> >> > - exception implementation
> >> >
> >> > So imagine that in the future you would have a context that can be
> accessed
> >> > in read-only, where you could only:
> >> > - set the temporaries (but not arguments)
> >> > - set the pc (or something equivalent, as set the currently executed
> ast
> >> > node)
> >> > - use continuations (exceptions can be implemented on top of
> continuations)
> >> >
> >> > I would like to know if there are things that you do now and that you
> would
> >> > not be able to do with a context like that. For non meta developer
> (like
> >> > enterprise app developer) I guess it will not change anything, but I
> want to
> >> > know if you implemented a framework as seaside, does it requires other
> >> > things from the context and why ?
> >> >
> >>
> >> To my thinking playing with pc is awfully evil, it should be
> >> read-only, only to allow debugger
> >> to map it to source code. Same goes for stack pointer.
> >
> >
> > There are good uses for this  I just used it to implement basic-block
> coverage for methods.  One can use it for exception handling (mustBeBoolean
> etc).  I'm always wary of introducing restrictions when the system has
> worked fine without them for years.  One exception recently was in adding
> bounds checking to CompiledMethod>>at:put: so one could not change
> arbitrary bytes in the literals via at:put:.  But this was adding safety,
> not adding a restriction.  I see no harm in allowing one to assign the pc.
>  It is unsafe, and the system will likely crash if you get it wrong.  But
> it is also potentially useful (e.g. I've used it to do a prototype of
> tail-recursion elimination).
>
> Do you mean just eliminating tail calls in some easy places, or proper
> tail calls? (I keep saying "proper tail call" and not "tail call
> optimisation/elimination" because implementing proper tail calls is
> _language design_, not optimising. Or, having proper tail calls lets
> you do things that are impossible without a global program
> transformation. Handily, we can often implement language design in our
> own language!)
>

I mean a hack that allows a context to restart itself with any of different
receiver/arguments/method.  e.g. thisContext tailSend: selector to:
receiver with: arg with: arg.  More a test of contexts than a useful
facility.  But a fun experiment all the same.


> frank
>
> >  So let's be laissez faire, unless the freedoms in question really do
> only do harm.
> >
> >
> >>
> >>
> >> Setting receiver is less evil and it may work, if receiver belongs to
> >> same inheritance chain
> >> as compiled method's class. But it should not be set without checking
> this.
> >>
> >> And for method's temps, it is fine.
> >>
> >> > Thanks for answering,
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko.
> >>
> >
> >
> >
> > --
> > best,
> > Eliot
> >
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130710/726adf22/attachment.htm