February 2006 - Haskell-Cafe

Re: [Haskell] page renaming on the Haskell Wiki
by Graham Klyne 22 Feb '06

22 Feb '06

Wolfgang, [Switching to haskell-cafe] Re: [1] http://www.mail-archive.com/haskell@haskell.org/msg18352.html [2] http://www.mail-archive.com/haskell@haskell.org/msg18356.html [3] http://www.w3.org/Provider/Style/URI Wolfgang Jeltsch wrote (in [2]): > On the other hand, I think that the above W3C article is far too extreme. It > tells you that stability is the most important thing concerning URIs. I will pursue this a little further, because I think that getting the web presence right is very important to maintaining an online community. It may be that we must agree to disagree, but based on my experience of using the web, stability of URIs *is* the most important thing (after content, of course). I have been using the W3C web site now for many years, and the inconsistencies you mention have never been a problem for me -- indeed, I hadn't even noticed them until you mentioned them. Why is this? I hypothesize that it is because, when the Web is used effectively, it is really quite rare to enter a URI manually. Instead, one uses various index pages, RSS feeds, search tools and so on to find a URI, and then simply click on it. Many URIs are never seen by human eye, but placed behind descriptive links. W3C themselves use URIs very intensively in transient communications, and their mailing system is set up to facilitate this (see their x-archived-at mail headers). A result of this is that the email archives, together with the web site pages, form a tightly interlinked collection of documents and comments that can be, and are, frequently cross-referenced rather than reinvented. But, for this to work, once a link has been placed in a document, feed, archive or whatever, it is crucially important that it continues to work for as long as the information it references is of interest to people. Without this, all the devices we use to find our way around the web simply fail -- not all at once, but over time. Even with every intent to maintain stability, this happens, but if you allow that URI stability is somehow less important than other conveniences, then I think all hope is lost for information continuing to be accessible. As for the difficulty of designing a consistent URI naming scheme for all time, the W3C position explicitly recognizes this, and this is why they recommend incorporating dates near the the root of the URI path. That way, fashions can change without requiring that pages published using older conventions be removed. How to do this in a wiki, I'm not sure, though I don't take that to mean we shouldn't try. I think the mediawiki mechanism you mention is reasonable if not ideal, though this would clearly be overwhelmed if page-renaming were to become the norm. There are, as you indicate, other technical concerns. But I still think they are more easily solved that the problems that arise by failing to maintain URI stability. Best regards, #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact

3 4

Emulating bash pipe/ process lib
by Marc Weber Marc Weber 22 Feb '06

22 Feb '06

Hi. I want to write a little haskell program executing about 4 programs passing data via pipes. As my python script seems to be slower than a bash script I want to try a ghc executable now. It should invoke different parts of a text to speech chain. This way I have one interface then. Talar und #haskell told me that I might use runProcess and pass handles for stdin and out created by createPipe and fdToHandle. So my simple test looks like this: module Main where import System.IO import System.Posix.IO main = do (fdIn,fdOut) <- createPipe let (iohIn, iohOut) = (fdToHandle fdIn, fdToHandle fdOut) hIn <- iohIn hOut <- iohOut hPutStr hIn "test" line <- hGetLine hOut print line -- should now print test having been piped through my pipe but I get the error: pipe2: <file descriptor: 3>: hPutStr: illegal operation (handle is not open for writing) And in current CVS docs in base.System.Process.hs it is said that createPipe is no longer exported ? I've also found this library: http://www.haskell.org/communities/11-2005/html/report.html#processlib which seems to do something similar but is meant to pipe haskell types between different threads (? I haven't understood what's going on there because I can't understand Russian ;-) Is this of any help for me? Greetings Marc

6 12

getChar + System.Cmd.system + threads causes hangups
by Einar Karttunen 22 Feb '06

22 Feb '06

Hello Using system or any variant of it from System.Process seems broken in multithreaded environments. This example will fail with and without -threaded. When run the program will print "hello: start" and then freeze. After pressing enter (the first getChar) System.Cmd.system will complete, but without that it will freeze for all eternity. What is the best way to fix this? I could use System.Posix, but that would lose windows portablity which is needed. import Control.Concurrent import System.Cmd main = do forkIO (threadDelay 100000 >> hello) getChar getChar hello = do putStrLn "hello: start" system "echo hello world!" putStrLn "hello: done" - Einar Karttunen

3 4

Re: Array interface refactoring
by bulat.ziganshin＠gmail.com 22 Feb '06

22 Feb '06

Hello Alson, Tuesday, February 21, 2006, 11:33:49 PM, you wrote: AK> As a Haskell new-ish-bie, the various Array interfaces AK> seem a bit inconsistent and make learning/using arrays AK> complicated. I *do* understand how to use arrays in AK> Haskell, but I think that the interface could be AK> cleaned up. sorry, but i think that you don't understand the whole situation. btw, are you read http://haskell.org/haskellwiki/Arrays ? AK> Examples of current confusions: AK> IArray and Array are dupes (obvious); Array is a type constructor, while IArray is a class AK> listArray for IArray, but newListArray for MArrays; AK> "!" for IArray, but readArray for MArrays. they have different types (!) :: IArray -> Ix -> Element readArray :: MArray -> Ix -> IO Element can you unify these two operations - one monadic and one pure to common type signature? AK> Proposal: I would propose the following for Haskell': AK> "Array" is the interface for arrays; drop IArray; AK> "MArray" is the interface for arrays in monads (IO, AK> ST, etc); and these two interfaces should support operations with the same names but different types? :) i partially agree with your other suggestions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

(Un)termination of overloading resolution
by oleg＠pobox.com 22 Feb '06

22 Feb '06

Martin Sulzmann wrote: > Let's consider the general case (which I didn't describe in my earlier > email). > In case we have an n-ary type function T (or (n+1)-ary type class > constraint T) the conditions says for each > > type T t1 ... tn = t > > (or rule T t1 ... tn x ==> t) > > then rank(ti) > rank(t) for each i=1,..,n ... > Sorry, I left out the precise definition of the rank function > in my previous email. Here's the formal definition. > > rank(x) is some positive number for variable x > > rank(F t1 ... tn) = 1 + rank t1 + ... + rank tn > > where F is an n-ary type constructor. > > rank (f t) = rank f + rank t > > f is a functor variable Yes, I was wondering what rank means exactly. But now I do have a problem with the criterion itself. The following simple and quite common code > newtype MyIOState a = MyIOState (Int -> IO (a,Int)) > > instance Monad MyIOState where > return x = MyIOState (\s -> return (x,s)) > > instance MonadState Int MyIOState where > put x = MyIOState (\s -> return ((),x)) becomes illegal then? Indeed, the class |MonadState s m| has a functional dependency |m -> s|. In our case, m = MyIOState, rank MyIOState = 1 s = Int rank Int = 1 and so rank(m) > rank(s) is violated, right? BTW, the above definition of the rank is still incomplete: it doesn't say what rank(F t1 ... tm) is where F is an n-ary type constructor and m < n. Hopefully, the rank of an incomplete type application is bounded (otherwise, I have a non-termination example in mind). If the rank is bounded, then the problem with defining an instance of MonadState persists. For example, I may wish for a more complex state (which is realistic): > newtype MyIOState a = MyIOState (Int -> IO (a,(Int,String,Bool))) > instance MonadState (Int,String,Bool) MyIOState Now, the rank of the state is 4...

2 1

Constructor classes implementation
by Sean Seefried 21 Feb '06

21 Feb '06

Hey all, If you're interested in an implementation of constructor classes (type classes which can take constructors as arguments; already implemented in Haskell) please see: http://www.cse.unsw.edu.au/~sseefried/code.html This should help understanding the paper by Mark P. Jones called "A system of constructor classes: overloading and implicit higher-order polymorphism" much easier. The implementation not only infers the type but also prints out a trace of the derivation tree for the syntax directed rules. Cheers, Sean p.s. If you find any bugs, please let me know.

3 4

RE: [Haskell-cafe] typesafe non-local returns in the IO monad
by Simon Peyton-Jones 21 Feb '06

21 Feb '06

I'm not sure this works. Consider this newContinuation (\k -> return (callContinuation k)) ... The partial application (callContinuation k) has no 's' in its type, and so can go anywhere. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of John | Meacham | Sent: 21 February 2006 12:40 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] typesafe non-local returns in the IO monad | | Although I am sure I am not the first to discover this, I thought it was | a neat application of the runST trick. Safe non-local returns for | the IO monad. What I mean by safe is that it is impossible to return to | a context that no longer exists. the api is simple: | | > module System.IO.Continuation(IOCont(),newContinuation,callContinuation) where | > | > data IOCont s a = .... | > | > newContinuation :: (forall s . IOCont s a -> IO b) -> (a -> IO b) -> IO b | > newContinuation act cc = ... | > | > callContinuation :: IOCont s a -> a -> IO b | > callContinuation cont x = ... | | newContinuation runs its first argument passing a fresh jumppoint into | it, if it is jumped to then the argument is passed to the second | argument of newContinuation. | | the universal quantification means that the continuation is unable to | escape the action so you know its context is still available on the | stack. | | in jhc these are just implemented as straight FFI calls to setjmp(2) and | longjmp(2) and an IORef. | | I feel using the term 'continuation' is something of a misnomer as true | continuations would allow jumping between multiple stacks I would think | but am unsure what a good name for this is then. Is there a fully | typesafe interface for 'true' IO continuations for some definition of | 'true'? hmm.... | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Re: Streams: the extensible I/O library
by Simon Marlow 21 Feb '06

21 Feb '06

Bulat Ziganshin wrote: > I have developed a new I/O library that IMHO is so sharp that it can > eventually replace the current I/O facilities based on using Handles. > The main advantage of the new library is its strong modular design > using typeclasses. I've taken a brief look, and I must say it's nice (but you knew that anyway :-)). My initial thoughts: I would prefer to see more type structure, rather than putting everything in the Stream class. You have classes ByteStream, BlockStream etc, but these are just renamings of the Stream class. There are many compositions that are illegal, but we don't find out until runtime; it would make a lot more sense to me to expose this structure in the type system. My view is that the most basic level of stream is a byte stream, supporting only two operations: read an array of bytes and write an array of bytes, i.e. vGetBuf/vPutBuf. This makes implementing a stream, or transformer, much easier and shorter. Also I'd like to see separate input/output streams for even more type safety, and I believe simplicity, but this is less important than separating byte streams from text streams. I believe certain other operations would benefit from being moved into separate classes: eg. vSeek into a Seekable class, vSetBuffering into a Buffered class, and so on. This will improve performance too - your Stream class has dictionaries with 20+ elements. I see that buffering works on vPutChar/vGetChar, and yet you seem to be buffering bytes - which is it? Are you supposed to buffer before or after doing character encoding? It seems before, because otherwise buffering will strip out all but the low 8 bits of each character. Using a more explicit type structure would help a lot here. Incedentally, I'm suprised that you can use list-based character encoding/decoding and still get good performance, I expected to need to do encoding directly between buffers. Still, as I said, I think the general approach is excellent, and is definitely heading in the right direction. Oh, and some of the code is GPL'd, which is a problem for incorporation in standard libraries. This is just something to bear in mind if the aim is for this to be a candidate for a/the standard IO library. Cheers, Simon

4 7

Re: [Haskell-cafe] Re: Hashtable woes
by Chris Kuklewicz 21 Feb '06

21 Feb '06

Ketil Malde wrote: > Chris Kuklewicz <haskell(a)list.mightyreason.com> writes: > >> Is Jan-Willem Maessen's Hash available anywhere? I could benchmark it. > > Did you ever get around to run the benchmark? I browsed around a bit, > and found that the knucleotide is probably the worst GHC benchmark in > the shootout (even TCL beats GHC by a factor of two!) - which is > disheartening, because I rely a lot on associative data structures > (usually Data.Map) in my programs. > > Or have Adrian Hey's AVL-trees been tried? > > -k No, I did not try it. This message from Simon Marlow > Jan-Willem's HashTable attached. It uses unsafeThaw/unsafeFreeze tricks > to avoid the GC overheads, for this you need an up to date GHC due to a > bug in the garbage collector: grab a STABLE snapshot (6.4.1 won't work). > Or remove the unsafeThaw/unsafeFreeze to use it with 6.4.1, and be > prepared to bump the heap size. > > In GHC 6.6 the unsafeThaw/unsafeFreeze tricks aren't required, because > the GC is essentially doing it for you - we put a write barrier in the > IOArray implementation. indicates that it triggers a bug in 6.4.1, which is what the shootout is using. And I suspected bumping the heap size just won't cut it for the amount of data we are processing. But I did not test that suspicion. We never pounded on Data.Map, but I suspect it cannot be as bad as Data.Hashtable. -- Chris

6 7

typesafe non-local returns in the IO monad
by John Meacham 21 Feb '06

21 Feb '06

Although I am sure I am not the first to discover this, I thought it was a neat application of the runST trick. Safe non-local returns for the IO monad. What I mean by safe is that it is impossible to return to a context that no longer exists. the api is simple: > module System.IO.Continuation(IOCont(),newContinuation,callContinuation) where > > data IOCont s a = .... > > newContinuation :: (forall s . IOCont s a -> IO b) -> (a -> IO b) -> IO b > newContinuation act cc = ... > > callContinuation :: IOCont s a -> a -> IO b > callContinuation cont x = ... newContinuation runs its first argument passing a fresh jumppoint into it, if it is jumped to then the argument is passed to the second argument of newContinuation. the universal quantification means that the continuation is unable to escape the action so you know its context is still available on the stack. in jhc these are just implemented as straight FFI calls to setjmp(2) and longjmp(2) and an IORef. I feel using the term 'continuation' is something of a misnomer as true continuations would allow jumping between multiple stacks I would think but am unsure what a good name for this is then. Is there a fully typesafe interface for 'true' IO continuations for some definition of 'true'? hmm.... John -- John Meacham - ⑆repetae.net⑆john⑈

1 0