-
Notifications
You must be signed in to change notification settings - Fork 23
Next version #43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
/AbsoluteURI
representation to requireScheme