[web-devel] ANN: url-generic-0.1: Parse/format generic key/value URLs from record data types.

[Christopher Done]

On 21 June 2011 02:02, Jeremy Shaw <jeremy at n-heptane.com> wrote:
> On Mon, Jun 20, 2011 at 6:12 PM, Christopher Done
> <chrisdone at googlemail.com> wrote:
>>> You allow the fields to be specified in any order -- but that makes it
>>> difficult to support record types that contain other record types,
>>> doesn't it?
>>
>> Does it? Why?
>>
>> /foo/x/1/y/a/1/b/2/z/2 seems no more ambiguous than /foo/y/b/1/a/2/z/2/x/1
>>
>> I'd think the problem stopping embedded types is optional fields.
>
> Yeah actually, it should work out ok. But you will need to take a
> rather different approach to parsing.
>
> It just won't be fun to write the code. But that is your job not mine :p

Sure. :-)

> So, the current SYB stuff is going to have issues with this I think.

Of course, I had no intention for embedded types. That idea came from
you guys later. The current parser clearly wouldn't work at all.

> We have to be careful to handle the cases where the incoming url is
> missing a field or (incorrectly) has a field twice.

You mean accepting URLs with missing fields? I think missing fields
could make the whole embedded types thing ambiguous:

data Foo = Foo { fooRed :: Integer, fooBar :: Bar, fooBlue :: Integer }

data Bar = Bar { barYellow :: Integer, barBlue :: Maybe Integer }

/foo/red/123/bar/yellow/678/blue/999

What does blue refer to? If we take it to parse the inner one first,
then suddenly order matters. So we either need to have order matter or
remove optional parameters, or somehow put up with this. Tricky.