Hi all,

Slight tangent - I wanted to show a place where I actively want to be 
able to shadow variables lexically.

I am working with an Actor DSL that expands to use of a "well-known" 
local variable called "thisTurn". Here's an example of the kind of 
expanded code I want to be able to have:

   thisTurn spawn: [:thisTurn |

     "NB. thisTurn here is in a different Actor's context to
      the thisTurn that had #spawn: sent to it!"

     thisTurn assert: (Presence new userName: 'me').
     thisTurn assert: (Observe new
       label: #Presence;
       observer: (thisTurn ref
         onAsserted: [:thisTurn :p :handle |
           "Similarly, thisTurn here is the turn active at the
            time an asserted event matching the given label is
            processed, not the time that the Observe assertion is
            made."

           "..."];
         onRetracted: [:thisTurn :handle |
           "..."]))]

The idea is that thisTurn should represent the 
ambiently-active-and-current Turn at the time each little fragment of 
code runs.

I could use a DynamicVariable, but it seems a bit of a shame to use such 
a big hammer to (poorly?) simulate what lexical scope gives for free.

TL;DR: To this old functional programmer, shadowing within a method 
isn't an error, but is instead useful.

Now that we have had proper lexical closures for quite a few years, 
could we consider lifting the restriction on shadowing? I'm aware there 
would likely be social obstacles to doing so; would there also be 
technical obstacles?

Cheers,
   Tony




On 4/18/21 2:44 PM, Marcel Taeumel wrote:
> Hi Christoph, hi Eliot,
> 
> it might be that the likelihood of shadowing increases with the use of 
> cull'ed block invocations, which we have been supporting more and more 
> in the last years:
> 
> self owner ifNotNil: [:owner | "..."].
> self submorphs ifNotEmpty: [:submorphs | "..."].
> 
> As alternative names, one could drop their actual "role" and just use 
> their kinds (as generic as desired):
> 
> self owner ifNotNil: [:morph | "..."].
> self submorphs ifNotEmpty: [:morphs | "..."].
> self submorphs ifNotEmpty: [:objects | "..."].
> 
> In the past, I happened to mistakenly have used the wrong role, 
> shadowing the right one:
> 
> self allOwnersDo: [:owner | "..."].
> self allOwnersDo: [:morph | "..."].
> 
> Yet, we do have misleading protocol on what to actually call "owner." 
> Just the morph that has me directly in its submorphs? That might be 
> another topic. :-)
> 
> ***
> 
> To avoid shadowing, I find myself using (a) abbreviations, (b) 
> kind/class, or (c) count-prefix "a" or "some". Or a combination of 
> those. Unfortunately, omitting the domain-specific role in a name might 
> impair readability.
> 
> I just noticed that I am finde with "aMorph" as a method argument, yet I 
> would never use "a" in a block argument. :-D Strange.
> 
> Best,
> Marcel
> 
>> Am 18.04.2021 05:39:33 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>
>> Hi Christoph,
>>
>>
>> > On Apr 12, 2021, at 12:32 PM, Christoph Thiede wrote:
>> >
>> > Hi Eliot,
>> >
>> > I fear that changes like this will not be very durable unless tested 
>> in any
>> > way. At the moment, you won't even notice a new shadow unless you have
>> > opened a Transcript by accident when accepting a method. Should we maybe
>> > show a message window for shadows instead when compiled interactively,
>> > analogously to the warnings about superfluous temps?
>>
>> I’m removing shadows, not adding new ones. In all cars I saw eleven 
>> ing s from the compiler in the update stream and replaced shadowed 
>> temp cars by renamed temp vars. So my changes have no semantic effect 
>> and only remove the warning.
>>
>> >
>> > (In a larger context, I would strongly opt for (finally) introducing a
>> > mechanism for linter/compiler annotations in CodeHolders. Most modern
>> > editors and IDEs have it, even Pharo; if Squeak does not want to get 
>> left
>> > behind, we should support something like this, too. It could or 
>> should be
>> > configurable, of course.)
>> >
>> > LBNL, if I understand Chris correctly, "anOwner" might be a 
>> suboptimal name
>> > for a variable that holds Morph instances, right? :)
>> >
>> > Best,
>> > Christoph
>> >
>> >
>> >
>> > -----
>> > Carpe Squeak!
>> > --
>> > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>> >
>>
> 
>