Inconsistent behavior of 'delete'

Inconsistent behavior of 'delete'

[Stone, Joshua I]

WAS: [Bug translator/2115] support some function calls on maps
fche at redhat dot com wrote:
> "clear" == "delete MAP"

I tried this out, and sure enough it works.  But, I noticed that it
currently only works in two specific cases: deleting one index from a
map of ints, or deleting an entire map (but not a pmap).

IMHO, 'delete' should just work for any (L-value) type of operand.
Deleting scalars (int, string, or stat) should reset them to their
initial state.  All map types should support deleting either individual
indices or the entire map, whether it's a map of ints or strings or a
pmap of stats.

Using 'delete' only really makes sense for globals, but if it's
implemented as suggested above, it might as well just work for local
ints and strings as well.  This is fine - my whole argument is to
maintain universal semantics.

I wrote a pass-4 script to try all of these cases (below), but I wanted
to make sure everyone agrees with my concept of 'delete' before I check
it in to the testsuite.  Right now this fails with an obscure message:
"terminate called after throwing an instance of 'semantic_error*'".

Comments?


Josh


PS: delete doesn't have any documentation in the map pages - the only
mention is in stapex(5) as somewhat of an aside.  Once we decide how it
should work, I can write that up for stap(1)...


pass-4 script: delete.stp
----------------------------------------
#! stap -p4

global a, b, c, d, e, f

probe begin {
    a = 1; delete a;
    b = "b"; delete b;
    c <<< 1; delete c;
    d[1] = 1; delete d[1]; delete d;
    e[1] = "e"; delete e[1]; delete e;
    f[1] <<< 1; delete f[1]; delete f;

    x = 1; delete x;
    y = "y"; delete y;
}

Re: Inconsistent behavior of 'delete'

[Martin Hunt]

On Fri, 2006-01-06 at 12:36 -0800, Stone, Joshua I wrote:
> WAS: [Bug translator/2115] support some function calls on maps
> fche at redhat dot com wrote:
> > "clear" == "delete MAP"
> 
> I tried this out, and sure enough it works.  But, I noticed that it
> currently only works in two specific cases: deleting one index from a
> map of ints, or deleting an entire map (but not a pmap).

Not working for pmaps is certainly a bug. It also needs to work for
stats. The rest is debatable, but probably desirable for consistency.

Should we consider changing the name to "clear" instead of "delete"?
For maps, delete actually deletes entries, freeing up memory. However,
that doesn't apply to other types.

Martin

Re: Inconsistent behavior of 'delete'

[Frank Ch. Eigler]

joshua.i.stone wrote:

> [...]  IMHO, 'delete' should just work for any (L-value) type of
> operand.  Deleting scalars (int, string, or stat) should reset them
> to their initial state.  [...]

The delete operator in systemtap was based on that of awk, which
operates on array elements, or optionally arrays, and like C++, is
intended to hint at memory deallocation implications.  I don't feel
strongly either way about whether it should be a "reset" for ordinary
scalar ints/strings.  Scalar stats would benefit from a reset
operation, assuming we actually have functioning scalar stats. :-(

- FChE

RE: Inconsistent behavior of 'delete'

[Stone, Joshua I]

Martin Hunt wrote:
> Not working for pmaps is certainly a bug. It also needs to work for
> stats. The rest is debatable, but probably desirable for consistency.

Agreed.  It also doesn't work for maps with string values, which is
definitely a bug.

> Should we consider changing the name to "clear" instead of "delete"?
> For maps, delete actually deletes entries, freeing up memory. However,
> that doesn't apply to other types.

As long as it's one or the other - I don't think "clear" and "delete"
should coexist.

From the user perspective, I think "clear" might be more meaningful.
One can read from uninitialized or deleted map indices and get a 0 or ""
as if it were cleared.  But the language has no concept of memory
management, so "delete" is really meaningless.  Manually clearing an
entry (e.g. assigning 0 or "") will also free memory, so that
distinction doesn't matter to the user.

Josh