Re: [gentoo-dev] [RFC] New version constraints: variant one

2016-12-04 Thread konsolebox
On Mon, Dec 5, 2016 at 1:41 AM, Kent Fredric  wrote:
> On Mon, 5 Dec 2016 01:21:34 +0800
> konsolebox  wrote:
>
>> Well that's just it: ease of use and simplicity vs. portability with
>> possible new parameter types in the future; your pick.  I'll
>> personally go for the former this time.
>>
>> Also, what kind of added type of parameters would you expect that
>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>>
>> I also find that the current features are already mature enough; we're
>> just enhancing it to have better control.  I don't expect anything big
>> to be added further.
>
> Its just frustrating for me, because its not the first time I've had this
> conversation.
>
> I have some vague memory of the last time we changed dependency syntax,
> and I said then something along the lines of "hey, why not get this right so
> we don't have to have this again later"
>
> And here we are, bike shedding, debating new syntax classes without forsight.

I would love to prove this with a proof-of-concept, but I don't have
the motivation yet.  I also did it once, it wasn't helpful.

>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>
> The difference between an "operator" and an "identifier" is one of the two
> hails from a limited set of punctuation marks, and sometimes the order is
> important.
>
> For example: 5 + 6 and  add( 5, 6 ), are functionally equivalent, however,
> the former hailed from a narrow supply of characters which people saw fit
> to use for everything, and now you have fun problems in JavaScript where
> "+" does more than one thing depending on conditions.
>
> Punctuation is powerful, but its a limited resource that serves itself
> best when used sparingly.

I agree with that, but we have to consider balancing it a bit sometimes.

-- 
konsolebox



Re: [gentoo-dev] [RFC] New version constraints: variant one

2016-12-04 Thread Kent Fredric
On Mon, 5 Dec 2016 01:21:34 +0800
konsolebox  wrote:

> Well that's just it: ease of use and simplicity vs. portability with
> possible new parameter types in the future; your pick.  I'll
> personally go for the former this time.
> 
> Also, what kind of added type of parameters would you expect that
> would be conflicting with USE flags, or other operators?  Wouldn't
> adding another operator be enough, and not an identifying key?
> 
> I also find that the current features are already mature enough; we're
> just enhancing it to have better control.  I don't expect anything big
> to be added further.

Its just frustrating for me, because its not the first time I've had this
conversation.

I have some vague memory of the last time we changed dependency syntax,
and I said then something along the lines of "hey, why not get this right so
we don't have to have this again later"

And here we are, bike shedding, debating new syntax classes without forsight.

> would be conflicting with USE flags, or other operators?  Wouldn't
> adding another operator be enough, and not an identifying key?

The difference between an "operator" and an "identifier" is one of the two
hails from a limited set of punctuation marks, and sometimes the order is
important.

For example: 5 + 6 and  add( 5, 6 ), are functionally equivalent, however,
the former hailed from a narrow supply of characters which people saw fit
to use for everything, and now you have fun problems in JavaScript where
"+" does more than one thing depending on conditions.

Punctuation is powerful, but its a limited resource that serves itself
best when used sparingly.


pgpYBkbFhyT7n.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New version constraints: variant one

2016-12-04 Thread konsolebox
On Sun, Dec 4, 2016 at 11:22 PM, Kent Fredric  wrote:
> On Thu, 1 Dec 2016 14:53:51 +0800
> konsolebox  wrote:
>
>> I got similar idea here, but my version is that you don't have to use
>> u: or v:
>
> The entire point of defining it as a prefix-space was to avoid ambiguity,
> and leave plenty of room for other such selector prefixes.
>
> Relying on properties like "is it a number" or "is it text" is a shoddy
> heuristic.
>
> A heuristic that will fail us as soon as we want to add new features in
> our matcher syntax.
>
> Hence,
>
>[(,...)]
>
>CONSTRAINT: :(,...)
>
>
> Then instead of debates about how we can invent some "new" syntax
> where we have to constantly reinvent existing syntax to allow space
> for the new syntax, we can just define new identifiers, because we thought
> ahead about this problem and gave us wiggle room to add features.

Well that's just it: ease of use and simplicity vs. portability with
possible new parameter types in the future; your pick.  I'll
personally go for the former this time.

Also, what kind of added type of parameters would you expect that
would be conflicting with USE flags, or other operators?  Wouldn't
adding another operator be enough, and not an identifying key?

I also find that the current features are already mature enough; we're
just enhancing it to have better control.  I don't expect anything big
to be added further.

And come to think of it, a parameter with a key can be distinguished
differently from a USE flag, because a USE flag wouldn't have a colon,
so a parameter with an identifier that defines its class can still be
added if with would need it in the future.

-- 
konsolebox



Re: [gentoo-dev] [RFC] New version constraints: variant one

2016-12-04 Thread Kent Fredric
On Thu, 1 Dec 2016 14:53:51 +0800
konsolebox  wrote:

> I got similar idea here, but my version is that you don't have to use
> u: or v:

The entire point of defining it as a prefix-space was to avoid ambiguity,
and leave plenty of room for other such selector prefixes.

Relying on properties like "is it a number" or "is it text" is a shoddy
heuristic.

A heuristic that will fail us as soon as we want to add new features in
our matcher syntax.

Hence, 

   [(,...)]

   CONSTRAINT: :(,...)


Then instead of debates about how we can invent some "new" syntax
where we have to constantly reinvent existing syntax to allow space
for the new syntax, we can just define new identifiers, because we thought
ahead about this problem and gave us wiggle room to add features.



pgpPjQN0_eTZ1.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New version constraints: variant one

2016-11-30 Thread konsolebox
On Fri, Nov 11, 2016 at 10:37 PM, Kent Fredric  wrote:
> orrr we could do away with punctuation abuse and make "[]" be a 
> "Parameter space"
>
>
>dev-foo/bar[u:foo,v:>=3]

I got similar idea here, but my version is that you don't have to use
u: or v:.  When I was looking for the feature that 'foo[bar?]'
provides yesterday, I saw that the the special operators for use flags
don't conflict with the version operators.  And only use flags use
non-operator characters, so they could be used alone and
distinguishably without any.

dev-foo[>=3,foo]

So this time instead of using () for versions and [] for use flags, we
can just have [] for both.  Of course this again requires that
independent and rearrangeable version elements be implemented.

-- 
konsolebox



Re: [gentoo-dev] [RFC] New version constraints: variant one

2016-11-11 Thread Kent Fredric
On Thu, 10 Nov 2016 23:53:40 +0100
Michał Górny  wrote:

>   dev-foo/bar[>=3][foo]# version + USE

I kinda find this asking for problems with visual ambiguity.

Use different grouping symbols or supercede the USE syntax entirely.

   dev-foo/bar[foo]#(>=3)

Or something. I'm also suggesting here the possibility to define 2-symbol
openers instead of 1, like is common in quoting systems, eg:

  ${thingshere}
  #{thingshere}
  &{thingshere}

That way you have more wiggle room for more punctuation abuse later.

orrr we could do away with punctuation abuse and make "[]" be a "Parameter 
space"


   dev-foo/bar[u:foo,v:>=3]

Where the general form is:

  [NAME:VAL,VAL,VAL,NAME:VAL,VAL]

Where

  NAME=u == "use requirement"
  NAME=v == "version requirement"

I know I'm painting a bike shed here, but I remember years ago suggesting the
last feature we added should have planned for a more future-extensible syntax,
and here we are again, bodging syntax entirely instead of simply extending the 
defined one.

Punctuation is precious and rare, and so you should exploit only as little as 
you need.



pgpJ78LZzAsW3.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New version constraints: variant one

2016-11-10 Thread konsolebox
On Fri, Nov 11, 2016 at 6:53 AM, Michał Górny  wrote:
> Hello, everyone.
>
> Following my earlier threads, I'd like to propose a first complete
> solution for new version restrictions for package dependencies. I
> honestly doubt it's going to be approved since it's a major change.
> Nevertheless, I think it's an interesting topic for consideration.
>
> What is included:
>
> - conjunctive version ranges,
> - revision-free and revision-oriented comparisons,
> - full set of (blocker-free) logical operators.
>
> What isn't included:
>
> - disjunctive version ranges,
> - complete lower bound problem solution,
> - extensions for prefix matching,
> - some convenience shortcuts like Ruby's ~> op.
>
>
> Backwards compatibility [recommended]
> =
>
> For backwards compatibility, package dependency specifications using
> old-style restrictions will still be accepted. Those specifications
> will retain the old behavior, and have no new features.
>
>
> New package dependency syntax
> =
>
> New-style package dependencies use the following syntax:
>
>"/"  [":" ] ["["  "]"] ["["  "]"]
>
> with  now using the following sub-syntax:
>
> [","  ...]
>
> The version restriction operator is removed from the front and all
> package dependency specifications start with the category and package
> name, followed by optional package slot. This can be followed by
> optional version restrictions and USE flag restrictions.
>
> The version constraints (if present) must *always* be placed inside
> square brackets, even for a single constraint. Each constraint starts
> with an operator followed by a version string. Multiple constraints are
> separated using "," character, and are conjunctive (AND-ed).
>
> The operators are not valid for beginning of a USE dependency string,
> therefore the version constraint can be clearly distinguished from USE
> contraints.
>
> The version and USE flag constraints are always disjoint. If both are
> present, they must be surrounded by separate pairs of brackets.
>
> Examples:
>
>   dev-foo/bar:13[foo]  # slot + USE
>   dev-foo/bar[>=3] # single version constraint
>   dev-foo/bar:4[>=4.11,<4.20]  # slot + version range
>   dev-foo/bar[>=3][foo]# version + USE

Looks like you excluded the independent rearrangeability of the
conditional elements, and the OR feature; and also, grouping being
optional where AND would be the default control operator.

Does that still allow multi-level grouping?

You can choose to have such restrictions now, but I still highly
suggest the use of () instead of [], so it would be clear that [] is
for use flags, and () is for versions.  Not only would that lessen
confusion and remove the parser's necessity to look-ahead-and-verify,
it would also make the syntax open to future improvements.

The use of comma as a separator looks good, and minimizes the
characters that the parser would have to check when checking for a new
token.

> Version restrictions
> 
>
> Each version restriction consists of an operator followed by a version
> string.
>
> The following revision-free version comparison operators are provided:
>
>  ==   exact version match, or prefix match (with *)
>  !=   exact version non-match, or prefix non-match (with *)
>    <=   version less or equal to match
>  >version greater than match
>  >=   version greater or equal to match
>
> All those operators compare on versions ignoring the revision part.
> They must be followed by a valid version with no revision part.
> Additionally, the == and != operators can accept a version followed by
> * to indicate prefix match.
>
> The following revision-oriented version comparison operators are
> provided:
>
>  ===  exact version+revision match
>  !==  exact version+revision non-match
>  <==  version+revision less or equal to match
>  >==  version+revision greater or equal to match

I doubted this at first but after further examination I found that
it's actually more consistent.  It's more aggressive but it's a more
correct solution.

-- 
konsolebox



[gentoo-dev] [RFC] New version constraints: variant one

2016-11-10 Thread Michał Górny
Hello, everyone.

Following my earlier threads, I'd like to propose a first complete
solution for new version restrictions for package dependencies. I
honestly doubt it's going to be approved since it's a major change.
Nevertheless, I think it's an interesting topic for consideration.

What is included:

- conjunctive version ranges,
- revision-free and revision-oriented comparisons,
- full set of (blocker-free) logical operators.

What isn't included:

- disjunctive version ranges,
- complete lower bound problem solution,
- extensions for prefix matching,
- some convenience shortcuts like Ruby's ~> op.


Backwards compatibility [recommended]
=

For backwards compatibility, package dependency specifications using
old-style restrictions will still be accepted. Those specifications
will retain the old behavior, and have no new features.


New package dependency syntax
=

New-style package dependencies use the following syntax:

   "/"  [":" ] ["["  "]"] ["["  "]"]

with  now using the following sub-syntax:

[","  ...]

The version restriction operator is removed from the front and all
package dependency specifications start with the category and package
name, followed by optional package slot. This can be followed by
optional version restrictions and USE flag restrictions.

The version constraints (if present) must *always* be placed inside
square brackets, even for a single constraint. Each constraint starts
with an operator followed by a version string. Multiple constraints are
separated using "," character, and are conjunctive (AND-ed).

The operators are not valid for beginning of a USE dependency string,
therefore the version constraint can be clearly distinguished from USE
contraints.

The version and USE flag constraints are always disjoint. If both are
present, they must be surrounded by separate pairs of brackets.

Examples:

  dev-foo/bar:13[foo]  # slot + USE
  dev-foo/bar[>=3] # single version constraint
  dev-foo/bar:4[>=4.11,<4.20]  # slot + version range
  dev-foo/bar[>=3][foo]# version + USE


Version restrictions


Each version restriction consists of an operator followed by a version
string.

The following revision-free version comparison operators are provided:

 ==   exact version match, or prefix match (with *)
 !=   exact version non-match, or prefix non-match (with *)
 version greater than match
 >=   version greater or equal to match

All those operators compare on versions ignoring the revision part.
They must be followed by a valid version with no revision part.
Additionally, the == and != operators can accept a version followed by
* to indicate prefix match.

The following revision-oriented version comparison operators are
provided:

 ===  exact version+revision match
 !==  exact version+revision non-match
 <==  version+revision less or equal to match
 >==  version+revision greater or equal to match

Those operators include both version and revision in the comparison.
They must be followed by a valid version with an optional revision
part. No revision is equal to -r0. Prefix match is not allowed.

Examples:

 [==1.3.3] version 1.3.3, any revision
 [>1.3.3]  version >1.3.3 (e.g. 1.3.3.1 or 1.3.4...)
 [<=1.3.3] version <=1.3.3 (incl. any revision of 1.3.3)
 [===1.3.3]1.3.3-r0
 [>==1.3.3-r2] 1.3.3-r2 or newer
 [>=1.2,!=1.3.3]   version >=1.2 but not 1.3.3 (any revision)
 [>=1.2,<1.4]  version >=1.2 but <1.4
 [==1.2*]  any version starting with 1.2 prefix
 [>=1.2,<1.8,!=1.6*]   version >=1.2 but <1.8, also excluding 1.6*


Mapping from existing dependency syntax
===

It should be noted that whenever revision match is desired, one of *==
operators need to be used. They do not include '<' or '>' variants, so
the revision needs to be decreased or increased appropriately for <==
or >==.

The behavior of current '~' operator is now equal to '==', so the
former is removed.

 =foo-1.2.3 ===1.2.3
 =foo-1.2.3-r3  ===1.2.3-r3
 =foo-1.2.3*==1.2.3*
 ~foo-1.2.3 ==1.2.3
 >foo-1.2.3 >==1.2.3-r1
 >foo-1.2.3-r   >1.2.3
 >=foo-1.2.3>=1.2.3 or >==1.2.3
 >=foo-1.2.3-r3 >==1.2.3-r3
 =1.2,<1.6,!=1.4*,!=1.5*]

While I agree that this is not perfect and can become quite verbose at
times, the use cases for it are rather limited.

Revision ranges can be easily constructed using version ranges:

 [>==1.3-r3,<==1.3-r7]

Not that I see any real use for them.

Pre-release version ranges can be achieved using the relatively safe
_alpha_alpha or _p_p suffixes, or just predicting the upstream version
use.

The convenience Ruby ~> operator needs to be expanded to the verbose
range:

 [>=1.3.4,<1.4] or [>=1.3.4,==1.3*]


Rationale
=

The key goal behind this