[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Additional "in" operator for fields being lists of strings

From: Marcin Szewczyk
Subject: Re: Additional "in" operator for fields being lists of strings
Date: Thu, 30 Jul 2020 21:08:02 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

On Thu, Jul 30, 2020 at 08:03:24PM +0200, Jose E. Marchesi wrote:
> [...]
>    - Currently the sex evaluator is not aware of the existence of enumerated
>      values, treating enumerated fields as strings.  In order to support
>      multi-valued enumerated fields the interpreter must be equipped with
>      enum-specific operators.  These operators would scan the list of values
>      and implement the proper semantics.
> [...]
> %rec: Device
> %type: Tag enum dinglebop fleeb plubus grumbo
> You could write records with multiple Tags in two ways, as you suggest:
> Device: plumbus
> Tag: dinglebop
> Tag: fleeb
> Tag: plubus
> Tag: grumbo
> or:
> Device: plumbus
> Tag: dinglebop fleeb plubus grumbo
> (Note Tag no Tags)
> And then you could use the normal == or ~ operators like:
> Tag == "fleeb" || Tag == "grumbo"
> As I observe in my notes above, this would require to make ==, !=, <, >,
> ~ and the like aware of enumerated fields.

One question comes to mind. Should the != operator mean:
1. at least one enum value different than  or
2. none of enum tokens may be equal to the specified value.

The second one would be more intuitive and useful to me but one would
have to be very careful to produce same results for both
single-field-multi-enums, multi-field-single-enums and mixed variants.
Should they give same results? Should a normalization step be taken?

    Device: plumbus
    Tag: plubus
    Tag: dinglebop fleeb
    Tag: grumbo

to (only for enum fields):

    Device: plumbus
    Tag: plubus dinglebop fleeb grumbo

Currently, I cannot see any exclusion operator. For multi-field strings
neither 'Y!="y3"' nor '!(Y="y3")' will exclude a record if there is any
Y field that matches these conditions. So the second semantic variant
would give something new and interesting but also incompatible with the
current string semantics. Maybe then another operator would be useful
not to break backwards compatibility and keep semantics 1 for `!=`? To
minimize confusion the "in" operator would be allowed only for enums
(because of the unique normalization step).

Marcin Szewczyk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]