On Thu, May 13, 2004 at 09:41:54PM +0100, Dave Mitchell wrote:
: On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote:
: > No, you still have the four basic actions. Subparsing is all hidden in
: > the lexer.
:
: Hence why the lexer in Perl 5 is 8000 lines long ;-)
Well, actually, the lexe
On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote:
> No, you still have the four basic actions. Subparsing is all hidden in
> the lexer.
Hence why the lexer in Perl 5 is 8000 lines long ;-)
--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has
On Thu, May 13, 2004 at 03:27:43PM -0400, Dan Sugalski wrote:
: I think the prudent thing to do there, since we're going to very
: rarely be adding new operators, is to assign the darned things real
: precedence numbers which get dynamically set. Add a new operator
: between two others and every
At 12:22 PM -0700 5/13/04, Larry Wall wrote:
I'd take the latter approach myself, since in any event it will
probably need tweaks that are foreign to whatever tool you choose.
In particular, the fact that Perl 6 uses string comparison rather than
numeric comparison to do precedence levels is going
On Thu, May 13, 2004 at 01:01:12PM -0500, Abhijit A. Mahabal wrote:
: I have been thinking the following about what larry said earlier. Is this
: what you meant, larry?
:
: $grammar = q{
: class_defn: "class" block .. etc (normal top-down stuff)
: ...
: term: { call Parse::Yapp o
On Thu, 13 May 2004, Dan Sugalski wrote:
>
> The big problem is that I don't know *how* to implement a mixed-type
> parser generator. I'm not big on parsers in general, so I'm mostly
> stuck with the literature if I need to write one from scratch.
I have been thinking the following about what lar
Dan Sugalski writes:
> And personally I'd be happy to do violence to the dragon book. (Not
> that it's *entirely* horrible, as I occasionally need to prop doors
> open or shim a broken table leg temporarily...)
>
> But, anyway, snipping out the rest of this stuff...
>
> The big problem is that
At 9:35 AM -0700 5/13/04, Larry Wall wrote:
On Thu, May 13, 2004 at 10:26:32AM -0500, Abhijit A. Mahabal wrote:
:
: On Wed, 12 May 2004, Larry Wall wrote:
:
: > In fact, I'd go so far as to say that it's almost impossible to do
: > recursive descent when you allow for defining new operator preceden
On Thu, May 13, 2004 at 10:26:32AM -0500, Abhijit A. Mahabal wrote:
:
: On Wed, 12 May 2004, Larry Wall wrote:
:
: > In fact, I'd go so far as to say that it's almost impossible to do
: > recursive descent when you allow for defining new operator precedence
: > levels on the fly as Perl 6 does.
:
On Wed, 12 May 2004, Larry Wall wrote:
> In fact, I'd go so far as to say that it's almost impossible to do
> recursive descent when you allow for defining new operator precedence
> levels on the fly as Perl 6 does.
>
> : Operator precedence can be done in
> : a recdescent grammar straightforward
On Tue, May 11, 2004 at 10:48:22AM -0400, Dan Sugalski wrote:
: >Certainly some things won't be recursive-descent anyway (operator
: >precedence).
:
: Oh, don't be too sure of that. :)
Oh, I think Allison can be quite sure of that. :-)
In fact, I'd go so far as to say that it's almost impossibl
Steve Fink wrote:
>
> I suspect a slight variant of the above may work best. Rather than
> doing a full-out LALR(1) parser for the bottom-up components, you'd do
> a somewhat more naive but still table-driven (shift/reduce) parser,
> carefully limiting what it is assuming about the FIRST() etc. of
Top-down and bottom-up are not mutually exclusive. At least not
completely. But self-modifying parsers are *much* easier to do with
top-down than bottom-up, because the whole point of bottom-up is that
you can analyze the grammar at "compile" (parser generation) time, and
propagate the knowledge th
On May-10, Joseph Ryan wrote:
>
> The Parse::RecDescent in parrot/lib is a hacked version that removes
> a bunch of stuff (tracing code, iirc) from the outputted grammer so
> that it runs many orders faster than the regular version. Or, to
> put it another way, it increases P6C's runspeed from "i
All~
If I recall my dragon book correctly, shift reduce parsers (which are
what most compilers use) can actually parse a larger class of grammars
then recursive descent parsers which can only parse LL(k) grammars. So
that is another good reason to have it. Perhaps Perl 6 grammars should
prov
At 1:24 PM -0500 5/10/04, Allison Randal wrote:
Dan Sugalski wrote:
I'm not so sure about that. (Not that it won't be replaced, but that
it needs the grammar engine) I'm pretty sure that grammars as Larry's
defined 'em are recursive-descent, and if that's true then I've this
really nasty feelin
Dan Sugalski wrote:
>
> I'm not so sure about that. (Not that it won't be replaced, but that
> it needs the grammar engine) I'm pretty sure that grammars as Larry's
> defined 'em are recursive-descent, and if that's true then I've this
> really nasty feeling we're going to find it insufficientl
At 12:34 PM -0500 5/10/04, Allison Randal wrote:
And don't forget, this is just a prototype. All the code will be
replaced as soon as we get a working grammar engine.
I'm not so sure about that. (Not that it won't be replaced, but that
it needs the grammar engine) I'm pretty sure that grammars as
Steve Fink wrote:
Neither of those seems right to me. The first keys off of the position
of the binary, which could be anywhere with respect to the library
module you're in; the second is relative to whatever the current
directory is while you're running the script. I would think that
something l
Abhijit A. Mahabal wrote:
>
> On Mon, 10 May 2004, Steve Fink wrote:
>
> > use File::Basename qw(dirname);
> > use lib dirname($INC{"P6C/Parser.pm"})."/../../../../lib";
>
> I had already tried that, and it doesn't seem to work. I guess it is some
> timing issue: $INC{"P6C/Parser.pm"} gets
On Mon, 10 May 2004, Steve Fink wrote:
> use File::Basename qw(dirname);
> use lib dirname($INC{"P6C/Parser.pm"})."/../../../../lib";
I had already tried that, and it doesn't seem to work. I guess it is some
timing issue: $INC{"P6C/Parser.pm"} gets defined after P6C::Parser.pm is
loaded (I
On May-09, Abhijit A. Mahabal wrote:
> On Sat, 8 May 2004, Abhijit A. Mahabal wrote:
>
> > I was writing a few tests for the P6 parser and ran into a weird problem.
> > If I have the following in a file in languages/perl6, it works as
> > expected:
>
> [...]
>
> > Now, if I put exactly the same
On Sat, 8 May 2004, Abhijit A. Mahabal wrote:
> I was writing a few tests for the P6 parser and ran into a weird problem.
> If I have the following in a file in languages/perl6, it works as
> expected:
[...]
> Now, if I put exactly the same contents in a file in
> languages/perl6/t/parser, then
23 matches
Mail list logo
