[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
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) >
[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 .
> 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,
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 r
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
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
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 thi
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. si
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,
On Tue, Feb 21, 2006 at 01:15:48PM +, Simon Marlow wrote:
> I agree that a generic select/poll interface would be nice. If it was
> in terms of Handles though, that's not useful for implementing the I/O
> library. If it was in terms of FDs, that's not portable - we'd need a
> separate one
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 mi
Am Dienstag, 21. Februar 2006 13:06 schrieb Simon Marlow:
> If we get class synonyms (see Haskell' proposal) this will get easier.
This raises two questions in me:
1. Is this the thing, John Meacham proposed some time ago?
2. What is the URL of the respective Haskell' proposal?
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 "assoc
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,
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)
System.Cmd.s
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
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
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 O
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 implem
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(IOC
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
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
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 encodin
24 matches
Mail list logo
