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