This post is an exploration of a generic technique to effectively circumvent return type polymorphism in Haskell programs using GADTs and existential quantification.

This was already featured in the Weekly News a couple of weeks back, but I think maybe it deserves it’s own thread. I’ve tried to explain this approach to some people before, but I think this article does a much better job than I have.

I do think the “Defeating” in the title might be a little bit negative, it’s have preferred something neutral like “When your result type depends on your argument values”, but it’s still something useful to know from retaining your type safety.

This existentials and GADTs can be converted into a CPS style without type equality constraints (usually, with enough work) so that you can start from this description but use it in languages with less sophisticated type systems – as long as they have parametricity – like Haskell 2010.

  • lukewarm@kbin.social
    1·
    1 year ago

    This is probably a stupid question, but what does this trickery with GADTs and Existential Types give compared to the “normal” way?

    import Data.Int (Int8, Int16)
import Data.ByteString (ByteString)

data ParsedImage
  = ParsedAs8 (Int, Int, [Int8])
  | ParsedAs16 (Int, Int, [Int16])
  deriving Show

parseImage :: ByteString -> ParsedImage
parseImage = undefined

imageDimensions :: ByteString -> (Int, Int)
imageDimensions str =
  case parseImage str of
    ParsedAs8 (w, h, _) -> (w, h)
    ParsedAs16 (w, h, _) -> (w, h)

    Basically, the same way as a function can return an Either and everyone is happy to pattern-match on the result.

    • bss03@infosec.pubOPEnglish
      0·
      1 year ago

      The GADT allows some constructors to be safely unhandled when the type parameter is known.

      The consuming a ParsedImage, you always have to deal with both constructors. When consuming a Image px or an AnyImage, you also have to deal with both Image constructors. When consuming a Image Pixel8Bit the type system proves that it couldn’t be constructed with the Image16Bit constructor, so you only have to deal with the Image8Bit constructor.

      HTH

      • lukewarm@kbin.social
        1·
        1 year ago

        But how? Parsing function can return any of the types, we don’t know what was in the bytestring. So we’d need to deal with all variations in any case, no?

        Is the difference in that it becomes possible to pattern-match on a type of an element inside the structure, rather than on the structure as a whole? So as long as you don’t need that element, you can access elements that are common without pattern-matching? I guess it’s a marginal benefit…

        Or do I still misunderstand?

        • bss03@infosec.pubOP
          0·
          1 year ago

          Parsing function can return any of the types, we don’t know what was in the bytestring. So we’d need to deal with all variations in any case, no?

          Yes, the parsing function could return anything, but that’s not the exclusive source of values of the GADT.

          So, yes, when consuming the output of the parsing function, you have to deal with all the variations. But, when you have types that reflect some information is known about the type index, you only have to deal with the matching constructors.

          This is particularly important given the copy-paste transport of code from one context to another. You might have some code that works for a MyGADT MyType and doesn’t handle all the constructors. But, when you transport that code elsewhere and ask it to handle a MyGADT a, the type system will correctly warn you that you haven’t handled all the cases. This is an improvement over writing something like case x of { Right y -> stuff y; Left{} -> error "Can't happen; won't happen"; }, since I’m sure works fine in the right context, but doesn’t have a type that reflects what the programmer knows about x so if it is transported to a context where that information/assumption is no longer true, that’s only discovered at runtime. (This isn’t the best example, but it’s what I have for you.)

          • lukewarm@kbin.social
            1·
            1 year ago

            Well, I guess that I can see the value… Leaving copy-pasting problem aside, you might, for instance, want to have a type for a message with moderately complex envelope and a wide variety of possible payload types. It would be useful to have functions that act on the envelope, and treat payload as something opaque.

            Thanks for the conversation!