Re: [Haskell-cafe] Re: Associated Type Synonyms question

2006-02-21 Thread Martin Sulzmann
Claus Reinke writes: The main argument for ATS is that the extra parameter for the functionally dependend type disappears, but as you say, that should be codeable in FDs. I say should be, because that does not seem to be the case at the moment. My approach for trying the encoding was

[Haskell-cafe] Re: Streams: the extensible I/O library

2006-02-21 Thread Simon Marlow
Bulat Ziganshin wrote: Wednesday, February 08, 2006, 2:58:30 PM, you wrote: SM I would prefer to see more type structure, rather than putting SM everything in the Stream class. You have classes ByteStream, SM BlockStream etc, but these are just renamings of the Stream class. There SM are

[Haskell-cafe] Re: Hashtable woes

2006-02-21 Thread Simon Marlow
Brian Sniffen wrote: On 2/10/06, Ketil Malde [EMAIL PROTECTED] wrote: Hmm...perhaps it is worth it, then? The benchmark may specify hash table, but I think it is fair to interpret it as associative data structure - after all, people are using associative arrays that (presumably) don't

[Haskell-cafe] typesafe non-local returns in the IO monad

2006-02-21 Thread John Meacham
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

[Haskell-cafe] Re: Emulating bash pipe/ process lib

2006-02-21 Thread Simon Marlow
Bulat Ziganshin wrote: Friday, February 10, 2006, 2:53:25 PM, you wrote: i'm not very interested to do something fascinating in this area. it seems that it is enough to do 1) non-blocking read of the entire buffer on input 2) flush buffer at each '\n' at output that should be enough to

RE: [Haskell-cafe] typesafe non-local returns in the IO monad

2006-02-21 Thread Simon Peyton-Jones
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf

[Haskell-cafe] Re: standard poll/select interface

2006-02-21 Thread Simon Marlow
John Meacham wrote: On Fri, Feb 10, 2006 at 12:26:30PM +, Simon Marlow wrote: in fact, I think this should be the basic API, since you can implement readFD in terms of it. (readNonBlockingFD always reads at least one byte, blocking until some data is available). This is used to partially

[Haskell-cafe] Re: standard poll/select interface

2006-02-21 Thread Simon Marlow
Bulat Ziganshin wrote: SM I don't think async I/O is a stream transformer, fitting it into the SM stream hierarchy seems artificial to me. yes, it is possible - what i'm trying to implement everything as tranformer, independent of real necessity. i really thinks that idea of transformers fit

[Haskell-cafe] Re: getChar + System.Cmd.system + threads causes hangups

2006-02-21 Thread Simon Marlow
Einar Karttunen wrote: 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)

Re: [Haskell-cafe] Re: getChar + System.Cmd.system + threads causes hangups

2006-02-21 Thread Donn Cave
On Tue, 21 Feb 2006, Simon Marlow wrote: ... The reason for the deadlock is because getChar is holding a lock on stdin, and System.Cmd.system needs to access the stdin Handle in order to know which file descriptor to dup as stdin in the child process (the stdin Handle isn't always FD 0,

Re: [Haskell-cafe] Re: Hashtable woes

2006-02-21 Thread Chris Kuklewicz
Simon Marlow wrote: Brian Sniffen wrote: On 2/10/06, Ketil Malde [EMAIL PROTECTED] wrote: Hmm...perhaps it is worth it, then? The benchmark may specify hash table, but I think it is fair to interpret it as associative data structure - after all, people are using associative arrays that

Re: [Haskell-cafe] Constructor classes implementation

2006-02-21 Thread Daniel Fischer
Am Montag, 20. Februar 2006 13:35 schrieb Daniel Fischer: Cheers, Sean p.s. If you find any bugs, please let me know. Re bugs: 1. printGamma [] would print an unmotivated }, as witnessed by typeInf [] term14. 2. the case unify (ConT c) (AppT t1 t2) is missing. and unifying a

Re: [Haskell-cafe] Constructor classes implementation

2006-02-21 Thread Sean Seefried
Thank you for taking the time to look through the code. 1. printGamma [] would print an unmotivated }, as witnessed by typeInf [] term14. 2. the case unify (ConT c) (AppT t1 t2) is missing. and unifying a tyvar with itself fails. That probably doesn't occur in the inference-algorithm,

Re: [Haskell-cafe] typesafe non-local returns in the IO monad

2006-02-21 Thread John Meacham
On Tue, Feb 21, 2006 at 01:07:51PM -, Simon Peyton-Jones wrote: 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. Ah, you are right. silly

Re: [Haskell-cafe] Re: standard poll/select interface

2006-02-21 Thread Donn Cave
On Tue, 21 Feb 2006, John Meacham wrote: Yeah, this is why I have held off on a specific design until we get a better idea of what the new IO library will look like. I am thinking it will have to involve some abstract event source type with primitive routines for creating this type from things

Re: [Haskell-cafe] Constructor classes implementation

2006-02-21 Thread Donald Bruce Stewart
sean.seefried: I still don't see clearly. So you've implemented the type inference algorithm from Jones' paper, good. But is there any significance or gain, apart from it being a nice and interesting exercise? No. Nor did I state that there was. There's a reason I posted this to

[Haskell-cafe] (Un)termination of overloading resolution

2006-02-21 Thread oleg
Martin Sulzmann wrote: - The type functions are obviously terminating, e.g. type T [a] = [[a]] clearly terminates. - It's the devious interaction between instances/superclasss and type function which causes the type class program not to terminate. Is there a possible fix? Here's a

[Haskell-cafe] (Un)termination of overloading resolution

2006-02-21 Thread Martin Sulzmann
This is not a counter-example to my conjecture. 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

[Haskell-cafe] (Un)termination of overloading resolution

2006-02-21 Thread oleg
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 I

[Haskell-cafe] (Un)termination of overloading resolution

2006-02-21 Thread Martin Sulzmann
[EMAIL PROTECTED] writes: 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)

[Haskell-cafe] (Un)termination of overloading resolution

2006-02-21 Thread oleg
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)

[Haskell-cafe] (Un)termination of overloading resolution

2006-02-21 Thread Martin Sulzmann
[EMAIL PROTECTED] writes: 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