3 ms·

About Haskell's function type annotations: "But it usually results in a warning, and adding a type signature is a good practice." I prefer Rust's way of doing

About Haskell's function type annotations: "But it usually results in a warning, and adding a type signature is a good practice." I prefer Rust's way of doing this. When you're a beginner it ensures that you're passing and returning the proper type to and from the function, you kind of have the function as a guard which ensures that you're using the correct types.

ghostwriter 4y ago
> it ensures that you're passing and returning the proper type to and from the function You don't need it for all function declarations though, there are many trivial cases where type signatures don't add value. Consider that you probably would prefer most of the variables within a function to be inferred for you by the compiler. A similar thing could be said about the most of the functions within a given module. Important interface methods can be defined explicitly though, for extra clarity and self-documenting purposes.
- bryanlarsen 4y ago
  pub functions: should be explicit module functions: if I chose, I'd let them be derived, but I'm relatively indifferent inner functions: should be allowed to be derived, IMO. They're very infrequently used so this choice doesn't have much impact.
  - nicoburns 4y ago
    You can use closures as functions with type inferred signatures
    - bryanlarsen 4y ago
      Closures capture variables so have significant differences compared to inner functions. Capture can affect lifetimes so the difference is significant in Rust.
      - nicoburns 4y ago
        Closures don't have to capture variables. If they don't then they're equivalent to functions.
        bryanlarsen 4y ago
        That's what I thought too, but I fixed some compiler errors by turning a closure into an inner function. Probably a PBKAC, but...
        LegionMammal978 4y ago
        Perhaps it's due to the fact that you can't really have type-generic closures in Rust: once the compiler has inferred one type, the closure cannot be used with another type. In contrast, inner functions can have any number of additional type parameters.
thedataangel 4y ago
In "serious" Haskell code, almost all top-level definitions (i.e. functions) are given types - for exactly the reason you specify.
Y_Y 4y ago
I prefer to have a choice. You could have a compiler that doesn't run it you haven't eaten a balanced breakfast either. Haskell's type system is designed around type inference (of the Hindley-Milner kind), if it can infer the type I'd like to have the option to let it do so. It's certainly good practise to write out your types, and often your editor can do it for you, but there are tons of little places where it's a waste.
Hirrolot 4y ago
I find type errors in HM typing systems can sometimes be quite obscure and misleading, due to omnipresent type inference. Writing type signatures can save you from that. For example, even if the type signature is quite "obvious", you can erroneously plug in some other type into the function, which triggers the type system to underline the function being defined instead of the function call.
dgb23 4y ago
Rust only half-asses this though. Lifetime annotations are part of the type of the function but can be elided if unambiguous. For beginners and generally people who read code that's confusing. I don't think there's anything to be gained by writing a few less characters and editors can easily add them as well.
- iudqnolq 4y ago
  There's crucial nuance here. Lifetime annotations aren't elided based on there being only one unambiguous answer. Rather, there's three simple rules[1] that look at the function signature and in simple cases give what you probably want. If those simple rules don't match your use case you need to define manually, the compiler doesn't get clever. This means that if you want to take a reference to an array and return a reference to an item in an array, for example, elision will work fine. But if you take a reference to a key and look up a reference to the value in a global map you need to write it by hand, even though the compiler could pretty clearly guess the output lifetime you want. This preserves a crucial feature: you can know the exact signature of a function by only looking at the signature definition, you don't need to look into the body. Lifetime elision isn't like inferring argument types. It's like defaulting integer literals to i32 unless you specify otherwise. See https://doc.rust-lang.org/nomicon/lifetime-elision.html https://doc.rust-lang.org/nomicon/lifetime-elision.html
- kaba0 4y ago
  Is 4 ‘a, ‘b, etc. really more readable?

ghostwriter 4y ago

> it ensures that you're passing and returning the proper type to and from the function You don't need it for all function declarations though, there are many trivial cases where type signatures don't add value. Consider that you probably would prefer most of the variables within a function to be inferred for you by the compiler. A similar thing could be said about the most of the functions within a given module. Important interface methods can be defined explicitly though, for extra clarity and self-documenting purposes.

bryanlarsen 4y ago
pub functions: should be explicit module functions: if I chose, I'd let them be derived, but I'm relatively indifferent inner functions: should be allowed to be derived, IMO. They're very infrequently used so this choice doesn't have much impact.
- nicoburns 4y ago
  You can use closures as functions with type inferred signatures
  - bryanlarsen 4y ago
    Closures capture variables so have significant differences compared to inner functions. Capture can affect lifetimes so the difference is significant in Rust.
    - nicoburns 4y ago
      Closures don't have to capture variables. If they don't then they're equivalent to functions.
      - bryanlarsen 4y ago
        That's what I thought too, but I fixed some compiler errors by turning a closure into an inner function. Probably a PBKAC, but...
        LegionMammal978 4y ago
        Perhaps it's due to the fact that you can't really have type-generic closures in Rust: once the compiler has inferred one type, the closure cannot be used with another type. In contrast, inner functions can have any number of additional type parameters.

thedataangel 4y ago

In "serious" Haskell code, almost all top-level definitions (i.e. functions) are given types - for exactly the reason you specify.

Y_Y 4y ago

I prefer to have a choice. You could have a compiler that doesn't run it you haven't eaten a balanced breakfast either. Haskell's type system is designed around type inference (of the Hindley-Milner kind), if it can infer the type I'd like to have the option to let it do so. It's certainly good practise to write out your types, and often your editor can do it for you, but there are tons of little places where it's a waste.

Hirrolot 4y ago

I find type errors in HM typing systems can sometimes be quite obscure and misleading, due to omnipresent type inference. Writing type signatures can save you from that. For example, even if the type signature is quite "obvious", you can erroneously plug in some other type into the function, which triggers the type system to underline the function being defined instead of the function call.

dgb23 4y ago

Rust only half-asses this though. Lifetime annotations are part of the type of the function but can be elided if unambiguous. For beginners and generally people who read code that's confusing. I don't think there's anything to be gained by writing a few less characters and editors can easily add them as well.

iudqnolq 4y ago
There's crucial nuance here. Lifetime annotations aren't elided based on there being only one unambiguous answer. Rather, there's three simple rules[1] that look at the function signature and in simple cases give what you probably want. If those simple rules don't match your use case you need to define manually, the compiler doesn't get clever. This means that if you want to take a reference to an array and return a reference to an item in an array, for example, elision will work fine. But if you take a reference to a key and look up a reference to the value in a global map you need to write it by hand, even though the compiler could pretty clearly guess the output lifetime you want. This preserves a crucial feature: you can know the exact signature of a function by only looking at the signature definition, you don't need to look into the body. Lifetime elision isn't like inferring argument types. It's like defaulting integer literals to i32 unless you specify otherwise. See https://doc.rust-lang.org/nomicon/lifetime-elision.html https://doc.rust-lang.org/nomicon/lifetime-elision.html
kaba0 4y ago
Is 4 ‘a, ‘b, etc. really more readable?