Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make PGE support {PIR} closures instead of just {{PIR}} #379

Closed
p6rt opened this issue Oct 28, 2008 · 7 comments
Closed

make PGE support {PIR} closures instead of just {{PIR}} #379

p6rt opened this issue Oct 28, 2008 · 7 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Oct 28, 2008

Migrated from rt.perl.org#60186 (status was 'rejected')

Searchable as RT60186$

@p6rt
Copy link
Author

p6rt commented Oct 28, 2008

From @chrisdolan

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.

@p6rt
Copy link
Author

p6rt commented Oct 28, 2008

From @chrisdolan

pge-single-bracket-closure.patch
Index: compilers/pge/PGE/Perl6Regex.pir
===================================================================
--- compilers/pge/PGE/Perl6Regex.pir	(revision 32192)
+++ compilers/pge/PGE/Perl6Regex.pir	(working copy)
@@ -218,7 +218,7 @@
     optable.newtok('term:<commit>', 'equiv'=>'term:', 'nows'=>1, 'match'=>'PGE::Exp::Cut')
 
     $P0 = get_global 'parse_closure'
-    optable.newtok("term:{{",       'equiv'=>'term:', 'nows'=>1, 'parsed'=>$P0)
+    optable.newtok("term:{",        'equiv'=>'term:', 'nows'=>1, 'parsed'=>$P0)
 
     $P0 = get_global 'parse_action'
     optable.newtok("term:{*}",      'equiv'=>'term:', 'nows'=>1, 'parsed'=>$P0)
@@ -1077,7 +1077,11 @@
     .local string target
     .local int pos, len
     (mob, pos, target) = mob.'new'(mob, 'grammar'=>'PGE::Exp::Closure')
-    len = 2
+    len = 1
+    $S0 = substr target, pos, 2
+    if $S0 != "*}" goto init
+    (mob) = parse_action(mob)
+    .return (mob)
   init:
     $S0 = substr target, pos, 1
     if $S0 != "{" goto body

@p6rt
Copy link
Author

p6rt commented Oct 28, 2008

From @pmichaud

On Mon, Oct 27, 2008 at 10​:24​:56PM -0700, Chris Dolan wrote​:

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

@p6rt
Copy link
Author

p6rt commented Oct 28, 2008

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Oct 28, 2008

From @pmichaud

On Mon, Oct 27, 2008 at 10​:24​:56PM -0700, Chris Dolan wrote​:

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

@p6rt
Copy link
Author

p6rt commented Dec 15, 2008

From @pmichaud

Rejecting patch for now... will wait for PGE refactors to work on
allowing non-PIR closures.

Thanks for submitting a patch!

Pm

@p6rt
Copy link
Author

p6rt commented Dec 15, 2008

@pmichaud - Status changed from 'open' to 'rejected'

@p6rt p6rt closed this as completed Dec 15, 2008
@p6rt p6rt added the patch label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant