- Libraries - Haskell.org

RE: [Haskell-cafe] Can we do better than duplicate APIs? [was: Data.CompactString 0.3]
by Simon Peyton-Jones 26 Mar '07

26 Mar '07

[Probably libraries(a)haskell.org is the right list for this message, so I'm fwding your message below, and will reply there.] | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Benjamin | Franksen | Sent: 23 March 2007 22:56 | To: haskell-cafe(a)haskell.org | Cc: haskell(a)haskell.org | Subject: [Haskell-cafe] Can we do better than duplicate APIs? [was: Data.CompactString 0.3] | | [sorry for the somewhat longer rant, you may want to skip to the more | technical questions at the end of the post] | | Twan van Laarhoven wrote: | > I would like to announce version 0.3 of my Data.CompactString library. | > Data.CompactString is a wrapper around Data.ByteString that represents a | > Unicode string. This new version supports different encodings, as can be | > seen from the data type: | > | > [...] | > | > Homepage: http://twan.home.fmf.nl/compact-string/ | > Haddock: http://twan.home.fmf.nl/compact-string/doc/html/ | > Source: darcs get http://twan.home.fmf.nl/repos/compact-string | | After taking a look at the Haddock docs, I was impressed by the amount of | repetition in the APIs. Not ony does Data.CompactString duplicate the whole | Data.ByteString interface (~100 functions, adding some more for encoding | and decoding), the whole interface is again repeated another four times, | once for each supported encoding. | | Now, this is /not/ meant as a criticism of the compact-string package in | particular. To the contrary, duplicating a fat interface for almost | identical functionality is apparently state-of-the-art in Haskell library | design, viz. the celebrated Data.Bytesting, whose API is similarly | repetitive (see Data.List, Data.ByteString.Lazy, etc...), as well as | Map/IntMap/SetIntSet etc. I greatly appreciate the effort that went into | these libraries, and admire the elegance of the implementation as well as | the stunning results wrt. efficiency gains etc.. However I fear that | duplicating interfaces in this way will prove to be problematic in the long | run. | | The problems I (for-)see are for maintenance and usability, both of which | are of course two sides of the same coin. For the library implementer, | maintenance will become more difficult, as ever more of such 'almost equal' | interfaces must be maintained and kept in sync. One could use code | generation or macro expansion to alleviate this, but IMO the necessity to | use extra-language pre-processors points to a weakness in the language; it | be much less complicated and more satisfying to use a language feature that | avoids the repetition instead of generating code to facilitate it. On the | other side of teh coin, usability suffers as one has to lookup the (almost) | same function in more and more different (but 'almost equal') module | interfaces, depending on whether the string in question is Char vs. Byte, | strict vs. lazy, packed vs. unpacked, encoded in X or Y or Z..., especially | since there is no guarantee that the function is /really/ spelled the same | everywhere and also really does what the user expects.(*) | | I am certain that most, if not all, people involved with these new libraries | are well aware of these infelicities. Of course, type classes come to mind | as a possible solution. However, something seems to prevent developers from | using them to capture e.g. a common String or ListLike interface. Whatever | this 'something' is, I think it should be discussed and addressed, before | the number of 'almost equal' APIs becomes unmanageable for users and | maintainers. | | Here are some raw ideas: | | One reason why I think type classes have not (yet) been used to reduce the | amount of API repetition is that Haskell doesn't (directly) support | abstraction over type constraints nor over the number of type parameters | (polykinded types?). Often such 'almost equal' module APIs differ in | exactly these aspects, i.e. one has an additional type parameter, while yet | another one needs slightly different or additional constraints on certain | types. Oleg K. has shown that some if these limitations can be overcome w/o | changing or adding features to the language, however these tricks are not | easy to learn and apply. | | Another problem is the engineering question of how much to put into the | class proper: there is a tension between keeping the class as simple as | possible (few methods, many parametric functions) for maximum usability vs. | making it large (many methods, less parametric functions) for maximum | efficiency via specialized implementations. It is often hard to decide this | question up front, i.e. before enough instances are available. (This has | been stated as a cause for defering the decision for a common interface to | list-like values or strings). Since the type of a function doesn't reveal | whether it is a normal function with a class constraint or a real class | method, I imagine a language feature that (somehow) enables me to | specialize such a function for a particular instance even if it is not a | proper class member. | | Or maybe we have come to the point where Haskell's lack of a 'real' module | system, like e.g. in SML, actually starts to hurt? Can associated types | come to the rescue? | | Cheers | Ben | -- | (*) I know that strictly speaking a class doesn't guarantee any semantic | conformance either, but at least there is a common place to document the | expected laws that all implementations should obey. With duplicated module | APIs there is no such single place. | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

compare on Double
by Ian Lynagh 24 Mar '07

24 Mar '07

Hi all, Proposal: http://hackage.haskell.org/trac/ghc/ticket/1239 Consider: let n = 0/0 :: Double in (n `compare` n, n < n, n == n, n > n) In GHC and YHC this gives (GT,False,False,False) while in hugs it gives (EQ,False,False,False) Neither of these is very satisfactory, as I would expect x `compare` y === EQ => (x == y) === True x `compare` y === GT => (x > y) === True and it's even less pleasant that the implementations differ for no good reason. The Haskell report isn't very helpful on how comparing exceptional Doubles should behave, as it doesn't even say you need to have NaN etc: http://haskell.org/onlinereport/basic.html#sect6.4 The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types are undefined; an implementation may choose error (_|_, semantically), a truncated value, or a special value such as infinity, indefinite, etc. I think that the right answer is that n `compare` n above (and more generally such a comparison for any incomparable Doubles or Floats) should raise an error (i.e. be _|_). The changes needed are simple, e.g. for GHC (D# x) `compare` (D# y) | x <## y = LT | x ==## y = EQ | otherwise = GT becomes (D# x) `compare` (D# y) | x <## y = LT | x ==## y = EQ | x >## y = GT | otherwise = error "Incomparable values" Deadline: 1 week after discussion ends. Thanks Ian

10 14

Proposal: Add Text.PrettyPrint.HughesPJ.zeroText
by Neil Mitchell 24 Mar '07

24 Mar '07

Hi I propose the addition of zeroText to the HughesPJ pretty printer. Ticket number 1217 has been opened for this issue. [Add zeroText to Text.PrettyPrint.HughesPJ Neil Mitchell <http://www.cs.york.ac.uk/~ndm/>**20070313023534] { hunk ./Text/PrettyPrint/HughesPJ.hs 177 - char, text, ptext, + char, text, ptext, zeroText, hunk ./Text/PrettyPrint/HughesPJ.hs 263 +-- | Some text, but without any width. Use for non-printing text +-- such as a HTML or Latex tags +zeroText :: String -> Doc + hunk ./Text/PrettyPrint/HughesPJ.hs 595 +zeroText s = textBeside_ (Str s) 0 Empty } Currently using the pretty printer it is impossible to output pretty HTML - <b>name</b> takes up 7+4 letters in width, instead of the 4 it really takes. With zeroText the "<b>" can be constructed to take up no space. This method is essential, and cannot otherwise be implemented without breaking the abstraction of the library. The Yhc project has cloned HughesPJ with this 5 line change as a result - moving back to the base version is preferable. Please discuss. Deadline is a week after discussion stops. Thanks Neil

5 6

[trac@galois.com: Re: [GHC] #1218: Add sortNub and sortNubBy to Data.List]
by dons＠cse.unsw.edu.au 23 Mar '07

23 Mar '07

I propose we *do not* change the api to add the special case: sortNub = sort . nub = map head . group . sort and instead add a rewrite rule to Data.List to provide this optimisation. {-# RULES "sort/nub" sort . nub = map head . group . sort #-} Along with a QuickCheck property to test it: prop_sortnub xs = sort (nub xs) == map head (group (sort xs)) -- Don ----- Forwarded message from GHC <trac(a)galois.com> ----- Date: Sun, 18 Mar 2007 23:51:50 -0000 From: GHC <trac(a)galois.com> To: glasgow-haskell-bugs(a)haskell.org Subject: Re: [GHC] #1218: Add sortNub and sortNubBy to Data.List #1218: Add sortNub and sortNubBy to Data.List ----------------------------+----------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by dons): How about rather than changing the api, purely for efficiency reasons, we just add a rewrite rule to Data.List for this optimisation? The rule would be: {{{ {-# RULES "sort/nub" sort . nub = map head . group . sort #-} }}} sort . nub will be rewritten to the optimised case, and we won't need to further complicate the API. Quite often now it is possible for the library author to expose only a small, generic API, while providing internal rules for specific optimised cases. This keeps the interface small, while still providing performance. Data.ByteString does this in a number of places, for example: {{{ {-# RULES "FPS specialise filter (== x)" forall x. filter (== x) = filterByte x #-} }}} I'd really not like to see more functions exposed in the list interface, only as optimisations, that could be better provided via RULES. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ----- End forwarded message -----

8 23

Re[2]: Adding System.FilePath
by Bulat Ziganshin 20 Mar '07

20 Mar '07

Hello Artem, Friday, March 16, 2007, 12:09:49 PM, you wrote: > Unlike a lot of other languages (like Java) which grow incrementally, > heaving the whole lot of old baggage in their library API, GHC base is > allowed to evolve its interfaces (and yes, that breaks compatibility). I > think it is a healthy approach, while the Java approach might bloat it > to death (sadly, as i'm a Java user; at least the bytecode seem remains > in good shape). > Sorry if it seem like offtopic, but i think the ability of GHC base to > evolve, instead of just bloating away, is vital. this creates problems for developers and users. for example, program developed 3 years ago, may be easily incompatible with current ghc version instead, i propose to keep evolving things outside of base, which will allow to use any version of any library with any ghc version. if you build something written in times of ghc 6.2 - you use old version of library. if you build something more modern - you use newer version. cabal automatically handles keeping of multiple versions of same library and using proper version for each build. this technology provides us *both* evolving of libraries and compatibility with old versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

4 13

Data.IntMap.findMax is missing
by Christian Maeder 18 Mar '07

18 Mar '07

recently I've switched from "Data.Map.Map Int" to "Data.IntMap.IntMap", but I was disappointed because I did not find a function that would yield the maximum key faster than in linear time, i.e. O(log n). In fact the whole "Min/Max" section is missing in Data.IntMap (resp. Data.IntSet) compared to Data.Map (resp. Data.Set). (The section "Indexed" is also only in Data.Map.) Would somebody care to fix this? Cheers Christian

2 2

recursive programming in applicative functors?
by Conal Elliott 17 Mar '07

17 Mar '07

Is there a fixpoint operator for applicative functors, like mfix for MonadFix and loop for ArrowLoop?

3 2

Re[2]: Adding System.FilePath
by Bulat Ziganshin 16 Mar '07

16 Mar '07

Hello Artem, > With FPS i did use the library with GHC 6.4 by fetching and installing > it via Cabal, and with GHC 6.6 it is shipped (thanks for that!). The > same might be done to FilePath: those who need it before GHC 6.8 will > fetch and install it manually (or via hackage), and those who use GHC > 6.8 will have it out of the box. > P.S. > I think it should be possible to install the fresh version of FPS and > GHC compiler should be smart enough to link both the old version (if it > is required by some other part of the base) and the new one... well, i should explain the situation. first, there is no problem to include FPS as *separate* library in GHC and actually 6.6 provides lots of such libs (including ones that was not shipped with 6.4). you don't need to download/install these libraries too FPS is different - it was made a part of base library and this means 1) that .cabal files for libs/apps that uses fps should be different for ghc 6.4 and 6.6 2) that i can't upgrade to newer fps versions 3) that fps versions with api changes can't be used at all with 6.6! all that i propose is to detach fps from base lib and ship it as separate library *together* with ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

darcs patch: add hashbang header to Setup.hs
by Ketil Malde 16 Mar '07

16 Mar '07

Thu Mar 15 15:57:23 CET 2007 Ketil Malde <ketil(a)ii.uib.no> * add hashbang header to Setup.hs

2 2

Re: ANN: HSH 1.2.0
by Simon Marlow 16 Mar '07

16 Mar '07

Neil Mitchell wrote: > Hi > >> There are a couple of things about that function... >> >> First, I did see it, but its description is rather vague on what it >> does. From the description, it sounds like it is possible that it >> would not return an absolute path; I read it more as expanding >> symlinks. If it does indeed return an absolute path, I think that >> should be stated explicitly for clarity. > > More fatally it's only implemented on GHC, not for any reason, but > because whoever originally implemented it only used GHC! It's > explicitly #ifdef'd to do nothing (just a return) on other compilers. > I also hate the name. I know plenty of people who wanted the function, > but none who ever found it... I note that the deadline for discussion of System.FilePath has now passed (well, a long time ago :-), so it looks like it's going into base. Any final objections before we do this? Regarding canonicalizePath, I'd be perfectly happy to change its name and/or somehow make it more easily discoverable: does anyone want to make a proposal? Cheers, Simon

7 17