On 11/08/2016 10:47 AM, Michał Górny wrote:
>
> Strictly speaking, we don't have to since the lexing should be
> predictable enough. Of course, mistakes like missing version following
> the operator would result in curious errors.
>
> The major problem with spaces I see is that it means we end up having
> an additional [use] block floating following them.
>
I was also thinking that the logical operators could be infix, and then
you need the commas to avoid precedence issues with the implicit-and,
which is written " ". The [use] blocks could be moved next to the
package name I guess. If we were to rewrite the dependency syntax from
scratch, what would it look like? My first attempt would look something
like,
DEPEND="dev-lang/perl,
net-misc/wget || net-misc/curl,
apache2? ( www-servers/apache[apache2_modules_cgi] >= 2.4 ),
ssl? (
!libressl? ( dev-libs/openssl:=0 ),
libressl? ( dev-libs/libressl:= )
)"
The reason I'm entertaining this is because the more operators we add,
the more awkward the prefix notation gets. If we had spaces around the
operators, they wouldn't need to consist of invalid package characters,
and we could do something like,
DEPEND="app-foo/bar in [1,2]"
to request a version in the closed interval [1,2]. For (half) exclusive
ranges, we could have (1,2), (1,2], and [1,2) -- there's no need to
reinvent that particular wheel. We know that "in" surrounded by spaces
is an operator, and we know the types of its two arguments. With prefix
notation, you'd have
DEPEND="inapp-foo/bar[1,2]" #fail
There's always ∈, but you still have to figure out what's in the brackets.
It's fun to brainstorm, but there are probably numerous problems with
every syntax I've imagined, and the only way to have a meaningful
discussion about one of them would be to create a reference
implementation and migrate some ebuilds. Retraining hundreds of
developers and users is a high bar to set without being damn sure that
we've got it right.
