The current version of sweet-expressions transforms: f(x y z) into: (f x y z) So cos(x) becomes (cos x) and so on.
But what if you need to do a calculation to find the function (e.g., compute a lambda expression, select a function from many, etc.)? I think limiting this transformation to just simple names as prefixes is too limiting, and that it should be generalized instead. Instead, I propose that if some parentheses (...) are prefixed by a term, mapping that into (term ...). This could be repeated, since term(...) is itself a term. This would mean that: cos(x) => (cos x) ; already true f(x)(y) => ((f x) y) ; Look, I can compute the function f(a b)(c)(d) => (((f a b) c) d) ; ad nauseum...! This has some other advantages. Since this is simply a shorthand for functional composition, this makes a functional programming approach much simpler to notate. Note in particular that the nesting required by "traditional" s-expression notation simply goes away. Calling a lambda function this way is duck simple. It _does_ mean that if you forget to separate parameters with whitespace, we now have new cases where a transform you didn't intend will happen. But s-expressions are very sensitive to the nonpresence of whitespace anyway, so this is nothing new. Though I don't think it's a good idea, I _could_ make a special exception: if the term began with a traditional s-expression, then DON'T do this transform. The reason for this exception would be to allow reading of old code like this: (a)(b) But that would be more complex, which is why I think it's a bad idea. Anything INSIDE (...) would be a traditional s-expression anyway (since they would disable sweet-expressions), so this is remarkably unlikely to be a problem. And exceptions make reasoning hard... so I don't think I should create that special exception. NOT creating the exception will make it easier to code, and to understand. This would mean that: (a)(b) => ((a) b) IE, call a to find out what function to call, then call it with parameter b. --- David A. Wheeler
