Clarification for External Regex Variables?
Brad Bowman
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?
Is there any way to introduce a new variable to the containing scope
with a regex? Either the declaration scope or execution scope?
A05 says no, unless MY:: fiddling is allowed. 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 think I've used the word "scope" too much there)
My motivation for this is to use rules as an alternative parameter
list sublanguage. That idea is still in the oven though.
Brad
--
To ask when you already know is politeness. To ask when you don't know
is the rule. -- Hagakure http://bereft.net/hagakure/
Larry Wall
: 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
Brad Bowman
> On Thu, Dec 08, 2005 at 11:14:16PM +0100, Brad Bowman wrote:
> : 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.
Perhaps the "my" could then be placed outside the rule but apply
to the variables bound in the rule. Then the scoping would seem
natural and would have to be explicitly asked for.
I'm not sure where it could be squeezed in:
$str ~~ my m/ mv @files:=<ident>+ $dir:=<ident> /
Nah, that's ugly.
I considered a :my modifier but if you use a rule from elsewhere that
was created with rx:my/../ then variables pop into existence.
Perhaps :my can only be used with m// at rule applications.
But then matching is run time and my is compile time...
> 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,
That does do ease the pressure. I'm sure I'll be able to cope. :)
> 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.)
Great! I'll never need to learn XPATH or XSLT and my YAML schemas
will be rules. Presuming I'm understanding correctly.
One aspect of the "Matching against non-strings" of S05 that seemed
a little strange is the string, string tie-able or array limitation.
Couldn't there be a Matchable role that trees or other objects can do?
While I'm on the topic, how do you bump to the next object when
matching against tokens or other objects in an array?
I guess I'm asking is <.does('Bark')> a zero-width assertion?
Or does <,> skip to the boundary? (presumably not)
Brad
--
People with intelligence will use it to fashion both true and false and will
try to push through whatever they want with their clever reasoning. This is
injury from intelligence.
Nothing you do will have effect if you do not use truth. -- Hagakure
Juerd
> $str ~~ my m/ mv @files:=<ident>+ $dir:=<ident> /
> Nah, that's ugly.
It's mostly ugly because you're not used to it, I think.
my m[mv @files:=<ident>+ $dir:=<ident>] ~~ $str;
Looks nicer, though.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html