- Libraries - Haskell.org

Re: Drastic Prelude changes imminent
by davean 03 Feb '15

03 Feb '15

Ah yes. That is, strictly speaking not code. I suppose it could count as breakage also, but I think it is far less likely to cause confusion though as they're clearly asking about implementation and getting an answer that its changed. On Tue, Feb 3, 2015 at 2:41 PM, Erik Hesselink <hesselink(a)gmail.com> wrote: > On Tue, Feb 3, 2015 at 8:32 PM, davean <davean(a)xkcd.com> wrote: > > On Tue, Feb 3, 2015 at 2:20 PM, Erik Hesselink <hesselink(a)gmail.com> > wrote: > >> > >> > 2. Breakage of existing tutorials/documentation > >> > >> I was just wondering which of these you were alluding to. Turns out > >> it's all of them :) I'm surprised you mention breakage of code, since > >> in my experience most of the breakage in GHC 7.10 I've seen in my own > >> packages and the Stackage builds is due to other factors: the > >> Applicative/Monad changes, time 1.5, etc. It would be interesting (but > >> time consuming) to gather some statistics on this. The breakage of > >> tutorials is unfortunate, yes. > > > > > > So how bad is the breakage of tutorial code really? Looking around almost > > all of it has a full top level type which makes it still work. I've only > > looked for a few minutes but my first impression is that not much breaks > > with this. Is this just a theory or have people actually determined that > > tutorial code breaks? > > > > (Actually, I've found plenty of broken tutorial code, but it wasn't due > to > > anything in prelude. Our standard library churn seems much worse on > > tutorials I've looked at then this seems to be.) > > I think the 'breakage' is mostly used as mentioning things that work > on lists, while they now work on Foldable/Traversables. For example, > LYAH mentions "length takes a list and returns its length, > obviously.", which isn't true anymore in the strictest sense, it takes > any Foldable. However, you could argue that this text is just > specialization, and that it's still true. There seem to be no things > that are generalized in the section about types, and soon after type > classes are already introduced. Real World Haskell is slightly more > "broken", for example, it lists: > > ghci> :type null > null :: [a] -> Bool > > Which isn't true anymore, it would now give "Foldable t => t a -> Bool". > > Regards, > > Erik > > P.S. You didn't send your message to haskell-cafe. Feel free to > forward it including this reply if you want. >

2 1

Proposal: Add mapWithIndex to Data.List
by David Feuer 01 Feb '15

01 Feb '15

Vectors offer `imap` and sequences offer `mapWithIndex`. I think lists deserve to have something like this too. The obvious implementation, using `zipWith`, is unlikely to be the most efficient (because foldr/build fusion doesn't handle zips so wonderfully). To a first approximation: mapWithIndex :: (Int -> a -> b) -> [a] -> [b] mapWithIndex f xs = build $ \c n -> let go x cont !i = f i x `c` cont (i+1) in foldr go (`seq` n) 0

2 4

Re: Drastic Prelude changes imminent
by Alec 31 Jan '15

31 Jan '15

On Sat Jan 31 2015 at 01:43:03 AM davean <davean(a)xkcd.com> wrote: > > Personally, I want a language thats good to use. That means constant > improvement. My life gets better by far more then it costs me to update > some code in fairly trivial ways when the language or libraries change. In > fact, Haskell makes updates easy. Why should we instead build up the need > to replace the language with a new one, how is that better? [...] > [...] Lets not > tear our hair out because someone made a bad decision in the 1980s and now > we're stuck with it. I've done that. It was terrible. The world doesn't > need another language that makes that mistake. > +1, Haskell98 is not a suicide pact.

1 0

Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
by Greg Fitzgerald 28 Jan '15

28 Jan '15

If BBP is going to be released as-is, can we please call the next release GHC 8.0? Good stuff: http://semver.org/ Thanks, Greg On Tue, Jan 27, 2015 at 10:22 AM, David Luposchainsky <dluposchainsky(a)googlemail.com> wrote: > Hello *, > > as much as I welcome these changes to the Prelude kitchen sink, I'm > confused about how this does not make the release a major version bump. > It changes half of the functions exposed by default in a dramatic way, > after all. Do we want to keep GHC 8 for a new Report? > > Greetings, > David/quchen > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

6 5

Re: Drastic Prelude changes imminent
by Greg Weber 27 Jan '15

27 Jan '15

On Tue, Jan 27, 2015 at 2:17 PM, Mikolaj Konarski < mikolaj.konarski(a)gmail.com> wrote: > > We already have a process that works pretty well. Create a wiki page that > > specifies the implementation. Notifying every Haskell user is pointless > if > > there is no specification for them to look at. I have no idea why the > > specification step was skipped for this change. > > Because code was the shortest specification in this case? > Or, alternatively, the specification was too vague, as in, > the most sensible set of changes that make these 5 imports > coexist without an error? Or because the best specification > was a set of detailed, readable commit messages that show > the road from this vague specification to the actual decisions > and code changes? With lots of time in between for others > to offer suggestion for subsequent commits and catch problems? > > I don't mean there's no communication problem, but specifications > are not always a solution. Perhaps a wiki page should list the commits, > as they were created. Or perhaps they were listed somewhere? > None of these rhetorical questions are satisfactory. I understand the need to iterate on a design and start with a vague specification. But by the time something concrete is figured out, it should be explained. Explaining the iteration process with a few of the code examples would answer a lot of the questions here. In the end, the changes have been explained many times over now, just not coherently in one place.

2 2

NumberSieves status/maintenance
by David Feuer 25 Jan '15

25 Jan '15

This package was last updated in 2012, and the linked darcs repository is inaccessible. Do you intend to continue to maintain this package? If not, I would be happy to take over. Thanks, David Feuer

1 0

Problem using Text.Regex on OS X.
by Peter Sumskas 25 Jan '15

25 Jan '15

Hi, I'm new to Haskell so I'm not sure how to solve this issue, yet. I was directed to this list from the IRC channel. Here's the issue: Using GHCi on OS X: Prelude Data.Text> :m Text.Regex Prelude Text.Regex> let r = mkRegex "_" ... eliding successful "Loading package ..." lines ... Loading package regex-compat-0.95.1 ... can't load .so/.DLL for: /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib (dlopen(/Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib, 9): Library not loaded: @rpath/libHSmtl-2.1.3.1-ghc7.8.3.dylib Referenced from: /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib Reason: image not found) After running otool over the regex-compat dylib I can see lines like: ... Load command 24 cmd LC_RPATH cmdsize 80 path /Users/mark/Projects/hp/build/package/mtl-2.1.3.1/build/dist/build (offset 12) ... Which is not a path that is relevant to my installation. It was suggested that this may be an error in the way packages are being built for OS X. Whatever the cause, I'm bringing it to the attention of this list in order to gain information on what course to take in addressing this issue. Thanks for your help. Kind regards, Peter Sumskas.

2 1

removing constraints
by Ross Paterson 22 Jan '15

22 Jan '15

Recent changes to avoid warnings have removed some constraints from module interfaces: * in Data.Array, Ix i was removed from: instance Ix i => Functor (Array i) instance Ix i => Foldable (Array i) bounds :: Ix i => Array i e -> (i,i) elems :: Ix i => Array i e -> [e] * in Data.Ratio, Integral a was removed from: instance (Integral a, Show a) => Show (Ratio a) numerator :: (Integral a) => Ratio a -> a denominator :: (Integral a) => Ratio a -> a These constraints are not needed by the GHC implementations, but might be needed for other possible implementations, so in a sense the changes are leaking the GHC implementations. This seems most clear in the Functor and Foldable instances for Array, and elems. Portable implementations of these will require the Ix constraint -- I think it should be restored. The other cases are more arguable. For example the change to Data.Ratio declares that the pair is kept in reduced form, but one could argue that requiring that is no bad thing.

6 8

locale: decimal comma vs. point
by Henning Thielemann 21 Jan '15

21 Jan '15

If I export a label track from Audacity the time stamps are formatted with decimal commas instead of decimal points. E.g. 1.5s is formatted as "1,5" not "1.5". I guess this is because I have German locale as default. I want to write numbers from Haskell compatible to this format and thus I want to know whether I have to format numbers with decimal commas or decimal points. However an according information or even better, a locale-aware printf seems to be missing in old-locale. :-(

1 0

Hackage is flooded with old package versions reuploads
by kyra 21 Jan '15

21 Jan '15

Hi, guys, It looks old (and even ancient) versions of many packages gets uploaded to hackage over and over again in ever increasing amounts. The username of uploader for vast majority of these uploads is HerbertValerioRiedel. While this is harmless I wonder what idea stands behind this? Cheers, Kyra

14 31