On 1/30/2026 2:18 PM, Duke Normandin wrote:
On Fri, 30 Jan 2026 06:45:43 -0500 Eliot Moss moss@cs.umass.edu wrote:
On 1/30/2026 12:16 AM, Duke Normandin wrote:
On Thu, 29 Jan 2026 21:38:48 -0500 Eliot Moss moss@cs.umass.edu wrote:
On 1/29/2026 6:18 PM, Duke Normandin wrote:
Taken from Paulson's book: Chap2.4
A) fun square x = x * x;
Error- Unable to resolve overloading for *
I understand the above!
B) fun square(x : real) = x * x; I understand: x is declared as a real
C) fun square x = x * x : real; I see this as declaring a function w/o parentheses AND that the r_result_ is a 'real'
I have a problem with this declaration:
D) fun square x : real = x * x; I see this as declaring a function w/o parentheses, AND declaring x to be a 'real' I do NOT see/understand that this syntax indicates that the type of the _result_ is a 'real'
The type of the result is a real by implication of what * does on reals, i.e., it produces a real.
An "implied" result type! Now why didn't I think of that?
Personally, I prefer:
fun square (x:real) = x * x : real;
because it's self-documenting to the max, IMO.
Functional languages are big on type inference.
I'm gathering as much ...
It can be a culture shock coming from languages that require many more type annotations.
Thankfully, it seems to me that using type inference can be by-passed most of the time. I'd hate to have to come back to my code 6 mos down the round and wonder what was *inferred* in the code. Commenting the code and/or using more type annotation - finding a suitable balance!
Well, I've been coding in various languages since 1966 (8th grade), and I think that it's more helpful to try to meet each language on its own terms. I can take a while to get the hang of a particular language's "flow", but once you have it, going with the flow can be great. W.r.t type inference, I'll also mention that the trend for Java over time has been to introduce more type inference. This is different from *dynamic* typing, such as seen in Python and Javascript. I think you can make stronger arguments that that kind of dynamicity tend to undermine software reliability.
Cheers - EM