Re: 6.2 The Two Flavors of Variables

[Philip Guenther]

On Thu, Feb 24, 2011 at 4:19 PM, grischka <address@hidden> wrote:
> Paul Smith wrote:
...
>> You may consider it so, but along with the use of TABs to prefix recipe
>> lines you must blame the inventors of the original make, back in the
>> 1970's, and also of course the writers of the POSIX spec.  This is the
>> one and only type of variable that is defined and supported in those
>> makes and so it must be defined and supported this way in GNU make.
>
> POSIX doesn't talk about "recursive variables".  POSIX just requires
> lazy evaluation of what it calls "macros".

And it places no requirements on how they are described by the
documentation.  So?


> Even less does POSIX require or even suggest a second flavor of non-
> POSIX-compliant variables to work around a flaw with the normal
> variables.

To be clear, the fact that GNU make has this second flavor of variable
does not render it non-compliant.  Any makefile that uses them has
violated a 'shall' clause of the standard and therefore its behavior
is undefined by the standard.  Ergo, they are a permitted extension of
the standard.

>From your statement, however, I gather you find the
variables---sorry--the macros specified by the POSIX standard to be
flawed.  Righto.  So, I take it that you're either working to extend
POSIX (there was that recent exchange on the austin-group mailing list
about variable flavors...) or don't care about POSIX.  Can you please
clarify your position?


...
> Lazy macro evaluation exists elsewhere too (for example in C preprocessors).
> Still I've never seen the term "recursive variables" in any context
> other than with gnu-make and then always to explain why it doesn't work
> as people expect.

Yes, many people try to use make as a procedural language when it was
originally just a declarative language.  Simply expanded variables
move it more towards the former, but I think you cannot eliminate the
basic declarative aspect of the rules without changing it to something
that most people wouldn't recognize as "make".

(I suspect part of the problem is that that it is the only declarative
language that many current programmers experience.  Maybe if more
people experienced Haskell, or Prolog, or (ha!) Metafont this wouldn't
be an issue...)


>> Does each instance of the variable start at the "top" of the expansion, so
>> that each instance requires its own pointer into the stack of potential
>> values?
>
> No.  You don't run expansion on instances of variables but you enter
> an instance of expansion for a certain variable.  Think of the function
> that takes a variable name and returns the expanded string:  It only
> ever deals with a single variable at the same time.
>
> This function increments the "expansion-level" of the variable on
> entrance and decrements it before it returns.  The end condition
> for recursion is represented by the maximum level which is equal to
> the number of assignments made to this variable in the makefile.
...

IMO, implementing and usability testing of this would actually make a
good subject for a USENIX paper.


Philip Guenther