Re: [RFC] Scoped variables, supercharged

[Jouke Witteveen]

On Fri, Dec 27, 2019 at 4:29 PM <address@hidden> wrote:
>
> Jouke Witteveen writes:
>  > On Thu, Dec 26, 2019 at 10:52 PM Paul Smith <address@hidden> wrote:
>  > >
>
>  <snip>
>
>  > > I believe thutt is thinking of creating new scopes in makefiles 
> themselves,
>  > > not within a variable/function context, for example within included
>  > > makefiles or even within subsections of a particular makefile.
>
>  Yes.

Well, this request is not that ;-). Maybe it can help with it and make
something like it possible through some clever construct, but it was
designed purely for lexical scoping.

>  > Ah, now I understand. With $(let), the scope is determined by the
>  > parentheses, but theoretically, a file-scope could be a thing too.
>  >
>  > > For example something where you could say:
>  > >
>  > >    FOO = bar
>  > >
>  > >    push scope
>  > >    local FOO = baz
>  > >
>  > >    $(FOO): blah
>  > >    pop scope
>  > >
>  > >    $(FOO): yuck
>  > >
>  > > Of course if you wanted to write a bunch of define/endif stuff and use 
> eval
>  > > you could use $(let ...) to do something like this but it can get pretty
>  > > gross.
>  >
>  > Let's run a little test. I have a Makefile containing:
>  > ----
>  > X=global
>  > $(let X,local,$(eval include inc.mk))
>  > $(info $X)
>  > ----
>  > And a file callend inc.mk containing:
>  > ----
>  > $(info $X)
>  > X=included
>  > $(info $X)
>  > ----
>  > We can see what happens even without recompiling make by replacing the
>  > instance of $(let) by $(foreach). The resulting behavior is the same
>  > (because 'local' is only one word). We get the following:
>  > ----
>  > $ make
>  > local
>  > local
>  > included
>  > ----
>
>  Interesting.  I'd like to raise a few points.
>
>  o I would find it objectionable to have to $(eval) the include of
>    files to gain scoping.  At the very least, this would adversely
>    affect the readability of Makefiles.

These experiments were meant to test $(let), not to show any advisable
use of it. At least, that was my understanding of the suggestions by
Paul Smith. The points I was trying to make are that
1) the scope stack can act differently from what you expect, and
2) the obvious shortcomings of $(let) are also shortcomings of $(foreach).

>  o I don't think this meachanism correctly captures scoping.  The
>    state of $(X) can be set by the master Makefile, or by an include
>    file.  Furthermore, it can be changed by another included file.

$(let) provides lexical scoping in line with the use of let
expressions in other languages. The binding occurs at the time of
expansion. After expansion, the expression is fully expanded and the
scoped variables have completely disappeared.

>    But, the actual use of $(X) in a recipe can be deferred to much
>    later.  If there are several locations that set $(X) to a different
>    value, what value will be used when the recipe is expanded?
>
>  <snip>
>
>  > One way to think of why $(let) would be a reasonable addition to make
>  > is precisely because it does not deviate from established behavior too
>  > much. Yet, it provides a clear value. Outside of the scoping, it also
>  > enables basic list unpacking similar to `read` in the shell. My
>  > example with reverse demonstrates this aspect too.
>
>  I agree that there is a clear value.  But I still caution that it
>  should not be confused with full semantic scoping in a whole build
>  system implemented in Make.

I am not sure what you mean by 'full semantic scoping', but I do feel
that you try to make of $(let) something that it is not. I am sure you
are aware that you can give variables target-specific values. This may
be of use when one build system is used for targets on multiple
platforms. Also, make is very liberal in its variable names, so with
proper hygiene and discipline, you can append some namespace-like
prefix to all the variables used in a file.

Regards,
- Jouke