Dynamic scoping (take 2)
Me
C<temp> and C<let> right:
1. C<temp> dynamically scopes changes to a
variable's value to the enclosing block.
It does not dynamically scope the name.
The variable can obviously be a global.
It can also make sense if it is lexical.
Is the latter currently allowed?
2. C<let> is a conditional C<temp>; it only
restores a variable's value if, on exit
from the enclosing block, the block is
somehow considered to have "failed". It
can be applied to a global or lexical.
The above two features are basically sugar
for what would otherwise be achieved with
paired FIRST/LAST/UNDO blocks.
Both must be applied to an existing variable.
Next, I want to do a better job of stating
a problem I wonder about:
Consider "environmental" values such as
"screen sizes, graphics contexts, file
handles, environment variables, and
foreign interface environment handles." [1]
Consider a sub One that is going to call
a 10 deep stack of subs such that sub Ten
needs to access one of these environmental
values. How do you pass the data?
A. Globals. Bad. Disastrous in threads.
B. Passed as args to all intervening subs.
Verbose. Sometimes incredibly verbose.
C. Aggregate info into objects. But then
you still have to do either 1 or 2 above
with the object references. And it's a
shame to be forced to the object paradigm
unnecessarily.
D. Use $CALLERS::. Relatively succinct, but
definitely error-prone and ugly.
Given what I understand of Perl 6 syntax,
Parrot, and Perl philosophy, I suspect P6
should, and could fairly easily, provide a
good solution to the problem outlined above.
Does anyone agree the problem I've outlined
is inadequately addressed by $CALLERS::?
In previous emails I've suggested:
1. The notion of something like attaching
a C<passed> property on variables, and
picking appropriate defaults for its
args (not/ro/rw), to allow the writer
of a sub to easily strictly limit what
a called sub can access.
2. The notion of args that are explicitly
defined in a sub's sig but implicitly
passed. This kills most of the verbosity
of B above, while, in combination with
the previous point, being otherwise just
as safe as passing args explicitly all
the way down the call stack.
--
ralph
Me
> [implicit args]
Here's a snippet of conversation on a
haskell list about implementation of
implicit args : http://tinyurl.com/2ym1
--
ralph
Me
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
# unless it is passed
# to a sub explicitly.
my $foo; # same for $foo
my $baz is yours; # $baz will automatically
$baz = 10; # be passed to /directly/
# called subs that "ask"
# explicitly for $baz.
&waldo($foo);
}
sub waldo ($b ; $baz is yours)
{ print $baz; &emer; }
sub emer (;$baz is yours(no))
{ print $baz; &qux; }
sub qux { ... }
Running this prints '1010'. Here's why:
A property exists that can mark any lexical
as "yours". When a variable is marked yours
it is automatically passed to any directly
called sub (not nested subs) that mentions
it appropriately.
The "automatic" $_ (available without
declaring with a 'my') is marked "yours"
by default.
All other (ie declared) lexicals are, by
default, not yours, hence guaranteed to be
private lexicals unless explicitly passed
to a sub. This is safer than the current
perl 6 design in which use of $CALLER::,
and even builtins and subs that merely
use the topic, might accidentally clobber
one of my lexicals at any time.
Once execution reaches the body of waldo,
there is a new lexical called $baz that is
bound to the lexical with the same name in
the body of the caller.
The C<is yours> in waldo's sig has two
effects:
1. It requires that any /caller/ has a
variable of the same name marked as
yours or must pass a variable/value
using the named arg syntax for that
arg name;
2. It propogates the marking of $baz as
a yours marked variable for any sub
called from this, the body of waldo.
Once execution reaches the body of emer,
there is a new lexical called $baz that is
bound to the lexical from waldo which is in
turn bound to the lexical within qux.
The '(no)' at the end of the C<is yours>
means that $baz is private to emer -- it
will not be passed to called subs by the
yours mechanism.
In summary, you mark variables that are
to be automatically passed from sub to
sub with 'is yours' where appropriate.
--
ralph
Arcadi Shehter
If I misunderstood you -- correct me. It seems that all you worry
about is that you want some variable be seen in several subroutines
.. you propose a mechanism of passing them between desired subroutins
by default through all the dynamical chain of sub calls "connecting
them. It seems , on the other hand , that there is already existing
and ( to my taste ) simpler mechanism of making several subroutines (
and in general -- any lexical scopes ) share *the same* variable --
package ... ;
sub a { our $x is private ; ... } ; #...but see below ...
sub b { our $x is private ; ... } ;
so $x is *package* variable that can be seen *only* from "a" and "b".
it plays the role of "mailbox" : "a" can put there whatever it want to
pass to "b" . "b" should know about it ( and it knows because it
declares $x inside its body ) and should fetch whatever it wants.
it seems that this mechanism is cleaner and clearer and .. more
intuitive.
although...
on the second thought I have a feeling that I am pulling "is private"
property too much -- this way of using it was not discussed in Exe3.
so probably we should invent the property that does exactly that :
this variable is package *but* it is seen only from *several* lexical
scopes , something like this :
package ... ;
sub a { our $x is shared ; ... } ;
sub b { our $x is shared ; ... } ;
we can even prescribe which lexical scope is allowed to change it :
package ... ;
sub a { our $x is shared is rw; ... } ;
sub b { our $x is shared is ro; ... } ;
but maybe this is abuse for rw and ro here -- so this should be
package ... ;
sub a { our $x is shared(rw) ; ... } ;
sub b { our $x is shared(ro) ; ... } ;
also there is one thing that bothers me about even the original "is
private" property : what if my package is *really big* and I have in
two distant places two function that each want its own "static"
variable that they declare as Exe3 prescribe as
our $var is private;
but since I dont remember about having two such subs I can happen to
give them the same name - so that naively they will be aliased to the
same package variable . Now, with "is private" that is , probably not
a problem , because compiler can notice this and complain about it .
but If I want to pull similar mechanism for *sharing* variables --
this becomes a problem -- compiler cannot know that I wanted to share
one variable $x between aub A and sub B and *another* variable (
which I mistakenly called $x too ) between sub C and sub D . In this
case it will share $x between *all four* subs. I dont know how to
stop this source of errors . currently . but anyway that is what
bothered me with "is private" property.
anyway, my feeling is that once it is necessary to pass variable far
enough it is clearer to do it with globals -- which are restricted to
be seen only in the restricted set of lexical scopes.
arcadi .
Arcadi Shehter
I think , ( on the second reading of your post ) , that your proposal
of "my $x is yours" is logically very similar to my proposal of "our
$x is shared" but your proposal is cleaner if I understand it as
follows ( although I like more "shared" instead of "yours" for that
purpose ) : instead of aliasing the lexical variable variable $x to
the variable of the same name in the *current package* is yours
*create* a new (secret) symbol-table that is remembered by compiler to
be associated with variable $x and *aliases* $x to the variable of the
same name in that (secret) symbol-table . *Any* other instances of
"$x is yours" *alias* $x to *the same* variable $x in that (same)
secret symbol-table.
I do understand that strictly speaking you proposal is *very*
different -- since you want only those function that will *ever* call
each other ( not necessarily directly ) to share ( by default ) some
variable -- so you propose dynamic (???) sharing . I propose *static*
sharing -- but in practice they are *the same* -- the only difference
is that I may happen to make two functions that *never* call each
other ( or never happen to be in the same dynamic scope ) to share the
same variable . But I am in controll of this ( If I am carefull lI
will not do it -- and share variables only between those functions that it
makes sence to share between ).
my point is that static sharing is simpler to understand ( to me ) and
it is a simpler concept -- just some "mailbox" variable that "hangs"
somewere above the "battlefield" that only
several people can access . dynamic sharing is like a *red* message that
have to be passed ( secretly ) every time a soldier have it happens
to *meet* another soldier that know that it have to receive *red*
message.
and I am not talking about implementation .
arcadi
Me
> between desired subroutins by default
> through all the dynamical chain of sub
> calls "connecting them.
There's more, or rather, less to it than that.
The same mechanism also includes a clean way
to pass "it", something that needs to be done.
And a way to smoothly extend that for user
defined "pronouns" like $first, $rest and
$last, through to mini-vocabularies like
$source, $target, $user, ...
(Imagine you pull in fop1, fop2, fop3 that
are file ops written by three independent
authors that just agreed to conventions on
naming args. With the mechanism I propose
you can now do something like:
my $source, $target, $user;
...
fop1;
fop2;
fop3;
To get this sort of simplicity, you have
to decouple inter-sub interfaces in a
couple ways, including arg positions and
package names.)
So I'm addressing several idioms that range
from passing one or two pronouns around in
the local vicinity, between a caller and a
called sub, to passing a whole suite of
values (an "environment") to an execution
thread and the far away subs it will contain.
> anyway, my feeling is that once it is
> necessary to pass variable far enough
> it is clearer to do it with globals --
> which are restricted to be seen only
> in the restricted set of lexical scopes.
That's name restriction, not the container.
This doesn't help when dealing with threads.
Basically, global /containers/ is the root
of all evil, not so much global names.
> package ... ;
> sub a { our $x is shared ; ... } ;
> sub b { our $x is shared ; ... } ;
This isn't thread-safe.
There are other significant issues too, but
I'll move on.
> [accidentally aliasing vars to the same global]
> I dont know how to stop this source of errors.
Having lots of little local namespaces that
get chained across long distances does away
with this problem.
--
ralph
Me
But that's because that's the way you are
thinking about the problem/solution.
I'm just talking about a very local trick
of having autoargs instead of explicitly
passing args in parens. The fact that this
ends up creating an elegant alternative to
dangerous globals is in an important way a
mere somewhat surprising side-effect that
you don't even need to tell a newbie or
even an expert. It just works.
I've considered names like "passed",
"autoarg", "implied", and so on.
But ultimately yours seems to say it all:
my $foo is yours;
My means my lexical and yours means your
lexical where sub calling is the boundary
of what's mine and yours.
> (secret) symbol-table
I would have thought the symbol table
handling for implicit (your) args would
be the exact same as for regular explicit
args passed in parens.
> so you propose dynamic (???) sharing.
> I propose *static* sharing -- but in
> practice they are *the same* --
I'd claim that:
1. Autoargs would work with threads, static
sharing won't.
2. By requiring explicit marking of autoargs
all along the call chain, one retains a key
advantage of explicitly passing args, namely
avoidance of accidental action-at-a-distance.
Just look at a sub's sig to know what is
being shared between it and its callers.
3. Autoargs are significantly less verbose
in many scenarios.
4. Autoargs are conceptually simpler than
shared variables, for both newbies and
experts. But clearly this is subjective. :>
--
ralph
Arcadi Shehter
>
> 4. Autoargs are conceptually simpler than
> shared variables, for both newbies and
> experts. But clearly this is subjective. :>
>
thats exactly the point where I tryed to improve. Think of me as a
newbe ( which I am ) -- If I understand your proposal , I can explain it to
myself through the "sort of" shared variable :
$x is yours
tells that $x is aliased to variable in some "secret scope symbol
table" that ( the table ) is shared between caller and callee
also, another way :
$x is yours
is like saying that all functions that will ever call each other (
that is, if in my programm A calls B and B calls C and ... , then I
will croup them in a group that "ever call each other" ) and
which each have a declaration "$x is yours" may be thought
of as being in special common *enclosing* lexical scope , at the top
of which there is a declaration
my $x ;
so they all *share* the same variable .
I think the effect here is the same as what you are saying .
but may be I am wrong.
also , there is another question :
{
my $x is yours = 1;
a ;
print $x # print 1 or 5 ?
}
sub a { $x is yours ; $x = 5 ; }
( in my formulation it prints 5 ) .
so the question is : is "is yours" variable assigned or aliased in the
callee scope ? probably I missed this from your explanations .
probably we should have both , and then "is yours" mechanism is more
general .
also , anothre question . if "is shared" isn't thread safe , is static
scoping using
our $x is private ;
thread safe ??
arcadi .
Me
for the first time tonight.
> $x is yours
>
> tells that $x is aliased to variable in
> some "secret scope symbol table" that
>( the table ) is shared between caller
> and callee
The "secret" place is MyYourca, a Subterranean
island. People think it's an old, dangerous and
complex place, but actually it's a new, simple,
friendly, safe yet dynamic principality that
juxtaposes two localities each of which is just
an ordinary lexicality, as a defense against the
evils of globalization.
I'm not sure about the symbolism of all this;
I'll let others hash that out.
> also, another way :
>
> $x is yours
>
> is like saying that all functions that
> will ever call each other ... then I
> will croup them in a group ... may be
> thought of as being in special common
> *enclosing* lexical scope
Perhaps. I find what you've said confusing
so I'm not sure what you mean.
MyYourca already exists for transfer of
variables to called subs via parens; the
scheme I'm talking about just uses the
same MyYourca.
> *share* the same variable.
In the sense that $foo in:
sub baz ($foo) { print $foo };
sub bar { my $foo; baz ($foo); };
is shared (between baz and bar), then yes.
Anything more complicated than that, then,
technically, no.
> {
> my $x is yours = 1;
> a ;
> print $x # print 1 or 5 ?
> }
>
> sub a { $x is yours ; $x = 5 ; }
In my scheme, that would print 1 and some
variable $x that was declared either
package-wise or lexically at the point
where sub a was defined has been changed
to 5.
If sub a were defined this way:
sub a (;$x is yours) { $x = 5 ; }
then it would print 5.
> is "is yours" variable assigned or aliased
> in the callee scope ? probably we should
> have both , and then "is yours" mechanism
> is more general .
Well I was thinking it's always aliased but
can be read-only by attaching C<yours(ro)>
to a variable declaration (as part of an
explicit my, not in a sig; you can't put
C<is yours(ro)> in a sig -- I can't see an
alias/copy distinction, nor ability to set
ro in a sig, being worth the complexity
they introduce).
> also , anothre question . if "is shared"
> isn't thread safe , is static scoping using
>
> our $x is private ;
>
> thread safe ??
I may have incorrectly used the term "thread
safe". The point is that you can't arrange
for there being a unique $x for multiple
threads of the same code. At least I don't
see how.
--
ralph
Arcadi Shehter
so these two are equivalent ???
{
my $x is yours ;
my $y is yours ;
my $z is yours ;
....1...
sub_a ;
....2...
}
sub sub_a ( ; $x is yours, $y is yours ) { ...3... } ;
----------------------------- same as -------------
# ( here no special meaning for "is yours" -- just another property )
{
my $x is yours ;
my $y is yours ;
my $z is yours ;
....1...
#alias %MY to topic so that it can be fetched from sub_a by "is given"
$_ ::= \%MY ;
sub_a ;
....2...
}
sub sub_a ( ;$x is yours,
$y is yours ) is given($CALLER_SYMB)
{
#alias variables from $CALLER_SYMB to the local variables if
#requested
$SUB_SYMB ::= \%MY ;
for $SUB_SYMB.keys {
if $SUB_SYMB{$_}.yours
and $CALLER_SYMB{$_}.yours
{
$SUB_SYMB{$_} ::= $CALLER_SYMB{$_} ;
}
} ;
$CALLER_SYMB = undef ; #but better if this happens at compile time
# -- probably this have to be forced with
# BEGIN
....3...
} ;
arcadi
Larry Wall
: First, I'd like to confirm I've understood
: C<temp> and C<let> right:
:
: 1. C<temp> dynamically scopes changes to a
: variable's value to the enclosing block.
: It does not dynamically scope the name.
: The variable can obviously be a global.
: It can also make sense if it is lexical.
: Is the latter currently allowed?
I'm planning to allow it unless someone can come up with a good reason not to.
: 2. C<let> is a conditional C<temp>; it only
: restores a variable's value if, on exit
: from the enclosing block, the block is
: somehow considered to have "failed". It
: can be applied to a global or lexical.
At the moment, it doesn't apply to either. It applies only to the
current regex's variables. It is a bit of an inconsistency that
in the current model, regex variables are lexically scoped but not
actually declared. This may be a mistake.
: The above two features are basically sugar
: for what would otherwise be achieved with
: paired FIRST/LAST/UNDO blocks.
Well, there's no UNDO defined for regex backtracking unless we define
some kind of BACK block, but conceptually you're basically right.
: Both must be applied to an existing variable.
Not strictly true. if you say
/foo bar { let $baz = 2 } /
the $baz is creating a new variable within the scope of the surrounding regex.
: Next, I want to do a better job of stating
: a problem I wonder about:
:
: Consider "environmental" values such as
: "screen sizes, graphics contexts, file
: handles, environment variables, and
: foreign interface environment handles." [1]
:
: Consider a sub One that is going to call
: a 10 deep stack of subs such that sub Ten
: needs to access one of these environmental
: values. How do you pass the data?
:
: A. Globals. Bad. Disastrous in threads.
:
: B. Passed as args to all intervening subs.
: Verbose. Sometimes incredibly verbose.
:
: C. Aggregate info into objects. But then
: you still have to do either 1 or 2 above
: with the object references. And it's a
: shame to be forced to the object paradigm
: unnecessarily.
:
: D. Use $CALLERS::. Relatively succinct, but
: definitely error-prone and ugly.
But you haven't mentioned what's really going on with package
variables:
E. Passed via thread-local storage. Under I-threads, package variables
are *not* shared by default among threads, so they can be scoped
dynamically without the threading problems of A. Package variables
are global only if you squint really hard.
: Given what I understand of Perl 6 syntax,
: Parrot, and Perl philosophy, I suspect P6
: should, and could fairly easily, provide a
: good solution to the problem outlined above.
:
: Does anyone agree the problem I've outlined
: is inadequately addressed by $CALLERS::?
The real question is, do I agree. :-)
: In previous emails I've suggested:
:
: 1. The notion of something like attaching
: a C<passed> property on variables, and
: picking appropriate defaults for its
: args (not/ro/rw), to allow the writer
: of a sub to easily strictly limit what
: a called sub can access.
I think the granularity is wrong on this. Trying to mesh the
namespaces of caller and callee is a big problem as soon as you
have multiple callees with different ideas. In other words, I think
it's probably a mistake to try to generalize implicit $_ passing to
any name.
: 2. The notion of args that are explicitly
: defined in a sub's sig but implicitly
: passed. This kills most of the verbosity
: of B above, while, in combination with
: the previous point, being otherwise just
: as safe as passing args explicitly all
: the way down the call stack.
We already have currying, and I think that notion should be extended to
handle any caller-instituted defaulting. The granularity can be controlled
on a sub-by-sub or on a class-by-class basis.
# curry sub
my $DBhandle = mumble();
my &shortcut ::= &longcut.assuming(handle => $DBhandle);
# curry all methods of a class
use Dog.assuming(tail => "cut_short", ears => "cut_long");
my $little_dog = Dog.where_oh_where();
or some such. If there are early-binding/late-binding issues we
should address those as part of the currying design. For instance,
it's not clear above whether $DBhandle is evaluated at compile time
or run time. I think we have to say that it's a binding, which means
the value of handle depends on the *current* value of $DBhandle each
time the shortcut is called.
Basically, the parameter list of the subroutine is already providing a
limited namespace to be shared by caller and callee. If the caller really
wants to bind to a variable of the same name, they can always say
my $bar;
&foo.assuming(bar => $bar)
But I think it would be wrong for the callee to start forcing its
namespace into the namespace of the caller beyond what we already do
with named parameter syntax (and $_).
Larry
Simon Cozens
> : It can also make sense if it is lexical.
> : Is the latter currently allowed?
>
> I'm planning to allow it unless someone can come up with a good reason not to.
What were the good reasons for not allowing localized lexicals in Perl 5?
--
User: In 1793 the french king was executed.
MegaHAL: HA HA HA! CORRECT. ALTHOUGH, EXECUTED HAS MULTIPLE MEANINGS.
Me
Larry:
> I think that currying should be extended to
> handle any caller-instituted defaulting.
Argh. So obvious! (So of course I missed it.)
> Basically, the parameter list of the subroutine
> is already providing a limited namespace to be
> shared by caller and callee.
> ...
> But I think it would be wrong for the callee to
> start forcing its namespace into the namespace
> of the caller beyond what we already do with
> named parameter syntax (and $_).
Yes. I was following the same principles.
But I much prefer your route, that is, to use
assuming (a suggested perl lingo replacement
for currying) which so clearly fits the bill.
I love (natural) brevity, so perhaps one could
have .assuming map passed arg values that are
variables (rather than pairs) to a target arg
of same name:
my $tail = "cut_short";
my $ears = "cut_long";
Dog.assuming($tail, $ears);
What's the briefest way to say:
for [Dog, Devil] { use .assuming($tail, $ears) };
Presumably this won't work:
use (Dog&Devil).assuming($tail, $ears);
--
ralph
Randal L. Schwartz
Simon> What were the good reasons for not allowing localized lexicals in Perl 5?
Nobody could explain it in 50 words or less.
"What the hell is 'local my $foo = 35'?"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Me
idea is history, but for closure, yes, this
seems to be headed in the right direction,
at least in theory. It may have even been
practical to implement it thru the standard
property mechanism.
--
ralph
Me
no-global grail trail for at least one
more post.
> The granularity [of currying] can be
> controlled on a sub-by-sub or on a
> class-by-class basis.
If one could do something like this:
{
my $src = 'oldname1';
my $dest = 'newname1';
use FileUtils.default($src, $dest);
# FileUtils subs now use $src and/or
# $dest if $src and/or $dest args are
# not supplied at run-time:
&foo;
&foo('oldname2','newname2');
}
# FileUtils subs revert to normal
sub foo (;$src, $dest) {
&FileUtils::rename($src, $dest);
}
where FileUtils is a module (ie one can
curry classes OR modules), and where the
use XXX.default has something akin to the
effect of currying FileUtils sub calls
/if the relevant args do not exist/ till
the end of the enclosing lexical scope
for the current execution thread, and
where all of this can be done without a
significant hit to performance, then you
appear to have completely eliminated the
practical need for creating globals and
replaced it with a succinct and intuitive
way to express what's going on (even if
my example above isn't the clearest way
to explain it).
--
ralph
Larry Wall
: >>>>> "Simon" == Simon Cozens <si...@simon-cozens.org> writes:
:
: Simon> What were the good reasons for not allowing localized lexicals in Perl 5?
:
: Nobody could explain it in 50 words or less.
:
: "What the hell is 'local my $foo = 35'?"
That particular form is useless, since the scope of the temporization
is the same as the scope of the lexical. But there's no reason
not to be able to temporize a file-scoped lexical, for instance,
so that it behaves as a global to all the subs in the current file,
but is invisible outside the file.
Well, hey, that's close to 50 words. :-)
Larry