John Meacham wrote
[Rule 1]
* in a cooperative implementation of threading, any thread with value
_|_ may cause the whole program to have value _|_. In a preemtive one,
this is not true.
would the simple qualifier
'if there exists another runnable thread'
solve the issues?
if there
Fortunatly, I don't expect these issues to be much of a problem in
practice. (though, they certainly are real issues)
the vast majority of programs, haskell ones included, are either
interactive or batch. an interactive program spends most of its time
waiting for user input or external events,
On 4/11/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
| deriving (Show Foo)
I'm all for that. A modest but useful gain. All we need is the syntax,
and that is something that Haskell Prime might usefully define.
Speaking of which, how about simply qualifying a body-less instance
with
Hello,
I just moved the documentation (still accessible from the below wiki
page) to here:
http://users.skynet.be/jyp/html/collections/Data.Collections.html
the source being:
http://darcs.haskell.org/packages/collections/Data/Collections.hs
And, since you asked for it, there is something I
On 12 April 2006 08:41, John Meacham wrote:
However, I am also of the mind that preemtiveness alone doesn't buy
enough to make the runtime cost of locking worth it which is why I
plan for jhc to be fully cooperative or fully OS threaded with no
middle ground. but the situation is different in
On 12 April 2006 07:46, [EMAIL PROTECTED] wrote:
I am afraid I must ask for the clarification of the goals of this
discrimination between pre-emptive and cooperative scheduling -- which
leads me to further questions.
One one hand, I understand the motivation: providing guidance to the
end
On 11 April 2006 22:24, John Meacham wrote:
I'd like to be a bit more formal when it comes to the distinction
between cooperative and preemptive implementations of concurrency,
here is a first attempt.
1. termination,
In a concurrent implementation, a thread performing an infinite loop
On 12 April 2006 11:03, John Meacham wrote:
On Wed, Apr 12, 2006 at 10:24:57AM +0100, Simon Marlow wrote:
On 12 April 2006 08:41, John Meacham wrote:
However, I am also of the mind that preemtiveness alone doesn't buy
enough to make the runtime cost of locking worth it which is why I
plan
On Wed, Apr 12, 2006 at 10:58:32AM +0100, Simon Marlow wrote:
I don't know what it means for a thread to have value _|_. A thread
is defined by its observable effects, threads don't have values.
sure they do, the value is just usually discarded. cooperative
implementations are just the ones
On Wed, Apr 12, 2006 at 11:19:53AM +0100, Simon Marlow wrote:
I'll argue that point :) GHC makes run-time checks at safe points and
implements preemptive concurrency. Cooperative scheduling is when the
*programmer* has to insert the safe points.
the programmer of the standard libraries or
John Meacham [EMAIL PROTECTED] wrote:
In a concurrent implementation, a thread performing an infinite loop
with no IO or interaction with the outside world can potentially stall
switching to another thread forever, in FP, we usually denote an
infinite loop by _|_. so I think the first
On 12 April 2006 11:30, John Meacham wrote:
On Wed, Apr 12, 2006 at 11:19:53AM +0100, Simon Marlow wrote:
The safe points don't even have to be very often: in GHC the context
switch check is made after every 4k of allocation.
indeed, which means GHC technically doesn't meet the preemptive
On Apr 11, 2006, at 5:37 PM, Lennart Augustsson wrote:
Yes, I realize than dynamic idempotence is not the same as
cycle detection. I still worry. :)
I think expectance is in the eye of the beholder. The reason
that (the pure subset of) pH was a proper implementation of
Haskell was because
On Tue, Apr 11, 2006 at 09:54:12PM -0400, Robert Dockins wrote:
An additional issue is the following instance declarations, which require
undecidable instances under GHC:
Eq (s a) = Eq (Rev s a)
(Sequence s, Read (s a)) = Read (Rev s a)
(Sequence s, Show (s a)) = Show (Rev s a)
These are
Dear all,
Ross Peterson wrote:
The favourite customer for FDs has been the monad transformer library.
...
What other libraries should Haskell' support, and what are their
requirements?
Here are some classes from Yampa/earlier versions of FRP.
I shouldn't think they're particularly
Simon Marlow wrote:
I agree. So other suggestions? longrunning? mightblock or mayblock?
I don't like *block, because the question of blocking is irrelevant
to this issue. It's about whether the foreign call returns sooner or
later, not about whether it spends the time until then
Simon Marlow [EMAIL PROTECTED] wrote:
By infinite loop, you mean both non-terminating, and non-productive.
A non-terminating but productive pure computation (e.g. ones =
1:ones) is not necessarily a problem.
That's slightly odd terminology. ones = 1:ones is definitely
terminating.
On Mon, Apr 10, 2006 at 02:39:18PM +0100, Claus Reinke wrote:
class B a b | a - b
class C a b c | a - b
instance B a b = C [a] b Bool
Starting from a constraint set C [a] b Bool, C [a] c d, [...]
CHR-alt:
B a b = infer_B a b, memo_B a b.
memo_B a b1, memo_B a b2 ==b1=b2.
C a b c = infer_C
On Wed, Apr 12, 2006 at 12:07:06PM -0400, Wolfgang Thaller wrote:
3) There might be implementations where concurrent calls run on a
different thread than nonconcurrent calls.
this is necessarily true for non-OS threaded implementations. there is
no other way to wait for an arbitrary C call to
On Wed, Apr 12, 2006 at 09:21:10AM -0400, Jan-Willem Maessen wrote:
Though, to be fair, an awful lot of Prelude code didn't work in pH
unless it was re-written to vary slightly from the specification. So
the assumption of laziness was more deeply embedded than the spec was
willing to
On Wed, Apr 12, 2006 at 05:50:40PM +0100, Malcolm Wallace wrote:
The argument John was making is that this is a useful distinguishing
point to tell whether your concurrent implementation is cooperative or
preemptive. My argument is that, even if you can distinguish them in
this way, it is not
isaac jones [EMAIL PROTECTED] wrote:
Ross has asked for use cases for functional dependencies and so far
has only two replies. Surely there are those on this list who have
use of functional dependencies?
Personally, I have never used FDs, but I recall some discussion we had
in the Hat
On 4/12/06, Wolfgang Thaller [EMAIL PROTECTED] wrote:
Personally, I'm still in favour of inverting this. We are not in
court here, so every foreign function is guilty until proven
innocent. Every foreign function might be longrunning unless the
programmer happens to know otherwise. So maybe...
On Wed, Apr 12, 2006 at 04:40:29PM -0500, Taral wrote:
pure - side-effect free
we don't really need pure because not having an IO type in the result
implies pure.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
John Meacham [EMAIL PROTECTED] writes:
I object to the idea that concurrent calls are 'safer'. getting it
wrong either way is a bug. it should fail in the most obvious way
rather than the way that can remain hidden for a long time.
I wouldn't consider it a bug of an implementation if it makes
On Thu, Apr 13, 2006 at 12:43:26AM +0200, Marcin 'Qrczak' Kowalczyk wrote:
What about getaddrinfo()? It doesn't synchronize with the rest of the
program, it will eventually complete no matter whether other threads
make progress, so making it concurrent is not necessary for correctness.
It
John Meacham wrote:
This doesn't have to do with bound threads, [...]
I brought it up because the implementation you are proposing
fullfills the most important feature provided by bound threads,
namely to be able to access the thread local state of the main OS
thread (the one that runs C
On Wed, Apr 12, 2006 at 07:35:22PM -0400, Wolfgang Thaller wrote:
John Meacham wrote:
This doesn't have to do with bound threads, [...]
I brought it up because the implementation you are proposing
fullfills the most important feature provided by bound threads,
namely to be able to
Simon Marlow wrote:
do
r - return (mersenne' 44)
acquire'lock
putStrLn Great success
print r
release'lock
One may think that the long computation occurs in the r - ... line.
Alas, it may just as well occur in the print r line, when the digits
of the
John Meacham wrote:
However, in order to achieve that we would have to annotate the
foreign
functions with whether they use thread local state.
I am not opposed to that; however, you might not like that here
again, there would be the safe, possibly inefficient default choice,
which
On Wed, Apr 12, 2006 at 11:37:57PM -0400, Wolfgang Thaller wrote:
John Meacham wrote:
However, in order to achieve that we would have to annotate the
foreign
functions with whether they use thread local state.
I am not opposed to that; however, you might not like that here
again,
31 matches
Mail list logo
