Simon: as I mentioned yesterday, I think I've fixed your infinite-loop
problem.
If you can build GHC from source, or use last night's snapshot build,
you could see
if you agree that it's fixed.
Simon
| -Original Message-
| From: Simon David Foster [mailto:[EMAIL PROTECTED]
| Sent: 18 February 2005 09:36
| To: Ralf Laemmel
| Cc: GHC Users; Simon Peyton-Jones
| Subject: Re: Restricted Types and Infinite Loops
|
| On Fri, 2005-02-18 at 02:18 +0100, Ralf Laemmel wrote:
|
| Here I assume that you don't _really_ depend on ClassB to be a
| superclass of ClassA. (Why would you?)
|
| Ok, here's what the real class head is (or was before I butchered it
to
| make it work);
|
| class (Data (DictXMLData h) a, XMLNamespace a) = XMLData h a where
|
| We want to do this so that it is unnecessary to store XML Namespaces
in
| the XMLData instances (which is supposed to be for only encoding).
There
| are two reasons why this is necessary;
|
| * 1 - We have another class XSDType a, which gives types an XSD Type.
| This also depends on the types having a namespace. If we don't have
this
| class dependency, we end up with repeated data.
| * 2 - In various contexts, you will require a different namespace for
a
| particular element, but the same encoder. For example, when creating a
| SOAP Envelope, the int data-type could have the SOAP Encoding
| namespace or it could have the XSD Namespace. Further it may not have
a
| namespace at all, in which case the default instance (XMLNamespace a)
| will take over. By taking the dependency out you bind a particular
| namespace to an encoder.
|
| For now, the various encoders for XSD data-types are in the XSD
Module,
| this means that any user that wants to encode an int or string must
| import the XSD module, since we can't centralise the encoder.
|
| This is a simpler recursion scheme in terrms of class/instance
constraints.
|
| Maybe, but sadly it doesn't achieve my goal. I could do Namespaces via
a
| hook, but that makes the construction and encoding of namespace tables
| almost impossible.
|
| Thanks,
|
| -Si.
|
| --
| Simon David Foster [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
