bug-make
[Top][All Lists]
Advanced

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

math expressions (was: Re: Tail call elimination)


From: Paul Smith
Subject: math expressions (was: Re: Tail call elimination)
Date: Sat, 23 May 2020 16:31:37 -0400

On Fri, 2020-05-22 at 23:14 -0500, Pete Dietl wrote:
> So we are back to debating between many functions or (one or two)
> functions. Anyone else care to weigh in?

I understand what Tim is saying but I still prefer to have a single
function.  I want to reduce the "namespace leakage" for these
capabilities.  If we decide to add more operations to this in the
future I don't want it colliding with something else we want to do.

However, sometimes it's hard to see exactly how something will look
until we actually see it.

> As for a name for $(cond), we could call it 
> $(alu ...)
> And put arithmetic and logical operations in it :)

I guess this was not serious but... no :).

> I propose the following (a variation of example 2):
> 
> $(math + 5 (/ (* (/ (* 2 9) (+ 7 5 4)) (* 1024 1024)) 19))
> 
> This would involve doing our own parsing of the argument,
> however this should be trivial since we are using prefix notation.

If we want to support grouping directly we're still requiring the
function to be recursive.  If we use make expansion to provide grouping
the function doesn't need to be recursive (of course, we get recursion
implicitly because of make's expansion).

> I don’t like using $(cond)
> Because because I sort of want to option to implement cond like in
> Scheme.

I suspected someone would mention this :).  I want to reiterate that
even though we're adding some functionality, I'm not interested in
creating an entire programming language in make.

Today we have $(if ...) which has then/else clauses.  I understand that
a Lisp cond wouldn't need to nest each condition but I'm not convinced
that's a serious issue in any real makefiles.

And if you really want Lisp you can use the Guile integration.

So, I'm not too worried about this.  But, feel free to come up with
other names: I'm not saying it has to be that one.




reply via email to

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