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

[Jose E. Marchesi]

>> [...]
>>    - 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?
> Like:
>
>     Device: plumbus
>     Tag: plubus
>     Tag: dinglebop fleeb
>     Tag: grumbo
>
> to (only for enum fields):
>
>     Device: plumbus
>     Tag: plubus dinglebop fleeb grumbo

I would say we clearly want 2. for the semantics of != when applied to
enumerated fields.  Normalizing is indeed necessary.

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

Hmm, I don't think don't need to keep the existing string semantics for
enums, because in properly conformed data each Tag are restricted to
have only one of the valid values, i.e.:

--- foo.rec ---
%rec: Device
%type: Tag enum dinglebop fleeb plubus grumbo

Device: plumbus
Tag: dinglebop fleeb plubus grumbo
--- end of foo.rec ---

$ recfix foo.rec
foo.rec:5: error: invalid enum value.