Yes we do want make to be a first class language and have had to put up with it being a b*** a*** to do computations and impossibly slow to use $shell.
Regards, Tim On Mon, 11 May 2020, 20:47 Daniel Herring, <dherr...@ll.mit.edu> wrote: > 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. > > > > > >
