> A nice thing about "add" and "delete" for sets is that you can infer the 
> data type that you're operating on just looking at the local code/line. 

Only sort of.  For delete, you don't know whether it's a table or a set,
and for neither do you know what type of table/set if you can't immediately
apprehend the type of the index (e.g., "delete foo[foo2]" doesn't tell
me what type of index the set/table foo uses).

> E.g. say you come back to some code after a few months and see "foo += 
> 1".  Not obvious what 'foo' is anymore.

I don't think it's reasonable to have the bar be "can you tell what's going
on in isolation".  It should include consideration of associated context,
variable names, and comments.  In fact, even now you don't know whether
for "foo += 1" foo is an integer, a count, or a double.

> I do also notice that you had "s + e" in the proposal and not "v + e". 
> Isn't that weird by the same logic or is it just an accidental omission?

This is because "v + e" already has a meaning: apply "+ e" to each element
of v.  (Note though that "v += e" is not currently allowed.)

>      v += e               Append element to vector
> 
> And for that, a BiF or generic script-layer function call (if that were 
> possible) would even make me happy:
> 
>      push(v, e)
> ...
>      add_to_set(s, v)
>      delete_from_set(s, v)

Yuck.  I would hate this.  Might as well use Lisp!

A basic tenet of Bro's language design has been to minimize verbosity.
(For example, its use of type inference, and its support of C-style
operators like "++".)  Let's please not move in that direction.

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

Reply via email to