March 2013 - Libraries

Proxy and new-typeable
by Shachaf Ben-Kiki 19 Apr '13

19 Apr '13

I see that the new-typeable branch in GHC is using "typeRep :: forall a. Typeable a => Proxy a -> TypeRep" rather than "typeOf :: forall a. Typeable a => a -> TypeRep". This is clearly a big improvement over using undefined everywhere. I'd like to suggest a small change, if it hasn't been brought up before -- "typeRep :: forall proxy a. Typeable a => proxy a -> TypeRep". This makes typeRep compatible with any other Proxy type, since it doesn't use any properties of the concrete type -- it just uses it to pass information about the "a". Things that consume a Proxy don't ever need to refer to Proxy explicitly. This would make Typeable compatible with other Proxy libraries, like the one in "tagged". It would also make it compatible with any other type of kind * -> * -- for example, "typeRep ([] :: [Int])" would be a valid, and arguable more convenient, syntax for using typeRep. "Nothing :: Maybe Int" and so on would work too. So things that produce a "proxy" don't need to refer to Proxy explicitly either. Possibly this would make the Proxy type entirely unnecessary. If it stays, though, I suggest that it belongs in a module other than Data.Typeable.Internal -- it's a useful type for many other things, and as long as it's in base and exposed to users, it might as well be treated as a type in its own right. It's also a monad, can provide a variant of `asTypeOf`, and so on. Shachaf

7 24

Moving basic functions
by David Luposchainsky 06 Apr '13

06 Apr '13

Hello GHC HQ, hello mailing list, there are a couple of basic functions that I think aren't where they should be. 1. void is currently in Control.Monad. However, it is defined only in terms of fmap (and therefore only has a Functor constraint). Although this function is often used in a monadic setting as ">> return ()", I really don't think Control.Monad is the right place for it. 2. a) swap is the only function from Data.Tuple that is not exported to Prelude. On #haskell, people are sometimes even surprised there /is/ a Data.Tuple, and redefine their own version of swap at need. I therefore suggest including Data.Tuple.swap in the Prelude. The obvious downside of this change would of course be that it breaks code if there is a top-level user-defined version of it. Fixing this is of course trivial, but necessary. b) A related suggestion would be the addition of an irrefutable swap, (swap'?), defined as "swap ~(a,b) = (b,a)", and its addition to Prelude for the same reasons. 3. $>, a flipped version of <$, currently resides in Control.Comonad, but should be in Data.Functor. Applicative has <* and *>, Monad has >>= and =<<, and I personally keep redefining (or specifically importing) $> quite often, and I don't think I'm the only one. As these are quite small changes I think 2 weeks should be a sufficiently long discussion period. Greetings, David

8 17

The numeric c types are (effectively) integral, too.
by Jeff Shaw 29 Mar '13

29 Mar '13

This query is regarding Foreign.C.Types <http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Foreign-C…>. Now that the constructors for CClock, CTime, CUSeconds, and CSUSeconds are exposed, it's become clear that these are Ints or Words. Technically on some architectures they could be floating point, but I would bet that on all architectures that Haskell is ever used on, none of these are floating point types. Adding Bounded, Enum, Integral, and Bits instances to the "numeric" types would break nothing and ease situations such as this: roundTo :: CTime -> CTime -> CTime roundTo a b = (a `div` b) * b This works right now, but requires a trivial Integral class be written for every program that wants to do it. instance Integral CTime where quot (CTime a) (CTime b) = CTime (a `quot` b) rem (CTime a) (CTime b) = CTime (a `rem` b) div (CTime a) (CTime b) = CTime (a `div` b) mod (CTime a) (CTime b) = CTime (a `mod` b) quotRem (CTime n) (CTime d) = (\(d,m) -> (CTime d, CTime m)) (quotRem n d) divMod (CTime n) (CTime d) = (\(d,m) -> (CTime d, CTime m)) (divMod n d) toInteger (CTime t) = toInteger t I think this and the other trivial instances should just go right into Foreign.C.Types for all the "numeric" types in Foreign.C.Types. Any thoughts to the contrary? Jeff

8 22

cabal executable using local hsc modules
by Andreas Voellmy 25 Mar '13

25 Mar '13

Hi, I have a library that has some modules written as .hsc files and I want to include some executables that use those modules. Cabal doesn't seem to find the modules when it is building the executable. It complains that the module used by the executable is in a hidden package (of the same name as the package being built). Adding the package as a dependency in the executable section doesn't work since it references a library defined in the same package. Is this a bug? I've attached three files illustrating the problem. A.hsc is a tiny module in the library, B.hs is the executable that uses A, foo.cabal defines both the library and the executable. I am using $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library and when I run "cabal install -v" I get $ cabal install --disable-library-profiling Resolving dependencies... Configuring foo-1.0... Building foo-1.0... Preprocessing library foo-1.0... [1 of 1] Compiling A ( dist/build/A.hs, dist/build/A.o ) In-place registering foo-1.0... Preprocessing executable 'B' for foo-1.0... B.hs:3:8: Could not find module `A' It is a member of the hidden package `foo-1.0'. Perhaps you need to add `foo' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Failed to install foo-1.0 cabal: Error: some packages failed to install: foo-1.0 failed during the building phase. The exception was: ExitFailure 1

2 10

Advance notice that I'd like to make Cabal depend on parsec
by Duncan Coutts 22 Mar '13

22 Mar '13

Hi folks, I want to give you advance notice that I would like to make Cabal depend on parsec. The implication is that GHC would therefore depend on parsec and thus it would become a core package, rather than just a HP package. So this would affect both GHC and the HP, though I hope not too much. The rationale is that Cabal needs to parse things, like .cabal files and currently we do not have a decent parser in the core libraries. By decent I mean one that can produce error messages with source locations and that doesn't have unpredictable memory use. The only parser in the core libraries at the moment is Text.ParserCombinators.ReadP from the base package and that fails my "decent" criteria on both counts. Its idea of an error message is (), and on some largish .cabal files we take 100s of MB to parse (I realise that the ReadP in the base package is a cutdown version so I don't mean to malign all ReadP-style libs out there). Partly due to the performance problem, the terrible .cabal file error messages, and partly because Doaitse Swierstra keeps asking me if .cabal files have a grammar, I've been writing a new .cabal parser. It uses an alex lexer and a parsec parser. It's fast and the error messages are pretty good. I have reverse engineered a grammar that closely matches the existing parser and .cabal files in the wild, though I'm not sure Doaitse will be satisfied with the approach I've taken to handling layout. Why did I choose parsec? Practicality dictates that I can only use things in the core libraries, and the nearest thing we have to that is the parser lib that is in the HP. I tried to use happy but I could not construct a grammar/lexer combo to handle the layout (also, happy is not exactly known for its great error messages). I've been doing regression testing against hackage and I'm satisfied that the new parser matches close enough. I've uncovered all kinds of horrors with .cabal files in the wild relying on quirks of the old parser. I've made adjustments for most of them but I will be breaking a half dozen old packages (most of those don't actually build correctly because though their syntax errors are not picked up by the parser, they do cause failure eventually). So far I've just done the outline parser, not the individual field parsers. I'll be doing those next and then integrate. So this change is still a bit of a ways off, but I thought it'd be useful to warn people now. Duncan

14 25

Making monads from transformed monads
by Henning Thielemann 22 Mar '13

22 Mar '13

In a library I want to give a base monad and allow the user to choose a monad transformer. However, the Monad.Trans.Class from transformers is not strong enough, because it cannot warrant that a transformed monad is a monads itself. I have appended a module that implements a class with methods 'point' and 'bind' that correspond to 'return' and '>>='. A backward-compatible solution would be to add the class as subclass of current Monad.Trans.Class. This is how I implemented my proof-of-concept. A cleaner solution for the long run would be to add the methods 'point' and 'bind' directly to the current Monad.Trans.Class. Is there any interest in that extension or modification?

1 0

Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Johan Tibell 22 Mar '13

22 Mar '13

Hi all, As requested by Mark, here's a proposal to include unordered-containers and hashable in the platform: http://trac.haskell.org/haskell-platform/wiki/Proposals/unordered-containers The timeline is pretty short, so lets see if we can agree on this before Monday March 25th, 2013. -- Johan

11 20

ANN: text-printer - abstract interface for text builders/printers
by Mikhail Vorozhtsov 22 Mar '13

22 Mar '13

Hello, I was writing a library for working with IP addresses when I found myself puzzled with the number of contexts in which the textual representation of an address could be used: plain strings, bytestring builders (ASCII/UTF8), text builders, pretty printers, etc. I could've just written an `addressToString :: Address -> String` function, but that would be suboptimal: (a) namespace pollution (that's a lot of *ToString's if you count IPv4/6, network addresses, socket addresses, etc) and (b) some contexts can take advantage of the fact that textual representations are ASCII (e.g. UTF8 bytestring builder). And so the text-printer[1] was born. It is mainly two type classes. One for injecting text into a monoid, with special methods for ASCII and UTF-8 characters/strings. The other provides the default injection for values of a type (think of the `Pretty` type class in pretty printing libraries), the textual representation is supposed to be simple (single-line). Plus some convenient combinators and number formatters. [1] http://hackage.haskell.org/package/text-printer

1 0

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by Johan Tibell 22 Mar '13

22 Mar '13

On Wed, Mar 20, 2013 at 11:00 AM, Bardur Arantsson <spam(a)scientician.net>wrote: > AFAICT, the hash function needn't be cryptographically secure (though > that obviously avoids the issue altogether) -- if there is some > determined-at-startup "salt" that's added in to all hashed values then > that should provide good enough protection. Obviously this will mean > that the hashes won't be repeatable across runs of the same program, but > that's usually acceptable for a hash function which isn't used for > content identification(*). > > (*) For which you should use a cryptographically secure hash anyway. > This is what Python did and unfortunately it's not enough as the salt can easily be recovered if you use a weak hash function. See the SipHash paper. > > SipHash is one way to address these kinds of attacks. There are other > means > > as well. For example, many general DoS protection mechanisms (timeouts, > IP > > banning, etc) also work on these kind of attacks. > > > > Timeouts aren't necessarily sufficient -- the application can keep > sending data (e.g. form parameter data) and can cause 100% cpu usage for > a loooooonng time. After that it can just start over. > But that limits how long the any given request can occupy the CPU for (as we will sever the connection after X seconds.) > IP banning can only happen after the problem occurs. > Not at all. $BIG_WEB_COMPANIES do it on the fly using $SECRET_SMART_SAUCE. Hash flooding is only one of many ways to DoS a server. You can try other things, like building a bot net and trying to flood the connection. Just as sandboxing is a better way to run untrusted software than trying to plug every whole in your code/RTS, generic anti-DoS techniques are usually better than trying to figure out every possible way someone can DoS you. -- Johan

2 2

Re: Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
by wren ng thornton 22 Mar '13

22 Mar '13

On 3/20/13 1:02 PM, Thomas Schilling wrote:> To make this more precise the next version of hashable (say, 1.3) > would include this: > > newtype SipHashed a = SipHashed a > > class SipHashable a where > sipHashWithSalt :: Int -> a -> Int > > instance SipHashable a => Hashable (SipHashed a) where > hashWithSalt salt (SipHashed x) = sipHashWithSalt salt x > > Then all Hashable instances are taken from hashable-1.1. All Hashable > instances from hashable-1.2 are renamed to become instances of > SipHashable. That seems like a reasonable solution. I only ever use hashmaps explicitly for speed reasons and in applications that are not susceptible to DoS. The arguments about not wanting to introduce security issues due to some transitive dependency also hold for not wanting to introduce performance issues due to some transitive dependency. I respect all the folks working on web frameworks in Haskell, but there are also those of us who work on programs where compute time really is the number one concern (once an acceptable level of correctness and precision has been obtained); and when experiments are measured in days or weeks of cluster time, those "little" 1.3x and 1.5x slowdowns really hurt, let alone the 2.0x people've mentioned with siphash. One concern with the above approach: is "siphash" a sufficiently generic name, or is it just one hashing method that happens to deflect this DoS issue? I haven't read the paper, so... -- Live well, ~wren

4 3