> On Wed, Apr 25, 2018 at 10:40 -0700, you wrote:
> 
> >     s1 + s2         Set union (for sets of the same type, of course)
> >     s1 || s2        Set union
> 
> (What's the difference between the two? Or do you mean either one or
> the other?)

No difference.  It just seems to me that we need something for intersection,
and using existing operators, the natural for that is "&&".  Once we have
that, might as well support "||" for union.  But given symmetry with other
operators, "+" should work too.

> Like Justin, I was also thinking "|" and "&" might be more intuitive.

If we didn't have the keyword issue with &attributes, then I could see that.
But that strikes me as a significant drawback.  (Also, if we do add these,
then a user might reasonably expect them to work bitwise for count's.  We
could then consider implementing that too I guess.)

> other languages mgiht also coerce set operands into booleans in such a
> context, so that, e.g., "s1 || s2" evaluates to true if either is
> non-empty. 

Hey I don't care about other seriously busted languages! ;-)

> I see the problem with the parser but maybe adding keywords is the way
> to go.

Yuck.

> >     s += e          Add the element 'e' to set 's'
> >                             (same as the current "add s[e]")
> >     s -= e          Remove the 'e' element from 's', if present
> >                             (same as the current "delete s[e]")
> 
> I'd skip these. I don't think we should add an additional set of
> operators for things that Bro already supports

I actually feel the opposite, that "add" is clunky ("delete" a bit less so)
and thus these are more natural.  But in particular it seems we ought to
support these due to needing to support "v += e" (which is the one that
I most want!).

> >     s1 += s2        Same as "s1 = s1 + s2"
> 
> (Or s1 |= s2 if we pick "|" for union.)

Yeah, if we bite off the '&'-keyword ugliness.  Ugh.

> >     v += e          Append the element 'e' to the vector 'v'
> 
> That's probably the most requested Bro operator ever! :)

Yee-up, per my note above!

> >     v += s          Append the elements of 's' to the vector 'v',
> >                             with the order not being defined
> 
> This one I'm unsure about. The point about the order being undefined
> seems odd. If I don't care about order, wouldn't I stay with a set?

I do have a use case, but I agree it's odd; let me revisit it to see if
I really do need it.  I might instead settle for "vector of set[xxx]".

                Vern
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Reply via email to