On Wed, 2004-08-25 at 16:19, Tomasz Zielonka wrote: > > > > Is there anyway of getting around this? > > Perhaps you could just 'encode Id' that parts? > > Best regards, > Tom
Ok then, well it looks like this method is going to very cumbersome to use; for example a context for a reasonably simple complex data-type would be; (Hook Element t, Hook Bool t, Hook [ERS] t, Hook (Selection ERS) t, Hook ERS t, Hook (Maybe PackedString) t, Hook PackedString t, Hook IsQualified t, Hook (Ser t) t, Hook Int t, Hook (Maybe QName) t, Hook QName t) (and baring in mind most of the auto-generated code will have types namespace qualified making that humongously long). So I was thinking of another method of doing this; First of all I though of scrapping the extra type-class and just using a simple extra parameter; e.g. type Mixer a = a -> (String -> String). But this doesn't work for any sort of recursive since the a is always unified with the top-level type. Unless there's someway of getting around this? Another thought I had was to use an existentially quantified type to represent the Mix function; type Mix = forall a . a -> (String -> String) but I don't think this will allow extra constraints to be brought in. Is there any other way of doing this without another type-class? -Si. -- Simon D. Foster <[EMAIL PROTECTED]> Sheffield University _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
