- Libraries - Haskell.org

Re: Numeric read seems too strict
by David Feuer 09 Oct '16

09 Oct '16

The second pass can be a huge problem for a failure. For example, when parsing a long string, we first look for an open parenthesis. To do so, we lex the next token. Supposing that's the string itself, we conclude that it is a string and not an open parenthesis, so we *throw it away and start over*. I hope to get the paren issue fixed for good at Hac Phi. Aside from that rather prominent one, I don't know how much the double scanning hurts, but it certainly can't *help* in most cases. In a more typical parsing situation, the parser would consume a stream of tokens instead of a list of characters. We can't do that here. On Oct 9, 2016 12:56 AM, "wren romano" <winterkoninkje(a)gmail.com> wrote: > > On Sat, Oct 1, 2016 at 8:34 PM, David Feuer <david.feuer(a)gmail.com> wrote: > > Instead of scanning first (in lexing) to find the end of the number and then > > scanning the string again to calculate the number, start to calculate once > > the first digit appears. > > Ah, yes. bytestring-lexing does that (among numerous other things). It > does save a second pass over the characters, but I'm not sure what > proportion of the total slowdown of typical parser combinators is > actually due to the second pass, as opposed to other problems with the > typical "how hard can it be" lexers/parsers people knock out. Given > the multitude of other problems (e.g., using Integer or other > expensive types throughout the computation, not forcing things often > enough to prevent thunks and stack depth, etc), I'm not sure it's > legit to call it a "parser vs lexer" issue. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

Re: Numeric read seems too strict
by David Feuer 09 Oct '16

09 Oct '16

By the way, I believe we should be able to read numbers more efficiently by parsing them directly instead of lexing first. We have to deal with parentheses, white space, and signs uniformly for all number types. Then specialized foldl'-style code *should* be able to parse integral and fractional numbers faster than any lex-first scheme. On Sep 12, 2016 1:53 PM, "David Feuer" <david.feuer(a)gmail.com> wrote: I noticed the other day that readMaybe (fix ('a':)) :: Maybe Double is an infinite loop. The problem is that the lexer doesn't know that it's expected to lex a number. It just keeps scanning and scanning to get to the end of the endless token. Shall we fix this?

4 8

Re: space leak in base or mtl
by Edward Kmett 06 Oct '16

06 Oct '16

At the least transformers should probably provide the manual overrides for <* and *> for all of the monad transformer data types. That should fix these cases. -Edward On Thu, Oct 6, 2016 at 5:08 AM, Zoran Bosnjak <zoran.bosnjak(a)via.si> wrote: > Dear base and mtl maintainers, > I would like to report a memory leak problem (not sure which haskell > component) when using "forever" in combination with "readerT" or "stateT". > Simple test program to reproduce the problem: > --- > import Control.Concurrent > import Control.Monad > import Control.Monad.Trans > import Control.Monad.Trans.Reader > import Control.Monad.Trans.State > > main :: IO () > main = do > -- no leak when using loop1 instead of loop2 > --let loop1 = (liftIO $ threadDelay 1) >> loop1 > let loop2 = forever (liftIO $ threadDelay 1) > > _ <- runStateT (runReaderT loop2 'a') 'b' > return () > --- > > I have asked on haskell-cafe, but the analysis is above my haskell > knowledge: > https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125176.html > https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125177.html > https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125178.html > > regards, > Zoran > >

1 0

looking for haskell-llvm list maintainer Erik de Castro Lopo
by Henning Thielemann 03 Oct '16

03 Oct '16

A bit off-topic: I tried to send an e-mail to haskell-llvm(a)projects.haskell.org It was refused, although an e-mail to the list was accepted a month ago. I tried to reach the list maintainer at: haskell-llvm-owner(a)projects.haskell.org Erik de Castro Lopo <mle+hs(a)mega-nerd.com> Erik de Castro Lopo <erikd(a)mega-nerd.com> No success. Any idea how to contact Erik or what is broken at haskell-llvm(a)projects.haskell.org?

3 3

Generalise type of deleteBy
by Matthew Pickering 01 Oct '16

01 Oct '16

The type of `deleteBy` in `Data.List` could easily be generalised in a useful way. ``` deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a] ``` to ``` deleteBy :: (a -> b -> Bool) -> a -> [b] -> [b] ``` There is this closed ticket but no reasons for not generalising. https://ghc.haskell.org/trac/ghc/ticket/3399 Discussion Period: 1 week. Matt

10 12

Proposal: add Monoid1 and Semigroup1 classes
by David Feuer 01 Oct '16

01 Oct '16

I've been playing around with the idea of writing Haskell 2010 type classes for finite sequences and non-empty sequences, somewhat similar to Michael Snoyman's Sequence class in mono-traversable. These are naturally based on Monoid1 and Semigroup1, which I think belong in base. class Semigroup1 f where (<<>>) :: f a -> f a -> f a class Semigroup1 f => Monoid1 f where mempty1 :: f a Then I can write class (Monoid1 t, Traversable t) => Sequence t where singleton :: a -> t a -- and other less-critical methods class (Semigroup1 t, Traversable1 t) => NESequence where singleton1 :: a -> t a -- etc. I can, of course, just write my own, but I don't think I'm the only one using such.

4 6

Bug in Eq/Ord typeclass documentation?
by Grant Wu 26 Sep '16

26 Sep '16

Neither Eq nor Ord have the types/summary of the methods that are part of the minimal complete definition listed. See http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Eq. Hopefully this is the right place to email. If not, apologies in advance. Thanks, Grant Wu grantwwu(a)gmail.com

2 1

Numeric read seems too strict
by David Feuer 12 Sep '16

12 Sep '16

I noticed the other day that readMaybe (fix ('a':)) :: Maybe Double is an infinite loop. The problem is that the lexer doesn't know that it's expected to lex a number. It just keeps scanning and scanning to get to the end of the endless token. Shall we fix this?

1 0

Discussion: name for reversing fromList in Data.Sequence
by David Feuer 05 Sep '16

05 Sep '16

I'd like to add a function fromListReversing :: [a] -> Seq a to Data.Sequence, with fromListReversing = reverse . fromList = fromList . reverse I don't know just what to call this function, however.

3 2

Modules for new map merge functions may be renamed
by David Feuer 02 Sep '16

02 Sep '16

We hope to make one more, fairly small, major release for containers for inclusion in GHC 8.2. I am considering renaming the new modules Data.Map.Merge.Lazy and Data.Map.Merge.Strict instead of Data.Map.Strict.Merge and Data.Map.Lazy.Merge. That seems more consistent with the module scheme for the rest of the package, and leaves open the option of adding extra merge-related modules in the future. I'm sorry about the potential wobble, but I think taking care of this now will lead to much less trouble than waiting till later.

1 0