3 ms·

> 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 synta

> 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'.

kmill 9y ago
> 3 (f x) Ok, so you have indeed changed syntax. Saying that Haskell/ML-style function application syntax is consistent with juxtaposition for multiplication is in no way inconsistent with anything I have said so far. Remember, you used "gravitationalAttraction(mass1, mass2, radius)" in your very first example, and I am speaking to the difficulties getting that example to work. When I said "it is at odds with juxtaposition for multiplication," I meant "having Haskell/ML-style function application along with classical function application notation", given your original example. There is nothing controversial with the statement "if you are allowed to change the notation for function application, then you can add juxtaposition for multiplication in a consistent way." But I feel this goes against your design goal of "writ[ing] multiplication naturally." That's not to say we can't come to see Haskell/ML-style function application as natural, but it is not yet the mathematical syntax people learn in school. >>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... Either I missed something basic, or I actually meant something about how mathematicians think about the objects of their work. It is extremely rare to see the functions returned by functions being used immediately as functions. They'd rather either use subscripts like F_t(v) or use a pairing between spaces. In abstract algebra, it's common to see fgx to mean f(g(x)) when f,g are in a ring R and x is in an R-module. With Rtimes being the multiplication in R and App being application, fgx is interpreted as both App(Rtimes(f,g),x) and App(f,App(g,x)), since they must be equal. Mathematicians would be surprised at the interpretation App(App(f,g),x). > I think it's pretty obviously unreasonable. In any reasonable language: Yes, you can make consistent systems where it is unreasonable, but that doesn't mean that there is no system in which it can be a reasonable interpretation. I didn't just make that interpretation up: things like e^A where A is a square matrix come up frequently in the study of differential equations, and it is interpreted by substituting A into a power series for e^x.
- alphaalpha101 9y ago
  >Ok, so you have indeed changed syntax. Saying that Haskell/ML-style function application syntax is consistent with juxtaposition for multiplication is in no way inconsistent with anything I have said so far. Remember, you used "gravitationalAttraction(mass1, mass2, radius)" in your very first example, and I am speaking to the difficulties getting that example to work. That's the same syntax. f x. x is a tuple. >When I said "it is at odds with juxtaposition for multiplication," I meant "having Haskell/ML-style function application along with classical function application notation", given your original example. But again, it isn't. f(x, y, z) is just f applied to the tuple (x, y, z) in ML. >That's not to say we can't come to see Haskell/ML-style function application as natural, but it is not yet the mathematical syntax people learn in school. It really is exactly the same notation. >It is extremely rare to see the functions returned by functions being used immediately as functions. You really think so? I have seen a lot of mathematics in my time and I really disagree with this claim. >In abstract algebra, it's common to see fgx to mean f(g(x)) when f,g are in a ring R and x is in an R-module. With Rtimes being the multiplication in R and App being application, fgx is interpreted as both App(Rtimes(f,g),x) and App(f,App(g,x)), since they must be equal. Mathematicians would be surprised at the interpretation App(App(f,g),x). fgx is just terrible notation. I've never seen it. I've seen (f o g)(x). I've seen f(g(x)). I've not ever seen fgx. >Yes, you can make consistent systems where it is unreasonable, but that doesn't mean that there is no system in which it can be a reasonable interpretation. I didn't just make that interpretation up: things like e^A where A is a square matrix come up frequently in the study of differential equations, and it is interpreted by substituting A into a power series for e^x. Not really. That's the definition of exp(A). That doesn't mean that you just substitute A into the power series for e^x and then try to parse that. We're talking about strongly statically typed programming languages.

kmill 9y ago

> 3 (f x) Ok, so you have indeed changed syntax. Saying that Haskell/ML-style function application syntax is consistent with juxtaposition for multiplication is in no way inconsistent with anything I have said so far. Remember, you used "gravitationalAttraction(mass1, mass2, radius)" in your very first example, and I am speaking to the difficulties getting that example to work. When I said "it is at odds with juxtaposition for multiplication," I meant "having Haskell/ML-style function application along with classical function application notation", given your original example. There is nothing controversial with the statement "if you are allowed to change the notation for function application, then you can add juxtaposition for multiplication in a consistent way." But I feel this goes against your design goal of "writ[ing] multiplication naturally." That's not to say we can't come to see Haskell/ML-style function application as natural, but it is not yet the mathematical syntax people learn in school. >>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... Either I missed something basic, or I actually meant something about how mathematicians think about the objects of their work. It is extremely rare to see the functions returned by functions being used immediately as functions. They'd rather either use subscripts like F_t(v) or use a pairing between spaces. In abstract algebra, it's common to see fgx to mean f(g(x)) when f,g are in a ring R and x is in an R-module. With Rtimes being the multiplication in R and App being application, fgx is interpreted as both App(Rtimes(f,g),x) and App(f,App(g,x)), since they must be equal. Mathematicians would be surprised at the interpretation App(App(f,g),x). > I think it's pretty obviously unreasonable. In any reasonable language: Yes, you can make consistent systems where it is unreasonable, but that doesn't mean that there is no system in which it can be a reasonable interpretation. I didn't just make that interpretation up: things like e^A where A is a square matrix come up frequently in the study of differential equations, and it is interpreted by substituting A into a power series for e^x.

alphaalpha101 9y ago
>Ok, so you have indeed changed syntax. Saying that Haskell/ML-style function application syntax is consistent with juxtaposition for multiplication is in no way inconsistent with anything I have said so far. Remember, you used "gravitationalAttraction(mass1, mass2, radius)" in your very first example, and I am speaking to the difficulties getting that example to work. That's the same syntax. f x. x is a tuple. >When I said "it is at odds with juxtaposition for multiplication," I meant "having Haskell/ML-style function application along with classical function application notation", given your original example. But again, it isn't. f(x, y, z) is just f applied to the tuple (x, y, z) in ML. >That's not to say we can't come to see Haskell/ML-style function application as natural, but it is not yet the mathematical syntax people learn in school. It really is exactly the same notation. >It is extremely rare to see the functions returned by functions being used immediately as functions. You really think so? I have seen a lot of mathematics in my time and I really disagree with this claim. >In abstract algebra, it's common to see fgx to mean f(g(x)) when f,g are in a ring R and x is in an R-module. With Rtimes being the multiplication in R and App being application, fgx is interpreted as both App(Rtimes(f,g),x) and App(f,App(g,x)), since they must be equal. Mathematicians would be surprised at the interpretation App(App(f,g),x). fgx is just terrible notation. I've never seen it. I've seen (f o g)(x). I've seen f(g(x)). I've not ever seen fgx. >Yes, you can make consistent systems where it is unreasonable, but that doesn't mean that there is no system in which it can be a reasonable interpretation. I didn't just make that interpretation up: things like e^A where A is a square matrix come up frequently in the study of differential equations, and it is interpreted by substituting A into a power series for e^x. Not really. That's the definition of exp(A). That doesn't mean that you just substitute A into the power series for e^x and then try to parse that. We're talking about strongly statically typed programming languages.