1429
Golang be like (i.imgur.com)
submitted 3 years ago by to c/programmer_humor@programming.dev
137 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 6 points 3 years ago (3 children)

The exception handling question mark, spelled ? and abbreviated and pronounced eh?, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can't do foo()?.bar()?.baz()? in Haskell so it's only theoretical purity which is half-arsed, not ergonomics.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 2 years ago (1 child)

    It's not a half-arsed copy, it's borrowing a limited subset of HKT for a language with very different goals. Haskell can afford a lot of luxuries that Rust can't.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago

    It's a specialised syntax transformation that has nothing to do with HKTs, or the type system in general. Also HKTs aren't off the table it's just that their theory isn't exactly trivial in face of the rest of Rust's type system but we already have GATs.

    It actually wouldn't be hard writing a macro implementing do-notation that desugars to and_then calls on a particular type to get some kind of generic code (though of course monomorphised), but of course that would be circumventing the type system.

    Anyhow my point stands that how Rust currently does it is imitating all that Haskell goodness on a practical everyday coding level but without having (yet) to solve the hard problem of how to do it without special-cased syntax sugar. With proper monads we e.g. wouldn't need to have separate syntax for async and ?

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago* (1 child)

    Note: Lemmy code blocks don't play nice with some symbols, specifically < and & in the following code examples

    This isn't a language level issue really though, Haskell can be equally ergonomic.

    The weird thing about ?. is that it's actually overloaded, it can mean:

    • call a function on A? that returns B?
    • call a function on A? that returns B

    you'd end up with B? in either case

    Say you have these functions

    toInt :: String -> Maybe Int

double :: Int -> Int

isValid :: Int -> Maybe Int

    and you want to construct the following using these 3 functions

    fn :: Maybe String -> Maybe Int

    in a Rust-type syntax, you'd call

    str?.toInt()?.double()?.isValid()

    in Haskell you'd have two different operators here

    str >>= toInt &lt;&amp;> double >>= isValid

    however you can define this type class

    class Chainable f a b fb where
    (?.) :: f a -> (a -> fb) -> f b

instance Functor f => Chainable f a b b where
    (?.) = (&lt;&amp;>)

instance Monad m => Chainable m a b (m b) where
    (?.) = (>>=)

    and then get roughly the same syntax as rust without introducing a new language feature

    str ?. toInt ?. double ?. isValid

    though this is more general than just Maybes (it works with any functor/monad), and maybe you wouldn't want it to be. In that case you'd do this

    class Chainable a b fb where
    (?.) :: Maybe a -> (a -> fb) -> Maybe b

instance Chainable a b b where
    (?.) = (&lt;&amp;>)

instance Chainable a b (Maybe b) where
    (?.) = (>>=)

    restricting it to only maybes could also theoretically help type inference.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago* (last edited 2 years ago)

    I was thinking along the lines of "you can't easily get at the wrapped type". To get at b instead of Maybe b you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they're awkward in a monadic context) whereas Rust will gladly hand you that b in the middle of an expression, and doesn't force you to name the point.

    Or to give a concrete example, if foo()? {...} is rather awkward in Haskell, you end up writing things like

    foo x y = bar >>= baz x y
  where
    baz x y True = x
    baz x y False = y

    , though of course baz is completely generic and can be factored out. I think I called it "cap" in my Haskell days, for "consequent-alternative-predicate".

    Flattening Functors and Monads syntax-wise is neat but it's not getting you all the way. But it's the Haskell way: Instead of macros, use tons upon tons of trivial functions :)

  • permalink
  • fedilink
  • source
  • parent