Binding attributes to values/variables

Description

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

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

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

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

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.

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

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

Environment

None

Assignee

Unassigned

Reporter

Robin Sommer

Labels

None

External issue ID

327

Components

Affects versions

Priority

Normal
Configure