Sven Van Caekenberghe-2 wrote
> Nicolas,
>
>> On 28 Sep 2017, at 23:56, Nicolas Cellier <
> nicolas.cellier.aka.nice@
> > wrote:
>>
>> Hi Sven,
>> for now it works because the context into which the block is executed
>> still has full access to the variables and receiver of outer context from
>> which the block is declared.
>>
>> But it's not necessarily the case in all dialects.
>> In VW for example, I get nil instead of foobar
>> #('loop on value 1 in nil' 'loop on value 2 in nil' 'loop on value 3 in
>> nil')
>>
>> This is because the optimized block has its own method (a CompiledBlock)
>> and a restricted context (a BlockContext).
>> The receiver is the BlockClosure and this closure has no copiedValues
>> from the outerContext and an outerContext set to nil because some
>> analyzer in the compilation phase thought the closure would never access
>> the outerContext (no return to outerContext) nor any of its variable.
>>
>> Once we'll have clean blocks - depending on the implementation - things
>> might change in Pharo too.
>> But we must ask Clement on this subject (I add not taken time to check
>> the implementation he proposes).
>
> I think I understand: you basically say that the compiler could
> remove/optimise away local/temp variables if it decides they are not used,
> hence accessing them dynamically will fail. This could be compiler/dialect
> specific.
>
> That being said, such behaviour would also make the debugger look strange
> (assigned local/temp is in the source code but not in the context).
>
> In Pharo, even the following (currently) works fine:
>
> [ :x :y | '{x}+{y}={x+y}' interpolate ] value: 7 value: 8.
>
> Sven
Not quite; a clean blocks defining feature is that there's no references to
any variables defined in an outer scope. In other words, a block where all
variables used are either block params, or defined locally in the block. So
the above example is a clean block, and would still work.
Removing temps identified as unused, is an orthagonal optimization.
It's possible to define even more types of blocks based on the defining
scope used (for instance, if a block only uses instance scoped vars/self
calls, it's essentially an anonymous method, and could be cached as such),
but clean/unclean is the most useful distinction.
Like Denis said though, there's really quite a few tools you'd need to
update if you want them to function "correctly" with string interpolation.
Opinions differ, but at least to me, those tools being (mostly*) reliable is
worth more than a less verbose version of format:. If one could have one's
cake and eat it too, however...
(For reference, I just spent some time writing a translator from a custom
application-defined executable string format -> standard blocks for exactly
this reason, once you lose reliable senders/implementors/refactorings, it
can become hard to evolve an application in a confident manner)
Cheers,
Henry
* We already have things like perform: aPartial, selector of course
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
