4 ms·

As someone who learned it casually a while back: Haskell's not great for strings, I'll give you that. How does the OCaml type system compare with Haskell's tho

As someone who learned it casually a while back: Haskell's not great for strings, I'll give you that. How does the OCaml type system compare with Haskell's though?

pdimitar 7y ago
Last I checked, they weren't that different. But I found OCaml's syntax more intuitive. Subjective, I admit. Truthfully though, both languages have similar pains. You can do one thing in 10 different ways in both, for example, which isn't tempting. But OCaml seems more terse, and its compiler is lightning-fast, so that tipped the scales for me.
atombender 7y ago
The big distinguishing difference is that OCaml doesn't have ad-hoc polymorphism and function overloading. You cannot have a function that operates on many different types; which is why you have two sets of arithmetic operators for integers and floats ("+" vs "+.", for example). In theory you can use modules for this, but it's awkward, and I don't think they're generally used this way. (OCaml is getting implicit modules, and this may help the situation.) In Haskell, typeclasses make this super easy. It allows you define a family of functions/operators that together become what a Go or Java developer might call an interface. Code written to use a particular typeclass will work for any implementation of that typeclass. On the other hand, OCaml's module system is very powerful and has no counterpart in Haskell. It allows you to package a whole type implementation into a single module that has a public signature, and can be instantiated with generic type parameters.
- chongli 7y ago
  I don’t know anything about OCaml so please forgive me if this question seems silly. two sets of arithmetic operators for integers and floats What if I want to create more numeric types? Say vectors in R^n, for example. Do I need to create more operators for vector addition and scalar multiplication? How do I make sure the user can’t add vectors of incompatible dimension?
  - atombender 7y ago
    Yes, you need to add new functions. You cannot redefine "+" to work a custom vector type. Similarly, you cannot have a "print" function that works for all sorts of types. OCaml has print_string, print_int, and so on. OCaml does have parametric polymorphism ("generics"). You can write functions which support generic parameters. And you can use modules as "functors" to sort of package up types in a similar way as Haskell typeclasses (e.g. see [1]). [1] https://stackoverflow.com/questions/14934242/whats-the-closest-thing-to-haskells-typeclasses-in-ocaml https://stackoverflow.com/questions/14934242/whats-the-close...
- vmchale 7y ago
  > OCaml's module system is very powerful and has no counterpart in Haskell. Is this taking into account backpack?
  - atombender 7y ago
    I'm not familiar with Backpack, but reading about it [1], it looks like its goal is indeed to provide an OCaml-style module system to Haskell. [1] https://plv.mpi-sws.org/backpack/ https://plv.mpi-sws.org/backpack/
marcosdumay 7y ago
> Haskell's not great for strings What do you mean by that?
- vmchale 7y ago
  The default String type is a linked list of characters, which means various things are slower than they should be.
  - marcosdumay 7y ago
    Hum... Yes. String is there for historical reasons that turned out to be a bad fit to what Haskell became. But there is no reason to use it. Text does everything String does.
- mic47 7y ago
  There are couple of implementarion of strings: * String - this is default, it is list of characters and it was a mistake. * ByteString and LazyByteString - this represents array of 8bit characters. Performant but does not handle encodings * Text and LazyText - this is what you want to use when yiu work with text, since it represent text in unicode. There is mess in these types. s9me libraries are using different types, so you might have to convert between those and it can be confusing, and the conversion apis are not unified. But if you manage in your project consistently use single type (say Text), then you'll actually have a great time working with strings. Its problem if you want to quickly mash together few libraries that does not use same types, since it get messy. Reason for this is mostly historic.
  - marcosdumay 7y ago
    > ByteString and LazyByteString - this represents array of 8bit characters Not exactly. ByteString has no relation at all with text or characters. It represents a sequence of bytes, AKA binary data. I imagined I would hear complaints about too many text types when I made that question, but it sounded like the GP had a different complaint. The library mess is real, but it's improving quickly and it's a bad reason to decide Haskell is a bad language to deal with text. It's throwing a lot of great stuff out just because of a minor inconvenient. And by the way, one of the best things on Haskell is that you can defined a lot more text types. For example, my current project has types for internal identifiers, HTML, HTML form values, JS, and SQL, they are all text but I can always be sure things are properly encoded.
kadoban 7y ago
Data.Text are fine strings really. Better than most languages I'd say, if not by a lot.

As someone who learned it casually a while back: Haskell's not great for strings, I'll give you that. How does the OCaml type system compare with Haskell's though?

pdimitar 7y ago

Last I checked, they weren't that different. But I found OCaml's syntax more intuitive. Subjective, I admit. Truthfully though, both languages have similar pains. You can do one thing in 10 different ways in both, for example, which isn't tempting. But OCaml seems more terse, and its compiler is lightning-fast, so that tipped the scales for me.

atombender 7y ago

The big distinguishing difference is that OCaml doesn't have ad-hoc polymorphism and function overloading. You cannot have a function that operates on many different types; which is why you have two sets of arithmetic operators for integers and floats ("+" vs "+.", for example). In theory you can use modules for this, but it's awkward, and I don't think they're generally used this way. (OCaml is getting implicit modules, and this may help the situation.) In Haskell, typeclasses make this super easy. It allows you define a family of functions/operators that together become what a Go or Java developer might call an interface. Code written to use a particular typeclass will work for any implementation of that typeclass. On the other hand, OCaml's module system is very powerful and has no counterpart in Haskell. It allows you to package a whole type implementation into a single module that has a public signature, and can be instantiated with generic type parameters.

chongli 7y ago
I don’t know anything about OCaml so please forgive me if this question seems silly. two sets of arithmetic operators for integers and floats What if I want to create more numeric types? Say vectors in R^n, for example. Do I need to create more operators for vector addition and scalar multiplication? How do I make sure the user can’t add vectors of incompatible dimension?
- atombender 7y ago
  Yes, you need to add new functions. You cannot redefine "+" to work a custom vector type. Similarly, you cannot have a "print" function that works for all sorts of types. OCaml has print_string, print_int, and so on. OCaml does have parametric polymorphism ("generics"). You can write functions which support generic parameters. And you can use modules as "functors" to sort of package up types in a similar way as Haskell typeclasses (e.g. see [1]). [1] https://stackoverflow.com/questions/14934242/whats-the-closest-thing-to-haskells-typeclasses-in-ocaml https://stackoverflow.com/questions/14934242/whats-the-close...
vmchale 7y ago
> OCaml's module system is very powerful and has no counterpart in Haskell. Is this taking into account backpack?
- atombender 7y ago
  I'm not familiar with Backpack, but reading about it [1], it looks like its goal is indeed to provide an OCaml-style module system to Haskell. [1] https://plv.mpi-sws.org/backpack/ https://plv.mpi-sws.org/backpack/

marcosdumay 7y ago

> Haskell's not great for strings What do you mean by that?

vmchale 7y ago
The default String type is a linked list of characters, which means various things are slower than they should be.
- marcosdumay 7y ago
  Hum... Yes. String is there for historical reasons that turned out to be a bad fit to what Haskell became. But there is no reason to use it. Text does everything String does.
mic47 7y ago
There are couple of implementarion of strings: * String - this is default, it is list of characters and it was a mistake. * ByteString and LazyByteString - this represents array of 8bit characters. Performant but does not handle encodings * Text and LazyText - this is what you want to use when yiu work with text, since it represent text in unicode. There is mess in these types. s9me libraries are using different types, so you might have to convert between those and it can be confusing, and the conversion apis are not unified. But if you manage in your project consistently use single type (say Text), then you'll actually have a great time working with strings. Its problem if you want to quickly mash together few libraries that does not use same types, since it get messy. Reason for this is mostly historic.
- marcosdumay 7y ago
  > ByteString and LazyByteString - this represents array of 8bit characters Not exactly. ByteString has no relation at all with text or characters. It represents a sequence of bytes, AKA binary data. I imagined I would hear complaints about too many text types when I made that question, but it sounded like the GP had a different complaint. The library mess is real, but it's improving quickly and it's a bad reason to decide Haskell is a bad language to deal with text. It's throwing a lot of great stuff out just because of a minor inconvenient. And by the way, one of the best things on Haskell is that you can defined a lot more text types. For example, my current project has types for internal identifiers, HTML, HTML form values, JS, and SQL, they are all text but I can always be sure things are properly encoded.

kadoban 7y ago

Data.Text are fine strings really. Better than most languages I'd say, if not by a lot.