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
