- Haskell-Cafe - Haskell.org

Request for feedback: Understanding Haskell Monads
by Ertugrul Soeylemez 28 Dec '08

28 Dec '08

Hello fellow Haskellers, In the last few weeks I have written a comprehensive tutorial about Haskell monads [1], and I was hoping to get some constructive feedback. I'd appreciate any well meant criticism. [1] http://ertes.de/articles/monads.html Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/

5 6

generating random lists until some predicate holds
by Nicholas O. Andrews 28 Dec '08

28 Dec '08

Hi all, What's the best way to implement the following Python code in Haskell? It is purposefully written in a functional style (and as a result will kill your recursion stack every other run). # begin Python from random import * def genList (): return [randint(0,9) for x in range(10)] def randWhile (predicate): result = genList () if predicate(result): return result else: return randWhile (predicate) def allEven (list): return reduce(lambda x,y: x and y, [x%2 == 0 for x in list]) print randWhile (allEven) # End Python Thanks!

3 2

Fram
by Haakon Meland Eriksen 28 Dec '08

28 Dec '08

Dear Haskell community, It was kindly suggested to me by John Peterson that I might reach you here and tell you a little bit about Fram, a small Mediawiki extension. Fram lets you intersperse your explanation with actual code, and then Fram extracts and concatenates the code, giving you a file with code for download. This means anyone with access to Fram can improve your code, either by explaining it or by enhancing the code itself. It is released under the GNU GPL version 3 at no cost. Fram is now at version 0.2, and equals the Mediawiki extension RawFile 0.2, written by Belgian developer Philippe Teuwen. Phil and I are collaborating to improve Fram into a fully fledged literate programming tool like "noweb" written by Norman Ramsey. It was originally Ramsey who suggested to me that Fram may be interesting to the Haskell community wiki, so here we are. If this sounds useful, please have a look at http://far.no/fram/ or go below the main-deck into the cabins to explore the articles http://far.no/fram/index.php?title=Fram http://far.no/fram/index.php?title=Test http://far.no/fram/index.php?title=Usbpix and if these don't make sense, have a look at our help page http://far.no/fram/index.php?title=Help:Contents If you are curious about the name, "Fram" is also the name of a famous ship used by Norwegian polar explorers in the last century. It means "Forward". Yours sincerely, Haakon Meland Eriksen

2 3

Missing Network Functions
by John Van Enk 28 Dec '08

28 Dec '08

While working on a project, I discovered that hton[sl] and ntoh[sl] are missing from the networking libraries. It appears there was some justification for this, but I've fallen upon a few instances where things were *not* working as expected. (Specifically when newtype'ing around HostAddress.) As such, I'm putting together a few extra functions that I think should exist in Network somewhere. I'm calling the package Network.Util (but am open to changes). Currently this only has: - htons - htonl - ntohs - ntohl Before I drop this on hackage: 1. Is there a reason I shouldn't do this? 2. Are there other suggestions for missing functions? (preferably cross-platform suggestions) Thanks all. /jve

5 6

chroot a single thread
by Jeremy Shaw 28 Dec '08

28 Dec '08

Hello, I am working on an application where I would like to chroot a thread, but I am not seeing a way to do it. I already have code which can run an IO action inside a chroot. The type signature is: fchroot :: FilePath -> IO a -> IO a The first argument is the new root, the second argument is the action to run with that root. You can see the implementation here if you are curious: http://src.seereason.com/build-env/Chroot.hs The problem with that function is that chroot affects the root of the whole process. In a single-threaded program this is (possibly) ok, because the original root is restored after the IO action completes (though with unsafeInterleaveIO, perhaps bad stuff will happen). In a multithreaded program it can be disasterous. As far as I know, the only solution would be to implement a function like fchroot which looks more like: pchroot :: FilePath -> IO () -> IO ExitCode Here the IO action would be forked off and run in a whole new process so that changing its root does not affect other 'threads'. Of course, you also can't use any of the nifty Haskell intra-thread communication stuff. Basically you can pass some values in and get back an exit code. However, I am not even sure how to implement a useful version of pchroot. In theory, I can just use forkProcess, but, the Giant Warning for forkProcess indicates that this will not be very useful in practice: forkProcess comes with a giant warning: since any other running threads are not copied into the child process, it's easy to go wrong: e.g. by accessing some shared resource that was held by another thread in the parent. Another example is the I/O manager thread: since the I/O manager isn't running in the child, attempting to do any Handle-based I/O will deadlock. Anyone have an ideas ? Thanks! - jeremy

4 4

Re: Re[2]: [Haskell-cafe] Data.ByteString join
by Galchin, Vasili 28 Dec '08

28 Dec '08

ooops ... .my bad ... so I guess Hoogle is the way to go?? On Sun, Dec 28, 2008 at 5:39 AM, Bulat Ziganshin <bulat.ziganshin(a)gmail.com>wrote: > Hello Vasili, > > Sunday, December 28, 2008, 1:59:43 PM, you wrote: > > > http://cvs.haskell.org/Hugs/pages/libraries/base/Data-ByteString.html > > look carefully - it's hugs docs > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > >

1 1

Re: Missing Network Functions
by John Van Enk 28 Dec '08

28 Dec '08

I want to group them with Network functions because traditionally these specific functions *are* in networking packages. On *nix systems, the prototypes reside in <netinet/in.h>. On Windows they reside in <winsock2.h> and one must link against libws2_32. The package I have locally supports all platforms. It just does a foreign import of the function (and uses a preprocessor definition to pick the calling convention). One could make an argument to add these sorts of functions to Word and Int packages. /jve On Sat, Dec 27, 2008 at 7:14 PM, Chris Kuklewicz < haskell(a)list.mightyreason.com> wrote: > Are these going to be available on Windows or just Posix systems? > > And these are NOT performing network communication. They are bit > manipulations. > > I could imagine putting them in/under the Data.Word or Data.Bits more than > Network.* > > And they should also be made to work with the corresponding Foreign.C.Types > of CShort, etc. > > > John Van Enk wrote: > >> While working on a project, I discovered that hton[sl] and ntoh[sl] are >> missing from the networking libraries. It appears there was some >> justification for this, but I've fallen upon a few instances where things >> were *not* working as expected. (Specifically when newtype'ing around >> HostAddress.) >> >> As such, I'm putting together a few extra functions that I think should >> exist in Network somewhere. I'm calling the package Network.Util (but am >> open to changes). >> >> Currently this only has: >> >> * htons >> * htonl >> * ntohs >> * ntohl >> >> Before I drop this on hackage: >> >> 1. Is there a reason I shouldn't do this? >> 2. Are there other suggestions for missing functions? (preferably >> cross-platform suggestions) >> >> Thanks all. >> >> /jve >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >

2 1

Re: [Haskell-cafe] ByteString typechecking issues....
by Galchin, Vasili 28 Dec '08

28 Dec '08

Not in scope: `Data.ByteString.join' when Data.ByteString.join $ encode (buildHeader ss) -- ByteString -- [] (map encode (buildEntries (sequenceListExtract ss))) -- [ByteString] ?? Thanks, guys On Sat, Dec 27, 2008 at 3:13 AM, Eugene Kirpichov <ekirpichov(a)gmail.com>wrote: > I think Luke meant that you forgot to qualify the import for join, and > the compiler guessed that you are meaning the monad one, thus the > error. > > 2008/12/27 Galchin, Vasili <vigalchin(a)gmail.com>: > > Hi Luke, > > > > join :: ByteString -> [ByteString] -> ByteString ??? > > > > Vasili > > > > On Sat, Dec 27, 2008 at 1:58 AM, Luke Palmer <lrpalmer(a)gmail.com> wrote: > >> > >> 2008/12/26 Galchin, Vasili <vigalchin(a)gmail.com> > >>> > >>> Hello, > >>> > >>> I have a ByteString -> [ByteString] -> ByteString situation, i.e. > >>> concatenation ..... > >>> > >>> > >>> -- marshall into ByteString representation > >>> join > >>> (encode (buildHeader > >>> ss)) -- ByteString > >>> (map encode (buildEntries (sequenceListExtract > >>> ss))) -- [ByteString] > >>> > >>> > >>> I get the following typecheck error which is vexing me .... > >>> > >>> Couldn't match expected type `t -> t -> B.ByteString' > >>> against inferred type `B.ByteString' > >>> > >>> ??? > >> > >> join is not a function in Data.ByteString. By the error I'm guessing > >> you're getting the join from Control.Monad, instantiated to (->). > >> You are looking for "concat"; i.e. > >> concat $ > >> encode (buildHeader ss) : > >> -- ByteString > >> map encode (buildEntries (sequenceListExtract ss)) > >> -- [ByteString] > >> > >> (Control.Monad.join does end up meaning"concat" when working on lists of > >> lists, but it does not generalize to lists of other things). > >> Luke > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

4 4

Re: [Haskell-cafe] Re: [Haskell] ANN: HLint 1.0
by Claus Reinke 28 Dec '08

28 Dec '08

>> You were asking about getting the output of ':show modules' into a >> variable 'x', so that you can process it further. ':redir x :show modules' >> should do just that. There is another example command for implementing >> ':edit' this way (by now a native ghci command). > > I think I'm seeing your meaning. So that brings me up to this: > > let hlint _ = return $ unlines [":redir hlintvar1 :show modules", "let > hlintvar2 = map (fst . break (==',') . drop 2 . snd . break (== '(')) > $ lines hlintvar1", ":! hlint (concat $ intersperse \" \" hlintvar2"] > :def hlint hlint > > This doesn't work. The issue is that :! is weird; for it to work, one > need to pass each argument as a separate string, and it won't evaluate > a variable. It isn't just ':!', quoting/variable interpretation is generally rather uncomfortable in GHCi scripting (so much so that I originally submitted output redirection as a patch before figuring out that it could be done without patching GHCi - that surprise find was the motivation for posting my findings as an email). Have you tried reading the mini tutorial that I keep mentioning and which the "using GHCi" page is pointing to? Here's the direct link: http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html The discussion is rather brief, but that tutorial has several examples that need to work around issues like this, ranging from simple but tedious construct-the-command-string to extra levels of ':cmd' in order to get extra levels of interpretation (when you need to construct a command string from a variable that will be bound via a constructed command string (see the definitions of ':find', ':le' or ':b(rowse)' - the latter is an example of using the info from ':show modules'). Claus

2 1

Don't make 'show*' functions
by Thomas DuBuisson 28 Dec '08

28 Dec '08

Hello cafe, This is just a small thought, but its been bugging me. We have these things called type classes for a reason (I like to think). When making a new data type 'Data', it is not productive to avoid type classes such as 'Show' and export a 'showData' function. Examples of what I'm talking about include showHtml, showTrie, showInstalledPackageInfo... I know the default derivation (and thus generally accepted) instance of Show isn't pretty, but that just means to me that we need either more methods within the Show type class or start using the prettyclass package more. If the problem is an API issue lets fix Pretty or Show. But this show* stuff should disappear in the long run. Tom

6 7