[Top][All Lists]

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

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

From: Paul Smith
Subject: Re: math expressions (was: Re: Tail call elimination)
Date: Mon, 25 May 2020 17:58:26 -0400

On Mon, 2020-05-25 at 12:07 -0400, Sam Kendall wrote:
> I'd like to raise some questions that I think any proposal ought to
> answer. I'll assume a straw man proposal: there's one function, and
> it takes one of the following forms:

I believe the form being considered is:


where LIST expands to a space-separated list of integer values.  The
operator is applied to the entire list, from left to right.

> A binary operator (first form) is one of + - * and /. The only unary
> operator is "-".

Negation (unary "-") is definitely a problem since unfortunately
standard math uses the same symbol for negation and subtraction.  I
don't want to use the OPERATOR (in the above form) to handle it,
because I don't want to have $(math -,2) behave differently from $(math
-,2 0): it's too bizarre and confusing.

I'd prefer to see it allowed in the parsing of LIST, and handled there.
This absolutely needs thought and needs to be in the proposal.

> There might also be equality and relational operators. A value is an
> optional "-" followed by one or more decimal digits. It represents a
> 64-bit signed integer.

If negation is handled during LIST parsing then we need to allow
multiple initial "-", so you can say "-$(foo)" where $(foo) is -5.

This does mean that we wouldn't support "--"/"++" operators.

For all your other questions I agree the proposal needs to address
them.  I agree with you that all invalid operations should yield fatal

The only one I'm not sure about is overflow.  That will need some
thought.  Gnulib contains a comprehensive set of macros to deal with
overflow, in various ways.

reply via email to

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