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 ? Thanks for answering,
On 9 July 2013 10:15, Clément Bera <bera.clement@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. 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.
2013/7/9 Igor Stasenko <siguctua@gmail.com>
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.
For stack pointer I don't know use cases so I have to agree. Now for pc in a smalltalk debugger you can select a place in code and execute 'run to here without executing code'. It is hidden in Pharo (right menu on stack) but it is a button in Visual works. So even if evil, it is required for some functionalities. I don't know if it could be deleted like that.
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.
Setting receiver fails in Cog and no one complains so ..
And for method's temps, it is fine.
Thanks for answering,
-- Best regards, Igor Stasenko.
On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 July 2013 10:15, Clément Bera <bera.clement@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). 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
On 10 July 2013 00:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 July 2013 10:15, Clément Bera <bera.clement@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). 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.
Hi Clément: On 09 Jul 2013, at 10:15, Clément Bera <bera.clement@gmail.com> wrote:
Now I'd like to know what context's state do we modify, and what states are just internal representations ?
I extended my VM with additional information that is kept in the context. My contexts can be 'owned' by a certain metaobject, and they indicate with a boolean whether the execution should regard that metaobject or not, for instance to delegate certain operations to it. So, that's all not exactly 'Pharo' but, I wanted to point out that there are use cases where additional fields and mutability of those is desirable. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
2013/7/9 Stefan Marr <smalltalk@stefan-marr.de>
Hi Clément:
On 09 Jul 2013, at 10:15, Clément Bera <bera.clement@gmail.com> wrote:
Now I'd like to know what context's state do we modify, and what states are just internal representations ?
I extended my VM with additional information that is kept in the context. My contexts can be 'owned' by a certain metaobject, and they indicate with a boolean whether the execution should regard that metaobject or not, for instance to delegate certain operations to it.
Sounds cool, nice idea. What VM did you extend ? Vanilla, Stack ? If i remember correctly you implemented Roar VM so maybe you extended this one ?
So, that's all not exactly 'Pharo' but, I wanted to point out that there are use cases where additional fields and mutability of those is desirable.
Yeah this feature is nice. And an efficient implementation should be doable. Thanks for your answer.
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Clément: On 09 Jul 2013, at 11:19, Clément Bera <bera.clement@gmail.com> wrote:
Sounds cool, nice idea. What VM did you extend ? Vanilla, Stack ? If i remember correctly you implemented Roar VM so maybe you extended this one ?
It is an extension to the RoarVM, but for all intents and purposes I use it like a classic interpreter. Thus, no context-to-stack mapping is used. Probably not very useful without all the context, but the relevant code looks often like this: https://github.com/smarr/OmniVM/blob/master/vm/src/interpreter/squeak_interp... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Clément, this is a bug. Thanks for finding it. On Tue, Jul 9, 2013 at 1:15 AM, Clément Bera <bera.clement@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 ?
Thanks for answering,
-- best, Eliot
participants (4)
-
Clément Bera -
Eliot Miranda -
Igor Stasenko -
Stefan Marr