From abela at chalmers.se Sat Oct 4 15:44:28 2014 From: abela at chalmers.se (Andreas Abel) Date: Sat, 4 Oct 2014 17:44:28 +0200 Subject: Several default implementations for instance methods Message-ID: <543015DC.8020506@chalmers.se> Consider the following class for an overloaded pretty printer. For atomic data (numeric types, String etc.) one would implement prettyShow, for complex data either pretty or prettyPrec. > import Text.PrettyPrint > > class Pretty a where > pretty :: a -> Doc > prettyShow :: a -> String > prettyPrec :: Int -> a -> Doc Implementing one of these methods should be enough, giving default implementations for the other two. It is easy to get prettyShow and prettyPrec from pretty. > prettyShow = render . pretty > prettyPrec = const . pretty However, to define pretty from one of the others, I need two default implementations. > pretty = text . prettyShow > pretty = prettyPrec 0 Is there a way to get this to work? Workarounds (not entirely satisfactory): Technically, one could define a cycle of default implementations. Alternative 1: > pretty = prettyPrec 0 > prettyShow = render . pretty > prettyPrec _ = text . prettyShow Problem: Here, if pretty is defined, > prettyPrec _ = text . render . pretty instead of just > prettyPrec _ = pretty and (text . render) is not the identity (destroys inner document structure). Alternative 2: > pretty = text . prettyShow > prettyShow = render . prettyPrec 0 > prettyPrec _ = pretty Problem: Here, if prettyPrec is defined, > pretty = text . render . prettyPrec 0 instead of just > pretty = prettyPrec 0 I guess alternative 2 is worse than alternative 1, as one would usually define prettyPrec to get pretty, and not the otherway round. But none of these two alternatives really does the job. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From carter.schonwald at gmail.com Sat Oct 4 16:05:30 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 4 Oct 2014 12:05:30 -0400 Subject: [Haskell-cafe] Several default implementations for instance methods In-Reply-To: <543015DC.8020506@chalmers.se> References: <543015DC.8020506@chalmers.se> Message-ID: hrm, so youre wanting something even smarter than the MINIMAL pragma stuff, namely "depending on which subset of the complementary methods are defined, define this method differently"? On Sat, Oct 4, 2014 at 11:44 AM, Andreas Abel wrote: > Consider the following class for an overloaded pretty printer. For > atomic data (numeric types, String etc.) one would implement > prettyShow, for complex data either pretty or prettyPrec. > > > import Text.PrettyPrint > > > > class Pretty a where > > pretty :: a -> Doc > > prettyShow :: a -> String > > prettyPrec :: Int -> a -> Doc > > Implementing one of these methods should be enough, giving default > implementations for the other two. > > It is easy to get prettyShow and prettyPrec from pretty. > > > prettyShow = render . pretty > > prettyPrec = const . pretty > > However, to define pretty from one of the others, I need two default > implementations. > > > pretty = text . prettyShow > > pretty = prettyPrec 0 > > Is there a way to get this to work? > > Workarounds (not entirely satisfactory): Technically, one could define > a cycle of default implementations. Alternative 1: > > > pretty = prettyPrec 0 > > prettyShow = render . pretty > > prettyPrec _ = text . prettyShow > > Problem: Here, if pretty is defined, > > > prettyPrec _ = text . render . pretty > > instead of just > > > prettyPrec _ = pretty > > and (text . render) is not the identity (destroys inner document > structure). > > Alternative 2: > > > pretty = text . prettyShow > > prettyShow = render . prettyPrec 0 > > prettyPrec _ = pretty > > Problem: Here, if prettyPrec is defined, > > > pretty = text . render . prettyPrec 0 > > instead of just > > > pretty = prettyPrec 0 > > I guess alternative 2 is worse than alternative 1, as one would > usually define prettyPrec to get pretty, and not the otherway round. > But none of these two alternatives really does the job. > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www2.tcs.ifi.lmu.de/~abel/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Oct 4 16:17:40 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 4 Oct 2014 12:17:40 -0400 Subject: [Haskell-cafe] Several default implementations for instance methods In-Reply-To: References: <543015DC.8020506@chalmers.se> Message-ID: On Sat, Oct 4, 2014 at 12:05 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > hrm, so youre wanting something even smarter than the MINIMAL pragma > stuff, namely > "depending on which subset of the complementary methods are defined, > define this method differently"? > I've been expecting someone to ask for that ever since MINIMAL was floated.... (In fact I more than half expected MINIMAL to vanish under a bikeshed with that as its frame.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: