Home » Archived » B3 » suggestion for changes to advice expressions
|
| Re: suggestion for changes to advice expressions [message #492132 is a reply to message #492131] |
Mon, 19 October 2009 01:02   |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
I forgot two things:
Synthetic nodes
---
Currently ':' is used to refer to a synthetic node - like "first" or
"last" - we could use @ for that.
Example -
x:*:y:values@first = 10;
Insert (assuming that "first" means "before first") the value 10 in
every feature "values" of any feature "y" being a grandchild of "x"
Set operators
---
XPath has a union set operator | which is used as in:
x/y[z=a] | x/p
i.e. all 'y' children of 'x' with a 'z' feature of value 'a'
One can imagine having the full set of operators:
| = union
& = intersection
^ = symmetric difference (i.e. not in both)
- = complement
() = evaluation order control
If there are two sets A and B, with an intersection C. Then:
A | B => A + B
A & B => C
A ^ B => A + B - C
A - B => A - C
B - A => B - C
I think these are very valuable in some advanced cases, as it allows
stating what would otherwise be impossible to query for without
performing multiple steps where each step colors nodes.
The set operations are also of value when operating on path group vectors.
Imagine a group declaration of
group{ a; b; c; }
And parts b and c include (via some nesting) the part x. As a
constructor of the system, I don't want x included in the result because
I want a different packaging where x is mixed in at a later stage. I
can't change b and c because they are outside of my control. It is also
difficult to restate them to not include x as it comes via dependencies
further away. I can't simply add advice that makes everything downstream
drop requirements on x and not include it - then those parts of the
build would fail.
One can imagine a statement like
group {a; b; c; -x; } to mean that the paths produced by x are dropped
from the resulting path group vector. As this is not the most common of
operations, this is better moved to expressions in an action.
action {
group { all={a; b; c;); x = x; }
layout{ expr all - x; }
where would be posible to use the full set of set operators.
- henrik
On 10/19/09 1:31 AM, Henrik Lindberg wrote:
> I suggest that we change the syntax for advice expressions.
> At first I attempted to use the standard XPath syntax, but since // and
> * are defined in XPath, there are many XPath's that conflicts with the
> use of // and /* */ comments (I would like to keep those).
>
> To avoid the issue, I used the following mapping from XPath to b3:
>
> / = /
> * = ?
> // = /??
>
> And I was not very happy about this. Later we decided to use ":" as the
> member/feature operator in expressions. I think it makes sense to apply
> this to the advice expressions as well.
>
> So, XPath operators would instead be mapped like this:
>
> / = :
> * = *
> // = ::
>
> Examples:
> x:y - feature y of x
> x:*:y - feature y of any child of x
> x::y - feature y of any descendant of x (ANT uses **, which is also a
> possibility - i.e. x:**:y)
>
> Thoughts ?
>
> - henrik
|
|
|
| Re: suggestion for changes to advice expressions [message #492155 is a reply to message #492131] |
Mon, 19 October 2009 07:35 |
|
I agree. Using ':' and '*' is much cleaner. I think we should support both x::y and x:**:y if possible.
- thomas
On 10/19/2009 01:31 AM, Henrik Lindberg wrote:
> I suggest that we change the syntax for advice expressions.
> At first I attempted to use the standard XPath syntax, but since // and
> * are defined in XPath, there are many XPath's that conflicts with the
> use of // and /* */ comments (I would like to keep those).
>
> To avoid the issue, I used the following mapping from XPath to b3:
>
> / = /
> * = ?
> // = /??
>
> And I was not very happy about this. Later we decided to use ":" as the
> member/feature operator in expressions. I think it makes sense to apply
> this to the advice expressions as well.
>
> So, XPath operators would instead be mapped like this:
>
> / = :
> * = *
> // = ::
>
> Examples:
> x:y - feature y of x
> x:*:y - feature y of any child of x
> x::y - feature y of any descendant of x (ANT uses **, which is also a
> possibility - i.e. x:**:y)
>
> Thoughts ?
>
> - henrik
|
|
| |
| Re: suggestion for changes to advice expressions [message #492200 is a reply to message #492180] |
Mon, 19 October 2009 12:38 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
The use of ':' is subject to decision on JS, and complying with JS
syntax, where member operator is '.' or '[expr]' which clashes quite
badly. However, since advice could be seen as being "something
different" we could stick with : there anyway.
- henrik
On 10/19/09 12:50 PM, Henrik Lindberg wrote:
> Thomas Hallgren<thomas@tada.se> wrote:
>> I agree. Using ':' and '*' is much cleaner. I think we should support
>> both x::y and x:**:y if possible.
>>
> Will try that.
>> - thomas
>>
>> On 10/19/2009 01:31 AM, Henrik Lindberg wrote:
>>> I suggest that we change the syntax for advice expressions.
>>> At first I attempted to use the standard XPath syntax, but since //
>>> and
>>> * are defined in XPath, there are many XPath's that conflicts with
>>> the
>>> use of // and /* */ comments (I would like to keep those).
>>>
>>> To avoid the issue, I used the following mapping from XPath to b3:
>>>
>>> / = /
>>> * = ?
>>> // = /??
>>>
>>> And I was not very happy about this. Later we decided to use ":" as
>>> the
>>> member/feature operator in expressions. I think it makes sense to
>>> apply
>>> this to the advice expressions as well.
>>>
>>> So, XPath operators would instead be mapped like this:
>>>
>>> / = :
>>> * = *
>>> // = ::
>>>
>>> Examples:
>>> x:y - feature y of x
>>> x:*:y - feature y of any child of x
>>> x::y - feature y of any descendant of x (ANT uses **, which is also
>>> a
>>> possibility - i.e. x:**:y)
>>>
>>> Thoughts ?
>>>
>>> - henrik
>
>
|
|
|
| Re: suggestion for changes to advice expressions [message #582861 is a reply to message #492131] |
Mon, 19 October 2009 01:02 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
I forgot two things:
Synthetic nodes
---
Currently ':' is used to refer to a synthetic node - like "first" or
"last" - we could use @ for that.
Example -
x:*:y:values@first = 10;
Insert (assuming that "first" means "before first") the value 10 in
every feature "values" of any feature "y" being a grandchild of "x"
Set operators
---
XPath has a union set operator | which is used as in:
x/y[z=a] | x/p
i.e. all 'y' children of 'x' with a 'z' feature of value 'a'
One can imagine having the full set of operators:
| = union
& = intersection
^ = symmetric difference (i.e. not in both)
- = complement
() = evaluation order control
If there are two sets A and B, with an intersection C. Then:
A | B => A + B
A & B => C
A ^ B => A + B - C
A - B => A - C
B - A => B - C
I think these are very valuable in some advanced cases, as it allows
stating what would otherwise be impossible to query for without
performing multiple steps where each step colors nodes.
The set operations are also of value when operating on path group vectors.
Imagine a group declaration of
group{ a; b; c; }
And parts b and c include (via some nesting) the part x. As a
constructor of the system, I don't want x included in the result because
I want a different packaging where x is mixed in at a later stage. I
can't change b and c because they are outside of my control. It is also
difficult to restate them to not include x as it comes via dependencies
further away. I can't simply add advice that makes everything downstream
drop requirements on x and not include it - then those parts of the
build would fail.
One can imagine a statement like
group {a; b; c; -x; } to mean that the paths produced by x are dropped
from the resulting path group vector. As this is not the most common of
operations, this is better moved to expressions in an action.
action {
group { all={a; b; c;); x = x; }
layout{ expr all - x; }
where would be posible to use the full set of set operators.
- henrik
On 10/19/09 1:31 AM, Henrik Lindberg wrote:
> I suggest that we change the syntax for advice expressions.
> At first I attempted to use the standard XPath syntax, but since // and
> * are defined in XPath, there are many XPath's that conflicts with the
> use of // and /* */ comments (I would like to keep those).
>
> To avoid the issue, I used the following mapping from XPath to b3:
>
> / = /
> * = ?
> // = /??
>
> And I was not very happy about this. Later we decided to use ":" as the
> member/feature operator in expressions. I think it makes sense to apply
> this to the advice expressions as well.
>
> So, XPath operators would instead be mapped like this:
>
> / = :
> * = *
> // = ::
>
> Examples:
> x:y - feature y of x
> x:*:y - feature y of any child of x
> x::y - feature y of any descendant of x (ANT uses **, which is also a
> possibility - i.e. x:**:y)
>
> Thoughts ?
>
> - henrik
|
|
|
| Re: suggestion for changes to advice expressions [message #582921 is a reply to message #492131] |
Mon, 19 October 2009 07:35 |
|
I agree. Using ':' and '*' is much cleaner. I think we should support both x::y and x:**:y if possible.
- thomas
On 10/19/2009 01:31 AM, Henrik Lindberg wrote:
> I suggest that we change the syntax for advice expressions.
> At first I attempted to use the standard XPath syntax, but since // and
> * are defined in XPath, there are many XPath's that conflicts with the
> use of // and /* */ comments (I would like to keep those).
>
> To avoid the issue, I used the following mapping from XPath to b3:
>
> / = /
> * = ?
> // = /??
>
> And I was not very happy about this. Later we decided to use ":" as the
> member/feature operator in expressions. I think it makes sense to apply
> this to the advice expressions as well.
>
> So, XPath operators would instead be mapped like this:
>
> / = :
> * = *
> // = ::
>
> Examples:
> x:y - feature y of x
> x:*:y - feature y of any child of x
> x::y - feature y of any descendant of x (ANT uses **, which is also a
> possibility - i.e. x:**:y)
>
> Thoughts ?
>
> - henrik
|
|
| |
| Re: suggestion for changes to advice expressions [message #582976 is a reply to message #492180] |
Mon, 19 October 2009 12:38 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
The use of ':' is subject to decision on JS, and complying with JS
syntax, where member operator is '.' or '[expr]' which clashes quite
badly. However, since advice could be seen as being "something
different" we could stick with : there anyway.
- henrik
On 10/19/09 12:50 PM, Henrik Lindberg wrote:
> Thomas Hallgren<thomas@tada.se> wrote:
>> I agree. Using ':' and '*' is much cleaner. I think we should support
>> both x::y and x:**:y if possible.
>>
> Will try that.
>> - thomas
>>
>> On 10/19/2009 01:31 AM, Henrik Lindberg wrote:
>>> I suggest that we change the syntax for advice expressions.
>>> At first I attempted to use the standard XPath syntax, but since //
>>> and
>>> * are defined in XPath, there are many XPath's that conflicts with
>>> the
>>> use of // and /* */ comments (I would like to keep those).
>>>
>>> To avoid the issue, I used the following mapping from XPath to b3:
>>>
>>> / = /
>>> * = ?
>>> // = /??
>>>
>>> And I was not very happy about this. Later we decided to use ":" as
>>> the
>>> member/feature operator in expressions. I think it makes sense to
>>> apply
>>> this to the advice expressions as well.
>>>
>>> So, XPath operators would instead be mapped like this:
>>>
>>> / = :
>>> * = *
>>> // = ::
>>>
>>> Examples:
>>> x:y - feature y of x
>>> x:*:y - feature y of any child of x
>>> x::y - feature y of any descendant of x (ANT uses **, which is also
>>> a
>>> possibility - i.e. x:**:y)
>>>
>>> Thoughts ?
>>>
>>> - henrik
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 10:23:15 GMT 2024
Powered by FUDForum. Page generated in 0.03219 seconds |
] 
Search
Help
Register
Login
Home
