set and vector operators

Development
21

One additional piece of context here: That vector(...) syntax could
then be used more broadly in the sense of creating a different
semantic context for the operations inside. That kind of opens up a
whole new set of of type-specific operator meanings, without affecting
current/standard ones (it's like introducing R inside parentheses :-).

Yeah, framing it as type-specific operators makes sense.

It's not the super-great, but at least it's explicit and we couldn't
come up with anything better if we want to have such operations as
operators. Might work for some other types as well.

Isn't the existing "v + e" an alternative that one could say is "better" ? Other languages also take that to mean "vectorized/array operation".

I think for Bro, it's just that vectorized/array operations will be a less common use-case than appending and so there's incentive to make the later more succinct?

Just to put it out there again: I wouldn't mind something like "append(v, e)" and leaving the existing vector operations like "v + e" alone. It may make the common case more verbose, though there's also less ambiguities.

- Jon

22

That still seems odd to me. If "v += e" means "append", then I might
expect "v + e" to do the same, except producing a new value w/ original
vector not modified.

Yeah, I agree with that actually. Getting rid of the current "v + e"
semantics (which nobody knows/uses anyways) means we can turn both '+'
und '+=' into add-element-to-vector operations. Question is if we want
to do that right away, or wait for a version for deprecating/flagging
current usage of "v + e" (although I doubt there's any!)

Isn't the existing "v + e" an alternative that one could say is "better" ?

Only if we don't want "+" to mean "append element to vector". If we
switch '+' to meaning that, then there's nothing good left for the
operation "add e to all vector elements". And the "append" operation
indeed seems more common in Bro than the element-wise operation, so
I'd prefer switching.

Just to put it out there again: I wouldn't mind something like "append(v, e)"

I don't really like the free function style very much, what I could
see is using methods: "v.append(e)". I actually like that style quite
a bit. But as I said to Vern last week, it'd be a bit odd to introduce
that pattern to Bro now, we don't use that style anywhere else. May be
just too late for starting that.

Robin

23

1.5 months ago we haggled over adding these and came close to converging,
and then I dropped the ball on trying to ice the deal :-(. (Well, I also
needed some time to lick my wounds, since I didn't get my way much on
syntax preferences! :-P)

Here's where I believe we wound up:

(1) Add bitwise operators on "count" variables for &, | and ~.

(2) Deprecate element-wise arithmetic operations on vectors, such
    as "v * 3" meaning "multiply each element of v by 3". Perhaps down
    the road we'll introduce syntax that flags things like "for this
    expression, vectorize it".

(3) Implement "v += e" to mean "append the element e to the vector v".

(4) Wait on whether "v + e" should mean "return a vector that is v with
    the element e appended". (And indeed we can't do this right now if
    we're #2.)

(5) Keep "add" and "delete" for manipulating sets in terms of individual
    elements.

(6) Add "s1 & s2", "s1 | s2", and "s1 - s2" as intersection, union,
    and set difference.

I'm not clear whether we reached agreement on:

(7?) Add "s1 &= s2" etc. to mean "s1 = s1 & s2". The advantage of
     having this as an operator is it might more easily enable efficient
     implementation of some set operations for big sets. I suppose
     if we have it then we'd be expected to also have:
  (7') "c1 &= c2" etc., i.e., bitwise assignments for "count"
       variables.

Please chime in if you remember where we wound up differently, and also
whether you disagree with #7.

Again, my apologies for the lengthy lull in attending to this thread.

    Vern

24

(3) Implement "v += e" to mean "append the element e to the vector v".

Do we want to do this now, or should we potentially wait a release-cycle
with it (to prevent the situation where v + e and v+= e means something
different).

Looking at the emails I am generally not 100% sure if we reached consensus
on this one.

(4) Wait on whether "v + e" should mean "return a vector that is v with
    the element e appended". (And indeed we can't do this right now if
    we're #2.)

Yup.

I'm not clear whether we reached agreement on:

(7?) Add "s1 &= s2" etc. to mean "s1 = s1 & s2". The advantage of
     having this as an operator is it might more easily enable efficient
     implementation of some set operations for big sets. I suppose
     if we have it then we'd be expected to also have:
  (7') "c1 &= c2" etc., i.e., bitwise assignments for "count"
       variables.

They were contained in the "minimal" list that Jon came up with. I think I
would be ok with them, but they did not really get any discussion
afterwards that I can see.

Johanna

25

(1) Add bitwise operators on "count" variables for &, | and ~.

Yeah, looks like everyone was in favor of those.

(2) Deprecate element-wise arithmetic operations on vectors, such
    as "v * 3" meaning "multiply each element of v by 3". Perhaps down
    the road we'll introduce syntax that flags things like "for this
    expression, vectorize it".

(3) Implement "v += e" to mean "append the element e to the vector v".

(4) Wait on whether "v + e" should mean "return a vector that is v with
    the element e appended". (And indeed we can't do this right now if
    we're #2.)

This sounds like what everyone was thinking. My suggestion for the
timing of these would be to implement the deprecation (2) by itself
ASAP, at least before the 2.6 release, and shortly after 2.6 it can be
removed in git/master and both (3) and (4) done. Hopefully 2.6 is not
terribly far away.

(5) Keep "add" and "delete" for manipulating sets in terms of individual
    elements.

(6) Add "s1 & s2", "s1 | s2", and "s1 - s2" as intersection, union,
    and set difference.

Yeah, sounds right.

I'm not clear whether we reached agreement on:

(7?) Add "s1 &= s2" etc. to mean "s1 = s1 & s2". The advantage of
     having this as an operator is it might more easily enable efficient
     implementation of some set operations for big sets. I suppose
     if we have it then we'd be expected to also have:
        (7') "c1 &= c2" etc., i.e., bitwise assignments for "count"
             variables.

Please chime in if you remember where we wound up differently, and also
whether you disagree with #7.

I don't see much previous discussion around these, though they all
make sense to me.

- Jon

26

> (3) Implement "v += e" to mean "append the element e to the vector v".

Do we want to do this now, or should we potentially wait a release-cycle
with it (to prevent the situation where v + e and v+= e means something
different).

Turns out that "v += e" currently generates an error ("requires two
arithmetic or two string operands"), so it seems safe to me to introduce
it as append-to-vector concurrent with deprecating "v + e" (which from the
discussion on the list it seems likely current has little or no use).

BTW, "v1 += v2" likewise generates an error, even when "v1 + v2" works.

    Vern

27

Yeah, seems fine for v += e and v + e to temporarily have different
meanings given that the later will, for some time, have a clear
deprecation/warning message for each use (in any rare cases where it
might actually be used). So my current POV is everything you outlined
looks good to do whenever.

- Jon