Re: New scope checking patch

["Rob Quill" <rob dot quill at gmail dot com>]

2008/7/29 Tom Tromey <tromey@redhat.com>:
> Rob> If this patch it implemented as an internal function, what is to
> Rob> stop someone passing an expression to $in_scope(), in which case,
> Rob> does the patch need to be able to determine if a whole expression
> Rob> is in scope?
>
> In the internal-function form, in_scope would take a string-valued
> argument.  So, the expression would be evaluated first -- just like
> any other function argument -- and then passed to the in_scope
> primitive.
>
> I guess this would prevent easy checking of whether an entire
> expression is in scope.  (BTW does that mean just checking all the
> names in the expression?)

Yep. Exactly. I just checked and found I had discussed the problem I
had in the first post in this thread.

"There is a caveat with the patch which is as follows. If a variable is
not in scope then the expression parser in c-exp.y inserts a value 0
into the expression tree. When the scope checking function sees a 0
expression in the tree it will return 0, to indicate not in scope.
However, in the general case it should be true that all literals are
in scope. However, due to the above caveat $in_scope(0) will return 0,
any any other literal will return 1.

This also affects compound expressions that involve the literal 0. For
example, $in_scope(0+3) will return 0, as an expression with a binary
operator is considering in scope iff both of its operands are in
scope."

Obviously this disappears though with the current patch as it can't
deal with compound expressions.

Rob