Re: Dropping "call" operator?

[Kaz Kylheku]

On 2024-03-24 13:59, Paul Smith wrote:
> On Wed, 2023-12-27 at 21:45 -0800, Kaz Kylheku wrote:
>> What would be wrong with allowing the $(call ...) operator to be
>> elided?
>>
>> Instead $(call macro,a,b,c), why can't we have $(macro a,b,c), if
>> macro doesn't shadow a built-in function?
>>
>> When there are no arguments, we cal invoke it as $(macro), but when
>> there are arguments $(call ...) must be used.
>>
>> The presence of arguments can be used to deduce that a macro call
>> with arguments is to take place.
> 
> I have considered doing this, but only AFTER it becomes an error (not
> just a warning) to create a make variable with whitespace in the name.

Could you elaborate? How recent of a gmake do we need for this diagnostic?
Is there another way to create variables with spaces other than something like:

  VARSP := a b c
  $(VARSP) = value
  $(info $(a b c)) # produces "value"

for which lines should there be a diagnostic, using what GNU make versions
and options, if any? Sorry for appearing lazy, I will independently check
this myself. 4.3 is silent, so far. I have some newer installation kicking
around, as well as some project directories from past make hacking.

Anyway, so if $(call ...) can be dropped, we have the ambiguity
$(a b) refers to an "a b" variable, or invokes an "a" macro with
argument "b". I'm taking it for granted that there is some kind of warning,
suggesting that creating a variable with whitespace is a dubious construct
that is deprecated.

There is a second problem. It appears that variable names /with embedded
commas/ are allowed. Given:

  FOO = A B C
  BAR = A B C,

  $(FOO) = FOOVAL
  $(BAR) = BARVAL

  $(info $(A B C))
  $(info $(A B C,))

I get FOOBAR and BARVAL being printed by $(info ...). It appears that
$(A B C,) treats "A B C," as a name, which corresponds to a variable
that was created by $(BAR) = BARVAL.

In the following remarks, I'm going to pretend I didn't see
the above.

There are ways to introduce dropping the call operator, while keeping
variables with whitespace in the same deprecated status, so they
continue to work as before.

Note: in the following descriptions, I'm assuming that $(call X) has
the same meaning as $(X) when no commas are present in X.
I'm relying on $(call ...) notation as the target language
for indicating semantics.

The following table gives possible rules for handling a variable
reference containing spaces:

  commas present  variable exists  treatment  example
     
  no              yes              variable   $(a b c) -> $(call a b c)
                                              $(a b)   -> $(call a b)

  no              no               macro      $(a b c) -> $(call a,b c)
                                              $(a b)   -> $(call a,b)

  yes             --               macro      $(a b c,) -> $(call a,b c)
                                              $(a b,c)  -> $(call a,b,c)
                                              $(a,b,c)  -> ??? improper form

Notes:

- When commas are present, spaces in the name are unsupported; the name
is the token before the first space; everything after that is comma
separated args.

- The "variable exists" test applies to everything in the parentheses.
If that doesn't exist, the token before the first space is tried
as the variable; everything after that is one argument.

Another different idea is to literally just drop call, without shuffling
commas around:

   $(call a,b,c)   becomes  $(a,b,c)   rather than   $(a b,c)

Pro: easy, error-resistant conversion between old and new call formats.

Con: macro calls don't look like built-in operator calls: $(op arg1,arg2,...).