Understanding 'the defaultStack'

[Mark Waddingham]

On 2016-10-09 22:25, Jeanne A. E. DeVoto wrote:
> At this point, I'm starting to wonder whether the defaultStack should
> be redesigned/re-specced to make it more predictable.
> 
> I don't think it's feasible to actually make major changes in the way
> the defaultStack works, but possibly a new property could be designed
> that acts in such a way that workarounds like this aren't normally
> needed. Setting and re-setting the defaultStack to make sure it's
> right is almost as annoying as specifying the stack every time you
> refer to an object (which I sometimes do anyway, for fear of the
> defaultStack changing from under me).
> 
> If it were being designed from scratch, what would the ideal behavior
> be for a targetStack property? Should it remain unchanged while a
> script is running (unless set explicitly)?

I don't think its even possible to add a new property which works 
'better' (by some metric) as the defaultStack is what is used to 'fill 
in' missing stack references in chunk expressions - thus its 
defaultStack, or something else, but not both (otherwise there's no way 
for the engine to know whether you want to use the new fangled 
targetStack for that purpose, or the old fashioned defaultStack for that 
purpose - in any one case).

I wonder if there are just some cases in the current behavior which need 
some review and refinement - in particular, the scope of the changes to 
the defaultStack.

One thing to consider is what the locality of a change should be. In 
particular:

   1) If the defaultStack is changed in a handler, should it remain that 
way for all subsequent commands (which don't explicitly change the 
defaultStack) and should the change recurse into called functions and 
commands?

   2) If the defaultStack is changed in a handler called from another 
handler, should the change propagate back up to the caller?

I think (1) is definitely wanted. If you have changed the defaultStack 
in a handler, then it makes sense that anything executed within that 
handler, and any handlers invoked within it should use that context.

I think (2) is definitely not wanted. If the locality of a change to the 
defaultStack propagates back to callers, then the callers loose control 
and knowledge of what they are actually acting on.

If changes propagate down, and not up then all we need to do is mark 
commands which explicitly change the defaultStack as doing so. e.g.

   1) go stack tStack - open stack tStack and set the defaultStack to it

   2) set the defaultStack to tStack - set the defaultStack to tStack

   3) send tMessage to tObject - execute tMessage in the context of 
tObject, setting the defaultStack to the stack of tObject for the 
duration of the handler

   4) call tMessage to tObject - execute tMessage of tObject, leaving the 
defaultStack untouched

With that in mind then the proposed 'using' clause would basically just 
be a local push / pop of the defaultStack:

   using stack "foo"
     ...
   end using

Would be equivalent to:

   put the defaultStack into tOldDS
   set the defaultStack to "foo"
   ...
   set the defaultStack to tOldDS

Anyway, the above is just a suggestion (on the whole) - I'm not sure the 
above to rules (i.e. defaultStack changes propagate into callees, not 
back into callers) necessarily model the current usage that well or not. 
However, they are (at least) relatively easy to write down and 
understand (?).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps