[Haskell-cafe] serialize an unknown type

[Iustin Pop]

On Sun, Oct 21, 2012 at 08:11:50PM +0200, Corentin Dupont wrote:
> Hi Iustin,
> yes I want to deserialize an unknown type based on the content of the file
> (in this example).
> Let's say I can reduce the spectum of types to: Strings, all the types in
> Enum, Ints. Is it possible?

Maybe :) I don't know how to do "all the types in enum". For Strings,
Ints and Float, you could have something like: serialise a pair instead
of just the type, and decode:

data Event = EventString String | EventInt Int | EventFloat Float
…
  (kind, val) <- read in_data
  return $ case kind of
    "string" -> EventString val
	"int -> EventInt (read val)
	"float" -> EventFloat (read val)

But this is only for a very few specific types.

> My real problem is that on my web interface I want to use web routes to
> allow a user to pass an Event back to the engine.
> The problem is that it seems that web-routes only accepts Strings (or some
> known types) to be passed on the web route, whereas I need to pass random
> types.

Are you sure you need to pass random types? Can't you define a (large)
set of known types, for example?

regards,
iustin

> On Sun, Oct 21, 2012 at 8:00 PM, Iustin Pop <iusty at k1024.org> wrote:
> 
> > On Sun, Oct 21, 2012 at 07:20:10PM +0200, Corentin Dupont wrote:
> > > Hi,
> > > Sorry if it was not enough explicit.
> > > I want to write functions like this:
> > >
> > > serialize :: (Show a) => Event a -> IO ()
> > > deserialize :: (Read a) => IO () -> Event a
> > >
> > > The functions would write and read the data in a file, storing/retrieving
> > > also the type "a" I suppose...
> >
> > Can't you simply, when defining the type event, add a "deriving (Show,
> > Read)"? Then the standard (but slow) read/show serialisation would work
> > for you.
> >
> > If you're asking to de-serialise an unknown type (i.e. you don't know
> > what type it should restore a-priori, but you want to do that based on
> > the contents of the file), things become a little more complex. Unless
> > you can further restrict the type 'a', really complex.
> >
> > Maybe stating your actual problem, rather than the implementation
> > question, would be better?
> >
> > regards,
> > iustin
> >