Current state?

Since this list has been started, I'd assume that means work on the
final Perl6 compiler is about to start. (Although, with this crowd,
you never do know...)

In the interest of a layman's curiosity: What's the current status?

(And I already wonder if this won't make the summaries even more irregular.=
 ;)
--=20
Schw=E4che zeigen hei=DFt verlieren;
h=E4rte hei=DFt regieren.
  - "Glas und Tr=E4nen", Megaherz
0
methanal
9/8/2004 10:48:05 AM
perl.perl6.compiler 1237 articles. 0 followers. Follow

44 Replies
623 Views

Similar Articles

[PageSpeed] 12

On Wed, Sep 08, 2004 at 10:48:05AM +0000, Herbert Snorrason wrote:
> 
> In the interest of a layman's curiosity: What's the current status?

We're in the beginning stages of building a basic perl 6 grammar engine 
(i.e., probably without p6 closures) that compiles to parrot and handles
basic optimizations.  Concurrent with that I'm working on a Perl 6 grammar.

I'm expecting a working basic grammar engine in a little over a month.
We'll test it on a few simple languages, and then start using it to build
the Perl 6 parser and code generator.

Pm
0
pmichaud
9/8/2004 1:33:45 PM
Patrick R. Michaud wrote:

>We're in the beginning stages of building a basic perl 6 grammar engine 
>(i.e., probably without p6 closures) that compiles to parrot and handles
>basic optimizations.  Concurrent with that I'm working on a Perl 6 grammar.
>  
>
Where can one get a look at these wonderful things? tinderbox.perl.org 
would be my guess, but it does not seem to be working.
0
gregory
9/8/2004 2:53:07 PM
On Wed, Sep 08, 2004 at 07:53:07AM -0700, Gregory Keeney wrote:
> Patrick R. Michaud wrote:
> 
> >We're in the beginning stages of building a basic perl 6 grammar engine 
> >(i.e., probably without p6 closures) that compiles to parrot and handles
> >basic optimizations.  Concurrent with that I'm working on a Perl 6 grammar.
> > 
> >
> Where can one get a look at these wonderful things? tinderbox.perl.org 
> would be my guess, but it does not seem to be working.

They're not even that far along yet.  :-)  They should begin appearing
there soon (announcements will be made to this list).

Pm
0
pmichaud
9/8/2004 3:01:19 PM
On Wed, 8 Sep 2004 07:33:45 -0600, Patrick R. Michaud
<pmichaud@pobox.com> wrote:
> We're in the beginning stages of building a basic perl 6 grammar engine
> (i.e., probably without p6 closures) that compiles to parrot and handles
> basic optimizations.  Concurrent with that I'm working on a Perl 6 gramma=
r.
The system described in Apocalypse 5, I take it? (Don't hurt me, I
just like to be certain...)

> I'm expecting a working basic grammar engine in a little over a month.
> We'll test it on a few simple languages, and then start using it to build
> the Perl 6 parser and code generator.
Cool. Any estimate for a working version?

And any way for an overeager newbie to help? :D
--=20
Schw=E4che zeigen hei=DFt verlieren;
h=E4rte hei=DFt regieren.
  - "Glas und Tr=E4nen", Megaherz
0
methanal
9/8/2004 3:18:27 PM
[Herbert == methanal@gmail.com on Wed, 8 Sep 2004 15:18:27 +0000]

  Herbert> And any way for an overeager newbie to help?

The classic answer is "write tests".  There's thousands of code
snippets that have been tossed out to the various perl6-* lists over
the last few years.  Many are bogus, but woven into most threads are
examples of "this should work" real Perl6 code.  Just by browsing
lists archives, in a few days, you could probably write a few dozen
placeholder tests.  You couldn't be very confident of them, given you
don't have a language implementation to test them with.  But they
would make great fodder for the team, and would either get morphed
into final tests in the distribution, or morphed into conversations
where the final syntax does get hashed out.  Few things will get the
syntax nailed down like throwing out erroneous test cases.

Think very simple tests.  Maybe 3 tests for each of the operators thus
far defined.  Tests to check that the unicode and plain ascii versions
of operators both give the same results.  Little object tests.  Etc.
If the first thing implemented is the grammar engine, Patrick/et al
will need test code to parse.

-- jared@wordzoo.com

"One cannot mark the point without marking the path."
0
jared
9/8/2004 4:19:51 PM
On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote:
: We're in the beginning stages of building a basic perl 6 grammar engine 
: (i.e., probably without p6 closures) that compiles to parrot and handles
: basic optimizations.

I wonder whether, in the absence of closures, we'll have to have some
similar way to embed syntax-tree building code (PIR?) as actions in
the grammar.  Perhaps most of the grammar can rely on the built-up
tree of $0 nodes, but we'll at least have to have an escape down into
the operator precedence parser.  (Though we could bootstrap with pure
(slow) recursive descent and then layer the operator precedence over
that later, I suppose.  We'd only have to rewrite a few <expr>-like
rules at that point.  But I'm just a little scared that operator
precedence will be one of those optimizations that's always the
project after this one...)

Larry
0
larry
9/8/2004 4:56:12 PM
On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
> On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote:
> : We're in the beginning stages of building a basic perl 6 grammar engine 
> : (i.e., probably without p6 closures) that compiles to parrot and handles
> : basic optimizations.
> 
> I wonder whether, in the absence of closures, we'll have to have some
> similar way to embed syntax-tree building code (PIR?) as actions in
> the grammar.  

We may indeed need this.  I think the easiest way would be to
build some sort of "special-purpose" assertions or rules that
fire off some PIR code.  

Or, perhaps we can just find a way to do a funky sort of replacement
whereby p6 source code gets replaced by its equivalent PIR code as
soon as the compiler think it has a rule matched.  Naaah, scratch that.

> Perhaps most of the grammar can rely on the built-up
> tree of $0 nodes, but we'll at least have to have an escape down into
> the operator precedence parser.  [...]    But I'm just a little 
> scared that operator precedence will be one of those optimizations 
> that's always the project after this one... [...]

No, I'm expecting that we'll go ahead and build something to deal with
operator precedence early on, at least for bootstrapping purposes.
This is part of the reason why I was eager to see the precedence tables
get nailed down a bit more.

Pm
0
pmichaud
9/8/2004 5:21:34 PM
On Wed, Sep 08, 2004 at 09:19:51AM -0700, Jared Rhine wrote:
> [Herbert == methanal@gmail.com on Wed, 8 Sep 2004 15:18:27 +0000]
> 
>   Herbert> And any way for an overeager newbie to help?
> 
> The classic answer is "write tests".  [...]   Just by browsing
> lists archives, in a few days, you could probably write a few dozen
> placeholder tests.  

Indeed, and I'd say that in the immediate future we'll be wanting
rules/grammar tests (to test the grammar engine) more than we'll 
need perl 6 code, although we'll certainly take that as well.

> You couldn't be very confident of them, given you
> don't have a language implementation to test them with.  

In the case of p6 rules, you can at least test them against Perl6::Rules
from CPAN.

> Think very simple tests.  Maybe 3 tests for each of the operators thus
> far defined.  

Exactly.

> If the first thing implemented is the grammar engine, Patrick/et al
> will need test code to parse.

I'm sure many people on this list know this already, but it's worth 
pointing out to newbies that the "grammar engine" doesn't directly 
parse Perl 6; the grammar engine will parse/compile the Perl 6 grammar 
(still being written using perl 6 rules), and the output of *that*
becomes the "Perl 6 compiler" (running in Parrot) which then
compiles Perl 6 source code into Parrot (or PIR or AST or whatever).

So, in addition to having Perl 6 code to test the compiler, we
also need a good set of Perl 6 rules to test the grammar engine.  :-)

Pm
0
pmichaud
9/8/2004 5:51:18 PM
At 11:21 AM -0600 9/8/04, Patrick R. Michaud wrote:
>On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
>>  On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote:
>>  : We're in the beginning stages of building a basic perl 6 grammar engine
>>  : (i.e., probably without p6 closures) that compiles to parrot and handles
>>  : basic optimizations.
>>
>>  I wonder whether, in the absence of closures, we'll have to have some
>>  similar way to embed syntax-tree building code (PIR?) as actions in
>>  the grammar. 
>
>We may indeed need this.

Or we could just get closures working...
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
0
dan
9/8/2004 5:56:29 PM
----- Original Message -----
From: Jared Rhine <jared@wordzoo.com>
Date: Wednesday, September 8, 2004 12:19 pm
Subject: Current state?

> [Herbert == methanal@gmail.com on Wed, 8 Sep 2004 15:18:27 +0000]
> 
>  Herbert> And any way for an overeager newbie to help?
> 
> The classic answer is "write tests".  There's thousands of code
> snippets that have been tossed out to the various perl6-* lists over
> the last few years.

If you want to write tests, I would say the best place to start is the A5 stuff, for two reasons:

a.) Grammar/Regex tests would be really useful in testing the Grammar engine.

b.) The A5 stuff is definitely the most stable part of the Perl6 design.  As far as I know, it hasn't really changed much at all over the past 2 years.  You could probably work directly off of A5 and S5 without having to worry if the reality is much different from the document.

- Joe

0
ryan
9/8/2004 6:18:38 PM
----- Original Message -----
From: Dan Sugalski <dan@sidhe.org>
Date: Wednesday, September 8, 2004 1:56 pm
Subject: Re: Current state?

> At 11:21 AM -0600 9/8/04, Patrick R. Michaud wrote:
> >On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
> >>  On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud 
> wrote:>>  : We're in the beginning stages of building a basic perl 
> 6 grammar engine
> >>  : (i.e., probably without p6 closures) that compiles to parrot 
> and handles
> >>  : basic optimizations.
> >>
> >>  I wonder whether, in the absence of closures, we'll have to 
> have some
> >>  similar way to embed syntax-tree building code (PIR?) as 
> actions in
> >>  the grammar. 
> >
> >We may indeed need this.
> 
> Or we could just get closures working...

To get closure assertions working, you need  
something that compiles the code in the
closure assertion, and so there is a bit of a 
bootstrapping problem. (:

Maybe some sort of compromise/hack solution would 
work, where closure assertions would be allowed but 
only contain simple assignments: 

  rule hack {
    (\d)(<[a-z]>)\2
    <{ $0 = $1 }>
  }

0
ryan
9/8/2004 6:35:21 PM
On Wed, Sep 08, 2004 at 02:18:38PM -0400, JOSEPH RYAN wrote:

: b.) The A5 stuff is definitely the most stable part of the Perl6
: design.  As far as I know, it hasn't really changed much at all over
: the past 2 years.  You could probably work directly off of A5 and
: S5 without having to worry if the reality is much different from
: the document.

The main change we've made since then is that $?foo variables are
scoped to the current rule, while $foo must be declared outside
the rule (presuming C<use strict>).

The other change we've made since then is that named rules aren't
remembered as named fields unless you put a ? inside, so that after
you've done

    /<?foo> <ws> <?bar>/

there are potentially $0�foo� and $0�bar� fields, but no $0�ws�.  That is,
the above is equivalent to

    /$?foo:=<foo> <ws> $?bar:=<bar>/

Larry
0
larry
9/8/2004 6:37:15 PM
On Wed, 08 Sep 2004 14:18:38 -0400, JOSEPH RYAN <ryan.311@osu.edu> wrote:
> If you want to write tests, I would say the best place to start is the A5=
 stuff, for two reasons:
>=20
> a.) Grammar/Regex tests would be really useful in testing the Grammar eng=
ine.
>=20
> b.) The A5 stuff is definitely the most stable part of the Perl6 design. =
 As far as I know, it hasn't really changed much at all over the past 2 yea=
rs.  You could probably work directly off of A5 and S5 without having to wo=
rry if the reality is much different from the document.

Certainly good points. And, as stated, that'll be the first part made
to run, as it's requisite for the Perl6 compiler proper. (Read: We
aren't getting Perl6 until it's working.) The operators, particularly,
would be a pest. The synopses are kept up to date, though, aren't
they?
--=20
Schw=E4che zeigen hei=DFt verlieren;
h=E4rte hei=DFt regieren.
  - "Glas und Tr=E4nen", Megaherz
0
methanal
9/8/2004 6:37:20 PM
----- Original Message -----
From: "Patrick R. Michaud" <pmichaud@pobox.com>
Date: Wednesday, September 8, 2004 1:21 pm
Subject: Re: Current state?

> On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
> > On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote:
> > : We're in the beginning stages of building a basic perl 6 
> grammar engine 
> > : (i.e., probably without p6 closures) that compiles to parrot 
> and handles
> > : basic optimizations.
> > 
> > I wonder whether, in the absence of closures, we'll have to have 
> some> similar way to embed syntax-tree building code (PIR?) as 
> actions in
> > the grammar.  
> 
> We may indeed need this.  I think the easiest way would be to
> build some sort of "special-purpose" assertions or rules that
> fire off some PIR code.  

That's probably the best solution for now.

> Or, perhaps we can just find a way to do a funky sort of replacement
> whereby p6 source code gets replaced by its equivalent PIR code as
> soon as the compiler think it has a rule matched.  Naaah, scratch 
> that.

We tried that as an optimization in the prototype 
Perl6 compiler.  It ended up being a really really 
really bad idea because the grammar backtracked like 
a madman.  It might be workable if we can infuse 
<commit>'s in every location possible...

- Joe

0
ryan
9/8/2004 6:47:24 PM
On Wed, Sep 08, 2004 at 02:35:21PM -0400, JOSEPH RYAN wrote:
> From: Dan Sugalski <dan@sidhe.org>
> > 
> > Or we could just get closures working...
> 
> To get closure assertions working, you need  
> something that compiles the code in the
> closure assertion, and so there is a bit of a 
> bootstrapping problem. (:
> 
> Maybe some sort of compromise/hack solution would 
> work, where closure assertions would be allowed but 
> only contain simple assignments: 

Indeed, after Dan's suggestion I was thinking that we
might proceed along the lines of "limited closures",
where we do some quick-and-dirty processing of
simple closure assertions until we do have a Perl 6
compiler lying around that can handle it for us.  :-)
But I'd like to first get to where we're parsing rules
and matching them in parrot before I dive fully into
handling closures.

Pm
0
pmichaud
9/8/2004 6:48:03 PM
On Wed, Sep 08, 2004 at 02:47:24PM -0400, JOSEPH RYAN wrote:
: We tried that as an optimization in the prototype 
: Perl6 compiler.  It ended up being a really really 
: really bad idea because the grammar backtracked like 
: a madman.  It might be workable if we can infuse 
: <commit>'s in every location possible...

I presume you mean the lower-level backtracking controls.  A <commit>
can only cause you to fail completely, and then only if you backtrack
over it.  (Or are you referring specifically to efficient error
recovery?)

Anyway, we'll try to write the grammar to minimize (and hopefully
eliminate) backtracking on any successful parse.  Might have to
generate some junctive parse states by hand until we can bring some
yacc-like analysis tools to bear on Perl grammars.  Backtracking may
turn out to be quite useful for trying to figure out what they *should*
have said so we can emit useful diagnostics, but we won't fall into
the PL/I trap of trying to "fix" their program on the fly for them.

So what we probably need is some <commit>-like thing that latches
to a bogus-compile state but continues to try to parse for a while.
Probably want a variant that also just throws away everything to the
end of the current statement if we can't figure anything useful out
by backtracking.  Even if the backtracking doesn't improve the primary
error message, it could usefully figure out that you were *trying*
to declare something of the name "foo", and maybe some of its traits,
so you don't get a mess of bogus cascaded errors based on the missing
declaration.

But let's crawl first.

Larry
0
larry
9/8/2004 7:09:23 PM
At 2:35 PM -0400 9/8/04, JOSEPH RYAN wrote:
>----- Original Message -----
>From: Dan Sugalski <dan@sidhe.org>
>Date: Wednesday, September 8, 2004 1:56 pm
>Subject: Re: Current state?
>
>>  At 11:21 AM -0600 9/8/04, Patrick R. Michaud wrote:
>>  >On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
>>  >>  On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud
>>  wrote:>>  : We're in the beginning stages of building a basic perl
>>  6 grammar engine
>>  >>  : (i.e., probably without p6 closures) that compiles to parrot
>>  and handles
>>  >>  : basic optimizations.
>>  >>
>>  >>  I wonder whether, in the absence of closures, we'll have to
>>  have some
>>  >>  similar way to embed syntax-tree building code (PIR?) as
>>  actions in
>>  >>  the grammar.
>>  >
>>  >We may indeed need this.
>>
>>  Or we could just get closures working...
>
>To get closure assertions working, you need 
>something that compiles the code in the
>closure assertion, and so there is a bit of a
>bootstrapping problem. (:

Ah, OK. I thought the problem was that parrot's closure stuff wasn't 
working right. (which I think it might not be :)
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
0
dan
9/8/2004 7:12:55 PM
[Patrick == pmichaud@pobox.com on Wed, 8 Sep 2004 11:51:18 -0600]

  Patrick> ...in the immediate future we'll be wanting rules/grammar
  Patrick> tests (to test the grammar engine) more than we'll need
  Patrick> perl 6 code, although we'll certainly take that as well.

If you wanted to describe the form such tests might take, maybe
Herbert will get excited enough to pitch in with such tests.  I grok
the difference between the grammar engine and the actual compiler, but
I'm blanking on how to describe the process of writing tests that
aren't simple "Perl 6 code snippet" style tests at this early stage.

-- jared@wordzoo.com

"We suffer primarily not from our vices or our weaknesses, but from our
 illusions.  We are haunted, not by reality, but by those images we have put
 in place of reality." - Daniel J. Boorstin
0
jared
9/8/2004 9:22:04 PM
----- Original Message -----
From: Larry Wall <larry@wall.org>
Date: Wednesday, September 8, 2004 3:09 pm
Subject: Re: Current state?

> On Wed, Sep 08, 2004 at 02:47:24PM -0400, JOSEPH RYAN wrote:
> : We tried that as an optimization in the prototype 
> : Perl6 compiler.  It ended up being a really really 
> : really bad idea because the grammar backtracked like 
> : a madman.  It might be workable if we can infuse 
> : <commit>'s in every location possible...
> 
> I presume you mean the lower-level backtracking controls.  A <commit>
> can only cause you to fail completely, and then only if you backtrack
> over it.  (Or are you referring specifically to efficient error
> recovery?)

Well, I meant in the sense of "Ok, since we're 
<commit>ing here, we should assume that everything 
we've already parsed is ok (i.e., we're not going to 
backtrack over it).  Its now ok to translate it into
PIR without wasting our time."  The idea was to 
reduce/eliminate the translation of code that might
get backtracked over.

- Joe

0
ryan
9/9/2004 1:06:48 AM
----- Original Message -----
From: Jared Rhine <jared@wordzoo.com>
Date: Wednesday, September 8, 2004 5:22 pm
Subject: Current state?

> [Patrick == pmichaud@pobox.com on Wed, 8 Sep 2004 11:51:18 -0600]
> 
>  Patrick> ...in the immediate future we'll be wanting rules/grammar
>  Patrick> tests (to test the grammar engine) more than we'll need
>  Patrick> perl 6 code, although we'll certainly take that as well.
> 
> If you wanted to describe the form such tests might take, maybe
> Herbert will get excited enough to pitch in with such tests.  I grok
> the difference between the grammar engine and the actual compiler, but
> I'm blanking on how to describe the process of writing tests that
> aren't simple "Perl 6 code snippet" style tests at this early stage.

Test::More with Parrot::Test would probably be good enough.  For an example, take a look at:

http://xrl.us/cy66

Except that in this case, it would just be something like:

    ##############################
    # to test $0
    output_is(<<'CODE', <<'OUT', "Description.");
    "a string on which to test the pattern" =~ /(pattern)/
    CODE
    pattern
    OUT

- Joe

0
ryan
9/9/2004 1:51:11 AM
Herbert Snorrason <methanal@gmail.com> writes:

> Since this list has been started, I'd assume that means work on the
> final Perl6 compiler is about to start. (Although, with this crowd,
> you never do know...)
>
> In the interest of a layman's curiosity: What's the current status?
>
> (And I already wonder if this won't make the summaries even more
> irregular. ;)

I hope not. I'm slowly getting back to a weekly schedule after the
summer. 
0
pdcawley
9/9/2004 7:39:18 PM
Jared Rhine <jared@wordzoo.com> writes:

> [Patrick == pmichaud@pobox.com on Wed, 8 Sep 2004 11:51:18 -0600]
>
>   Patrick> ...in the immediate future we'll be wanting rules/grammar
>   Patrick> tests (to test the grammar engine) more than we'll need
>   Patrick> perl 6 code, although we'll certainly take that as well.
>
> If you wanted to describe the form such tests might take, maybe
> Herbert will get excited enough to pitch in with such tests.  I grok
> the difference between the grammar engine and the actual compiler, but
> I'm blanking on how to describe the process of writing tests that
> aren't simple "Perl 6 code snippet" style tests at this early stage.

How about:

    /a pattern/

    "target_string" <matches?> "$1" "$2" "$3"...

    "another_target" <matches?> "$1" ... 
    
    /another pattern/

    ...

The game is to get a bunch of tests written. Given a sufficiently
regular layout Luke and Patrick can no doubt write some code that will
massage things into something that can get run under some test harness.
0
pdcawley
9/12/2004 8:41:40 PM
Patrick R. Michaud wrote:
> On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
> 
>>On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote:
>>: We're in the beginning stages of building a basic perl 6 grammar engine 
>>: (i.e., probably without p6 closures) that compiles to parrot and handles
>>: basic optimizations.
>>
>>I wonder whether, in the absence of closures, we'll have to have some
>>similar way to embed syntax-tree building code (PIR?) as actions in
>>the grammar.  
> 
> We may indeed need this.  I think the easiest way would be to
> build some sort of "special-purpose" assertions or rules that
> fire off some PIR code.  

Or, instead of thinking of this as a special-purpose thing, consider 
rules to be a sepperate language from perl, mostly independent of it, 
and the /default/ language for assertations/rules being perl, but allow 
a :<language> attribute to have them be in PIR instead.  (Or, 
presumably, anything else that we can pass off to parrot's compiler 
interface.)  That is, C< /(.) {:PIR print P0;}/ > contains an embedded 
closure that is PIR code.  C< /(.) {print $0;} > contains an closure 
that is perl6 code (which will fail, hopefully at compile-time, until we 
have a parrot-callable perl6 compiler), and C< /(.) {:forth P0 print}/ > 
contains an embedded forth closure.

This means that we don't have to throw all the PIR-using grammars out 
when we want to be able to use "real" grammars, because PIR-using 
grammars /are/ real grammars.  Ideally, we can even make a 
:embeddedlang('PIR') to set the default, to enable better re-use from 
other languages.

Now for the cons:
- The compilation interface doesn't have any way to be given a bunch of
   code that includes code in the target language in the beginning, that
   will consume that, then hand the rest back to us.
- This means that the grammar parser has to figure that out itself.
- ...until we extend the compilation interface.
- It means that we have a more complicated grammar engine (slightly).
- It means that we're changing the one bit of perl6 that we just said
   hadn't been changed much.

	-=- James Mastros
0
james
9/14/2004 2:03:49 PM
On Tue, Sep 14, 2004 at 04:03:49PM +0200, James Mastros wrote:
> 
> Or, instead of thinking of this as a special-purpose thing, consider 
> rules to be a sepperate language from perl, mostly independent of it, 
> and the /default/ language for assertations/rules being perl, but allow 
> a :<language> attribute to have them be in PIR instead.  

Excellent idea -- we may indeed do something along these lines.

Pm

0
pmichaud
9/14/2004 2:33:50 PM
On Tue, Sep 14, 2004 at 04:03:49PM +0200, James Mastros wrote:
> Or, instead of thinking of this as a special-purpose thing, consider 
> rules to be a sepperate language from perl, mostly independent of it, 
> and the /default/ language for assertations/rules being perl, but allow 
> a :<language> attribute to have them be in PIR instead.  (Or, 
> presumably, anything else that we can pass off to parrot's compiler 
> interface.)  That is, C< /(.) {:PIR print P0;}/ > contains an embedded 
> closure that is PIR code.  C< /(.) {print $0;} > contains an closure 
> that is perl6 code (which will fail, hopefully at compile-time, until we 
> have a parrot-callable perl6 compiler), and C< /(.) {:forth P0 print}/ > 
> contains an embedded forth closure.

I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and 
C< /(.) { use Forth; P0 print}/ >  :-) As long as we're special-casing
things and "hand parsing" we might as well use a small subset of Perl)

> Now for the cons:
> - The compilation interface doesn't have any way to be given a bunch of
>   code that includes code in the target language in the beginning, that
>   will consume that, then hand the rest back to us.
> - This means that the grammar parser has to figure that out itself.
> - ...until we extend the compilation interface.

I'm not sure I understand what you mean by "the compliation interface"
here.

> - It means that we have a more complicated grammar engine (slightly).

There's a certain amount of complexity we have to deal with anyway.
As long as we introduce the minimum amount necessary to acheive the
maximum functionality, we're good.

> - It means that we're changing the one bit of perl6 that we just said
>   hadn't been changed much.

It's writ in still-soft clay anyway :)

-Scott
-- 
Jonathan Scott Duff
duff@pobox.com
0
duff
9/14/2004 2:43:56 PM
I'd suggest looking at the t/op/re_tests file from Perl 5.  It's based
on the test suite that originally came with Henry Spencer's regular
expression package.  It would, of course, need to be translated and
extended, but it contains a lot of torturous tests for the standard
rx behavior.  And it's all just a table of tests and results, so no
Perl code at all.

Oh, and for your reference purposes an update of S5 is in the works.
More news on that later today.

Larry
0
larry
9/14/2004 3:43:08 PM
On Tue, Sep 14, 2004 at 08:43:08AM -0700, Larry Wall wrote:
> I'd suggest looking at the t/op/re_tests file from Perl 5.  It's based
> on the test suite that originally came with Henry Spencer's regular
> expression package.  It would, of course, need to be translated and
> extended, but it contains a lot of torturous tests for the standard
> rx behavior.  And it's all just a table of tests and results, so no
> Perl code at all.

And, in fact, eventually it'd be nice to have a Parrot-based test
harness for this, since the rules are going to be compiled into Parrot
subroutines (or objects) and executed from there.  Basically read 
patterns/test cases from the table, call the "p6ge" compiler on each pattern,
and run the test targets and output the results.  

Pm
0
pmichaud
9/14/2004 3:57:25 PM
At 4:03 PM +0200 9/14/04, James Mastros wrote:
>Now for the cons:
>- The compilation interface doesn't have any way to be given a bunch of
>   code that includes code in the target language in the beginning, that
>   will consume that, then hand the rest back to us.
>- This means that the grammar parser has to figure that out itself.
>- ...until we extend the compilation interface.
>- It means that we have a more complicated grammar engine (slightly).
>- It means that we're changing the one bit of perl6 that we just said
>   hadn't been changed much.

It would seem to me that the "right" thing to do is to use the 
language of the currently running sub, which could be queried easily 
enough if subs carried along with them the language that they are 
written in.

Which, since we don't do that now, would seem to be a sensible thing 
to add to all sub PMCs.
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
0
dan
9/14/2004 5:40:10 PM
Jonathan Scott Duff wrote:
> On Tue, Sep 14, 2004 at 04:03:49PM +0200, James Mastros wrote:
>>Or, instead of thinking of this as a special-purpose thing
> I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and 
> C< /(.) { use Forth; P0 print}/ >  :-) As long as we're special-casing
> things and "hand parsing" we might as well use a small subset of Perl)
You're still thinking in terms of this being a temporary hack.  We've 
found ourself in a position where perl6 grammars don't have all the 
functionality needed to write the metagrammar... in particular, they 
don't have the ability to specify embedded code in PIR, only in perl6.

Instead of looking to introduce a hack, look to figure out how we can 
fit this ability into the design of rules.  Instead of { ... } just 
containing perl6 code, we need a way to signal that it's not perl6 code. 
  I think the way to do that is by following the open curly with a 
colon, and the name of the language, which should match <identifier>. 
Everything that after that identifier is taken to be in the language 
named.  If there is no colon, the language is assumed to be 'perl6'. 
(Note that this implies the actual code always starts with a single 
space for non-perl6 code, and that you have to play games if the perl6 
code is supposed to begin with a colon -- but all there any valid and 
useful uses for such code?)

Of course, this is really language design -- Larry, you listening?

>>Now for the cons:
>>- The compilation interface doesn't have any way to be given a bunch of
>>  code that includes code in the target language in the beginning, that
>>  will consume that, then hand the rest back to us.
>>- This means that the grammar parser has to figure that out itself.
>>- ...until we extend the compilation interface.
> I'm not sure I understand what you mean by "the compliation interface"
> here.
The interface that is behind the C<compile> opcode of parrot.  See 
http://www.parrotcode.org/docs/ops/core.html, near the bottom, under 
"native call interface".

>>- It means that we have a more complicated grammar engine (slightly).
> There's a certain amount of complexity we have to deal with anyway.
> As long as we introduce the minimum amount necessary to acheive the
> maximum functionality, we're good.
I think that's the case here.

	-=- James Mastros
0
james
9/14/2004 6:13:13 PM
On Tue, Sep 14, 2004 at 08:13:13PM +0200, James Mastros wrote:
> Jonathan Scott Duff wrote:
> >On Tue, Sep 14, 2004 at 04:03:49PM +0200, James Mastros wrote:
> >>Or, instead of thinking of this as a special-purpose thing
> >I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and 
> >C< /(.) { use Forth; P0 print}/ >  :-) As long as we're special-casing
> >things and "hand parsing" we might as well use a small subset of Perl)
> You're still thinking in terms of this being a temporary hack.  

Actually I was thinking in terms of this being a permanent hack.

> We've 
> found ourself in a position where perl6 grammars don't have all the 
> functionality needed to write the metagrammar... in particular, they 
> don't have the ability to specify embedded code in PIR, only in perl6.
> 
> Instead of looking to introduce a hack, look to figure out how we can 
> fit this ability into the design of rules.  Instead of { ... } just 
> containing perl6 code, we need a way to signal that it's not perl6 code. 

Right. "use Python;" and "use PIR;" seem just as good as ":Python" or
":PIR" to me and have the added benefit of looking like something Perl
would do. (I'm not sure whether that's a benefit or not but it sounds
good for now :)

> >>Now for the cons:
> >>- The compilation interface doesn't have any way to be given a bunch of
> >> code that includes code in the target language in the beginning, that
> >> will consume that, then hand the rest back to us.
> >>- This means that the grammar parser has to figure that out itself.
> >>- ...until we extend the compilation interface.
> >I'm not sure I understand what you mean by "the compliation interface"
> >here.
> The interface that is behind the C<compile> opcode of parrot.  See 
> http://www.parrotcode.org/docs/ops/core.html, near the bottom, under 
> "native call interface".

Ah.  Hrm. Surely the grammar engine needs to know where the "closure"
ends.  Can't it just send the bit that needs compilation and basically
do a substitution? 

-Scott
-- 
Jonathan Scott Duff
duff@pobox.com
0
duff
9/14/2004 7:25:47 PM
On Tue, Sep 14, 2004 at 08:13:13PM +0200, James Mastros wrote:
: Of course, this is really language design -- Larry, you listening?

Sure, I'm listening, but what's the point when I agree with everyone.  :-)

I agree that the default should be the current outer language.

I agree that the default ought to be overridable.

I agree that the right way to do that is with something like "use PIR;"
rather than inventing an inconsistent syntax.

On the other hand, I don't think any such declaration belongs in the
closures themselves.  Can you imagine how many "use Mumbles" you're
talking about?  I think the file as a whole should have some way of
declaring what the language of its closures should be.  In Perl terms,
it's a file-scoped pragma.  If your regexen are embedded in some
other kind of file, it needs something like a pragma to declare that.
But in Perl 6, it'll probably be

    use rx :deflang�PIR�

or some such.

Larry
0
larry
9/14/2004 7:42:59 PM
On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote:
> : Of course, this is really language design -- Larry, you listening?
> 
> Sure, I'm listening, but what's the point when I agree with everyone.  :-)
> 
> I agree that the default should be the current outer language.
> I agree that the default ought to be overridable.
> I agree that the right way to do that is with something like "use PIR;"
> rather than inventing an inconsistent syntax.

This will likely betray some deep ignorance on my part (and this
discussion may have taken place already elsewhere), but since I'm 
currently working on a rules syntax parser I'll barrel forth anyway:  

What should the mechanism be for the rule parser to figure out where 
a closure begins and ends within a rule expression?  Does the rules
parser have to call the outer language compiler directly?  

If so, does this imply that the rules parser has to be running in 
Parrot to be able to call the outer language compiler, or is there a 
way to do this from C?

And does the outer language compiler have to have options that
allow the caller to say: "hey, here's some program code with perhaps 
a bunch of rule-syntax stuff appended to it, could you just give me 
back the first complete 'closure unit' and oh, by the way, tell me how 
many characters you used to do it or give me the left-over string so
I can continue parsing my stuff?"

Or is there some syntactic shortcut that can be made to let us find
the end of a closure without having to fully parse the closure itself?

How does p5 do it?

(And you can see why I've been willing to postpone true closures in 
rules just a bit longer until we got a p6 compiler started. :-)

Pm
0
pmichaud
9/14/2004 7:56:43 PM
At 8:13 PM +0200 9/14/04, James Mastros wrote:
>Instead of looking to introduce a hack, look to figure out how we 
>can fit this ability into the design of rules.  Instead of { ... } 
>just containing perl6 code, we need a way to signal that it's not 
>perl6 code.

How about... it brackets code in the current language? (I'm sure 
Larry can do something with the colon to indicate otherwise, when it 
doesn't) That should work fine to bracket every language except those 
that don't use paired {} characters, or have really funky string 
escape rules so the end of the code is mis-identified. But, then, 
those languages will probably find a way to use the convenient 
"function to set the characters which indicate the start and end of 
embedded code" function which will, no doubt, be provided...
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
0
dan
9/14/2004 8:23:08 PM
----- Original Message -----
From: "Patrick R. Michaud" <pmichaud@pobox.com>
Date: Tuesday, September 14, 2004 3:56 pm
Subject: Re: Current state?

> On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote:
> > : Of course, this is really language design -- Larry, you listening?
> > 
> > Sure, I'm listening, but what's the point when I agree with 
> everyone.  :-)
> > 
> > I agree that the default should be the current outer language.
> > I agree that the default ought to be overridable.
> > I agree that the right way to do that is with something like 
> "use PIR;"
> > rather than inventing an inconsistent syntax.
> 
> This will likely betray some deep ignorance on my part (and this
> discussion may have taken place already elsewhere), but since I'm 
> currently working on a rules syntax parser I'll barrel forth 
> anyway:  
> 
> What should the mechanism be for the rule parser to figure out 
> where 
> a closure begins and ends within a rule expression?  Does the rules
> parser have to call the outer language compiler directly?  

Since a closure can contain arbitrary Perl6 code, yeah.  But I was under the impression that parsing the rules themselves needed to be done by the outer language parser just because of that jazz.  Maybe the outer language parser could parse the rule first, and then replace language-specific constructs with stubs or the body of a PIR sub:

    rule rules {
        $rules := (rules) { for 1..5 { print "$rules totally rule.\n" } }
    }
    
And, after the outer language Perl6 compiler gets done with it, the Rules Engine would see:
    
    rule rules {
        (rules) {
            .param MatchObject match
            
            set $I1, 1
            new $P0, .PerlString
            set $P0, " totally rule."
            L_1:
            
            new $P1, .PerlString
            clone $P1, match["1"]
            concat $P1, $P0
            print $P1
            inc $I1
            le $I1, 5, L_I
        }
    }

And then it would be easy to find the end of the closure construct since it will contain plain ol' PIR.

> If so, does this imply that the rules parser has to be running in 
> Parrot to be able to call the outer language compiler, or is there 
> a 
> way to do this from C?
> 
> And does the outer language compiler have to have options that
> allow the caller to say: "hey, here's some program code with 
> perhaps 
> a bunch of rule-syntax stuff appended to it, could you just give 
> me 
> back the first complete 'closure unit' and oh, by the way, tell me 
> how 
> many characters you used to do it or give me the left-over string so
> I can continue parsing my stuff?"

Well, you could always design the compiler so that it can be put into a special mode that:

- recieves the raw text as an argument
- tries to parse a whole block from that (e.g., starts at rule "block" instead of rule "prog")
- if successful, compiles that block into a closure PMC and modifies the raw text by deleting the parsed text from the start of it.  (kinda like Parse::RecDescent::Consumer)
- returns the closure PMC and the modified text

> Or is there some syntactic shortcut that can be made to let us find
> the end of a closure without having to fully parse the closure itself?
> 
> How does p5 do it?

p5 just tries to find a balanced set of curlies.

> (And you can see why I've been willing to postpone true closures 
> in 
> rules just a bit longer until we got a p6 compiler started. :-)

Oh, definitely, definitely. :)

- Joe

0
ryan
9/14/2004 9:27:44 PM
"Patrick R. Michaud" <pmichaud@pobox.com> wrote:
:How does p5 do it?

Brokenly. It looks for balanced curlies unintelligently; try:
  perl -we '/(?{ "})" })/'

I'd expect p6 rules to be parsed using a grammar, and within such
a context to invoke the 'closure' rule; it's that rule that'd have
the responsibility of knowing where to start and stop, and what
language it's supposed to be reading. I'd expect it to discover
the language initially from independent contextual information
(ie C< use rx deflang('PIR') >), but be able to switch based on
the string being parsed (ie C< m/{use grammar 'PIR'; ...}/ >).

It does get tricky if the language you're parsing does (or can) use
'}' in an unbalanced manner, the equivalent of a perl5/6 TERM
starting with a '}' that didn't close a previous '{' - I don't know
how you'd decide in that case which '}' terminates the closure, but
that's a problem for the grammar implementing 'closure' in that
language, not for the 'rule' parser per se. I think that simply
means that not every language can embed every language in this way.

Hugo
0
hv
9/14/2004 9:53:03 PM
On Tue, 14 Sep 2004 08:43:08 -0700, Larry Wall <larry@wall.org> wrote:
> I'd suggest looking at the t/op/re_tests file from Perl 5.  It's based
> on the test suite that originally came with Henry Spencer's regular
> expression package.  It would, of course, need to be translated and
> extended, but it contains a lot of torturous tests for the standard
> rx behavior.  And it's all just a table of tests and results, so no
> Perl code at all.
So ... I suppose I'll start by (trying and) translating that into Perl
6 rules, and then ask for further guidance. :>

--=20
Schw=E4che zeigen hei=DFt verlieren;
h=E4rte hei=DFt regieren.
  - "Glas und Tr=E4nen", Megaherz
0
methanal
9/15/2004 12:37:52 PM
Patrick R. Michaud wrote:
> On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote:
>>I agree that the default should be the current outer language.
>>I agree that the default ought to be overridable.
>>I agree that the right way to do that is with something like "use PIR;"
>>rather than inventing an inconsistent syntax.
/me starts to make an observation that making it look like perl6 when 
it's not is paramount to lying to our users, but decides to invoke rule 
1 in his mind.

I'm assuming s/outer language/inner language/g in the following, as it 
makes no sense otherwise...
> What should the mechanism be for the rule parser to figure out where 
> a closure begins and ends within a rule expression?  Does the rules
> parser have to call the outer language compiler directly?  

> If so, does this imply that the rules parser has to be running in 
> Parrot to be able to call the outer language compiler, or is there a 
> way to do this from C?
It has to either be within Parrot or embed Parrot, as most of the 
language compilers are written in PIR.

> And does the outer language compiler have to have options that
> allow the caller to say: "hey, here's some program code with perhaps 
> a bunch of rule-syntax stuff appended to it, could you just give me 
> back the first complete 'closure unit' and oh, by the way, tell me how 
> many characters you used to do it or give me the left-over string so
> I can continue parsing my stuff?"
Not presently, but there should be.  (And there should be an extra, 
optional, argument to the compile opcode to pass in options like this.)

(The interface should probably be to consume the used portion of the S 
register passed in.)

> Or is there some syntactic shortcut that can be made to let us find
> the end of a closure without having to fully parse the closure itself?
Well, we could do that for the time being, in which case, I suggest the 
end condition be a m:5/^}\s*/ line.

> How does p5 do it?
To quote perlre, "Currently, the rules to determine where the "code" 
ends are somewhat convoluted."  (Search for "(?{ code })".)

> (And you can see why I've been willing to postpone true closures in 
> rules just a bit longer until we got a p6 compiler started. :-)
Aye, I can, but if you work with p6i to get compilers to take a hint 
that says that they're parsing embedded code, and tell us when they're 
finished, and get the PIR compiler to pay attention to such a hint, then 
you can lob the hard bits off to the inner language compilers... and get 
correct semantics out of it, instead of the mostly-correct semantics 
that perl5 has.

	-=- James Matros
0
james
9/17/2004 9:44:09 AM
On Fri, Sep 17, 2004 at 11:44:09AM +0200, James Mastros wrote:
> 
> >Or is there some syntactic shortcut that can be made to let us find
> >the end of a closure without having to fully parse the closure itself?
> Well, we could do that for the time being, in which case, I suggest the 
> end condition be a m:5/^}\s*/ line.

I'm going to go with a syntactic shortcut for the time being, albeit
something more complex than the suggestion above.  I don't want to force
people to make multi-line closures.  It will probably look for matching
braces, skipping over quoted strings and anything with a backslash in
front of it.  Yes, I know it's possible to construct cases where this
won't do the right thing -- I'm just trying to get something usable for
now.

In the long run I'm thinking we may just leave the syntactic shortcut 
in place, for those compilers that don't (or can't?) provide all of the 
"parse one closure, tell me how many characters you used" semantics 
we'd need.  Maybe we'll have a rule option that says "don't use the 
closure syntax shortcut, call the compiler directly", or have the rule 
automatically decide what to do based on the properties of the 
(inner) compiler.

Pm
0
pmichaud
9/17/2004 2:19:37 PM
On Fri, Sep 17, 2004 at 11:44:09AM +0200, James Mastros wrote:
> Patrick R. Michaud wrote:
> >On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote:
> >>I agree that the default should be the current outer language.
> >>I agree that the default ought to be overridable.
> >>I agree that the right way to do that is with something like "use PIR;"
> >>rather than inventing an inconsistent syntax.
> /me starts to make an observation that making it look like perl6 when 
> it's not is paramount to lying to our users, but decides to invoke rule 
> 1 in his mind.

Er, that's not what Larry said.   The "outer" language is Perl and
*it* specifies what to expect in the "inner" language. Thus, in the
Perl code there will be "use rx :deflang<<PIR>>" or "use PIR" or some
such, not in the closure.

> I'm assuming s/outer language/inner language/g in the following, as it 
> makes no sense otherwise...
> >What should the mechanism be for the rule parser to figure out where 
> >a closure begins and ends within a rule expression?  Does the rules
> >parser have to call the outer language compiler directly?  
> 
> >If so, does this imply that the rules parser has to be running in 
> >Parrot to be able to call the outer language compiler, or is there a 
> >way to do this from C?
> It has to either be within Parrot or embed Parrot, as most of the 
> language compilers are written in PIR.

I don't know that this is necessarily true. The inner language just
has to generate a "closure" in some manner that the rules parser can
deal with.  Unless that's what you mean by "embed Parrot".

> >And does the outer language compiler have to have options that
> >allow the caller to say: "hey, here's some program code with perhaps 
> >a bunch of rule-syntax stuff appended to it, could you just give me 
> >back the first complete 'closure unit' and oh, by the way, tell me how 
> >many characters you used to do it or give me the left-over string so
> >I can continue parsing my stuff?"
> Not presently, but there should be.  (And there should be an extra, 
> optional, argument to the compile opcode to pass in options like this.)
> 
> (The interface should probably be to consume the used portion of the S 
> register passed in.)

It's a good thing Larry gave us <cut> then ;-)

-Scott
-- 
Jonathan Scott Duff
duff@pobox.com
0
duff
9/17/2004 3:07:00 PM
Jonathan Scott Duff wrote:
> I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and 
> C< /(.) { use Forth; P0 print}/ >  :-) As long as we're special-casing
> things and "hand parsing" we might as well use a small subset of Perl)

Is perl actually going to allow arbitrary languages in the closures for 
REs?  For languages that don't have a clean notion of closures or a 
friend idea of how to use curly brases, this sounds like quite a feature 
to implement even with a full perl6 compiler to start with.

Why not say the closures in perl's RE are always in perl (ignoring 
macros) and that you have to have eval functions/macros for the other 
languages like :

	rx{ <<foo>> { PIR :P0($<<foo>>) { print P0 } }
	rx{  <foo>  { PIR<< print P0 >>} }
	rx{  <foo>  { PIR <<EOPIR
		    print P0
		    EOPIR
		  }
	}

I guess saying PIR in every rule might get repetitive.  It would be easy 
to special case in the bootstrap parser and would work in a way that 
would seem to make regular perl REs easier to manage.

Dan

0
eddward
9/18/2004 5:29:52 AM
On Sat, Sep 18, 2004 at 12:29:52AM -0500, Dan Hursh wrote:
> Jonathan Scott Duff wrote:
> >I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and 
> >C< /(.) { use Forth; P0 print}/ >  :-) As long as we're special-casing
> >things and "hand parsing" we might as well use a small subset of Perl)
> 
> Is perl actually going to allow arbitrary languages in the closures for 
> REs?  For languages that don't have a clean notion of closures or a 
> friend idea of how to use curly brases, this sounds like quite a feature 
> to implement even with a full perl6 compiler to start with.

I'm by no means an expert, but I'd say that the inner languages don't
need to have any idea of closure or of curly braces; those are Perl's
responsibility. Perl will package up the stuff between the curlies and
ship it off to another compiler. All that compiler needs to do is return
something that Perl can wrap up in a closure of its own (or, of course,
it could return an actual closure) Yes, there is always the possibiilty
Perl can't tell where the closing curly is, especially if the inner
language doesn't play well, but it can make a good guess and provide
mechanisms for the programmer to give hints.

You can s/Perl/the rules parser/ above for bootstrapping I think.

> Why not say the closures in perl's RE are always in perl (ignoring 
> macros) and that you have to have eval functions/macros for the other 
> languages like :
> 
> 	rx{ <<foo>> { PIR :P0($<<foo>>) { print P0 } }
> 	rx{  <foo>  { PIR<< print P0 >>} }
> 	rx{  <foo>  { PIR <<EOPIR
> 		    print P0
> 		    EOPIR
> 		  }
> 	}
> 
> I guess saying PIR in every rule might get repetitive.  It would be easy 
> to special case in the bootstrap parser and would work in a way that 
> would seem to make regular perl REs easier to manage.

That's kind of where I started with the { use PIR; ... } stuff up above.
You need some sort of quoting mechanism to delineate the other language
and you need some way to tell perl what the other language is, so why
not just use perl (or a small subset for bootstrapping) as the inner
language since it already has these things.

But the problems are the same no matter the syntax :)

-Scott
-- 
Jonathan Scott Duff
duff@pobox.com
0
duff
9/18/2004 4:36:32 PM
At 11:36 AM -0500 9/18/04, Jonathan Scott Duff wrote:
>I'm by no means an expert, but I'd say that the inner languages don't
>need to have any idea of closure or of curly braces; those are Perl's
>responsibility.

Rather it's the rules parser's responsibility. Don't forget, more 
languages than just perl 6 are going to be using the new rules parser.
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
0
dan
9/18/2004 7:41:37 PM
On Sat, Sep 18, 2004 at 03:41:37PM -0400, Dan Sugalski wrote:
> At 11:36 AM -0500 9/18/04, Jonathan Scott Duff wrote:
> >I'm by no means an expert, but I'd say that the inner languages don't
> >need to have any idea of closure or of curly braces; those are Perl's
> >responsibility.
> 
> Rather it's the rules parser's responsibility. Don't forget, more 
> languages than just perl 6 are going to be using the new rules parser.

Sure, that's why I said you could s/Perl/the rules parser/ later in that
message. But I've also been thinking of the rules parser as Perl's core;
it's kind of like a universal bootstrapper that can get you to Perl (or
any language of your choosing, but mostly Perl :-).

-Scott
-- 
Jonathan Scott Duff
duff@pobox.com
0
duff
9/18/2004 8:32:41 PM
At 3:32 PM -0500 9/18/04, Jonathan Scott Duff wrote:
>On Sat, Sep 18, 2004 at 03:41:37PM -0400, Dan Sugalski wrote:
>>  At 11:36 AM -0500 9/18/04, Jonathan Scott Duff wrote:
>>  >I'm by no means an expert, but I'd say that the inner languages don't
>>  >need to have any idea of closure or of curly braces; those are Perl's
>>  >responsibility.
>>
>>  Rather it's the rules parser's responsibility. Don't forget, more
>>  languages than just perl 6 are going to be using the new rules parser.
>
>Sure, that's why I said you could s/Perl/the rules parser/ later in that
>message. But I've also been thinking of the rules parser as Perl's core;
>it's kind of like a universal bootstrapper that can get you to Perl (or
>any language of your choosing, but mostly Perl :-).

I think that'll ultimately not be what happens. Regardless of any 
initial intention, the rules engine will get used by everyone, unless 
it's difficult, in which case Parrot will end up with two embedded 
rules engines -- the perl 6 one, and PCRE2 for everyone else 
(including Perl 5, I'd bet, which'd be mildly embarrassing). I'd 
really, *really* like to avoid that. And I think we can, with a 
little bit of thought about it beforehand.
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
0
dan
9/18/2004 8:48:53 PM
Reply:

Similar Artilces:

[perl6/specs] 008ddd: [S32::Exception] update to current state of the ar...
----==_mimepart_4f3285bb3412a_53153fbf5d95f2fc1116a Date: Wed, 08 Feb 2012 06:24:59 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <4f3285bb351e1_53153fbf5d95f2fc11174f@sh1.rs.github.com.mail> Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 008dddba5999d7c7ad03ed629fb6a356c9dcab06 https://github.com/perl6/specs/commit/008dddba5999d7c7ad03ed629fb6a356c9dcab06 Author: Moritz Lenz <moritz@faui2k3.org> Date: 2012-02-08 (Wed, 08 Feb 2012) Changed paths: M S32-...

perl6 compiler
Hello, I had just began looking at the perl6 raduko compiler and have a question. Is perl6 actually compiled then ran similar to java or is the script ran and then compiled at run time? -Wendell On Mar 14, 2010, at 11:09 AM, dell wrote: > Is perl6 actually compiled then ran similar to java > or is the script ran and then compiled at run time? It supports either, but defaults to single-step compile-run (like Perl 5). I think that a transparent cache is envisioned for the future, so that a compiled version is silently saved during the first compil...

Current state
I've applied Jarkko's `fix' for POSIX machines not being POSIX after all on signals, and I have extended Steve Hay's patch 25209: Change 25210 on 2005/07/21 by merijn@merijn-lt09 'I *DO* have AIX, and extending ' Change 25209 on 2005/07/21 by steveh@steveh-TANGAROA 'Make makedef.pl read "miniperl ' Change 25208 on 2005/07/21 by steveh@steveh-TANGAROA 'Make the canned config.h files ' Change 25207 on 2005/07/21 by merijn@merijn-lt09 'Subject: [PATCH] Re: [PATCH] su' Change 25206 on 2005/07/21 by steveh@steveh-TANGAROA 'Rearrange w...

perl6-compiler
perl6-compiler is missing at http://dev.perl.org/perl6/lists/ and it seems not to be gatewayed to nntp.perl.org. OTOH a lot of unused perl6 lists and newsgroups are there. Finally I tried to subscribe already twice and got no answer. Thanks, leo http://www.nntp.perl.org/group/perl.perl6.compiler -- It's there. Correct, though, that it's not listed on the lists page... On Thu, 21 Oct 2004 09:02:23 +0200, Leopold Toetsch <lt@toetsch.at> wrote: > perl6-compiler is missing at http://dev.perl.org/perl6/lists/ and it > seems not to be gatewayed to nntp.perl...

to compile or not to compile ?
Hi I've been dabbling with  .net but am now trying to bite the bullet and learn it moving from classic asp I am a bit confused as to wether it is 'standard' practise to 'build' your project into dll's and upload these to the server or wether to simply use script and upload as you would classic asp to the server. what is 'standard' practise is there an advantage or disadvantage to using script / compiling thanks What is "Standard" depends a bit upon the tool you are using. For VS.NET 2003, compiling into a dll placed in the bin folder is the default behavior.  Othe...

cannot install perl6 compiler
ok I'm trying to install rakudo-star-2010.07 which I got from git hub http://github.com/downloads/rakudo/star/rakudo-star-2010.07.tar.gz and I get this error when I try to run perl Configure.pl --gen-parrot Reading configuration information from install/bin/parrot_config ... ===SORRY!=== Parrot revision r48225 required (currently r0) To automatically build the version of Parrot that came with this distribution (), try re-running Configure.pl with the '--gen-parrot' option. Or, use the '--parrot-config' option to explicitly specify the location of pa...

Current State of Jaguar
I read the Jaguar CTS white paper by Anne Thomas on the Powersoft / Jaguar CTS web page. It made a lot of references to features available in the "next" release, such as IIOP protocol support between client and server, single server limitations, etc. Is version 1.1 the "next release". If not, when will the "next" release be released....so to speak! Thanks Daymond Smart dsmart@vyvx.com ...

Current state of ithreads
Can I check what is the current state of ithreads as we approach 5.7.3? I ask because I was thinking of working on 'trylock' but I'm having trouble getting ithreads to work at all on my Linux 2.4.2 box (seg faults, undefined unlock_enabled, unbalanced scopes/saves/contexts etc). I can provide some examples if that will help. I know Nick Ing-Simmons was doing work on ithreads. If this is still work in progress with known problems, then apologies and I'll stay out of the way. Andy ===== Andy Bussey andybussey@yahoo.com ___________________________________...

[svn:parrot-pdd] r32941
Author: coke Date: Thu Nov 20 08:20:24 2008 New Revision: 32941 Modified: trunk/docs/pdds/pdd19_pir.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/compilers/imcc/imcc.l trunk/compilers/imcc/imcc.y trunk/compilers/imcc/imclexer.c trunk/compilers/imcc/imcparser.c trunk/compilers/imcc/pbc.c trunk/compilers/imcc/unit.h trunk/compilers/pct/src/POST/Compiler.pir trunk/compilers/pct/src/POST/Node.pir trunk/editor/pir-mode.el trunk/editor/pir_vim.in trunk/include/parrot/sub.h trunk/languages/perl6/...

Unable to read current state
I posted a week or so ago asking for a way to get an AD dn into an eDir attribute and the good Father gave me a command to use - (token-xpath("query:readObject($destQueryProcessor,$UserAsn,",'User',")/@src-dn")). However I'm having trouble getting it to work and I'm assuming it's the way I'm implementing it. It is in the output transform of the sub channel. The transaction bombs out with the error below, the association looks to be correct. Thanks Rule selected. [24/06/2008 14:42:41.64] Drvrs : NOS-AD-DIIRD ST: Applying rule &...

What is the current state of Persistent Treeviews?
I need to implement a treeview to display a large amount of hierarchical data.  The tree will have 4 levels, with the top 3 being branches and the bottom level being a leaf.  When the user clicks on a leaf then the disconnected dataset will be queried and the associated data returned will be used to populate a bunch of other controls on the page.  The user will then be free to edit this data at will.  The user will also be free to add and delete leafs.To accomplish this, my first inclination was to use the Microsoft Treeview control sitting inside of an Ajax UpdatePanel.&...

Querying the current state of the mouse
Hi, Is there any way to simply ask Firefox what the current state of the mouse is? (ie. where it's pointing and what buttons are pressed.) (Also, is there a better place for me to ask this question?) Thanks, Ok I just saw the message saying this group is moving, but I don't seem to be able to post messages at mozilla.general yet. Maybe one of you would be kind enough to answer my question here despite the fact that this newsgroup is "abandoned". :-) Thanks. On 21.01.2006 08:45, p.r.doyle@gmail.com wrote: --- Original Message --- > Ok I jus...

Spinrite Crash
Months ago, just after the latest version of SpinRite (6) came out, I purchased a copy for precautionary maintenance on my personal home computers. I made a CD and ran it on my Toshiba A20 laptop and SR ran a while, then crashed with an error. I tried a few things, but the same thing happened over and over, so I contacted GRC. I was told the problem was with the free DOS that is used to run SR and that I should make a bootable DOS disk with another DOS. This did not turn out to be an easy thing to do, (I should mention that the drive is NTFS) and after a few days of fooling arou...

Some thoughts on the current state of SQRL
Hi all, I've been away from the groups for a while as life has been hectic and still is but I thought I would catch up with the current state of SQRL. I've read through all the pages on SQRL that Steve has put together on grc.com and also the last couple of weeks of posts in this group. That still leaves 4000+ post here that I haven't read so forgive me if I touch on ground that has already been covered. Here are my thoughts: Firstly everything seems to have evolved quite nicely. The crypto, protocol and semantics all look pretty good. So to some details.....

Web resources about - Current state? - perl.perl6.compiler

Heliospheric current sheet - Wikipedia, the free encyclopedia
A /m². The thickness of the current sheet is about 10,000 km. The underlying magnetic field is called the interplanetary magnetic field , and ...

Killer Deals: Free Apple SuperDrive and 25-100% off AppleCare on all current 13" & 15" MacBooks
Lowest Prices Anywhere: For the next 6 days, grab a Free AppleSuper Drive plus 25% to 100% off AppleCare extended protection plans on all of ...

"In the current flap over some things that Dr. Carson said, the biggest discrepancy has been between ...
Writes Thomas Sowell , noting that "the Pyramids are not an issue in today’s American political campaign." Well, yeah, but the soundness of the ...

Muslim Americans: Current political climate worse than after 9/11
CNN Muslim Americans: Current political climate worse than after 9/11 CNN (CNN) It was never this bad, not even after 9/11. That's what many ...

Paul Ryan comes up empty when pressed on what's wrong with our current refugee screening process
That wonky wonk House Speaker Paul Ryan really needs to bone up on our refugee screening program , because he really doesn't get it. Steve Benen: ...

‘Mockingjay Part 2’ Racks Up $16M In Thursday Night Previews; Current Global B.O. At $43M
... 1 which made $17M. Among the franchise’s Thursday pre-openings, Catching Fire is the best with $25.25M from shows starting at 8PM. Current global ...

AD/CVD ruling and overseas capacity expansions are variables to the current PV boom, says EnergyTrend ...
China's National Reform and Development Commission has announced that there will be no significant reduction in feed-in tariff (FiT) rates for ...

Former Apple designers slag company’s current mobile UI, obsession with simplicity
A team of former Apple employees have taken aim at how the giant does UI design or rather, how it doesn't do UI design these days.

3 Stocks That Should Do Well In The Current Global Economic Environment
Rudolph-Riad Younes: We are at the juncture in the financial markets globally where the Fed is intent on raising interest rates. While in Europe ...

Gwen Stefani & Blake Shelton Reveal New Details That Give Light To Current Status Of Their Romance
It’s only been weeks since Blake Shelton and Gwen Stefani revealed to the world that they are officially dating. As is the case with any new ...

Resources last updated: 11/24/2015 9:18:23 AM