> 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? You're the benevolent dictator right Paul? :) > > 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? I only prefer my suggestion because it removes a lot of dollar signs and `insert name of function here` repetition. 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.