syntax consistency question

Development
1

set[string]
and
vector of string

Why do these have such differing syntaxes? I understand that internally vectors are really much more similar to tables than sets, but in usage they're more equivalent to an ordered set than a table (in my mind at least). If we add FIFO-type operations to vectors so that they're easier to work with, they would feel even more like ordered sets. For example, using a totally made up code snippet...

global stuff: vector[string] = vector();
enqueue stuff["foo"];
enqueue stuff["bar"];
print |stuff|;
  ==> 2
print dequeue stuff;
  ==> foo
print dequeue stuff;
  ==> bar
print |stuff|;
  ==> 0

Although it's essentially used as a FIFO here, it's still feels sort of set-y. BTW, this code or something like it working would be awesome. :slight_smile:

  .Seth

2

Yeah, I also discovered that vectors are kinda limited in their
functionality. I think it would be great to have two different data
types in Bro. Possibly both supporting the same.

* array or vector (pretty much like the current vector type):
  + O(1) random element access
  + O(1) (armotized) adding to / removing from *end*
  + O(n) adding to / removing from *beginning*
  + grows (shrinks?) dynamically.

* queue, deque (for FIFOs, stacks, etc)
  + O(n) random element access
  + O(1) adding/removing from *either end*

cu
Gregor

3

Don't really like this syntax but also don't see another more
intuitive operator. Could we just add more built-ins for vector
operations like these? (e.g., vector_dequeue(v)). As usual,
type-safety would be a problem though.

Robin

4

Or more generally, lists. I agree, but adding that is a major task, I
don't see that near-term. Perhaps for the 1.7 timeline?

Robin

5

sounds good to me

6

Me too.

  .Seth

7

Another vector wish list item: can we please make them zero-based? I
propose to do that immediately while we're working on scripts anyway.

Robin

8

Seems reasonable to me.

  .Seth

9

IIRC, there's a #define that decides whether it's 0 or 1. (And yes, 0
based seems great). IIRC, 0 might be used as a special value in C++ code
but I'm not sure....

cu
gregor

10

Right, technically the change is trivial, I was mainly looking for a
consensus. Seem we have one.

Robin

11

Right, technically the change is trivial, I was mainly looking for a
consensus. Seem we have one.

Well, depends on how you define consensus. I prefer indexing to start
with 1. I think use of 0-basing is a holdover from C's too-low-level model
equating arrays with pointers.

But given I'm the lone holdout, and vectors aren't something we've used
much, I'm not going to fight hard. However, I can picture an attribute
&base=1 or whatever to re-base particular vectors.

    Vern

12

Well, depends on how you define consensus.

Defined as "hearing no objections so far". :slight_smile:

I prefer indexing to start with 1. I think use of 0-basing is a
holdover from C's too-low-level model equating arrays with pointers.

Maybe, but it's so common also with many other languages that I find
it not worth the confusion that a different base causes.

much, I'm not going to fight hard. However, I can picture an attribute
&base=1 or whatever to re-base particular vectors.

Oh, please not. That would be even worse because now one has to check
everytime whether a vector has that attribute.

Robin