- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] education or experience?
by Doug McIlroy 10 Dec '12

10 Dec '12

> Yes... CS academics delivers less than it could/should; > and whatever this delivery is, its asymptotically sub-linear. > Some of it is to do with the not-quick-enough takeup of FP in academia, > though there are obviously many other factors as well. > http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html > and sequel is about this: how we are not getting over the quirks of the > past history of CS in present day teaching. Here too suggestions for > modifications/ change of emphasis are appreciated. Rusi's cogent blog post includes a list of techniques/concepts that the "unconverted" could profitably pick up from the FP community. In fact the FP community came late to some of these, just as programming languages at large came late to garbage collection. Lazy evaluation--at the heart of spreadsheets since the beginning. Pattern matching--native to string processing (e.g. COMIT, SNOBOL). Appeared nearly in its present form in COGENT (1965). Booleans as first class*--surely this is a joke. Algol 60 had them. Matlab exploits them heavily (though represented as doubles). Data orientation--COBOL fostered this outlook; see Michael Jackson. As long as Lisp ruled, FP lagged on data types. FP also deserves credit for infinite data structures (though the special case of stream processing dates way back). Doug McIlroy * It's amusing to note that "real" Booleans--the ones that Boole used--were integers. For Boole, or(a,b) = a + b - a*b.

4 4

Re: [Haskell-cafe] education or experience?
by Doug McIlroy 10 Dec '12

10 Dec '12

1 0

How can I avoid buffered reads?
by Leon Smith 10 Dec '12

10 Dec '12

I have some code that reads (infrequently) small amounts of data from /dev/urandom, and because this is pretty infrequent, I simply open the handle and close it every time I need some random bytes. The problem is that I recently discovered that, thanks to buffering within GHC, I was actually reading 8096 bytes when I only need 16 bytes, and thus wasting entropy. Moreover calling hSetBuffering handle NoBuffering did not change this behavior. I'm not sure if this behavior is a bug or a feature, but in any case it's unacceptable for dealing with /dev/urandom. Probably the simplest way to fix this is to write a little C helper function that will read from /dev/urandom for me, so that I have precise control over the system calls involved. But I'm curious if GHC can manage this use case correctly; I've just started digging into the GHC.IO code myself. Best, Leon {-# LANGUAGE BangPatterns, ViewPatterns #-} import Control.Applicativeimport Data.Bitsimport Data.Word(Word64)import qualified Data.ByteString as Simport qualified Data.ByteString.Lazy as Limport Data.ByteString.Internal (c2w)import qualified System.IO as IOimport qualified Data.Binary.Get as Get showHex :: Word64 -> S.ByteStringshowHex n = s where (!s,_) = S.unfoldrN 16 f n f n = Just (char (n `shiftR` 60), n `shiftL` 4) char (fromIntegral -> i) | i < 10 = (c2w '0' - 0) + i | otherwise = (c2w 'a' - 10) + i twoRandomWord64s :: IO (Word64,Word64)twoRandomWord64s = IO.withBinaryFile "/dev/urandom" IO.ReadMode $ \handle -> do IO.hSetBuffering handle IO.NoBuffering Get.runGet ((,) <$> Get.getWord64host <*> Get.getWord64host) <$> L.hGet handle 16 main = do (x,y) <- twoRandomWord64s S.hPutStrLn IO.stdout (S.append (showHex x) (showHex y)) {- Relevant part of strace: open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff367e528) = -1 EINVAL (Invalid argument) ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ffff367e528) = -1 EINVAL (Invalid argument) read(3, "N\304\4\367/\26c\"\3218\237f\214yKg~i\310\r\262\"\224H\340y\n\376V?\265\344"..., 8096) = 8096 close(3) = 0 -}

8 12

education or experience?
by Christopher Howard 09 Dec '12

09 Dec '12

I'm at something of a crossroads, and I'm hoping to get a bit of free career advice. I really enjoy programming with Haskell (and a few other exotic languages), and was hoping I could eventually make a living in that sort of field. Not rich and famous, necessarily, just enough to get by comfortably. I'm trying to decide, however; should I go back to school, finish my B.S. and pursue a Masters in CompSci? Or would the time (and money) be better spent aggressively pursuing volunteer work for companies, hoping to eventually get the experience and contacts that lead to a paying job? To be honest, I don't really want to go back to school, because I learn a lot faster (and more economically) on my own. However, I'm not sure which path is the fastest, and safest, approach to an actual paycheck. (Also, I'm something of a die-hard FOSS purist, if that affects the discussion at all.) -- frigidcode.com

6 5

Help optimize fannkuch program
by Branimir Maksimovic 09 Dec '12

09 Dec '12

Well, playing with Haskell I have literally trasnlated my c++ program http://shootout.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=… got decent performance but not that good in comparisonwith c++ On my machine Haskell runs 52 secs while c++ 30 secs.(There is Haskell entry that is fastest but unfortunately does not runs on test machine is on par with c++http://shootout.alioth.debian.org/u64q/program.php?test=fannkuchredux&la… is something which I have missing since programsare identical.Aa with previous entries you gurus here helped a lot in both helpand learning experience.I simply love Haskell ;)I plan to contribute this program as it is much faster than current runningentry http://shootout.alioth.debian.org/u64q/program.php?test=fannkuchredux&lang=… if it is multithreaded and my is not. This is program: {-# LANGUAGE CPP, BangPatterns #-}{- The Computer Language Benchmarks Game http://shootout.alioth.debian.org/ contributed by Branimir Maksimovic -} import System.Environmentimport Text.Printfimport Data.Bits import qualified Data.Vector.Unboxed.Mutable as VMimport qualified Data.Vector.Generic.Mutable as VGimport qualified Data.Vector.Unboxed as V main = do n <- getArgs >>= readIO.head (checksum,maxflips) <- fannkuch n printf "%d\nPfannkuchen(%d) = %d\n" checksum n maxflips fannkuch n = do !perm <- V.unsafeThaw $ V.fromList [1..n] !tperm <- VG.new n !cnt <- VG.replicate n 0 let loop :: Int -> Int -> Int -> IO(Int,Int) loop !c !m !pc = do !b <- next_permutation perm n cnt if b == False then return (c,m) else do VM.unsafeCopy tperm perm !flips <- count_flips tperm 0 loop (c + (if pc .&. 1 == 0 then flips else -flips)) (max m flips) (pc+1) r <- loop 0 0 1 return r next_permutation :: VM.IOVector Int -> Int -> VM.IOVector Int-> IO(Bool)next_permutation !perm !n !cnt = do !i <- loop 1 if(i >= n) then return False else do !v <- VM.unsafeRead cnt i VM.unsafeWrite cnt i (v+1) return True where loop :: Int -> IO(Int) loop !i | i < n = do !tmp <- VM.unsafeRead perm 0 let rotate :: Int -> IO() rotate !j = if j >= i then do VM.unsafeWrite perm i tmp return () else do !v <- VM.unsafeRead perm (j+1) VM.unsafeWrite perm j v rotate (j+1) rotate 0 !v <- VM.unsafeRead cnt i if v >= i then do VM.unsafeWrite cnt i 0 loop (i+1) else return i | otherwise = return i count_flips :: VM.IOVector Int -> Int -> IO(Int)count_flips !tperm !flips = do !f <- VM.unsafeRead tperm 0 if f == 1 then return flips else do VG.reverse $ VM.unsafeSlice 0 f tperm count_flips tperm (flips+1)

2 4

Best approach to avoid dependency hells
by Ivan Perez 08 Dec '12

08 Dec '12

Hello everyone, I've spent the last couple of days fighting my way around a dependency hell with my own libraries and packages. If I install them package by package (by hand), I'm very likely to hit one of these conflicts that I'm talking about. A simple example of something that did happen: - Package A depends on bytestring, and is compatible with both 0.9.* and 0.10.* - Package B depends on ghc, which I installed using the package manager and which depends on bytestring 0.9.2 - Package B depends on package A. I do not want to add to the cabal files that B depends on bytestring 0.9.*, because it's not true, or that A depends on bytstring 0.9, because it's also not true. I would like to the best approach to 1) avoid these situations and 2) fix them when they happen. Regarding (2), Is there any way to automatically rebuild all the broken packages? Regarding (1), I thought about using cabal-dev, but I think I'll just have the same problem, won't I? After all, I started from a clean fresh ghc installation and I just installed what I needed to make my program run. I also thought about adding process, bytestring and other global packages to the list of constraints in ~/.cabal/config. Would this be a good approach, or will it lead to bigger headaches in the future (for instance, in the form of programs that just cannot be installed at all)? Also, is there any way to detect potential dependency hells without having to install a package? (Some tool that will analyse the dependency information (statically) and determine more strict or incorrect upper and lower bounds for the dependencies of a package.) Cheers, Ivan

5 7

Safe Haskell safe-inferred status
by Omari Norman 08 Dec '12

08 Dec '12

Is there a way to determine whether a module has been marked safe by GHC for purposes of Safe Haskell? The GHC 7.4 docs say that if I compile a module and I don't use the -XSafe or -XTrustworthy flag, GHC will automatically figure out whether the module would have compiled with -XSafe and, if so, marks the module as safe. Where does GHC record this determination? It doesn't seem to show up in ghc-pkg dump (there you can see trusted packages, but I am looking for safe-inferred status for modules.) ghc --show-iface seems to come up dry too. I know Haddock shows this information but sometimes it says "Safe Haskell: None". I have no idea what this means so I was wondering what GHC itself says. Thanks. --Omari

2 1

Understanding GHC's instance inference.
by Takayuki Muranushi 08 Dec '12

08 Dec '12

Dear everyone, I have a code https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11-… that produces a type-error when I remove a type signature. https://github.com/nushio3/practice/blob/master/instance-inference/zipf-11.… The strange point is the following error message from ghc 7.6.1 (abbreviated; the full error text is included as the comment of the code): No instance for (PType (Cons V.Vector (V.Vector Double) (Cons V.Vector (V.Vector Char) (Cons V.Vector (V.Vector Int) (Nil V.Vector)))) ((Double -> Char -> Int -> String) -> a0)) arising from a use of `forZN' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there is a potential instance available: instance [overlap ok] (Zip v, Reduce v f0 vaS r (Nil v)) => PType (Cons v (v i) vaS) ((i -> f0) -> v r) ghc presents only one potential instance, and it seems to me that by setting v = V.Vector i = Double f0 = Char -> Int -> String r = String etc, you can actually match the 'potential' instance. The fact that this code typechecks with an additional type signature (zipf-11-1.hs) shows that there is a way to satisfy the constraint. So the question: why the instance inference stops here, when there is only one potential instance and no ambiguity? Or is it? What are potential instances? I thought the cause of the error is that ghc cannot match (v r) with (a0), and so I tried to shrink the example before I post. However my guess was wrong. Tinyer example did typecheck: https://github.com/nushio3/practice/blob/master/instance-inference/copy-01.… https://github.com/nushio3/practice/blob/master/instance-inference/copy-02.… https://github.com/nushio3/practice/blob/master/instance-inference/copy-04.… If you have any sample codes that fails to typecheck and presents only one "potential instance" , that will be a great clue for me. Also, please recommend me any reading material for instance inference. (Haskell 98 deals with instance declaration syntax, and there are variety of text for type inference, but I could find few for instance inference.) Best, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

2 2

Maintainer of fixpoint
by Petr P 07 Dec '12

07 Dec '12

Dear Haskellers, I've made some minor improvements of fixpoint package < http://hackage.haskell.org/package/fixpoint>. I tried to contact the original maintainer twice, but without success. The package hasn't been updated for 4 years. How should I proceed? Should I start a new fork of the package? Or is there a way how to take over an orphaned package? Thanks for help, Petr Pudlak

3 3

yaml and aeson Was: Growing Haskell Platform
by Michael Snoyman 07 Dec '12

07 Dec '12

On Fri, Dec 7, 2012 at 10:54 AM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > * Michael Snoyman <michael(a)snoyman.com> [2012-12-07 09:52:07+0200] > > Let me bring up one other package: yaml (written by me). I think it's a > > pretty good fit for the standard YAML packaging library, since it simply > > reuses the existing infrastructure from the aeson package (i.e. the > ToJSON > > and FromJSON typeclasses, and the Value datatype). But I'm actually a bit > > concerned about proposing it, based on some history. > > When I was looking at existing YAML libraries, I rejected yours when I > saw JSON types. (I did see the "do not let that confuse you, it's > intentional" warning, and no, it didn't help.) > > Besides giving the feeling that the API is a hack, this will inevitably > confuse readers of my code who are not familiar with the library and, > just based on the names, will assume that the code is working with JSON, > not YAML. > > If you mean the naming is a hack, I agree. But if we pretend for a moment that the word JSON was actually replaced with YAML everywhere, I think the abstraction is correct. The Value datatype represents a very sane subset of YAML that people usually want to deal with. And if they want to deal with all the glories of aliases and tags, we still have the Text.Libyaml interface which preserves all information. In other words, the hack is in the name, not the abstraction. > IIUC, "all of the existing tools for JSON processing" are mainly just > existing FromJSON instances. I am not sure how common this situation is, > but for that you could define a newtype whose FromYAML instance would > internally use the FromJSON instance of the underlying type. > > It's the two typeclasses and the Value datatype. Don't underestimate the importance of reusing infrastructure here. If we had our own types and classes in YAML, then everyone who wants to include serialization classes in their packages would have to write redundant instances for both packages. Most likely, that would just mean incomplete instances for both packages. It would also mean that we'd have to duplicate libraries like aeson-lens, and duplicate all bugfixes in built-in instances, Generics code, TH code, etc. As a side benefit, the current setup allows code to remain serialization-format-agnostic. For example, Persistent can read configuration from either JSON to YAML files. Since YAML is a superset of JSON, that's not such an amazing statement, but it does mean that users can avoid an extra yaml package dependency if they really are just sticking with JSON data. > Or perhaps the JSON-agnostic subset of aeson could be extracted into a > separate library, which both aeson and yaml would depend on. > > I'd be very much in favor of that. I'm not so irked by the "name hack" to have bothered bringing this up with Bryan, but if he's willing to make that change, I'd certainly be grateful. I actually think it would be more logical for the typeclasses to be called ToValue and FromValue anyway, since that more directly states what they do. > As for toYAML/toJSON, I guess most of the time they are different anyway — > otherwise it's defeating the purpose of YAML to be more human-readable > than JSON. > > I don't think that's true in practice. Most of the readability of YAML comes from the syntax, not the choice of actual serialization structure. But I could be mistaken. Michael

2 2