- Haskell-Cafe - Haskell.org

(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 22 Feb '06

22 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 22 Feb '06

22 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

Unexpected results with simple IO
by Maurício 21 Feb '06

21 Feb '06

Dear Haskell users, I have a problem using IO. The small test program below asks the user to guess from a list of random numbers between 1 and 10. Everything works well excepts for one problem: all the messages ("Guess a number...", "Right..." and "Wrong...") are printed after the program finishes, i.e., I have to use it blind. I'm afraid I misunderstand something important about lazyness or monads... What am I doing wrong? Thanks, Maurício module Main where import Random main = do r_gen <- getStdGen --random generator let r_list = (randomRs (1,10) r_gen) --random list guess_loop (r_list) guess_loop (r:r_others) = do putStrLn "Guess a number between 1 and 10:" n <- readLn if n==r then do putStrLn "Right! :)" return () else do putStrLn "Wrong... :(" guess_loop r_others

3 5

Code completion? (IDE)?
by Marc Weber 21 Feb '06

21 Feb '06

vim7 has introduced "omni-completion"... So I'm interested wether there are any projects which support any kind of completion.? I've read the thread about Eclipse IDE haskell plugin. Would you recommend picking up code from a haskell compiler and adapt it for this purpose? I'm interested but don't plan to implement this in the near future. Marc

4 5

Lazy read
by Neil Mitchell 21 Feb '06

21 Feb '06

Hi, I have a nice big data structure that I serialise to a file using "show", and read back in using "read". This data structure has deriving (Read, Show), which makes it all nice and easy to save and load this data structure, without worrying about parsing code etc. The problem is that this data structure can become quite big, and while show operates lazily, read does not. I understand the reason for this - that it internally calls reads and that on a parse error reads will not return a result - i.e. it has to get to the end to determine whether the parse was valid or not. However, in my particular case, I know the data structure is valid, and if it isn't then I'm quite happy with the parser throwing an error half way through - after having lazily returned half of the data. A short example, which shows up the exact same issue is: head ((read $ show [1..n]) :: [Int]) The time of this operation is dependant on n, because of the strictness of read. What is the best way to modify the code to have read operate lazily? Is there any method that doesn't require writing a custom parser? Is there any standard way for solving a problem like this? Thanks Neil

4 4

RE: [Haskell-cafe] building ghc on win with gcc of cygwin, without cygwin1.dll (-mno-cygwin flag) ?
by Simon Peyton-Jones 20 Feb '06

20 Feb '06

| Googling around I've found that there exists the -mno-cygwin flag which | you can use to not include this lib.. So would it might be possible to | get a ghc build not using cygwin.dll with just cygwin ? I don't know. It sounds plausible. But we only have enough resource to maintain one route for building GHC on Windows. We'd be delighted if other folk were engaged enough to push other routes through and make them work. Another route we don't have, but which in principle is definitely feasible is to compile GHC using Cygwin for Cygwin. The advantage would be that the resulting GHC would have a working Posix library. The disadvantage is that programs it compiles would require Cygwin to run. Anyway, it's up for grabs. Please grab away! We need more Windows-savvy expertise on GHC. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Marc | Weber | Sent: 12 February 2006 04:45 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] building ghc on win with gcc of cygwin,without cygwin1.dll (-mno-cygwin flag) | ? | | Hi.. I've found the nice documentation about building ghc on | haskell.org/ghc -> documentation. | There is one chapter (#1) about C compilers and environments to use: | Either MSYS or cywin and | gcc of MinGW because gcc of cygwin will link to cygwin1.dll by default | which may change and therefore can brake your apps. | Googling around I've found that there exists the -mno-cygwin flag which | you can use to not include this lib.. So would it might be possible to | get a ghc build not using cygwin.dll with just cygwin ? | I haven't read anything about that in those docs. | | Or does this flag simply include cygwin.dll within your apps (statically | linked) ? | | #1 :http://www.haskell.org/ghc/docs/latest/html/building/platforms.html#ghc -cygwin | | Marc | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0