Restricted Types and Infinite Loops

Keean Schupke k.schupke at imperial.ac.uk
Fri Feb 18 04:41:37 EST 2005


Having looked at some of my source code this relies on Data having a
functional dependancy such that:

    class Data d a | d -> a ...

So it might not work for what you want.

    Keean.


Keean Schupke wrote:

> I seem to remember that if you define the class:
>
> class DictXMLData h => XMLData h ...
>
> instance (Data d a,XMLNamespace a) => XMLData d where ...
>
> then providing you annotate the instance functions with the relavent
> scoped type variables (d and a) then the compiler will infer XMLNamespace
> correctly for those instances that use it from the XMLData constraint.
>
>    Keean.
>
> Simon David Foster wrote:
>
>> 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.
>>
>>  
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




More information about the Glasgow-haskell-users mailing list