Re: undefine

Hi Paul,

Paul D. Smith <[email protected]> writes:

> There are other questions here of course.  Do we need a new keyword to
> mark a variable as local to the scope?

I think the first question should be whether a scope behaves like
a "stack scope" so that once the scope is "popped" all its variables
a gone (similar to automatic variables in C) or like a "namespace
scope" so that all the variables defined in the scope are preserved 
(similar to global variables in C++ namespaces).

If we choose the first approach then it is not clear what happens
when such a scoped variable is referenced from a global recursive
variable or from a rule, e.g.,

FOO = foo
<start scope>
  BAR = bar
  ::FOO = $(BAR)

  foo:
	@echo $(BAR)
<end scope>
# What's the value of BAR here?

The second approach seems more natural for the GNU make model. The 
only problem is that the scopes would probably need to be named and
it might be hard to come up with names that don't conflict. To resolve
this we could allow "unnamed" scopes (in which case make will come up
with a unique name).


> 	FOO = foo
> 	<new scope>
> 		FOO = fum
> 		BAR = baz $(FOO) boz
> 	<end scope>
> 
> Now what's the value of $(FOO)?

Using my second model, this is pretty simple: global FOO has value 'foo'.
FOO in the unnamed scope has value 'fum'.  BAR in the unnamed scope
references FOO from the unnamed scope. We can add some more interesting
stuff:

all: foo bar

FOO = foo
<new scope>
  FOO = fum
  BAR = baz $(FOO) boz

  bar: ;echo $(BAR)
<end scope>

foo: ;echo $(FOO)

This makefile would print:

foo
baz fum boz


> Maybe we could repurpose the new "private" keyword to mean "local to
> this scope".

I think a variable is by definition local to the scope. If we have
named scopes and can qualify variable names with scope names, then we
can refer to global/scoped variables within any scope as we please
as long as we know the name. For example:

FOO = foo

my {
  ::FOO = bar # Set global FOO
  BAR = baz $(::FOO) boz
}

BAR = $(my::BAR)


> I guess, symbols like braces or something

I think this is a very good idea.


Anyway, I got carried away a bit ;-). I will go ahead and implement
undefine for the time being, then.


Boris