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
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:= /) because otherwise
> we make = meta (whi
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:= [is named \(
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?
>
>
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 c
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
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 $
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 d
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)} /
> >
> > Th
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 und
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 C variables and that only C
> variable assignments are undone on backtracking.
It seems odd to require two syntactic elements to achieve one se
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 ca
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
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 $
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< := > ?
Depen
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".
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 C are, but I'm getting there. Thi
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
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 = "Th
19 matches
Mail list logo
