Can a link to be added to ?


On 08/25/2015 07:11 AM, Florian Festi wrote:

I have been visiting Michael Schröder discussing the syntax for the rich
deps [1]. There are still a few issues we like to get some input from
the wider community:

IF Operator
We concluded that the most important question was what to do with the if
operator. There are two basic variants that can both be used with
different symbols: forward and backward [2].

Requires: (langsupport-es ? foo-lang-es)
Requires: (langsupport-es ?? foo-lang-es)
Requires: (langsupport-es then foo-lang-es)
Requires: (langsupport-es THEN foo-lang-es)
Requires: (langsupport-es -> foo-lang-es)
Requires: (foo-lang-es if langsupport-es)
Requires: (foo-lang-es IF langsupport-es)
Requires: (foo-lang-es <- langsupport-es)

With ELSE operand:
Requires: (pkgB ? pkgA : pkgC)
Requires: (pkgB ?? pkgA !! pkgC)
Requires: (pkgB then pkgA else pkgC)
Requires: (pkgB THEN pkgA ELSE pkgC)
Requires: (pkgA if pkgB else pkgC)
Requires: (pkgA IF pkgB ELSE pkgC)

Semantics for all examples is: foo-lang-es/pkgA is needed if
langsupport-es/pkgB is installed. pkgC is required instead if
langsupport-es/pkgB is not installed.

After a lengthy discussion we are pretty confident that the Python style
(. IF . [ELSE .]) is the best choice. It gives a clear hint which
direction the operator works and is more familiar than the implication
arrows and THEN.

As I - as a Python programmer - am pretty biased I am very interested if
programmers knowing only other languages or package maintainers without
programming skills can relate to this decision.

We discussed whether the operators should be upper or lower case or case
insensitive. So far we think *upper case* is better as is stands out
between the typically lower case package names. But we are interested on
second opinions on this, too.

AND and OR

Assuming that (. IF . [ELSE .]) is chosen as syntax if the if operator
we discussed how to represent AND and OR. We dropped || and && as dpkg
uses | and having bitwise and logical operators at the same time does
not make any sense in an rpm context - we are operating on true Boolean
only there is no change of ints getting into this.

In the end this is more or less a matter of taste. We tended to just
stick to written out operators but in the end there is no strong case to
make for any of them.

So what syntax does feel most natural to you (most obvious pro arguments
in parenthesis)

[ ] AND and OR   (easier to spot, aligned with IF and ELSE)
[ ] & and |      (aligned with dpkg and many programming languages)
[ ] && and ||    (stress Boolean character)

NOT not?

We discussed whether to add a NOT operator. One of the reasons not to
was that it is pretty awkward if used on the top level:

Requires: (NOT pkgA)
which is basically a Conflict
or even:
Conflicts: (NOT pkgA)
which is basically a Requires

Technically a NOT operator should not be needed. So we are basically
looking for real life examples where it would be really handy or even a
pain if it was missing. What would you do with a NOT operator?


[2] We are talking about Boolean operators here - not if statements.
Those variants are identical to the forward and backward implication
which are identical to (NOT . OR .) and (. OR NOT .)

Rpm-ecosystem mailing list

Reply via email to