Parse queries to a map of `String` to `String` using `'&'` and `'='`

[seagreen]

This would be a really useful utility function to have, though since I don't think & and = are actually part of the official URI specification I understand if you want to leave it out.

[ezrakilty]

It's a reasonable suggestion. Let me ponder it.

A consequence of the fact that those symbols are not part of the spec is that, actually, there are a few different possible interpretations of the query string. For example, you suggest using a Map String String, but multiple occurrences of a key are allowed, and some people take advantage of this. Possibly a Map String [String] would be in order... but also, conceivably the order of key occurrences could matter, so that foo=1&bar=2&baz=3 is different from foo=1&baz=3&bar=2 (same key-value pairs, different order).

Let's leave this open to allow a discussion about it, in case a consensus emerges.

[seagreen]

Great points. The thing to do (if you decide it's worth it) would probably be to make it a [(String, String)].

[JulianLeviston]

I've been working on adjustments that do this... for my own specific uses... it keeps the query as two possible states, and parses them into one of those depending on the scheme — which dictates which query param separators and query param key-value separators to use. When it parses, it pulls it into an assocation list (ie [(String, String)] if it can, otherwise just parses it as a String.

When it pretty-prints, it joins them back according to the scheme... mind you, this doesn't allow for multiple separator types independent of the scheme — I hadn't really thought about that. (ie maybe using @ isntead of = and + instead of &, which is the one I'd wanted for the scheme active, for example).

So we have:

data URIQuery
    = URIQueryString String
    | URIQueryAssocList [(String, String)]
  deriving (Eq, Ord, Typeable, Data, Generic, NFData, Show)