1 |
On wto, 2017-06-06 at 14:08 +0200, Alexis Ballier wrote: |
2 |
> On Mon, 05 Jun 2017 20:10:12 +0200 |
3 |
> Michał Górny <mgorny@g.o> wrote: |
4 |
> [...] |
5 |
> > > > Stand-alone makes little sense (and little trouble) but as you |
6 |
> > > > could have seen it's used nested in other thingies: |
7 |
> > > > |
8 |
> > > > 1. || ( ( a b ) ( c d ) e ) |
9 |
> > > > |
10 |
> > > > 2. ?? ( ( a b ) ( c d ) e ) |
11 |
> > > > |
12 |
> > > > 3. ^^ ( ( a b ) ( c d ) e ) |
13 |
> > > |
14 |
> > > Yeah that's the nesting problem causing a parse error. |
15 |
> > > Those should be expanded to implications. What I'm relying onto is |
16 |
> > > all clauses to be of the form '[list of conditions]? [list of |
17 |
> > > constraints]' |
18 |
> > |
19 |
> > I've noticed that you turned the implications into multi-conditions, |
20 |
> > breaking all my scripts ;-). Is the [list of conditions] conjunctive |
21 |
> > or disjunctive? |
22 |
> |
23 |
> conjunctive as in foo? ( bar? ( baz ) ) -> [foo,bar]?[baz] |
24 |
|
25 |
Yeah, I guess that's useful. I didn't do that originally because I |
26 |
wanted the AST to be fully compatible with REQUIRED_USE in Gentoo. But I |
27 |
guess it doesn't hurt, and makes a lot of the code simpler. |
28 |
|
29 |
I've backported this change and adjusted all the remaining modules to |
30 |
work with it correctly. |
31 |
|
32 |
> |
33 |
> [...] |
34 |
> > > > The question is whether we want to: |
35 |
> > > > |
36 |
> > > > a. actually try to solve this nesting insanity, |
37 |
> > > > |
38 |
> > > > b. declare it unsupported and throw REQUIRED_USE mismatch on user, |
39 |
> > > > |
40 |
> > > > c. ban it altogether. |
41 |
> > > |
42 |
> > > |
43 |
> > > I don't think it is *that* insane to support nesting :) |
44 |
> > > |
45 |
> > > > ( ^^ ( ?? ( a b ) c ( d e ) ) f ) |
46 |
> |
47 |
> If you really need that then you'd need to expand it manually. It seems |
48 |
> better to have it expanded internally automatically. |
49 |
> Remember you were the one wanting to keep || & co because they're |
50 |
> simpler to read and write ;) |
51 |
> |
52 |
|
53 |
Well, I was able to implement the logic for all-of blocks outside |
54 |
and inside other n-ary constraints, including the necessary logic |
55 |
transformations. Fun fact is, I was able to do it without implementing |
56 |
a complete set of logic functions and transformations in AST ;-). |
57 |
|
58 |
I've just made it fail (correctly this time) with any other kind of |
59 |
nesting -- I don't think it's going to have a real use case and even if |
60 |
it did, there are more readable ways of solving the same problem. |
61 |
|
62 |
The question is -- will you rebase now on top of my changes |
63 |
(and preferably use nice logical changes with good commit messages), |
64 |
or should I try later to merge the rest of your code in? ;-) |
65 |
|
66 |
Also, do I presume correctly that for all supported cases (i.e. those |
67 |
which your nsolve does not reject), solve and nsolve are compatible? |
68 |
|
69 |
-- |
70 |
Best regards, |
71 |
Michał Górny |