linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Jon Loeliger <jdl@jdl.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] DTC: Remove the need for the GLR Parser.
Date: Wed, 24 Oct 2007 11:11:59 +1000	[thread overview]
Message-ID: <20071024011159.GI10595@localhost.localdomain> (raw)
In-Reply-To: <E1IkKge-00060g-2l@jdl.com>

On Tue, Oct 23, 2007 at 09:24:52AM -0500, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > On Mon, Oct 22, 2007 at 04:13:54PM -0500, Jon Loeliger wrote:
[snip]
> > I really thought our conflicts
> > were somewhere else.  Specifically I thought the problem was that we
> > needed to look ahead more tokens that we were able to differentiate
> > between property and subnode definitions, i.e. between:
> > 	label propname =
> > and
> > 	label propname {
> 
> Yes, it was.  When you compute the closure of the propdef with
> the rule as a right-recursive, that's when you get the conflict.

Ah, right.  Been too long since studied LR parsers, obviously.

[snip]
> > More significantly, I don't know that we want to burn our bridges with
> > glr-parser.  glr-parser is a beautiful algorithm which means we can
> > use essentially whatever form of grammar is the easiest to work with
> > without having to fiddle about to ensure it's LALR(1).  This could
> > still be useful if we encounter some less easily finessable grammar
> > construct in future.
> 
> I'm not saying we can't use it in the future, as needed!  I'm just
> saying it isn't strictly necessary now.

Sure.  Sorry, I was unclear; I wasn't saying we shouldn't remove the
glr-parser option now: certainly we should remove that
right-recursion, and then we don't need it.  I'm saying we shouldn't
do other things which would preclude bringing it back.

> > And even without glr-parser, I'm still uncomfortable with the
> > lexer<->parser execution ordering issues with the current
> > /dts-version/ proposal.  It may now be true that the order is
> > guaranteed to be correct, but it's still not exactly obvious.
> 
> I'm fine with it, and though I read your words, I'm not really
> sure why you are not....  In the long term, maybe think of it
> as a temporary hack then.  We'll convert the existing DTS files
> over to the new version, and then deprecate the "dts-version 0"
> files and support and it will all go away relatively soon.

I just think that putting the version number into the token is
simpler, clearer and has no disadvantage compared to a version
integer.  And will remain so if we have to bump the version again.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

      parent reply	other threads:[~2007-10-24  1:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-22 21:13 [PATCH] DTC: Remove the need for the GLR Parser Jon Loeliger
2007-10-23  2:54 ` David Gibson
2007-10-23 14:24   ` Jon Loeliger
2007-10-23 14:41     ` Segher Boessenkool
2007-10-23 14:49       ` Jon Loeliger
2007-10-23 23:41         ` David Gibson
2007-10-23 23:37       ` David Gibson
2007-10-23 16:07     ` Jon Loeliger
2007-10-23 23:44       ` David Gibson
2007-10-24  1:11     ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071024011159.GI10595@localhost.localdomain \
    --to=david@gibson.dropbear.id.au \
    --cc=jdl@jdl.com \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).