[Haskell-cafe] Re: Extensible Serialization class with type classes

[Ralf Laemmel]

[redirected to Haskell-cafe from ghc...]

I think the point is not to define your class Seriliazer,
but to define it as a generic function instead. After all,
it is kind of show (because it is serialisation).

Reading your
earlier emails, it seems a remaining problem is to keep
this function somewhat open as to allow to special cases
afterwards. This is a nice topic. Here we go.

The normal serialisation function with a serialisation result
Q is of such a type

serialise :: Data a => a -> Q

Internally such a function would be probably defined by
recursion such as

serialise = ... gmapQ serialise ...

In fact, some types would already be subject to special cases.
So we have

serialise = generic_case `extQ` specific_case1 `extQ` specific_case2 ...
 where
  generic_case = ... gmapQ serialise ...
  specific_case1 = ... % do something for my favourite type

This is exactly the code skeleton of show.

Now the question is how to make the whole business extensible.

I normally do this with a type as follows:

extensible_serialise :: Data a => (forall b. Data b => b -> Maybe Q) -> 
a -> Q

That is, there is an extra parameter for the type specific cases to
be ruled from the outside. Note the Maybe. Here, Nothing means that a
specific type is not handled by the parameter, so the normal serialise
has to be applied.


Regarding your other problem, optional types, this seems to be solvable 
as well.
Again, *don't* define this class

class XSDType a with
 where xsdType :: a -> String
       xsdNS :: a -> String

...but rather define a generic function, this time is nothing but
a type case of type

 forall x. Typeable x => x -> Maybe (String, String)


Hope it helps.

Conclusion: don't use classes, rather use generic functions.

Ralf

Simon David Foster wrote:

>On Thu, 2004-08-26 at 20:52, Ralf Laemmel wrote:
>  
>
>>Hi Simon,
>>
>>I think you should be able to succeed with Scrap your boilerplate.
>>(I am not sure that you need existentials.)
>>
>>For the overall XmlIsh style of type erasue and type validation see the 
>>XmlIsh example at:
>>http://www.cs.vu.nl/boilerplate/
>>    
>>
>
>The main requirements for the XML serializer are;
>
>1) It should be scalable; so users should be able to import a compile
>module with the basic XML infrastructure and add serializers for new
>Complex and Simple (i.e. leaf node) types.
>
>2) It should be optionally typeable; there exists several systems for
>typing an XML document, the most prominent of which is XSD. The main
>requirement is that if the XML tree is to be typed, clearly each node in
>the tree must be associated with mapping to an XSD name and name-space
>(2 Strings) or some other data items if typing by another system. The
>way I was planning on doing this was using a class; XSDType a with
>functions xsdType :: a -> String and xsdNS :: a -> String. Then at
>serialisation if a particular type and all it's constituent types were
>XSD Typeable, extra data (i.e. an extra attribute type="nsp:name") can
>(again optionally) be inserted into the tree.
>
>The XmlIsh example uses a number of functions for serialising different
>data-types down the tree. I'm not sure how scalable doing it this way
>would be; can you integrate a type-class system with it? The other
>problem is dealing with Schematic extensions, such as SOAP Arrays which
>have the requirement that the elements are always typeable but should
>not be part of the core serialiser.
>
>My other question is, section 7 only mentions polymorphic types which
>hold constraints Data, Typeable and Typeable1; can the new Generics deal
>with other polymorphic constraints? This is the main problem; the
>type-class system can deal fine with just serialisation of data-type
>content, it just doesn't seem to be able to handle an optional
>type-system.
>
>Ideally I need to produce a system where one XML namespace maps to one
>module and that module provides data-types, serialisers and typers for
>the given XML types, such that other modules which use those data-types
>themselves should be able to import that module and its serialisers to
>(heuristically) build serialisers for itself.
>
>-Si.
>
>
>
>_______________________________________________
>Glasgow-haskell-users mailing list
>Glasgow-haskell-users at haskell.org
>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>  
>