[Bro-Dev] #327: Binding attributes to values/variables

[Bro Tracker]

#327: Binding attributes to values/variables
------------------------+---------------------
 Reporter:  robin       |       Type:  Problem
   Status:  new         |   Priority:  Normal
Milestone:  Bro1.7      |  Component:  Bro
  Version:  git/master  |
------------------------+---------------------
 From Vern:

     In abstract terms, we need to marry two notions: per-variable
     attributes (those introduced when defining the variable) and
     per-value attributes (those introduced when creating a value).
     These both exist under-the-hood, but the rules for propagating
     them are ad hoc.

 I'm attaching the follow-up email thread with further thoughts on
 streamlining this.

 Robin

 [attachment:"None"]

 Did we ever reach resolution regarding the appended thread (from, um,
 a year ago!), or at least put something in the Tracker so we don't lose
 sight of it?

                 Vern

 [attachment:"None-1"]

 On Tue, Nov 03, 2009 at 17:25 -0800, you wrote:

 > In abstract terms, we need to marry two notions: per-variable attributes
 > (those introduced when defining the variable) and per-value attributes
 > (those introduced when creating a value).  These both exist under-the-
 hood,
 > but the rules for propagating them are ad hoc.

 This is something I've wondered about a few times already what the
 right thing to do is. The keyword at the moment is indeed "ad-hoc":
 I remember that a number of times I've been running into problems
 with propagating (or not propagating) attributes, and while I was
 always able to fix the immediate problem in some way, we don't have
 a clear system at the moment when that happens and when not.

 That said, I'm not really sure that this should ideally look like.
 Intuitively, I'd actually say attributes belong to values, not
 variables, because transfer-on-assignment can lead to subtle effects
 (values are passed around, and what if the receiving function
 happens to assign the value to the wrong variable?. Also what if you
 assign a value with attribute X to a variable without X; shouldn't
 the value then be *deleted* for consistency reasons?).

 If we accept for a moment that attributes belong only to values,
 then we can think about how to set them. A global definition such as

       const log_file = open_log_file("foo") &rotate_interval

 can be interpreted as assigning the attribute to the value returned
 from the function (more generaly to whatever what the assigned
 expression yields).

 We can use the "add foo &raw_output" syntax you suggested for adding
 attributes to the value of foo dynamically.

 A declaration such as

       const foo = F &redef;

 can be interpreted as "we can rebind foo if it's current value has
 the &redef attribute".

 I haven't thought this through actually but I guess my question is
 whether we need per-variable attributes at all?

 Robin

 [attachment:"None-2"]

 On Nov 4, 2009, at 7:54 PM, Robin Sommer wrote:

 >That said, I'm not really sure that this should ideally look like.
 >Intuitively, I'd actually say attributes belong to values, not
 >variables, because transfer-on-assignment can lead to subtle effects
 >(values are passed around, and what if the receiving function
 >happens to assign the value to the wrong variable?. Also what if you
 >assign a value with attribute X to a variable without X; shouldn't
 >the value then be *deleted* for consistency reasons?).

 Attributes being attached to value really seems to make sense.

 >If we accept for a moment that attributes belong only to values,
 >then we can think about how to set them. A global definition such as
 >
 >     const log_file = open_log_file("foo") &rotate_interval

 It works in this case, but this has typically been where trouble was
 encountered.  What about cases where there isn't a value assigned yet?
 Something like...

 const bad_addrs_with_description: table[addr] of string &redef
 &write_expire=10mins;

 There isn't a value yet, but it has an attribute applied to it.  Would
 that style still be supported?  It would seem to conflict with having only
 value attributes.

 Even for my database backed variable stuff I'm working on, it created a
 stumbling block.  What I'm doing internally is creating a copy of the
 value including attributes to a separate internal value when a query is
 being run.  That value is then filled from the database and the script
 level variable is rebound to my newly filled internal value and the old
 value is deleted.  I think that would be the right way to do it in this
 case even if only value attributes exist because it's an internal detail
 and the new value is being created internally, but it's certainly
 confusing sometimes.

   .Seth

 [attachment:"None-3"]

 On Wed, Nov 04, 2009 at 20:26 -0500, you wrote:

 > const bad_addrs_with_description: table[addr] of string &redef
 > &write_expire=10mins;
 >
 > There isn't a value yet, but it has an attribute applied to it.

 Actually there is: it's assigned an empty table. So, yes that would
 still work.

 What would be different however is a later assignment (redef for
 const [1]), which would ignore the &write_expire of the original
 definition and instead use the attributes from the assigned value.

 Robin

 [1] A "=" redef, not a "+=" redef which works on the original value.

 [attachment:"None-4"]

 On Nov 10, 2009, at 12:32 AM, Robin Sommer wrote:

 >What would be different however is a later assignment (redef for
 >const [1]), which would ignore the &write_expire of the original
 >definition and instead use the attributes from the assigned value.
 >
 >[1] A "=" redef, not a "+=" redef which works on the original value.


 Ah, ok.  This is all coming together for me now. :)

 Another question I have is if the change was made to allow attribute
 additions and deletions at runtime, does it sort of violate the concept of
 const?  const seems to tie together the value and variable together and
 make them unchangeable at runtime but it's a little confusing conceptually
 if you're able to still change the attributes of a const at runtime.

 Am I thinking about that right?

   .Seth

 [attachment:"None-5"]

 On Fri, Nov 13, 2009 at 13:24 -0500, you wrote:

 > Another question I have is if the change was made to allow attribute
 > additions and deletions at runtime, does it sort of violate the concept
 > of const?

 That's a good point, yes. Perhaps "const foo = xxx" should actually
 mean that the value xxx gets an (internal) attribute &const so that
 it's not changeable? And then assigning to a global with a current
 value that has the &const attribute would be prohibited as well.
 Does that make sense?

 Robin

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/327>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker