In case you further want to discuss this, I've re-opened
http://hackage.haskell.org/trac/ghc/ticket/2528#comment:10
So, I'm against your proposal, Cale, but suggest that you revert the
order in your example (if you want to exploit this behavior).
Cheers Christian
Am 08.09.2011 02:07, schrieb
Am 20.09.2011 20:21, schrieb Edward Kmett:
[...]
I would suggest you rephrase this as a formal proposal, then I can
happily vote +1.
Seeing the "wonderful" interrelation between elem, nub, nubBy and i.e.
unionBy eq xs ys = xs ++ foldl (flip (deleteBy eq)) (nubBy eq ys) xs
intersectBy eq
On Thursday 08 September 2011, 02:07:39, Cale Gibbard wrote:
>
> If we reimplement it in the obvious way:
> ghci> let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x)
> (nubBy f xs)
> ghci> nubBy (>=) [1,2,3,4]
> [1,2,3,4]
>
> I'm aware that the Report (strangely!) explicitly leaves the b
Apologies for responding to myself, but the difference between the
REPORT_PRELUDE and the ghc implementation also applies to elem and notElem.
#ifdef USE_REPORT_PRELUDE
elem x = any (== x)
notElem x = all (/= x)
#else
elem _ [] = False
elem x (y:ys) = x==
Looking at the old tickets
http://hackage.haskell.org/trac/ghc/ticket/2528
http://hackage.haskell.org/trac/ghc/ticket/3280
the USE_REPORT_PRELUDE version of nub is also different
from the implementation, but both variants fulfill "nub = nubBy (==)"
(the prelude version by definition).
So when we
If this is a _proposal_ to change ghc's non-Report-compatible Data.List
implementation to match the behaviour of the Report implementation, then count
me as a +1.
> I think an important convention when it comes to higher order
> functions on lists is that to the extent which is possible, the
> f
Looking at the code of nubBy
http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.4.0.0/src/Data-List.html#nubBy
nubBy :: (a -> a -> Bool) -> [a] -> [a]
#ifdef USE_REPORT_PRELUDE
nubBy eq [] = []
nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (e
Except that I didn't really say anything about evaluation order, I
said something about the semantics of the higher order function, and
what I wanted those semantics to be.
Now, of course, the Report definition leaves it completely ambiguous
what set of tests nubBy will perform when applied to som
Greetings,
It might be nice to have "nubBy" work in a way that is more intuitive to
computer scientists who expect list evaluation to work in a specific
order. Unfortunately, Haskell is quite explicit about not specifying the
order of evaluation, which can make Haskell more intuitive for
mathemati
I just tried this in ghci-7.0.3:
ghci> nubBy (>=) [1,2,3,4]
[1]
Think about what this is doing: it is excluding 2 from the list
because 2 >= 1, rather than including it because 1 >= 2 fails.
I think an important convention when it comes to higher order
functions on lists is that to the extent wh
10 matches
Mail list logo