8 ms·

why, it is just an ADT which could be implemented in almost any language. Something like tagging a value with a type-tag and then define whole bunch of construc

why, it is just an ADT which could be implemented in almost any language. Something like tagging a value with a type-tag and then define whole bunch of constructors and selectors, and then procedures which removes the tag, applies a given procedure and sticks the the tag to the result. (cons 'safe x) OK, In Haskell this stuff could be type-checked, which means only that the arguments to functions and its return values are of correct type (tags are present). But calling this a "safety" is a silly meme.)

wyager 12y ago
>which could be implemented in almost any language. You need HKTs to have type-checked generic monads. Almost no languages have them.
- wycats 12y ago
  Yes, if you want type-checked generic monads. Dynamic languages can implement generic, but not type-checked monads. Many static languages can implement type-checked but non-generic monads. Now you need to show how type-checked generic monads are critical. That's much harder than showing that the monadic pattern is useful.
  - tel 12y ago
    Being able to abstract over the monad leads to monad transformers of the `transformers`, `mtl`, and `extensible-effects` varieties. You can argue that those aren't valuable, but I don't think you can argue that type-checked generic monads are critical for achieving them. In practice, 75% of the time that I use monads I am using some kind of monad stack. I'm sure you can argue that this is unnecessary or that I only do so because Haskell affords it... but on the other hand, I believe that transformer stacks do a good job of elaborating the space of effect types with an efficient, expressive language. Without them you either elide side effect reification or build a lot of one-off monad stacks.
  - iopq 12y ago
    Except in dynamic languages most people reinvent the wheel and don't quite get to a monadic interface. Like Javascript promises. They could have had ONE interface that is consistent. But Promises are actually a special snowflake that solves the problem in a slightly different way with a slightly different interface. And that's because nobody can complain that their stuff doesn't compile due to it not satisfying some interface.
chongli 12y ago
Why is it silly? Haskell libraries derive a lot of safety benefit out of being able to type-check different kinds of effects. One example is the STM library which uses this property to prohibit IO within an atomic transaction. Since transactions may be aborted and/or repeated, it's important to ensure no interaction with the outside world takes place within them lest these effects be repeated.
- dschiptsov 12y ago
  Because it has nothing to do with safety, but with manipulating of specialized data-structures. "Instantiation of a value of a given type" in Haskell is what? Calling a "type-constructor" which is just what? Constructor - a procedure which returns a data-structure. Now, how CL style type-tagging is fundamentally different form what Haskell does What Haskell does in no more "safer" than if I do tag-checking at runtime. (That's why CL is called a strong-typed language). So this is why it is a silly meme. The idea that compile-time checks is much better than runtime checks is also not obvious (Java's and other commercial languages nonsense about type safety aside - Java is no more safe than CL). What is better - to clutter the code with explicit type annotation or clutter the code with explicit type-tag checking in the runtime code is another question.) I personally love Lisp and Erlang with "everything is a pointer to a tagged value" semantics.
  - freyrs3 12y ago
    Safety as you're using is not the concept that Haskeller's refer to when they talk about the language. "Type safety" is a very precise term that refers to several proofs about the semantics of the language. See: http://jspha.com/posts/all_you_wanted_to_know_about_types_but_were_afraid_to_ask/#formal-terminology http://jspha.com/posts/all_you_wanted_to_know_about_types_bu...
    - dschiptsov 12y ago
      OK. All I am trying to say is that there are different kinds of strong-typed languages, and neither one is "safer" or superior.
dschiptsov 12y ago
Why, I could write such stuff too ;) http://karma-engineering.com/lab/wiki/Monads http://karma-engineering.com/lab/wiki/Monads

wyager 12y ago

>which could be implemented in almost any language. You need HKTs to have type-checked generic monads. Almost no languages have them.

wycats 12y ago
Yes, if you want type-checked generic monads. Dynamic languages can implement generic, but not type-checked monads. Many static languages can implement type-checked but non-generic monads. Now you need to show how type-checked generic monads are critical. That's much harder than showing that the monadic pattern is useful.
- tel 12y ago
  Being able to abstract over the monad leads to monad transformers of the `transformers`, `mtl`, and `extensible-effects` varieties. You can argue that those aren't valuable, but I don't think you can argue that type-checked generic monads are critical for achieving them. In practice, 75% of the time that I use monads I am using some kind of monad stack. I'm sure you can argue that this is unnecessary or that I only do so because Haskell affords it... but on the other hand, I believe that transformer stacks do a good job of elaborating the space of effect types with an efficient, expressive language. Without them you either elide side effect reification or build a lot of one-off monad stacks.
- iopq 12y ago
  Except in dynamic languages most people reinvent the wheel and don't quite get to a monadic interface. Like Javascript promises. They could have had ONE interface that is consistent. But Promises are actually a special snowflake that solves the problem in a slightly different way with a slightly different interface. And that's because nobody can complain that their stuff doesn't compile due to it not satisfying some interface.

chongli 12y ago

Why is it silly? Haskell libraries derive a lot of safety benefit out of being able to type-check different kinds of effects. One example is the STM library which uses this property to prohibit IO within an atomic transaction. Since transactions may be aborted and/or repeated, it's important to ensure no interaction with the outside world takes place within them lest these effects be repeated.

dschiptsov 12y ago
Because it has nothing to do with safety, but with manipulating of specialized data-structures. "Instantiation of a value of a given type" in Haskell is what? Calling a "type-constructor" which is just what? Constructor - a procedure which returns a data-structure. Now, how CL style type-tagging is fundamentally different form what Haskell does What Haskell does in no more "safer" than if I do tag-checking at runtime. (That's why CL is called a strong-typed language). So this is why it is a silly meme. The idea that compile-time checks is much better than runtime checks is also not obvious (Java's and other commercial languages nonsense about type safety aside - Java is no more safe than CL). What is better - to clutter the code with explicit type annotation or clutter the code with explicit type-tag checking in the runtime code is another question.) I personally love Lisp and Erlang with "everything is a pointer to a tagged value" semantics.
- freyrs3 12y ago
  Safety as you're using is not the concept that Haskeller's refer to when they talk about the language. "Type safety" is a very precise term that refers to several proofs about the semantics of the language. See: http://jspha.com/posts/all_you_wanted_to_know_about_types_but_were_afraid_to_ask/#formal-terminology http://jspha.com/posts/all_you_wanted_to_know_about_types_bu...
  - dschiptsov 12y ago
    OK. All I am trying to say is that there are different kinds of strong-typed languages, and neither one is "safer" or superior.

dschiptsov 12y ago

Why, I could write such stuff too ;) http://karma-engineering.com/lab/wiki/Monads http://karma-engineering.com/lab/wiki/Monads