From bart at cs.pdx.edu  Wed Oct  1 04:19:41 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Wed Oct  1 04:16:38 2008
Subject: A different approach to nubOrd (Re: Proposal #2629)
References: <loom.20080928T074555-138@post.gmane.org>
	<loom.20080930T040121-808@post.gmane.org>
	<200809300220.13140.dan.doel@gmail.com>
	<loom.20080930T161230-327@post.gmane.org>
Message-ID: <loom.20081001T070211-729@post.gmane.org>

Bart Massey <bart <at> cs.pdx.edu> writes:
> Any suggestions from anyone about how to proceed?  Or are we just done at this
> point?  So close...

OK, I've got a new version of nubOrd together.  This one is just nubOrd, no
nubWith, no nubInt, nothing fancy.  There's two variants, nubOrd' and nubOrd''.
 The latter gets a slight performance win by omitting some work that would
preserve the order of output with respect to nub.

The basic strategy of nubOrd' is to pull off a prefix l of the input list as
long as the current stoplist s, nubSort l, merge l with s to get a new stoplist
s', use s in a merge step to filter l, then sort the remainder of l back to the
original order.  Finally, the resulting l' and s' are prepended to a recursive
call on the rest of the list.

nubOrd' has roughly the same time complexity as the set-based nubOrd did.  This
is because each step of nubOrd requires log m time to search the stoplist, and
each collection of steps in nubOrd' requires amortized log m time for the sorts.

Let's do some side by side comparison:

               nub      nubSort       nubOrd        nubOrd'      nubOrd''

laziness       full     no            full          spine        spine

worst-case     O(mn)    O(n log n)    O(n log m)    O(n log m)   O(n log m)
complexity
(m symbols,
 length n)

relative       1x       50x           1.1x          5x           5x
runtime with
m = 1

absolute       84s      0.14s         0.16s          0.35s       0.21s
runtime with
m = n = 10^5

dependencies   no       no            Data.Set      no           no
outside                               (containers)
Data.List

outputs in     yes      no            yes           yes          no
order of
first mention

code           small    tiny          smallish      wtf          wtf-lite
complexity


This table suggests to me that nubOrd' is viable, assuming spine-laziness is
sufficient.  It solves the time problems of nub and nubSort, solves the
dependency problem of nubOrd, and preserves the order of its outputs.  I don't
like the 5x slowdown for small m, or the non-laziness on elements, but I guess I
am willing to take them to get  the other stuff.  Maybe someone or the compiler
can do some optimization later.

The code for nubOrd', in all its hideous glory, is at the end of this post. 
Comments, corrections and improvements welcome.

    Bart Massey
    bart <at> cs.pdx.edu

merge :: Ord e => [e] -> [e] -> [e]
merge l1 [] = l1
merge [] l2 = l2
merge l1@(e1 : e1s) l2@(e2 : e2s)
    | e1 < e2 = e1 : merge e1s l2
    | e1 > e2 = e2 : merge l1 e2s
    | otherwise = merge l1 e2s

nubOrd' :: Ord e => [e] -> [e]
nubOrd' [] = []
nubOrd' (e : es) = e : go [e] es where
    go _ [] = []
    go s l = l1' ++ go s' l2 where
      (l1, l2) = splitAt (length s) l
      curl = filterDups $ sort $ zip l1 ([1..] :: [Integer])
      s' = merge s (map fst curl)
      l1' = map fst $ sortBy flipcmp $ stopMerge s curl
      (a, b) `flipcmp` (c, d) = (b, a) `compare` (d, c)
      filterDups [] = []
      filterDups (s1@(e1, _) : (e2, _) : ss) | e1 == e2 = filterDups (s1 : ss)
      filterDups (s1 : ss) = s1 : filterDups ss
      stopMerge _ [] = []
      stopMerge [] m2 = m2
      stopMerge m1@(e1 : e1s) m2@(s2@(e2, _) : s2s)
          | e1 < e2 = stopMerge e1s m2
          | e1 > e2 = s2 : stopMerge m1 s2s
          | otherwise = stopMerge m1 s2s


From alfonso.acosta at gmail.com  Wed Oct  1 05:06:54 2008
From: alfonso.acosta at gmail.com (Alfonso Acosta)
Date: Wed Oct  1 05:03:38 2008
Subject: HackageDB bug in exposed modules
In-Reply-To: <1222800030.14163.210.camel@dell.linuxdev.us.dell.com>
References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com>
	<1222795137.14163.203.camel@dell.linuxdev.us.dell.com>
	<6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com>
	<6a7c66fc0809301045r31ac06efq604ff84ea9909e01@mail.gmail.com>
	<1222800030.14163.210.camel@dell.linuxdev.us.dell.com>
Message-ID: <6a7c66fc0810010206xa1d0357q2942023917209fe@mail.gmail.com>

On Tue, Sep 30, 2008 at 8:40 PM, Duncan Coutts
<duncan.coutts@worc.ox.ac.uk> wrote:
> On Tue, 2008-09-30 at 19:45 +0200, Alfonso Acosta wrote:
>> BTW, can someone tell me how long does HackageDB normally take to
>> compile the uploaded packages and generate the haddock documentation?
>
> It's normally on the order of a few hours. I'm afraid I do not know
> exactly.

I'm just asking because I uploaded this package 4 days ago and it
still doesn't show the haddock documentation
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parameterized-data-0.1.3

There is no rush, I'm just trying to understand how the compilation of
packages works HackageDB (I uploaded some other packages after that
one and their haddock documentation is ready)
From apfelmus at quantentunnel.de  Wed Oct  1 05:34:23 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Wed Oct  1 05:31:21 2008
Subject: Proposal #2629: Data.List: Replace nub;   add nubOrd, nubInt,
 nubWith
In-Reply-To: <57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com>
References: <loom.20080928T074555-138@post.gmane.org>	<57526e770809281105if142137p8e5473b13d4ce71f@mail.gmail.com>	<gbr0e7$hnt$1@ger.gmane.org>
	<57526e770809291555h73953b08p15aac52f2e48dc8f@mail.gmail.com>
Message-ID: <gbvg6v$mj0$1@ger.gmane.org>

Alexander Dunlap wrote:
> apfelmus wrote:
>> Alexander Dunlap wrote:
>>> This seems like a good idea but it's kind of strange to have three
>>> different exposed versions of nub. Would it be possible to hide them,
>>> hide the StopList typeclass and use {-# RULES #-} pragmas to use the
>>> faster versions when possible?
>>
>> I don't think that using RULES pragmas is a good solution to the problem.
> 
> Why not? I thought that was the major purpose of RULES - to implement
> transformations that don't affect semantics. It seems silly to clutter
> up classes with extra functions just for efficiency or to have to
> change programs every time the types change. The fact that RULES don't
> work in GHCi is admittedly a downside; is there any plan to change
> that?

Why not type classes? :) Their major purpose is to overload a value at
different types, like

  nub :: Eq a => [a] -> [a]
  nub :: Ord a => [a] -> [a]
  nub :: [Int] -> [Int]

and that's exactly what we're trying to do. Adding  nub  with a default
definition is a two-line change to the definition of the  Eq  class and
it's completely backwards compatible, no existing program needs to be
changed.

But as said, Haskell98 is currently unable to specialize  nub  for a
general  Ord  context, we would need some extension about superclasses
for that. But this extension is desirable for Functor, Monad and
Applicative anyway.


The argument that the semantics of the different  nubs  are all the same
does have merits, but we're already putting functions into the class for
efficiency reasons, like

  (/=) and (==)
  (>),(>=) and  compare
  (/) and  recip
  tan  and  sin,cos
  (>>)  and  (>>=)
  etc.


Regards,
apfelmus

From deduktionstheorem at web.de  Wed Oct  1 12:32:46 2008
From: deduktionstheorem at web.de (Stephan Friedrichs)
Date: Wed Oct  1 12:29:29 2008
Subject: Data.Foldable documentation
Message-ID: <48E3A62E.7070309@web.de>

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.

  - Dieter Nuhr
From sedillard at ucdavis.edu  Thu Oct  2 13:28:10 2008
From: sedillard at ucdavis.edu (Scott Dillard)
Date: Thu Oct  2 13:24:48 2008
Subject: Map / Set folding API changes
Message-ID: <d9b657cd0810021028h5b7e3101p70c75f9c178fd66e@mail.gmail.com>

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
change it to (a -> (k,v) -> a) ? This goes against the established
(and IMO unfortunate) convention that all the "WithKey" functions pass
the key as an additional argument, instead of tupling it with the
value.

Scott
From ross at soi.city.ac.uk  Fri Oct  3 07:38:04 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Fri Oct  3 07:34:43 2008
Subject: HackageDB bug in exposed modules
In-Reply-To: <6a7c66fc0810010206xa1d0357q2942023917209fe@mail.gmail.com>
References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com>
	<1222795137.14163.203.camel@dell.linuxdev.us.dell.com>
	<6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com>
	<6a7c66fc0809301045r31ac06efq604ff84ea9909e01@mail.gmail.com>
	<1222800030.14163.210.camel@dell.linuxdev.us.dell.com>
	<6a7c66fc0810010206xa1d0357q2942023917209fe@mail.gmail.com>
Message-ID: <20081003113804.GA3034@soi.city.ac.uk>

On Wed, Oct 01, 2008 at 11:06:54AM +0200, Alfonso Acosta wrote:
> I'm just asking because I uploaded this package 4 days ago and it
> still doesn't show the haddock documentation
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parameterized-data-0.1.3
> 
> There is no rush, I'm just trying to understand how the compilation of
> packages works HackageDB (I uploaded some other packages after that
> one and their haddock documentation is ready)

I was specifically excluding type-level and parameterized-data for some
reason that I can't remember.  So I've stopped.
From alfonso.acosta at gmail.com  Fri Oct  3 10:55:04 2008
From: alfonso.acosta at gmail.com (Alfonso Acosta)
Date: Fri Oct  3 10:51:41 2008
Subject: HackageDB bug in exposed modules
In-Reply-To: <20081003113804.GA3034@soi.city.ac.uk>
References: <6a7c66fc0809300959p6566517dm93bcc46430f5791@mail.gmail.com>
	<1222795137.14163.203.camel@dell.linuxdev.us.dell.com>
	<6a7c66fc0809301039o792e280egf841b3d406586fa5@mail.gmail.com>
	<6a7c66fc0809301045r31ac06efq604ff84ea9909e01@mail.gmail.com>
	<1222800030.14163.210.camel@dell.linuxdev.us.dell.com>
	<6a7c66fc0810010206xa1d0357q2942023917209fe@mail.gmail.com>
	<20081003113804.GA3034@soi.city.ac.uk>
Message-ID: <6a7c66fc0810030755t10e56f6aga3d863e49059d975@mail.gmail.com>

On Fri, Oct 3, 2008 at 1:38 PM, Ross Paterson <ross@soi.city.ac.uk> wrote:
> I was specifically excluding type-level and parameterized-data for some
> reason that I can't remember.  So I've stopped.

Thanks.
From isaacdupree at charter.net  Fri Oct  3 13:35:20 2008
From: isaacdupree at charter.net (Isaac Dupree)
Date: Fri Oct  3 13:32:03 2008
Subject: Proposal #2629: Data.List: Replace nub;
	add nubOrd, nubInt, nubWith
In-Reply-To: <117f2cc80809300858o71f85ef3tdcde00d3c4859b17@mail.gmail.com>
References: <loom.20080928T074555-138@post.gmane.org>	<loom.20080930T040121-808@post.gmane.org>
	<117f2cc80809300858o71f85ef3tdcde00d3c4859b17@mail.gmail.com>
Message-ID: <48E657D8.7010509@charter.net>

David Roundy wrote:
> Actually, the asymptotic complexity (measured in terms of list length)
> of nubOrd is identical to the asymptotic complexity of nubAscii,
> nubBool or nubFinite.  They differ by a constant factor of the log(#
> possible data values).

except for infinite possible data values, such as Integer or 
String -- then they don't differ by a constant factor of 
infinity!  (And the constant factor on, say, Int64 and 
higher could be a lot larger than some implementations might 
be able to make it, I'm not sure)

-Isaac
From bart at cs.pdx.edu  Sat Oct  4 00:25:43 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Sat Oct  4 00:22:33 2008
Subject: Proposal #2629: Data.List: Replace nub;	add
	nubOrd, nubInt, nubWith
References: <loom.20080928T074555-138@post.gmane.org>	<loom.20080930T040121-808@post.gmane.org>
	<117f2cc80809300858o71f85ef3tdcde00d3c4859b17@mail.gmail.com>
	<48E657D8.7010509@charter.net>
Message-ID: <loom.20081004T041415-902@post.gmane.org>

I think that the easiest way to think about the asymptotic
complexity of the nub* functions is in terms of the length n
of the input list and the number of unique elements m in
that list, as I did in a previous posting.  My original
point in this thread, which I stated badly, is this: Since
array access is constant time, one can imagine an
implementation nubIx that has O(n) worst-case time on any Ix
datatype, regardless of m. This contrasts with the O(mn)
complexity of nub and the O(n log m) complexity of nubOrd on
values of type Ix.  It is true that for any fixed m any nub*
is O(n), but IMHO this fact is a bit misleading; we probably
want to think about the asymptotic complexity in m as well
as n to get a clear picture of what's going on.

    Bart Massey
    bart <at> cs.pdx.edu


From bart at cs.pdx.edu  Sat Oct  4 03:26:25 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Sat Oct  4 03:23:08 2008
Subject: Status of nubOrd (Proposal #2629)
References: <loom.20080928T074555-138@post.gmane.org>
	<loom.20080930T040121-808@post.gmane.org>
	<200809300220.13140.dan.doel@gmail.com>
	<loom.20080930T161230-327@post.gmane.org>
	<loom.20081001T070211-729@post.gmane.org>
Message-ID: <loom.20081004T042734-500@post.gmane.org>

I need to know what the community wants me to do to close
out my proposal to add nubOrd to the standard libraries.
After ruling out a lot of marginal choices, I guess I see
three leading alternatives, all of which have negatives.
I'd love to have some feedback on these so I can start
thinking about other things.

1) Stick nubOrd' from my previous message into Data.List and
   call it a day.

   Advantages: Does no violence to the current library
   structure.  Provides a nubOrd that has O(n log m)
   asymptotic performance, and performs reasonably in
   practice with large m.

   Disadvantages: In the worst case, 5x performance is left
   on the floor.  Not particularly lazy: will work with
   infinite lists, but not with lists terminating in bottom;
   will only randomly work with lists containing bottom
   elements.  Quite ugly implementation.  No nubWith.

   My score: 2/5

2) Stick (non-StopList) nubWith in Data.List.  Stick nubOrd
   in Data.Set, implemented using nubWith.

   Advantages: Provides a highly efficient, fully lazy
   nubOrd.  Provides nubWith.  Reasonable implementation.

   Disadvantages:  Sticking nubOrd in Data.Set is weird.

   My score: 4/5

3) Leave well enough alone.

   Advantages: Full-on inherency.  Leaves no weird mess for
   future librarians.

   Disadvantages: No nubOrd means that folks keep writing
   nubSort and/or using nub in situations where it might
   fall over from poor performance.  Everyone having their
   own nub* implementations is a maintenance problem.  No
   nubWith means that it's more work to implement one's own
   nub*, making this problem worse.

   My score: 1/5

Comments gratefully received.  Based on them, I'll supersede
Proposal #2629 with the appropriate replacement Proposal.
My patch for (2) works fine with GHC 6.8.3.  I'm working on
compiling for current top-of-tree right now; should
have it shortly.

Thanks.

    Bart Massey
    bart <at> cs.pdx.edu


From isaacdupree at charter.net  Sat Oct  4 08:21:41 2008
From: isaacdupree at charter.net (Isaac Dupree)
Date: Sat Oct  4 08:18:16 2008
Subject: Status of nubOrd (Proposal #2629)
In-Reply-To: <loom.20081004T042734-500@post.gmane.org>
References: <loom.20080928T074555-138@post.gmane.org>	<loom.20080930T040121-808@post.gmane.org>	<200809300220.13140.dan.doel@gmail.com>	<loom.20080930T161230-327@post.gmane.org>	<loom.20081001T070211-729@post.gmane.org>
	<loom.20081004T042734-500@post.gmane.org>
Message-ID: <48E75FD5.2040900@charter.net>

Bart Massey wrote:
> 2) Stick (non-StopList) nubWith in Data.List.  Stick nubOrd
>    in Data.Set, implemented using nubWith.
> 
>    Advantages: Provides a highly efficient, fully lazy
>    nubOrd.  Provides nubWith.  Reasonable implementation.
> 
>    Disadvantages:  Sticking nubOrd in Data.Set is weird.
> 
>    My score: 4/5

indeed a weird location, but only an import-line needs to 
change if someone invents a super-duper nubOrd that's even 
faster but depends on more libraries.  Would it be better to 
stick it in a new module e.g. Data.Set.Nub?

-Isaac
From nominolo at googlemail.com  Sat Oct  4 10:01:15 2008
From: nominolo at googlemail.com (Thomas Schilling)
Date: Sat Oct  4 09:57:47 2008
Subject: Data.Foldable documentation
In-Reply-To: <48E3A62E.7070309@web.de>
References: <48E3A62E.7070309@web.de>
Message-ID: <916b84820810040701t7135940dl648ffa84d337c0e@mail.gmail.com>

I think this is covered by the assumed associativity of mappend.
I.e., if `f' is associative, then `foldr = foldl' modulo performance.

2008/10/1 Stephan Friedrichs <deduktionstheorem@web.de>:
> 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.
>
>  - Dieter Nuhr
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From ross at soi.city.ac.uk  Sat Oct  4 10:25:45 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Sat Oct  4 10:22:19 2008
Subject: Data.Foldable documentation
In-Reply-To: <916b84820810040701t7135940dl648ffa84d337c0e@mail.gmail.com>
References: <48E3A62E.7070309@web.de>
	<916b84820810040701t7135940dl648ffa84d337c0e@mail.gmail.com>
Message-ID: <20081004142545.GA11695@soi.city.ac.uk>

On Sat, Oct 04, 2008 at 03:01:15PM +0100, Thomas Schilling wrote:
> 2008/10/1 Stephan Friedrichs <deduktionstheorem@web.de>:
> > 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.
>
> I think this is covered by the assumed associativity of mappend.
> I.e., if `f' is associative, then `foldr = foldl' modulo performance.

No, there's a bug in the documentation here (and in Data.Traversable):
it actually suggests the implementation that is incorrect for Heap.
The grouping doesn't matter, thanks to associativity, but the sequence
in which the elements are visited does.  In the heap case foldMap should
process the entries in priority order, and traverse can't be done without
rebuilding the heap.  Any other sequence would break the abstraction.
From jpm at cs.uu.nl  Sat Oct  4 11:17:41 2008
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Sat Oct  4 11:14:15 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <20080925155836.GA30388@matrix.chaos.earth.li>
References: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt>
	<DDDBBB05564D4BF490428F607AF0BC9D@cr3lt>
	<20080903081355.GA2149@soi.city.ac.uk> <g9ls3q$h2c$1@ger.gmane.org>
	<638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
Message-ID: <52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputPatchesArray
Type: application/octet-stream
Size: 657 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081004/f09cfb24/outputPatchesArray-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputPatchesBase
Type: application/octet-stream
Size: 44368 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081004/f09cfb24/outputPatchesBase-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputPatchesGHC
Type: application/octet-stream
Size: 11195 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081004/f09cfb24/outputPatchesGHC-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputPatchesSyb
Type: application/octet-stream
Size: 46289 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081004/f09cfb24/outputPatchesSyb-0001.obj
From bart at cs.pdx.edu  Sat Oct  4 12:23:09 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Sat Oct  4 12:19:49 2008
Subject: Status of nubOrd (Proposal #2629)
References: <loom.20080928T074555-138@post.gmane.org>	<loom.20080930T040121-808@post.gmane.org>	<200809300220.13140.dan.doel@gmail.com>	<loom.20080930T161230-327@post.gmane.org>	<loom.20081001T070211-729@post.gmane.org>
	<loom.20081004T042734-500@post.gmane.org>
	<48E75FD5.2040900@charter.net>
Message-ID: <loom.20081004T160954-9@post.gmane.org>

Isaac Dupree <isaacdupree <at> charter.net> writes:
> Bart Massey wrote:
> > 2) Stick (non-StopList) nubWith in Data.List.
> 
> >    Disadvantages:  Sticking nubOrd in Data.Set is weird.
> 
> indeed a weird location.  Would it be better to 
> stick it in a new module e.g. Data.Set.Nub?

Another possibility I considered is to stick nubOrd in Data.List.Nub.  As far as
I know, since containers depends on base and Data.Set depends on Data.List,
there's nothing preventing us from putting Data.List.Nub in containers even
though Data.List is in base.  Does someone know otherwise?

> only an import-line needs to 
> change if someone invents a super-duper nubOrd that's even 
> faster but depends on more libraries.

I believe that, given sufficient effort, I could prove that the nubOrd as given
is optimal in asymptotic complexity. The constant factors seem really good and
entirely dependent on those of the Set implementation.  So I'm not so worried
about a faster nubOrd. :-)


Leaving nubOrd in Data.Set does make a weird kind of sense; we put the various
nub* in whatever module their underlying stop list representation is in.  Thus
nubIx might go in Data.Array.  Also, it's less of a change to the existing
structure.

If we made a Data.List.Nub, presumably as more nub* implementations were added,
they would all pile in there.  One problem with this plan is that if someone
decides to write a nub* using a stop list from a module in a different package
that depends on containers, we're going to end up with the same circular
dependency problem we have now.


However, getting back to your original suggestion, I think it's also a little
weird to potentially have a bunch of modules with a special submodule containing
one function, so I guess I'd probably rather just stick it in Data.Set and be
done with it.  What do others think?

From dons at galois.com  Sat Oct  4 15:15:47 2008
From: dons at galois.com (Don Stewart)
Date: Sat Oct  4 15:12:11 2008
Subject: Arch Haskell News: Oct 4 2008
Message-ID: <20081004191547.GA1429@scytale.galois.com>

A weekly update about Haskell on Arch Linux.

Highlights,
           
    * Arch now has 609 Haskell packages in AUR.
      That?s a record increase of 19 new packages in the last 7 days.

Noteworthy,
           
    * mp3decoder-0.0.1: ?MP3 decoder for teaching.?
    * yi-0.4.6.2: ?The Haskell-Scriptable Editor?
    * haskell-haskore-0.0.5.1: ?The Haskore Computer Music System?

Full update list,
                 
    http://archhaskell.wordpress.com/2008/10/04/arch-haskell-news-oct-4-2008/

-- Don

From igloo at earth.li  Sat Oct  4 15:52:54 2008
From: igloo at earth.li (Ian Lynagh)
Date: Sat Oct  4 15:49:26 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
References: <DDDBBB05564D4BF490428F607AF0BC9D@cr3lt>
	<20080903081355.GA2149@soi.city.ac.uk> <g9ls3q$h2c$1@ger.gmane.org>
	<638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
Message-ID: <20081004195254.GA29716@matrix.chaos.earth.li>


Hi Pedro,

On Sat, Oct 04, 2008 at 05:17:41PM +0200, Jos? Pedro Magalh?es wrote:
> 
> I'm attaching patches

Thanks!

> Ian, do you think this could be incorporated in any possible upcoming beta
> versions/release candidates before the final release? I did some sanity
> checking but it would be good if a wider audience could test it.

I've applied it to HEAD and 6.10.

For some reason the checksum on the base patch was wrong, but it
looks OK anyway.


Thanks
Ian

From ross at soi.city.ac.uk  Sun Oct  5 06:34:13 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Sun Oct  5 06:30:44 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
References: <DDDBBB05564D4BF490428F607AF0BC9D@cr3lt>
	<20080903081355.GA2149@soi.city.ac.uk> <g9ls3q$h2c$1@ger.gmane.org>
	<638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
Message-ID: <20081005103413.GA19480@soi.city.ac.uk>

On Sat, Oct 04, 2008 at 05:17:41PM +0200, Jos? Pedro Magalh?es wrote:
> Basically, a new module Data.Data in base contains the previous
> Data.Generics.Basics and most of the instances from Data.Generics.Instances.
> Other changes are:
> 
> On Mon, Sep 15, 2008 at 13:28, Jos? Pedro Magalh?es <jpm@cs.uu.nl> wrote:
> 
>       + Ratio has to be fixed to have a consistent instance: either it's seen
>         as an abstract datatype (therefore with undefined gunfold) or a gfoldl
>         has to be defined matching its gunfold;
> 
> Ratio had its gfoldl defined to match its gunfold. Since GHC.Ratio exports the
> constructor (:%), I guess Ratio cannot be considered abstract.

I don't think GHC.Ratio counts as part of the public interface.
But Ratio isn't a showstopper.

>           o The imports of SYB in the following modules should be fixed to
>             avoid bringing into scope all the instances:
> 
>         ./containers/Data/IntMap.hs
>         ./containers/Data/IntSet.hs
>         ./containers/Data/Map.hs
>         ./containers/Data/Sequence.hs
>         ./containers/Data/Set.hs
>         ./containers/Data/Tree.hs
>         ./network/Network/URI.hs
>         ./packedstring/Data/PackedString.hs
> 
> This was not done, given the discussion in [1] regarding instance visibility
> and orphans.

I've pushed patches to HEAD to do this for array, containers,
packedstring and template-haskell.  I think we should be aiming to
remove all dependencies of boot libs on syb, and possibly to making syb
an extra-lib.  The only boot lib left depending on syb is bytestring,
but I understand that has other issues.
From claus.reinke at talk21.com  Sun Oct  5 09:40:08 2008
From: claus.reinke at talk21.com (Claus Reinke)
Date: Sun Oct  5 09:36:55 2008
Subject: Splitting SYB from the base package in GHC 6.10
References: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt><DDDBBB05564D4BF490428F607AF0BC9D@cr3lt><20080903081355.GA2149@soi.city.ac.uk>
	<g9ls3q$h2c$1@ger.gmane.org><638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com><52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com><20080916084133.GA2878@soi.city.ac.uk><20080922195449.GA22526@matrix.chaos.earth.li><52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com><20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
Message-ID: <gcag3t$2u4$1@ger.gmane.org>

>The following "dubious" instances are now in the syb package (in the
>Data.Generics.Instances module): DataType TyCon TypeRep Handle ThreadId
>StablePtr (a -> b) (IO a) (ST s a) (STM a) (IORef a) (TVar a) (MVar a). All
>the other instances are in the base package, Data.Data module.

Contrary to that list, 'Data (a->b)' is still in Data.Data?

Claus



From twanvl at gmail.com  Sun Oct  5 11:39:40 2008
From: twanvl at gmail.com (Twan van Laarhoven)
Date: Sun Oct  5 11:35:59 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
Message-ID: <48E8DFBC.30408@gmail.com>

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 
used for combining functions, as in Data.Map.unionWith. Making a 
Data.List.unionWith that does something completely different sounds like a bad idea.

"ByComparing": Defining
    sortByComparing f = sortBy (comparing f)
makes sense, naming wise. A disadvantage of this name is that it is too long. 
Also, we would get a distinction between "groupByEquating" and "sortByComparing".


-- Variations --

When f is a slow function the call "sortOn f xs" recomputes f more than 
necessary. A version that caches the result of f is easy to define:

     sortOn' f = map fst . sortOn snd . map (\x -> (x,f x))

This is perhaps not the best name, since ' usually means strictness.


-- Descending sort--

To be able to sort lists in reverse order, a simple newtype should be added to 
Data.Ord:

     newtype Down a = Down { getDown :: a }

     instance Ord a => Ord (Down a) where
         Down x < Down y  =  y < x

Now "sortOn Down xs == reverse (sort xs)".
The name Down comes from [2], maybe Desc is a better name?


-- Proposal--

Ticket:   #2659 (for sortOn and friends)
Ticket:   #2660 (for Down newtype)
Deadline: now+2 weeks = 2008-10-20

Questions:
   1. should sortOn be added to Data.List?
   2. should all other *On functions be added as well?
   3. what name should these functions get?
   4. should the sortOn' variations be added? What about the naming?
   5. should Down be added to Data.Ord?

Note: The addition of sortOn was previously proposed as #2406 and rejected 
because it did not follow the library submission guidelines.


Twan


[1] http://www.google.com/codesearch?q=lang%3Ahaskell+sortBy
[2] http://research.microsoft.com/~simonpj/papers/list-comp/index.htm
From lemming at henning-thielemann.de  Sun Oct  5 12:00:33 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun Oct  5 11:57:01 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <48E8DFBC.30408@gmail.com>
References: <48E8DFBC.30408@gmail.com>
Message-ID: <Pine.SOC.4.64.0810051747490.15371@haydn.informatik.uni-halle.de>


On Sun, 5 Oct 2008, Twan van Laarhoven wrote:

> 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

I also prefer these functions and have called them '*Key', because they 
work on a key:
    http://darcs.haskell.org/htam/src/Useful.hs

> Questions:
>  1. should sortOn be added to Data.List?

yes

>  2. should all other *On functions be added as well?

yes

>  3. what name should these functions get?

'On' is ok for me

>  4. should the sortOn' variations be added? What about the naming?

Both variants differ only in efficiency, where none is superior over the 
other. I don't think that the prime is a good way to indicate the 
difference. Maybe you can use 'sortKey' for the variant for selector 
functions and 'sortOn' for the caching variant.

>  5. should Down be added to Data.Ord?

I find it useful.

From duncan.coutts at worc.ox.ac.uk  Sun Oct  5 14:34:43 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Oct  5 15:50:56 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <48E8DFBC.30408@gmail.com>
References: <48E8DFBC.30408@gmail.com>
Message-ID: <1223231683.14163.493.camel@dell.linuxdev.us.dell.com>

On Sun, 2008-10-05 at 17:39 +0200, Twan van Laarhoven wrote:
> 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]


I think fewer names and more combinations is usually best unless there
is a really compelling reason. Just because things are often used in
combination doesn't mean we have to make a new name to represent that
composition. As functional programmers we are very used to using
composition, especially simple function application.

What is wrong with

sortBy (comparing fieldFoo) ?

It's not very long, it's pretty descriptive and easily generalises using
the 'on' function.

The only thing missing here is equating. I still have to define that
myself to write:

groupBy (equating fieldBar)

I know I can write

groupBy ((==) `on` fieldBar) but that just does not read so nicely.

So perhaps I should file a counter-proposal suggesting that all we need
to do is to add equating to Data.Eq. :-)


Duncan

From dave at zednenem.com  Mon Oct  6 00:07:00 2008
From: dave at zednenem.com (David Menendez)
Date: Mon Oct  6 00:03:27 2008
Subject: Status of nubOrd (Proposal #2629)
In-Reply-To: <loom.20081004T042734-500@post.gmane.org>
References: <loom.20080928T074555-138@post.gmane.org>
	<loom.20080930T040121-808@post.gmane.org>
	<200809300220.13140.dan.doel@gmail.com>
	<loom.20080930T161230-327@post.gmane.org>
	<loom.20081001T070211-729@post.gmane.org>
	<loom.20081004T042734-500@post.gmane.org>
Message-ID: <49a77b7a0810052107h5da08c00v8553aa16d219ea4d@mail.gmail.com>

On Sat, Oct 4, 2008 at 3:26 AM, Bart Massey <bart@cs.pdx.edu> wrote:
> I need to know what the community wants me to do to close
> out my proposal to add nubOrd to the standard libraries.
> After ruling out a lot of marginal choices, I guess I see
> three leading alternatives, all of which have negatives.
> I'd love to have some feedback on these so I can start
> thinking about other things.

I realize I'm coming into this discussion late, but has anyone
surveyed existing Haskell code to see how often nub is used? How many
of those cases require the specific functionality of nub, as opposed
to something like "Set.toList . Set.fromList"? I may be misjudging
things, but I can't imagine it's often enough to justify three or more
implementations in the standard library.

If there are really a lot of cases where people need a collection that
(1) has no duplicates, and (2) preserves an arbitrary order of
elements, maybe we'd be better off designing a data structure
specifically for that.

-- 
Dave Menendez <dave@zednenem.com>
<http://www.eyrie.org/~zednenem/>
From allbery at ece.cmu.edu  Mon Oct  6 00:13:11 2008
From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH)
Date: Mon Oct  6 00:09:43 2008
Subject: Status of nubOrd (Proposal #2629)
In-Reply-To: <49a77b7a0810052107h5da08c00v8553aa16d219ea4d@mail.gmail.com>
References: <loom.20080928T074555-138@post.gmane.org>
	<loom.20080930T040121-808@post.gmane.org>
	<200809300220.13140.dan.doel@gmail.com>
	<loom.20080930T161230-327@post.gmane.org>
	<loom.20081001T070211-729@post.gmane.org>
	<loom.20081004T042734-500@post.gmane.org>
	<49a77b7a0810052107h5da08c00v8553aa16d219ea4d@mail.gmail.com>
Message-ID: <62AC37E4-7ADB-48D3-BDC3-BD3992BE7244@ece.cmu.edu>

On 2008 Oct 6, at 0:07, David Menendez wrote:
> On Sat, Oct 4, 2008 at 3:26 AM, Bart Massey <bart@cs.pdx.edu> wrote:
>> I need to know what the community wants me to do to close
>> out my proposal to add nubOrd to the standard libraries.
>> After ruling out a lot of marginal choices, I guess I see
>> three leading alternatives, all of which have negatives.
>> I'd love to have some feedback on these so I can start
>> thinking about other things.
>
> I realize I'm coming into this discussion late, but has anyone
> surveyed existing Haskell code to see how often nub is used? How many

It's not so much that nub is used often. it's that it's often  
*reimplemented*.

> If there are really a lot of cases where people need a collection that
> (1) has no duplicates, and (2) preserves an arbitrary order of
> elements, maybe we'd be better off designing a data structure
> specifically for that.


Feel free to contribute.  Make sure it supports the whole spectrum of  
list operations, including list comprehensions.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


From dave at zednenem.com  Mon Oct  6 02:02:07 2008
From: dave at zednenem.com (David Menendez)
Date: Mon Oct  6 01:58:33 2008
Subject: Status of nubOrd (Proposal #2629)
In-Reply-To: <62AC37E4-7ADB-48D3-BDC3-BD3992BE7244@ece.cmu.edu>
References: <loom.20080928T074555-138@post.gmane.org>
	<loom.20080930T040121-808@post.gmane.org>
	<200809300220.13140.dan.doel@gmail.com>
	<loom.20080930T161230-327@post.gmane.org>
	<loom.20081001T070211-729@post.gmane.org>
	<loom.20081004T042734-500@post.gmane.org>
	<49a77b7a0810052107h5da08c00v8553aa16d219ea4d@mail.gmail.com>
	<62AC37E4-7ADB-48D3-BDC3-BD3992BE7244@ece.cmu.edu>
Message-ID: <49a77b7a0810052302h217c48dsb64dee9ee3ca414c@mail.gmail.com>

On Mon, Oct 6, 2008 at 12:13 AM, Brandon S. Allbery KF8NH
<allbery@ece.cmu.edu> wrote:
> On 2008 Oct 6, at 0:07, David Menendez wrote:
>>
>> On Sat, Oct 4, 2008 at 3:26 AM, Bart Massey <bart@cs.pdx.edu> wrote:
>>>
>>> I need to know what the community wants me to do to close
>>> out my proposal to add nubOrd to the standard libraries.
>>> After ruling out a lot of marginal choices, I guess I see
>>> three leading alternatives, all of which have negatives.
>>> I'd love to have some feedback on these so I can start
>>> thinking about other things.
>>
>> I realize I'm coming into this discussion late, but has anyone
>> surveyed existing Haskell code to see how often nub is used? How many
>
> It's not so much that nub is used often. it's that it's often
> *reimplemented*.

By people who *need* a faster nub, or by people who figured they could
make nub faster by changing the type? How often does someone need the
exact behavior of nub, instead of something faster like "Set.toList .
Set.fromList"?

All this effort to optimize a seemingly obscure function feels like
overkill. We might be better off just adding a note to the
documentation of nub suggesting that people use Data.Set instead. (We
can't get rid of it, because it's in the H98 Report.)

In any case, my only objection is to complicating the standard
libraries. If someone wants to post a faster nub to Hackage, that's
fine.

>> If there are really a lot of cases where people need a collection that
>> (1) has no duplicates, and (2) preserves an arbitrary order of
>> elements, maybe we'd be better off designing a data structure
>> specifically for that.
>
>
> Feel free to contribute.  Make sure it supports the whole spectrum of list
> operations, including list comprehensions.

Demonstrate the need, and I'd be happy to contribute.

-- 
Dave Menendez <dave@zednenem.com>
<http://www.eyrie.org/~zednenem/>
From jpm at cs.uu.nl  Mon Oct  6 04:00:14 2008
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Mon Oct  6 03:56:39 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <20081005103413.GA19480@soi.city.ac.uk>
References: <DDDBBB05564D4BF490428F607AF0BC9D@cr3lt>
	<g9ls3q$h2c$1@ger.gmane.org>
	<638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
	<20081005103413.GA19480@soi.city.ac.uk>
Message-ID: <52f14b210810060100y4fa82f81ofbe48db5931330c2@mail.gmail.com>

Hello,

On Sun, Oct 5, 2008 at 12:34, Ross Paterson <ross@soi.city.ac.uk> wrote:

> On Sat, Oct 04, 2008 at 05:17:41PM +0200, Jos? Pedro Magalh?es wrote:
> > Basically, a new module Data.Data in base contains the previous
> > Data.Generics.Basics and most of the instances from
> Data.Generics.Instances.
> > Other changes are:
> >
> > On Mon, Sep 15, 2008 at 13:28, Jos? Pedro Magalh?es <jpm@cs.uu.nl>
> wrote:
> >
> >       + Ratio has to be fixed to have a consistent instance: either it's
> seen
> >         as an abstract datatype (therefore with undefined gunfold) or a
> gfoldl
> >         has to be defined matching its gunfold;
> >
> > Ratio had its gfoldl defined to match its gunfold. Since GHC.Ratio
> exports the
> > constructor (:%), I guess Ratio cannot be considered abstract.
>
> I don't think GHC.Ratio counts as part of the public interface.
> But Ratio isn't a showstopper.


Sorry, I meant GHC.Real. But I am not sure on this definition either; no one
before had suggested whether to remove or add functionality to this
instance,just that the previous state was inconsistent.


Thanks,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20081006/bec7ed08/attachment.htm
From jpm at cs.uu.nl  Mon Oct  6 04:00:40 2008
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Mon Oct  6 03:57:07 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <gcag3t$2u4$1@ger.gmane.org>
References: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt>
	<g9ls3q$h2c$1@ger.gmane.org>
	<638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
	<gcag3t$2u4$1@ger.gmane.org>
Message-ID: <52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputPatchBase
Type: application/octet-stream
Size: 1500 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081006/fcb5dbe7/outputPatchBase.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: outputPatchSyb
Type: application/octet-stream
Size: 1026 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081006/fcb5dbe7/outputPatchSyb.obj
From neil.mitchell.2 at credit-suisse.com  Mon Oct  6 04:21:45 2008
From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil)
Date: Mon Oct  6 04:19:06 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <48E8DFBC.30408@gmail.com>
References: <48E8DFBC.30408@gmail.com>
Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3AA3@ELON17P32001A.csfb.cs-group.com>

Hi Twan,

> 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

All good, apart from deleteFirstsOn. I honestly don't know what that
function does, I was thinking possibly something like the first
component of tuples? But no real idea.


> When f is a slow function the call "sortOn f xs" recomputes f 
> more than necessary. A version that caches the result of f is 
> easy to define:
> 
>      sortOn' f = map fst . sortOn snd . map (\x -> (x,f x))

In Hoogle I use sortOn to be the non-cacheing version, and sortWith to
be the cacheing version. However, I think we can just ignore the
non-cacheing version - if your extraction function is expensive you
probably want to think a bit anyway.

> To be able to sort lists in reverse order, a simple newtype 
> should be added to
> Data.Ord:
> 
>      newtype Down a = Down { getDown :: a }
> 
>      instance Ord a => Ord (Down a) where
>          Down x < Down y  =  y < x
> 
> Now "sortOn Down xs == reverse (sort xs)".
> The name Down comes from [2], maybe Desc is a better name?

I prefer Down, and strongly support this proposal as well.

>    1. should sortOn be added to Data.List?

Yes.

>    2. should all other *On functions be added as well?

Yes (apart from deleteFirstsOn)

>    3. what name should these functions get?

*On, as you have given them.

>    4. should the sortOn' variations be added? What about the naming?

No.

>    5. should Down be added to Data.Ord?

Yes.

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

From bart at cs.pdx.edu  Mon Oct  6 05:39:35 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Mon Oct  6 05:36:20 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
References: <48E8DFBC.30408@gmail.com>
Message-ID: <loom.20081006T093305-258@post.gmane.org>

Twan van Laarhoven <twanvl <at> gmail.com> writes:
> Almost all uses of sortBy in user code use 'comparing',
> 'on' or a similar construction [1].

I certainly agree that there is room for improvement here.
But I hate to see the proliferation of functions, almost
all alike.  I guess I would support the proposal if that's
the way folks would like to go, though.

I would prefer:

  1) Get rid of any need for Data.Function by exporting
     'fix' and 'on' into the Prelude.  The rest of it is
     already in the Prelude anyway, and the implementations
     of 'fix' and 'on' are trivial.  (I'd say Data.Function
     is kind of a failed experiment at this point, but what
     do I know?)

  2) Move the sort functions into Data.Ord.  Obviously, they
     would have to be re-exported by Data.List.  It seems to
     me that 'sort' should have been there in the first
     place, and that 'sortBy" should be in the same place as
     'sort'.
  
  3) Incorporate the 'Down' (Is 'Descending' too long?) type
     in Data.Ord as suggested (but see below).

Now Data.Ord would be the one-stop shopping place for all
our sorting needs.

If all of this were done, I really wouldn't mind importing
Data.Ord to get the sorting functions and continuing to
write 'sortBy (comparing f)' or 'sortBy (p `on` f)' when I
wanted to do such a thing.  Even 'sortBy (comparing Down
`on` f)' isn't so bad.

Minor nits in the proposal:

  * You need to implement either (<=) or `comparing` for
    Down (preferably `comparing`), not just (<).  Otherwise
    sort nonterminates with a stack overflow.  This one took
    me a while to figure out.

    As far as I can tell you'll need to make Down an
    instance of Eq as well as Ord to get the latter instance
    to typecheck.

    These problems suggest that you haven't yet tried your
    proposal at all. :-) :-)

  * getDown might better be called fromDown?


    Bart Massey
    bart <at> cs.pdx.edu


From Malcolm.Wallace at cs.york.ac.uk  Mon Oct  6 12:23:02 2008
From: Malcolm.Wallace at cs.york.ac.uk (Malcolm.Wallace@cs.york.ac.uk)
Date: Mon Oct  6 12:20:01 2008
Subject: darcs patch: avoid import renaming errors in nhc98 (and 2 more)
Message-ID: <20081006162302.78CC0306DE71@ua021.cs.york.ac.uk>

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

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

Mon Oct  6 11:23:29 BST 2008  Malcolm.Wallace@cs.york.ac.uk
  * in cabal file, avoid -package syb when building with nhc98
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 4065 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/libraries/attachments/20081006/baefaac8/attachment.bin
From twanvl at gmail.com  Mon Oct  6 16:50:29 2008
From: twanvl at gmail.com (Twan van Laarhoven)
Date: Mon Oct  6 16:46:55 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3AA3@ELON17P32001A.csfb.cs-group.com>
References: <48E8DFBC.30408@gmail.com>
	<33A3F585590A6F4E81E3D45AA4A111C902CD3AA3@ELON17P32001A.csfb.cs-group.com>
Message-ID: <48EA7A15.20408@gmail.com>

Mitchell, Neil wrote:
> Hi Twan,
> 
> 
>>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
> 
> 
> All good, apart from deleteFirstsOn. I honestly don't know what that
> function does, I was thinking possibly something like the first
> component of tuples? But no real idea.

deleteFirstBy is "\\By", so it should perhaps be called differenceBy. But this 
is just the name that the List module uses. The reason for adding deleteFirstOn 
is simply consistency, since we also have a By version.

> In Hoogle I use sortOn to be the non-cacheing version, and sortWith to
> be the cacheing version. However, I think we can just ignore the
> non-cacheing version - if your extraction function is expensive you
> probably want to think a bit anyway.

If the extraction function is slow, like say "sortOn length", caching is a clear 
win. On the other hand, there is some constant cost involved.

Here are some benchmarks of sorting words in a dictionary:

                 no cache     cache
   sortOn f      3.203125     0.625000
   sortOn id     0.156250     0.187500

where f = length . nub . sort, i.e. an expensive function.

I'm not sure if the factor 1.2 overhead of the caching version is important 
enough to warrant exposing two different implementations.


Twan
From bernardy at chalmers.se  Mon Oct  6 17:32:54 2008
From: bernardy at chalmers.se (Jean-Philippe Bernardy)
Date: Mon Oct  6 17:29:19 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <48EA7A15.20408@gmail.com>
References: <48E8DFBC.30408@gmail.com>
	<33A3F585590A6F4E81E3D45AA4A111C902CD3AA3@ELON17P32001A.csfb.cs-group.com>
	<48EA7A15.20408@gmail.com>
Message-ID: <953e0d250810061432y328d70c3h25ca18fe2a673422@mail.gmail.com>

How about capturing the pattern in higher order functions?

if we define:

> import Data.Function
> import Data.List

> data Cache b a = Cache b a
> fromCache (Cache _ a) = a
> toCache f a = Cache (f a) a
> cache (Cache b _) = b

> caching f g = map fromCache . g . map (toCache f)

then sortOn becomes:

> sortOn2 f = caching f (sortBy (compare `on` cache))

and with the instances

> instance Ord b => Ord (Cache b a) where
>    compare x y = compare (cache x) (cache y)
>
> instance Eq b => Eq (Cache b a) where
>    x == y = cache x == cache y

it gets even simpler:

> sortOn3 f = caching f sort

It could be that I missed the point, but I'd much rather not see so
many functions
added to base without a strong case for it.

Cheers,
JP.
From s.clover at gmail.com  Mon Oct  6 18:36:51 2008
From: s.clover at gmail.com (Sterling Clover)
Date: Mon Oct  6 18:33:16 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <953e0d250810061432y328d70c3h25ca18fe2a673422@mail.gmail.com>
References: <48E8DFBC.30408@gmail.com>
	<33A3F585590A6F4E81E3D45AA4A111C902CD3AA3@ELON17P32001A.csfb.cs-group.com>
	<48EA7A15.20408@gmail.com>
	<953e0d250810061432y328d70c3h25ca18fe2a673422@mail.gmail.com>
Message-ID: <dfbc0a890810061536y2fb059e9o9acf7d857b4e0bf4@mail.gmail.com>

On Mon, Oct 6, 2008 at 5:32 PM, Jean-Philippe Bernardy <bernardy@chalmers.se
> wrote:

> How about capturing the pattern in higher order functions?
>

I absolutely agree with the spirit of this. We're in a language with higher
order functions and polymorphism -- the best there is for that! We should
take advantage of this and do away with specialized implementations
altogether, including By. The caching overhead is relatively minimal for
simple cases, and for complex cases its a big win.
The problem with the "caching" solution as presented, however, is that it
works for functions with the signature of sort. But most functions, such as
maximum, have no such signature. But wait... polymorphism comes to the
rescue!

First the preliminaries:

> {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances,
FunctionalDependencies #-}
> module Schwartz where
> import Data.List
> import Control.Applicative
> import Data.Function

Then a type for our Schwartzian transform:

> data Schwartz a b = Schwartz {sw_out :: !a, sw_trans :: !b}
> instance Eq b => Eq (Schwartz a b) where (==) = (==) `on` sw_trans
> instance Ord b => Ord (Schwartz a b) where compare = compare `on` sw_trans

Injection:

> sw_in f = Schwartz <*> f

And a higher order function for the [a] -> [a] case:

> schwartzAWith :: (a -> b) -> ([Schwartz a b] -> [Schwartz a b]) -> [a] ->
[a]
> schwartzAWith f g = map sw_out . g . map (sw_in f)

And then for the [a] -> a case:

> schwartzBWith :: (a -> b) -> ([Schwartz a b] -> Schwartz a b) -> [a] -> a
> schwartzBWith f g =     sw_out . g . map (sw_in f)

A bit clunky, but a typeclass that embodies the pattern:

> class ToSchwartz a b c d | c -> d where
>    using :: (a -> b) -> ([Schwartz a b] -> c) -> [a] -> d

Instances:

> instance ToSchwartz a b [Schwartz a b] [a] where
>    using u = schwartzAWith u
>
> instance ToSchwartz a b (Schwartz a b)  a  where
>    using u = schwartzBWith u

And now....
GHCi> using negate sort [1..5]
[5,4,3,2,1]
GHCi> using negate maximum [1..5]
1

A solution that would please the most discerning Haskell programmer (or Mel
Brooks).

--Sterl.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20081006/52baee32/attachment.htm
From apfelmus at quantentunnel.de  Tue Oct  7 05:44:24 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Tue Oct  7 05:41:01 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <48E8DFBC.30408@gmail.com>
References: <48E8DFBC.30408@gmail.com>
Message-ID: <gcfb1n$ooc$1@ger.gmane.org>

Twan van Laarhoven wrote:

> -- Proposal--
> 
> Ticket:   #2659 (for sortOn and friends)
> Ticket:   #2660 (for Down newtype)
> Deadline: now+2 weeks = 2008-10-20
> 
> Questions:
>   1. should sortOn be added to Data.List?
>   2. should all other *On functions be added as well?
>   3. what name should these functions get?
>   4. should the sortOn' variations be added? What about the naming?
>   5. should Down be added to Data.Ord?

-1 concerning sortOn and friends

I think that

  sortBy (comparing f)

is a very good and modular name for the functionality intended, no need
to create another one. The only advantage of a special  sortOn  function
would be that you can document it, i.e. there's no haddock blurb for
sortBy (comparing f) .

Hm, though  sortOn  could be useful if it caches the values of  f  by
default, like the  sortOn'  proposed. But Jean-Philippe's code is a
beautiful solution for this situation.


+1 concerning Down,

but I don't like the name. In particular I don't like the "get" prefix
in "getDown". I'd simply use

  newtype Desc a = Desc a

without label or  fromDesc  if really necessary.


Regards,
apfelmus

From g9ks157k at acme.softbase.org  Tue Oct  7 07:17:04 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Tue Oct  7 07:13:27 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <1223231683.14163.493.camel@dell.linuxdev.us.dell.com>
References: <48E8DFBC.30408@gmail.com>
	<1223231683.14163.493.camel@dell.linuxdev.us.dell.com>
Message-ID: <200810071317.04633.g9ks157k@acme.softbase.org>

Am Sonntag, 5. Oktober 2008 20:34 schrieb Duncan Coutts:
> I think fewer names and more combinations is usually best unless there
> is a really compelling reason. Just because things are often used in
> combination doesn't mean we have to make a new name to represent that
> composition. As functional programmers we are very used to using
> composition, especially simple function application.

I fully agree!

The identifiers of the proposed new functions are rather systematic.  So why 
not use the means of the language (combining higher-order functions) to 
express the underlying structure instead of relying on naming conventions and 
boilerplate code?

Best wishes,
Wolfgang
From marlowsd at gmail.com  Tue Oct  7 08:40:46 2008
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue Oct  7 08:37:16 2008
Subject: Status of nubOrd (Proposal #2629)
In-Reply-To: <loom.20081004T042734-500@post.gmane.org>
References: <loom.20080928T074555-138@post.gmane.org>	<loom.20080930T040121-808@post.gmane.org>	<200809300220.13140.dan.doel@gmail.com>	<loom.20080930T161230-327@post.gmane.org>	<loom.20081001T070211-729@post.gmane.org>
	<loom.20081004T042734-500@post.gmane.org>
Message-ID: <48EB58CE.2050409@gmail.com>

Bart Massey wrote:

> 2) Stick (non-StopList) nubWith in Data.List.  Stick nubOrd
>    in Data.Set, implemented using nubWith.
> 
>    Advantages: Provides a highly efficient, fully lazy
>    nubOrd.  Provides nubWith.  Reasonable implementation.
> 
>    Disadvantages:  Sticking nubOrd in Data.Set is weird.
> 
>    My score: 4/5

(2) seems reasonable to me, as long as we improve the documentation for nub 
to point out the quadratic complexity and direct users who want a faster 
version to Data.Set.nubOrd.

Cheers,
	Simon
From duncan.coutts at worc.ox.ac.uk  Tue Oct  7 17:04:30 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Oct  7 17:00:53 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <gcfb1n$ooc$1@ger.gmane.org>
References: <48E8DFBC.30408@gmail.com>  <gcfb1n$ooc$1@ger.gmane.org>
Message-ID: <1223413470.14163.573.camel@dell.linuxdev.us.dell.com>

On Tue, 2008-10-07 at 11:44 +0200, apfelmus wrote:

> I think that
> 
>   sortBy (comparing f)
> 
> is a very good and modular name for the functionality intended, no need
> to create another one. The only advantage of a special  sortOn  function
> would be that you can document it, i.e. there's no haddock blurb for
> sortBy (comparing f) .

Lets fix the sortBy documentation to mention the comparing idiom.

> Hm, though  sortOn  could be useful if it caches the values of  f  by
> default, like the  sortOn'  proposed. But Jean-Philippe's code is a
> beautiful solution for this situation.
> 
> 
> +1 concerning Down,
> 
> but I don't like the name. In particular I don't like the "get" prefix
> in "getDown". I'd simply use

Can't we do it with just some compare flip function:

sortBy (thing compare)

or

sortBy (thing $ comparing fieldFoo)

Would that work and what would be a good name?


Duncan

From waldmann at imn.htwk-leipzig.de  Wed Oct  8 04:01:03 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Wed Oct  8 04:00:30 2008
Subject: cabal-install, ghc-6.10
Message-ID: <48EC68BF.6030606@imn.htwk-leipzig.de>

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20081008/aa0e8ec7/signature.bin
From Malcolm.Wallace at cs.york.ac.uk  Wed Oct  8 05:55:28 2008
From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace)
Date: Wed Oct  8 05:54:56 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <loom.20081006T093305-258@post.gmane.org>
References: <48E8DFBC.30408@gmail.com>
	<loom.20081006T093305-258@post.gmane.org>
Message-ID: <20081008105528.014ec8ca.Malcolm.Wallace@cs.york.ac.uk>

>   1) Get rid of any need for Data.Function by exporting
>      'fix' and 'on' into the Prelude.

This can't be done, for one simple reason: the Prelude is Haskell'98,
and therefore currently immutable.

Regards,
    Malcolm
From bertram.felgenhauer at googlemail.com  Wed Oct  8 08:03:37 2008
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Wed Oct  8 08:00:01 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
Message-ID: <20081008120337.GE4249@zombie.inf.tu-dresden.de>

Twan van Laarhoven wrote:
> 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

Too many functions, and too little added functionality, IMHO.

>     newtype Down a = Down { getDown :: a }

I like this one.

Bertram
From bertram.felgenhauer at googlemail.com  Wed Oct  8 08:06:36 2008
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Wed Oct  8 08:03:00 2008
Subject: Status of nubOrd (Proposal #2629)
Message-ID: <20081008120636.GF4249@zombie.inf.tu-dresden.de>

Bart Massey wrote:
> 1) Stick nubOrd' from my previous message into Data.List and
>    call it a day.

I don't like it, for the simple reason that its exact strictness
properties are hard to explain. Low performance hurts, too.

> 2) Stick (non-StopList) nubWith in Data.List.  Stick nubOrd
>    in Data.Set, implemented using nubWith.
>
>    Advantages: Provides a highly efficient, fully lazy
>    nubOrd.  Provides nubWith.  Reasonable implementation.

That's nubWith :: (a -> b -> Maybe b) -> b -> [a] -> [a], right?

I have no strong opinion about this proposal either way.

>    Disadvantages:  Sticking nubOrd in Data.Set is weird.

That doesn't worry me much. We can always add a link to the
documentation of 'nub'.

All in all I must say that the design space for nub functions is
surprisingly big. One aspect that hasn't been mentioned yet is
special handling for finite types. For example,

   nubBool (True:True:False:undefined)

could well return [True,False], because all possible values have
been exhausted at that point.

I'm not suggesting to add more functions for this - nubBool is
easily expressed as

  nubBool = take 2 . nub

regards,

Bertram
From doaitse at swierstra.net  Wed Oct  8 08:07:50 2008
From: doaitse at swierstra.net (S. Doaitse Swierstra)
Date: Wed Oct  8 08:04:09 2008
Subject: A general question about the use of classes in defining interfaces
Message-ID: <AC76AD64-B529-4395-BB1E-227F2561006E@swierstra.net>

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

but this is also rather inefficient; why first building a result if  
you are going to throw it away anyway?

My life would be simpler if the extensions would either be  
incorporated in the class Applicative, with default definitions, and  
were not defined at top level, or in a class Extend_Applicative.

More in general I think it is preferred to place common patterns in  
classes with a default implementation, so they can be redefined  
instead of defining them at top level.

1) Does everyone agree with this observation, and if not what am I  
missing?
2) Can we change the module Applicative to reflect my view? I think it  
can be done without implying heavy changes to other modules.

Doaitse



From ross at soi.city.ac.uk  Wed Oct  8 08:20:49 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Wed Oct  8 08:17:11 2008
Subject: A general question about the use of classes in defining
	interfaces
In-Reply-To: <B37AF425-A0D1-4B72-B9DF-0AABB201942E@swierstra.net>
References: <B37AF425-A0D1-4B72-B9DF-0AABB201942E@swierstra.net>
Message-ID: <20081008122049.GA3092@soi.city.ac.uk>

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
> sequence since thi is non-sense, etc. Of course we can describe <* by
>
> p <* q = pure const <*> p <*> q
>
> but this is also rather inefficient; why first building a result if you
> are going to throw it away anyway?

The current definition isn't quite as bad as that:

	p <* q = const <$> p <*> q
	f <$> a = fmap f a

but the general point stands.

> More in general I think it is preferred to place common patterns in  
> classes with a default implementation, so they can be redefined instead 
> of defining them at top level.
>
> 1) Does everyone agree with this observation, and if not what am I  
> missing?
> 2) Can we change the module Applicative to reflect my view? I think it  
> can be done without implying heavy changes to other modules.

This seems reasonable to me, as long as there aren't too many of them;
we do this for lots of other classes.  Would you like to list all the
functions that you would like to have as redefinable methods?
From nhn at Cs.Nott.AC.UK  Wed Oct  8 08:26:56 2008
From: nhn at Cs.Nott.AC.UK (Henrik Nilsson)
Date: Wed Oct  8 08:24:01 2008
Subject: A general question about the use of classes in defining
	interfaces
In-Reply-To: <AC76AD64-B529-4395-BB1E-227F2561006E@swierstra.net>
References: <AC76AD64-B529-4395-BB1E-227F2561006E@swierstra.net>
Message-ID: <48ECA710.7080703@cs.nott.ac.uk>

Hi Doaitse, Ross,

Doaitse wrote:

 > 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.

There used to be the same problem with the Arrow class, with
operators like &&& and *** having standard definitions, but not
being redefineable due to not being class methods, which prevented
(or at least made much more difficult) certain optimizations.

After some prodding from me, Ross moved them into the Arrow class,
with default definitions.

I was and still am quite happy with that, and I'm not aware of
any major drawbacks, except that it might not be so clear
exactly where to draw the line between methods and top-level
standard definitions if one opt to include more than the bare
minimum of methods.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn@cs.nott.ac.uk

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

From doaitse at swierstra.net  Wed Oct  8 09:13:08 2008
From: doaitse at swierstra.net (S. Doaitse Swierstra)
Date: Wed Oct  8 09:09:28 2008
Subject: A general question about the use of classes in defining
	interfaces
In-Reply-To: <20081008122049.GA3092@soi.city.ac.uk>
References: <B37AF425-A0D1-4B72-B9DF-0AABB201942E@swierstra.net>
	<20081008122049.GA3092@soi.city.ac.uk>
Message-ID: <3D409B9F-F2D7-47D7-9354-71FDAC1862FA@swierstra.net>

Ok,

then I will carefully complete and refactor my new combinators (and  
rewrite part of the manual ;-}{) and come up with a proposal,

  Doaitse




On 8 okt 2008, at 14:20, Ross Paterson wrote:

> 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
>> sequence since thi is non-sense, etc. Of course we can describe <* by
>>
>> p <* q = pure const <*> p <*> q
>>
>> but this is also rather inefficient; why first building a result if  
>> you
>> are going to throw it away anyway?
>
> The current definition isn't quite as bad as that:
>
> 	p <* q = const <$> p <*> q
> 	f <$> a = fmap f a
>
> but the general point stands.
>
>> More in general I think it is preferred to place common patterns in
>> classes with a default implementation, so they can be redefined  
>> instead
>> of defining them at top level.
>>
>> 1) Does everyone agree with this observation, and if not what am I
>> missing?
>> 2) Can we change the module Applicative to reflect my view? I think  
>> it
>> can be done without implying heavy changes to other modules.
>
> This seems reasonable to me, as long as there aren't too many of them;
> we do this for lots of other classes.  Would you like to list all the
> functions that you would like to have as redefinable methods?
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From dons at galois.com  Wed Oct  8 16:06:01 2008
From: dons at galois.com (Don Stewart)
Date: Wed Oct  8 16:02:09 2008
Subject: cabal-install, ghc-6.10
In-Reply-To: <48EC68BF.6030606@imn.htwk-leipzig.de>
References: <48EC68BF.6030606@imn.htwk-leipzig.de>
Message-ID: <20081008200601.GE22268@scytale.galois.com>

waldmann:
> 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

A new release of cabal-install and cabal are about to arrive, which will
handle the conflicted base issue, issue, as well as other things.
From duncan.coutts at worc.ox.ac.uk  Wed Oct  8 13:27:34 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Oct  8 16:05:09 2008
Subject: cabal-install, ghc-6.10
In-Reply-To: <48EC68BF.6030606@imn.htwk-leipzig.de>
References: <48EC68BF.6030606@imn.htwk-leipzig.de>
Message-ID: <1223486854.14163.683.camel@dell.linuxdev.us.dell.com>

On Wed, 2008-10-08 at 10:01 +0200, Johannes Waldmann wrote:
> 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

You need the latest darcs version of cabal-install if you want to use it
with ghc 6.10. Besides working with the latest version of the Cabal lib
(which is what comes with 6.10) there are also some important changes to
the dependency resolver that enable it to cope with the fact that
ghc-6.10 has two versions of the base library.

Both versions of base often need to be used within a single install
plan. Previously this would have violated our definition of a consistent
install plan.

Duncan

From bart at cs.pdx.edu  Thu Oct  9 04:41:38 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Thu Oct  9 04:38:10 2008
Subject: Status of nubOrd (Proposal #2629)
References: <20081008120636.GF4249@zombie.inf.tu-dresden.de>
Message-ID: <loom.20081009T083718-897@post.gmane.org>

Bertram Felgenhauer <bertram.felgenhauer <at> googlemail.com> writes:
> Bart Massey wrote:
> That's nubWith :: (a -> b -> Maybe b) -> b -> [a] -> [a], right?

Yep.


> All in all I must say that the design space for nub functions is
> surprisingly big. One aspect that hasn't been mentioned yet is
> special handling for finite types.

We actually did talk about it a little earlier in this sprawling
thread.  But nubWith should handle it nicely if folks care.

>   nubBool = take 2 . nub

nub works fine on Bool, but you probably want nubWith for Char.

Thanks much for the comments!

    Bart Massey
    bart <at> cs.pdx.edu

From apfelmus at quantentunnel.de  Thu Oct  9 06:13:16 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Thu Oct  9 06:09:43 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <1223413470.14163.573.camel@dell.linuxdev.us.dell.com>
References: <48E8DFBC.30408@gmail.com> <gcfb1n$ooc$1@ger.gmane.org>
	<1223413470.14163.573.camel@dell.linuxdev.us.dell.com>
Message-ID: <gcklfs$j1v$1@ger.gmane.org>

Duncan Coutts wrote:
>> +1 concerning Down,
>>
>> but I don't like the name. In particular I don't like the "get" prefix
>> in "getDown". I'd simply use
> 
> Can't we do it with just some compare flip function:
> 
> sortBy (thing compare)
> 
> or
> 
> sortBy (thing $ comparing fieldFoo)
> 
> Would that work and what would be a good name?

thing = flip  works :)

But  Down  could be useful on its own, for instance for converting
a heap that stores elements in maximum order into one that stores them
in minimum order, i.e. when there is an Ord class constraint instead of
a simple higher-order function. Some exploration of the design space here

  http://thread.gmane.org/gmane.comp.lang.haskell.cafe/35988

Hm, I think that the  Cache b a  thing is more general, though, it may
be worth extending this to a full proposal.


Regards,
apfelmus

From g9ks157k at acme.softbase.org  Thu Oct  9 09:41:43 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu Oct  9 09:38:00 2008
Subject: Status of nubOrd (Proposal #2629)
In-Reply-To: <loom.20081009T083718-897@post.gmane.org>
References: <20081008120636.GF4249@zombie.inf.tu-dresden.de>
	<loom.20081009T083718-897@post.gmane.org>
Message-ID: <200810091541.43530.g9ks157k@acme.softbase.org>

Am Donnerstag, 9. Oktober 2008 10:41 schrieb Bart Massey:
> >   nubBool = take 2 . nub

nub [False,True,undefined] => _|_

but

nubBool [False,True,undefined] => [False,True]

right?  Is this really intended?

Take care.  Bool has three values (False, True and _|_).  This is no Agda. ;-) 

Best wishes,
Wolfgang
From bertram.felgenhauer at googlemail.com  Thu Oct  9 11:08:22 2008
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Thu Oct  9 11:04:47 2008
Subject: Status of nubOrd (Proposal #2629)
In-Reply-To: <200810091541.43530.g9ks157k@acme.softbase.org>
References: <20081008120636.GF4249@zombie.inf.tu-dresden.de>
	<loom.20081009T083718-897@post.gmane.org>
	<200810091541.43530.g9ks157k@acme.softbase.org>
Message-ID: <20081009150822.GA5537@zombie.inf.tu-dresden.de>

Wolfgang Jeltsch wrote:
> Am Donnerstag, 9. Oktober 2008 10:41 schrieb Bart Massey:
> > >   nubBool = take 2 . nub

Hmm, I wrote that.

> nub [False,True,undefined] => _|_

Surely you mean  False : True : _|_

> but
> 
> nubBool [False,True,undefined] => [False,True]
> 
> right?  Is this really intended?

Yes. It's a feature. I'm perfectly happy with

  nub :: [Bool] -> [Bool] ? nubBool,

which means that pure functions using 'nubBool' will never fail when
using 'nub' instead works, because pure functions are monotonous. Most
of the time, relaxing the strictness of functions is not a problem.

> Take care.  Bool has three values (False, True and _|_).
> This is no Agda. ;-)

Yes, I know. But for some reason people rarely try to actually evaluate
a _|_ value, even in Haskell. ;-)

Bertram
From roconnor at theorem.ca  Thu Oct  9 14:25:49 2008
From: roconnor at theorem.ca (roconnor@theorem.ca)
Date: Thu Oct  9 14:22:05 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <20081008120337.GE4249@zombie.inf.tu-dresden.de>
References: <20081008120337.GE4249@zombie.inf.tu-dresden.de>
Message-ID: <alpine.LRH.2.00.0810091418120.4638@theorem.ca>

>>     groupOn         :: Eq b => (a -> b) -> [a] -> [[a]]

I don't know how other people use groupBy, but I'm almost always looking 
for something of the the type

Eq b => (a -> b) -> [a] -> [(b,[a])]

I just bring this up as something to think about.  It is easy to construct 
from groupOn, however it is almost as easy to construct from groupBy.  So 
groupOn doesn't really gain me much. :)

-- 
Russell O'Connor                                      <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
From patperry at stanford.edu  Thu Oct  9 16:26:17 2008
From: patperry at stanford.edu (Patrick Perry)
Date: Thu Oct  9 16:22:37 2008
Subject: Bugfix for QuickCheck 1.1.0.0
In-Reply-To: <20080905154441.GA15602@matrix.chaos.earth.li>
References: <4E804BD8-22DB-4EDF-AC29-900908603650@stanford.edu>
	<62E8F614-D0C2-46BA-AE22-FFE642C88585@stanford.edu>
	<20080905154441.GA15602@matrix.chaos.earth.li>
Message-ID: <EDDD1E71-08C0-4B4C-88B1-3D8E47D54218@stanford.edu>


The version of QuickCheck in GHC-6.10 fixes a bug in the version  
bundled with GHC-6.8.  Both versions of the library claim to be  
Quickcheck-1.1.0.0.  Should someone bump the version number?


Patrick

This is the last time I bother anybody about this.  This whole process  
has been far too painful.

On Sep 5, 2008, at 8:44 AM, Ian Lynagh wrote:

> On Sun, Aug 31, 2008 at 10:28:32AM -0700, Patrick Perry wrote:
>> It's been a week and no one has objected.  I'm interpreting your
>> silence on the matter as consent.  Could someone with commit access
>> please add the patch and bump the version number for QuickCheck?
>
> So are we all agreed that this should be applied, now?
>
> Patrick, could you add to
>    http://hackage.haskell.org/trac/ghc/ticket/2535
> a summary of the discussion and a link to the mailing list archives of
> this thread, please?
>
>
> Thanks
> Ian
>

From dons at galois.com  Thu Oct  9 16:30:25 2008
From: dons at galois.com (Don Stewart)
Date: Thu Oct  9 16:26:34 2008
Subject: Bugfix for QuickCheck 1.1.0.0
In-Reply-To: <EDDD1E71-08C0-4B4C-88B1-3D8E47D54218@stanford.edu>
References: <4E804BD8-22DB-4EDF-AC29-900908603650@stanford.edu>
	<62E8F614-D0C2-46BA-AE22-FFE642C88585@stanford.edu>
	<20080905154441.GA15602@matrix.chaos.earth.li>
	<EDDD1E71-08C0-4B4C-88B1-3D8E47D54218@stanford.edu>
Message-ID: <20081009203025.GK27019@scytale.galois.com>

patperry:
> The version of QuickCheck in GHC-6.10 fixes a bug in the version  
> bundled with GHC-6.8.  Both versions of the library claim to be  
> Quickcheck-1.1.0.0.  Should someone bump the version number?
> 
> Patrick
> 
> This is the last time I bother anybody about this.  This whole process  
> has been far too painful.

The bumping of extralibs prior to the RC would have been useful, but it
isn't a showstopper for testing.

-- Don
From lemming at henning-thielemann.de  Fri Oct 10 04:54:52 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri Oct 10 04:51:05 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <200810071317.04633.g9ks157k@acme.softbase.org>
References: <48E8DFBC.30408@gmail.com>
	<1223231683.14163.493.camel@dell.linuxdev.us.dell.com>
	<200810071317.04633.g9ks157k@acme.softbase.org>
Message-ID: <Pine.SOC.4.64.0810101024310.8605@haydn.informatik.uni-halle.de>


On Tue, 7 Oct 2008, Wolfgang Jeltsch wrote:

> Am Sonntag, 5. Oktober 2008 20:34 schrieb Duncan Coutts:
>> I think fewer names and more combinations is usually best unless there
>> is a really compelling reason. Just because things are often used in
>> combination doesn't mean we have to make a new name to represent that
>> composition. As functional programmers we are very used to using
>> composition, especially simple function application.
>
> I fully agree!
>
> The identifiers of the proposed new functions are rather systematic.  So why
> not use the means of the language (combining higher-order functions) to
> express the underlying structure instead of relying on naming conventions and
> boilerplate code?

  The problem is, that combinations of functions get larger and larger this 
way. I consider it good style to write short function definitions, which 
in turn use other functions, that make sense of their own. If every 
function definition is short, your argument would mean, that it is better 
not to define such functions at all, why not inlining all those 
definitions in the main program? Why having 'map' and 'filter', they are 
just 'foldr' with simple function arguments. I have once proposed to add 
'toMaybe' to Data.Maybe [1]. It was rejected, because it can easily be 
implemented with 'guard'. However, that's not the point. It's often the 
case that 'toMaybe' is simpler to apply and it denotes a frequent pattern. 
So I continue to define it in the Utility modules of many of my packages. 
The same discussion arose about 'concatMap' and 'intercalate'.
  I see two extremes:
   1. Minimal number of functions in standard modules and many 
re-implementations of common patterns in Utility modules of various 
packages or worse: large function definitions in application code.
   2. Maximum number of functions in standard moudles for every combination 
or at least for every already used combination of functions, where 
application code only consists of calling one function from a standard 
module.
  I think none of the extremes is what we want. In my opinion if people 
become aware that a certain combination of functions is widely spread, or 
even more a certain combination is the main application of one of the 
invoked functions, this is a good sign to make this use pattern explicit 
by a new function. I share the impression with the original poster, that 
'sortBy' and 'groupBy' are most oftenly used with 'on'. I remember that 
'on' was precisely introduced to support 'sortBy' and 'groupBy'. However 
'sortBy' with 'on' must recompute the sorting key. Such recomputation can 
only be avoided with a new function - or by optimizer rules, which 
replace 'sortBy (compare `on` f)' by 'sortOn f' and so on.


[1] http://www.haskell.org/pipermail/haskell-cafe/2007-November/034259.html
From lemming at henning-thielemann.de  Fri Oct 10 05:03:25 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri Oct 10 04:59:39 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <953e0d250810061432y328d70c3h25ca18fe2a673422@mail.gmail.com>
References: <48E8DFBC.30408@gmail.com>
	<33A3F585590A6F4E81E3D45AA4A111C902CD3AA3@ELON17P32001A.csfb.cs-group.com>
	<48EA7A15.20408@gmail.com>
	<953e0d250810061432y328d70c3h25ca18fe2a673422@mail.gmail.com>
Message-ID: <Pine.SOC.4.64.0810101101160.8605@haydn.informatik.uni-halle.de>


On Mon, 6 Oct 2008, Jean-Philippe Bernardy wrote:

> How about capturing the pattern in higher order functions?
>
> if we define:
>
>> import Data.Function
>> import Data.List
>
>> data Cache b a = Cache b a
>> fromCache (Cache _ a) = a
>> toCache f a = Cache (f a) a
>> cache (Cache b _) = b
>
>> caching f g = map fromCache . g . map (toCache f)

I've already done this with plain pairs - a distinct type like Cache is of 
course better. See attachKey:
   http://darcs.haskell.org/htam/src/Useful.hs

From jpm at cs.uu.nl  Fri Oct 10 08:31:00 2008
From: jpm at cs.uu.nl (=?ISO-8859-1?Q?Jos=E9_Pedro_Magalh=E3es?=)
Date: Fri Oct 10 08:27:13 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com>
References: <1C4AE74FD8C843B1AAC9D92AE067F090@cr3lt>
	<638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
	<gcag3t$2u4$1@ger.gmane.org>
	<52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com>
Message-ID: <52f14b210810100531q309ddc04v5d9e1f039d40db77@mail.gmail.com>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchBase3-compat
Type: application/octet-stream
Size: 444 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081010/4e2ff941/patchBase3-compat.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchBase4
Type: application/octet-stream
Size: 1482 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081010/4e2ff941/patchBase4.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchSyb
Type: application/octet-stream
Size: 1931 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20081010/4e2ff941/patchSyb.obj
From dons at galois.com  Sat Oct 11 13:21:47 2008
From: dons at galois.com (Don Stewart)
Date: Sat Oct 11 13:17:47 2008
Subject: A wiki page for managing the 6.10 handover
Message-ID: <20081011172147.GD11641@scytale.galois.com>

http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_6.10

It collects the 7 or so known issues that break code with GHC 6.10.
Please feel free to clean up, and especially *add techniques for
handling each change*.

If we do this right, with cabal-install being smart, clear summaries of
what is broken and how to fix it, this might be the smoothest major
release yet.

-- Don
From igloo at earth.li  Sat Oct 11 13:40:14 2008
From: igloo at earth.li (Ian Lynagh)
Date: Sat Oct 11 13:36:24 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com>
References: <g9ls3q$h2c$1@ger.gmane.org>
	<638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
	<gcag3t$2u4$1@ger.gmane.org>
	<52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com>
Message-ID: <20081011174014.GA21775@matrix.chaos.earth.li>

On Mon, Oct 06, 2008 at 10:00:40AM +0200, Jos? Pedro Magalh?es wrote:
> On Sun, Oct 5, 2008 at 15:40, Claus Reinke <claus.reinke@talk21.com> wrote:
> 
> > >The following "dubious" instances are now in the syb package (in the
> > >Data.Generics.Instances module): DataType TyCon TypeRep Handle ThreadId
> > >StablePtr (a -> b) (IO a) (ST s a) (STM a) (IORef a) (TVar a) (MVar a).
> > All
> > >the other instances are in the base package, Data.Data module.
> >
> > Contrary to that list, 'Data (a->b)' is still in Data.Data?
> >
> 
> Oops, my mistake. Thanks for noticing! Attaching patches.

Applied to 6.10 and HEAD.


Thanks
Ian

From bulat.ziganshin at gmail.com  Sat Oct 11 13:47:36 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Sat Oct 11 13:45:21 2008
Subject: A wiki page for managing the 6.10 handover
In-Reply-To: <20081011172147.GD11641@scytale.galois.com>
References: <20081011172147.GD11641@scytale.galois.com>
Message-ID: <25706211.20081011214736@gmail.com>

Hello Don,

Saturday, October 11, 2008, 9:21:47 PM, you wrote:
> It collects the 7 or so known issues that break code with GHC 6.10.

i've quickly tried to compile my app with 6.10 (using base4). all the
problems i got was due to exception handling. catch, finally, throwIO
doesn't work

added to wiki


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From dons at galois.com  Sat Oct 11 13:54:10 2008
From: dons at galois.com (Don Stewart)
Date: Sat Oct 11 13:50:09 2008
Subject: A wiki page for managing the 6.10 handover
In-Reply-To: <25706211.20081011214736@gmail.com>
References: <20081011172147.GD11641@scytale.galois.com>
	<25706211.20081011214736@gmail.com>
Message-ID: <20081011175410.GF11641@scytale.galois.com>

bulat.ziganshin:
> Hello Don,
> 
> Saturday, October 11, 2008, 9:21:47 PM, you wrote:
> > It collects the 7 or so known issues that break code with GHC 6.10.
> 
> i've quickly tried to compile my app with 6.10 (using base4). all the
> problems i got was due to exception handling. catch, finally, throwIO
> doesn't work
> 
> added to wiki

The fix for exception handling and friends is to add a dependency on
base-3,

    http://haskell.org/haskellwiki/Upgrading_packages#Adding_base-3_constraints

If you build your app with cabal-install, it will work this out for you,
otherwise, you need to add something like

     --constraint="base<4"

if you use runhaskell, or

    --package base-3.0.3.0

if you use ghc --make.

-- Don
From bulat.ziganshin at gmail.com  Sat Oct 11 14:02:20 2008
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Sat Oct 11 14:09:03 2008
Subject: A wiki page for managing the 6.10 handover
In-Reply-To: <20081011175410.GF11641@scytale.galois.com>
References: <20081011172147.GD11641@scytale.galois.com>
	<25706211.20081011214736@gmail.com>
	<20081011175410.GF11641@scytale.galois.com>
Message-ID: <1705811808.20081011220220@gmail.com>

Hello Don,

Saturday, October 11, 2008, 9:54:10 PM, you wrote:

seems that i misunderstood it: i thought it's a list of base4 vs base3
changes, but actually it seems like a base30 vs base31?

base3 -> base4 upgrade hints are not documented anywhere?


> bulat.ziganshin:
>> Hello Don,
>> 
>> Saturday, October 11, 2008, 9:21:47 PM, you wrote:
>> > It collects the 7 or so known issues that break code with GHC 6.10.
>> 
>> i've quickly tried to compile my app with 6.10 (using base4). all the
>> problems i got was due to exception handling. catch, finally, throwIO
>> doesn't work
>> 
>> added to wiki

> The fix for exception handling and friends is to add a dependency on
> base-3,

>    
> http://haskell.org/haskellwiki/Upgrading_packages#Adding_base-3_constraints

> If you build your app with cabal-install, it will work this out for you,
> otherwise, you need to add something like

>      --constraint="base<4"

> if you use runhaskell, or

>     --package base-3.0.3.0

> if you use ghc --make.

> -- Don


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com

From dons at galois.com  Sat Oct 11 14:23:24 2008
From: dons at galois.com (Don Stewart)
Date: Sat Oct 11 14:19:21 2008
Subject: A wiki page for managing the 6.10 handover
In-Reply-To: <1705811808.20081011220220@gmail.com>
References: <20081011172147.GD11641@scytale.galois.com>
	<25706211.20081011214736@gmail.com>
	<20081011175410.GF11641@scytale.galois.com>
	<1705811808.20081011220220@gmail.com>
Message-ID: <20081011182324.GG11641@scytale.galois.com>

bulat.ziganshin:
> Hello Don,
> 
> Saturday, October 11, 2008, 9:54:10 PM, you wrote:
> 
> seems that i misunderstood it: i thought it's a list of base4 vs base3
> changes, but actually it seems like a base30 vs base31?
> 
> base3 -> base4 upgrade hints are not documented anywhere?
> 

It's a list of how to upgrade your code to GHC 6.10 and keep it working.
If you want to describe how to migrate from base3 to base4, that is also
useful, but not criical yet, since it won't break things.

-- Don
From dons at galois.com  Sat Oct 11 21:13:51 2008
From: dons at galois.com (Don Stewart)
Date: Sat Oct 11 21:09:45 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
Message-ID: <20081012011351.GL11641@scytale.galois.com>


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,

    * Changes to Arrow class definition
    * Changes to types of Map and Set functions
    * Cabal changes
    * Changes to ghc-api
    * Changes to when 'forall' is parsed (add Rank2Types)
    * GHC.Prim was moved,
    * Changes to -fvia-C and headers
    * GADT changes,
    * pragma warnings tightened
    * Integer constructors have moved
    * New warnings and used -Werror

How to address these, as library maintainers, is addressed here,

    http://haskell.org/haskellwiki/Upgrading_packages

Packages that have broken wrt. the new core library APIs are,

    ArrayRef-0.1.2
    CLASE-2008.9.23.2
    EdisonCore-1.2.1.2
    HPDF-1.4
    HaLeX-1.1
    Hashell-0.15
    Hipmunk-0.2
    MemoTrie-0.0
    NewBinary-0.1.1
    PArrows-0.1
    TypeCompose-0.5
    WebBits-0.9.2
    YamlReference-0.9.2
    Yampa-0.9.2.2
    arrows-0.4
    bytestring-show-0.2
    cabal-setup-1.2.1
    chp-1.1.0
    cmath-0.3
    fixpoint-0.1
    hasim-0.1
    hask-home-2007.12.6
    heap-0.4.0
    hetris-0.2
    hexpat-0.2
    hinstaller-2008.2.16
    hint-0.2.4.1
    hslackbuilder-0.0.1
    hxt-8.1.0
    iException-0.0.1
    libGenI-0.16.1
    list-extras-0.2.2
    logfloat-0.9.1
    mage-1.1.0
    numeric-prelude-0.0.4
    plugins-1.3
    quantum-arrow-0.0.4
    regex-tdfa-0.94    
    streamproc-1.1
    stringtable-atom-0.0.4
    typalyze-0.1.1
    unicode-prelude-0.1
    xmonad-utils-0.1
    yhccore-0.9

GHC bugs are suspected for,

    xmonad-contrib, stream-fusion, harpy, OpenAFP

Tickets are open for these.

Build reports for these packages were posted yesterday,

    http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15430

-- Don
From ashley at semantic.org  Sat Oct 11 22:12:14 2008
From: ashley at semantic.org (Ashley Yakeley)
Date: Sat Oct 11 22:08:22 2008
Subject: Ubuntu Haskell
In-Reply-To: <20081004191547.GA1429@scytale.galois.com>
References: <20081004191547.GA1429@scytale.galois.com>
Message-ID: <48F15CFE.9000106@semantic.org>

Don Stewart wrote:
>     * Arch now has 609 Haskell packages in AUR.

Have you thought about doing this for Ubuntu? If you know how to 
automatically generate packages, you could set up a PPA (private package 
archive) on Launchpad.

-- 
Ashley Yakeley
From dons at galois.com  Sat Oct 11 22:16:22 2008
From: dons at galois.com (Don Stewart)
Date: Sat Oct 11 22:12:18 2008
Subject: Ubuntu Haskell
In-Reply-To: <48F15CFE.9000106@semantic.org>
References: <20081004191547.GA1429@scytale.galois.com>
	<48F15CFE.9000106@semantic.org>
Message-ID: <20081012021622.GO11641@scytale.galois.com>

ashley:
> Don Stewart wrote:
> >    * Arch now has 609 Haskell packages in AUR.
> 
> Have you thought about doing this for Ubuntu? If you know how to 
> automatically generate packages, you could set up a PPA (private package 
> archive) on Launchpad.

I've spoken with Jeremy Shaw, who has similar systems in place, based
also on Cabal (and cabal-install), for generating native packages for
Debian & Ubuntu.

However, we do need some Ubuntu champions who can work incrementally,
over a long time, to keep packages up to date on their systems.

Automation makes this a *lot* easier, so you may only need one or two
people, motivated to work on their distro.

-- Don
From igloo at earth.li  Sun Oct 12 06:39:11 2008
From: igloo at earth.li (Ian Lynagh)
Date: Sun Oct 12 06:35:19 2008
Subject: Splitting SYB from the base package in GHC 6.10
In-Reply-To: <52f14b210810100531q309ddc04v5d9e1f039d40db77@mail.gmail.com>
References: <638ABD0A29C8884A91BC5FB5C349B1C32AE88093CD@EA-EXMSG-C334.europe.corp.microsoft.com>
	<52f14b210809150428w4cd4061bg4b855fc44ac11b28@mail.gmail.com>
	<20080916084133.GA2878@soi.city.ac.uk>
	<20080922195449.GA22526@matrix.chaos.earth.li>
	<52f14b210809230603n5d7c2fa5ga6a791e48a27bcad@mail.gmail.com>
	<20080925155836.GA30388@matrix.chaos.earth.li>
	<52f14b210810040817p30893bb9vdb04aa6d57bc3702@mail.gmail.com>
	<gcag3t$2u4$1@ger.gmane.org>
	<52f14b210810060100w40f91dd3i27a63e2b10bc9ff5@mail.gmail.com>
	<52f14b210810100531q309ddc04v5d9e1f039d40db77@mail.gmail.com>
Message-ID: <20081012103911.GA18317@matrix.chaos.earth.li>


Hi Pedro,

On Fri, Oct 10, 2008 at 02:31:00PM +0200, Jos? Pedro Magalh?es wrote:
> 
> I'm attaching some more patches to fix the haddock documentation (somewhat)
> and the export list of Data.Generics.Instances.

Thanks; applied to HEAD and 6.10.


Thanks
Ian

From lemming at henning-thielemann.de  Sun Oct 12 09:40:53 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun Oct 12 09:37:17 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <20081012011351.GL11641@scytale.galois.com>
References: <20081012011351.GL11641@scytale.galois.com>
Message-ID: <Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>


On Sat, 11 Oct 2008, Don Stewart wrote:

> Build reports for these packages were posted yesterday,
>
>    http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15430

For 'numeric-prelude' it is reported:

numeric-prelude
     src/Number/Complex.hs:3:12:
         cannot parse LANGUAGE pragma: comma-separated list expected


The offending pragma is:
{-# LANGUAGE_HOW_CAN_WE_ENABLE Rules ? #-}

Why is this interpreted as LANGUAGE pragma at all?

... and erm, how can I enable parsing of optimizer rules?
With {-# OPTIONS_GHC -O #-} ?
From igloo at earth.li  Sun Oct 12 09:56:37 2008
From: igloo at earth.li (Ian Lynagh)
Date: Sun Oct 12 09:52:44 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
Message-ID: <20081012135637.GA21073@matrix.chaos.earth.li>

On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
> 
> ... and erm, how can I enable parsing of optimizer rules?
> With {-# OPTIONS_GHC -O #-} ?

Yes, although note that Cabal passes -O by default. I'd recommend not
putting it in a pragma, as that will break
    ./Setup configure --disable-optimization


Thanks
Ian

From duncan.coutts at worc.ox.ac.uk  Sun Oct 12 12:52:38 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Oct 12 12:48:46 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <20081012135637.GA21073@matrix.chaos.earth.li>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
Message-ID: <1223830358.14942.7.camel@dell.linuxdev.us.dell.com>

On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
> On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
> > 
> > ... and erm, how can I enable parsing of optimizer rules?
> > With {-# OPTIONS_GHC -O #-} ?
> 
> Yes, although note that Cabal passes -O by default. I'd recommend not
> putting it in a pragma, as that will break
>     ./Setup configure --disable-optimization

I think the question was how to get the RULES pragmas to be parsed. One
does have to turn on a language extension to get the forall in rules to
parse and it's not very clear at the moment which one we should be
using.

See http://hackage.haskell.org/trac/ghc/ticket/2497

Duncan

From dons at galois.com  Sun Oct 12 14:09:18 2008
From: dons at galois.com (Don Stewart)
Date: Sun Oct 12 14:05:15 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
Message-ID: <20081012180918.GA18699@scytale.galois.com>

duncan.coutts:
> On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
> > On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
> > > 
> > > ... and erm, how can I enable parsing of optimizer rules?
> > > With {-# OPTIONS_GHC -O #-} ?
> > 
> > Yes, although note that Cabal passes -O by default. I'd recommend not
> > putting it in a pragma, as that will break
> >     ./Setup configure --disable-optimization
> 
> I think the question was how to get the RULES pragmas to be parsed. One
> does have to turn on a language extension to get the forall in rules to
> parse and it's not very clear at the moment which one we should be
> using.
> 
> See http://hackage.haskell.org/trac/ghc/ticket/2497

I've been suggesting Rank2Types, which does the trick.

-- Don
From lemming at henning-thielemann.de  Sun Oct 12 14:38:55 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun Oct 12 14:35:00 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
Message-ID: <Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>


On Sun, 12 Oct 2008, Duncan Coutts wrote:

> On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
>> On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
>>>
>>> ... and erm, how can I enable parsing of optimizer rules?
>>> With {-# OPTIONS_GHC -O #-} ?
>>
>> Yes, although note that Cabal passes -O by default. I'd recommend not
>> putting it in a pragma, as that will break
>>     ./Setup configure --disable-optimization
>
> I think the question was how to get the RULES pragmas to be parsed.

I wondered whether it is possible to let the compiler read and store the 
RULES pragmas without optimizing the code in the same module with respect 
to these RULES. When I want to compile the code without optimization - for 
whatever reason - I would still like to have the RULES checked. They could 
still be applied when imported to another module that is compiled with 
optimization.
From dons at galois.com  Sun Oct 12 15:38:40 2008
From: dons at galois.com (Don Stewart)
Date: Sun Oct 12 15:34:42 2008
Subject: Arch Haskell News: Oct 12 2008
Message-ID: <20081012193840.GC18699@scytale.galois.com>

News about Haskell on Arch Linux
http://archhaskell.wordpress.com/2008/10/12/arch-haskell-news-oct-12-2008/

Arch now has 624 Haskell packages in AUR.

That?s an increase of 15 new packages in the last 7 days.

Planning is also underway for the GHC 6.10 release, and the 6.10 release
candidate is in testing.

Noteworthy

* cabal-install-0.6.0: ?The command-line interface for Cabal and Hackage.?
* haskell-cabal-1.6.0.1: ?A framework for packaging Haskell software?
* haskell-bytestring-0.9.1.3: ?Fast, packed, strict and lazy byte arrays with a list interface?
* haskell-transactional-events-0.1.0.0: ?Transactional events, based on Concurrent ML semantics?

Full details on the site.
From dons at galois.com  Sun Oct 12 17:46:05 2008
From: dons at galois.com (Don Stewart)
Date: Sun Oct 12 17:42:05 2008
Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate
Message-ID: <20081012214605.GA19039@scytale.galois.com>

Hey all.

The GHC 6.10 RCs are out, and we're preparing the release. To help manage the 
transistion to GHC 6.10 it is now possible to actually build all the 3rd party
Haskell packages, and publish their results wrt. the release candidate.

For the first time ever, we're able to have all the 3rd party code
tested and ready to go *prior* to the release of the new compiler and
base libraries.

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

      1 UnpackFailed
      2 DownloadFailed
      2 InstallFailed
     16 ConfigureFailed
     73 DependencyFailed
    132 BuildFailed
    456 InstallOk

Note that these builds are with "soft deps", provided on hackage,

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

which train cabal-install to build a larger set of packages.

The important result:

    *46 packages produce different results to ghc 6.8.2*

These packages and their logs are listed below.

If you maintain one of the following packages, and are able to fix it before
GHC 6.10 is released, your users will be happy.

The most common issues for these differences are,

    * Changes to Arrow class definition
    * Changes to types of Map and Set functions
    * Cabal changes
    * Changes to ghc-api
    * Changes to when 'forall' is parsed (add Rank2Types)
    * GHC.Prim was moved,
    * Changes to -fvia-C and headers
    * GADT changes,
    * pragma warnings tightened
    * Integer constructors have moved
    * New warnings and used -Werror

How to address these, as library maintainers, is addressed here,

    http://haskell.org/haskellwiki/Upgrading_packages

Build reports for everything, produced today, are here,

    http://galois.com/~dons/tmp/build-logs-2008-10-12/

The following packages are producing different results than with ghc 6.8.2.
Package maintainers are invited to look at them.

    ArrayRef-0.1.2
    CLASE-2008.9.23.2
    EdisonCore-1.2.1.2
    HPDF-1.4
    HaLeX-1.1
    Hashell-0.15
    Hipmunk-0.2
    MemoTrie-0.0
    NewBinary-0.1.1
    PArrows-0.1
    TypeCompose-0.5
    WebBits-0.9.2
    YamlReference-0.9.2
    Yampa-0.9.2.2
    arrows-0.4
    bytestring-show-0.2
    cabal-setup-1.2.1
    chp-1.1.0
    cmath-0.3
    fixpoint-0.1
    hasim-0.1
    hask-home-2007.12.6
    hetris-0.2
    hexpat-0.2
    hinstaller-2008.2.16
    hint-0.2.4.1
    hslackbuilder-0.0.1
    hxt-8.1.0
    iException-0.0.1
    libGenI-0.16.1
    list-extras-0.2.2
    logfloat-0.9.1
    mage-1.1.0
    numeric-prelude-0.0.4
    plugins-1.3
    quantum-arrow-0.0.4
    regex-tdfa-0.94    
    streamproc-1.1
    stringtable-atom-0.0.4
    typalyze-0.1.1
    xmonad-utils-0.1
    yhccore-0.9

If you'd like to try your own build of all of hackage, grab a package
list (such as this one),

    http://www.galois.com/~dons/tmp/pkgs-6.10 

Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage),
and cabal-install 0.6 (on hackage), and then simply,

    cabal install -v -O0 $(cat pkgs-6.10) --build-reports

This will construct a clever plan to install all the packages in the
right order, and write logs to ~/.cabal/logs and a full structured build
report into ~/.cabal/packages/hackage.*/build-report.log

-- Don

From marlowsd at gmail.com  Mon Oct 13 05:08:44 2008
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Oct 13 05:04:56 2008
Subject: A wiki page for managing the 6.10 handover
In-Reply-To: <20081011172147.GD11641@scytale.galois.com>
References: <20081011172147.GD11641@scytale.galois.com>
Message-ID: <48F3101C.5010402@gmail.com>

Don Stewart wrote:
> http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_6.10
> 
> It collects the 7 or so known issues that break code with GHC 6.10.
> Please feel free to clean up, and especially *add techniques for
> handling each change*.
> 
> If we do this right, with cabal-install being smart, clear summaries of
> what is broken and how to fix it, this might be the smoothest major
> release yet.

This is wonderful.  I've been making noises about trying to make the 
transition smoother this time, but you and Duncan have done most of the 
hard work.  Not only that, but the process has turned up some bugs that 
hopefully we'll be able to fix in time for the release.  Great stuff, 
thanks guys!

Cheers,
	Simon

From simonpj at microsoft.com  Mon Oct 13 05:12:03 2008
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon Oct 13 05:07:19 2008
Subject: A wiki page for managing the 6.10 handover
In-Reply-To: <48F3101C.5010402@gmail.com>
References: <20081011172147.GD11641@scytale.galois.com>
	<48F3101C.5010402@gmail.com>
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76A789AC@EA-EXMSG-C334.europe.corp.microsoft.com>

| http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_
| 6.10
| >
| > It collects the 7 or so known issues that break code with GHC 6.10.
| > Please feel free to clean up, and especially *add techniques for
| > handling each change*.
| >
| > If we do this right, with cabal-install being smart, clear summaries of
| > what is broken and how to fix it, this might be the smoothest major
| > release yet.
|
| This is wonderful.  I've been making noises about trying to make the
| transition smoother this time, but you and Duncan have done most of the
| hard work.  Not only that, but the process has turned up some bugs that
| hopefully we'll be able to fix in time for the release.  Great stuff,
| thanks guys!

Yes, a big thank you from me too.  Fantastic work.

Simon
From marlowsd at gmail.com  Mon Oct 13 05:14:36 2008
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon Oct 13 05:10:52 2008
Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate
In-Reply-To: <20081012214605.GA19039@scytale.galois.com>
References: <20081012214605.GA19039@scytale.galois.com>
Message-ID: <48F3117C.1020805@gmail.com>

Don Stewart wrote:

> Note that these builds are with "soft deps", provided on hackage,
> 
>     base < 4
>     parsec < 3
>     HaXml == 1.13.*
>     QuickCheck < 2
> 
> which train cabal-install to build a larger set of packages.

Will this happen automatically somehow, or will users have to do this manually?

> The important result:
> 
>     *46 packages produce different results to ghc 6.8.2*
> 
> These packages and their logs are listed below.
> 
> If you maintain one of the following packages, and are able to fix it before
> GHC 6.10 is released, your users will be happy.
> 
> The most common issues for these differences are,
> 
>     * Changes to Arrow class definition
>     * Changes to types of Map and Set functions

It would be feasible to provide a containers-0.1, if anyone thinks that's 
worthwhile.

>     * Cabal changes
>     * Changes to ghc-api
>     * Changes to when 'forall' is parsed (add Rank2Types)
>     * GHC.Prim was moved,

Nobody should be importing GHC.Prim, use GHC.Exts instead.

>     * Changes to -fvia-C and headers

I wrote a more detailed entry for the release notes about this:

http://www.haskell.org/ghc/dist/stable/docs/users_guide/release-6-10-1.html

("FFI change" under "User-visible compiler changes")

Cheers,
	Simon
From simonpj at microsoft.com  Mon Oct 13 09:04:11 2008
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Mon Oct 13 09:00:17 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>

| >> Yes, although note that Cabal passes -O by default. I'd recommend not
| >> putting it in a pragma, as that will break
| >>     ./Setup configure --disable-optimization
| >
| > I think the question was how to get the RULES pragmas to be parsed.

There's a bug I'm fixing (http://hackage.haskell.org/trac/ghc/ticket/2497).

| I wondered whether it is possible to let the compiler read and store the
| RULES pragmas without optimizing the code in the same module with respect
| to these RULES. When I want to compile the code without optimization - for
| whatever reason - I would still like to have the RULES checked. They could
| still be applied when imported to another module that is compiled with
| optimization.

Indeed you can: use -fno-omit-interface-pragmas. This overrides the default, which is that with -O no non-essential info is put in the interface file.

If you think it's worth improving the documentation (e.g. you didn't know about this), then I'd welcome a concrete suggestion.  (eg Say "...this..." in the second bullet off ...".)

Simon
From dons at galois.com  Mon Oct 13 13:54:08 2008
From: dons at galois.com (Don Stewart)
Date: Mon Oct 13 13:50:32 2008
Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate
In-Reply-To: <48F3117C.1020805@gmail.com>
References: <20081012214605.GA19039@scytale.galois.com>
	<48F3117C.1020805@gmail.com>
Message-ID: <20081013175408.GA22398@scytale.galois.com>

marlowsd:
> Don Stewart wrote:
> 
> >Note that these builds are with "soft deps", provided on hackage,
> >
> >    base < 4
> >    parsec < 3
> >    HaXml == 1.13.*
> >    QuickCheck < 2
> >
> >which train cabal-install to build a larger set of packages.
> 
> Will this happen automatically somehow, or will users have to do this 
> manually?

Yes, Duncan and Ross have modified the scripts on hackage, so that a 
"preferred-versions" file is included in the Hackage index. So there is
one central point where these version suggestions to cabal-install are
set. As long as you're using cabal-install 0.6, and do a 'cabal update' 
things should just work.

-- Don
From duncan.coutts at worc.ox.ac.uk  Mon Oct 13 14:27:55 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Mon Oct 13 14:24:00 2008
Subject: 2008-10-12 Hackage status with GHC 6.10 release candidate
In-Reply-To: <20081013175408.GA22398@scytale.galois.com>
References: <20081012214605.GA19039@scytale.galois.com>
	<48F3117C.1020805@gmail.com>
	<20081013175408.GA22398@scytale.galois.com>
Message-ID: <1223922475.14942.40.camel@dell.linuxdev.us.dell.com>

On Mon, 2008-10-13 at 10:54 -0700, Don Stewart wrote:
> marlowsd:
> > Don Stewart wrote:
> > 
> > >Note that these builds are with "soft deps", provided on hackage,
> > >
> > >    base < 4
> > >    parsec < 3
> > >    HaXml == 1.13.*
> > >    QuickCheck < 2
> > >
> > >which train cabal-install to build a larger set of packages.
> > 
> > Will this happen automatically somehow, or will users have to do this 
> > manually?
> 
> Yes, Duncan and Ross have modified the scripts on hackage, so that a 
> "preferred-versions" file is included in the Hackage index.

There was a day and a half or so when this change got accidentally
reverted due to some mis-communication between myself and Ross (my
fault). It's all fixed up now.

Currently these preferred version are only taken into account by "cabal
install" not "cabal configure" (though that's an obvious improvement to
do).

Duncan

From duncan.coutts at worc.ox.ac.uk  Mon Oct 13 14:35:14 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Mon Oct 13 14:31:26 2008
Subject: [Haskell-cafe] Hackage and GUI (was Hackage status with GHC
	6.10 release candidate)
In-Reply-To: <1223907325.2972.27.camel@localhost.localdomain>
References: <20081012214605.GA19039@scytale.galois.com>
	<1223907325.2972.27.camel@localhost.localdomain>
Message-ID: <1223922914.14942.44.camel@dell.linuxdev.us.dell.com>

On Mon, 2008-10-13 at 16:15 +0200, Hans van Thiel wrote:

> What's the status of Gtk2Hs with regard to Cabal? Is it correct that not
> one of the applications on Hackage, and there are some, uses or can use
> a GUI at this point in time?

Gtk2Hs still does not use Cabal as its build system. With the recent
summer of code project on a dependency framework for Cabal we're now
much closer to being able to convert Gtk2Hs to use Cabal.

There are several packages on hackage that depend on gtk2hs or
wxhaskell.

> Secondly, has Gtk2Hs compatibility been tested with GHC 6.10? In the
> past there have sometimes been problems with new GHC releases and
> Gtk2Hs. These have always been addressed, but it usually took a few
> months..

I think I've seen some patches going past on the gtk2hs-devel list for
ghc-6.10 compatibility.

Duncan

From dons at galois.com  Tue Oct 14 01:08:42 2008
From: dons at galois.com (Don Stewart)
Date: Tue Oct 14 01:04:40 2008
Subject: 2008-10-13 Hackage status with GHC 6.10 release candidate
Message-ID: <20081014050842.GB25748@scytale.galois.com>

Hey all.

The GHC 6.10 RCs are out, and we're preparing the release of GHC proper.
To help manage the transistion to GHC 6.10 it is now possible to
actually build all the 3rd party Haskell packages, and publish their
results wrt. the release candidate.

For the first time ever, we're able to have all the 3rd party code
tested and ready to go *prior* to the release of the new compiler and
base libraries.

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

      1 UnpackFailed
      2 DownloadFailed
      2 InstallFailed
     16 ConfigureFailed
     68 DependencyFailed
    122 BuildFailed
    469 InstallOk

Since yesterday,

    * dependency failures have reduced by 5
    * build failures have reduced by 10
    * total successfully installed packages are **up by 14**

These new packages now all build ok with the GHC 6.10 release candidate,

    Graphalyze-0.4
    alsa-midi
    calc
    glome-hs
    harpy
    heap
    hmp3
    ircbouncer
    mohws
    panda
    pandoc
    roguestar-engine
    type-level
    typeof
    unicode-prelude
    urlcheck

Good work everyone!

Some packages are still not ready though, if you maintain one of the following
packages, and are able to fix it before GHC 6.10 is released, your users will
be happy.

The most common issues for these differences are,

    * Changes to Arrow class definition
    * Changes to types of Map and Set functions
    * Cabal changes
    * Changes to ghc-api
    * Changes to when 'forall' is parsed (add Rank2Types)
    * GHC.Prim was moved,
    * Changes to -fvia-C and headers
    * GADT changes,
    * pragma warnings tightened
    * Integer constructors have moved
    * New warnings and used -Werror

The following packages are still producing different results than with ghc
6.8.2.  Package maintainers are invited to look at them.

I've marked the easy ones.

    ArrayRef-0.1.2
        Easy:   duplicate type signatures
    CLASE-2008.9.23.2
        Hard:   GADT changes 
    EdisonCore-1.2.1.2
        Easy:   Monadic Map
    HPDF-1.4
        Easy:   Monadic Map
    HaLeX-1.1
        Easy:   Name clash with permutations
    Hashell-0.15
        ?   :   GHC API
    Hipmunk-0.2
        Easy:   Monadic Map
    MemoTrie-0.0
        Easy:   'forall' parsing
    NewBinary-0.1.1
        Easy:   Integer constructors moved
    PArrows-0.1
        Easy:   GHC.Prim moved (use GHC.Exts)
    TypeCompose-0.5
        Easy:   Arrow class changes
    YamlReference-0.9.2
        Hard.   Unknown
    Yampa-0.9.2.2
        Arrow class changes
    arrows-0.4
        Arrow class changes
    bytestring-show-0.2
        Easy:   Integer constructors moved
    cabal-setup-1.2.1
        Hard:   Cabal changes
    chp-1.1.0
        Easy:   Arrow class changes
    cmath-0.3
        Hard:   -fvia-C changes
    fixpoint-0.1
        Easy:   Uses -Werror unnecessarily
    hasim-0.1
        Hard:   GADT changes
    hask-home-2007.12.6
        Easy:   Cabal changes
    hetris-0.2
        Easy:   header macros/-fvia-C
    hexpat-0.2
        Easy:   'forall' parsing in RULES
    hinstaller-2008.2.16
        Easy:   Cabal changes
    hint-0.2.4.1
        Hard?   GHC API
    hslackbuilder-0.0.1
        Easy:   Cabal changes
    hxt-8.1.0
        Easy:   Arrow class change
    iException-0.0.1
        ?       Exception changes
    libGenI-0.16.1
        Easy:   Monadic Map changes
    mage-1.1.0
        Hard:   -fvia-C changes
    numeric-prelude-0.0.4
        Easy:   Lanuage pragma
    plugins-1.3
        Easy:   Cabal changes
    quantum-arrow-0.0.4
        Easy:   Arrow class changes
    regex-tdfa-0.94    
        Easy:   Map changes
    streamproc-1.1
        Easy:   Arrow class changes
    stringtable-atom-0.0.4
        Easy:   Monadic Map
    typalyze-0.1.1
        ?       GHC API
    xmonad-utils-0.1
        ?       GHC API
    yhccore-0.9
        ?       Pragma parsing

Build reports for everything, produced today, are here,

    http://galois.com/~dons/tmp/build-logs-2008-10-13/

How to address these, as library maintainers, is addressed here,

    http://haskell.org/haskellwiki/Upgrading_packages

If you'd like to try your own build of all of hackage, grab a package
list (such as this one),

    http://www.galois.com/~dons/tmp/pkgs-6.10 

Install a GHC 6.10 release candidate, upgrade to Cabal 1.6 (on hackage),
and cabal-install 0.6 (on hackage), and then simply,

    cabal install -v -O0 $(cat pkgs-6.10) --build-reports

This will construct a clever plan to install all the packages in the
right order, and write logs to ~/.cabal/logs and a full structured build
report into ~/.cabal/packages/hackage.*/build-report.log

I'll start mailing maintainers personally tomorrow.

-- Don
From duncan.coutts at worc.ox.ac.uk  Tue Oct 14 01:19:09 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Tue Oct 14 01:15:17 2008
Subject: 2008-10-13 Hackage status with GHC 6.10 release candidate
In-Reply-To: <20081014050842.GB25748@scytale.galois.com>
References: <20081014050842.GB25748@scytale.galois.com>
Message-ID: <1223961549.14942.95.camel@dell.linuxdev.us.dell.com>

On Mon, 2008-10-13 at 22:08 -0700, Don Stewart wrote:
> Using GHC 6.10 RC from today, Cabal 1.6 and cabal-install 1.16, of 682
> libraries and apps tried in total,

Note that's cabal-install-0.6  :-)

>       1 UnpackFailed

I've diagnosed this one. It will be fixed in the next cabal-install
point release.

> The following packages are still producing different results than with
> ghc 6.8.2.  Package maintainers are invited to look at them.

>     cabal-setup-1.2.1
>         Hard:   Cabal changes

This package is deprecated. Its functionality is completely subsumed by
cabal-install.

Another point for implementing that hackage feature to tag packages as
superseded.

Duncan

From simonpj at microsoft.com  Wed Oct 15 04:46:34 2008
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Wed Oct 15 04:42:35 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76A7961E@EA-EXMSG-C334.europe.corp.microsoft.com>

Right.  I've finally fixed 2497; it was a typo, and while I thought I'd tested it, the test didn't tet that RULES compile without any flags.

The story is that you should not need any funny RankN flags just to make RULES parse and typecheck. -XScopedTypeVariables gets set automatically inside a RULES pragma.  This is what the discussion on #2497 claimed, but there was a bug in the impl.


Ian pls merge:

Simon


| -----Original Message-----
| From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Duncan
| Coutts
| Sent: 12 October 2008 17:53
| To: Ian Lynagh
| Cc: Henning Thielemann; libraries@haskell.org
| Subject: Re: 2008-10-11 Hackage status with GHC 6.10
|
| On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
| > On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
| > >
| > > ... and erm, how can I enable parsing of optimizer rules?
| > > With {-# OPTIONS_GHC -O #-} ?
| >
| > Yes, although note that Cabal passes -O by default. I'd recommend not
| > putting it in a pragma, as that will break
| >     ./Setup configure --disable-optimization
|
| I think the question was how to get the RULES pragmas to be parsed. One
| does have to turn on a language extension to get the forall in rules to
| parse and it's not very clear at the moment which one we should be
| using.
|
| See http://hackage.haskell.org/trac/ghc/ticket/2497
|
| Duncan
|
| _______________________________________________
| Libraries mailing list
| Libraries@haskell.org
| http://www.haskell.org/mailman/listinfo/libraries

From Malcolm.Wallace at cs.york.ac.uk  Wed Oct 15 05:41:25 2008
From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace)
Date: Wed Oct 15 05:39:56 2008
Subject: Repair to floating point enumerations?
Message-ID: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>

Dear Haskell-Primers (and libraries).

Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98
Prelude, regarding numeric enumerations for Floats/Doubles:

    Prelude> [0, 0.3 .. 1.1]
    [0.0,0.3,0.6,0.899999,1.2]

What is odd is that the last value of the list is much larger than the
specified termination value.  But this is exactly as specified by the
Haskell'98 Report.

    http://haskell.org/onlinereport/basic.html#sect6.3.4

    "For Float and Double, the semantics of the enumFrom family is given
    by the rules for Int above, except that the list terminates when the
    elements become greater than e3+i/2 for positive increment i, or
    when they become less than e3+i/2 for negative i.

We have discussed this question (and related ones, such as whether Float
and Double belong in the Enum class at all) several times before, and I
do not wish to rehash all of those points again e.g.:

    http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg07289.html
    http://www.haskell.org/pipermail/haskell/2001-October/008218.html
    http://www.haskell.org/pipermail/haskell/2002-October/010607.html

Phil proposes that, although retaining the instances of Enum for Float
and Double, we simplify the definitions of the numericEnumFrom family:

  numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a -> a -> [a]
  numericEnumFrom         =  iterate (+1)
  numericEnumFromThen n m =  iterate (+(m-n)) n
  numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
  numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen n m)

The particular feature of note is that the odd fudge factor of (1/2 *
the increment) is removed.  The inexact nature of floating point numbers
would therefore cause a specification like

    [ 0.0, 0.1 .. 0.3 ]

to yield the sequence

    [ 0.0, 0.1, 0.2 ]

that is, to omit the upper bound, because (3 * 0.1) is actually
represented as 0.30000000000004, strictly greater than 0.3.

Phil argues that this behaviour is more desirable: "the simple fix is
that the user must add a suitable epsilon to the upper bound.  The key
word here is *suitable*.  The old definitions included completely
bizarre and often highly unsuitable choices of epsilon."

This proposal seems to me to improve the consistency of the enumeration
syntax across both the integral and floating types.  Some users may
still be surprised, but the surprise will be easier to explain.

I am bringing this question to the attention of all who are interested
in Haskell Prime, because it seems like a sensible and well-reasoned
change.  Discussion on whether to adopt this proposal for H' is welcome.

But as maintainer and bug-fixer of the Haskell'98 Report, I have also
been asked whether we should make this change retrospectively to the
Haskell'98 language (as a "typo").  Since it involves not merely an
ordinary library function, but a Prelude function, and moreover a
function that is used in the desugaring of syntax, it is less clear to
me whether to alter Haskell'98.

Thoughts?

Regards,
    Malcolm
From neil.mitchell.2 at credit-suisse.com  Wed Oct 15 06:25:38 2008
From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil)
Date: Wed Oct 15 06:26:32 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
Message-ID: <33A3F585590A6F4E81E3D45AA4A111C902CD3B48@ELON17P32001A.csfb.cs-group.com>

Hi Malcolm,

The current behaviour does sound like a bug, and the revised behaviour
does sound like a fix - and one that has a sensible explanation if
people trip over it. In general having floating point be a member of
classes such as Eq has some obvious problems, but I realise is a
necessity for practical programming. Given that we have Eq Double, then
Enum Double seems no worse.

If we don't alter H98 then a valid program under H98 vs H' will give
different results without any warning - that seems really bad. In
addition, having two instances around for one typeclass/type pair in a
big library (base) which are switched with some flag seems like a
nightmare for compiler writers. So I think a good solution would be to
fix H98 as a typo, and include it in H'.

Thanks

Neil


> -----Original Message-----
> From: libraries-bounces@haskell.org 
> [mailto:libraries-bounces@haskell.org] On Behalf Of Malcolm Wallace
> Sent: 15 October 2008 10:41 am
> To: haskell-prime@haskell.org
> Cc: libraries@haskell.org
> Subject: Repair to floating point enumerations?
> 
> Dear Haskell-Primers (and libraries).
> 
> Recently, Phil Wadler has pointed out a weird anomaly in the 
> Haskell'98 Prelude, regarding numeric enumerations for Floats/Doubles:
> 
>     Prelude> [0, 0.3 .. 1.1]
>     [0.0,0.3,0.6,0.899999,1.2]
> 
> What is odd is that the last value of the list is much larger 
> than the specified termination value.  But this is exactly as 
> specified by the
> Haskell'98 Report.
> 
>     http://haskell.org/onlinereport/basic.html#sect6.3.4
> 
>     "For Float and Double, the semantics of the enumFrom 
> family is given
>     by the rules for Int above, except that the list 
> terminates when the
>     elements become greater than e3+i/2 for positive increment i, or
>     when they become less than e3+i/2 for negative i.
> 
> We have discussed this question (and related ones, such as 
> whether Float and Double belong in the Enum class at all) 
> several times before, and I do not wish to rehash all of 
> those points again e.g.:
> 
>     http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg07289.html
>     http://www.haskell.org/pipermail/haskell/2001-October/008218.html
>     http://www.haskell.org/pipermail/haskell/2002-October/010607.html
> 
> Phil proposes that, although retaining the instances of Enum 
> for Float and Double, we simplify the definitions of the 
> numericEnumFrom family:
> 
>   numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a 
> -> a -> [a]
>   numericEnumFrom         =  iterate (+1)
>   numericEnumFromThen n m =  iterate (+(m-n)) n
>   numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
>   numericEnumFromThenTo n m p = takeWhile (<= p) 
> (numericEnumFromThen n m)
> 
> The particular feature of note is that the odd fudge factor 
> of (1/2 * the increment) is removed.  The inexact nature of 
> floating point numbers would therefore cause a specification like
> 
>     [ 0.0, 0.1 .. 0.3 ]
> 
> to yield the sequence
> 
>     [ 0.0, 0.1, 0.2 ]
> 
> that is, to omit the upper bound, because (3 * 0.1) is 
> actually represented as 0.30000000000004, strictly greater than 0.3.
> 
> Phil argues that this behaviour is more desirable: "the 
> simple fix is that the user must add a suitable epsilon to 
> the upper bound.  The key word here is *suitable*.  The old 
> definitions included completely bizarre and often highly 
> unsuitable choices of epsilon."
> 
> This proposal seems to me to improve the consistency of the 
> enumeration syntax across both the integral and floating 
> types.  Some users may still be surprised, but the surprise 
> will be easier to explain.
> 
> I am bringing this question to the attention of all who are 
> interested in Haskell Prime, because it seems like a sensible 
> and well-reasoned change.  Discussion on whether to adopt 
> this proposal for H' is welcome.
> 
> But as maintainer and bug-fixer of the Haskell'98 Report, I 
> have also been asked whether we should make this change 
> retrospectively to the
> Haskell'98 language (as a "typo").  Since it involves not 
> merely an ordinary library function, but a Prelude function, 
> and moreover a function that is used in the desugaring of 
> syntax, it is less clear to me whether to alter Haskell'98.
> 
> Thoughts?
> 
> Regards,
>     Malcolm
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 
> 

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

From droundy at darcs.net  Wed Oct 15 10:44:03 2008
From: droundy at darcs.net (David Roundy)
Date: Wed Oct 15 10:40:34 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
Message-ID: <20081015144403.GH5323@darcs.net>

On Wed, Oct 15, 2008 at 10:41:25AM +0100, Malcolm Wallace wrote:
> Dear Haskell-Primers (and libraries).
>
> Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98
> Prelude, regarding numeric enumerations for Floats/Doubles:
>
>     Prelude> [0, 0.3 .. 1.1]
>     [0.0,0.3,0.6,0.899999,1.2]
>
> What is odd is that the last value of the list is much larger than the
> specified termination value.  But this is exactly as specified by the
> Haskell'98 Report.
>
>     http://haskell.org/onlinereport/basic.html#sect6.3.4
>
>     "For Float and Double, the semantics of the enumFrom family is given
>     by the rules for Int above, except that the list terminates when the
>     elements become greater than e3+i/2 for positive increment i, or
>     when they become less than e3+i/2 for negative i.
>
> We have discussed this question (and related ones, such as whether Float
> and Double belong in the Enum class at all) several times before, and I
> do not wish to rehash all of those points again e.g.:
>
>     http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg07289.html
>     http://www.haskell.org/pipermail/haskell/2001-October/008218.html
>     http://www.haskell.org/pipermail/haskell/2002-October/010607.html
>
> Phil proposes that, although retaining the instances of Enum for Float
> and Double, we simplify the definitions of the numericEnumFrom family:
>
>   numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a -> a -> [a]
>   numericEnumFrom         =  iterate (+1)
>   numericEnumFromThen n m =  iterate (+(m-n)) n
>   numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
>   numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen n m)
>
> The particular feature of note is that the odd fudge factor of (1/2 *
> the increment) is removed.  The inexact nature of floating point numbers
> would therefore cause a specification like
>
>     [ 0.0, 0.1 .. 0.3 ]
>
> to yield the sequence
>
>     [ 0.0, 0.1, 0.2 ]
>
> that is, to omit the upper bound, because (3 * 0.1) is actually
> represented as 0.30000000000004, strictly greater than 0.3.
>
> Phil argues that this behaviour is more desirable: "the simple fix is
> that the user must add a suitable epsilon to the upper bound.  The key
> word here is *suitable*.  The old definitions included completely
> bizarre and often highly unsuitable choices of epsilon."
>
> This proposal seems to me to improve the consistency of the enumeration
> syntax across both the integral and floating types.  Some users may
> still be surprised, but the surprise will be easier to explain.
>
> I am bringing this question to the attention of all who are interested
> in Haskell Prime, because it seems like a sensible and well-reasoned
> change.  Discussion on whether to adopt this proposal for H' is welcome.
>
> But as maintainer and bug-fixer of the Haskell'98 Report, I have also
> been asked whether we should make this change retrospectively to the
> Haskell'98 language (as a "typo").  Since it involves not merely an
> ordinary library function, but a Prelude function, and moreover a
> function that is used in the desugaring of syntax, it is less clear to
> me whether to alter Haskell'98.
>
> Thoughts?

It sounds like a bad fix to me.  It seems important that the
[0.0,0.1.. x] notation should work correctly in the common cases.  And
the common case really is that the final value is intended as an exact
multiple of the increment.

Why not look for a heuristic that gets the common cases right, rather
than going with an elegant wrong solution? After all, these
enumerations are most often used by people who neither care nor know
how they're implemented, but who most likely would prefer if haskell
worked as well as matlab, python, etc.

One reasonable option would be to actually take into account the
expected roundoff error (which isn't hard to compute for simple sums
like this).

It would also be a good idea to reduce that roundoff error by using
multiplication rather than addition to create the enumeration (which
also allows us to ensure that finite enumerations terminate).
e.g. it's a shame that length [1 .. 1e8 :: Float] fails to terminate.
Admittedly, this is a stupid thing to compute, but it's also stupid to
add many small numbers together in sequence, since it always serves to
increase the roundoff error.  It's true that most people's C code
would be just as naive, but we're writing Haskell, and you're talking
about the Prelude, which should be written intelligently, not using
the simplest code, in such a way that it won't bite programmers.

David
From lennart at augustsson.net  Wed Oct 15 10:55:09 2008
From: lennart at augustsson.net (Lennart Augustsson)
Date: Wed Oct 15 10:51:07 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <20081015144403.GH5323@darcs.net>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
	<20081015144403.GH5323@darcs.net>
Message-ID: <f4876cd70810150755v38b7e96ckb7703c0ac7d2baaa@mail.gmail.com>

I'm sorry, but people who write [0.0,0.1 .. x] where x is a multiple
of 0.1 get exactly what they deserve if x is not included.  Floating
point numbers are not the real numbers, and the sooner they learn that
the better.  We can fudge this all we like, but 0.1 is never going to
be exactly representable as a binary floating point number no matter
what we do.

On Wed, Oct 15, 2008 at 3:44 PM, David Roundy <droundy@darcs.net> wrote:
> On Wed, Oct 15, 2008 at 10:41:25AM +0100, Malcolm Wallace wrote:
>> Dear Haskell-Primers (and libraries).
>>
>> Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98
>> Prelude, regarding numeric enumerations for Floats/Doubles:
>>
>>     Prelude> [0, 0.3 .. 1.1]
>>     [0.0,0.3,0.6,0.899999,1.2]
>>
>> What is odd is that the last value of the list is much larger than the
>> specified termination value.  But this is exactly as specified by the
>> Haskell'98 Report.
>>
>>     http://haskell.org/onlinereport/basic.html#sect6.3.4
>>
>>     "For Float and Double, the semantics of the enumFrom family is given
>>     by the rules for Int above, except that the list terminates when the
>>     elements become greater than e3+i/2 for positive increment i, or
>>     when they become less than e3+i/2 for negative i.
>>
>> We have discussed this question (and related ones, such as whether Float
>> and Double belong in the Enum class at all) several times before, and I
>> do not wish to rehash all of those points again e.g.:
>>
>>     http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg07289.html
>>     http://www.haskell.org/pipermail/haskell/2001-October/008218.html
>>     http://www.haskell.org/pipermail/haskell/2002-October/010607.html
>>
>> Phil proposes that, although retaining the instances of Enum for Float
>> and Double, we simplify the definitions of the numericEnumFrom family:
>>
>>   numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a -> a -> [a]
>>   numericEnumFrom         =  iterate (+1)
>>   numericEnumFromThen n m =  iterate (+(m-n)) n
>>   numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
>>   numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen n m)
>>
>> The particular feature of note is that the odd fudge factor of (1/2 *
>> the increment) is removed.  The inexact nature of floating point numbers
>> would therefore cause a specification like
>>
>>     [ 0.0, 0.1 .. 0.3 ]
>>
>> to yield the sequence
>>
>>     [ 0.0, 0.1, 0.2 ]
>>
>> that is, to omit the upper bound, because (3 * 0.1) is actually
>> represented as 0.30000000000004, strictly greater than 0.3.
>>
>> Phil argues that this behaviour is more desirable: "the simple fix is
>> that the user must add a suitable epsilon to the upper bound.  The key
>> word here is *suitable*.  The old definitions included completely
>> bizarre and often highly unsuitable choices of epsilon."
>>
>> This proposal seems to me to improve the consistency of the enumeration
>> syntax across both the integral and floating types.  Some users may
>> still be surprised, but the surprise will be easier to explain.
>>
>> I am bringing this question to the attention of all who are interested
>> in Haskell Prime, because it seems like a sensible and well-reasoned
>> change.  Discussion on whether to adopt this proposal for H' is welcome.
>>
>> But as maintainer and bug-fixer of the Haskell'98 Report, I have also
>> been asked whether we should make this change retrospectively to the
>> Haskell'98 language (as a "typo").  Since it involves not merely an
>> ordinary library function, but a Prelude function, and moreover a
>> function that is used in the desugaring of syntax, it is less clear to
>> me whether to alter Haskell'98.
>>
>> Thoughts?
>
> It sounds like a bad fix to me.  It seems important that the
> [0.0,0.1.. x] notation should work correctly in the common cases.  And
> the common case really is that the final value is intended as an exact
> multiple of the increment.
>
> Why not look for a heuristic that gets the common cases right, rather
> than going with an elegant wrong solution? After all, these
> enumerations are most often used by people who neither care nor know
> how they're implemented, but who most likely would prefer if haskell
> worked as well as matlab, python, etc.
>
> One reasonable option would be to actually take into account the
> expected roundoff error (which isn't hard to compute for simple sums
> like this).
>
> It would also be a good idea to reduce that roundoff error by using
> multiplication rather than addition to create the enumeration (which
> also allows us to ensure that finite enumerations terminate).
> e.g. it's a shame that length [1 .. 1e8 :: Float] fails to terminate.
> Admittedly, this is a stupid thing to compute, but it's also stupid to
> add many small numbers together in sequence, since it always serves to
> increase the roundoff error.  It's true that most people's C code
> would be just as naive, but we're writing Haskell, and you're talking
> about the Prelude, which should be written intelligently, not using
> the simplest code, in such a way that it won't bite programmers.
>
> David
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From duncan.coutts at worc.ox.ac.uk  Wed Oct 15 13:58:06 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Oct 15 13:53:52 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76A7961E@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A7961E@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <1224093486.14942.423.camel@dell.linuxdev.us.dell.com>

On Wed, 2008-10-15 at 09:46 +0100, Simon Peyton-Jones wrote:
> Right.  I've finally fixed 2497; it was a typo, and while I thought
> I'd tested it, the test didn't tet that RULES compile without any
> flags.

That's great, thanks.

> The story is that you should not need any funny RankN flags just to
> make RULES parse and typecheck. -XScopedTypeVariables gets set
> automatically inside a RULES pragma.  This is what the discussion on
> #2497 claimed, but there was a bug in the impl.

And for people trying to make their code compatible with older ghc too,
they can use this in their .cabal files:

extensions: ScopedTypeVariables

Which makes Cabal pass -XScopedTypeVariables for ghc-6.8 and for 6.6 and
earlier is passes -fglasgow-exts. This is what the bytestring package is
currently using (and no more ghc-options: -fglasgow-exts).

Duncan

From duncan.coutts at worc.ox.ac.uk  Wed Oct 15 14:17:42 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Oct 15 14:13:29 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C902CD3B48@ELON17P32001A.csfb.cs-group.com>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
	<33A3F585590A6F4E81E3D45AA4A111C902CD3B48@ELON17P32001A.csfb.cs-group.com>
Message-ID: <1224094662.14942.442.camel@dell.linuxdev.us.dell.com>

On Wed, 2008-10-15 at 11:25 +0100, Mitchell, Neil wrote:
> Hi Malcolm,
> 
> The current behaviour does sound like a bug, and the revised behaviour
> does sound like a fix - and one that has a sensible explanation if
> people trip over it. In general having floating point be a member of
> classes such as Eq has some obvious problems, but I realise is a
> necessity for practical programming. Given that we have Eq Double, then
> Enum Double seems no worse.
> 
> If we don't alter H98 then a valid program under H98 vs H' will give
> different results without any warning - that seems really bad. In
> addition, having two instances around for one typeclass/type pair in a
> big library (base) which are switched with some flag seems like a
> nightmare for compiler writers. So I think a good solution would be to
> fix H98 as a typo, and include it in H'.

I would take the contrary position and say H98 should be left alone and
the change should be proposed for H'.

The argument is that H98 is done and the revised report was published 7
years ago. Changing H98 now just doesn't seem to make much sense.

If we're talking about changing the meaning of 'valid' programs then
doing that at a boundary like H98 -> H' seems much more sensible than
having to explain the difference in H98-pre2008 programs vs
H98-post2008.

People will not expect all programs to be exactly the same between H98
and H' (otherwise there would be little need for a new standard). Yes H'
is mostly compatible extensions but not all of it.

Duncan

From lemming at henning-thielemann.de  Wed Oct 15 14:47:21 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed Oct 15 14:43:19 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>


On Mon, 13 Oct 2008, Simon Peyton-Jones wrote:

> | I wondered whether it is possible to let the compiler read and store the
> | RULES pragmas without optimizing the code in the same module with respect
> | to these RULES. When I want to compile the code without optimization - for
> | whatever reason - I would still like to have the RULES checked. They could
> | still be applied when imported to another module that is compiled with
> | optimization.
>
> Indeed you can: use -fno-omit-interface-pragmas. This overrides the 
> default, which is that with -O no non-essential info is put in the 
> interface file.
>
> If you think it's worth improving the documentation (e.g. you didn't 
> know about this), then I'd welcome a concrete suggestion.  (eg Say 
> "...this..." in the second bullet off ...".)

  I found it just confusing to switch on two features (namely 'optimization 
including application of rules' and 'parsing, checking and storing new 
rules') with one option (namely -O). It remains confusing for me also if 
one of the two features can be enabled separately with 
-fno-omit-interface-pragmas, but the other feature cannot. Also the option 
sounds like it also applies not only to RULES. I also find the doubled 
negation in 'no omit' confusing. What about 
'-finclude-all-interface-pragmas'?
  What concerns documentation: The description of an option for enabling 
parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.
From isaacdupree at charter.net  Wed Oct 15 16:06:27 2008
From: isaacdupree at charter.net (Isaac Dupree)
Date: Wed Oct 15 16:02:34 2008
Subject: Proposal #2659: Add sortOn and friends to Data.List
In-Reply-To: <gcfb1n$ooc$1@ger.gmane.org>
References: <48E8DFBC.30408@gmail.com> <gcfb1n$ooc$1@ger.gmane.org>
Message-ID: <48F64D43.4020106@charter.net>

apfelmus wrote:
> but I don't like the name. In particular I don't like the "get" prefix
> in "getDown". I'd simply use
> 
>   newtype Desc a = Desc a

what's up with "Down", "Descending" etc.?  "Ord" is a 
symmetric, mathematical concept, no more "ascending" than 
"descending"!  It's just a convention (created/used by 
functions like "sort") to sort ascending, and it annoys me a 
little that they're not called "sortAsc" (sortAscending) to 
say what they do.  I'd suggest something like "ReverseOrd" 
or "ReverseOrder", (or "Opposite..."?) (or some abbreviated 
version?)

-Isaac
From droundy at darcs.net  Wed Oct 15 16:54:25 2008
From: droundy at darcs.net (David Roundy)
Date: Wed Oct 15 16:50:17 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <f4876cd70810150755v38b7e96ckb7703c0ac7d2baaa@mail.gmail.com>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
	<20081015144403.GH5323@darcs.net>
	<f4876cd70810150755v38b7e96ckb7703c0ac7d2baaa@mail.gmail.com>
Message-ID: <20081015205425.GN5323@darcs.net>

Here's a counter-proposal:

numericEnumFromThenTo   :: RealFloat a => a -> a -> a -> [a]
numericEnumFrom 0 = map fromInteger [1..]
numericEnumFrom n = map ((n+).fromInteger) [1..]
numericEnumFromThen n m =  map (\x -> n+fromInteger x*(m-n)) [1..]
numericEnumFromTo n m = takeWhile (<= m*(1 + epsilon)) (numericEnumFrom n)
numericEnumFromThenTo n m p = takeWhile (<= p*(1 + 2*epsilon)) (numericEnumFromThen n m)

epsilon :: RealFloat a => a
epsilon = 1/2^(floatDigits (undefined :: a))

This uses quite a reasonable approximation for the roundoff error, and
has the advantage of not inappropriately returning _|_.  It does
sometimes create duplicate entries in the list, but I think that is
better that returning an infinite list of duplicate entries as the
code proposed below does.

And yes, the fuzzy comparison is a bit ugly, but at least it means
that every user is not forced to implement fuzzy comparison in their
quick and dirty code (which is the only thing this syntax is good
for).

David

On Wed, Oct 15, 2008 at 03:55:09PM +0100, Lennart Augustsson wrote:
> I'm sorry, but people who write [0.0,0.1 .. x] where x is a multiple
> of 0.1 get exactly what they deserve if x is not included.  Floating
> point numbers are not the real numbers, and the sooner they learn that
> the better.  We can fudge this all we like, but 0.1 is never going to
> be exactly representable as a binary floating point number no matter
> what we do.
> 
> On Wed, Oct 15, 2008 at 3:44 PM, David Roundy <droundy@darcs.net> wrote:
> > On Wed, Oct 15, 2008 at 10:41:25AM +0100, Malcolm Wallace wrote:
> >> Dear Haskell-Primers (and libraries).
> >>
> >> Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98
> >> Prelude, regarding numeric enumerations for Floats/Doubles:
> >>
> >>     Prelude> [0, 0.3 .. 1.1]
> >>     [0.0,0.3,0.6,0.899999,1.2]
> >>
> >> What is odd is that the last value of the list is much larger than the
> >> specified termination value.  But this is exactly as specified by the
> >> Haskell'98 Report.
> >>
> >>     http://haskell.org/onlinereport/basic.html#sect6.3.4
> >>
> >>     "For Float and Double, the semantics of the enumFrom family is given
> >>     by the rules for Int above, except that the list terminates when the
> >>     elements become greater than e3+i/2 for positive increment i, or
> >>     when they become less than e3+i/2 for negative i.
> >>
> >> We have discussed this question (and related ones, such as whether Float
> >> and Double belong in the Enum class at all) several times before, and I
> >> do not wish to rehash all of those points again e.g.:
> >>
> >>     http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg07289.html
> >>     http://www.haskell.org/pipermail/haskell/2001-October/008218.html
> >>     http://www.haskell.org/pipermail/haskell/2002-October/010607.html
> >>
> >> Phil proposes that, although retaining the instances of Enum for Float
> >> and Double, we simplify the definitions of the numericEnumFrom family:
> >>
> >>   numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a -> a -> [a]
> >>   numericEnumFrom         =  iterate (+1)
> >>   numericEnumFromThen n m =  iterate (+(m-n)) n
> >>   numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
> >>   numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen n m)
> >>
> >> The particular feature of note is that the odd fudge factor of (1/2 *
> >> the increment) is removed.  The inexact nature of floating point numbers
> >> would therefore cause a specification like
> >>
> >>     [ 0.0, 0.1 .. 0.3 ]
> >>
> >> to yield the sequence
> >>
> >>     [ 0.0, 0.1, 0.2 ]
> >>
> >> that is, to omit the upper bound, because (3 * 0.1) is actually
> >> represented as 0.30000000000004, strictly greater than 0.3.
> >>
> >> Phil argues that this behaviour is more desirable: "the simple fix is
> >> that the user must add a suitable epsilon to the upper bound.  The key
> >> word here is *suitable*.  The old definitions included completely
> >> bizarre and often highly unsuitable choices of epsilon."
> >>
> >> This proposal seems to me to improve the consistency of the enumeration
> >> syntax across both the integral and floating types.  Some users may
> >> still be surprised, but the surprise will be easier to explain.
> >>
> >> I am bringing this question to the attention of all who are interested
> >> in Haskell Prime, because it seems like a sensible and well-reasoned
> >> change.  Discussion on whether to adopt this proposal for H' is welcome.
> >>
> >> But as maintainer and bug-fixer of the Haskell'98 Report, I have also
> >> been asked whether we should make this change retrospectively to the
> >> Haskell'98 language (as a "typo").  Since it involves not merely an
> >> ordinary library function, but a Prelude function, and moreover a
> >> function that is used in the desugaring of syntax, it is less clear to
> >> me whether to alter Haskell'98.
> >>
> >> Thoughts?
> >
> > It sounds like a bad fix to me.  It seems important that the
> > [0.0,0.1.. x] notation should work correctly in the common cases.  And
> > the common case really is that the final value is intended as an exact
> > multiple of the increment.
> >
> > Why not look for a heuristic that gets the common cases right, rather
> > than going with an elegant wrong solution? After all, these
> > enumerations are most often used by people who neither care nor know
> > how they're implemented, but who most likely would prefer if haskell
> > worked as well as matlab, python, etc.
> >
> > One reasonable option would be to actually take into account the
> > expected roundoff error (which isn't hard to compute for simple sums
> > like this).
> >
> > It would also be a good idea to reduce that roundoff error by using
> > multiplication rather than addition to create the enumeration (which
> > also allows us to ensure that finite enumerations terminate).
> > e.g. it's a shame that length [1 .. 1e8 :: Float] fails to terminate.
> > Admittedly, this is a stupid thing to compute, but it's also stupid to
> > add many small numbers together in sequence, since it always serves to
> > increase the roundoff error.  It's true that most people's C code
> > would be just as naive, but we're writing Haskell, and you're talking
> > about the Prelude, which should be written intelligently, not using
> > the simplest code, in such a way that it won't bite programmers.
> >
> > David
> > _______________________________________________
> > Libraries mailing list
> > Libraries@haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
From lane at downstairspeople.org  Wed Oct 15 17:23:43 2008
From: lane at downstairspeople.org (Christopher Lane Hinson)
Date: Wed Oct 15 17:19:40 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <20081015205425.GN5323@darcs.net>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
	<20081015144403.GH5323@darcs.net>
	<f4876cd70810150755v38b7e96ckb7703c0ac7d2baaa@mail.gmail.com>
	<20081015205425.GN5323@darcs.net>
Message-ID: <alpine.DEB.1.10.0810151658230.31970@greatmoo.downstairspeople.org>


I agree with David, we should be using multiplication, not addition.
However, I think that under the law of least surprise, we should
require that for all a,b,z:

all (\x -> x >= a && x < z || x <= a && x > z) [a,b..z].

For example, anything in the neighborhood of this is just unfair, even 
if it's within David's fudge factor:

Prelude> map (\x -> 1 / (x-0.6)) [0,0.1..0.55]
[-1.6666666666666667,-2.0,-2.5,-3.333333333333334,-5.000000000000001,-10.000000000000002,Infinity]

If I want to include the terminating value, then what I really want is 
probably some f such that:

f (6 :: Int) 0 0.55 = [0,0.11,0.22,0.33,0.44,0.55]

--Lane



On Wed, 15 Oct 2008, David Roundy wrote:

> Here's a counter-proposal:
>
> numericEnumFromThenTo   :: RealFloat a => a -> a -> a -> [a]
> numericEnumFrom 0 = map fromInteger [1..]
> numericEnumFrom n = map ((n+).fromInteger) [1..]
> numericEnumFromThen n m =  map (\x -> n+fromInteger x*(m-n)) [1..]
> numericEnumFromTo n m = takeWhile (<= m*(1 + epsilon)) (numericEnumFrom n)
> numericEnumFromThenTo n m p = takeWhile (<= p*(1 + 2*epsilon)) (numericEnumFromThen n m)
>
> epsilon :: RealFloat a => a
> epsilon = 1/2^(floatDigits (undefined :: a))
>
> This uses quite a reasonable approximation for the roundoff error, and
> has the advantage of not inappropriately returning _|_.  It does
> sometimes create duplicate entries in the list, but I think that is
> better that returning an infinite list of duplicate entries as the
> code proposed below does.
>
> And yes, the fuzzy comparison is a bit ugly, but at least it means
> that every user is not forced to implement fuzzy comparison in their
> quick and dirty code (which is the only thing this syntax is good
> for).
>
> David
>
> On Wed, Oct 15, 2008 at 03:55:09PM +0100, Lennart Augustsson wrote:
>> I'm sorry, but people who write [0.0,0.1 .. x] where x is a multiple
>> of 0.1 get exactly what they deserve if x is not included.  Floating
>> point numbers are not the real numbers, and the sooner they learn that
>> the better.  We can fudge this all we like, but 0.1 is never going to
>> be exactly representable as a binary floating point number no matter
>> what we do.
>>
>> On Wed, Oct 15, 2008 at 3:44 PM, David Roundy <droundy@darcs.net> wrote:
>>> On Wed, Oct 15, 2008 at 10:41:25AM +0100, Malcolm Wallace wrote:
>>>> Dear Haskell-Primers (and libraries).
>>>>
>>>> Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98
>>>> Prelude, regarding numeric enumerations for Floats/Doubles:
>>>>
>>>>     Prelude> [0, 0.3 .. 1.1]
>>>>     [0.0,0.3,0.6,0.899999,1.2]
>>>>
>>>> What is odd is that the last value of the list is much larger than the
>>>> specified termination value.  But this is exactly as specified by the
>>>> Haskell'98 Report.
>>>>
>>>>     http://haskell.org/onlinereport/basic.html#sect6.3.4
>>>>
>>>>     "For Float and Double, the semantics of the enumFrom family is given
>>>>     by the rules for Int above, except that the list terminates when the
>>>>     elements become greater than e3+i/2 for positive increment i, or
>>>>     when they become less than e3+i/2 for negative i.
>>>>
>>>> We have discussed this question (and related ones, such as whether Float
>>>> and Double belong in the Enum class at all) several times before, and I
>>>> do not wish to rehash all of those points again e.g.:
>>>>
>>>>     http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg07289.html
>>>>     http://www.haskell.org/pipermail/haskell/2001-October/008218.html
>>>>     http://www.haskell.org/pipermail/haskell/2002-October/010607.html
>>>>
>>>> Phil proposes that, although retaining the instances of Enum for Float
>>>> and Double, we simplify the definitions of the numericEnumFrom family:
>>>>
>>>>   numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a -> a -> [a]
>>>>   numericEnumFrom         =  iterate (+1)
>>>>   numericEnumFromThen n m =  iterate (+(m-n)) n
>>>>   numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
>>>>   numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen n m)
>>>>
>>>> The particular feature of note is that the odd fudge factor of (1/2 *
>>>> the increment) is removed.  The inexact nature of floating point numbers
>>>> would therefore cause a specification like
>>>>
>>>>     [ 0.0, 0.1 .. 0.3 ]
>>>>
>>>> to yield the sequence
>>>>
>>>>     [ 0.0, 0.1, 0.2 ]
>>>>
>>>> that is, to omit the upper bound, because (3 * 0.1) is actually
>>>> represented as 0.30000000000004, strictly greater than 0.3.
>>>>
>>>> Phil argues that this behaviour is more desirable: "the simple fix is
>>>> that the user must add a suitable epsilon to the upper bound.  The key
>>>> word here is *suitable*.  The old definitions included completely
>>>> bizarre and often highly unsuitable choices of epsilon."
>>>>
>>>> This proposal seems to me to improve the consistency of the enumeration
>>>> syntax across both the integral and floating types.  Some users may
>>>> still be surprised, but the surprise will be easier to explain.
>>>>
>>>> I am bringing this question to the attention of all who are interested
>>>> in Haskell Prime, because it seems like a sensible and well-reasoned
>>>> change.  Discussion on whether to adopt this proposal for H' is welcome.
>>>>
>>>> But as maintainer and bug-fixer of the Haskell'98 Report, I have also
>>>> been asked whether we should make this change retrospectively to the
>>>> Haskell'98 language (as a "typo").  Since it involves not merely an
>>>> ordinary library function, but a Prelude function, and moreover a
>>>> function that is used in the desugaring of syntax, it is less clear to
>>>> me whether to alter Haskell'98.
>>>>
>>>> Thoughts?
>>>
>>> It sounds like a bad fix to me.  It seems important that the
>>> [0.0,0.1.. x] notation should work correctly in the common cases.  And
>>> the common case really is that the final value is intended as an exact
>>> multiple of the increment.
>>>
>>> Why not look for a heuristic that gets the common cases right, rather
>>> than going with an elegant wrong solution? After all, these
>>> enumerations are most often used by people who neither care nor know
>>> how they're implemented, but who most likely would prefer if haskell
>>> worked as well as matlab, python, etc.
>>>
>>> One reasonable option would be to actually take into account the
>>> expected roundoff error (which isn't hard to compute for simple sums
>>> like this).
>>>
>>> It would also be a good idea to reduce that roundoff error by using
>>> multiplication rather than addition to create the enumeration (which
>>> also allows us to ensure that finite enumerations terminate).
>>> e.g. it's a shame that length [1 .. 1e8 :: Float] fails to terminate.
>>> Admittedly, this is a stupid thing to compute, but it's also stupid to
>>> add many small numbers together in sequence, since it always serves to
>>> increase the roundoff error.  It's true that most people's C code
>>> would be just as naive, but we're writing Haskell, and you're talking
>>> about the Prelude, which should be written intelligently, not using
>>> the simplest code, in such a way that it won't bite programmers.
>>>
>>> David
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries@haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
From duncan.coutts at worc.ox.ac.uk  Thu Oct 16 00:56:43 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Oct 16 00:52:27 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
	<Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>
Message-ID: <1224133003.14942.459.camel@dell.linuxdev.us.dell.com>

On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:

>   I found it just confusing to switch on two features (namely 'optimization 
> including application of rules' and 'parsing, checking and storing new 
> rules') with one option (namely -O). It remains confusing for me also if 
> one of the two features can be enabled separately with 
> -fno-omit-interface-pragmas, but the other feature cannot. Also the option 
> sounds like it also applies not only to RULES. I also find the doubled 
> negation in 'no omit' confusing. What about 
> '-finclude-all-interface-pragmas'?
>   What concerns documentation: The description of an option for enabling 
> parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.

While it used to be more complex, the situation now is quite simple:

RULES are always parsed (no flags or language extensions needed). They
also go into the .hi files (unless you use the obscure option to change
that), so they are exported for all client modules.

RULES get used/applied with -O. Again, there is an option to turn off
the use of rules (without affecting other optimisations).

This seems pretty sane and easy to explain.

Duncan

From simonpj at microsoft.com  Thu Oct 16 06:12:43 2008
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Thu Oct 16 06:08:39 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <1224133003.14942.459.camel@dell.linuxdev.us.dell.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
	<Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>
	<1224133003.14942.459.camel@dell.linuxdev.us.dell.com>
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA340@EA-EXMSG-C334.europe.corp.microsoft.com>

| RULES are always parsed (no flags or language extensions needed). They
| also go into the .hi files (unless you use the obscure option to change
| that), so they are exported for all client modules.

The latter isn't true, and I think that's what Henning is objecting to.

Currently, without -O GHC puts the absolute minimum in interface files to get the clients to compile: just the exports and their types.  For example, if you have
        f x = x
GHC will not put that unfolding in the interface file, tiny though it is.

Currently without -O GHC therefore does *not* put RULES in the interface file.  I thought that was consistent, since they are to do with optimisation.


If, however, there's a consensus that RULES should be persisted even without -O, that'd be easy to arrange. For example, I think that deprecations are persisted unconditionally.

Simon

| -----Original Message-----
| From: Duncan Coutts [mailto:duncan.coutts@worc.ox.ac.uk]
| Sent: 16 October 2008 05:57
| To: Henning Thielemann
| Cc: Simon Peyton-Jones; libraries@haskell.org
| Subject: RE: 2008-10-11 Hackage status with GHC 6.10
|
| On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:
|
| >   I found it just confusing to switch on two features (namely 'optimization
| > including application of rules' and 'parsing, checking and storing new
| > rules') with one option (namely -O). It remains confusing for me also if
| > one of the two features can be enabled separately with
| > -fno-omit-interface-pragmas, but the other feature cannot. Also the option
| > sounds like it also applies not only to RULES. I also find the doubled
| > negation in 'no omit' confusing. What about
| > '-finclude-all-interface-pragmas'?
| >   What concerns documentation: The description of an option for enabling
| > parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.
|
| While it used to be more complex, the situation now is quite simple:
|
| RULES are always parsed (no flags or language extensions needed). They
| also go into the .hi files (unless you use the obscure option to change
| that), so they are exported for all client modules.
|
| RULES get used/applied with -O. Again, there is an option to turn off
| the use of rules (without affecting other optimisations).
|
| This seems pretty sane and easy to explain.
|
| Duncan
|

From lemming at henning-thielemann.de  Thu Oct 16 10:58:53 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu Oct 16 10:54:49 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <1224133003.14942.459.camel@dell.linuxdev.us.dell.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
	<Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>
	<1224133003.14942.459.camel@dell.linuxdev.us.dell.com>
Message-ID: <Pine.SOC.4.64.0810161656370.19009@haydn.informatik.uni-halle.de>


On Wed, 15 Oct 2008, Duncan Coutts wrote:

> On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:
>
>>   I found it just confusing to switch on two features (namely 'optimization
>> including application of rules' and 'parsing, checking and storing new
>> rules') with one option (namely -O). It remains confusing for me also if
>> one of the two features can be enabled separately with
>> -fno-omit-interface-pragmas, but the other feature cannot. Also the option
>> sounds like it also applies not only to RULES. I also find the doubled
>> negation in 'no omit' confusing. What about
>> '-finclude-all-interface-pragmas'?
>>   What concerns documentation: The description of an option for enabling
>> parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.
>
> While it used to be more complex, the situation now is quite simple:
>
> RULES are always parsed (no flags or language extensions needed). They
> also go into the .hi files (unless you use the obscure option to change
> that), so they are exported for all client modules.

So they are handled like all pragmas. That sounds fine to me.

> RULES get used/applied with -O. Again, there is an option to turn off
> the use of rules (without affecting other optimisations).
>
> This seems pretty sane and easy to explain.

yes, indeed
From dons at galois.com  Thu Oct 16 14:40:13 2008
From: dons at galois.com (Don Stewart)
Date: Thu Oct 16 14:35:56 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA340@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
	<Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>
	<1224133003.14942.459.camel@dell.linuxdev.us.dell.com>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76AFA340@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <20081016184013.GG4205@scytale.galois.com>

simonpj:
> | RULES are always parsed (no flags or language extensions needed). They
> | also go into the .hi files (unless you use the obscure option to change
> | that), so they are exported for all client modules.
> 
> The latter isn't true, and I think that's what Henning is objecting to.
> 
> Currently, without -O GHC puts the absolute minimum in interface files
> to get the clients to compile: just the exports and their types.  For
> example, if you have
>         f x = x
> GHC will not put that unfolding in the interface file, tiny though it
> is.
> 
> Currently without -O GHC therefore does *not* put RULES in the
> interface file.  I thought that was consistent, since they are to do
> with optimisation.
> 
> If, however, there's a consensus that RULES should be persisted even
> without -O, that'd be easy to arrange. For example, I think that
> deprecations are persisted unconditionally.

So the next build with GHC 6.10 branch we should no longer see
'forall' parse failures from hackage libraries that use RULES?

-- Don
From duncan.coutts at worc.ox.ac.uk  Thu Oct 16 14:47:57 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Oct 16 14:43:36 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA340@EA-EXMSG-C334.europe.corp.microsoft.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
	<Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>
	<1224133003.14942.459.camel@dell.linuxdev.us.dell.com>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76AFA340@EA-EXMSG-C334.europe.corp.microsoft.com>
Message-ID: <1224182877.14942.498.camel@dell.linuxdev.us.dell.com>

On Thu, 2008-10-16 at 11:12 +0100, Simon Peyton-Jones wrote:
> | RULES are always parsed (no flags or language extensions needed). They
> | also go into the .hi files (unless you use the obscure option to change
> | that), so they are exported for all client modules.
> 
> The latter isn't true, and I think that's what Henning is objecting
> to.

Oops.

As I read it Henning wants the RULES parsed with or without -O. That bit
is now much simpler than it used to be.

I didn't read his objection as wanting them always exported even if the
defining module was not built without -O, just that they should always
be parsed and checked.

> Currently, without -O GHC puts the absolute minimum in interface files
> to get the clients to compile

Right. My mistake.

> Currently without -O GHC therefore does *not* put RULES in the
> interface file.  I thought that was consistent, since they are to do
> with optimisation.

Right. 

> If, however, there's a consensus that RULES should be persisted even
> without -O, that'd be easy to arrange. For example, I think that
> deprecations are persisted unconditionally.

I think the current behaviour is consistent and makes sense.

We do want the minimum without -O because it gives more minimal rebuilds
if the .hi files do not change so often.

I've updated the wiki page on 6.10 upgrading:
http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_RULES_parsing

Duncan

From isaacdupree at charter.net  Thu Oct 16 17:31:50 2008
From: isaacdupree at charter.net (Isaac Dupree)
Date: Thu Oct 16 17:27:54 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <alpine.DEB.1.10.0810151658230.31970@greatmoo.downstairspeople.org>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>	<20081015144403.GH5323@darcs.net>	<f4876cd70810150755v38b7e96ckb7703c0ac7d2baaa@mail.gmail.com>	<20081015205425.GN5323@darcs.net>
	<alpine.DEB.1.10.0810151658230.31970@greatmoo.downstairspeople.org>
Message-ID: <48F7B2C6.2040702@charter.net>

Christopher Lane Hinson wrote:
> 
> I agree with David, we should be using multiplication, not addition.
> However, I think that under the law of least surprise, we should
> require that for all a,b,z:
> 
> all (\x -> x >= a && x < z || x <= a && x > z) [a,b..z].

so that [0,0.1..0.3] doesn't include the terminating value 
that's a little more than the literal 0.3?

> For example, anything in the neighborhood of this is just unfair, even 
> if it's within David's fudge factor:
> 
> Prelude> map (\x -> 1 / (x-0.6)) [0,0.1..0.55]
> [-1.6666666666666667,-2.0,-2.5,-3.333333333333334,-5.000000000000001,-10.000000000000002,Infinity] 

but that's a significant fudge, 0.5 versus 0.55 versus 0.6 
-- right?

-Isaac
From droundy at darcs.net  Thu Oct 16 17:37:07 2008
From: droundy at darcs.net (David Roundy)
Date: Thu Oct 16 17:32:53 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <48F7B2C6.2040702@charter.net>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
	<20081015144403.GH5323@darcs.net>
	<f4876cd70810150755v38b7e96ckb7703c0ac7d2baaa@mail.gmail.com>
	<20081015205425.GN5323@darcs.net>
	<alpine.DEB.1.10.0810151658230.31970@greatmoo.downstairspeople.org>
	<48F7B2C6.2040702@charter.net>
Message-ID: <20081016213707.GC5323@darcs.net>

On Thu, Oct 16, 2008 at 05:31:50PM -0400, Isaac Dupree wrote:
> Christopher Lane Hinson wrote:
>>
>> I agree with David, we should be using multiplication, not addition.
>> However, I think that under the law of least surprise, we should
>> require that for all a,b,z:
>>
>> all (\x -> x >= a && x < z || x <= a && x > z) [a,b..z].
>
> so that [0,0.1..0.3] doesn't include the terminating value that's a
> little more than the literal 0.3?

We could do what octave appears to do, which is to set anything within
the fudge factor (but greater than the upper bound) equal to the upper
bound.  That seems like a reasonable option to me.

David
From simonpj at microsoft.com  Fri Oct 17 03:29:44 2008
From: simonpj at microsoft.com (Simon Peyton-Jones)
Date: Fri Oct 17 03:25:38 2008
Subject: 2008-10-11 Hackage status with GHC 6.10
In-Reply-To: <20081016184013.GG4205@scytale.galois.com>
References: <20081012011351.GL11641@scytale.galois.com>
	<Pine.SOC.4.64.0810121537300.23145@haydn.informatik.uni-halle.de>
	<20081012135637.GA21073@matrix.chaos.earth.li>
	<1223830358.14942.7.camel@dell.linuxdev.us.dell.com>
	<Pine.SOC.4.64.0810122033250.26699@haydn.informatik.uni-halle.de>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76A78BB7@EA-EXMSG-C334.europe.corp.microsoft.com>
	<Pine.SOC.4.64.0810142137100.11675@haydn.informatik.uni-halle.de>
	<1224133003.14942.459.camel@dell.linuxdev.us.dell.com>
	<638ABD0A29C8884A91BC5FB5C349B1C32D76AFA340@EA-EXMSG-C334.europe.corp.microsoft.com>
	<20081016184013.GG4205@scytale.galois.com>
Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D76AFA7A6@EA-EXMSG-C334.europe.corp.microsoft.com>

| So the next build with GHC 6.10 branch we should no longer see
| 'forall' parse failures from hackage libraries that use RULES?

Yes -- but not for the reasons below.  It should work now because I fixed http://hackage.haskell.org/trac/ghc/ticket/2497

Simon

| -----Original Message-----
| From: Don Stewart [mailto:dons@galois.com]
| Sent: 16 October 2008 19:40
| To: Simon Peyton-Jones
| Cc: Duncan Coutts; Henning Thielemann; libraries@haskell.org
| Subject: Re: 2008-10-11 Hackage status with GHC 6.10
|
| simonpj:
| > | RULES are always parsed (no flags or language extensions needed). They
| > | also go into the .hi files (unless you use the obscure option to change
| > | that), so they are exported for all client modules.
| >
| > The latter isn't true, and I think that's what Henning is objecting to.
| >
| > Currently, without -O GHC puts the absolute minimum in interface files
| > to get the clients to compile: just the exports and their types.  For
| > example, if you have
| >         f x = x
| > GHC will not put that unfolding in the interface file, tiny though it
| > is.
| >
| > Currently without -O GHC therefore does *not* put RULES in the
| > interface file.  I thought that was consistent, since they are to do
| > with optimisation.
| >
| > If, however, there's a consensus that RULES should be persisted even
| > without -O, that'd be easy to arrange. For example, I think that
| > deprecations are persisted unconditionally.
|
| So the next build with GHC 6.10 branch we should no longer see
| 'forall' parse failures from hackage libraries that use RULES?
|
| -- Don

From jon.fairbairn at cl.cam.ac.uk  Fri Oct 17 06:49:52 2008
From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn)
Date: Fri Oct 17 06:46:08 2008
Subject: Repair to floating point enumerations?
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
	<20081015144403.GH5323@darcs.net>
	<f4876cd70810150755v38b7e96ckb7703c0ac7d2baaa@mail.gmail.com>
	<20081015205425.GN5323@darcs.net>
	<alpine.DEB.1.10.0810151658230.31970@greatmoo.downstairspeople.org>
	<48F7B2C6.2040702@charter.net> <20081016213707.GC5323@darcs.net>
Message-ID: <wfod1jsdgv.fsf@calligramme.charmers>

David Roundy <droundy@darcs.net> writes:

> On Thu, Oct 16, 2008 at 05:31:50PM -0400, Isaac Dupree wrote:
>> Christopher Lane Hinson wrote:
>>>
>>> I agree with David, we should be using multiplication, not addition.
>>> However, I think that under the law of least surprise, we should
>>> require that for all a,b,z:
>>>
>>> all (\x -> x >= a && x < z || x <= a && x > z) [a,b..z].
>>
>> so that [0,0.1..0.3] doesn't include the terminating value that's a
>> little more than the literal 0.3?
>
> We could do what octave appears to do, which is to set anything within
> the fudge factor (but greater than the upper bound) equal to the upper
> bound.  That seems like a reasonable option to me.

I've not been following this closely, but I've not seen a
clear definition of what this is all for.  Without that,
we're going to see a succession of fudges that will work for
some notions of what the notation means and fail for others.

Assuming z>=a, must the resulting list include a? include z
exactly when?  If a or z is a literal, does include here
mean "include the value represented by the literal" or some
other nearby value?  Must the step (l!!(i+1)-l!!i) always be
the same? Must it equal (b-a)? (I can even imagine that for
some applications, a list that looked like this: [0.0,
1.0e-2, 2.0e-2, 3.0e-2, 4.0e-2, 5.0e-2,
6.0000000000000005e-2, 7.0e-2, 8.0e-2, 9.0e-2,
9.999999999999999e-2, 0.10999999999999999, 0.11] would be
preferable to one that included only one of the last two
elements).

Whatever is decided for floats, the definition must be
consistent with that for discrete quantities. I'm not sure
this is possible. Since floating point numbers are full of
surprises for anyone who is used to real numbers (and even a
few for people who are quite familiar with floats), the
principle of least surprise would surely indicate no
instance of Enum for floats.

-- 
J?n Fairbairn                                 Jon.Fairbairn@cl.cam.ac.uk


From rl at cse.unsw.edu.au  Fri Oct 17 08:06:44 2008
From: rl at cse.unsw.edu.au (Roman Leshchinskiy)
Date: Fri Oct 17 08:02:55 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
Message-ID: <BA06BC01-C1C5-433E-B45E-C7A7B2C6BE68@cse.unsw.edu.au>

On 15/10/2008, at 20:41, Malcolm Wallace wrote:

> Phil proposes that, although retaining the instances of Enum for Float
> and Double, we simplify the definitions of the numericEnumFrom family:
>
>  numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a -> a ->  
> [a]
>  numericEnumFrom         =  iterate (+1)
>  numericEnumFromThen n m =  iterate (+(m-n)) n
>  numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
>  numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen  
> n m)


I'd like to raise the following two points in this context.

Firstly, an array library which attempts to provide reasonable  
counterparts to the list functions would want to define array versions  
of enumFromTo and enumFromThenTo. To be efficient, it must be able to  
determine the expected number of elements reasonably fast (in constant  
time).

Secondly, a parallel array library (such as the one provided by DPH)  
also needs to be able to generate, say, the first half of the array on  
one processor and the second half on another. This requires enumFromTo  
to obey some form of the following law for some f and g:

   enumFromTo m n = enumFromTo m (f m n) ++ enumFromTo (g m n) n

It might make sense to try to provide this for Float and Double for  
the sake of consistency with future libraries. I'm not sure how easy  
it is to do, though.

Roman


From conal at conal.net  Fri Oct 17 18:20:14 2008
From: conal at conal.net (Conal Elliott)
Date: Fri Oct 17 18:16:04 2008
Subject: OpenGL+GLUTwith ghc-6.10 ?
Message-ID: <ea8ae9fb0810171520s2174b05ft1f14ea67cf43863b@mail.gmail.com>

Has anyone gotten OpenGL+GLUT to work with ghc-6.10?  It crashes for me on
createWindow (from Graphics.UI.GLUT.Window).  I'm using the
ghc-6.10.0.20081007 from a win32 installer, along with OpenGL-2.2.1.1 and
GLUT-2.1.1.2 from Hackage.  Thanks,  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20081017/bbda71b6/attachment.htm
From haskell at list.mightyreason.com  Fri Oct 17 18:33:08 2008
From: haskell at list.mightyreason.com (Chris Kuklewicz)
Date: Fri Oct 17 18:29:09 2008
Subject: Compiling regex-posix-0.93.2 on windows
In-Reply-To: <DBF981D47267004EAB5288C984EA2AFBA58CE7@sron-chi-exc06.ronin.roncap.com>
References: <DBF981D47267004EAB5288C984EA2AFBA58CE7@sron-chi-exc06.ronin.roncap.com>
Message-ID: <48F912A4.9060306@list.mightyreason.com>

I am not sure what is going wrong.  I have not been using Haskell on windows.  I 
am also copying this reply to haskell-cafe and libaries mailing lists.  Does 
anyone know?

Parnell Flynn wrote:
> I am having a terrible time compiling the 0.93.2 version of the 
> regex-posix library on windows XP.
> 
> I have Cygwin and MinGW installed and I have a version of the regex.h 
> header in C:/cygwin/usr/include what shared libraries do I need?
> 
> Here is a copy of the error it finds the include but is unable to link.
> 
> This links to the standard c library version of regular expressions.
> 
> The corresponding c header file is regex.h and there is a chance you
> 
> will need to edit the end of the regex-posix.cabal file to find the
> 
> include directory and/or library.
> 
> Preprocessing library regex-posix-0.93.2...
> 
> dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x85):Wrap_hsc_make.c: 
> undefined reference to `_impure_ptr'
> 
> dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0xc9):Wrap_hsc_make.c: 
> undefined reference to `_impure_ptr'
> 
> dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0xf1):Wrap_hsc_make.c: 
> undefined reference to `_impure_ptr'
> 
> dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x125):Wrap_hsc_make.c: 
> undefined reference to `_impure_ptr'
> 
> dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x159):Wrap_hsc_make.c: 
> undefined reference to `_impure_ptr'
> 
> dist/build/Text/Regex/Posix/Wrap_hsc_make.o(.text+0x18d):Wrap_hsc_make.c: 
> more undefined references to `_impure_ptr' follow
> 
> collect2: ld returned 1 exit status
> 
> linking dist\build\Text\Regex\Posix\Wrap_hsc_make.o failed
> 
> command was: y:\ghc\ghc-6.8.2\bin\ghc.exe -optl-LC:/cygwin/lib 
> dist\build\Text\Regex\Posix\Wrap_hsc_make.o -o 
> dist\build\Text\Regex\Posix\Wrap_hsc_make.exe
> 
> bash-3.2$
> 
> Thanks,
> 
> Parnell
> 
> Parnell Flynn ? 230 South Lasalle Street ? Suite 400 ? Chicago, IL 60604 
> ? 312.244.5317 (o) ?  parnell___.flynn@ronin-capital.com_ 
> <mailto:parnell.flynn@ronin-capital.com>
> 

From gtener at gmail.com  Sat Oct 18 12:57:26 2008
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Sat Oct 18 12:53:13 2008
Subject: [Haskell-cafe] ANNOUNCE: Glob 0.1, globbing library
In-Reply-To: <gdar1j$cgf$3@ger.gmane.org>
References: <gdar1j$cgf$3@ger.gmane.org>
Message-ID: <220e47b40810180957o4b1ab85aic52ea8220e07c8b5@mail.gmail.com>

On Fri, Oct 17, 2008 at 22:02, Matti Niemenmaa
<matti.niemenmaa+news@iki.fi> wrote:
> Greetings to all,
>
> I hereby announce the release of Glob 0.1, a small library for glob-matching
> purposes based on a subset of zsh's syntax.
>
> Web page at: http://iki.fi/matti.niemenmaa/glob/index.html
> Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Glob
>
> Simple example: match (compile "foo*baz") "foobarbaz" == True.
>
> It can also group the contents of a directory given a list of patterns to match:
> globDir [compile "foo*baz"] "<a directory containing foobarbaz and joe>" gives
> (["dir/foobarbaz"],["dir/joe"]).
>
> Comments, complaints, feature requests, bug reports are all welcome. It should
> work on both GHC 6.8 and 6.10, but I've only tested the latter.
>

Hello

I tried out your package, but it doesn't seem to work correctly on
Windows. I checked the code and it has directory separator hard coded,
which seem to be the source of problems. Please see:

http://www.haskell.org/ghc/docs/latest/html/libraries/filepath/System-FilePath-Posix.html#v%3ApathSeparators

All best

Christopher Skrz?tnicki
From matti.niemenmaa+news at iki.fi  Sat Oct 18 13:28:31 2008
From: matti.niemenmaa+news at iki.fi (Matti Niemenmaa)
Date: Sat Oct 18 13:24:38 2008
Subject: [Haskell-cafe] ANNOUNCE: Glob 0.1, globbing library
In-Reply-To: <220e47b40810180957o4b1ab85aic52ea8220e07c8b5@mail.gmail.com>
References: <gdar1j$cgf$3@ger.gmane.org>
	<220e47b40810180957o4b1ab85aic52ea8220e07c8b5@mail.gmail.com>
Message-ID: <gdd6c3$2cq$1@ger.gmane.org>

Gah, I fail at posting to mailing lists. For posterity, the message I sent to
Krzysztof:

Krzysztof Skrz?tnicki wrote:
> On Fri, Oct 17, 2008 at 22:02, Matti Niemenmaa <matti.niemenmaa+news@iki.fi>
> wrote:
>> Web page at: http://iki.fi/matti.niemenmaa/glob/index.html Hackage:
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Glob
>
> I tried out your package, but it doesn't seem to work correctly on Windows. I
> checked the code and it has directory separator hard coded, which seem to be
> the source of problems.

Interesting, given that I've only tested it on Windows. ;-) Can you give an
example which doesn't work?

> Please see:
>
>
http://www.haskell.org/ghc/docs/latest/html/libraries/filepath/System-FilePath-Posix.html#v%3ApathSeparators

I tried to be diligent about using isPathSeparator and the related functions and
constants (even isExtSeparator), and a grep over the code reveals nothing, so if
something doesn't work I don't think it's because of that.

P.S.: I just uploaded 0.2 which has a somewhat speedier globDir. No
functionality changes.

From gtener at gmail.com  Sat Oct 18 14:14:10 2008
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Sat Oct 18 14:09:56 2008
Subject: [Haskell-cafe] ANNOUNCE: Glob 0.1, globbing library
In-Reply-To: <gdd6c3$2cq$1@ger.gmane.org>
References: <gdar1j$cgf$3@ger.gmane.org>
	<220e47b40810180957o4b1ab85aic52ea8220e07c8b5@mail.gmail.com>
	<gdd6c3$2cq$1@ger.gmane.org>
Message-ID: <220e47b40810181114h1c76caf8yb4d9a0e884ca1082@mail.gmail.com>

On Sat, Oct 18, 2008 at 19:28, Matti Niemenmaa
<matti.niemenmaa+news@iki.fi> wrote:
> Gah, I fail at posting to mailing lists. For posterity, the message I sent to
> Krzysztof:
>
> Krzysztof Skrz?tnicki wrote:
>> On Fri, Oct 17, 2008 at 22:02, Matti Niemenmaa <matti.niemenmaa+news@iki.fi>
>> wrote:
>>> Web page at: http://iki.fi/matti.niemenmaa/glob/index.html Hackage:
>>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Glob
>>
>> I tried out your package, but it doesn't seem to work correctly on Windows. I
>> checked the code and it has directory separator hard coded, which seem to be
>> the source of problems.
>
> Interesting, given that I've only tested it on Windows. ;-) Can you give an
> example which doesn't work?
>

Ouch... I feel like I deserve an entry on http://failblog.org/
Somehow I assumed that globDir has type
[Pattern] -> FilePath -> IO [FilePath]
where in reality it has type
[Pattern] -> FilePath -> IO ([[FilePath]], [FilePath])

When I saw lots of files that didn't match my query I thought there is a bug...
I'll certainly doublecheck any bug reports before submitting.
Sorry for the noise.

All best

Christopher Skrz?tnicki
From dons at galois.com  Sat Oct 18 14:50:14 2008
From: dons at galois.com (Don Stewart)
Date: Sat Oct 18 14:45:46 2008
Subject: Arch Haskell News: Oct 18 2008
Message-ID: <20081018185014.GA12925@scytale.galois.com>

= News about Haskell on Arch Linux =

Arch Linux now has 639 Haskell packages in AUR.

That?s an increase of 15 new Haskell packages in the last 7 days. Growth appears
to be holding steady at just over 2 new packages a day on Hackage this
month.

Noteworthy

    * haskell-gnuplot-0.2: ?2D and 3D plots using gnuplot?
    * alex-2.3: ?Alex is a tool for generating lexical analysers in Haskell?
    * happy-1.18.1: ?Happy is a parser generator for Haskell?
    * haskell-tfp-0.1: ?Type-level programming library using type families?

Full details on the site.

    http://archhaskell.wordpress.com/2008/10/18/arch-haskell-news-oct-18-2008/

From bart at cs.pdx.edu  Tue Oct 21 05:03:55 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Tue Oct 21 04:59:48 2008
Subject: Proposal #2717: Add nubWith, nubOrd
Message-ID: <loom.20081021T090019-984@post.gmane.org>

Ok, I've killed the overly ambitious proposal #2629, and replaced
it with the more modest proposal #2717
  http://hackage.haskell.org/trac/ghc/ticket/2717
which just adds Data.List.nubWith and Data.Set.nubOrd as previously
discussed ad nauseam.

I know at least one person thought that adding these was a bad idea, but some
others thought it was a fine thing to do.  Hence the discussion on this list.

    Bart Massey
    bart@cs.pdx.edu

From neil.mitchell.2 at credit-suisse.com  Tue Oct 21 05:16:57 2008
From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil)
Date: Tue Oct 21 05:13:34 2008
Subject: Proposal #2717: Add nubWith, nubOrd
In-Reply-To: <loom.20081021T090019-984@post.gmane.org>
References: <loom.20081021T090019-984@post.gmane.org>
Message-ID: <33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>

Hi,

nubOrd: Seems good. Useful function to have. Shame its not in Data.List,
but I understand the reasons for that, and think this is a perfectly
sensible choice.

nubWith: Seems bad. A not particularly useful function (other than to
write nubOrd), with a fairly confusing name. I have previously used
nubWith to mean nubOn (nubOn f = nubBy ((==) `on` f)) with cacheing of
the function f. As a name, "with" only means "with additional stuff" -
it gives no hint what the additional stuff is. The concept of stop-lists
is a little confusing, and then you tell the user they almost certainly
want to pass [] every single time - in that case why do they get an
option? Also stop-lists have type "b", so
stop-unconstrainted-type-variable seems a more appropriate name :-) The
type signature is fairly complex.

I'm not even convinced that nubWith really is a nub function, and not
just some generalised filter - filterState perhaps. In which case you'd
want to generalise Maybe b to (Bool,b). Can you ever imagine anyone
other than nubOrd using nubWith? Is it a genuine utility function people
have been crying out for? It seems perfectly good to include as a local
function in Data.Set to be used to implement nubOrd, but I don't see its
value as a standalone export from a very commonly used library full of
very useful stuff.

So, in summary I think nubOrd is great, and nubWith isn't nub, and isn't
great.

Thanks

Neil
 

> -----Original Message-----
> From: libraries-bounces@haskell.org 
> [mailto:libraries-bounces@haskell.org] On Behalf Of Bart Massey
> Sent: 21 October 2008 10:04 am
> To: libraries@haskell.org
> Subject: Proposal #2717: Add nubWith, nubOrd
> 
> Ok, I've killed the overly ambitious proposal #2629, and 
> replaced it with the more modest proposal #2717
>   http://hackage.haskell.org/trac/ghc/ticket/2717
> which just adds Data.List.nubWith and Data.Set.nubOrd as 
> previously discussed ad nauseam.
> 
> I know at least one person thought that adding these was a 
> bad idea, but some others thought it was a fine thing to do.  
> Hence the discussion on this list.
> 
>     Bart Massey
>     bart@cs.pdx.edu
> 
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 
> 

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

From daveroundy at gmail.com  Tue Oct 21 08:54:33 2008
From: daveroundy at gmail.com (David Roundy)
Date: Tue Oct 21 08:50:12 2008
Subject: Proposal #2717: Add nubWith, nubOrd
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>
References: <loom.20081021T090019-984@post.gmane.org>
	<33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>
Message-ID: <117f2cc80810210554u21af0c05y52b8b4c6fc7ab7f7@mail.gmail.com>

On Tue, Oct 21, 2008 at 5:16 AM, Mitchell, Neil
<neil.mitchell.2@credit-suisse.com> wrote:
> So, in summary I think nubOrd is great, and nubWith isn't nub, and isn't
> great.

Good  points.

David
From Christian.Maeder at dfki.de  Tue Oct 21 11:41:16 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Tue Oct 21 11:36:53 2008
Subject: fgl version missing on hackage
Message-ID: <48FDF81C.9010405@dfki.de>

Hi Ross,

on
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl
there are fgl-versions 5.3, 5.4.1.1

However, ghc-6.8.3 was shipped with fgl-5.4.2.0

fgl-5.4.2.0 exports more functions (ie. xdfsWith)
and I would like to use it with other ghc versions, too.

Could you upload fgl-5.4.2.0?

Cheers Christian

From dons at galois.com  Tue Oct 21 11:45:00 2008
From: dons at galois.com (Don Stewart)
Date: Tue Oct 21 11:42:30 2008
Subject: fgl version missing on hackage
In-Reply-To: <48FDF81C.9010405@dfki.de>
References: <48FDF81C.9010405@dfki.de>
Message-ID: <20081021154500.GE27232@scytale.galois.com>

Christian.Maeder:
> Hi Ross,
> 
> on
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl
> there are fgl-versions 5.3, 5.4.1.1
> 
> However, ghc-6.8.3 was shipped with fgl-5.4.2.0
> 
> fgl-5.4.2.0 exports more functions (ie. xdfsWith)
> and I would like to use it with other ghc versions, too.
> 
> Could you upload fgl-5.4.2.0?
> 
> Cheers Christian

Since this is not a core library, and is maintained by Martin Erwig, he
should probably be doing the hackage uploads now, as he releases new
versions.

Martin, have you used Hackage?

-- Don
From bart at cs.pdx.edu  Tue Oct 21 13:38:22 2008
From: bart at cs.pdx.edu (Bart Massey)
Date: Tue Oct 21 13:34:10 2008
Subject: Proposal #2717: Add nubWith, nubOrd
References: <loom.20081021T090019-984@post.gmane.org>
	<33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>
Message-ID: <loom.20081021T170645-558@post.gmane.org>

Mitchell, Neil <neil.mitchell.2 <at> credit-suisse.com> writes:
> nubOrd: Seems good. Useful function to have. Shame its not in Data.List,
> but I understand the reasons for that, and think this is a perfectly
> sensible choice.

Thanks.

> nubWith: Seems bad. A not particularly useful function (other than to
> write nubOrd), with a fairly confusing name. I have previously used
> nubWith to mean nubOn (nubOn f = nubBy ((==) `on` f)) with cacheing of
> the function f. As a name, "with" only means "with additional stuff" -
> it gives no hint what the additional stuff is.

Were we to keep it, do you have a better naming suggestion?  I agree that
nubWith is not optimal, but I don't have a great alternative.  As you sort
of suggest below, maybe nubFilter could work?  [The problem starts with
the belief of everyone I've ever talked to about it that "nub" itself
should have been called "uniq". :-)]

> The concept of stop-lists is a little confusing, and then you tell
> the user they almost certainly want to pass [] every single time - in that
> case why do they get an option?

One can imagine situations in which you want to accumulate a "stop list"
over several runs of the function, but of course nubWith as designed won't
let you do that, so that's fail.

If they already have a list of things they want pre-stopped, they could
pass that in.  Imagine a variant of nondescendingSubsequence below in
which the accumulator started with 0 instead of the first element, for
example.

Of course the technical reason the user needs to pass an empty stop list is that
we killed the type class that goes with nubWith, so there's no way to know what
the empty accumulator of their stop list type actually is.

> Also stop-lists have type "b", so stop-unconstrainted-type-variable
> seems a more appropriate name.  

The name "stop list" is a term of art in the algorithm and AI fields, which
is why I chose it.  I could stick some bib reference in the docs if
you thought that would help.  In general, the stop list is an accumulator
of values that you want to stop after the first one.

> The type signature is fairly complex.

I agree.  I'd written this off initially for this reason, but other
folks on the list seem to be fine with it.

> I'm not even convinced that nubWith really is a nub function, and not
> just some generalised filter - filterState perhaps. In which case you'd
> want to generalise Maybe b to (Bool,b).

Or to Either b b?  Which is preferred in this case?

> Can you ever imagine anyone other than nubOrd using nubWith?

Yes. As discussed previously you can get a significant constant factor
speedup with nubInt on IntSets if you need it.  Also, as discussed previously,
you can get a speedup for nubChar by using a mutable array as the stop list.

One can also imagine using this in less traditional ways; for example

  nondescendingSubsequence [] = []
  nondescendingSubsequence (e : es) =
    e : nubWith (\a b-> if (a >= b) then Just a else Nothing) e es

  > nondescendingSubsequence [1,2,3,2,3,3,4,1,1]
  [1,2,3,3,3,4]

> Is it a genuine utility function people
> have been crying out for?

IMHO it is a "genuine utility function", whatever that means.
It certainly isn't something "people have been crying out for",
so if that's the criterion we should omit it.

It just seems churlish to hide it, given that it's sitting in
there being a perfectly useful building block for things people
do cry out for.  I'd guess it would be used about as often
as "break", which is in there for much the same reason.

> It seems perfectly good to include as a local
> function in Data.Set to be used to implement nubOrd, but I don't see its
> value as a standalone export from a very commonly used library full of
> very useful stuff.

We could move it to live in Data.Set with nubOrd if folks think that it
doesn't belong in Data.List.  Or we could move them both into their own module,
although that seems silly to me given that I can't really think what else
goes in there.

> So, in summary I think nubOrd is great, and nubWith isn't nub, and isn't
> great.

Thanks hugely for the detailed commentary!

Please understand that I'm in no way wedded to the idea of getting any of this
in; I want to do what works best for everyone, and am grateful for your and
everyone's help in figuring out what that is.

    Bart Massey
    bart@cs.pdx.edu

From ross at soi.city.ac.uk  Tue Oct 21 17:51:48 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Tue Oct 21 17:47:28 2008
Subject: fgl version missing on hackage
In-Reply-To: <20081021154500.GE27232@scytale.galois.com>
References: <48FDF81C.9010405@dfki.de>
	<20081021154500.GE27232@scytale.galois.com>
Message-ID: <20081021215147.GA7070@soi.city.ac.uk>

On Tue, Oct 21, 2008 at 08:45:00AM -0700, Don Stewart wrote:
> Christian.Maeder:
> > on
> > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl
> > there are fgl-versions 5.3, 5.4.1.1
> > 
> > However, ghc-6.8.3 was shipped with fgl-5.4.2.0
> > 
> > fgl-5.4.2.0 exports more functions (ie. xdfsWith)
> > and I would like to use it with other ghc versions, too.
> > 
> > Could you upload fgl-5.4.2.0?
> 
> Since this is not a core library, and is maintained by Martin Erwig, he
> should probably be doing the hackage uploads now, as he releases new
> versions.

But Christian is talking about a release that has already been made,
as part of a GHC release.  There's a list of these here:

http://www.haskell.org/haskellwiki/Libraries_released_with_GHC

(I see that Win32's version number went backwards between GHC 6.6.1/6.8.1.)

It might make sense for some of these versions to be extracted from the
GHC source releases and placed on hackage.
From jstrait at moonloop.net  Tue Oct 21 19:53:02 2008
From: jstrait at moonloop.net (Jon Strait)
Date: Tue Oct 21 20:00:07 2008
Subject: HUnit in Hackage
Message-ID: <48FE6B5E.9000804@moonloop.net>

Just some quick user feedback/questions.

The current HUnit in Hackage depends on base (==4.*).  I'm running  GHC
6.8.3 with base 3.0.2.0.   Is there an easier way to upgrade base
without rebuilding GHC?  Otherwise, the Cabal upgrade refuses to work
unless I uninstall my older HUnit completely, do the Cabal upgrade, then
re-install the older HUnit.  I have other packages which depend on
HUnit, so this must be done every time.  Or is there a way to tell Cabal
Install that I want to mask off HUnit for upgrading when I do a Cabal
upgrade?

Thanks,
Jon

From neil.mitchell.2 at credit-suisse.com  Wed Oct 22 03:59:12 2008
From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil)
Date: Wed Oct 22 03:55:41 2008
Subject: Proposal #2717: Add nubWith, nubOrd
In-Reply-To: <loom.20081021T170645-558@post.gmane.org>
References: <loom.20081021T090019-984@post.gmane.org>
	<33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>
	<loom.20081021T170645-558@post.gmane.org>
Message-ID: <33A3F585590A6F4E81E3D45AA4A111C90396078B@ELON17P32001A.csfb.cs-group.com>

Hi

> Were we to keep it, do you have a better naming suggestion?

[Warning: untested code]

filterAccum :: (acc -> x -> (acc,Bool)) -> acc -> [x] -> (acc, [x])
filterAccum f a [] = (a, [])
filterAccum f a (x:xs) = (an, [x|b]++rest)
   where (a2,b) = f a x
         (an,rest) = filterAccum f a2 xs

This follows the type of mapAccumL, and is more general than your
function. You could change the utility function to be (acc -> x ->
(acc,Maybe y)) to get a variant that is more general than both mapAccum
and filterAccum.


> could work?  [The problem starts with the belief of everyone 
> I've ever talked to about it that "nub" itself should have 
> been called "uniq". :-)]

Your function has nothing to do with uniqueness or nubness. It is
filtering with a state.

> Of course the technical reason the user needs to pass an 
> empty stop list is that we killed the type class that goes 
> with nubWith, so there's no way to know what the empty 
> accumulator of their stop list type actually is.

This all seems like complexity that shouldn't be there. The base library
should provide simple things (folds, maps, filters) and simple concepts
with very slightly more involved implementations (sort, reverse, nub).
Anything that isn't a simple concept should go in a separate library.

> general, the stop list is an accumulator of values that you 
> want to stop after the first one.

That's how you use it from nubOrd, not anything to do with the function.

> > I'm not even convinced that nubWith really is a nub 
> function, and not 
> > just some generalised filter - filterState perhaps. In which case 
> > you'd want to generalise Maybe b to (Bool,b).
> 
> Or to Either b b?  Which is preferred in this case?

Either b b is a horrible type, its semantically equivalent to (Bool,b)
but with added confusion (in most cases, there are some exceptions). See
my above filterState for a more general version.


> > Can you ever imagine anyone other than nubOrd using nubWith?
> 
> Yes. As discussed previously you can get a significant 
> constant factor speedup with nubInt on IntSets if you need 
> it.  Also, as discussed previously, you can get a speedup for 
> nubChar by using a mutable array as the stop list.

Sounds like great reasons for adding nubInt (or just nubOrd in the
IntMap module). Perhaps there should also be a CharMap module which
provides similar values for Char. I can't imagine your nubChar with a
mutable array handles all Unicode points?

These ideas are starting to be more radical, and sound like the thing a
type class or type families would be suited for. Perhaps prototype these
ideas in a "fastnub" library on Hackage?

> One can also imagine using this in less traditional ways; for example
> 
>   nondescendingSubsequence [] = []
>   nondescendingSubsequence (e : es) =
>     e : nubWith (\a b-> if (a >= b) then Just a else Nothing) e es
> 
>   > nondescendingSubsequence [1,2,3,2,3,3,4,1,1]
>   [1,2,3,3,3,4]
> 
> > Is it a genuine utility function people have been crying out for?
> 
> IMHO it is a "genuine utility function", whatever that means.
> It certainly isn't something "people have been crying out 
> for", so if that's the criterion we should omit it.

I think for the base library that "crying out for" is the minimum
criteria. We also need it to have an obvious name, a well explored
design space (or an obviously trivial design space), and the desire to
support it for all eternity.

> It just seems churlish to hide it, given that it's sitting in 
> there being a perfectly useful building block for things 
> people do cry out for.  I'd guess it would be used about as 
> often as "break", which is in there for much the same reason.

Hoogle uses break 33 times. It used to use it a lot more, but then I
moved to using Parsec. I've never had a desire to use filterState or
nubWith. I'm only one person, so this may not be typical.

> 
> > It seems perfectly good to include as a local function in 
> Data.Set to 
> > be used to implement nubOrd, but I don't see its value as a 
> standalone 
> > export from a very commonly used library full of very useful stuff.
> 
> We could move it to live in Data.Set with nubOrd if folks 
> think that it doesn't belong in Data.List.  Or we could move 
> them both into their own module, although that seems silly to 
> me given that I can't really think what else goes in there.

It's too little for its own module - if you are going to do that just
make it a separate package. I don't want nubWith moved to Data.Set, I
want it hidden. Once its hidden, then it can go wherever (although
because of package scoping rules etc inside Data.Set is the best place)

> Please understand that I'm in no way wedded to the idea of 
> getting any of this in; I want to do what works best for 
> everyone, and am grateful for your and everyone's help in 
> figuring out what that is.

I realise. I really am very enthusiastic about getting nubOrd in (I've
even proposed it previously myself), and appreciate the effort you've
put into this.

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

From marlowsd at gmail.com  Wed Oct 22 06:11:54 2008
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed Oct 22 06:07:37 2008
Subject: Repair to floating point enumerations?
In-Reply-To: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
References: <20081015104125.3c260127.Malcolm.Wallace@cs.york.ac.uk>
Message-ID: <48FEFC6A.5040004@gmail.com>

Malcolm Wallace wrote:

> Phil proposes that, although retaining the instances of Enum for Float
> and Double, we simplify the definitions of the numericEnumFrom family:
> 
>   numericEnumFromThenTo   :: (Fractional a, Ord a) => a -> a -> a -> [a]
>   numericEnumFrom         =  iterate (+1)
>   numericEnumFromThen n m =  iterate (+(m-n)) n
>   numericEnumFromTo n m   =  takeWhile (<= m) (numericEnumFrom n)
>   numericEnumFromThenTo n m p = takeWhile (<= p) (numericEnumFromThen n m)

I'll leave it to the floating-point experts to decide exactly what to do 
here for Haskell' (but I note that David Roundy's version looks better than 
the iterate version above, because the errors won't accumulate).

> But as maintainer and bug-fixer of the Haskell'98 Report, I have also
> been asked whether we should make this change retrospectively to the
> Haskell'98 language (as a "typo").  Since it involves not merely an
> ordinary library function, but a Prelude function, and moreover a
> function that is used in the desugaring of syntax, it is less clear to
> me whether to alter Haskell'98.

We definitely can't make breaking changes to Haskell 98; this would be much 
more than a "typo".

However, this does give us a problem if we decide to make a change here for 
H', as Neil points out, because there would be two mutually-incompatible 
instances for Enum Float.  We'd need to have a clear distinction between 
programs that are Haskell 98 and those that are not, with only the former 
allowed to use the haskell98 package.

Cheers,
	Simon

From isaacdupree at charter.net  Wed Oct 22 15:56:33 2008
From: isaacdupree at charter.net (Isaac Dupree)
Date: Wed Oct 22 15:52:30 2008
Subject: Proposal #2717: Add nubWith, nubOrd
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C90396078B@ELON17P32001A.csfb.cs-group.com>
References: <loom.20081021T090019-984@post.gmane.org>	<33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>	<loom.20081021T170645-558@post.gmane.org>
	<33A3F585590A6F4E81E3D45AA4A111C90396078B@ELON17P32001A.csfb.cs-group.com>
Message-ID: <48FF8571.4070701@charter.net>

Mitchell, Neil wrote:
> Hi
> 
>> Were we to keep it, do you have a better naming suggestion?
> 
> [Warning: untested code]
> 
> filterAccum :: (acc -> x -> (acc,Bool)) -> acc -> [x] -> (acc, [x])
> filterAccum f a [] = (a, [])
> filterAccum f a (x:xs) = (an, [x|b]++rest)
>    where (a2,b) = f a x
>          (an,rest) = filterAccum f a2 xs
> 
> This follows the type of mapAccumL, and is more general than your
> function.

can we call it filterAccumL then?  It took me a while to 
figure out from the code whether it was truly an "L" or "R" 
version, and in principle there could be filterAccumR 
(although I don't know why we'd want it)

> You could change the utility function to be (acc -> x ->
> (acc,Maybe y)) to get a variant that is more general than both mapAccum
> and filterAccum.

in which case the result type would be (acc, [y]), and it 
would have a similar type and semantics to
Data.Maybe.mapMaybe :: (a -> Maybe b) -> [a] -> [b]

.. maybeAccumL? :-)

-Isaac
From duncan.coutts at worc.ox.ac.uk  Wed Oct 22 17:45:21 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Oct 22 17:40:58 2008
Subject: HUnit in Hackage
In-Reply-To: <48FE6B5E.9000804@moonloop.net>
References: <48FE6B5E.9000804@moonloop.net>
Message-ID: <1224711921.21116.205.camel@dell.linuxdev.us.dell.com>

On Tue, 2008-10-21 at 16:53 -0700, Jon Strait wrote:
> Just some quick user feedback/questions.
> 
> The current HUnit in Hackage depends on base (==4.*).  I'm running  GHC
> 6.8.3 with base 3.0.2.0.   Is there an easier way to upgrade base
> without rebuilding GHC?  Otherwise, the Cabal upgrade refuses to work
> unless I uninstall my older HUnit completely, do the Cabal upgrade, then
> re-install the older HUnit.  I have other packages which depend on
> HUnit, so this must be done every time.  Or is there a way to tell Cabal
> Install that I want to mask off HUnit for upgrading when I do a Cabal
> upgrade?

I've updated the hunit package so that the latest version will build
with either base 3 or 4 (ie with ghc-6.8 or 6.10).

I'll upload that to hackage soon. In the mean time use the older version
of hunit eg:

cabal install 'hunit < 1.2.0.1'


In future I'll try to make cabal-install a bit cleverer so that when the
latest version obviously cannot be installed then it'll consider older
versions too (but not full backtracking). This should help users who are
using an older generation of packages.

Duncan

From neil.mitchell.2 at credit-suisse.com  Thu Oct 23 03:30:20 2008
From: neil.mitchell.2 at credit-suisse.com (Mitchell, Neil)
Date: Thu Oct 23 03:26:32 2008
Subject: Proposal #2717: Add nubWith, nubOrd
In-Reply-To: <48FF8571.4070701@charter.net>
References: <loom.20081021T090019-984@post.gmane.org>
	<33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>
	<loom.20081021T170645-558@post.gmane.org>
	<33A3F585590A6F4E81E3D45AA4A111C90396078B@ELON17P32001A.csfb.cs-group.com>
	<48FF8571.4070701@charter.net>
Message-ID: <33A3F585590A6F4E81E3D45AA4A111C90396079E@ELON17P32001A.csfb.cs-group.com>

Hi

> >> Were we to keep it, do you have a better naming suggestion?
> > 
> > [Warning: untested code]
> > 
> > filterAccum :: (acc -> x -> (acc,Bool)) -> acc -> [x] -> (acc, [x]) 
> > filterAccum f a [] = (a, []) filterAccum f a (x:xs) = (an, 
> > [x|b]++rest)
> >    where (a2,b) = f a x
> >          (an,rest) = filterAccum f a2 xs
> > 
> > This follows the type of mapAccumL, and is more general than your 
> > function.
> 
> can we call it filterAccumL then?  It took me a while to 
> figure out from the code whether it was truly an "L" or "R" 
> version, and in principle there could be filterAccumR 
> (although I don't know why we'd want it)

Yes, that would be the sensible name. However, I don't think it deserves
to be in the standard libraries :-)

If anyone feels it should be, that sounds like it should be a separate
proposal from nubOrd.

> > You could change the utility function to be (acc -> x -> (acc,Maybe 
> > y)) to get a variant that is more general than both mapAccum and 
> > filterAccum.
> 
> in which case the result type would be (acc, [y]), and it 
> would have a similar type and semantics to 
> Data.Maybe.mapMaybe :: (a -> Maybe b) -> [a] -> [b]
> 
> .. maybeAccumL? :-)

Yes, that does seem like the correct name for it. Again, I don't think
it's a massively useful function - the Accum functions just aren't as
useful anymore now Monads are better understood.

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

From apfelmus at quantentunnel.de  Thu Oct 23 03:59:26 2008
From: apfelmus at quantentunnel.de (apfelmus)
Date: Thu Oct 23 03:55:14 2008
Subject: Proposal #2717: Add nubWith, nubOrd
In-Reply-To: <33A3F585590A6F4E81E3D45AA4A111C90396078B@ELON17P32001A.csfb.cs-group.com>
References: <loom.20081021T090019-984@post.gmane.org>	<33A3F585590A6F4E81E3D45AA4A111C903960775@ELON17P32001A.csfb.cs-group.com>	<loom.20081021T170645-558@post.gmane.org>
	<33A3F585590A6F4E81E3D45AA4A111C90396078B@ELON17P32001A.csfb.cs-group.com>
Message-ID: <gdpasu$p79$1@ger.gmane.org>

Mitchell, Neil wrote:
> Hi
> 
>> Were we to keep it, do you have a better naming suggestion?
> 
> [Warning: untested code]
> 
> filterAccum :: (acc -> x -> (acc,Bool)) -> acc -> [x] -> (acc, [x])
> filterAccum f a [] = (a, [])
> filterAccum f a (x:xs) = (an, [x|b]++rest)
>    where (a2,b) = f a x
>          (an,rest) = filterAccum f a2 xs
> 
> This follows the type of mapAccumL, and is more general than your
> function. You could change the utility function to be (acc -> x ->
> (acc,Maybe y)) to get a variant that is more general than both mapAccum
> and filterAccum.

In other words,

   mapAccumL    = mapM
   filterAccumL = filterM

when used with the state monad.


Concerning the proposal, I agree with Neil, +1 for  nubOrd  and -1 for
nubWith  . Adding  filterAccum  sounds reasonable but should be a
separate proposal.


The patch introduces two documentation errors concerning the asymptotic
complexity:  m  is *not* the number of duplicate elements but the number
of *unique* elements, i.e.  n  minus the number of duplicates.
Furthermore, the proposed documentation for  nubOrd  should mention what
 nubOrd  actually does. I suggest changing it to:

  Like 'nub', the 'nubOrd' function removes duplicate elements
  from a list.

  But while 'nub' only requires that two elements
  can be tested for equality ('Eq a'), 'nubOrd' requires that
  the elements can be ordered ('Ord a'). This allows the 'nubOrd'
  implementation to be significantly faster; it runs in
  /O(n log m)/ time where /n/ is the length of the list and
  /m/ is the number of unique elements in that list.


Regards,
apfelmus

From Christian.Maeder at dfki.de  Thu Oct 23 07:40:15 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu Oct 23 07:35:44 2008
Subject: fgl version missing on hackage
In-Reply-To: <20081021215147.GA7070@soi.city.ac.uk>
References: <48FDF81C.9010405@dfki.de>	<20081021154500.GE27232@scytale.galois.com>
	<20081021215147.GA7070@soi.city.ac.uk>
Message-ID: <4900629F.90507@dfki.de>

Ross Paterson wrote:
> On Tue, Oct 21, 2008 at 08:45:00AM -0700, Don Stewart wrote:
>> Christian.Maeder:
>>> Could you upload fgl-5.4.2.0?
[..]

I see, there is even a newer version fgl-5.4.2.1
http://web.engr.oregonstate.edu/~erwig/fgl/haskell/

I would very much appreciate, if these libraries were reachable via
cabal-install, Martin.

> http://www.haskell.org/haskellwiki/Libraries_released_with_GHC
> 
> (I see that Win32's version number went backwards between GHC 6.6.1/6.8.1.)

columns for ghc-6.6 and ghc-6.6.1 are reversed

> It might make sense for some of these versions to be extracted from the
> GHC source releases and placed on hackage.

fgl-5.4.2.0 is the only library left that:
 - is not on hackage
 - has a blank entry for ghc-6.10.1 on
   http://www.haskell.org/haskellwiki/Libraries_released_with_GHC
 - was shipped with ghc-6.8.3 or earlier ghcs (on the same page)

So at least fgl-5.4.2.0 should be uploaded. (Version fgl-5.4.1 for
ghc-6.6.1 is also missing)

Cheers Christian
From ross at soi.city.ac.uk  Thu Oct 23 07:57:40 2008
From: ross at soi.city.ac.uk (Ross Paterson)
Date: Thu Oct 23 07:53:18 2008
Subject: fgl version missing on hackage
In-Reply-To: <4900629F.90507@dfki.de>
References: <48FDF81C.9010405@dfki.de>
	<20081021154500.GE27232@scytale.galois.com>
	<20081021215147.GA7070@soi.city.ac.uk> <4900629F.90507@dfki.de>
Message-ID: <20081023115740.GA12068@soi.city.ac.uk>

On Thu, Oct 23, 2008 at 01:40:15PM +0200, Christian Maeder wrote:
> columns for ghc-6.6 and ghc-6.6.1 are reversed

Thanks.

> fgl-5.4.2.0 is the only library left that:
>  - is not on hackage
>  - has a blank entry for ghc-6.10.1 on
>    http://www.haskell.org/haskellwiki/Libraries_released_with_GHC
>  - was shipped with ghc-6.8.3 or earlier ghcs (on the same page)
> 
> So at least fgl-5.4.2.0 should be uploaded.

I uploaded it (the version in ghc-6.8.3) just before you posted.
From gale at sefer.org  Thu Oct 23 09:20:30 2008
From: gale at sefer.org (Yitzchak Gale)
Date: Thu Oct 23 09:16:02 2008
Subject: Proposal #2717: Add nubWith, nubOrd
In-Reply-To: <loom.20081021T090019-984@post.gmane.org>
References: <loom.20081021T090019-984@post.gmane.org>
Message-ID: <2608b8a80810230620k5adb3805yc99c1536348de60b@mail.gmail.com>

Bart Massey wrote:
>  http://hackage.haskell.org/trac/ghc/ticket/2717

Hmm, this reminds us that Data.Set really needs

insertMember :: Ord a => a -> Set a -> (Bool, Set a)

so that we don't need to traverse the tree twice each
time. And the same for Data.IntSet, of course.
Analogous to existing things like

Data.Set.deleteFindMin
Data.Map.insertLookupWithKey

Hasn't someone made this obvious proposal before?
From dons at galois.com  Thu Oct 23 09:40:17 2008
From: dons at galois.com (Don Stewart)
Date: Thu Oct 23 09:35:45 2008
Subject: fgl version missing on hackage
In-Reply-To: <4900629F.90507@dfki.de>
References: <48FDF81C.9010405@dfki.de>
	<20081021154500.GE27232@scytale.galois.com>
	<20081021215147.GA7070@soi.city.ac.uk> <4900629F.90507@dfki.de>
Message-ID: <20081023134017.GC365@scytale.galois.com>

Christian.Maeder:
> Ross Paterson wrote:
> > On Tue, Oct 21, 2008 at 08:45:00AM -0700, Don Stewart wrote:
> >> Christian.Maeder:
> >>> Could you upload fgl-5.4.2.0?
> [..]
> 
> I see, there is even a newer version fgl-5.4.2.1
> http://web.engr.oregonstate.edu/~erwig/fgl/haskell/
> 
> I would very much appreciate, if these libraries were reachable via
> cabal-install, Martin.
> 
> > http://www.haskell.org/haskellwiki/Libraries_released_with_GHC
> > 
> > (I see that Win32's version number went backwards between GHC 6.6.1/6.8.1.)
> 
> columns for ghc-6.6 and ghc-6.6.1 are reversed
> 
> > It might make sense for some of these versions to be extracted from the
> > GHC source releases and placed on hackage.
> 
> fgl-5.4.2.0 is the only library left that:
>  - is not on hackage
>  - has a blank entry for ghc-6.10.1 on
>    http://www.haskell.org/haskellwiki/Libraries_released_with_GHC
>  - was shipped with ghc-6.8.3 or earlier ghcs (on the same page)
> 
> So at least fgl-5.4.2.0 should be uploaded. (Version fgl-5.4.1 for
> ghc-6.6.1 is also missing)
> 

yes, that's a good point to remember. ghc's moving out of the library
maintainance business, in favour of hackage and the platform team. the 
gap between 'extralibs' released with ghc 6.10 and ghc 6.8 needs to be
checked, to make sure those packages in the gap are on hackage.

-- Don
From waldmann at imn.htwk-leipzig.de  Thu Oct 23 14:44:33 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Thu Oct 23 14:40:11 2008
Subject: configVerbose, writeHookedBuildInfo
Message-ID: <4900C611.2080906@imn.htwk-leipzig.de>

Hello.

these things seem to have gone missing from Cabal-1.4 to 1.6:
configVerbose writeHookedBuildInfo

this is from a Setup.lhs posted here:
http://article.gmane.org/gmane.comp.lang.haskell.libraries/7628

now what? I knew to insert build-depends: base==3.* but here I'm lost.

J.W.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20081023/34ee01de/signature.bin
From duncan.coutts at worc.ox.ac.uk  Thu Oct 23 18:20:43 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Thu Oct 23 18:33:01 2008
Subject: configVerbose, writeHookedBuildInfo
In-Reply-To: <4900C611.2080906@imn.htwk-leipzig.de>
References: <4900C611.2080906@imn.htwk-leipzig.de>
Message-ID: <1224800443.21116.328.camel@dell.linuxdev.us.dell.com>

On Thu, 2008-10-23 at 20:44 +0200, Johannes Waldmann wrote:
> Hello.
> 
> these things seem to have gone missing from Cabal-1.4 to 1.6:
> configVerbose writeHookedBuildInfo

There is configVerbosity with a slightly different type.
writeHookedBuildInfo moved to the Distribution.PackageDescription.Parse
module. It's not ideal but having one massive
Distribution.PackageDescription module was also not ideal. I'd use
recursive modules but that has it's own set of problems.

Duncan

From dominic.steinitz at blueyonder.co.uk  Sat Oct 25 06:49:15 2008
From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz)
Date: Sat Oct 25 06:44:49 2008
Subject: Some QuickCheck Instances
Message-ID: <4902F9AB.6020503@blueyonder.co.uk>

I often find I need to use QuickCheck & SmallCheck with e.g. Word8 but
there don't seem to be standard instances. Would these be worth adding?
If so, what would I need to do? Just send a patch to the maintainers?

Thanks, Dominic.

> 
> instance Serial Word8 where
>    series d = drawnFrom (map fromIntegral [0..d])

> instance Arbitrary Word8 where
>    arbitrary =
>       do n <- choose ((fromIntegral (minBound::Word8))::Int,
>                       (fromIntegral (maxBound::Word8))::Int)
>          return (fromIntegral n)
> 
> instance Arbitrary Word64 where
>    arbitrary =
>       do n <- choose ((fromIntegral (minBound::Word64))::Integer,
>                       (fromIntegral (maxBound::Word64))::Integer)
>          return (fromIntegral n)
> 
> instance Arbitrary Word128 where
>    arbitrary =
>       do n <- choose ((fromIntegral (minBound::Word128))::Integer,
>                       (fromIntegral (maxBound::Word128))::Integer)
>          return (fromIntegral n)
> 

From waldmann at imn.htwk-leipzig.de  Mon Oct 27 15:03:54 2008
From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann)
Date: Mon Oct 27 14:59:15 2008
Subject: configVerbose, writeHookedBuildInfo
In-Reply-To: <1224800443.21116.328.camel@dell.linuxdev.us.dell.com>
References: <4900C611.2080906@imn.htwk-leipzig.de>
	<1224800443.21116.328.camel@dell.linuxdev.us.dell.com>
Message-ID: <4906109A.3010506@imn.htwk-leipzig.de>

Thanks, Duncan.

Now I have *.cabal and Setup.hs that make hsql-[mysql-]-1.7 compile
with ghc-6.10.0.20081007. Where to send them?

Johannes.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20081027/4eeb1488/signature.bin
From duncan.coutts at worc.ox.ac.uk  Wed Oct 29 05:51:36 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Wed Oct 29 06:44:19 2008
Subject: configVerbose, writeHookedBuildInfo
In-Reply-To: <4906109A.3010506@imn.htwk-leipzig.de>
References: <4900C611.2080906@imn.htwk-leipzig.de>
	<1224800443.21116.328.camel@dell.linuxdev.us.dell.com>
	<4906109A.3010506@imn.htwk-leipzig.de>
Message-ID: <1225273896.24950.1.camel@dell.linuxdev.us.dell.com>

On Mon, 2008-10-27 at 20:03 +0100, Johannes Waldmann wrote:
> Thanks, Duncan.
> 
> Now I have *.cabal and Setup.hs that make hsql-[mysql-]-1.7 compile
> with ghc-6.10.0.20081007. Where to send them?

Frederik Eaton <frederik@ofb.net> is the current HSQL maintainer.

Duncan

From pcc03 at doc.ic.ac.uk  Thu Oct 30 13:17:42 2008
From: pcc03 at doc.ic.ac.uk (Peter Collingbourne)
Date: Thu Oct 30 13:12:51 2008
Subject: darcs patch: Added list operations for arrows
Message-ID: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>

Hello,

This patch adds two arrow combinators which I have found useful: mapA
(equivalent of map) and filterA (equivalent of filter).

Thu Oct 30 16:50:02 GMT 2008  Peter Collingbourne <pcc03@doc.ic.ac.uk>
  * Added list operations for arrows

Thanks,
-- 
Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 2903 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/libraries/attachments/20081030/4cf34fca/attachment.bin
From g9ks157k at acme.softbase.org  Fri Oct 31 08:26:55 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Fri Oct 31 08:22:11 2008
Subject: darcs patch: Added list operations for arrows
In-Reply-To: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
References: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
Message-ID: <200810311326.55357.g9ks157k@acme.softbase.org>

Am Donnerstag, 30. Oktober 2008 18:17 schrieb Peter Collingbourne:
> Hello,
>
> This patch adds two arrow combinators which I have found useful: mapA
> (equivalent of map) and filterA (equivalent of filter).
>
> Thu Oct 30 16:50:02 GMT 2008  Peter Collingbourne <pcc03@doc.ic.ac.uk>
>   * Added list operations for arrows
>
> Thanks,

Hello,

wouldn?t it be better to stop using identifiers containing categorization in 
form of single letters like filterA, mappend, etc.?  I?d say, we have the 
module system for this: Monoid.append, Arrow.filter, etc.  Is someone 
interested in cleaning up the library interfaces in this regard while 
maintaining compatibility?

Best wishes,
Wolfgang
From duncan.coutts at worc.ox.ac.uk  Fri Oct 31 09:21:40 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Fri Oct 31 09:16:50 2008
Subject: darcs patch: Added list operations for arrows
In-Reply-To: <200810311326.55357.g9ks157k@acme.softbase.org>
References: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
	<200810311326.55357.g9ks157k@acme.softbase.org>
Message-ID: <1225459300.8437.79.camel@localhost>

On Fri, 2008-10-31 at 13:26 +0100, Wolfgang Jeltsch wrote:
> Am Donnerstag, 30. Oktober 2008 18:17 schrieb Peter Collingbourne:
> > Hello,
> >
> > This patch adds two arrow combinators which I have found useful: mapA
> > (equivalent of map) and filterA (equivalent of filter).
> >
> > Thu Oct 30 16:50:02 GMT 2008  Peter Collingbourne <pcc03@doc.ic.ac.uk>
> >   * Added list operations for arrows
> >
> > Thanks,
> 
> Hello,
> 
> wouldn?t it be better to stop using identifiers containing categorization in 
> form of single letters like filterA, mappend, etc.?  I?d say, we have the 
> module system for this: Monoid.append, Arrow.filter, etc.  Is someone 
> interested in cleaning up the library interfaces in this regard while 
> maintaining compatibility?

Here here! 

'A.filter' rather than 'filterA' (with a suitable qualified import).

Duncan

From g9ks157k at acme.softbase.org  Fri Oct 31 10:45:17 2008
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Fri Oct 31 10:40:26 2008
Subject: darcs patch: Added list operations for arrows
In-Reply-To: <1225459300.8437.79.camel@localhost>
References: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
	<200810311326.55357.g9ks157k@acme.softbase.org>
	<1225459300.8437.79.camel@localhost>
Message-ID: <200810311545.17419.g9ks157k@acme.softbase.org>

Am Freitag, 31. Oktober 2008 14:21 schrieben Sie:
> On Fri, 2008-10-31 at 13:26 +0100, Wolfgang Jeltsch wrote:
> > Am Donnerstag, 30. Oktober 2008 18:17 schrieb Peter Collingbourne:
> > > Hello,
> > >
> > > This patch adds two arrow combinators which I have found useful: mapA
> > > (equivalent of map) and filterA (equivalent of filter).
> > >
> > > Thu Oct 30 16:50:02 GMT 2008  Peter Collingbourne <pcc03@doc.ic.ac.uk>
> > >   * Added list operations for arrows
> > >
> > > Thanks,
> >
> > Hello,
> >
> > wouldn?t it be better to stop using identifiers containing categorization
> > in form of single letters like filterA, mappend, etc.?  I?d say, we have
> > the module system for this: Monoid.append, Arrow.filter, etc.  Is someone
> > interested in cleaning up the library interfaces in this regard while
> > maintaining compatibility?
>
> Here here!
>
> 'A.filter' rather than 'filterA' (with a suitable qualified import).
>
> Duncan

Hmm, is this meant ironically or seriously?  Sorry, I just don?t know.

A.filter has the advantage over filterA that it has more structure: the module 
name expresses the general topic and the actual name denotes the concrete 
function.  In addition, you can drop the qualification if there is no 
ambiguity.

Another point is that filterA uses just a single letter for ?arrow?.  This 
concept quickly leads to ambiguities.  For example, in mappend, the ?m? 
stands for ?monoid? while in msum, it stands for ?monad?.  Something like 
filterArrow would have the disadvantage that it is longer.  With qualified 
imports, the user of the library can decide whether to use a single letter 
(A.filter) or something more descriptive (Arrow.filter).

I think, this topic came up a while ago on some Haskell list already and there 
were several people arguing that employing the module system as I suggest was 
the better way.

Best wishes,
Wolfgang
From leather at cs.uu.nl  Fri Oct 31 11:17:40 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Fri Oct 31 11:12:46 2008
Subject: darcs patch: Added list operations for arrows
In-Reply-To: <200810311545.17419.g9ks157k@acme.softbase.org>
References: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
	<200810311326.55357.g9ks157k@acme.softbase.org>
	<1225459300.8437.79.camel@localhost>
	<200810311545.17419.g9ks157k@acme.softbase.org>
Message-ID: <3c6288ab0810310817g4c6b15feqfcf78853df70a80d@mail.gmail.com>

> > Here here!
> >
> > 'A.filter' rather than 'filterA' (with a suitable qualified import).
> >
> > Duncan
>
> Hmm, is this meant ironically or seriously?  Sorry, I just don't know.
>

I believe this is a Duncan-esque form of agreement with your recommendation.

I also agree with you. See, for example, EMGM's use of generic versions of
Prelude functions.

Regards,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20081031/3dd8f99b/attachment.htm
From lemming at henning-thielemann.de  Fri Oct 31 15:10:18 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri Oct 31 15:05:31 2008
Subject: darcs patch: Added list operations for arrows
In-Reply-To: <3c6288ab0810310817g4c6b15feqfcf78853df70a80d@mail.gmail.com>
References: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
	<200810311326.55357.g9ks157k@acme.softbase.org>
	<1225459300.8437.79.camel@localhost>
	<200810311545.17419.g9ks157k@acme.softbase.org>
	<3c6288ab0810310817g4c6b15feqfcf78853df70a80d@mail.gmail.com>
Message-ID: <alpine.DEB.1.00.0810312009590.14945@anubis.informatik.uni-halle.de>


On Fri, 31 Oct 2008, Sean Leather wrote:

>>> Here here!
>>>
>>> 'A.filter' rather than 'filterA' (with a suitable qualified import).
>>>
>>> Duncan
>>
>> Hmm, is this meant ironically or seriously?  Sorry, I just don't know.
>>
>
> I believe this is a Duncan-esque form of agreement with your recommendation.
>
> I also agree with you. See, for example, EMGM's use of generic versions of
> Prelude functions.

What is EMGM?
From lemming at henning-thielemann.de  Fri Oct 31 15:12:16 2008
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri Oct 31 15:07:23 2008
Subject: darcs patch: Added list operations for arrows
In-Reply-To: <200810311326.55357.g9ks157k@acme.softbase.org>
References: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
	<200810311326.55357.g9ks157k@acme.softbase.org>
Message-ID: <alpine.DEB.1.00.0810312011310.14945@anubis.informatik.uni-halle.de>


On Fri, 31 Oct 2008, Wolfgang Jeltsch wrote:

> Hello,
>
> wouldn?t it be better to stop using identifiers containing categorization in
> form of single letters like filterA, mappend, etc.?  I?d say, we have the
> module system for this: Monoid.append, Arrow.filter, etc.  Is someone
> interested in cleaning up the library interfaces in this regard while
> maintaining compatibility?

At least, I would be interested in using such cleaned up interface.
From leather at cs.uu.nl  Fri Oct 31 20:39:59 2008
From: leather at cs.uu.nl (Sean Leather)
Date: Fri Oct 31 20:35:04 2008
Subject: darcs patch: Added list operations for arrows
In-Reply-To: <alpine.DEB.1.00.0810312009590.14945@anubis.informatik.uni-halle.de>
References: <E1Kvb9S-0000fu-88@raphael.doc.ic.ac.uk>
	<200810311326.55357.g9ks157k@acme.softbase.org>
	<1225459300.8437.79.camel@localhost>
	<200810311545.17419.g9ks157k@acme.softbase.org>
	<3c6288ab0810310817g4c6b15feqfcf78853df70a80d@mail.gmail.com>
	<alpine.DEB.1.00.0810312009590.14945@anubis.informatik.uni-halle.de>
Message-ID: <3c6288ab0810311739u72895d51k8fc2993dfa2efb1f@mail.gmail.com>

> I also agree with you. See, for example, EMGM's use of generic versions of
>> Prelude functions.
>>
>
> What is EMGM?
>

My apologies for not providing the appropriate link.

  http://www.cs.uu.nl/wiki/GenericProgramming/EMGM

In summary: datatype-generic programming using type classes with a
sum-of-products view.

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20081101/6a3e772e/attachment.htm