[Haskell-cafe] Re: Extensible Serialization class with type classes
Ralf.Laemmel at cwi.nl
Thu Aug 26 20:02:38 EDT 2004
[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).
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 ...
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
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.
Simon David Foster wrote:
>On Thu, 2004-08-26 at 20:52, Ralf Laemmel wrote:
>>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:
>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
>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.
>Glasgow-haskell-users mailing list
>Glasgow-haskell-users at haskell.org
More information about the Haskell-Cafe