Re: Tail call elimination

[Pete Dietl]

On Tue, May 19, 2020 at 11:13 AM Paul Smith <address@hidden> wrote:
>
> No, I don't like this.  Perhaps addition is sufficient for your use-
> case but others may need multiplication or division and I certainly
> don't want to start adding 10 different explicit funtions like "add",
> "mult", etc.  I prefer a single mathematical expression function.

I concur with this.

> Name: I'm using expr here just for convenience.  Is there a better
> name?

Other than `expr`, maybe `math` or `arith`, but I think at least some people
will be familiar with `expr`.
Another option would be to introduce some new syntax like $(()),
but that might break existing Makefiles and would probably be more work,
though it looks cleaner IMO.

> Whitespace: do we have to put whitespace around every operator, like
> expr(1), or is the function smart enough to understand $(expr 1+1+4)?

I think we should go for C-like parsing where the whitespace is insignificant.

> Grouping: do we try to implement expression grouping with () (e.g.,
> $(expr (1 + 1) * 4) or is it good enough to just say people need to
> nest expr functions: $(expr $(expr 1 + 1) * 4)?

I think nesting `expr` is too noisy.

> Precedence: do we try to implement standard mathematical precedence
> (multiplication/division before addition/subtraction) or do we just
> evaluate left to right and require explicit grouping?  It would
> definitely be a source of ongoing user confusion to not follow normal
> precedence rules, but supporting it would make the implementation more
> complex.

We should definitely implement the proper precedence.
Follow the rules for c?
https://en.cppreference.com/w/c/language/operator_precedence

I took a programming languages class at University and my professor wrote all
of the material for it. Specifically, notes on implementing
recursive-descent parsers (hereinafter "RDP")
for an interpreted language (which I believe is the type of parsing Make uses).
I plan on using this page http://beastie.cs.ua.edu/proglan/expgram.html
as a reference for how to accomplish left associativity and the correct
presence in a RDP.

> Increment/decrement: do we try to implement += / -= and/or ++ --?  It
> would be something like the symbol on the left would be interpreted as
> a variable name, so $(expr foo += 5) would add 5 to the variable foo
> (and expand to the new value of $(foo)).  If we support ++/-- do we
> support both pre- and post- operators?  This isn't needed in places
> where you can just say "foo = $(expr $(foo) + 5)", but allowing
> assignment within an expression could be very helpful.  It could be
> done anyway with: $(eval foo := $(expr $(foo) + 5))$(foo) ... is it
> worthwhile to add syntactic sugar for this?

yes assignments as expressions is valuable to make things more readable
I think.

> If we support increment/decrement do we go farther and support variable
> interpolation a la shell $((...)), where a symbol is assumed to be the
> value of the variable (that is, $(expr foo + 10) is equivalent to
> $(expr $(foo) + 10)?  I wouldn't bother implementing this by itself but
> it becomes a question if increment/decrement needs it anyway.

I don't have a preference on this. Allowing the behavior of $(())
is useful for cutting down on any noisy/messy/extraneous symbols
in the argument to $(expr)