bug-make
[Top][All Lists]
Advanced

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

Re: Tail call elimination


From: Paul Smith
Subject: Re: Tail call elimination
Date: Mon, 18 May 2020 15:39:45 -0400

On Mon, 2020-05-18 at 21:05 +0200, Jouke Witteveen wrote:
> On Mon, May 18, 2020 at 8:50 PM Paul Smith <address@hidden> wrote:
> > 
> > On Mon, 2020-05-11 at 16:32 -0500, Pete Dietl wrote:
> > > I would like to know your thoughts about adding something like
> > > $(expr
> > > ) to evaluate integer expressions and comparisons.
> > 
> > I have no problem with some basic math facilities.  We already have
> > functions like $(word ...), $(words ...), and $(wordlist ...),
> > which sort of need math to be fully useful.
> 
> Each of these has an obvious 'output', which is not the case for
> something like a comparison operator.

We should be sure to not talk past each other.  There are at least 3
different sets of functionality I think people are referring to:

* Math operators (+ - * / %)
* Integer comparison (< > == != >= <=)
* String comparison (eq ne le ge gt lt)

Then there are specialized operations such as semver-based version
comparison operators etc.

I was talking specifically about math functions in the above paragraph:
the word* functions resolve to integers or take integers as arguments:
this behavior naturally leads one to expect that there is a way to
manipulate integers in GNU make functions... which there is not (fancy
tricks notwithstanding).

> 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.

For integer comparison this is quite simple.

String comparisons are much harder because you run into issues like
locale (would it just be UTF-8 comparison), dealing with whitespace
(GNU make doesn't interpret quote characters: do we just say we don't
support comparing strings containing whitespace?), etc. etc.

And of course version comparison is a whole other level given all the
different ways it can be done.

I don't think we should discuss built-in string or version comparison,
and should restrict ourselves to discussing math, and possibly integer
comparisons.




reply via email to

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