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

Vladimir Zlatanov vlado at dikini.net
Mon Jun 20 13:37:56 CEST 2011

>> expressions possible. For example having a compound page with several
>> different posts in it, expressed in the url. This language gives
>> control to the user to express exactly what content they want combined
>> and how. This power is often under estimated. The scenarios are too
>> many to mention.
> For example? What's an example of a compound page, expressed in the url?

Ok. Let's try. I'll simplify it a bit. This will assume that we have a
product combinator type

data Comb a b = Comb { left::a, right::b } deriving (Data,Typeable,Show)

Let's have a page which includes two different pieces of content side
by side, let's say product comparison.

The product type could be something like

data Product = Prouct { productId::Integer }

We should be able to form values of type

type TwoProducts = Comb Product Product

That type could be expressed in a URL like:

The whole idea is to have the primitive resources as types, and to
provide the the necessary combinators - product, and maybe a sum one.

>> data Event = Event { eventId     :: Maybe Integer -- ^ The event id.
>>                    , eventScope  :: Bool          -- ^ Show the scope?
>>                    , eventLayout :: Layout        -- ^ Layout for the page.
>>                    , eventRec :: Rec
>>                    }
>> deriving (Data,Typeable,Show)
>> data Rec = Rec { one :: Int, two :: Int }    deriving (Data,Typeable,Show)
>> Would it be possible to express the above in a URL? I understand that
>> at the moment it is not, but what are your thoughts on how far it
>> would be reasonable to push the encoding.
> How would you expect that to be represented? I thought a little about
> it… it seems like if it was
>> data Rec = Rec { one :: Int, two :: Int }    deriving (Data,Typeable,Show)
> Then you could represent it as
> /event/id/1/one/a/two/b
> or
> /event/id/1/rec-one/a/rec-two/b
> The former could be a problem as it may lead to ambiguities, unless
> you decided that sub-types' fields would have precedence?

To be honest I'm not sure. But if we use '/' as white space, and have
only left associativie combinators/constructors, with no variadic
arguments, the result should be unambiguous. It will be possibly
comprehendible (is it a word?) by humans for short urls.

I would use the constructors like:


This makes it unambiguous what we mean, in case we have the same field
names, but slightly more verbose.


would work as well, but you need the source or specs to read it

More information about the web-devel mailing list