Re: Tail call elimination

[Daniel Herring]

Hi Pete,

I like your enthusiasm and understand the benefit.  If this can be 
done cleanly, then why not?

However, I am still vaguely uneasy about the idea.  I don't think Make 
will ever be a first-class programming language.  Prolog was a better 
general-purpose language, but more people use Make because it is a 
domain-specific tool.  Traditional Make has a certain simplicity that 
makes it fairly easy to read and to machine generate.  As Make becomes 
Turing-complete, it may loose these properties and grow in complexity.

How would you debug this?  Do parallel builds?  Do distributed builds? 
Optimize build times?  etc.


Maybe it would be more useful to develop a protocol for invoking external 
programs and including their results in the build rules?  Something like 
the support for generating build dependencies, with cleaner semantics and 
a direct way to run multiple times in a build.  For example, when a code 
generator like Qt's moc or uic is run, it could also generate a rule 
update that causes Make to compile and link the results.

This might give full general semantics (invoke your language of choice) 
while preserving simplicity (communicate simple Make rules).

If we do want Make to be Turing-complete, then it may be better to link in 
an embedded language (Guile, Lua, Python, ...), rather than building a new 
ad-hoc language.

- Daniel


On Mon, 11 May 2020, Pete Dietl wrote:

> What do you all think about me attempting to implementing tail call elimination 
> for recursive make functions? This combined with the proposed (let) construct 
> would be rather powerful.
>
> I did the first 10 exercises in Advent of Code 2019 in Make. but ran into 
> problems with blowing the stack from recursion.