Re: math expressions (was: Re: Tail call elimination)

[Jouke Witteveen]

On Wed, May 27, 2020 at 8:47 PM Pete Dietl <petedietl@gmail.com> wrote:
>
> A few questions.
>
> Technically, the C standard allows for machines which don't use 2's 
> complement.
> So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined behavior, so should we also
> indicate that we have undefined behavior or should we use some
> function that reliably detects and
> wraps signed arithmetic?
>
> Bit shifting to the right with signed integers is undefined behavior
> too. Usually this is an arithmetic shift,
> but it's not guaranteed. Should we try to guarantee this with some
> function or should we leave this as undefined behavior?

Here is a thought: The current support for numeric variables is
limited to unsigned numbers. We could choose to stick with that!
This would also deal with the earlier remark by Paul Smith regarding
the nasty nature of switching the sign of a numbers. In fairness,
switching a sign is really a syntactic operation:
minus = $(patsubst --%,%,$(1:%=-%))

> Before I make my proposal, what do you think of supporting the
> following operators:
> +, -, /, *, not, and, or, comp, <<, >>
>
> Should the logical operators have english names or should they be C
> symbols like !, &, |, ~ ?

I would definitely start with only addition, subtraction,
multiplication, and division:
$(math OP, LIST)
Note that when LIST is empty, addition and subtraction should yield
"0", while multiplication and division should yield "1". Every word in
list that is not a number must yield a "non-numeric argument" error,
number parsing should be shared with the current functions that accept
numeric arguments.

One more thing: I really like the proposal by Edward Welbourne for a
three-way comparison function. A numeric equivalent to $(if). His
$(conditional) proposal does not require any boolean tokens and feels
familiar with how things are working right now. One small issue is
that
$(conditional $(a),$(b),$(lt),$(eq))
should probably be empty when a is greater than b. A more ergonomic,
though probably too surprising alternative, is to use the second
argument also for the greater-than case if a third argument is
missing.

Let me know what your plans are, I am willing to help (but have limited time).
FSF copyright forms are in the process of being cleared at my work.

Regards,
- Jouke