Re: [Pharo-dev] thisContext usecases
Locked
Re: [Pharo-dev] thisContext usecases
 
|
Hi Clément, this is a bug. Thanks for finding it.
On Tue, Jul 9, 2013 at 1:15 AM, Clément Bera <[hidden email]> wrote:
best, Eliot
|
Re: [Pharo-dev] thisContext usecases
|
|
On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <[hidden email]> wrote:
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). So let's be laissez faire, unless the freedoms in question really do only do harm.
best, Eliot
|
Re: [Pharo-dev] thisContext usecases
|
|
On 9 July 2013 23:03, Eliot Miranda <[hidden email]> wrote: > > > > On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <[hidden email]> wrote: >> >> On 9 July 2013 10:15, Clément Bera <[hidden email]> 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!) 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 > |
Re: [Pharo-dev] thisContext usecases
|
|
In reply to this post by Eliot Miranda-2
On 10 July 2013 00:03, Eliot Miranda <[hidden email]> wrote: > > > > On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <[hidden email]> wrote: >> >> On 9 July 2013 10:15, Clément Bera <[hidden email]> 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). So let's be laissez faire, unless the freedoms in question really do only do harm. > Apparently one should know what he doing, when assigning to context's pc. And that's the reason why it considered 'evil' :) To me this is strange way to program: context just reflecting activation of your program, so if you changing pc, you changing the flow of your program. Isn't it would be wiser in such case to just change the original program to make it behave like you want, instead of hacking it via setting context's pc? Of course, there is exceptions like tail-recursion elimination, which you cannot implement by changing code in your program. > >> >> >> 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 regards, Igor Stasenko. |
Re: [Pharo-dev] thisContext usecases
|
|
On 2013-07-10, at 11:37, Igor Stasenko <[hidden email]> wrote: > Of course, there is exceptions like tail-recursion elimination, which > you cannot implement by changing code in your program. Or implementing GOTO. You've got to be able to have GOTO ;) - Bert - |
Re: [Pharo-dev] thisContext usecases
|
|
On 10 July 2013 11:43, Bert Freudenberg <[hidden email]> wrote: > > On 2013-07-10, at 11:37, Igor Stasenko <[hidden email]> wrote: > >> Of course, there is exceptions like tail-recursion elimination, which >> you cannot implement by changing code in your program. > > > Or implementing GOTO. You've got to be able to have GOTO ;) > But at which level? if at level of compiler , then it is completely acceptable. But not at level of direct manipulation. What i mean that for all such cases there should be a higher abstraction layer, allowing user to do what it does.. but not allow user to code: context pc: 10. > - Bert - > > -- Best regards, Igor Stasenko. |
Re: [Pharo-dev] thisContext usecases
|
|
In reply to this post by Frank Shearar-3
On Tue, Jul 9, 2013 at 11:29 PM, Frank Shearar <[hidden email]> wrote:
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.
best, Eliot
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |