Record with expected fields - Haskell

My library may ask the user code to supply a product type that must have at least two types of a certain type (say, path and parsed). The user may define it as this:

data Article path parsed
  = Article
    { _article_path :: path
    , _article_parsed :: parsed
    , _article_title :: Text
    , _article_description :: Maybe Text
    }

This doesn't look right though. Is there a type sytem feature I can use to enforce this constraint? So users can define their product types however they want, except to make sure they support those two fields (which the library should be able to access)?

(The library will fill-in the rest of the fields by loading some JSON, whose structure is defined by the user, based on the fields they use)

Maybe this? http://hackage.haskell.org/package/named-records-0.5/docs/Data-NamedRecord.html

Or this: http://hackage.haskell.org/package/vinyl-0.12.0/docs/Data-Vinyl-Tutorial-Overview.html

Or maybe this: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#record-field-selector-polymorphism

I mean, I'd probably go down a DSum + Classy Lens approach, but that's just me. :slight_smile:

DSum to link a tag to a result type, and using classy lenses to make sure that the target datatype can at least return path and parsed.

A full blown extensible records may be too much weight for what you need.

@Sridhar Ratnakumar Have them provide foo :: d path parsed -> (path, parsed) method - they shouldn't be able to come up with those out of thin air, right?

@Ben Kolera I have used DSum/DMap before, but have a hard time figuring out how they fit in this case.

@TheMatten I'll try to frame the question better.

Found another library that's possibly relevant: https://github.com/i-am-tom/higgledy

Okay, an update. I ended up sidestepping this problem entirely by designing my types differently. In particular, I detached the Document type from the Markup type class. Separation of concerns, ftw. https://github.com/srid/rib/pull/51/files