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

[Jose E. Marchesi]

Hi Marcin!

> I would like to propose an additional "in" operator which would treat
> field's string value as a space-separated list and check if the
> specified token is present.
>
> I know that fully normalized relational databases would look like this:
>
>     Device: plumbus
>     Tag: dinglebop
>     Tag: fleeb
>     Tag: plubus
>     Tag: grumbo
>
> But it might be quicker to use when constructed in the following manner:
>
>     Device: plumbus
>     Tags: dinglebop fleeb plubus grumbo

I already considered adding something like this.  These are my notes:

* Multi-valued enum fields                                          :PROJECT:
** Purpose

   It is common to have several "enumerated" fields in a single record.  For
   example, the entities impacted by a bug report in a bug tracking system:

     Id: 102
     Title: The timing of load instructions is missing cycles.
     Entity: ERC32
     Entity: LEON2
     Entity: LEON3

   The verbosity is a bit too much, which leads to big records and can impact
   readability.

** Outcome

   The usage of lists of enumerated values is allowed.  The values are
   separated by one or more blank characters.  For example:

     Id: 102
     Title: The timing of load instructions is missing cycles.
     Entity: ERC32 LEON2 LEON3

   Commas, which are ignored, can be optionally used as well:

     Entity: ERC32, LEON2, LEON3

** Impact

   The support of multi-valued enumerated fields would have the following impact
   in recutils:

   - 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.

Your 'in' operator seems to be a step in this direction, but if I
remember well I originally intended this to be transparent given the
field is declared as an Enum, i.e., to this record type:

%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.

Supporting commas was mainly in order to ease supporting the Debian
package format...