[Top][All Lists]

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

Re: Tail call elimination

From: Tim Murphy
Subject: Re: Tail call elimination
Date: Mon, 18 May 2020 20:04:40 +0000

Re comparing strings: we already have ifeq and what I have often wanted is to have a function equivalent so I can use it in expressions. As bad as ifeq may be from the point of view of locale this need be no better to be an improvement over the unpleasant hacks I've had to use to get the same effect with more complicated expressions.

Re math operations. Give me integer increment and I could jump for joy, give me lt and gt and $(add 1,2,...)  and I'd cover most of the use cases I've ever personally needed.  You are right to say that a tiny number of things can make a huge difference.



On Mon, 18 May 2020 at 19:39, Paul Smith <address@hidden> wrote:
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

reply via email to

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