<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 September 2016 at 12:19, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
On 29.09.2016, at 20:57, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
><br>
>><br>
>> Environment current<br>
>><br>
>> is parallel to<br>
>><br>
>> Project current<br>
>><br>
>> I think this is OK.<br>
>><br>
>> @Frank, could you elaborate please what you mean with '_delimited<br>
>> dynamic variable_' ?<br>
><br>
> Well, I like to be precise with my terminology. The tl;dr is that a delimited dynamic variable is just like what other people call a dynamic variable, except it plays nicely with stack slicing. The throw-a-Notification-get-an-<wbr>answer idiom is exactly equivalent to delimited dynamic variables<br>
><br>
> <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-February/176777.html" rel="noreferrer" target="_blank">http://lists.squeakfoundation.<wbr>org/pipermail/squeak-dev/2014-<wbr>February/176777.html</a> has a bit of a conversation around the topic, and has pointers to in-depth articles on delimited dynamic binding, and I've done my small part in trying to dig into the topic here: <a href="http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables/" rel="noreferrer" target="_blank">http://www.lshift.net/blog/<wbr>2012/06/27/resumable-<wbr>exceptions-can-macro-express-<wbr>delimited-dynamic-variables/</a>.<br>
><br>
> Anyway, the fundamental point I was trying to make is that using a Notification (CurrentEnvironment) is exactly avoiding global state, but it seems I missed the point that you and Nicolas were making, around various things having a #environment property.<br>
<br>
</span>A note: The first time I had seen a dynamic variable was in seaside where<br>
it is/was used for accessing the 'request context' (Being a web framework, this thingy described the HTTP request received by the framework).<br>
<br>
To access that, you call<br>
<br>
self requestContext zork<br>
<br>
in you seaside class, which boils down to<br>
<br>
requestContext<br>
<br>
^ CurrentRequestContext value<br>
<br>
And CurrentRequestContext being a Dynamic Variable implemented as Notification.<br>
<br>
However, since then, we have merged in the DynamicVariable as ProcessSpecificVariable contributed by Martin von Löwis.<br>
This provides a more efficient way to 'resolve' the DV to a value, because the Notification-based DV needs to peel the stack and re-built it (particularly hurting Cog) whereas the ProcessSpecificVariable-based DV 'just' needs some Dict-lookups in the current Process.<br></blockquote><div><br></div><div>This is why I like being specific in terminology. Yes, the thing called DynamicVariable in Squeak trunk is a dynamic variable, and not a delimited dynamic variable, which is exactly why you cannot combine using DynamicVariable and stack manipulations. Debugging happens to do said stack manipulations.</div><div><br></div><div>Yes, the Notification idiom is much less efficient (in its current implementation (*)) than DynamicVariable, but DynamicVariable fundamentally cannot work correctly with stack manipulations. Oleg Kiselyov covers the issue in depth in the various articles linked to from <a href="http://okmij.org/ftp/Computation/dynamic-binding.html#DDBinding">http://okmij.org/ftp/Computation/dynamic-binding.html#DDBinding</a>.</div><div><br></div><div>(*) I would imagine that VM support would allow for efficient delimited dynamic variables, because Henry Baker wrote a whole pile of papers back in the late 70s on the subject (see <a href="http://www.pipeline.com/~hbaker1/home.html">http://www.pipeline.com/~hbaker1/home.html</a>, for instance "Shallow Binding Makes Functional Arrays Fast".</div><div><br></div><div>frank</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
========<br>
<br>
I quite like accessing the current Environment via a dynamic variable, as it exactly provides the control-flow scope that is necessary for this kind of thing.<br>
<br>
We should however adopt a proper DV here, increasing efficiency and readability.<br>
No more 'CurrentEnvironment signal ifNil: […]'<br>
<br>
but rather<br>
<br>
Object>>environment<br>
<br>
^ CurrentEnvironment value<br>
<br>
and<br>
<br>
DynamicVariable subclass: #CurrentEnvironment<br>
instanceVariableNames: ''<br>
classVariableNames: ''<br>
poolDictionaries: ''<br>
category: '...'<br>
and<br>
CurrentEnvironment class>>default<br>
<br>
^ Smalltalk globals<br>
<br>
and then, for example<br>
<br>
EnvironmentLoader>>evaluate: chunk<br>
<br>
^ CurrentEnvironment use: environment during:<br>
[Compiler evaluate: chunk environment: environment]<br>
<br>
<br>
(not tested, tho)<br>
<br>
Best regards<br>
<span class="gmail-HOEnZb"><font color="#888888"> -Tobias<br>
</font></span><br>
PS: I sometimes call DVs semi-globals. not really global, not really non-global…<br>
<br>
<br>
</blockquote></div><br></div></div>