4 ms·

Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a po

by rntz 12y ago

Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system.

dragonwriter 12y ago
> Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system But AFAICT, you don't really need type-system support to use monads or monad transformers -- Haskell's purity, static typing, and use of monads for IO forces Haskell users to become familiar with monads, which may encourage Haskellers to develop the skill to use them for other purposes, but there is nothing stopping you from using monads and monad transformers in a dynamically typed language.
- rntz 12y ago
  No, you don't. But the question at hand isn't using a dynamically vs. a statically typed language, it is, given that you are in a statically typed language, is a Java-style one sufficient? Indeed, this is one of the benefits of dynamically typed languages: you're not restricted to any particular type discipline; you don't have to worry that the type system of the language you're in is too restrictive. OTOH, if you want it to be easy to write reusable code, having static typeclasses with type inference can be quite useful. You could write a monad transformer stack in a dynamically typed language, but you can't always write code that's generic across any monad without explicitly passing around an object that represents the monad in question. (Racket's "units" might be a reasonable solution to this problem, though.)
rbehrends 12y ago
Writing a parser combinator library does not require a powerful type system, especially not a custom one for a specific task (the students who were doing the scanner/parser task were limited to an environment where they had no access to third-party libraries, not that any existed for the language they were given). For a simple parser combinator implementation from scratch you require nothing more than basic types and the type of whatever AST you're generating. Parametric polymorphism is useful when you want to write a reusable parser combinator library, something that wasn't necessary, but even then you don't really need more than that (see other existing parser combinator libraries). Higher order functions can make your life easier, but note that the students had access to a Java-like language (of which there was both a statically and a dynamically typed version) with Ruby-style closures, so that wasn't an obstacle.
- rntz 12y ago
  Fair point.

by rntz 12y ago

Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system.

dragonwriter 12y ago

> Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system But AFAICT, you don't really need type-system support to use monads or monad transformers -- Haskell's purity, static typing, and use of monads for IO forces Haskell users to become familiar with monads, which may encourage Haskellers to develop the skill to use them for other purposes, but there is nothing stopping you from using monads and monad transformers in a dynamically typed language.

rntz 12y ago
No, you don't. But the question at hand isn't using a dynamically vs. a statically typed language, it is, given that you are in a statically typed language, is a Java-style one sufficient? Indeed, this is one of the benefits of dynamically typed languages: you're not restricted to any particular type discipline; you don't have to worry that the type system of the language you're in is too restrictive. OTOH, if you want it to be easy to write reusable code, having static typeclasses with type inference can be quite useful. You could write a monad transformer stack in a dynamically typed language, but you can't always write code that's generic across any monad without explicitly passing around an object that represents the monad in question. (Racket's "units" might be a reasonable solution to this problem, though.)

rbehrends 12y ago

Writing a parser combinator library does not require a powerful type system, especially not a custom one for a specific task (the students who were doing the scanner/parser task were limited to an environment where they had no access to third-party libraries, not that any existed for the language they were given). For a simple parser combinator implementation from scratch you require nothing more than basic types and the type of whatever AST you're generating. Parametric polymorphism is useful when you want to write a reusable parser combinator library, something that wasn't necessary, but even then you don't really need more than that (see other existing parser combinator libraries). Higher order functions can make your life easier, but note that the students had access to a Java-like language (of which there was both a statically and a dynamically typed version) with Ruby-style closures, so that wasn't an obstacle.

rntz 12y ago
Fair point.