5 ms·

This looks really nice. I've been wanting to get into clojure (mainly for the web aspect of it) for a while, but as someone who hasn't done much lisp and reall

This looks really nice. I've been wanting to get into clojure (mainly for the web aspect of it) for a while, but as someone who hasn't done much lisp and really loves Haskell's type system I've been hanging back a bit. I'm assuming that clojurescript will also work fine with this?

dsabanin 13y ago
Yes.
kenko 13y ago
This doesn't get you anything like the expressive power of Haskell's type system, though.
- swannodette 13y ago
  If you're going to make such a claim can you explain the capabilities, tradeoffs, and limitations of Haskell's support for typed records over what Typed Clojure provides?
  - kenko 13y ago
    No, I can't. I claimed that Typed Clojure doesn't get you the expressive power of Haskell's type system. I understand that Typed Clojure has some sophisticated facilities for refining types, and (e.g.) tracking what keys a map has, and lots of other neat stuff. This does not seem to me to increase the expressivity of the language, whereas Haskell's type system does (well, since I don't think one can separate Haskell into the language on the one hand and its type system on the other, it's misleading to talk about Haskell's type system increasing its expressivity). (I just about plotzed when I saw the definitions for `eval` and `view` in <http://okmij.org/ftp/tagless-final/course/Intro2.hs>. http://okmij.org/ftp/tagless-final/course/Intro2.hs>.) Everyone who writes a monad library for Clojure, for instance, has to take special measures to implement a properly polymorphic "return", or punts and doesn't do it. If Typed Clojure let me annotate `(return 5)` [ETA: or annotate something dynamically enclosing `(return 5)` with something that would force the given interpretation of the return call] with the type list of integer, or maybe integer, or whatever, and have it actually evaluate to [5] or #<Just 5>, or whatever, that would be great. AFAICT, it doesn't do that.
    - brandonbloom 13y ago
      > This does not seem to me to increase the expressivity of the language, whereas Haskell's type system does Some of us don't view that as a wanted feature. I wrote more optional/modular/pluggable type systems before. See: https://news.ycombinator.com/item?id=6196466 https://news.ycombinator.com/item?id=6196466 > polymorphic "return", or punts and doesn't do it Haskell's type inferencer is doing a "search" for a type that fits and slotting that in there as an implicit argument. An error occurs if two match and you need to provide a type signature to differentiate. You could do precisely the same thing using first-class type objects, which Clojure has. Haskell has finally added them too, but required a compiler change. (See: Typeable). That's how type classes work in general: A dictionary of methods has to be threaded through, unless the compiler can prove that the dictionary is a constant. Clojure does the same thing by embedding a pointer to that data in the first-class function object. Let's assume I have a typed module. I could trivially query that module, since the type descriptions are data. That's what the Haskell compiler is doing, but with first-class types, I can do it myself. There is no reason that a user-level macro can't add enough inference to perform polymorphic returns. But even if I could do this, I wouldn't want to. At most, I'd want an "infer-monad" form where I can explicitly say that I'm using my types to convey intent and am willing to pay the cost of coupling my program to a particular type system.
      - kenko 13y ago
        > Some of us don't view that as a wanted feature. No doubt! But someone who was describing his or her fondness for Haskell's type system---the person I was initially responding to---probably does. I'm familiar (though not intimately familiar) with the idea of dictionary passing and with the fact that type classes are implemented that way. I'm not sure what the point of the remark in the present context is, though. I gather that you aren't a fan of the compiler doing this for you. (I'm not precisely sure what you mean by first-class type objects here, given the mention of Data.Typeable; concretely, I'm aware of three monad libraries that offer something like a polymorphic return and I know how two of them do it; one with symbol macros and regular old maps, and one that (in the presently released version) uses a run-monad function that threads through a regular old map. You presumably are thinking of something else; if so, I'd be glad to know what it is.) > There is no reason that a user-level macro can't add enough inference to perform polymorphic returns. Well, if you say so. I can't quite picture how this would work as a macro, but I'm not going to deny it can be done on that ground. FWIW, regarding your last sentence, I find the idea of a program separate from a particular type system kind of hard to grasp.
  - deleted 13y ago
    [deleted]

dsabanin 13y ago

Yes.

kenko 13y ago

This doesn't get you anything like the expressive power of Haskell's type system, though.

swannodette 13y ago
If you're going to make such a claim can you explain the capabilities, tradeoffs, and limitations of Haskell's support for typed records over what Typed Clojure provides?
- kenko 13y ago
  No, I can't. I claimed that Typed Clojure doesn't get you the expressive power of Haskell's type system. I understand that Typed Clojure has some sophisticated facilities for refining types, and (e.g.) tracking what keys a map has, and lots of other neat stuff. This does not seem to me to increase the expressivity of the language, whereas Haskell's type system does (well, since I don't think one can separate Haskell into the language on the one hand and its type system on the other, it's misleading to talk about Haskell's type system increasing its expressivity). (I just about plotzed when I saw the definitions for `eval` and `view` in <http://okmij.org/ftp/tagless-final/course/Intro2.hs>. http://okmij.org/ftp/tagless-final/course/Intro2.hs>.) Everyone who writes a monad library for Clojure, for instance, has to take special measures to implement a properly polymorphic "return", or punts and doesn't do it. If Typed Clojure let me annotate `(return 5)` [ETA: or annotate something dynamically enclosing `(return 5)` with something that would force the given interpretation of the return call] with the type list of integer, or maybe integer, or whatever, and have it actually evaluate to [5] or #<Just 5>, or whatever, that would be great. AFAICT, it doesn't do that.
  - brandonbloom 13y ago
    > This does not seem to me to increase the expressivity of the language, whereas Haskell's type system does Some of us don't view that as a wanted feature. I wrote more optional/modular/pluggable type systems before. See: https://news.ycombinator.com/item?id=6196466 https://news.ycombinator.com/item?id=6196466 > polymorphic "return", or punts and doesn't do it Haskell's type inferencer is doing a "search" for a type that fits and slotting that in there as an implicit argument. An error occurs if two match and you need to provide a type signature to differentiate. You could do precisely the same thing using first-class type objects, which Clojure has. Haskell has finally added them too, but required a compiler change. (See: Typeable). That's how type classes work in general: A dictionary of methods has to be threaded through, unless the compiler can prove that the dictionary is a constant. Clojure does the same thing by embedding a pointer to that data in the first-class function object. Let's assume I have a typed module. I could trivially query that module, since the type descriptions are data. That's what the Haskell compiler is doing, but with first-class types, I can do it myself. There is no reason that a user-level macro can't add enough inference to perform polymorphic returns. But even if I could do this, I wouldn't want to. At most, I'd want an "infer-monad" form where I can explicitly say that I'm using my types to convey intent and am willing to pay the cost of coupling my program to a particular type system.
    - kenko 13y ago
      > Some of us don't view that as a wanted feature. No doubt! But someone who was describing his or her fondness for Haskell's type system---the person I was initially responding to---probably does. I'm familiar (though not intimately familiar) with the idea of dictionary passing and with the fact that type classes are implemented that way. I'm not sure what the point of the remark in the present context is, though. I gather that you aren't a fan of the compiler doing this for you. (I'm not precisely sure what you mean by first-class type objects here, given the mention of Data.Typeable; concretely, I'm aware of three monad libraries that offer something like a polymorphic return and I know how two of them do it; one with symbol macros and regular old maps, and one that (in the presently released version) uses a run-monad function that threads through a regular old map. You presumably are thinking of something else; if so, I'd be glad to know what it is.) > There is no reason that a user-level macro can't add enough inference to perform polymorphic returns. Well, if you say so. I can't quite picture how this would work as a macro, but I'm not going to deny it can be done on that ground. FWIW, regarding your last sentence, I find the idea of a program separate from a particular type system kind of hard to grasp.
- deleted 13y ago
  [deleted]