Re: Why call is not calling like native primitives? even when var is otherwise undef?

[Garreau\, Alexandre]

On 2018-05-21 at 12:17, Kyle Rose wrote:
>> On 2018-05-21 at 07:46, Kyle Rose wrote:
>>> $(call x) rebinds the positional parameters. $x and $(x) do
>>> not. This distinction is used to break macro logic into smaller
>>> pieces in which $1 et al. still refer to the positional parameters
>>> from the top-level macro instead of being rebound to the empty
>>> string.
>>
>> My suggestion was for only variable names containing a space, so $(x)
>> would keep legacy behavior, while $(x y) would work as any function
>> call.
>
> I've had the same thought myself. This would probably work, but it needs to
> do something consistent and understandable in cases like these:
>
> $(fn) <= variable evaluation
> $(fn literal) <= macro expansion
> $(fn $x) <= macro expansion, even if $x is empty
> $(fn ) <= ?? maybe macro expansion?

I think we should ask Paul how did he see it himself.  Personally,
following the idea of disallowing variable names with spaces (which
aren’t easy creating anymore) $(fn ) would stay a variable evaluation,
and either we let $(N) be possibly bound to the void string, possibly
allowing to be rebound if used in another macro, either we try to unify
something by always binding $(0) to the variable name, but then that
would break legacy behavior when you compose a macro from several other
macros…