John Meacham:
> On Wed, Mar 29, 2006 at 11:56:41AM +0100, Simon Marlow wrote:
> > Fair enough - I take that as a vote for a concurrency addendum.
>
> Actually, I think there is a lot we can standardize in a portable way
> when it comes to concurrency without compromising the ability for any
> comp
On Mar 29, 2006, at 11:50 AM, Robert Dockins wrote:
On Mar 29, 2006, at 2:23 PM, Andy Gill wrote:
John, et. al.,
I'd rather just use a polymorphic function, but would having some
sort of ... notation in class contexts help?
sort (Eq a,_) => [a] -> [a]
Which means that we need at least the
On Mar 29, 2006, at 2:23 PM, Andy Gill wrote:
John, et. al.,
I'd rather just use a polymorphic function, but would having some
sort of ... notation in class contexts help?
sort (Eq a,_) => [a] -> [a]
Which means that we need at least the Eq a, but perhaps more.
See #86 http://hackage.haskell
John, et. al.,
I'd rather just use a polymorphic function, but would having some
sort of ... notation in class contexts help?
sort (Eq a,_) => [a] -> [a]
Which means that we need at least the Eq a, but perhaps more.
See #86 http://hackage.haskell.org/trac/haskell-prime/wiki/
PartialTypeAnnotat
On 2006-03-29 at 18:34+0200 Wolfgang Jeltsch wrote:
> Am Freitag, 24. März 2006 14:40 schrieb John Hughes:
> > [...]
>
> > Thirdly, the laws one loses are "nearly true" anyway, and that's very often
> > enough. See "Fast and loose reasoning is morally correct", POPL 2006. We
> > don't need to give
Hi,
> context-switches happen only on specific events, which every
> thread will usually engage in, although it need not always do so:
>
> 1 only calls to yield
> 2 any calls to concurrency library api
> 3 any allocation
The Yhc concurrency switches every n instructions, and therefore even
an "ev
Am Freitag, 24. März 2006 14:40 schrieb John Hughes:
> [...]
> Thirdly, the laws one loses are "nearly true" anyway, and that's very often
> enough. See "Fast and loose reasoning is morally correct", POPL 2006. We
> don't need to give up anything to make reasoning *as though* such laws held
> soun
Pre-emption means that (1) threads have priority levels, and (2) that a
higher priority thread can steal the processor from a currently-running
lower priority thread, and (3) it can do so "immediately" it needs to,
without waiting for some "safe" synchronisation point.
obviously, cs-concepts are
Hi
> - we've been told here that concurrency is just a library
No, its not. The interface to concurrency is just a library, but
internally certain things in the runtime have to change.
> - FFI allows other Haskell' implementations to import that library
If all Haskell' prime implementations depen
On Wed, Mar 29, 2006 at 04:11:56PM +0100, Simon Marlow wrote:
> Ok, let's explore how difficult it really is.
>
> Take a single-threaded implementation that forks OS threads for
> concurrent foreign calls. Let's call the OS thread running Haskell code
> the "runtime thread". An OS thread wanting
here's another possible way to look at the complexities, and interactions
of FFI and Haskell' concurrency:
- we've been told here that concurrency is just a library
- GHC implements such a library
- all Haskell' implementations will support FFI
- FFI allows GHC to export that concurrency library
On 29 March 2006 14:35, John Meacham wrote:
> On Wed, Mar 29, 2006 at 02:05:35PM +0100, Simon Marlow wrote:
>
>> What you are suggesting is that there may be implementations that do
>> not support reentrant/blockable, but do support the others. And in
>> that case, of course you really need to kn
Malcolm correctly notes that when I say "non-blocking" I'm referring to
the behaviour from Haskell's point of view, not a property of the
foreign code being invoked.
In fact, whether the foreign code being invoked blocks or not is largely
immaterial. The property we want to capture is just this:
On Wed, 2006-03-29 at 07:32 -0600, Taral wrote:
> On 3/29/06, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > If we were to go down this route, we have to make reentrant the default:
> > 'unsafe' is so-called for a good reason, you should be required to write
> > 'unsafe' if you're doing something unsa
On 3/29/06, Taral <[EMAIL PROTECTED]> wrote:
> On 3/29/06, Ross Paterson <[EMAIL PROTECTED]> wrote:
> > -- The reference contains a rollback action to be executed on exceptions
> > newtype STM a = STM (IORef (IO ()) -> IO a)
>
> Cute, but why use an IORef?
>
> newtype STM a = STM (IO () -> IO a)
O
On 3/29/06, Ross Paterson <[EMAIL PROTECTED]> wrote:
> -- The reference contains a rollback action to be executed on exceptions
> newtype STM a = STM (IORef (IO ()) -> IO a)
Cute, but why use an IORef?
newtype STM a = STM (IO () -> IO a)
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
On Wed, Mar 29, 2006 at 02:05:35PM +0100, Simon Marlow wrote:
> > will all have different concrete implementations and generate
> > different code. for correctness reasons, not efficiency ones.
>
> Well, for correctness all you need is reentrant/blockable. If you have
> that, all the others are e
On 3/29/06, Simon Marlow <[EMAIL PROTECTED]> wrote:
> If we were to go down this route, we have to make reentrant the default:
> 'unsafe' is so-called for a good reason, you should be required to write
> 'unsafe' if you're doing something unsafe. So I'd suggest
>
> unsafe
> concurrent unsafe
>
On 29 March 2006 13:17, John Meacham wrote:
> On Wed, Mar 29, 2006 at 12:48:54PM +0100, Simon Marlow wrote:
>> I agree with what you say, but let me summarise it if I may, because
>> there's an assumption in what you're saying that's easy to miss.
>>
>> IF
>> the combination of 'blockable'
On Wed, Mar 29, 2006 at 12:48:54PM +0100, Simon Marlow wrote:
> I agree with what you say, but let me summarise it if I may, because
> there's an assumption in what you're saying that's easy to miss.
>
> IF
> the combination of 'blockable' and 'reentrant' is not
> required by the stan
On 3/29/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Proposal: make all pattern bindings completely monomorphic
> (regardless of type signatures)
...
> My bet is that this is a
> feature that is tricky to implement, but which is virtually never used.
If this prop
On 2006-03-28 at 08:02+0200 Tomasz Zielonka wrote:
> I wonder if it would be possible to remove the space-leak by running both
> branches concurrently, and scheduling threads in a way that would
> minimise the space-leak. I proposed this before
>
> http://www.haskell.org/pipermail/haskell-cafe/2
I agree with what you say, but let me summarise it if I may, because
there's an assumption in what you're saying that's easy to miss.
IF
the combination of 'blockable' and 'reentrant' is not
required by the standard,
THEN
we should allow foreign calls to be annotated with
On 29 March 2006 12:25, Ross Paterson wrote:
> On Wed, Mar 29, 2006 at 11:44:12AM +0100, Simon Marlow wrote:
>> It's much more useful to reserve the term "cooperative" for
>> when the burden is on the programmer to insert context-switch
>> points, as is the case in Hugs. This is a significant dif
On Wed, Mar 29, 2006 at 11:44:12AM +0100, Simon Marlow wrote:
> Let's stick to fairness. These are the requirements I think the
> standard should include:
>
>No runnable process will be indefinitely delayed.
>
>No thread can be blocked indefinitely on an MVar unless another
>thread h
On Wed, Mar 29, 2006 at 11:44:12AM +0100, Simon Marlow wrote:
> It's much more useful to reserve the term "cooperative" for
> when the burden is on the programmer to insert context-switch points, as
> is the case in Hugs. This is a significant difference from the
> programmer's point of view, wher
On Wed, Mar 29, 2006 at 11:56:41AM +0100, Simon Marlow wrote:
> Fair enough - I take that as a vote for a concurrency addendum.
Actually, I think there is a lot we can standardize in a portable way
when it comes to concurrency without compromising the ability for any
compiler to implement it and I
On 29 March 2006 10:16, John Meacham wrote:
> On Mon, Mar 27, 2006 at 03:36:55PM +0100, Simon Marlow wrote:
>>
>> (b) it is unlikely that Hugs or JHC will implement concurrency
>> even if it goes into the standard
>
> Well, if the standard is unimplemented for certain compilers, I think
>
John Meacham <[EMAIL PROTECTED]> wrote:
> It would be nice if we can deprecate the not very informative 'safe'
> and 'unsafe' names and use more descriptive ones that tell you what is
> actually allowed.
Yes. I have always found that naming convention confusing and
non-declarative. "Safe" mean
On 28 March 2006 15:26, Malcolm Wallace wrote:
> "Simon Marlow" <[EMAIL PROTECTED]> wrote:
>
>> Ok, I'll try to nail down what we should require in terms of fairness
>> (which is the same as pre-emption).
>
> The terms are not entirely synonymous.
>
> Pre-emption means that (1) threads have pri
On Wed, Mar 29, 2006 at 11:15:27AM +0100, Simon Marlow wrote:
> On 29 March 2006 09:11, John Meacham wrote:
>
> > It would be nice if we can deprecate the not very informative 'safe'
> > and 'unsafe' names and use more descriptive ones that tell you what is
> > actually allowed.
> >
> > 'reentra
On 29 March 2006 11:00, Ross Paterson wrote:
> On Tue, Mar 28, 2006 at 10:25:04AM +0100, Simon Marlow wrote:
>> On 28 March 2006 00:24, Ross Paterson wrote:
>>> How about STM (minus retry/orElse) and TVars as the portable
>>> interface? They're trivial for a single-threaded implementation, and
>>>
On 29 March 2006 09:11, John Meacham wrote:
> It would be nice if we can deprecate the not very informative 'safe'
> and 'unsafe' names and use more descriptive ones that tell you what is
> actually allowed.
>
> 'reentrant' - routine might call back into the haskell run-time
> 'blockable' - rout
On Tue, Mar 28, 2006 at 10:25:04AM +0100, Simon Marlow wrote:
> On 28 March 2006 00:24, Ross Paterson wrote:
> > How about STM (minus retry/orElse) and TVars as the portable
> > interface? They're trivial for a single-threaded implementation, and
> > provide a comfortable interface for everyone.
>
On Tue, Mar 28, 2006 at 11:05:03AM +0100, Malcolm Wallace wrote:
> I was misled by several people's hand-waving assertion that, provided
> you used MVars "correctly", there would be no synchronisation problems.
> But no-one had yet defined what "correct" meant. I kind of assumed they
> meant you c
On Mon, Mar 27, 2006 at 03:36:55PM +0100, Simon Marlow wrote:
> But before we get carried away figuring out all the pros and cons of
> various options, let me point out once again that
>
> This is just a marketing decision
>
> Because
>
> (a) we're going to standardise concurrency anyway
c
It would be nice if we can deprecate the not very informative 'safe'
and 'unsafe' names and use more descriptive ones that tell you what is
actually allowed.
'reentrant' - routine might call back into the haskell run-time
'blockable' - routine might block indefinitly
and it is not to hard to im
37 matches
Mail list logo
