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

[Paul Smith]

On Sat, 2020-05-23 at 15:43 -0500, Pete Dietl wrote:
> > I understand what Tim is saying but I still prefer to have a single
> > function.  I want to reduce the "namespace leakage" for these
> > capabilities.  If we decide to add more operations to this in the
> > future I don't want it colliding with something else we want to do.
> > 
> > However, sometimes it's hard to see exactly how something will look
> > until we actually see it.
> 
> Hm so does that imply that we're still on the fence?
> What can we do to resolve this? Take a poll?

I think, as I mentioned before, that someone (I guess that's you :))
should write up an actual proposal (maybe, for example, the start of a
new manual section) that can be examined and commented on.  Endless
streams of mailing list responses quickly give diminishing returns.  My
experience is that it's much easier to come to conclusions when there
is a concrete plan to start from.

I do want to reiterate something I mentioned initially: any effort of
this size will require copyright assignment to the FSF / GNU project. 
Please be sure you are OK with that.  Getting that in motion earlier
will avoid delays at the end.

> You're the benevolent dictator right Paul? :)

Perhaps, in the sense that I reserve the right of ultimate refusal :)

However, the person who makes the proposal and does the work gets to
make a lot of the decisions.

So, I say you should do that.

> > > I propose the following (a variation of example 2):
> > > 
> > > $(math + 5 (/ (* (/ (* 2 9) (+ 7 5 4)) (* 1024 1024)) 19))
> > 
> > If we want to support grouping directly we're still requiring the
> > function to be recursive.  If we use make expansion to provide
> > grouping the function doesn't need to be recursive (of course, we
> > get recursion implicitly because of make's expansion).
> 
> By recursive do you mean the implementation of
> $(math) in the make source is recursive?

Yes.

> It you need more convincing, one could argue that parsing it directly
> would likely lead to a more efficient implementation -- we would
> have the opportunity to implement this as an iterative process;
> either by loops or tail-call recursion. But I'll reiterate that my
> motivation is a more concise syntax.

We can always use evaluation so you could just implement the basics
first and get grouping via evaluation for free, then add explicit
grouping as a next step if you want.

I'm not sure that attempting to avoid recursion (which basically
involves replacing it with some sort of array- or list-based stack) is
worthwhile for the anticipated uses.  So, to me it all comes down to
the implementation: how much more complex is it.

I recommend as above: it is approached iteratively and then we can
decide at each point of it's "good enough" and how much complexity the
next step adds.