[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tail call elimination

From: Daniel Herring
Subject: Re: Tail call elimination
Date: Mon, 18 May 2020 21:40:04 -0400
User-agent: Alpine 2.21 (DEB 202 2017-01-01)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]