On Thu, Dec 08, 2005 at 11:14:16PM +0100, Brad Bowman wrote:
: Hello,
:
: I'd like to get clarification on the scoping of variables
: bound in a regex. It's described in S05 as follows:
:
: External aliasing
:
: * Instead of using internal aliases like:
:
: m/ mv @<files>:=<ident>+ $<dir>:=<ident> /
:
: the name of an ordinary variable can be used as an "external
: alias", like so:
:
: m/ mv @files:=<ident>+ $dir:=<ident> /
:
: * In this case, the behaviour of each alias is exactly as describe
: in the previous sections, except that the resulting capture(s) are
: bound directly (but still hypothetically) to the variables of the
: specified name that exist in the scope in which the rule declared.
:
: S05 and A05 both seems to say that @files and $dir must be already declared
: in the scope containing the declaration. Is that correct?
Yes, that's the current intent.
: Is there any way to introduce a new variable to the containing scope
: with a regex? Either the declaration scope or execution scope?
Not currently.
: A05 says no, unless MY:: fiddling is allowed.
MY:: fiddling is disallowed on an already compiled scope, and maybe even
on a compiling scope if COMPILING<$foo> becomes the normative way to
refer to the lexical scope being created.
: I can see that variables
: popping into existence goes against lexical scoping hygiene, but
: it may be acceptable with a "my" in the regex or limiting the
: additions to declaring scope.
I've gone around about that in my head lots of time, but there isn't
a good way to sneak a "my" into rule syntax, and besides, we're trying
to encourage people to think of rules as lexical scopes in their own
right, so even if you did sneak a "my" in there somehow, it would
most naturally limit itself to the scope of the rule.
And, of course, part of our reason for the $<foo> shortcut notation
is to take some of the pressure off the desire for lexical leakage,
but it's also a nice visual pun on <foo>, so self-documenting in a
"pillish" kind of way.
: My motivation for this is to use rules as an alternative parameter
: list sublanguage. That idea is still in the oven though.
Maybe some variant of "is parsed" and macros is where you're headed.
Or maybe we can do something better with named parameter binding:
my ($foo,$bar,*rest) := @/{};
Anyway, @Larry is also trying to come at it from the other direction
by allowing signatures as part of rule syntax, but that's motivated
by wanting to do pattern matching on trees, where a list of child
nodes is construed to look like an argument list. In theory a
declarative nested parameter syntax can be reversed and used to write
the constructors to rebuild the tree that would also be parseable by
the syntax. (Or at least one of those trees.)
Larry
