RE: New conditional assignm ent facility

[rsbecker]

On Monday, January 29, 2024 5:18 AM, Edward Welbourne wrote:
>rsbec...@nexbridge.com (27 January 2024 23:45) wrote:
>> My take on it is that +:= (because of the : ) means that you have to
resolve
>everything at that point.
>
>Surely it could equally mean: fully expand the right-hand side immediately,
append
>to the left-hand variable, preserving its type if set, else making it
immediate.  Then,
>if it was previously deferred-evaluation, its prior value remains
deferred-evaluated -
>only the part appended is evaluated right away.

I think we are saying the same thing.

Re: New conditional assignm ent facility

[Edward Welbourne]

rsbec...@nexbridge.com (27 January 2024 23:45) wrote:
> My take on it is that +:= (because of the : ) means that you have to resolve 
> everything at that point.

Surely it could equally mean: fully expand the right-hand side
immediately, append to the left-hand variable, preserving its type if
set, else making it immediate.  Then, if it was previously
deferred-evaluation, its prior value remains deferred-evaluated - only
the part appended is evaluated right away.

Eddy.

Re: New conditional assignment facility

[Edward Welbourne]

Paul Smith (27 January 2024 21:32) wrote:
> I'm interested in peoples' opinions about which of these two
> implementations they would feel to be more "intuitive" or "correct".
> Also please consider issues of "action at a distance" where a variable
> is assigned in one makefile and appended to in some other makefile,
> potentially far away.

A naive C-programmer approach starts from

  x += y

in C meaning the same as

  x = x + y

This leads to an "intuitive" approach being to have

  x +:= y

mean

  x := $(x) y

in make, with analogous statements for each of the other increment
operators.  IIRC, that runs into trouble because plain x += y has
already been implemented and preserves the type of x, rather than
revising it to be recursive evaluation.  Then again,

  x = $(x) y

would be problematic in any case, since $(x) would then be an infinite
recursion.  That's an argument for += to get special treatment.

Perhaps it would be useful to enumerate the other types of assignment
(I'm unfamiliar with the ones beyond = and := myself) and describe what
putting a $(x) to the right of each (as replacement for a + before it,
when x is the left-hand operand) would do and what problems each would
pose.  That might give some clarity to the options.  In particular,
given that it's immediately clear what

  x := $(x) y

does, having +:= do the same thing is semi-redundant.

Eddy.