Re: Hypothetical variables and scope
Jonathan Scott Duff wrote:
Because what you do with a hypothetical has to be reversible.
I thought it was just the hypothetical's existence that has to be
reversible.
That's not my understanding. You need to be able to cope with this too:
rule alias :w { \$ $name:=ident [is named \( $name:=ident \) ]? }
and have $name end up bound to the correct submatch even if the closing
paren is missing and the optional block fails.
Sounds like an optimization that should be in the hands of the
programmer to me.
Possibly. Though leaving optimization in the hands of the programmer
is generally a Bad Idea.
It's also a matter of syntactic consistency. It has to be := for
inlined bindings (i.e. rx/ $name:=ident /) because otherwise
we make = meta (which is *not* a good idea). So it probably should be
:= for explicit Clets as well.
Damian
Re: Hypothetical variables and scope
Damian Conway wrote:
Though leaving optimization in the hands of the programmer
is generally a Bad Idea.
That doesn't sound like a Perl slogan.
It's also a matter of syntactic consistency. It has to be := for
inlined bindings (i.e. rx/ $name:=ident /) because otherwise
we make = meta (which is *not* a good idea). So it probably should be
:= for explicit Clets as well.
If let only works on bindings, it really bites into the
expressiveness of the language. For example, the natural way
to skip text within a match is to do something like:
/ (\w+) \d+ (\w+) { let $1 _= $2; let $2 = undef } /
This feels natural too:
/ (\w+ \d+ \w+) { let $1 =~ s/\d+// } /
Binding might be really fast for some implementations of Perl,
but slow for others. Just like string eval may be impossible in
some, but trivial in others.
- Ken
Re: Hypothetical variables and scope
At 6:59 AM + 9/7/02, Damian Conway wrote: Jonathan Scott Duff wrote: Sounds like an optimization that should be in the hands of the programmer to me. Possibly. Though leaving optimization in the hands of the programmer is generally a Bad Idea. Oh, I dunno... If that programmer is me or one of the other folks from perl6-internals I think you're OK. :) Generally things are better if people clarify what they want, rather than specify optimization hints, otherwise you end up with dopey things like Java's final stuff. If the optimizer knows what you want to do it is more likely to be able generate fast code, but that works best when you clearly express the semantics -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Hypothetical variables and scope
Jonathan Scott Duff wrote:
This continues to make no sense to me. The hypotheticality of a
variable seems quite orthogonal to what you do with it (bind, assign,
whatever). Why should these two things be intimate?
Because what you do with a hypothetical has to be reversible.
And binding is far more cheaply reversible than assignment.
It's also far cheaper in the forward direction. And that's
important in pattern matching, especially as we may be to-and-fro-ing
over the hypothetical many times.
And if they are,
does that mean that these:
/ (\S*) { let $x = .pos } \s* foo /
/ (\S*) { let $x; ... $x = .pos } \s* foo /
throw some sort of exception or error?
Compile-time syntax error, I'd expect.
That could be surprising if
the ellipses are really some long bit of code. (Why is that scalar
different from any other scalar? Because it's hypothetical.
Yes. Because it's reversible.
Suddenly we've a new class of variable that people have to be aware of)
Yes.
Damian
Re: Hypothetical variables and scope
Damian Conway wrote: Because what you do with a hypothetical has to be reversible. And binding is far more cheaply reversible than assignment. Why not leave it in the language spec then? If it's too hard to implement, then the first release of Perl 6 can leave it out. Someday somebody might come up with an implementation. BTW, I thought the Apocalypses were moving us away from the-tarball-defines-the-language. Am I wrong to think that Perl 6 the spec may have more than Perl 6 the release? - Ken
Re: Hypothetical variables and scope
On Thu, Sep 05, 2002 at 03:38:03PM +, Damian Conway wrote: Jonathan Scott Duff wrote: This continues to make no sense to me. The hypotheticality of a variable seems quite orthogonal to what you do with it (bind, assign, whatever). Why should these two things be intimate? Because what you do with a hypothetical has to be reversible. I thought it was just the hypothetical's existence that has to be reversible. And binding is far more cheaply reversible than assignment. It's also far cheaper in the forward direction. And that's important in pattern matching, especially as we may be to-and-fro-ing over the hypothetical many times. Sounds like an optimization that should be in the hands of the programmer to me. Given that we've already given the programmer the ability to put arbitrarily complex code in the pattern, I think the expense of assignment versus binding may wash out in the forward direction. And the expense in the reverse direction may be equal if it just has to destroy the variable. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Hypothetical variables and scope
Ken Fox wrote:
/ $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
Shouldn't they both use C := ?
They should. The second version is a typo. It should be:
/ (gr\w+) { let $x := $1 } /
Depends on what you want. The $x := in the rule binds the
first match to $x -- it does not copy the value. The $x =
in the code block copies the value of the first match. You
can use either binding or assignment in the code block.
But not with the Clet keyword. That requires binding.
Both of them will be undone during backtracking. It's more
efficient to bind, but the copy guarantees changes to $x and $1
are independent.
This is not what Larry has said previously. He said that only
binding can be used with Clet variables and that only Clet
variable assignments are undone on backtracking.
Damian
Re: Hypothetical variables and scope
On Wed, Sep 04, 2002 at 11:27:46AM +, Damian Conway wrote:
This is not what Larry has said previously. He said that only
binding can be used with Clet variables and that only Clet
variable assignments are undone on backtracking.
It seems odd to require two syntactic elements to achieve one semantic.
And actually, after looking at A5, that's not what Larry wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
After this pattern, $x will be set to the ending position of
$1--but only if the pattern succeeds. If it fails, $x is
restored to undef when the closure is backtracked
I don't see any binding there, just letting.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Hypothetical variables and scope
On Wed, 2002-09-04 at 14:38, Jonathan Scott Duff wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
After this pattern, $x will be set to the ending position of
$1--but only if the pattern succeeds. If it fails, $x is
restored to undef when the closure is backtracked
I don't see any binding there, just letting.
I think the confusion here is that let is creating a binding, but the
binding is between the named variable (e.g. C$x) and the storage in
the result object (e.g. C$0.{x}). What C$0.{x} is is kind of beside
the point. It may be a binding as in:
... {let $x := $1} ...
or a stand-alone value as in:
... {let $x = $1 + 100} ...
Does this make sense? As I understand it, the let statement is
translated to something like this:
... { $self.{x} = sub {$1 + 100}; $x := $self.{x} } ...
Which will then be evaluated and the result substituted:
$0.{x} = $0.{x}.();
once backtracking is complete to avoid evaluating C$1 + 100 before a
final understanding of what C$1 contains is reached.
Is that roughly correct?
Re: Hypothetical variables and scope
On Wed, 2002-09-04 at 07:28, Damian Conway wrote:
Aaron Sherman wrote:
Hmm... I had not thought of the copy aspect. Certainly, the code version
is more flexible. You could define C$x above as anything. For example:
/ (gr\w+) {let $x = Gr_Thing.new($1)} /
The binding version is just a simple, fast version of one special case,
no?
No. It's the *only* way to set hypotheticals. Of course, you *can* always
do:
/ (gr\w+) { $x = Gr_Thing.new($1)} /
You chopped off some context. The discussion was about
/ $x := (gr\w+) /vs/ (gr\w+) { let $x := $1 } /
Not hypotheticals in particular. So, the question was is binding C$x
to C$1 via the former statement the same as binding C$x to C$1 via
the latter. I the replied that the former was in fact doable using the
latter syntax, but was more efficient (no closure to execute) while not
offering the flexibility of something like:
/ (gr\w+) {let $x = Gr_Thing.new($1)} /
I think you were saying the same thing as I was (e.g. that you could
only assign a hypothetical to a complex value this way).
Re: Hypothetical variables and scope
Jonathan Scott Duff wrote:
It seems odd to require two syntactic elements to achieve one semantic.
And actually, after looking at A5, that's not what Larry wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in discussions that
hypothetical bind, rather than assigning.
Perhaps he's changed his mind since, but I haven't heard anything to that
effect.
Damian
Re: Hypothetical variables and scope
On Wed, Sep 04, 2002 at 10:25:39PM +, Damian Conway wrote:
Jonathan Scott Duff wrote:
It seems odd to require two syntactic elements to achieve one semantic.
And actually, after looking at A5, that's not what Larry wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in discussions that
hypothetical bind, rather than assigning.
This continues to make no sense to me. The hypotheticality of a
variable seems quite orthogonal to what you do with it (bind, assign,
whatever). Why should these two things be intimate? And if they are,
does that mean that these:
/ (\S*) { let $x = .pos } \s* foo /
/ (\S*) { let $x; ... $x = .pos } \s* foo /
throw some sort of exception or error? That could be surprising if
the ellipses are really some long bit of code. (Why is that scalar
different from any other scalar? Because it's hypothetical. Suddenly
we've a new class of variable that people have to be aware of)
Anyway, I like the semantics described by Ken Fox earlier. (And, in
fact, that's what I thought happened until just recently :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Hypothetical variables and scope
On Mon, 2 Sep 2002 23:50:18 -0400 (EDT), Trey Harris wrote:
In a message dated 2 Sep 2002, Aaron Sherman writes:
{
my $x = 2;
my $y = The grass is green;
$y =~ /(gr\w+) {let $x = $1}/;
}
Yes. $0{x} would be set to grass. A lexical variable has been defined
in the same scope as the hypothetical with the same name, so its value is
set hypothetically (is hypothetically bound to?) $0{x}. When the rule
succeeds, $x's hypothetical value is made permanent.
module foo;
rule gr_word { (gr\w+) {let $x = $1} }
my code
use foo;
my $x = 2;
The grass is green =~ /gr_word/;
No. $0{x} would be set to grass. $x would stay as 2. $x is in a
different scope from the hypothetical, so it doesn't get touched.
Presumably there is some variant of the strict pragma which would catch
misspellings of $x. Actually, I'd like to see something explicit in the
rule which states whether the hypothetical binding applies to the surrounding
scope as well as to the match variables. Unfortunately, the only way I can
think of doing this is to state $OUTER::x, which is pretty horrible, and
doesn't give the impression that both the external variable and the match
variable are being bound.
Also the different operators used (:= inside the rule, = inside the code)
seems a bit confusing to me; I can't see that they're really doing anything
different:
/ $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
Shouldn't they both use C := ?
--
Peter Haworth [EMAIL PROTECTED]
Some more data?
No, no more. Please, no more...
-- Yanick, examining perl's strange behaviour
Re: Hypothetical variables and scope
Peter Haworth wrote:
Also the different operators used (:= inside the rule, = inside the code)
seems a bit confusing to me; I can't see that they're really doing anything
different:
/ $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
Shouldn't they both use C := ?
Depends on what you want. The $x := in the rule binds the
first match to $x -- it does not copy the value. The $x =
in the code block copies the value of the first match. You
can use either binding or assignment in the code block.
Both of them will be undone during backtracking. It's more
efficient to bind, but the copy guarantees changes to $x and $1
are independent.
- Ken
Re: Hypothetical variables and scope
On Tue, 2002-09-03 at 11:35, Ken Fox wrote:
Peter Haworth wrote:
Also the different operators used (:= inside the rule, = inside the code)
seems a bit confusing to me; I can't see that they're really doing anything
different:
/ $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
Shouldn't they both use C := ?
Depends on what you want. The $x := in the rule binds the
first match to $x -- it does not copy the value. The $x =
in the code block copies the value of the first match. You
can use either binding or assignment in the code block.
Hmm... I had not thought of the copy aspect. Certainly, the code version
is more flexible. You could define C$x above as anything. For example:
/ (gr\w+) {let $x = Gr_Thing.new($1)} /
The binding version is just a simple, fast version of one special case,
no?
Re: Hypothetical variables and scope
In a message dated 2 Sep 2002, Aaron Sherman writes:
I'm working on a library of rules and subroutines for dealing with UNIX
system files. This is really just a mental exercise to help me grasp the
new pattern stuff from A5.
I've hit a snag, though, on hypothetical variables. How would this code
work?
{
my $x = 2;
my $y = The grass is green;
$y =~ /(gr\w+) {let $x = $1}/;
}
I assume that it would change C$x from C2 to Cgrass.
Yes. $0{x} would be set to grass. A lexical variable has been defined
in the same scope as the hypothetical with the same name, so its value is
set hypothetically (is hypothetically bound to?) $0{x}. When the rule
succeeds, $x's hypothetical value is made permanent.
But here's
the case where I'm concerned:
module foo;
rule gr_word { (gr\w+) {let $x = $1} }
my code
use foo;
my $x = 2;
The grass is green =~ /gr_word/;
Would my local C$x be reset to Cgrass?
No. $0{x} would be set to grass. $x would stay as 2. $x is in a
different scope from the hypothetical, so it doesn't get touched.
That would seem to lead to
some very ugly namespace problems, since the module user never asked to
have C$x replaced, it's just a silent side-effect.
Nope, shouldn't have any effect.
Please tell me there's some magic way that this works, so that I'm wrong
:)
I don't think it's magic. It's just scoping.
Trey
Re: Hypothetical variables and scope
On Mon, 2002-09-02 at 23:50, Trey Harris wrote:
No. $0{x} would be set to grass. $x would stay as 2. $x is in a
different scope from the hypothetical, so it doesn't get touched.
Ok, it's just taking some time for me to get my head around just what
C/.../ and Crule{...} are, but I'm getting there. This makes sense
to me now. Question, is there any way that:
%x = / (moo) {let $cow = $1} /
could magically put the pairs from C$0 into C%x? That would be very
helpful for module authors, I would think.
