Re: Proposed change to default variable scoping

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-26 15:20:50

I just spent hours trying to implement this, and I think I'm finding out
that the idea is not yet fully-baked. The main problem is the crazy
dynamic scoping:

# baz.jam
x = BOOM ;

# foo.jam
module A
{
module B
{
x = 1 ;
rule foo ( ) { y = 1 ; }
}

rule bar ( )
{
y = BANG ;
B.foo ;
ECHO $(y) ; # what gets printed?

local x = 9 ;
import baz ;
ECHO $(x) ; # what gets printed?
}
}

If we can decide on reasonable semantics, I can implement them...

-Dave

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>

> Here's the tail of a conversation Rene and I have been having about
the
> default variable scoping in Boost.Jam. Right now we have three types
of
> variables:
>
> local, global, and module-local. The latter are not used in
Boost.Build
> v1 (since we don't use modules -- or rather, we only use the global
> module). Rene and I are proposing that we change the semantics of
> variables declared without "local" so that they are local to the
current
> module. Hey, that would also get rid of the need for the "module
local"
> declaration syntax! Hooray!
>
> If you have objections to this move, now is the time to speak up!
>
> -Dave
>
> ----- Original Message -----
> From: "Rene Rivera" <grafik666_at_[hidden]>
> To: "David Abrahams" <david.abrahams_at_[hidden]>
> Sent: Monday, March 25, 2002 1:01 PM
> Subject: Re: Still failing with Linux/GCC
>
>
> > On 2002-03-25 at 12:35 PM, david.abrahams_at_[hidden] (David Abrahams)
> wrote:
> >
> > >Let me get this straight: you want variables to default to local,
or
> to
> > >module local?
> >
> > module local.
> >
> > >I hate that Perforce made variables global by default, but
> > >since they did I don't think a construct which flips the default
> meaning
> > >to scope-local would be appropriate, especially given the dynamic
> > >scoping rules: it would change the meaning of called functions too
> > >drastically.
> > >
> > >On the other hand, getting rid of globals and making everything
> > >module-local by default (with no local { ... } ) construct makes
some
> > >sense to me as a backwardly-compatible change. To set a "global"
> > >variable, you would simply switch to the global module:
> > >
> > >rule set-global ( name : value * )
> > >{
> > > module { $($(<)) = $(>); }
> > >}
> >
> > Makes sense to me :-) And given that it adds a form of code
> documentation
> > indicating where we are modifying globals it's even desirable.
> >
> > >Could you explain more precisely what problem you're speaking of,
> what
> > >functionality you're after, and how it would help?
> >
> > The problem I'm facing is that when we include a new Jamfile I have
to
> go
> > search for it's corresponding project-root.jam. This is so we can
> support
> > cross-project dependencies. But different project-roots will very
> likely use
> > the same variables with different values, the immediate one is
> PROJECT_ROOT
> > and it's expected that constructs within a project, even when
included
> from
> > another, work with the local versions. That also applies to things
> like paths.
> >
> > It would help in that I could wrap the corresponding includes in a
> > corresponding project module. This way the variables within the
> project get
> > scoped to the project module. No collisions and multiple projects
can
> coexist.
> >
> >
> > -- grafik - Don't Assume Anything
> > -- rrivera_at_[hidden] - grafik_at_[hidden]
> > -- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]
>