2008-10-11 Hackage status with GHC 6.10

Daily update of the state of Hackage wrt. GHC 6.10 release candidates.

Lots of packages were updated today, Cabal 1.6 and cabal-install 0.6
were also put out. Things are in a good shape.

Note that you'll need a "soft dep" in your cabal index file,

    base < 4
    parsec < 3
    HaXml == 1.13.*
    QuickCheck < 2

for best results.

Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 684 libraries
and apps tried in total,

      1 UnpackFailed
      2 DownloadFailed
      2 InstallFailed
     16 ConfigureFailed
     74 DependencyFailed
    134 BuildFailed
    455 InstallOk

Compared to GHC 6.8.x's results, there are now *48* packages that
produce different results, or *6%* (down 2% from yesterday).

The most common issues are,

Re: A general question about the use of classes in defining interfaces

On Wed, Oct 08, 2008 at 12:36:02PM +0200, S. Doaitse Swierstra wrote:
> Stimulated by remarks made during the discussion on the future of  
> Haskell at the last Haskell Symposium, I have started to convert my new 
> parsing library (constructed for the Lernet summerschool in Uruguay) into 
> Cabalised form. In this library I have amongst others the class:
>
> class  Applicative p where
>   (<*>)     ::   p (b -> a)  -> p b   ->   p a
>   (<|>)     ::   p a         -> p a   ->   p a
>   (<$>)     ::   (b -> a)    -> p b   ->   p a
>   pReturn   ::   a                    ->   p a
>   pFail     ::                             p a
>   f <$> p   =  pReturn f <*> p
>
> which extends/deviates from the standard class Applicative, since I  
> think these functions more or less belong together. I am happy to factor 
> out <|> into a separate class.

This corresponds to Alternative, a subclass of Applicative (except for <$>
being a function instead of a method).  They certainly belong together
for parsers, but there are applicative functors that don't have the
extra monoidal structure.

> The problem which arises now is when I want to use the class Applicative
> as it is now defined in Control.Applicative. Functions like <$>, <$, <*
> and many have standard implementations in terms of the basic function pure
> and <*>. Although this looks fine at first sight, this is not so fine if
> we want to give more specialised (optimised, checking) implementations,
> as I am doing in my library. An example of this is e.g. in many, where
> I want to check that the parameter parser does not recognise the empty

A general question about the use of classes in defining interfaces

Stimulated by remarks made during the discussion on the future of  
Haskell at the last Haskell Symposium, I have started to convert my  
new parsing library (constructed for the Lernet summerschool in  
Uruguay) into Cabalised form. In this library I have amongst others  
the class:

class  Applicative p where
  (<*>)     ::   p (b -> a)  -> p b   ->   p a
  (<|>)     ::   p a         -> p a   ->   p a
  (<$>)     ::   (b -> a)    -> p b   ->   p a
  pReturn   ::   a                    ->   p a
  pFail     ::                             p a
  f <$> p   =  pReturn f <*> p

which extends/deviates from the standard class Applicative, since I  
think these functions more or less belong together. I am happy to  
factor out <|> into a separate class.

The problem which arises now is when I want to use the class  
Applicative as it is now defined in Control.Applicative. Functions  
like <$>, <$, <* and many have standard implementations in terms of  
the basic function pure and <*>. Although this looks fine at first  
sight, this is not so fine if we want to give more specialised  
(optimised, checking) implementations, as I am doing in my library. An  
example of this is e.g. in many, where I want to check that the  
parameter parser does not recognise the empty sequence since thi is  
non-sense, etc. Of course we can describe <* by

p <* q = pure const <*> p <*> q

cabal-install, ghc-6.10

Does cabal-install work with ghc-6.10? Not out-of-the box it seems.
With a recent 6.10 binary snapshot (containing Cabal-1.5.5), I get

Configuring cabal-install-0.5.2...
Setup: At least the following dependencies are missing:
Cabal ==1.4.*, HTTP >=3000 && <3002, base <3 && >=2.0 && <2.2

Regards, J.W.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

darcs patch: avoid import renaming errors in nhc98 (and 2 more)

Mon Oct  6 11:21:53 BST 2008  Malcolm.Wallace <at> cs.york.ac.uk
  * avoid import renaming errors in nhc98

Mon Oct  6 11:22:48 BST 2008  Malcolm.Wallace <at> cs.york.ac.uk
  * fix import of Control.Exception for nhc98

Mon Oct  6 11:23:29 BST 2008  Malcolm.Wallace <at> cs.york.ac.uk
  * in cabal file, avoid -package syb when building with nhc98

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Proposal #2659: Add sortOn and friends to Data.List

Hello list,

Almost all uses of sortBy in user code use 'comparing', 'on' or a similar 
construction [1]. I think we should add a function that makes this common 
behavior more convenient:

     sortOn :: Ord b => (a -> b) -> [a] -> [a]

For consistency we should also add *On for the other *By functions in Data.List:

     nubOn           :: Eq b => (a -> b) -> [a] -> [a]
     deleteOn        :: Eq b => (a -> b) -> a -> [a] -> [a]
     deleteFirstsOn  :: Eq b => (a -> b) -> [a] -> [a] -> [a]
     unionOn         :: Eq b => (a -> b) -> [a] -> [a] -> [a]
     intersectOn     :: Eq b => (a -> b) -> [a] -> [a] -> [a]
     groupOn         :: Eq b => (a -> b) -> [a] -> [[a]]
     sortOn          :: Ord b => (a -> b) -> [a] -> [a]
     insertOn        :: Ord b => (a -> b) -> a -> [a] -> [a]
     maximumOn       :: Ord b => (a -> b) -> [a] -> a
     minimumOn       :: Ord b => (a -> b) -> [a] -> a
    (nubSortOn       :: Ord b => (a -> b) -> [a] -> [a]) -- see #2629

-- Naming --

"On": The reason for the "on" suffix is that it relates to the "on" function 
from Data.Function: "sortOn f = sort (compare `on` f)". In code, "sortOn fst" is 
reasonably natural, "sortBy fst" would be better but that is already taken.

"With": Another possible choice is the "with" suffix. There is some precedence 
for this choice [2]. A big disadvantage is that the "with" suffix is commonly 

Map / Set folding API changes

Regarding this thread :
http://www.haskell.org/pipermail/libraries/2008-September/010653.html

and this ticket : http://hackage.haskell.org/trac/ghc/ticket/2580

I've attached a patch (to trac) which expands on Evan's changes and
propagates them to IntSet and IntMap.

Some (possibly controversial) changes of note :

    * Added foldr and foldl functions for the map types. This is
redundant, but so is much of the interface. The argument to
foldlWithKey has a strange type, (a -> key -> value -> a), that does
not place nice with flip and const. So I think its convenient to have
foldl as well, and since we've got that why not throw foldr in too.

    * Specialized default implementations of foldl and foldr for
Foldable class. This is perhaps better than exporting then from the
map libraries. Data.Sequence does it this way, but the map libraries
do not. If the API clutter is found to be unbearable then perhaps a
major cleanup is in order, hiding all folds in the map/set modules and
exporting them via Foldable.

Questions remaining :

Strict versions? I'm happy to add them. The only question is if it
(further) clutters the API.

As mentioned, the type of foldlWithKey is strange. It didn't dawn on
me until I went to define foldl in terms of foldlWithKey. Perhaps

Data.Foldable documentation

Hello,

I've got a suggestion for the documentation of the Data.Foldable module. 
The documentation [1] does not say anything about the order in which the 
elements are folded. But as far as I understand, the order in which the 
elements are traversed (i. e. the result of Data.Foldable.toList) has to 
bee deterministic. The documentation of the Foldable class IMHO should 
provide a clear statement about that.

Example: I implemented a heap that internally uses a tree of elements. 
It uses a tree to store the elements, but two heaps might be equal 
(contain the same elements) and still be represented by different trees. 
Then

instance Foldable (Heap p) where
     foldMap _ Empty          = mempty
     foldMap f (Tree _ x l r) = foldMap f l `mappend` f x `mappend` 
foldMap f r

is a bug which is not indicated by the documentation.

Thanks in advance
Stephan

[1] using ghc-6.8.3

--

-- 

Früher hieß es ja: Ich denke, also bin ich.
Heute weiß man: Es geht auch so.

HackageDB bug in exposed modules

Hi,

I just uploaded a library to hackagedb:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe

Everything went smoothly, but the webpage shows certain hidden modules
(other-modules section in the cabal description) as exposed.

Am I missing something or is this a bug in HackageDB?

Best regards,

Alfonso Acosta

Announce: Haskell protocol-buffers version 0.3.1

And now it is much more complete.  The 'hprotoc' compiler for proto files to 
Haskell source code now takes a "-u" command-line option.  When given, this 
turns on code generation to support loading, storing, and saving unknown fields.

The master source code archive has been broken up into the three corresponding 
Haskell packages:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers-descriptor
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc

The latest version is 0.3.1.  They must be installed in the order given above 
(and all have been tested with the "cabal-install" command).  In addition the 
new unknown field support, a few small bugs were fixed.

In the future I will look at the new extensible proto file option and see how 
such support could be added to this Haskell project.

Cheers,
   Chris

Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith

http://hackage.haskell.org/trac/ghc/ticket/2629

Everyone always complains about nub, but nobody ever does
anything about it except (map head . group . sort), which
isn't lazy and isn't always faster. 

I've implemented a new function nubWith that takes a
"stop list" as an argument and filters its target list
against the stop list.  I've then re-implemented nub and
implemented nubOrd and nubInt in terms of nubWith: the stop
list is a typeclass, so these implementations are trivial
and new implementations are easily added.  nubBy is left
alone, since there's nothing obvious to be done about it.
All of the nubs are still fully lazy.

Basic QuickCheck tests are provided, and pass.

Performance benchmarking code is provided.  The performance
of my nub implementation is quite comparable to that of
the standard one.  My nubOrd and nubInt implementations
are dramatically faster, since they use a Set and IntSet
respectively for the stop list.  In particular, they
are performant on long lists with long nubs, unlike the
basic nub.

My implementation is available via git at
  git://svcs.cs.pdx.edu/git/nub.git
or can be browsed at
  http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree
and has a maybe-outdated tarball at