Next version#43
Conversation
It's not actually spec conformant to have that, but if we make it a functor then `Identity` or an array/list can be substituted in as appropriate
I don't think there's an elegant way to support mongo-style multi-host (but non-spec-conformant) URIs without just handing control over entirely. Plus it reduces the number of type vars a bit, which is nice.
|
Ok, this is done at last I think! It's basically a new library at this point, but it solves a lot of problems with the existing design, at the expense of being super picky (even more so than it was before) and involving a lot of type parameters. For most uses, I would expect library users would create fully-applied type synonyms of AbsoluteURI/URI/RelativeRef/URIRef with premade options records. I think it should now be impossible to construct invalid (in the sense that they are un-parseable after printing) URIs too (aside from using the
|
This ended up not happening, as the main advantage was to be able to share some lenses between relative/hierarchical parts, etc. but some of these types are now sum types, so require |
|
Would be nice to add |
URI/AbsoluteURIrepresentation to requireScheme