4 ms·

>That's altering the syntax for function application by allowing f x to mean f(x), which is fine but changing the rules. If we do go with that, then "a b c" sho

>That's altering the syntax for function application by allowing f x to mean f(x), which is fine but changing the rules. If we do go with that, then "a b c" should be "Apply a (Apply b c)" because of the associativity of application --- traditional math tends not to have functions which return functions. That's the standard way of writing function application in functional programming languages. And in those languages, f a b c == (((f a) b) c) because they're curried: a function of 2 arguments (f: a -> b -> c) is a function f from type a to type (b -> c). And mathematics definitely has functions that return functions. For example, any function where the codomain is a space of sequences is technically a function that returns functions, as a sequence in X is a function from the natural numbers to X. >There is an ambiguity which comes up when you allow both f x and f(x) syntax, which is you cannot tell the difference between f(x,y) and f((x,y)) if your language has tuples. (One solution: make tuples be like Mathematica's Sequence, thus establishing the associativity of Cartesian products once and for all.) You don't need to tell the difference. If you have a curried function, then you write 'f x y' which isn't the same as 'f (x y)' (which is like the C-style 'f(x(y))'. If you have a non-curried function, then 'multiple arguments' are just a tuple, at least that's how it works in ML. A function that takes a tuple and a function with multiple arguments are equivalent. That's related to the fact that ((A AND B) IMPLIES C) is equivalent to (A IMPLIES (B IMPLIES C)). >A gotcha is that you can't write f(x)(y) if your function does return a function, since this will parse as f(x y). You would need to write (f(x))(y) instead. (If you insist the associativity rule should be the other way, then 3f(x) would be (3f)x, which is possibly ok, and sin cos x would be (sin(cos))(x).) sin cos x is okay notation in mathematics because sin can't take cos as an argument, so it obviously has to mean 'sin(cos x)' and not 'sin(cos)(x)'. But when dealing with computers, I would far rather just write sin (cos x) which is how people write it in Haskell/ML/Lisp. Not sure if you mean existential quantification or just the number 3 in '3f(x)' but as I said, I don't think that it's a good idea to support 'x f' as meaning '(lambda (a) (* 3 (f a)))' or '(a => 3 * f(a))' or '\a -> 3 * (f a)' or whatever your preferred function notation is for that scaling operation.

kmill 9y ago
Just to keep things in perspective, all I'm saying is that "the ability to write multiplication naturally" comes at a cost. I'm aware of Haskell/ML-like syntax for curried functions, but it is at odds with juxtaposition for multiplication. I'm speaking from the position of having tried designing languages with these features and not being able to find a way to make everything consistent. > And mathematics definitely has functions that return functions Recall, I said "tends not to". My point was that the notation of mathematics is set up to prefer the case of functions returning values. > Not sure if you mean existential quantification or just the number 3 in '3f(x)' I meant 3f(x) to mean 3*f(x). I believe you'd want to be able to write 3f(x) since you should be able to have the "ability to write multiplication naturally," in your words. > sin can't take cos as an argument But sin can be represented as a power series and cos can be substituted in with cos^n meaning iterating cos n times. This may or may not be reasonable; I don't think it is "obvious."
- alphaalpha101 9y ago
  > Just to keep things in perspective, all I'm saying is that "the ability to write multiplication naturally" comes at a cost. I'm aware of Haskell/ML-like syntax for curried functions, but it is at odds with juxtaposition for multiplication. But it doesn't. I've already explained why it's not an issue: they associate the same way (so it's not a parse-time issue), and they're never ambiguous (the type of the LHS is a function in one case and a number in the other case, and functions and numbers are never the same, so it's never an issue). >Recall, I said "tends not to". My point was that the notation of mathematics is set up to prefer the case of functions returning values. Functions are values... >I meant 3f(x) to mean 3*f(x). I believe you'd want to be able to write 3f(x) since you should be able to have the "ability to write multiplication naturally," in your words. 3 (f x) >But sin can be represented as a power series and cos can be substituted in with cos^n meaning iterating cos n times. This may or may not be reasonable; I don't think it is "obvious." I think it's pretty obviously unreasonable. In any reasonable language: sin : Number -> Number cos : Number -> Number So 'sin cos' is going to be a type error: "type mismatch, expected type 'Number' in argument to 'sin', got 'cos: Number -> Number'.
  - 9y ago

kmill 9y ago

Just to keep things in perspective, all I'm saying is that "the ability to write multiplication naturally" comes at a cost. I'm aware of Haskell/ML-like syntax for curried functions, but it is at odds with juxtaposition for multiplication. I'm speaking from the position of having tried designing languages with these features and not being able to find a way to make everything consistent. > And mathematics definitely has functions that return functions Recall, I said "tends not to". My point was that the notation of mathematics is set up to prefer the case of functions returning values. > Not sure if you mean existential quantification or just the number 3 in '3f(x)' I meant 3f(x) to mean 3*f(x). I believe you'd want to be able to write 3f(x) since you should be able to have the "ability to write multiplication naturally," in your words. > sin can't take cos as an argument But sin can be represented as a power series and cos can be substituted in with cos^n meaning iterating cos n times. This may or may not be reasonable; I don't think it is "obvious."

alphaalpha101 9y ago
> Just to keep things in perspective, all I'm saying is that "the ability to write multiplication naturally" comes at a cost. I'm aware of Haskell/ML-like syntax for curried functions, but it is at odds with juxtaposition for multiplication. But it doesn't. I've already explained why it's not an issue: they associate the same way (so it's not a parse-time issue), and they're never ambiguous (the type of the LHS is a function in one case and a number in the other case, and functions and numbers are never the same, so it's never an issue). >Recall, I said "tends not to". My point was that the notation of mathematics is set up to prefer the case of functions returning values. Functions are values... >I meant 3f(x) to mean 3*f(x). I believe you'd want to be able to write 3f(x) since you should be able to have the "ability to write multiplication naturally," in your words. 3 (f x) >But sin can be represented as a power series and cos can be substituted in with cos^n meaning iterating cos n times. This may or may not be reasonable; I don't think it is "obvious." I think it's pretty obviously unreasonable. In any reasonable language: sin : Number -> Number cos : Number -> Number So 'sin cos' is going to be a type error: "type mismatch, expected type 'Number' in argument to 'sin', got 'cos: Number -> Number'.
- 9y ago