[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
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to