| 1 |
On Wed, Nov 9, 2016 at 8:30 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> On 11/08/2016 10:47 AM, Michał Górny wrote: |
| 3 |
>> |
| 4 |
>> Strictly speaking, we don't have to since the lexing should be |
| 5 |
>> predictable enough. Of course, mistakes like missing version following |
| 6 |
>> the operator would result in curious errors. |
| 7 |
>> |
| 8 |
>> The major problem with spaces I see is that it means we end up having |
| 9 |
>> an additional [use] block floating following them. |
| 10 |
>> |
| 11 |
> |
| 12 |
> I was also thinking that the logical operators could be infix, and then |
| 13 |
> you need the commas to avoid precedence issues with the implicit-and, |
| 14 |
> which is written " ". |
| 15 |
|
| 16 |
Commas and spaces can be made optional if we allow the following |
| 17 |
tokens to be the delimiter itself. Grouping and use of white space |
| 18 |
can be optionally used in cases where operators would collide, most |
| 19 |
especially after :=. |
| 20 |
|
| 21 |
A valid package name entry also signals end of the rules for the previous entry. |
| 22 |
|
| 23 |
Also, precedence issues and confusions can be avoid by relying on more |
| 24 |
explicit grouping like () and {}, instead of &&, ||, & and |. |
| 25 |
|
| 26 |
> The [use] blocks could be moved next to the |
| 27 |
> package name I guess. |
| 28 |
|
| 29 |
It can actually be allowed to be placed anywhere if we don't use [] |
| 30 |
for condition grouping, and just use it for the use block. |
| 31 |
|
| 32 |
-- |
| 33 |
konsolebox |
Archives