
On 21 June 2011 02:02, Jeremy Shaw
On Mon, Jun 20, 2011 at 6:12 PM, Christopher Done
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.