On Mon, 1 Oct 2012 02:01:32 -0700 Brian Harring <ferri...@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
signature.asc
Description: PGP signature
