On Mon, 1 Oct 2012 02:01:32 -0700
Brian Harring <ferringb@gmail.com> wrote:
> On Mon, Oct 01, 2012 at 08:13:49AM +0100, Ciaran McCreesh wrote:
> > x? ( build: a run: b ) *is* nested "conflicting".
> > 
> > You're still failing to understand the point of labels parsing
> > rules, though: the point is to make uses like the above well
> > defined and consistent.
> 
> I understand them just fine; you're just either very fucking daft, 
> which I have a hard time believing, or lieing through your teeth 
> (which fits a decade of behaviour including multiple suspensions for 
> exactly that behaviour).
> 
> Implicit labels context is build+run.  Meaning the following
> > x? ( build: a run: b ) *is* nested "conflicting".
> 
> is actually
> 
> build+run x? ( build: a run: b )
> 
> Which isn't a nested conflict- subset, not conflict.

As I said right at the start, you're special-casing the top level to
something that can't normally be expressed using the syntax.

> You argue labels are required so people can do nested conflicts; 
> meaning the following extreme example:
> 
> run x? ( build: a test: b )
> 
> And as I nicely pointed out, /not a single fucking exheres/ does
> that. you've yet to pull out an example contradicting that analysis
> in addition.

No, I argue that having well-defined parsing rules means it doesn't
matter if someone does do that. Meaning, no special case for the top
level.

Your rules require a handler to say "have I seen any dep: blocks
further up the tree than my current position? If yes, handle this dep:
block one way; otherwise, handle it a different way". With labels, all
you do is initialise the label stack with build+run, and then no
special case handling is required.

That's what you should be putting in the GLEP. Not examples, but a big
fat warning that your syntax requires a very strange special case rule
to handle your default build+run behaviour.

> What I truly love about that solution there is that it's both 
> accurate, and if I play my cards right, I may be able to get a glep 
> passed calling your proposal academic wankery; minimally, it'll be
> fun from my standpoint to try, so at least something came out of the
> last few emails from you.

Oh come on, we all know that unnecessarily screwing up the syntax won't
make DEPENDENCIES be sufficiently un-exherbo-looking to get it passed...

-- 
Ciaran McCreesh