Re: Tail call elimination

[Daniel Herring]

On Mon, 18 May 2020, Paul Smith wrote:

> > This is also an objection against $(eq) and $(not), which are hidden
> > behind the EXPERIMENTAL compilation flag.
>
> It doesn't matter what the output is, IMO.  Boolean expressions in GNU
> make are quite trivial: empty string is false, anything else is true.
>
> So any comparison operator simply has to expand to the empty string for
> false any any non-empty value for true.  That could be a pre-defined
> value like "t" (for lispy folks) or "true" or we could arbitrarily
> choose one of the operands or whatever.


Hi Paul,

As you state, traditional languages aliased "empty" values to mean false. 
Lisp used the empty list, NIL.  C used the integer/pointer value 0.  etc.

This decision causes a difficult and error-prone ambiguity when the return 
value is really true and empty.  For example, the operation succeeded and 
the result was "", versus the operation failed and thus returned "".  So 
Scheme added separate #t and #f values, C++ added true and false keywords, 
newer languages are adding an "optional/maybe" construct, etc.

The present Make behavior is perfect for things like dependency lists. 
However, it feels limiting for other use cases.

If we cannot change this without breaking existing Makefiles, then could 
we add new features instead?

- Daniel