1 |
On Mon, 1 Oct 2012 02:01:32 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> On Mon, Oct 01, 2012 at 08:13:49AM +0100, Ciaran McCreesh wrote: |
4 |
> > x? ( build: a run: b ) *is* nested "conflicting". |
5 |
> > |
6 |
> > You're still failing to understand the point of labels parsing |
7 |
> > rules, though: the point is to make uses like the above well |
8 |
> > defined and consistent. |
9 |
> |
10 |
> I understand them just fine; you're just either very fucking daft, |
11 |
> which I have a hard time believing, or lieing through your teeth |
12 |
> (which fits a decade of behaviour including multiple suspensions for |
13 |
> exactly that behaviour). |
14 |
> |
15 |
> Implicit labels context is build+run. Meaning the following |
16 |
> > x? ( build: a run: b ) *is* nested "conflicting". |
17 |
> |
18 |
> is actually |
19 |
> |
20 |
> build+run x? ( build: a run: b ) |
21 |
> |
22 |
> Which isn't a nested conflict- subset, not conflict. |
23 |
|
24 |
As I said right at the start, you're special-casing the top level to |
25 |
something that can't normally be expressed using the syntax. |
26 |
|
27 |
> You argue labels are required so people can do nested conflicts; |
28 |
> meaning the following extreme example: |
29 |
> |
30 |
> run x? ( build: a test: b ) |
31 |
> |
32 |
> And as I nicely pointed out, /not a single fucking exheres/ does |
33 |
> that. you've yet to pull out an example contradicting that analysis |
34 |
> in addition. |
35 |
|
36 |
No, I argue that having well-defined parsing rules means it doesn't |
37 |
matter if someone does do that. Meaning, no special case for the top |
38 |
level. |
39 |
|
40 |
Your rules require a handler to say "have I seen any dep: blocks |
41 |
further up the tree than my current position? If yes, handle this dep: |
42 |
block one way; otherwise, handle it a different way". With labels, all |
43 |
you do is initialise the label stack with build+run, and then no |
44 |
special case handling is required. |
45 |
|
46 |
That's what you should be putting in the GLEP. Not examples, but a big |
47 |
fat warning that your syntax requires a very strange special case rule |
48 |
to handle your default build+run behaviour. |
49 |
|
50 |
> What I truly love about that solution there is that it's both |
51 |
> accurate, and if I play my cards right, I may be able to get a glep |
52 |
> passed calling your proposal academic wankery; minimally, it'll be |
53 |
> fun from my standpoint to try, so at least something came out of the |
54 |
> last few emails from you. |
55 |
|
56 |
Oh come on, we all know that unnecessarily screwing up the syntax won't |
57 |
make DEPENDENCIES be sufficiently un-exherbo-looking to get it passed... |
58 |
|
59 |
-- |
60 |
Ciaran McCreesh |