Skip Menu |
 
Report information
Id: 60186
Status: rejected
Priority: 0/
Queue: perl6

Owner: pmichaud <pmichaud [at] pobox.com>
Requestors: chris [at] chrisdolan.net
Cc:
AdminCc:

Severity: (no value)
Tag: Patch
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [PATCH] make PGE support {PIR} closures instead of just {{PIR}}
Date: Tue, 28 Oct 2008 00:24:27 -0500
To: rakudobug [...] perl.org
From: Chris Dolan <chris [...] chrisdolan.net>
Download (untitled) / with headers
text/plain 754b
As of parrot rev 32120, PGE only supports the old S05 closure syntax that had double curlies like so /foo {{ say "matched foo" }}/ The current S05 says this is legal: /foo { say "matched foo" }/ This was discussed on perl6.users at: http://www.nntp.perl.org/group/perl.perl6.users/2008/10/msg826.html The attached patch allows one to use either single or double curlies (or triple, etc, actually). I added disambiguation for the "{*}" token which is now a special case of "{...}". Perhaps that latter bit was over-engineering, but I don't grok the optable yet well enough to understand how it disambiguates on its own. In the future, I think we should consider deprecating the extraneous curlies, at least for PIR closures.

Message body is not shown because sender requested not to inline it.

Subject: Re: [perl #60186] [PATCH] make PGE support {PIR} closures instead of just {{PIR}}
Date: Tue, 28 Oct 2008 10:05:01 -0500
To: perl6-compiler [...] perl.org
From: "Patrick R. Michaud" <pmichaud [...] pobox.com>
Download (untitled) / with headers
text/plain 588b
On Mon, Oct 27, 2008 at 10:24:56PM -0700, Chris Dolan wrote: Show quoted text
> The attached patch allows one to use either single or double curlies > (or triple, etc, actually). I added disambiguation for the "{*}" > token which is now a special case of "{...}". Perhaps that latter > bit was over-engineering, but I don't grok the optable yet well > enough to understand how it disambiguates on its own.
Disambiguating the {*} isn't necessary, as the optable already does longest token matching, and thus will recognize {*} before the single curly. Other comments on the other threads. Pm
Subject: Re: [perl #60186] [PATCH] make PGE support {PIR} closures instead of just {{PIR}}
Date: Tue, 28 Oct 2008 10:20:26 -0500
To: perl6-compiler [...] perl.org
From: "Patrick R. Michaud" <pmichaud [...] pobox.com>
Download (untitled) / with headers
text/plain 1.8k
On Mon, Oct 27, 2008 at 10:24:56PM -0700, Chris Dolan wrote: Show quoted text
> As of parrot rev 32120, PGE only supports the old S05 closure syntax > that had double curlies like so > /foo {{ say "matched foo" }}/ > > The current S05 says this is legal: > /foo { say "matched foo" }/ > > This was discussed on perl6.users at: > http://www.nntp.perl.org/group/perl.perl6.users/2008/10/msg826.html > > The attached patch allows one to use either single or double curlies > (or triple, etc, actually). I added disambiguation for the "{*}" > token which is now a special case of "{...}". Perhaps that latter > bit was over-engineering, but I don't grok the optable yet well > enough to understand how it disambiguates on its own.
In reality, what has to happen here is that encountering a opening curly brace transfers parsing to the parser for the appropriate language (e.g., Perl 6, PIR, etc.). For example, consider a regex like: /foo { if True { say '{yes}'; } } bar/ Upon encountering the first curly brace we cannot simply scan ahead until the next closing curly brace we happen to find -- we actually have to transfer parsing to a different compiler (one that understands Perl 6), let that compiler parse as much as it can up to an unmatched closing curly brace, and return that result back to the regex parser to continue parsing the rest of the regex. This is why PGE currently requires at least two braces for open and closing, (1) to make it clearer that parsing is being done via a lookahead scan and not an actual parse, and (2) to avoid confusion if the embedded code has any single curlies within it. Beyond that, Parrot and PIR don't currently provide an easy way to switch to/from a PIR parser, so for embedding PIR for the time being we'll have to use some sort of lookahead scan to find the end of the PIR string. Pm
Download (untitled) / with headers
text/plain 128b
Rejecting patch for now... will wait for PGE refactors to work on allowing non-PIR closures. Thanks for submitting a patch! Pm


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org