Re: [Haskell-cafe] Build failure for PortMidi on mac: incorrect Block.h
Hello Brian Possibly you need to supply extra-include-dirs (and extra-lib-dirs) to cabal. It looks like a C header can't be parsed - the Haskell FFI preprocessor will try to compile pmmacosxcm.c by calling out to a C compiler before GHC compiles the Haskell source. Unless the C header is wrong - unlikely in a established library like PortAudio, header files generally fail to parse only when they can't find other headers to include. I'm afraid I can't help on which particular extra-include-dirs you might need as I've never run PortAudio / PortMidi on OSX. On Windows I did find that I needed the latest PartAudio release, I couldn't get previous stable stable versions to compile with MinGW. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Documentation for OpenGL?
Hi everyone. I'm looking for something specific. I'm trying to figure out how to use the depthFunc StateVar and I can't find any official documentation for it. I did a :t depthFunc in ghci and got depthFunc :: StateVar (Maybe ComparisonFunction) so I looked up ComparisonFunction and couldn't find anything official on that either. Is there any documentation for it? Maybe I wasn't looking in the right places? Thanks in advance. -Eitan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Documentation for OpenGL?
Woops, nevermind. I WAS looking in the wrong place. I should've known =P. Sorry for the unnecessary request. -Eitan PS. For anyone interested all of the documentation is in Graphics.Rendering.OpenGL.GL.PerFragment on hackage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: philosophy of Haskell
There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Hi Ertugrul, This state monad model does not really work for IO, since it fails to capture IO's concurrency (with non-deterministic interleaving). I don't know whether/how the EDSL model you mention addresses concurrency or FFI. So, maybe these models are models of something other (and much less expressive) than Haskell's IO. Which re-raises Jerzy's question. Regards, - Conal On Mon, Aug 9, 2010 at 10:38 PM, Ertugrul Soeylemez e...@ertes.de wrote: jerzy.karczmarc...@info.unicaen.fr wrote: Alberto G. Corona writes: (...) Desugarize the do notation, after that, desugarize the = and operators down to the function call notation and suddenly everithing lost its magic because it becomes clear that a haskell monad is a sugarization of plain functional tricks. Yep. But, BTW, could you tell me what was the result of the final desugarization and the BASIC sense of the IO monad for you? Example: do x - getLine print (x+1) print (x+2) There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Another one (the EDSL model, which I personally prefer) would desugar it to something as simple as this: GetLine `BindIO` \x - Print (x+1) `BindIO` const (Print (x+2)) I wonder if there are more models for IO. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] universal quantification is to type instantiations as existential quantification is to what
Dan Doel wrote: On Thursday 12 August 2010 7:59:09 pm wren ng thornton wrote: Not quite. Strong-sigma is a dependent pair where you can project both elements. Weak-sigma is a dependent pair where you can only project the first element (because the second is erased). Existentials are dependent pairs where you can only project the second component (because the first is erased). elim :: (A :: *) - (B :: A - *) - (_ :: Exists A B) - (C :: *) - (_ :: (a :: A) - B a - C) - C Notice how we only get the Church-encoding for existential elimination and how 'a' cannot appear in 'C'. Whereas for 'snd' we explicitly allow 'fst p' to escape. This is how it's usually explained, but note that this eliminator type is not strict enough to guarantee that it's safe to erase the first component. We can still write: [...] So, an existential of this sort still has to carry around its first component, it just doesn't have a strong elimination principle. Right. The point remains that existentials and sigmas differ. Using only 'elim' they differ in not having a strong elimination principle; using other things they differ in erasure properties as well. People seem eager to conflate the notions of existential quantification with strong sigma types, but the fact is that they are different things. Often we use existentials precisely because we want the weaker elimination principle, in order to hide details and bracket off where things can be accessed from. With strong sigmas we can't get those guarantees. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compiled OpenGL program has DOS window?
Hi. I'm working in Windows on an OpenGL application. I finally got everything working, doing all of my testing through the interpreter. When I finally compiled and ran the program from an executable for the first time I noticed that before creating my OpenGL window an empty DOS prompt popped up. I think I understand why the computer would want to do that, but I don't know how to make it stop. I've done some OpenGL in C++ and I remember having a similar problem. If I remember correctly the problem was fixed with a compiler flag. I'm using GHC and I looked through their compiler flags, but I didn't find anything that looked like it would deal with this. Anyone have any ideas? -Eitan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled OpenGL program has DOS window?
I vaguely recall that there is a way to avoid this if you don't import any terminal functions or something similar. I don't remember the specifics though. Sorry I couldn't be of more help! On Fri, Aug 13, 2010 at 4:18 PM, Eitan Goldshtrom thesource...@gmail.com wrote: Hi. I'm working in Windows on an OpenGL application. I finally got everything working, doing all of my testing through the interpreter. When I finally compiled and ran the program from an executable for the first time I noticed that before creating my OpenGL window an empty DOS prompt popped up. I think I understand why the computer would want to do that, but I don't know how to make it stop. I've done some OpenGL in C++ and I remember having a similar problem. If I remember correctly the problem was fixed with a compiler flag. I'm using GHC and I looked through their compiler flags, but I didn't find anything that looked like it would deal with this. Anyone have any ideas? -Eitan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Twidge Short URL not working...
Hello, It's my first time using this mailing list thing so forgive me if I made any mistakes. I was using Twidge (http://wiki.github.com/jgoerzen/twidge/) and it's mentioned there is an available support in the Haskell Cafe. I only have a slight problem with Twidge. It's currently not shortening URLs by default though I can see in my .twidgerc this line shortenurls: yes. Any things I should consider? Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
On 12/08/2010 21:59, Yitzchak Gale wrote: Wei Hu wrote: nonTermination _ = blackhole where blackhole = blackhole My original example was actually: process :: String - String process = let x = x in x Ah yes, that works too. But other similar versions don't, like this one: process :: String - String process _ = let x = x in x Hence why I added the tail in my version. So what happens is this: - the recursive definition causes the main thread to block on itself (known as a black hole) - the program is deadlocked (no threads to run), so the runtime invokes the GC to see if any threads are unreachable - the GC finds that (a) the main thread is unreachable and blocked on a blackhole, so it gets a NonTermination exception (b) the Handle is unreachable, so its finalizer is started - the finalizer runs first, and closes the Handle - the main thread runs next, and the exception handler for writeFile tries to close the Handle, which has already been finalized Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
On 13/08/2010 09:53, Simon Marlow wrote: On 12/08/2010 21:59, Yitzchak Gale wrote: Wei Hu wrote: nonTermination _ = blackhole where blackhole = blackhole My original example was actually: process :: String - String process = let x = x in x Ah yes, that works too. But other similar versions don't, like this one: process :: String - String process _ = let x = x in x Hence why I added the tail in my version. So what happens is this: - the recursive definition causes the main thread to block on itself (known as a black hole) - the program is deadlocked (no threads to run), so the runtime invokes the GC to see if any threads are unreachable - the GC finds that (a) the main thread is unreachable and blocked on a blackhole, so it gets a NonTermination exception (b) the Handle is unreachable, so its finalizer is started - the finalizer runs first, and closes the Handle - the main thread runs next, and the exception handler for writeFile tries to close the Handle, which has already been finalized Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. One other thing: this has nothing to do with lazy IO, the readFile is a red herring, you can get the same result without it. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled OpenGL program has DOS window?
On Fri, 13 Aug 2010 10:18:22 +0200, Eitan Goldshtrom thesource...@gmail.com wrote: Hi. I'm working in Windows on an OpenGL application. I finally got everything working, doing all of my testing through the interpreter. When I finally compiled and ran the program from an executable for the first time I noticed that before creating my OpenGL window an empty DOS prompt popped up. I think I understand why the computer would want to do that, but I don't know how to make it stop. I've done some OpenGL in C++ and I remember having a similar problem. If I remember correctly the problem was fixed with a compiler flag. I'm using GHC and I looked through their compiler flags, but I didn't find anything that looked like it would deal with this. Anyone have any ideas? -Eitan You can do this with the flag -optl-mwindows; this passes the flag -mwindows to the linker. Because this is a linker option, you cannot find it in the GHC documentation. This solution also works for other GUIs, like wxHaskell. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Compiled OpenGL program has DOS window?
Hello Henk-Jan, Friday, August 13, 2010, 2:23:58 PM, you wrote: You can do this with the flag -optl-mwindows; this passes the flag -mwindows to the linker. Because this is a linker option, you cannot find it in the GHC documentation. This solution also works for other GUIs, like wxHaskell. it may be added to some GHC FAQ though -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] String vs ByteString
Hi all, I'm using Tagsoup to strip data out of some rather large XML files. Since the files are large I'm using ByteString, but that leads me to wonder what is the best way to handle clashes between Prelude functions like putStrLn and the ByteString versions? Anyone have any suggestions for doing this as neatly as possible? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String vs ByteString
Just import the ByteString module qualified. In other words: import qualified Data.ByteString as S or for lazy bytestrings: import qualified Data.ByteString.Lazy as L Cheers, Michael On Fri, Aug 13, 2010 at 2:32 PM, Erik de Castro Lopo mle...@mega-nerd.commle%2...@mega-nerd.com wrote: Hi all, I'm using Tagsoup to strip data out of some rather large XML files. Since the files are large I'm using ByteString, but that leads me to wonder what is the best way to handle clashes between Prelude functions like putStrLn and the ByteString versions? Anyone have any suggestions for doing this as neatly as possible? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String vs ByteString
Hi Erik, On Fri, Aug 13, 2010 at 1:32 PM, Erik de Castro Lopo mle...@mega-nerd.commle%2...@mega-nerd.com wrote: Since the files are large I'm using ByteString, but that leads me to wonder what is the best way to handle clashes between Prelude functions like putStrLn and the ByteString versions? Anyone have any suggestions for doing this as neatly as possible? Use qualified imports, like so: import qualified Data.ByteString as B main = B.putStrLn $ B.pack test Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String vs ByteString
On Fri, Aug 13, 2010 at 2:42 PM, Johan Tibell johan.tib...@gmail.comwrote: Hi Erik, On Fri, Aug 13, 2010 at 1:32 PM, Erik de Castro Lopo mle...@mega-nerd.commle%2...@mega-nerd.com wrote: Since the files are large I'm using ByteString, but that leads me to wonder what is the best way to handle clashes between Prelude functions like putStrLn and the ByteString versions? Anyone have any suggestions for doing this as neatly as possible? Use qualified imports, like so: import qualified Data.ByteString as B main = B.putStrLn $ B.pack test If you want to pack a String into a ByteString, you'll need to import Data.ByteString.Char8 instead. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String vs ByteString
On Fri, Aug 13, 2010 at 1:47 PM, Michael Snoyman mich...@snoyman.comwrote: Use qualified imports, like so: import qualified Data.ByteString as B main = B.putStrLn $ B.pack test If you want to pack a String into a ByteString, you'll need to import Data.ByteString.Char8 instead. Very true. That's what I get for using a random example without testing it first. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hswip-0.3 embedding swi-prolog in haskell
I would like to announce a small library hswip. It is an analogue of pyswip [1] python library in haskell. Hswip allows to embed swi-prolog [2] interpreter into your haskell applications in a convenient way. Let't look at an example: main = do prologInit [-q,-nosignals] prologCall asserta(a(b,c)). prologCall asserta(parent(pam, bob)). prologCall asserta(parent(tom, bob)). prologCall asserta(parent(tom, liz)). prologCall asserta(parent(bob, ann)). prologCall asserta(parent(bob, pat)). prologCall asserta(parent(pat, jim)). res - prologCall parent(X,Y). print res Output: [[(X,pat),(Y,jim)],[(X,bob),(Y,pat)],[(X,bob),(Y,ann)],[(X,tom),(Y,liz)],[(X,tom),(Y,bob)],[(X,pam),(Y,bob)]] The library still has alpha quality and there are many things missing including exception handling and BSD license. Any feedback is welcome! -Evgeny Tarasov [1] http://code.google.com/p/pyswip/ [2] http://www.swi-prolog.org/ [3] http://hackage.haskell.org/package/hswip-0.3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Build failure for PortMidi on mac: incorrect Block.h
Stephen Tetley wrote: Possibly you need to supply extra-include-dirs (and extra-lib-dirs) to cabal. I tried --extra-include-dirs=/usr/include (the directory where the real Block.h resides) and there was no change. Adding the -v flag showed cabal trying to build with this line: /usr/bin/ghc -Iportmidi/pm_common -Iportmidi/pm_mac -Iportmidi/porttime -I/usr/include -package base-3.0.3.1 -optc-msse2 -optc-O2 -odir dist/build -c portmidi/pm_mac/pmmacosxcm.c Since it still picked up the GHC Block.h instead of /usr/include/Block.h, it seems as though ghc searches its own headers before those specified with -I. I suspect if I had a way to change that, it would work. -- Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String vs ByteString
Hi, Why don't you use the Data.Rope library ? The asymptotic complexities are way better than those of the ByteString functions. PE El 13/08/2010, a las 07:32, Erik de Castro Lopo escribió: Hi all, I'm using Tagsoup to strip data out of some rather large XML files. Since the files are large I'm using ByteString, but that leads me to wonder what is the best way to handle clashes between Prelude functions like putStrLn and the ByteString versions? Anyone have any suggestions for doing this as neatly as possible? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String vs ByteString
On Fri, Aug 13, 2010 at 4:03 PM, Pierre-Etienne Meunier pierreetienne.meun...@gmail.com wrote: Hi, Why don't you use the Data.Rope library ? The asymptotic complexities are way better than those of the ByteString functions. PE For some operations. I'd expect it to be a constant factor slower on average though. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String vs ByteString
I'm interested to see this kind of open debate on performance, especially about libraries that provide widely used data structures such as strings. One of the more puzzling aspects of Haskell for newbies is the large number of libraries that appear to provide similar/duplicate functionality. The Haskell Platform deals with this to some extent, but it seems to me that if there are new libraries that appear to provide performance boosts over more widely used libraries, it would be best if the new code gets incorporated into the existing more widely used libraries rather than creating more code to maintain / choose from. I think that open debate about performance trade-offs could help consolidate the libraries. Kevin On Aug 13, 4:08 pm, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Aug 13, 2010 at 4:03 PM, Pierre-Etienne Meunier pierreetienne.meun...@gmail.com wrote: Hi, Why don't you use the Data.Rope library ? The asymptotic complexities are way better than those of the ByteString functions. PE For some operations. I'd expect it to be a constant factor slower on average though. -- Johan ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Beautiful Differentiation using VectorSpace
Hi all, I'm trying to go through the paper Beautiful Differentiation by Conal Elliott and got a bit stuck. So I decided to download the VectorSpace package, which as far as I know implements the paper, and just try and play around with it. Unfortunately when I tried the simple examples at the beginning of the paper I got an error: Prelude Data.VectorSpace :m Data.Derivative Prelude Data.Derivative let f1 z = sqrt(3*sin z) Prelude Data.Derivative f1 (D 2 1) Top level: Couldn't match expected type `Data.VectorSpace.Scalar a' against inferred type `Data.VectorSpace.Scalar (Data.VectorSpace.Scalar a)' NB: `Data.VectorSpace.Scalar' is a type function, and may not be injective interactive:1:0: No instances for (Data.MemoTrie.HasTrie (Data.Basis.Basis a), Floating (Data.VectorSpace.Scalar a), Data.VectorSpace.VectorSpace (Data.VectorSpace.Scalar a)) arising from a use of `f1' at interactive:1:0-9 Possible fix: add an instance declaration for (Data.MemoTrie.HasTrie (Data.Basis.Basis a), Floating (Data.VectorSpace.Scalar a), Data.VectorSpace.VectorSpace (Data.VectorSpace.Scalar a)) In the expression: f1 (D 2 1) In the definition of `it': it = f1 (D 2 1) interactive:1:8: No instance for (Num (a Data.LinearMap.:-* (a : Data.VectorSpace.Scalar a))) arising from the literal `1' at interactive:1:8 Possible fix: add an instance declaration for (Num (a Data.LinearMap.:-* (a : Data.VectorSpace.Scalar a))) In the second argument of `D', namely `1' In the first argument of `f1', namely `(D 2 1)' In the expression: f1 (D 2 1) Which was completely incomprehensible to me. I tried looking at the documentation but I couldn't find anything about actually using the library. Does anyone have any experience using this library and maybe have some examples of it's use? Thanks Chris Witte ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Compiled OpenGL program has DOS window?
On Fri, 13 Aug 2010 12:29:52 +0200, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Henk-Jan, Friday, August 13, 2010, 2:23:58 PM, you wrote: You can do this with the flag -optl-mwindows; this passes the flag -mwindows to the linker. Because this is a linker option, you cannot find it in the GHC documentation. This solution also works for other GUIs, like wxHaskell. it may be added to some GHC FAQ though I have added it to the HaskellWiki page GHC/FAQ [0] Regards, Henk-Jan van Tuyl [0] http://www.haskell.org/haskellwiki/GHC/FAQ#A_DOS_shell_opens_when_my_program_opens_a_window -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 4:24 PM, Kevin Jardine kevinjard...@gmail.comwrote: I'm interested to see this kind of open debate on performance, especially about libraries that provide widely used data structures such as strings. One of the more puzzling aspects of Haskell for newbies is the large number of libraries that appear to provide similar/duplicate functionality. The Haskell Platform deals with this to some extent, but it seems to me that if there are new libraries that appear to provide performance boosts over more widely used libraries, it would be best if the new code gets incorporated into the existing more widely used libraries rather than creating more code to maintain / choose from. I think that open debate about performance trade-offs could help consolidate the libraries. Kevin I agree. Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. Those libraries have benchmarks and have been well tuned by experienced Haskelleres and should be the fastest and most memory compact in most cases. There are still a few cases where String beats Text but they are being worked on as we speak. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal, haddock, hscolour
How is the cabal magic that would run hscolour? I am using cabal haddock --executables --hyperlink-source and this generates the API docs for all modules, and all have source links, but the actual html-ized source is only generated for the main module, and missing for all others. Thanks - J.W. cabal --version cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library haddock --version Haddock version 2.7.2, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 HsColour --version HsColour 1.17 ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 4:43 PM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Aug 13, 2010 at 4:24 PM, Kevin Jardine kevinjard...@gmail.com wrote: I'm interested to see this kind of open debate on performance, especially about libraries that provide widely used data structures such as strings. One of the more puzzling aspects of Haskell for newbies is the large number of libraries that appear to provide similar/duplicate functionality. The Haskell Platform deals with this to some extent, but it seems to me that if there are new libraries that appear to provide performance boosts over more widely used libraries, it would be best if the new code gets incorporated into the existing more widely used libraries rather than creating more code to maintain / choose from. I think that open debate about performance trade-offs could help consolidate the libraries. Kevin I agree. Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. Those libraries have benchmarks and have been well tuned by experienced Haskelleres and should be the fastest and most memory compact in most cases. There are still a few cases where String beats Text but they are being worked on as we speak. How about the case for text which is guaranteed to be in ascii/latin1? ByteString again? Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Johan Tibell wrote: Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. Those libraries have benchmarks and have been well tuned by experienced Haskelleres and should be the fastest and most memory compact in most cases. There are still a few cases where String beats Text but they are being worked on as we speak. Which one do you use for strings in HTML or XML in which UTF-8 has become the commonly accepted standard encoding? It's text, not binary, so I should choose Data.Text. But isn't there a performance penalty for translating from Data.Text's internal 16-bit encoding to UTF-8? http://tools.ietf.org/html/rfc3629 http://www.utf8.com/ Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Friday 13 August 2010 17:25:58, Gábor Lehel wrote: How about the case for text which is guaranteed to be in ascii/latin1? ByteString again? If you can be sure that that won't change anytime soon, definitely. Bonus points if you can write the code so that later changing to e.g. Data.Text requires only a change of imports. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Friday 13 August 2010 17:27:32, Sean Leather wrote: Which one do you use for strings in HTML or XML in which UTF-8 has become the commonly accepted standard encoding? It's text, not binary, so I should choose Data.Text. But isn't there a performance penalty for translating from Data.Text's internal 16-bit encoding to UTF-8? Yes there is. Whether using String, Data.Text or Data.ByteString + Data.ByteString.UTF8 is the best choice depends on what you do. Test and then decide. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
2010/8/13 Gábor Lehel illiss...@gmail.com How about the case for text which is guaranteed to be in ascii/latin1? ByteString again? If you know it's text and not binary data you are working with, you should still use Data.Text. There are a few good reasons. 1. The API is more correct. For instance, if you use Text.toUpper on a string containing latin1 ß (eszett, sharp S), you'll get the two-character sequence SS, which is correct. Using Char8.map Char.toUpper here gives the wrong answer. 2. In many cases, the API is easier to use, because it's oriented towards using text data, instead of being a port of the list API. 3. Some commonly used functions, such as substring searching, are *way*faster than their ByteString counterparts. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Quoth Sean Leather leat...@cs.uu.nl, Which one do you use for strings in HTML or XML in which UTF-8 has become the commonly accepted standard encoding? It's text, not binary, so I should choose Data.Text. But isn't there a performance penalty for translating from Data.Text's internal 16-bit encoding to UTF-8? Use both? I am not familiar with Text, but UTF-8 is pretty awkward, and I will sure look into Text before wasting any time trying to fine-tune my ByteString handling for UTF-8. But in practice only a fraction of my data input will be manipulated in an encoding-sensitive context. I'm thinking _all_ data is binary, and accordingly all inputs are ByteString; conversion to Text will happen as needed for ... uh, wait, is there a conversion from ByteString to Text? Well, if not, no doubt that's coming. Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
Simon Marlow wrote: So what happens is this: - the recursive definition causes the main thread to block on itself (known as a black hole) - the program is deadlocked (no threads to run), so the runtime invokes the GC to see if any threads are unreachable - the GC finds that (a) the main thread is unreachable and blocked on a blackhole, so it gets a NonTermination exception (b) the Handle is unreachable, so its finalizer is started - the finalizer runs first, and closes the Handle - the main thread runs next, and the exception handler for writeFile tries to close the Handle, which has already been finalized Why is the Handle found unreachable? There seems to be a pointer to the Handle somewhere, which is later passed to the exception handler and used there. Why is that pointer not regarded by GC? Is that situation Handle-specific, or could step (b) above free memory the exception handler is going to acess? Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. That sounds like a work-around to me, not a fix, because it would not fix more complicated exception handlers. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
2010/8/13 Bryan O'Sullivan b...@serpentine.com 2010/8/13 Gábor Lehel illiss...@gmail.com How about the case for text which is guaranteed to be in ascii/latin1? ByteString again? If you know it's text and not binary data you are working with, you should still use Data.Text. There are a few good reasons. 1. The API is more correct. For instance, if you use Text.toUpper on a string containing latin1 ß (eszett, sharp S), you'll get the two-character sequence SS, which is correct. Using Char8.map Char.toUpper here gives the wrong answer. 2. In many cases, the API is easier to use, because it's oriented towards using text data, instead of being a port of the list API. 3. Some commonly used functions, such as substring searching, are *way*faster than their ByteString counterparts. These are all good reasons. An even more important reason is type safety: A function that receives a Text argument has the guaranteed that the input is valid Unicode. A function that receives a ByteString doesn't have that guarantee and if validity is important the function must perform a validity check before operating on the data. If the function does not validate the input the function might crash or, even worse, write invalid data to disk or some other data store, corrupting the application data. This is a bit of a subtle point that you really only see once systems get large. Even though you might pay for the conversion from ByteString to Text you might make up for that by avoiding several validity checks down the road. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Friday 13 August 2010 17:57:36, Bryan O'Sullivan wrote: 3. Some commonly used functions, such as substring searching, are *way*faster than their ByteString counterparts. That's an unfortunate example. Using the stringsearch package, substring searching in ByteStrings was considerably faster than in Data.Text in my tests. Replacing substrings blew Data.Text to pieces even, with a factor of 10-65 between ByteString and Text (and much smaller memory footprint). stringsearch (Data.ByteString.Lazy.Search): $ ./bmLazy +RTS -s -RTS ../../bigfile Gutenberg Hutzenzwerg /dev/null ./bmLazy ../../bigfile Gutenberg Hutzenzwerg +RTS -s 92,045,816 bytes allocated in the heap 31,908 bytes copied during GC 103,368 bytes maximum residency (1 sample(s)) 39,992 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 158 collections, 0 parallel, 0.01s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time0.00s ( 0.00s elapsed) MUT time0.07s ( 0.17s elapsed) GCtime0.01s ( 0.00s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time0.08s ( 0.17s elapsed) %GC time 10.5% (2.1% elapsed) Alloc rate1,353,535,321 bytes per MUT second Productivity 89.5% of total user, 40.1% of total elapsed Data.Text.Lazy: $ ./textLazy +RTS -s -RTS ../../bigfile Gutenberg Hutzenzwerg /dev/null ./textLazy ../../bigfile Gutenberg Hutzenzwerg +RTS -s 4,916,133,652 bytes allocated in the heap 6,721,496 bytes copied during GC 12,961,776 bytes maximum residency (58 sample(s)) 12,788,968 bytes maximum slop 39 MB total memory in use (1 MB lost due to fragmentation) Generation 0: 8774 collections, 0 parallel, 0.70s, 0.73s elapsed Generation 1:58 collections, 0 parallel, 0.03s, 0.03s elapsed INIT time0.00s ( 0.00s elapsed) MUT time9.87s ( 10.23s elapsed) GCtime0.73s ( 0.75s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 10.60s ( 10.99s elapsed) %GC time 6.9% (6.9% elapsed) Alloc rate497,956,181 bytes per MUT second bigfile is a ~75M file. The point of the more adequate API for text manipulation stands, of course. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer daniel.is.fisc...@web.dewrote: That's an unfortunate example. Using the stringsearch package, substring searching in ByteStrings was considerably faster than in Data.Text in my tests. Interesting. Got a test case so I can repro and fix? :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
On Fri, Aug 13, 2010 at 4:53 AM, Simon Marlow marlo...@gmail.com wrote: Ah yes, that works too. But other similar versions don't, like this one: process :: String - String process _ = let x = x in x Hence why I added the tail in my version. Without -O, this version doesn't work, but with -O it does. Why? So what happens is this: - the recursive definition causes the main thread to block on itself (known as a black hole) - the program is deadlocked (no threads to run), so the runtime invokes the GC to see if any threads are unreachable - the GC finds that (a) the main thread is unreachable and blocked on a blackhole, so it gets a NonTermination exception (b) the Handle is unreachable, so its finalizer is started - the finalizer runs first, and closes the Handle - the main thread runs next, and the exception handler for writeFile tries to close the Handle, which has already been finalized Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String vs ByteString
This back and forth on performance is great! I often see ByteString used where Text is theoretically more appropriate (eg. the Snap web framework) and it would be good to get these performance issues ironed out so people feel more comfortable using the right tool for the job based upon API rather than performance. Many other languages have two major formats for strings (binary and text) and it would be great if performance improvements for ByteString and Text allowed the same kind of convergence for Haskell. Kevin On Aug 13, 7:53 pm, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer daniel.is.fisc...@web.dewrote: That's an unfortunate example. Using the stringsearch package, substring searching in ByteStrings was considerably faster than in Data.Text in my tests. Interesting. Got a test case so I can repro and fix? :-) ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] gtk2hs with old gtk2
I'm trying to build gtk2hs on debian/lenny, that is, with gtk2 v. 2.12 if I understand this correctly. I got the gtk2hs sources from darcs (I guess it's 0.11.0) and http://www.haskell.org/gtk2hs/ says You need to specify -f-gtk_2_20 for Gtk+ 2.18 etc. I would love to, but where exactly? (When bootstrap.sh) Thanks - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: gtk2hs with old gtk2
Johannes Waldmann waldm...@imn.htwk-leipzig.de writes: I'm trying to build gtk2hs on debian/lenny, that is, with gtk2 v. 2.12 if I understand this correctly. I got the gtk2hs sources from darcs (I guess it's 0.11.0) and http://www.haskell.org/gtk2hs/ says You need to specify -f-gtk_2_20 for Gtk+ 2.18 etc. I would love to, but where exactly? (When bootstrap.sh) Infact, you don't need that. Just cabal install is enough. Flags gtk_version just use when first cabalized gtk2hs test-version relased, now gtk2hs can choose right gtk version automatically. Cheers, -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Friday 13 August 2010 19:53:37, Bryan O'Sullivan wrote:
On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer
daniel.is.fisc...@web.dewrote:
That's an unfortunate example. Using the stringsearch package,
substring searching in ByteStrings was considerably faster than in
Data.Text in my tests.
Interesting. Got a test case so I can repro and fix? :-)
Sure, use http://norvig.com/big.txt (~6.2M), cat it together a few times to
test on larger files.
ByteString code (bmLazy.hs):
{-# LANGUAGE BangPatterns #-}
module Main (main) where
import System.Environment (getArgs)
import qualified Data.ByteString.Char8 as C
import qualified Data.ByteString.Lazy as L
import Data.ByteString.Lazy.Search
main :: IO ()
main = do
(file : pat : _) - getArgs
let !spat = C.pack pat
work = indices spat
L.readFile file = print . length . work
Data.Text.Lazy (textLazy.hs):
{-# LANGUAGE BangPatterns #-}
module Main (main) where
import System.Environment (getArgs)
import qualified Data.Text.Lazy as T
import qualified Data.Text.Lazy.IO as TIO
import Data.Text.Lazy.Search
main :: IO ()
main = do
(file : pat : _) - getArgs
let !spat = T.pack pat
work = indices spat
TIO.readFile file = print . length . work
(Data.Text.Lazy.Search is of course not exposed by default ;), I use
text-0.7.2.1)
Some local timings:
1. real words in a real text file:
$ time ./textLazy big.txt the
92805
0.59user 0.00system 0:00.61elapsed 97%CPU
$ time ./bmLazy big.txt the92805
0.02user 0.01system 0:00.04elapsed 104%CPU
$ time ./textLazy big.txt and
43587
0.56user 0.01system 0:00.58elapsed 100%CPU
$ time ./bmLazy big.txt and
43587
0.02user 0.01system 0:00.03elapsed 88%CPU
$ time ./textLazy big.txt mother
317
0.44user 0.01system 0:00.46elapsed 99%CPU
$ time ./bmLazy big.txt mother
317
0.00user 0.01system 0:00.02elapsed 69%CPU
$ time ./textLazy big.txt deteriorate
2
0.37user 0.00system 0:00.38elapsed 98%CPU
$ time ./bmLazy big.txt deteriorate
2
0.01user 0.01system 0:00.02elapsed 114%CPU
$ time ./textLazy big.txt Project Gutenberg
177
0.37user 0.00system 0:00.38elapsed 97%CPU
$ time ./bmLazy big.txt Project Gutenberg
177
0.00user 0.01system 0:00.01elapsed 100%CPU
2. periodic pattern in a file of 33.4M of a:
$ time ./bmLazy ../AAA
aaa
3442
1.22user 0.04system 0:01.30elapsed 97%CPU
$ time ./textLazy ../AAA
aaa
593220
3.07user 0.03system 0:03.14elapsed 98%CPU
Oh, that's closer, but text doesn't find overlapping matches, well, we can
do that too (replace indices with nonOverlappingIndices):
$ time ./noBMLazy ../AAA
aaa
593220
0.18user 0.04system 0:00.23elapsed 97%CPU
Yeah, that's more like it :D
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: gtk2hs with old gtk2
Andy Stewart lazycat.manatee at gmail.com writes: Just cabal install is enough. Hm. That's what bootstrap.sh does, and it builds tools, then glib, but then: Preprocessing library gio-0.11.0... gtk2hsC2hs: Errors during expansion of binding hooks: ./System/GIO/Types.chs:584: (column 12) [ERROR] Unknown identifier! Cannot find a definition for `Emblem' in the header file. (and then some more) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Friday 13 August 2010 19:53:37 you wrote: On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer daniel.is.fisc...@web.dewrote: That's an unfortunate example. Using the stringsearch package, substring searching in ByteStrings was considerably faster than in Data.Text in my tests. Interesting. Got a test case so I can repro and fix? :-) Just occurred to me, a lot of the difference is due to the fact that text has to convert a ByteString to Text on reading the file, so I timed that by reading the file and counting the chunks, that took text 0.21s for big.txt vs. Data.ByteString.Lazy's 0.01s. So for searching in-memory strings, subtract about 0.032s/MB from the difference - it's still large. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String vs ByteString
Surely a lot of real world text processing programs are IO intensive? So if there is no native Text IO and everything needs to be read in / written out as ByteString data converted to/from Text this strikes me as a major performance sink. Or is there native Text IO but just not in your example? Kevin On Aug 13, 8:57 pm, Daniel Fischer daniel.is.fisc...@web.de wrote: Just occurred to me, a lot of the difference is due to the fact that text has to convert a ByteString to Text on reading the file, so I timed that by reading the file and counting the chunks, that took text 0.21s for big.txt vs. Data.ByteString.Lazy's 0.01s. So for searching in-memory strings, subtract about 0.032s/MB from the difference - it's still large. ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Friday 13 August 2010 21:32:12, Kevin Jardine wrote: Surely a lot of real world text processing programs are IO intensive? So if there is no native Text IO and everything needs to be read in / written out as ByteString data converted to/from Text this strikes me as a major performance sink. Or is there native Text IO but just not in your example? Outdated information, sorry. Up to ghc-6.10, text's IO was via ByteString, it's no longer so. However, the native Text IO is (of course) much slower than ByteString IO due to the need of en/decoding. Kevin On Aug 13, 8:57 pm, Daniel Fischer daniel.is.fisc...@web.de wrote: Just occurred to me, a lot of the difference is due to the fact that text has to convert a ByteString to Text on reading the file, so I timed that by reading the file and counting the chunks, that took text 0.21s for big.txt vs. Data.ByteString.Lazy's 0.01s. So for searching in-memory strings, subtract about 0.032s/MB from the difference - it's still large. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Johan Tibell johan.tib...@gmail.com writes: Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. If you have a large amount of mostly ASCII text, use ByteString, since Data.Text uses twice the storage. Also, ByteString might make more sense if the data is in a byte-oriented encoding, and the cost of encoding and decoding utf-16 would be significant. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String vs ByteString
I find it disturbing that a modern programming language like Haskell still apparently forces you to choose between a representation for mostly ASCII text and Unicode. Surely efficient Unicode text should always be the default? And if the Unicode format used by the Text library is not efficient enough then can't that be fixed? Cheers, Kevin On Aug 13, 10:28 pm, Ketil Malde ke...@malde.org wrote: Johan Tibell johan.tib...@gmail.com writes: Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. If you have a large amount of mostly ASCII text, use ByteString, since Data.Text uses twice the storage. Also, ByteString might make more sense if the data is in a byte-oriented encoding, and the cost of encoding and decoding utf-16 would be significant. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
There are many libraries for many purposes. How to pick your string library in Haskell http://blog.ezyang.com/2010/08/strings-in-haskell/ kevinjardine: I find it disturbing that a modern programming language like Haskell still apparently forces you to choose between a representation for mostly ASCII text and Unicode. Surely efficient Unicode text should always be the default? And if the Unicode format used by the Text library is not efficient enough then can't that be fixed? Cheers, Kevin On Aug 13, 10:28 pm, Ketil Malde ke...@malde.org wrote: Johan Tibell johan.tib...@gmail.com writes: Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. If you have a large amount of mostly ASCII text, use ByteString, since Data.Text uses twice the storage. Also, ByteString might make more sense if the data is in a byte-oriented encoding, and the cost of encoding and decoding utf-16 would be significant. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Excerpts from Kevin Jardine's message of Fri Aug 13 16:37:14 -0400 2010: I find it disturbing that a modern programming language like Haskell still apparently forces you to choose between a representation for mostly ASCII text and Unicode. Surely efficient Unicode text should always be the default? And if the Unicode format used by the Text library is not efficient enough then can't that be fixed? For what it's worth, Java uses UTF-16 representation internally for strings, and thus also wastes space. There is something to be said for UTF-8 in-memory representation, but it takes a lot of care. A newtype for dirty and clean UTF-8 may come in handy. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String vs ByteString
Hi Don, With respect, I disagree with that approach. Almost every modern programming language has one or at most two standard representations for strings. That includes PHP, Python, Ruby, Perl and many others. The lack of a standard text representation in Haskell has created a crazy patchwork of incompatible libraries requiring explicit and often inefficient conversions to connect them together. I expect Haskell to be higher level than those other languages so that I can ignore the lower level details and focus on the algorithms. But in fact the string issue forces me to deal with lower level details than even PHP requires. I end up with a program littered with ugly pack, unpack, toString, fromString and similar calls. That just doesn't feel right to me. Kevin On Aug 13, 10:39 pm, Don Stewart d...@galois.com wrote: There are many libraries for many purposes. How to pick your string library in Haskell http://blog.ezyang.com/2010/08/strings-in-haskell/ kevinjardine: I find it disturbing that a modern programming language like Haskell still apparently forces you to choose between a representation for mostly ASCII text and Unicode. Surely efficient Unicode text should always be the default? And if the Unicode format used by the Text library is not efficient enough then can't that be fixed? Cheers, Kevin On Aug 13, 10:28�pm, Ketil Malde ke...@malde.org wrote: Johan Tibell johan.tib...@gmail.com writes: Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. If you have a large amount of mostly ASCII text, use ByteString, since Data.Text uses twice the storage. �Also, ByteString might make more sense if the data is in a byte-oriented encoding, and the cost of encoding and decoding utf-16 would be significant. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Kevin Jardine kevinjard...@gmail.com writes: Almost every modern programming language has one or at most two standard representations for strings. That includes PHP, Python, Ruby, Perl and many others. The lack of a standard text representation in Haskell has created a crazy patchwork of incompatible libraries requiring explicit and often inefficient conversions to connect them together. Haskell does have a standard representation for strings, namely [Char]. Unfortunately, this sacrifices efficiency for elegance, which gives rise to the plethora of libraries. I end up with a program littered with ugly pack, unpack, toString, fromString and similar calls. Some of this can be avoided using a language extension that let you overload string constants. There are always trade offs, and no one solution will fit all: UTF-8 is space efficient while UTF-16 is time efficient (at least for certain classes of problems and data). It does seem that it should be possible to unify the various libraries wrapping bytestrings (CompactString, ByteString.UTF8 etc), however. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MOF and functional language paradigm
Hello, In my company (and I believe many, many companies) they use MOF heavily: http://en.wikipedia.org/wiki/Meta-Object_Facility MOF seems to be tightly coupled with object oriented program and has nothing to do with functional language approach?? Regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] putStrLn ß
L.S., When I try putStrLn ß (Eszett (sharp S)) in WinGhci, the interpreter seems to have disappeared; ctrl-C gives the message Interrupted in a separate window, but no new prompt. When I start GHCi in a shell, the interpreter displays: Prelude print ß \223 Is this a known issue? Other experiments with WinGhci: print αγδ a?d (Trying to print alpha, gamma, delta.) print β (Trying to print beta) interpreter hangs again. Details: - WinGhci 1.0.2 - GHCi, version 6.12.3 - Windows XP Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String vs ByteString
Pierre-Etienne Meunier wrote: Hi, Why don't you use the Data.Rope library ? The asymptotic complexities are way better than those of the ByteString functions. What I see as my current problem is that there is already a problem having two things Sting and ByteString which represent strings. Add Text and Data.Rope makes that problem worse, not better. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Kevin Jardine wrote: With respect, I disagree with that approach. Almost every modern programming language has one or at most two standard representations for strings. I think having two makes sense, one for arrays of arbitrary binary bytes and one for some unicode data format, preferably UTF-8. That includes PHP, Python, Ruby, Perl and many others. The lack of a standard text representation in Haskell has created a crazy patchwork of incompatible libraries requiring explicit and often inefficient conversions to connect them together. I expect Haskell to be higher level than those other languages so that I can ignore the lower level details and focus on the algorithms. But in fact the string issue forces me to deal with lower level details than even PHP requires. I end up with a program littered with ugly pack, unpack, toString, fromString and similar calls. That just doesn't feel right to me. That is what I was trying to say whenI started this thread. Thank you. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Ketil Malde wrote: Haskell does have a standard representation for strings, namely [Char]. Unfortunately, this sacrifices efficiency for elegance, which gives rise to the plethora of libraries. To have the default standard representation be one that works so poorly for many common everyday tasks such as mangling large chunks of XML is a large part of the problem. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Trying to compile Glade Gtk2Hs demo / cabal install glade problem
Thanks so very much Axel and Ivan. You were both absolutely correct and I can compile Glade apps now fine. Great help! The tricky part (for me) would have been looking at the error from cabal install glade: setup.exe: The pkg-config package libglade-2.0 version =2.0.0 is required but it could not be found. and determining that the problem was that libglade-2.0.pc needed the edit you described, but I made the edit and it all works now. -- Peter And I guess I don't need these edits to cabal/config after all: -- -- extra-include-dirs: -- extra-lib-dirs: extra-include-dirs: H:\proc\tools\Gtk+\include extra-lib-dirs: H:\proc\tools\Gtk+\lib -- New cabal install glade after libglade-2.0.pc edit: H:\proc\dev\cmdpkg-config --modversion libglade-2.0 2.6.4 H:\proc\dev\cmdcabal install glade Resolving dependencies... C:\DOCUME~1\pschmitz\LOCALS~1\Temp\glade-0.11.12236\glade-0.11.1\Gtk2HsSetup.hs:25: warning: #warning Setup.hs is guessing the version of Cabal. If compilation of Setup.hs fails use -DCABAL_VERSION_MINOR=x for Cabal version 1.x.0 when building (prefixed by --ghc-option= when using the 'cabal' command) [1 of 2] Compiling Gtk2HsSetup ( C:\DOCUME~1\pschmitz\LOCALS~1\Temp\glade-0.11.12236\glade-0.11.1\Gtk2HsSetup.hs, C:\DOCUME~1\pschmitz\LOCALS~1\Temp\glade-0.11.12236\glade-0.11.1\dist\setup\Gtk2HsSetup.o ) [2 of 2] Compiling Main ( C:\DOCUME~1\pschmitz\LOCALS~1\Temp\glade-0.11.12236\glade-0.11.1\Setup.hs, C:\DOCUME~1\pschmitz\LOCALS~1\Temp\glade-0.11.12236\glade-0.11.1\dist\setup\Main.o ) Linking C:\DOCUME~1\pschmitz\LOCALS~1\Temp\glade-0.11.12236\glade-0.11.1\dist\setup\setup.exe ... Configuring glade-0.11.1... Preprocessing library glade-0.11.1... Building glade-0.11.1... [1 of 2] Compiling Graphics.UI.Gtk.Glade.Types ( dist\build\Graphics\UI\Gtk\Glade\Types.hs, dist\build\Graphics\UI\Gtk\Glade\Types.o ) [2 of 2] Compiling Graphics.UI.Gtk.Glade ( dist\build\Graphics\UI\Gtk\Glade.hs, dist\build\Graphics\UI\Gtk\Glade.o ) Registering glade-0.11.1... Installing library in H:\proc\tools\cabal\glade-0.11.1\ghc-6.12.1 Registering glade-0.11.1... H:\proc\dev\cmd ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Kevin Jardine kevinjard...@gmail.com writes: Hi Don, With respect, I disagree with that approach. Almost every modern programming language has one or at most two standard representations for strings. Almost every modern programming language thinks you can whack a print statement wherever you like... ;-) That includes PHP, Python, Ruby, Perl and many others. The lack of a standard text representation in Haskell has created a crazy patchwork of incompatible libraries requiring explicit and often inefficient conversions to connect them together. I expect Haskell to be higher level than those other languages so that I can ignore the lower level details and focus on the algorithms. But in fact the string issue forces me to deal with lower level details than even PHP requires. I end up with a program littered with ugly pack, unpack, toString, fromString and similar calls. So, the real issue here is that there is not yet a good abstraction over what we consider to be textual data, and instead people have to code to a specific data type. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] putStrLn ß
Henk-Jan van Tuyl hjgt...@chello.nl writes: L.S., When I try putStrLn ß (Eszett (sharp S)) in WinGhci, the interpreter seems to have disappeared; ctrl-C gives the message Interrupted in a separate window, but no new prompt. That's weird; possibly an encoding problem When I start GHCi in a shell, the interpreter displays: Prelude print ß \223 Is this a known issue? Other experiments with WinGhci: print αγδ a?d (Trying to print alpha, gamma, delta.) print β (Trying to print beta) interpreter hangs again. Details: - WinGhci 1.0.2 - GHCi, version 6.12.3 - Windows XP This is an encoding problem; remember that print = putStrLn . show, so it escapes the String first (to a unicode code-point). , | Prelude print ß | \223 | Prelude putStrLn ß | ß ` (running ghci within a terminal on a Linux-based box). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, haddock, hscolour
Johannes Waldmann waldm...@imn.htwk-leipzig.de writes: How is the cabal magic that would run hscolour? I am using cabal haddock --executables --hyperlink-source and this generates the API docs for all modules, and all have source links, but the actual html-ized source is only generated for the main module, and missing for all others. I believe that cabal-install cannot yet do this because Duncan, etc. have not find a nice way of representing the ~/.cabal/config option and a command-line option (i.e. they can't think of a good name). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 4:03 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Kevin Jardine kevinjard...@gmail.com writes: Hi Don, With respect, I disagree with that approach. Almost every modern programming language has one or at most two standard representations for strings. Almost every modern programming language thinks you can whack a print statement wherever you like... ;-) That includes PHP, Python, Ruby, Perl and many others. The lack of a standard text representation in Haskell has created a crazy patchwork of incompatible libraries requiring explicit and often inefficient conversions to connect them together. I expect Haskell to be higher level than those other languages so that I can ignore the lower level details and focus on the algorithms. But in fact the string issue forces me to deal with lower level details than even PHP requires. I end up with a program littered with ugly pack, unpack, toString, fromString and similar calls. So, the real issue here is that there is not yet a good abstraction over what we consider to be textual data, and instead people have to code to a specific data type. Isn't this the same problem we have with numeric literals? I might even go so far as to suggest it's going to be a problem with all types of literals. Isn't it also a problem which is partially solved with the OverloadedStrings extension? http://haskell.cs.yale.edu/ghc/docs/6.12.2/html/users_guide/type-class-extensions.html#overloaded-strings It seems like the interface exposed by ByteString could be in a type class. At that point, would the problem be solved? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 9:55 AM, Daniel Fischer daniel.is.fisc...@web.dewrote: That's an unfortunate example. Using the stringsearch package, substring searching in ByteStrings was considerably faster than in Data.Text in my tests. Daniel, thanks again for bringing up this example! It turned out that quite a lot of the difference in performance was due to an inadvertent space leak in the text search code. With a single added bang pattern, the execution time and space usage both improved markedly. There is of course still lots of room for improvement, but having test cases like this helps immensely. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Jason Dagit da...@codersbase.com writes: On Fri, Aug 13, 2010 at 4:03 PM, Ivan Lazar Miljenovic So, the real issue here is that there is not yet a good abstraction over what we consider to be textual data, and instead people have to code to a specific data type. Isn't this the same problem we have with numeric literals? I might even go so far as to suggest it's going to be a problem with all types of literals. Not just literals; there is no common way of doing a character replacement (e.g. map toUpper) in a textual type for example. Isn't it also a problem which is partially solved with the OverloadedStrings extension? http://haskell.cs.yale.edu/ghc/docs/6.12.2/html/users_guide/type-class-extensions.html#overloaded-strings That just convert literals; it doesn't provide a common API. It seems like the interface exposed by ByteString could be in a type class. At that point, would the problem be solved? To a certain extent, yes. There is no one typeclass that could cover everything (especially since something as simple as toUpper won't work if I understand Bryan's ß - SS example), but it would help in the majority of cases. There has been one attempt, but it doesn't seem very popular (tagsoup has another, but it's meant to be internal only): http://hackage.haskell.org/packages/archive/ListLike/latest/doc/html/Data-ListLike.html#39 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: philosophy of Haskell
Conal Elliott co...@conal.net wrote: There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Hi Ertugrul, This state monad model does not really work for IO, since it fails to capture IO's concurrency (with non-deterministic interleaving). Well, it does capture concurrency and FFI, but it has no explicit notion for it. In other words, concurrent threads and FFI calls are effects like everything else, so the forkIO function just changes the world state implicitly and that's it. I don't know whether/how the EDSL model you mention addresses concurrency or FFI. Just like the state monad model. This is not a weakness of the interpretation, but of the IO monad itself, because it is quite a raw and straightforward language for doing I/O. Other approaches like functional reactive programming may be better at capturing these things, particularly the interactions between concurrent threads, at least for specific applications. So, maybe these models are models of something other (and much less expressive) than Haskell's IO. Which re-raises Jerzy's question. Haskell's IO is flexible at the cost of being quite low level. I think to capture things like concurrency properly and explicitly you need a richer sublanguage, maybe something based on the pi calculus. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/10 16:37 , Kevin Jardine wrote: Surely efficient Unicode text should always be the default? And if the Efficient for what? The most efficient Unicode representation for Latin-derived strings is UTF-8, but the most efficient for CJK is UTF-16. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxl5iUACgkQIn7hlCsL25VxzQCgl0lKLIPQwygh/LlUbCq3v2bv VOcAnR/xJfYBIa1NbNp5VcNk2TlZb1mn =b9YK -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 6:41 PM, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/10 16:37 , Kevin Jardine wrote: Surely efficient Unicode text should always be the default? And if the Efficient for what? The most efficient Unicode representation for Latin-derived strings is UTF-8, but the most efficient for CJK is UTF-16. I have an app that is using Data.Text, however I'm thinking of switching to UTF8 bytestrings. The reasons are that there are two main things I do with text: pass it to a C API to display, and parse it. The C API expects UTF8, and the parser libraries with a reputation for being fast all seem to have bytestring inputs, but not Data.Text (I'm using unpack - parsec, which is not optimal). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Friday 13 August 2010 8:51:46 pm Evan Laforge wrote: I have an app that is using Data.Text, however I'm thinking of switching to UTF8 bytestrings. The reasons are that there are two main things I do with text: pass it to a C API to display, and parse it. The C API expects UTF8, and the parser libraries with a reputation for being fast all seem to have bytestring inputs, but not Data.Text (I'm using unpack - parsec, which is not optimal). You should be able to use parsec with text. All you need to do is write a Stream instance: instance Monad m = Stream Text m Char where uncons = return . Text.uncons -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 10:01 PM, Dan Doel dan.d...@gmail.com wrote: On Friday 13 August 2010 8:51:46 pm Evan Laforge wrote: I have an app that is using Data.Text, however I'm thinking of switching to UTF8 bytestrings. The reasons are that there are two main things I do with text: pass it to a C API to display, and parse it. The C API expects UTF8, and the parser libraries with a reputation for being fast all seem to have bytestring inputs, but not Data.Text (I'm using unpack - parsec, which is not optimal). You should be able to use parsec with text. All you need to do is write a Stream instance: instance Monad m = Stream Text m Char where uncons = return . Text.uncons Then this should be on a 'parsec-text' package. Instances are always implicitly imported. Suppose packages A and B define this instance separately. If package C imports A and B, then it can't use any of those instances nor define its own. Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
So it's a bug in the garbage collector. It's closing a handle that clearly is still reachable, otherwise this would not have happened. On Fri, Aug 13, 2010 at 10:53 AM, Simon Marlow marlo...@gmail.com wrote: On 12/08/2010 21:59, Yitzchak Gale wrote: Wei Hu wrote: nonTermination _ = blackhole where blackhole = blackhole My original example was actually: process :: String - String process = let x = x in x Ah yes, that works too. But other similar versions don't, like this one: process :: String - String process _ = let x = x in x Hence why I added the tail in my version. So what happens is this: - the recursive definition causes the main thread to block on itself (known as a black hole) - the program is deadlocked (no threads to run), so the runtime invokes the GC to see if any threads are unreachable - the GC finds that (a) the main thread is unreachable and blocked on a blackhole, so it gets a NonTermination exception (b) the Handle is unreachable, so its finalizer is started - the finalizer runs first, and closes the Handle - the main thread runs next, and the exception handler for writeFile tries to close the Handle, which has already been finalized Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unwrapping long lines in text files
The program below takes a text file and unwraps all lines to 72 columns, but I'm getting an end of file message at the top of my output. How do I lose the EOF? Michael == unwrap.hs == main = do line - getLine if null line then do putStrLn main else do printList (words line) 1 main printList :: [String] - Int - IO () printList [] _ = do putStrLn printList (w:[]) k = do if k+(length w) = 72 then do putStrLn w else do putStrLn putStrLn w printList r@(w:ws) k = do if k+(length w) = 72 then do putStr w putStr printList ws (k+(length w)+1) else do putStrLn printList r 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Not sure if I understood what you're trying to do, but development will be easier if you minimize your IO, e.g. : maxLineLength :: Int maxLineLength = 72 wrapLine :: String - [String] wrapLine = [] wrapLine line | length line = maxLineLength= [line] | otherwise= take maxLineLength line : wrapLine (drop maxLineLength line) main :: IO () main = interact $ unlines . concatMap wrapLine . lines Now wrapLine is pure and you can use it more easily using GHCi. Removing dependencies on IO usually makes your problem easier to test and understand and your code simpler. In your example, the EOF probably happens on the call to getLine after input has run out. By using Prelude.interact, we can ignore details like that and rely on already-written functions. HTH, Bill On Friday Aug 13, 2010, at 9:38 PM, michael rice wrote: The program below takes a text file and unwraps all lines to 72 columns, but I'm getting an end of file message at the top of my output. How do I lose the EOF? Michael == unwrap.hs == main = do line - getLine if null line then do putStrLn main else do printList (words line) 1 main printList :: [String] - Int - IO () printList [] _ = do putStrLn printList (w:[]) k = do if k+(length w) = 72 then do putStrLn w else do putStrLn putStrLn w printList r@(w:ws) k = do if k+(length w) = 72 then do putStr w putStr printList ws (k+(length w)+1) else do putStrLn printList r 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Hello michael, Saturday, August 14, 2010, 5:38:46 AM, you wrote: The program below takes a text file and unwraps all lines to 72 columns, but I'm getting an end of file message at the top of my output. How do I lose the EOF? use isEOF function. even better, use interact -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Hi Bill, Each quote of the input is on a single line. I want to unwrap lines greater than 72 characters, i.e., break them into several lines each = 72 characters, but I don't want to break up words. and I want to retain the blank lines. So, my output is correct except for the error message. Michael My input data However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not trouble yourself much to get new things, whether clothes or friends. Things do not change, we change. Sell your clothes and keep your thoughts. God will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a man to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was hoeing in a village garden, and I felt that I was more distinguished by that circumstance that I should have been by any epaulet I could have worn. -Thoreau My output unwrap: stdin: hGetLine: end of file here's my eof message However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not trouble yourself much to get new things, whether clothes or friends. Things do not change, we change. Sell your clothes and keep your thoughts. God will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a man to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was hoeing in a village garden, and I felt that I was more distinguished by that circumstance that I should have been by any epaulet I could have worn. -Thoreau Your output == However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not t rouble yourself much to get new things, whether clothes or friends. Thin gs do not change, we change. Sell your clothes and keep your thoughts. G od will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a ma n to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was h oeing in a village garden, and I felt that I was more distinguished by t hat circumstance that I should have been by any epaulet I could have wor n. -Thoreau === --- On Fri, 8/13/10, Bill Atkins watk...@alum.rpi.edu wrote: From: Bill Atkins watk...@alum.rpi.edu Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Friday, August 13, 2010, 11:13 PM Not sure if I understood what you're trying to do, but development will be easier if you minimize your IO, e.g. : maxLineLength :: Int maxLineLength = 72 wrapLine :: String - [String] wrapLine = [] wrapLine line | length line = maxLineLength = [line] | otherwise = take maxLineLength line : wrapLine (drop maxLineLength line) main :: IO () main = interact $ unlines . concatMap wrapLine . lines Now wrapLine is pure and you can use it more easily using GHCi. Removing dependencies on IO usually makes your problem easier to test and understand and your code simpler. In your example, the EOF probably happens on the call to getLine after input has run out. By using Prelude.interact, we can ignore details like that and rely on already-written functions. HTH, Bill On Friday Aug 13, 2010, at 9:38 PM, michael rice wrote: The program below takes a text file and unwraps all lines to 72 columns, but I'm getting an end of file message at the top of my output. How do I lose the EOF? Michael == unwrap.hs == main = do line - getLine if null line then do putStrLn main else do printList (words line) 1 main printList :: [String] - Int - IO () printList [] _ = do putStrLn printList (w:[]) k = do if k+(length w) = 72 then do putStrLn w else do putStrLn putStrLn w printList r@(w:ws) k = do if k+(length w) = 72 then do putStr w putStr printList ws (k+(length w)+1) else do putStrLn printList r 1
Re: [Haskell-cafe] Re: philosophy of Haskell
On Sat, Aug 14, 2010 at 9:27 AM, Ertugrul Soeylemez e...@ertes.de wrote: Conal Elliott co...@conal.net wrote: There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Hi Ertugrul, This state monad model does not really work for IO, since it fails to capture IO's concurrency (with non-deterministic interleaving). Well, it does capture concurrency and FFI, but it has no explicit notion for it. In other words, concurrent threads and FFI calls are effects like everything else, so the forkIO function just changes the world state implicitly and that's it. Consider that IO's concurrency means that something else can happen between printing x+1 and printing x+2, so that x+2 is *not* printed in world2, but rather in a world influenced outside of this thread. Similarly, x+1 might not be printed in world1, and the getLine might not be executed in world0. So World - (a, World) is *not* expressive enough to explain Haskell-IO-style concurrency. Do you see what I mean? I don't know whether/how the EDSL model you mention addresses concurrency or FFI. Just like the state monad model. This is not a weakness of the interpretation, but of the IO monad itself, because it is quite a raw and straightforward language for doing I/O. And the IO monad is what Jerzy asked about. I'm pointing out that the state monad does not capture concurrency, and the EDSL model does not capture FFI. (Really, it depends which EDSL model. I haven't seen one that can capture FFI. And maybe not concurrency either.) Other approaches like functional reactive programming may be better at capturing these things, particularly the interactions between concurrent threads, at least for specific applications. So, maybe these models are models of something other (and much less expressive) than Haskell's IO. Which re-raises Jerzy's question. Haskell's IO is flexible at the cost of being quite low level. I think to capture things like concurrency properly and explicitly you need a richer sublanguage, maybe something based on the pi calculus. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: String vs ByteString
On Aug 14, 2:41 am, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: Efficient for what? The most efficient Unicode representation for Latin-derived strings is UTF-8, but the most efficient for CJK is UTF-16. I think that this kind of programming detail should be handled internally (even if necessary by switching automatically from UTF-8 to UTF-16 depending upon the language). I'm using Haskell so that I can write high level code. In my view I should not have to care if the people using my application write in Farsi, Quechua or Tamil. Kevin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
