4 ms·

I don't think this is true. Because: Standard ML does not have let rec, but can do type inference just fine.

by sampo 12y ago

pjmlp 12y ago
https://realworldocaml.org/v1/en/html/variables-and-functions.html#recursive-functions https://realworldocaml.org/v1/en/html/variables-and-function... "OCaml distinguishes between nonrecursive definitions (using let) and recursive definitions (using let rec) largely for technical reasons: the type-inference algorithm needs to know when a set of function definitions are mutually recursive, and for reasons that don't apply to a pure language like Haskell, these have to be marked explicitly by the programmer."
- sampo 12y ago
  Hmm, yes. Depends on whether /u/hencq asked about why rec is needed, or why and is needed. I answered above, why rec. And you answered why an explicit grouping of mutually recursive functions using and is needed. And true, this is needed for type inference. And even though Standard ML does not need rec, it does need and.
  - hencq 12y ago
    Ah very interesting. I guess my question was mainly about and, though I hadn't thought about the reasons for rec. It makes sense that that removes a class of errors. So as a follow-up question: why is type inference impossible without and or what is it about and that makes it possible? For instance, what would happen if I (out of laziness or something) would just insert and everywhere, even for functions that aren't mutually recursive. So, e.g. let rec f x = x + 1 and g y = y * 2 Would type inference somehow fail on that? If not, what's stopping me from writing a version of OCaml where all top level lets are automatically converted to let ... and ... and? (Other than a complete lack of necessary compiler writing skills obviously)
    - sampo 12y ago
      Here is a Stackoverflow answer: http://stackoverflow.com/a/904715/1115446 http://stackoverflow.com/a/904715/1115446 I don't think anything stops you from defining all functions in a program in one giant let rec ... and ..., but doing that might set some other limitations on how you can structure your code.

I don't think this is true. Because: Standard ML does not have let rec, but can do type inference just fine.

by sampo 12y ago

I don't think this is true. Because: Standard ML does not have let rec, but can do type inference just fine.

pjmlp 12y ago

https://realworldocaml.org/v1/en/html/variables-and-functions.html#recursive-functions https://realworldocaml.org/v1/en/html/variables-and-function... "OCaml distinguishes between nonrecursive definitions (using let) and recursive definitions (using let rec) largely for technical reasons: the type-inference algorithm needs to know when a set of function definitions are mutually recursive, and for reasons that don't apply to a pure language like Haskell, these have to be marked explicitly by the programmer."

sampo 12y ago
Hmm, yes. Depends on whether /u/hencq asked about why rec is needed, or why and is needed. I answered above, why rec. And you answered why an explicit grouping of mutually recursive functions using and is needed. And true, this is needed for type inference. And even though Standard ML does not need rec, it does need and.
- hencq 12y ago
  Ah very interesting. I guess my question was mainly about and, though I hadn't thought about the reasons for rec. It makes sense that that removes a class of errors. So as a follow-up question: why is type inference impossible without and or what is it about and that makes it possible? For instance, what would happen if I (out of laziness or something) would just insert and everywhere, even for functions that aren't mutually recursive. So, e.g. let rec f x = x + 1 and g y = y * 2 Would type inference somehow fail on that? If not, what's stopping me from writing a version of OCaml where all top level lets are automatically converted to let ... and ... and? (Other than a complete lack of necessary compiler writing skills obviously)
  - sampo 12y ago
    Here is a Stackoverflow answer: http://stackoverflow.com/a/904715/1115446 http://stackoverflow.com/a/904715/1115446 I don't think anything stops you from defining all functions in a program in one giant let rec ... and ..., but doing that might set some other limitations on how you can structure your code.