4 ms·

It should be noted that Haskell's type system supports a form of dynamic typing: Existential types http://www.haskell.org/haskellwiki/Existential_type http://ww

It should be noted that Haskell's type system supports a form of dynamic typing: Existential types http://www.haskell.org/haskellwiki/Existential_type http://www.haskell.org/haskellwiki/Existential_type (among other methods). Also, static polymorphic types are a superior substitute for many uses of dynamic typing.

silentbicycle 16y ago
My type system experience mostly comes from OCaml, not Haskell, and I haven't done much with existential types. While I feel vaguely anti-intellectual saying this: I grok the H-M type inference used by ML* , and the simplest mechanical application of it probably covers 95% of the things I'd use it for. It simplifies things immensely, yet it's easy to reason about. I'm not sure that more advanced types are useful enough to justify the added complexity, personally. (Though if I added one thing to ML, it would be typeclasses.) However, I'm sure that, with sufficient experience, they probably also become second nature. I just prefer languages with relatively small semantics. * If I had understood unification when I was learning OCaml (I learned Prolog/unification later), though, it would have seemed practically obvious. "It's trying to unify the types, based on actual usage...oh! And it infers when they're parametric!" (with a few special cases so that e.g. functions keep their more specific types in recursive calls.)
- aristidb 16y ago
  It's possible to do without Existential Types, in fact they are only a language extension supported by GHC, not part of any standard. I think the obvious way to "simulate" existential types is with records like data MyRec = MkMyRec { op1 :: Int -> (MkMyRec, Int); op2 :: MkMyRec } Existential types just give you direct access to all methods in an existing typeclass, which may or may not be helpful. Btw., OCaml is on my list of "things to do" right below "create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-)
  - loup-vaillant 16y ago
    "create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-) You might succeed by translating USSM http://www.loup-vaillant.fr/projects/ussm http://www.loup-vaillant.fr/projects/ussm The system is written in about 300 lines of Ocaml, and should be easy to translate. Plus, you can rewrite it piece by piece, and still have a system that works.
- jerf 16y ago
  My problem with raw H-M is that it introduces a lot of very tight binding between modules; this can be good when it comes time to detect things you missed in a refactoring, but it is often still a bit too much binding even in my own code base, and it is definitely too much binding in a library. And large code bases structured sanely should usually be built like libraries anyhow. Being able to use classes and a selected handful of other constructs goes a long ways towards making Haskell more practical, even if the inference engine sometimes needs a bit more help. (And yes, I know you can hide symbols and such, but with raw H-M you still get these rigid concrete types. An XML parsing library that emits only XML datatypes defined in that one library and every function you write then has to know about these datatypes, and you can forget about changing that library ever again without entirely rewriting every line of code that touches it. Theoretically "every line that touches it" should be in some interface that converts it to your internal concepts, but in practice I am not completely wrapping every damn library I use so I still end up with some concrete types from libraries throughout. Mathematically this makes perfect sense, as a developer it makes my laugh derisively. Fortunately the situation isn't as bad as all that, though I'm still not 100% convinced that I'm not still at least chuckling derisively. I've been fiddling with Haskell for nearly a year now and I'm still completely undecided whether this is the future or an amusing but futile diversion from the ivory tower. I've never been this undecided about a language for so long. The awesome is so awesome, then I stumble into some unbelievably poky briar patch that I could have at least hacked around in any other language.... it's very odd.)
  - silentbicycle 16y ago
    You're absolutely right about modules. I didn't mention them because I tend to think of the module system as being independent from the type system, but they're actually closely related.

silentbicycle 16y ago

My type system experience mostly comes from OCaml, not Haskell, and I haven't done much with existential types. While I feel vaguely anti-intellectual saying this: I grok the H-M type inference used by ML* , and the simplest mechanical application of it probably covers 95% of the things I'd use it for. It simplifies things immensely, yet it's easy to reason about. I'm not sure that more advanced types are useful enough to justify the added complexity, personally. (Though if I added one thing to ML, it would be typeclasses.) However, I'm sure that, with sufficient experience, they probably also become second nature. I just prefer languages with relatively small semantics. * If I had understood unification when I was learning OCaml (I learned Prolog/unification later), though, it would have seemed practically obvious. "It's trying to unify the types, based on actual usage...oh! And it infers when they're parametric!" (with a few special cases so that e.g. functions keep their more specific types in recursive calls.)

aristidb 16y ago
It's possible to do without Existential Types, in fact they are only a language extension supported by GHC, not part of any standard. I think the obvious way to "simulate" existential types is with records like data MyRec = MkMyRec { op1 :: Int -> (MkMyRec, Int); op2 :: MkMyRec } Existential types just give you direct access to all methods in an existing typeclass, which may or may not be helpful. Btw., OCaml is on my list of "things to do" right below "create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-)
- loup-vaillant 16y ago
  "create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-) You might succeed by translating USSM http://www.loup-vaillant.fr/projects/ussm http://www.loup-vaillant.fr/projects/ussm The system is written in about 300 lines of Ocaml, and should be easy to translate. Plus, you can rewrite it piece by piece, and still have a system that works.
jerf 16y ago
My problem with raw H-M is that it introduces a lot of very tight binding between modules; this can be good when it comes time to detect things you missed in a refactoring, but it is often still a bit too much binding even in my own code base, and it is definitely too much binding in a library. And large code bases structured sanely should usually be built like libraries anyhow. Being able to use classes and a selected handful of other constructs goes a long ways towards making Haskell more practical, even if the inference engine sometimes needs a bit more help. (And yes, I know you can hide symbols and such, but with raw H-M you still get these rigid concrete types. An XML parsing library that emits only XML datatypes defined in that one library and every function you write then has to know about these datatypes, and you can forget about changing that library ever again without entirely rewriting every line of code that touches it. Theoretically "every line that touches it" should be in some interface that converts it to your internal concepts, but in practice I am not completely wrapping every damn library I use so I still end up with some concrete types from libraries throughout. Mathematically this makes perfect sense, as a developer it makes my laugh derisively. Fortunately the situation isn't as bad as all that, though I'm still not 100% convinced that I'm not still at least chuckling derisively. I've been fiddling with Haskell for nearly a year now and I'm still completely undecided whether this is the future or an amusing but futile diversion from the ivory tower. I've never been this undecided about a language for so long. The awesome is so awesome, then I stumble into some unbelievably poky briar patch that I could have at least hacked around in any other language.... it's very odd.)
- silentbicycle 16y ago
  You're absolutely right about modules. I didn't mention them because I tend to think of the module system as being independent from the type system, but they're actually closely related.