Hi Tony,

thanks for this example. :-)

> 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.

Hmm.... I wonder if that would be actually a "big hammer" or just an indication that you favor larger pieces of code (i.e. long methods) over short ones. In modules composed of many short(-ish) methods, I tend to focus on object messaging and higher-level control flow. There, I do not think about lexical scoping as an important design element.

In Vivide, I use DynamicVariable to scope relevant domain objects (i.e. active vivide, active profile, active organization, active script, ...). :-)

(I noticed that Newspeak puts a stronger focus on lexical scoping than Squeak/Smalltalk does.)

Best,
Marcel
Am 19.04.2021 10:36:53 schrieb Tony Garnock-Jones <tonyg at leastfixedpoint.com>:
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 :
>>
>> 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
>> >
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210419/898a3a8a/attachment.html>