- Libraries - Haskell.org

Proposal: Improve error messages for (!!) (include index and length of list)
by Simon Hengel 17 Oct '14

17 Oct '14

Hi, currently we have the following implementation for (!!): #ifdef USE_REPORT_PRELUDE xs !! n | n < 0 = error "Prelude.!!: negative index" [] !! _ = error "Prelude.!!: index too large" (x:_) !! 0 = x (_:xs) !! n = xs !! (n-1) #else -- HBC version (stolen), then unboxified xs !! (I# n0) | isTrue# (n0 <# 0#) = error "Prelude.(!!): negative index\n" | otherwise = sub xs n0 where sub :: [a] -> Int# -> a sub [] _ = error "Prelude.(!!): index too large\n" sub (y:ys) n = if isTrue# (n ==# 0#) then y else sub ys (n -# 1#) #endif I propose to change the error messages for the non-report version to include index and list length, something that is functionally equivalent to: xs !! (I# n0) | isTrue# (n0 <# 0#) = indexError xs n0 | otherwise = sub xs n0 where sub :: [a] -> Int# -> a sub [] _ = indexError xs n0 sub (y:ys) n = if isTrue# (n ==# 0#) then y else sub ys (n -# 1#) indexError :: [a] -> Int# -> b indexError xs (I# -> n) | n < 0 = error ("Prelude.(!!): negative index " ++ show n) | otherwise = error ("Prelude.(!!): index " ++ show n ++ " too large for list of length " ++ show (length xs)) Some usage examples: *Main> [1, 2, 3] !! (-1) *** Exception: Prelude.(!!): negative index -1 *Main> [1, 2, 3] !! 3 *** Exception: Prelude.(!!): index 3 too large for list of length 3 This will require some refactoring, i.e. we need to move itos from GHC.Show to e.g. GHC.Base. Discussion period: 2 weeks Cheers, Simon

5 5

Proposal: Make a very slight change to the semantics of Data.List.isSuffixOf
by David Feuer 16 Oct '14

16 Oct '14

Currently, isSuffixOf is defined like this: xs `isSuffixOf` ys = reverse xs `isPrefixOf` reverse ys If ys is much longer than xs, this is not so wonderful, because we have to reverse the whole spine of ys. It also will fail whenever either xs *or* ys is infinite. The following implementation seems a lot saner (although longer): isSuffixOf :: forall a . (Eq a) => [a] -> [a] -> Bool [] `isSuffixOf` _ = True needle `isSuffixOf` hay = maybe False (\fp -> needle `eq` getEndChunk hay fp) (getFrontPointer needle hay) where eq :: [a] -> [a] -> [a] (x:xs) `eq` (y:ys) = x==y && (xs `eq` ys) getEndChunk :: [a] -> [a] -> [a] getEndChunk (_:hy) (_:fp) = getEndChunk hy fp getEndChunk hy _ = hy getFrontPointer :: [a] -> [a] -> Maybe [a] getFrontPointer [] hy = Just hy getFrontPointer _ [] = Nothing getFrontPointer (_:nd) (_:hy) = getFrontPointer nd hy This doesn't do any of that crazy stuff, and it will work just fine if the needle is infinite. The only slightly sticky point is that it's not *strictly* lazier. In particular, [1,2] `Data.List.isSuffixOf` [undefined, 7] = False [1,2] `isSuffixOf` [undefined, 7] = undefined But note that [1,2] `Data.List.isSuffixOf` [7,undefined] = undefined [1,2] `isSuffixOf` [7, undefined] = False It would be possible to get the same kind of laziness at the end using something structured as above, but it requires some unpleasantness: instead of using needle `eq` getEndChunk hay fp we'd have to use needle `backwardsEq` getEndChunk hay fp (x:xs) `backwardsEq` (y:ys) = (xs `backwardsEq` ys) && x==y This is yucky. My guess is that no one is relying on the current behavior, but I'd like to make sure everyone's okay with this. David

7 23

Re: Proposal: Make a very slight change to the semantics of Data.List.isSuffixOf
by David Feuer 14 Oct '14

14 Oct '14

On Oct 14, 2014 9:05 AM, "Kim-Ee Yeoh" <ky3(a)atamo.com> wrote: > > David, > > To paraphrase Kernighan, ascertaining correctness is twice as hard as writing a program in the first place. So if you're as clever as possible with your code, how will you know it's even correct? I think we have different senses of what is easy to understand. We're all working on modifications of Andreas Abel's "naive" approach. I don't think the Reid Barton/Kim-Ee Yeoh modification is easier to understand than the David Feuer/Milan Straka one. In particular, your approach makes the weird long needle/short haystack case implicit, dumping it into the equality test. I also think the principle of least (bad) surprise applies: I wouldn't *expect* an overly long needle to be traversed in full and then the elements compared. > Case in point: the infinite lists wrinkle that you started the thread with. /At a glance/ what do the general recursion versions (yours and Milan's) evaluate to on infinite lists? I can't undo my understanding and say what I would have thought. But it's certainly a whole lot easier to understand than, say, the `permutations` or `sort` functions, and I could easily add two or three lines of explanation that would guide anyone to a correct interpretation. > What are the benchmarks on the time it takes for a haskell programmer to figure them out? Would they not jump at the greater affordance of reasoning with Andreas's compositions? Let me know when the benchmarks and experimental results are in. Don't forget to get IRB approval for human trials. > Meaning and reasonableness have always been the hallmarks of core libs. I think we have an honest disagreement hear about what is "reasonable". I think it's unreasonable for [undefined, undefined] `isSuffixOf` [undefined] to be undefined, but you see it differently. > Least of all, since it's so losering to benchmark the wrong thing, see below on how Andreas-dropl no.1 beats out David-Milan by the tiniest sliver in short-needle-long-haystack. Like checking file extensions in pathnames that we saw in Andreas's Agda code. The "long haystack" benchmark I used is actually much, much longer than a path name. My "short needle, short haystack" example is the one designed to test the pathname extension performance. > Here a concrete app brings real meaning to the timings as opposed to optimizing for vaporware. Watch them Agdaists fall off their chairs when they hit the speed boost. ;)

1 0

Discussion: Add safeWithFile function
by David Feuer 13 Oct '14

13 Oct '14

Some care is required to use withFile properly with lazy IO, and people sometimes get it wrong. In some cases, readFile is a suitable replacement. In other cases, however, it may be necessary to ensure the file gets closed in a timely manner, and it may not be necessary to read the whole file. The following seems to do the trick: safeWithFile :: (NFData a) => String -> IOMode -> (Handle -> IO a) -> IO a safeWithFile name mode f = withFile name mode $ f >=> (return $!!) Sample use: *SafeWithFile> safeWithFile "SafeWithFile.hs" ReadMode hGetContents >>= putStr module SafeWithFile (safeWithFile) where import Control.DeepSeq import System.IO import Control.Monad safeWithFile :: (NFData a) => String -> IOMode -> (Handle -> IO a) -> IO a safeWithFile name mode f = withFile name mode $ f >=> (return $!!)

6 10

Optimizing isSuffixOf (was Re: Proposal: Make a very slight change to the semantics of Data.List.isSuffixOf)
by Kim-Ee Yeoh 11 Oct '14

11 Oct '14

On Fri, Oct 10, 2014 at 4:18 PM, Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> wrote: > That seems rather wordy to me. Can we get anywhere starting with > > a `isSuffixOf` b = a `elem` tails b > > and transforming? Is it only about wordiness & syntax? With the original a `isSuffixOf` b = reverse a `isPrefixOf` reverse b and with Jon's a `isSuffixOf` b = a `elem` tails b I'm completely convinced of the correctness, modulo that of the referenced functions. Moreover, the conviction was obtained cheaply. My finite neurons are saved for the greater task at hand. The proposal on the table snatches away that providence. I have to take it on the authority of others that it's correct. Rust recently exposed a bug in their string matching function. It's their version of Data.List.isInfixOf. See http://www.wabbo.org/blog/2014/22aug_on_bananas.html These days I point all my colleagues and friends to this article as a classic case of premature optimization. But I understand that some folks prefer their computations always rapid, if sometimes wrong. David, is there an application underlying the need for isSuffixOf speed? You might want to look into the ByteString libraries for your optimization efforts. Over there, performance is several notches up in priority. -- Kim-Ee

1 0

Re: [core libraries] List of core libraries
by Neil Mitchell 10 Oct '14

10 Oct '14

> Btw, I'm a bit wondering, why do you think the testsuite's failure won't > mark the Travis-CI build as failed? :) It's a bit hard to know for sure, but my logic is: * https://github.com/haskell/filepath/blob/master/tests/AutoTest.hs#L38 means that the output of the QuickCheck test doesn't cause an exception (as it originally was), but just prints a message about failure * The travis doesn't look at https://github.com/haskell/filepath/blob/master/tests/filepath.stdout So Travis doesn't check the test won't be broken by GHC, and I think without that check it doesn't spot failures. (That's my chain of reasoning, but it's all a little subtle, so could quite easily be wrong!) > I'd suggest to simply add you to the maintainer-team for filepath on > https://github.com/haskell/filepath/ if that's ok for you (in fact, I've > just added you in just in case) Great. >> * What's the integration with GHC? Does the filepath module get pulled >> directly into GHC source trees? I see it's in the GHC test suite - is >> that considered a good idea? > > it's a submodule in ghc.git, and we have an automatic mirroring job > mirroring to git.haskell.org/packages/filepath.git > > And from time to time, we'd update the commit ghc.git points to inside > filepath.git; so you can freely push to master on > https://github.com/haskell/filepath w/o affecting GHC HEAD, only when we > update the filepath gitlink we'd see the effect of it in GHC HEAD. Perfect. I'm sure I'll do something incompatible with the GHC world at some point, but just shout at me when I do (or, if there happens to be a list of the most likely stupid things I might do, let me know). > I think this is mostly a historic artefact, as something Travis wasn't > around when filepath started being used by GHC. Cabal was barely around when filepath started being used by GHC... Cabal test was at least one incompatible iteration as well. > Do you have the means to test filepath on all GHC tier-1 > platforms/archs? (That's the only benefit I currently see with having > the tests as part of GHC's validation testsuite) No, that's valuable, and certainly makes it work keeping. Thanks, Neil

1 0

Proposal: end lazy IO results with errors/exceptions
by David Feuer 10 Oct '14

10 Oct '14

Currently, withFile "foo" hGetContents >>= putStrLn prints out an empty line, the better to confuse newbies. I propose modifying the lazyRead function in GHC.IO.Handle.Text that currently reads lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, "") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) to something like lazyRead :: Handle -> IO String lazyRead handle = unsafeInterleaveIO $ withHandle "hGetContents" handle $ \ handle_ -> do case haType handle_ of ClosedHandle -> return (handle_, error "Forcing the result of a lazy read led to an attempt to read from a closed handle.") SemiClosedHandle -> lazyReadBuffered handle handle_ _ -> ioException (IOError (Just handle) IllegalOperation "hGetContents" "illegal handle type" Nothing Nothing) Ideally that error should instead be something to throw an imprecise exception, but I don't know how to use those yet. I can't personally see a way for this to break sane, working code, but the folks on #ghc thought it should be discussed and debated on list. David Feuer

10 12

Re: [core libraries] List of core libraries
by Neil Mitchell 09 Oct '14

09 Oct '14

I did semi-hand the filepath library over to the Core libraries committee, it was just about 6 years before the committee formed so you probably don't have records of it, which is why libraries@ is listed as the author. I'm happy to take a more active role in maintaining it. In particular, I was intending to review/comment on https://github.com/haskell/filepath/pulls, and have the intention to add a bunch of patches (https://github.com/ndmitchell/shake/issues/174) Most of the patches are either obviously a good idea (fixing broken code) or improving the docs. The only one which could have any debate surrounding it is the introduction of a new operator -<.>. I don't want to debate that now, but it would be good to get clarification as to whether I should unilaterally add it, or should go through the libraries submission process, or ... Thanks, Neil On Tue, Sep 30, 2014 at 4:17 PM, Andrew Gill <andygill(a)ku.edu> wrote: > All, > > I’ve not touched hoc for quite a while. KU now has the resources to take > ownership, if needed. It’s pretty stable, from what I understand, but could > do with the an updated manual. > > Andy Gill > > On Sep 28, 2014, at 1:45 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > > Herbert: > > Heretofore I'd been treating filepath as owned by Neil Mitchell, but that > statement does sound like he's handed it off to the libraries process, which > would make it a core-libraries issue if he doesn't want to deal with it. > > I'm copying him on this thread to get his opinion. > > I've also copied Andy Gill, to see if he has any opinions on the state of > who owns update responsibility for hpc itself. > > Andy, Neil: Thoughts? > > Thomas: Thanks for forcing this issue to attention. > > -Edward > > On Sun, Sep 28, 2014 at 2:14 PM, Herbert Valerio Riedel <hvriedel(a)gmail.com> > wrote: >> >> On 2014-09-28 at 19:40:25 +0200, Thomas Miedema wrote: >> >> [...] >> >> > Ok, final question: What about filepath and hpc? Their .cabal files list >> > libraries(a)haskell.org as maintainer, which usually means the Core >> > Libraries >> > Committee. Should filepath be added to that list, and the maintainer for >> > both filepath and hpc be set to the Core Libraries Committee? If not, >> > who >> > maintains filepath? >> >> This is supposed to be an answer, but rather additional data-points: >> >> As far as filepath is concerned: >> >> http://community.haskell.org/~ndm/filepath/ >> >> states >> >> | The library is now part of the core Haskell libraries, and since GHC >> | 6.6.1 has been shipped with all major compilers. While I am the >> | original author, changes are now made through the library submissions >> | process. >> >> as for Hpc, if you look at its changelog over at >> >> http://git.haskell.org/packages/hpc.git/shortlog >> >> it's been effectively maintained by GHC HQ for the last couple of >> years... > > >

2 2

ANN: New version of graphmod (1.2.4)
by Iavor Diatchki 03 Oct '14

03 Oct '14

Hello, I am pleased to announce a new version of `graphmod`---a program that helps you visualize the import dependencies between the modules in your Haskell programs. The new feature in version 1.2.4 is support for pruning the dependency graph, which is enabled with the flag -p or --prune-edges. When this option is selected, `graphmod` will ignore imports to modules that are already imported by some of the dependencies of the module. For example, consider the following modules: module A where { import B; import C } module B where { import C } module C where { } When generated with `--prune-edges`, the resulting graph will be: A -> B -> C Note that there is no edge from `A` to `C`, because `C` is already imported by `B`. Happy hacking, -Iavor

1 0

Removing MonadFail from Monad
by David Luposchainsky 03 Oct '14

03 Oct '14

Hey everyone, I feel like there are a couple of elephants in the room that are sort of important but nobody really addresses them directly. One of them was what became the AMP, and `fail` is another one. I resurrected and refurbished this proposal from a 6 month old Gist because there seemed to be some interest/talk going on in the form of side remarks in other discussions here. The sun shines, let's make some hay! The proposal text can be found at the end of this text (for the mailman archives), or in pretty HTML here: https://github.com/quchen/articles/blob/master/monad_fail.md Although this will technically a language-level change, the impact will mainly be a library and fail-safety detail. For this reason I think this mailing list is more suitable than other more specialized lists. Greetings, David/quchen PS: I would have chosen Fail Removal Proposal so we have a new buzzword, but unfortunately it does not abbreviate well. Call it the "fail of Haskell issue"? ;-) Removing `fail` from `Monad` ============================ The problem ----------- Currently, the `<-` symbol is desugared as follows: ```haskell do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` The problem with this is that `fail` cannot be sensibly implemented for many monads, for example `State`, `IO`, `Reader`. In those cases it defaults to `error`, i.e. the monad has a built-in crash. `MonadFail` class ----------------- To fix this, introduce a new typeclass: ```haskell class Monad m => MonadFail m where fail :: String -> m a ``` Desugaring is then changed to the following: ```haskell -- Explicitly irrefutable pattern: do not add MonadFail constraint do ~pat <- computation >>> let f pat = more more >>> in computation >>= f -- Only one data constructor: do not add MonadFail constraint do (Only x) <- computation >>> let f (Only x) = more more >>> in computation >>= f -- Otherwise: add MonadFail constraint do pat <- computation >>> let f pat = more more >>> f _ = fail "..." >>> in computation >>= f ``` Discussion ---------- - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail` class should be created. A parser might fail with an error message involving positional information, and for STM failure is undefined although it is `MonadPlus`. - The case of one data constructor should emit a warning if the data type is defined via `data`: adding another data constructor can make patterns in unrelated modules refutable. - Some monads use the pattern matching to force evaluation of the binding, for example lazy/strict `StateT`. I'm not sure what exactly the consequences of the above are here; I suspect a strictness annotation or `(>>=)` instead of `do` notation might be sufficient. - Getting the change to work should be boring but painless: all Monad instance declarations involving `fail` will break because the function is removed, and many monadic computations have to be annotated using `~` because they were written under the assumption that `fail` is never called. In both these cases compilation errors/warnings carry sufficient information to fix the source code easily. - Backwards compatibility with many old modules will be broken; I don't see a way around this. Other things to consider ------------------------ - Rename `fail`? It's quite a generic name that would be nice to have in APIs. `failM`? `mfail`? - Remove the `String` argument? (May hurt error reporting on pattern mismatch ..?) - How sensitive would existing code be to subtle changes in the strictness behaviour of `do` notation pattern matching? Applying the change ------------------- Like the AMP, 1. Implement ad-hoc warnings that code will receive a `MonadFail` constraint in a future version. "Either make the patterns irrefutable, or keep in mind that the next compiler version will require a `MonadFail` instance". Since `MonadFail` does not clash with an existing name, it could be introduced to `Control.Monad` right away. 2. Do the switch.

9 11