5 ms·

Is the parent actually talking about associated type constructors? This: > Having "Error Exception Int" would not let you ignore the error when you try to get

• steveklabnik 6y ago
  No, I believe that they are talking about higher kinded types, but I was trying to discuss all of our movement in this general direction. ATC gives you a certain amount of what you want out of HKT, in a Rust context, anyway. > just sounds like a description of Result, which of course Rust already has. That would be "Either Exception Int", I believe they were talking about Control.Monad.Error. But maybe you are right!
• thesz 6y ago
  No, I was talking about type constructors. Haskell's Functor class sets typechecking constraints on something that can contain different types but not a realisable type in itself: class Functor f where fmap :: (a -> b) -> f a -> f b Here, "f a" is a type, for example, list or maybe or "Map key a". But constraint is on "f", a type constructor variable (an application of type "a" to a type constructor "f" gives you a type "f a": Int is a type, List is a type constructor and List Int is a list of integers). The same goes to monads - they are type constructors (can hold different types) with a class constraint (must implement two or three functions). I think you cannot write something like that in Rust: f :: Monad m => m Int -> m Int -> M String f getA getB = do { a <- getA; b <- getB; return (show (a+b))} this code will work over Result, Maybe, List, IO, STM and many other things.
  • comex 6y ago
    So you're talking about the ability to have type constructors as generic parameters, a feature usually referred to as "higher-kinded types". Indeed, Rust cannot do this yet, although it will be able to do something like it (but uglier) soon using associated type constructors (something like Haskell's type families). However, I doubt this will have much impact on error handling. For example, from your earlier post: > PS And things from this comment [1] would be very much explainable through "follow the types". > [1] https://news.ycombinator.com/item?id=24526604 https://news.ycombinator.com/item?id=24526604 They already are explainable that way. I went through and mapped the bullets there to the actual language/library features being explained in the corresponding blog post: - A method on Result - A method on Result - A method on Result - The ? operator - Existential (boxed) types - The Any trait - API design tips - How to create an ADT and implement some traits for it - The ? operator uses the From trait - Pattern matching on ADTs In short, most of it is explaining either standard library functionality, or general-purpose language features as applied to the error-handling use case. The exception is the one language feature specific to error handling, the ? operator.
    • thesz 6y ago
      You peek only one thing here. https://docs.rs/stm/0.1.2/stm/ https://docs.rs/stm/0.1.2/stm/ - the user of STM must checks for the absence of side effects, not the compiler. How about that? Will Rust compiler be able to prevent user from executing side-effecting code in STM context? Will user of Rust compiler have the same ease as with Haskell's monads?
      • masklinn 6y ago
        > How about that? Will Rust compiler be able to prevent user from executing side-effecting code in STM context? Rust is not a pure language so no, side-effects are not part of the type-system at all.
        • thesz 6y ago
          STM internally side-effecting thing. Stream processing over I/O is also side effecting thing. The point is that one should not mix and match arbitrary stream processing with arbitrary STM transactions. One should have control over when and where and compiler should prevent incorrect use (just like with borrow checker).