On Saturday 01 April 2006 16:26, Bulat Ziganshin wrote:
> priorities are also useful for solving other problems, where bounded
> queues can't help us. as i said, my own program contains one thread
> that reads thousands of files from disk and pushes their data into
> the queue. t
Hello Simon,
Friday, March 31, 2006, 4:57:19 PM, you wrote:
>>>> threadSetPriority :: ThreadID -> Int -> IO ()
>>
>> it was requested by Joel Reymont, and he even give us information how
>> that is implemented in Erlang, together with hint to assign highe
; that we don't have it in GHC, and people manage to do a lot without
>> priorities. Priorities come with a whole can of worms that I'd
>> rather not deal with.
>
> it was requested by Joel Reymont, and he even give us information how
> that is implemented in Erlan
On Fri, Mar 31, 2006 at 10:30:51AM +0100, Malcolm Wallace wrote:
> > threadSetPriority :: ThreadID -> Int -> IO ()
>
> In any case, if priorities were to be introduced, I would not use Ints
> to represent them. How many priority levels are sufficient? A partial
> or
> > Thinking about it some. I think we will need some sort of very basic
> > thread priorities.
>
> I'd rather not, if we can avoid it.
Agreed. If someone wants to provide them as an optional extra, fine.
(We had thread priorities In concurrent embedded Gofer, a long time
Hello Simon,
Friday, March 31, 2006, 12:24:23 PM, you wrote:
>> threadSetPriority :: ThreadID -> Int -> IO ()
> I'd rather not, if we can avoid it. The only rationale I'll offer is
> that we don't have it in GHC, and people manage to do a lot without
> prior
Hello John,
Friday, March 31, 2006, 5:48:30 AM, you wrote:
> threadSetPriority :: ThreadID -> Int -> IO ()
> with a small modification to the progress guarentee saying that when
> threads of different priorities are runnable, one of the threads of the
> highest priority will
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I'd rather not, if we can avoid it. The only rationale I'll offer is that we
> don't have it in GHC, and people manage to do a lot without priorities.
> Priorities come with a whole can of worms that I'd
On 31 March 2006 02:49, John Meacham wrote:
> Thinking about it some. I think we will need some sort of very basic
> thread priorities.
>
> honoring these priorities will be _manditory_ for cooperative
> implementations but advisory for preemptive ones that meet the
> f
Actually, they should definitly always be advisory. You can't easily
write a portable program that depends on either priorities working or
fairness for correctness, you would write your code differently in each
case. And schedules are intimately tied to an implementation so I
wouldn'
Thinking about it some. I think we will need some sort of very basic
thread priorities.
honoring these priorities will be _manditory_ for cooperative
implementations but advisory for preemptive ones that meet the fairness
guarentees. priorities are sometimes needed in cooperative systems to
On Wed, Feb 08, 2006 at 12:03:54PM +0300, Bulat Ziganshin wrote:
> JM> If we had a good standard poll/select interface in System.IO then we
> JM> actually could implement a lot of concurrency as a library with no
> JM> (required) run-time overhead. I'd really like to see such a thing get
> JM> into
Hello John,
Friday, February 03, 2006, 12:00:32 PM, you wrote:
JM> If we had a good standard poll/select interface in System.IO then we
JM> actually could implement a lot of concurrency as a library with no
JM> (required) run-time overhead. I'd really like to see such a thing get
JM> into the sta
On 03 February 2006 16:03, John Goerzen wrote:
> I know, of course, that Java green threads and Haskell forkIO threads
> are called "threads", but I personally believe its misleading to call
> it concurrency -- they're not doing more than one thing at a time.
We use the terms "concurrency" and "p
On 05 February 2006 00:21, Benjamin Franksen wrote:
> On Friday 03 February 2006 08:52, Tomasz Zielonka wrote:
>> On Thu, Feb 02, 2006 at 01:05:57PM +, Ross Paterson wrote:
>>> Personally, I'm not sure about caseless underscore, concurrency,
>>> natural numbers and parallel list comprehensions
On 05/02/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> Hello Tomasz,
>
> Sunday, February 05, 2006, 2:45:44 PM, you wrote:
>
> >> > We don't have any problems with ensuring good cooperation between
> >> > mutable variables and concurrency synchronisation primitives, because
> >> > the language d
Hello Tomasz,
Sunday, February 05, 2006, 2:45:44 PM, you wrote:
>> > We don't have any problems with ensuring good cooperation between
>> > mutable variables and concurrency synchronisation primitives, because
>> > the language doesn't have mutable variables, they are delivered in
>> > the concur
On Sun, Feb 05, 2006 at 01:21:08AM +0100, Benjamin Franksen wrote:
> > We don't have any problems with ensuring good cooperation between
> > mutable variables and concurrency synchronisation primitives, because
> > the language doesn't have mutable variables, they are delivered in
> > the concurren
On Friday 03 February 2006 08:52, Tomasz Zielonka wrote:
> On Thu, Feb 02, 2006 at 01:05:57PM +, Ross Paterson wrote:
> > Personally, I'm not sure about caseless underscore, concurrency,
> > natural numbers and parallel list comprehensions.
>
> There is one more reason to leave concurrency out
On Sat, Feb 04, 2006 at 01:40:26PM +0300, Bulat Ziganshin wrote:
> GHC's libs (including handling of Handles) check "threaded" at
> run-time just to have one common compiled library instead of two ones
Yeah, but I don't expect a common compiled library between
different implementations.
Jo
Hello John,
Friday, February 03, 2006, 8:11:48 PM, you wrote:
>> Yes. Plus, I'd say, the presence of threading primitives that return
>> certain well-defined exceptions or something along those lines, so that
>> it's not necessary to know whether multithreading is supported at
>> compile time.
On Fri, Feb 03, 2006 at 11:18:58AM -0600, John Goerzen wrote:
> On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
> > On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
> > > I know, of course, that Java green threads and Haskell forkIO threads
> > > are called "threads",
Hello Tomasz,
Friday, February 03, 2006, 2:00:23 PM, you wrote:
>> >> Personally, I'm not sure about caseless underscore, concurrency, natural
>> >> numbers and parallel list comprehensions.
>>
>> TZ> The design of Haskell was so great, that we could add concurrency as
>> TZ> a library w
On 2006-02-03, John Goerzen <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
>> On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
>> > I know, of course, that Java green threads and Haskell forkIO threads
>> > are called "threads", but I pers
On Fri, Feb 03, 2006 at 05:56:41PM +0100, Tomasz Zielonka wrote:
> On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
> > I know, of course, that Java green threads and Haskell forkIO threads
> > are called "threads", but I personally believe its misleading to call it
> > concurrency --
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
> On Fri, Feb 03, 2006 at 01:00:32AM -0800, John Meacham wrote:
> > On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
> > > The interface can be a library, but (a) what libraries are available is
> > > part of the langu
On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
> Maybe this is just me being dense, but how is poll or select
> concurrency? There is no multiprocessing involved; it is simply a more
> efficient way to find which file descriptors are ready for some I/O
> action.
>
> I know, of cour
On Fri, Feb 03, 2006 at 12:00:23PM +0100, Tomasz Zielonka wrote:
> > TZ> The design of Haskell was so great, that we could add concurrency as
> > TZ> a library without introducing any problems... but we have
> > TZ> concurrency in the standard anyway...
> >
> > concurrency should go in
On Fri, Feb 03, 2006 at 01:00:32AM -0800, John Meacham wrote:
> On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
> > The interface can be a library, but (a) what libraries are available is
> > part of the language definition and (b) it's hard to build a good
> > implementation wi
On Fri, Feb 03, 2006 at 12:43:24PM +0300, Bulat Ziganshin wrote:
> Friday, February 03, 2006, 10:52:22 AM, you wrote:
>
> >> Personally, I'm not sure about caseless underscore, concurrency, natural
> >> numbers and parallel list comprehensions.
>
> TZ> The design of Haskell was so great, that
On Fri, 3 Feb 2006, Ross Paterson wrote:
As another example, Ben Rudiak-Gould recently pointed out that the
inclusion of stToIO breaks threaded state reasoning for ST, e.g.
readSTRef won't necessarily get what your last writeSTRef wrote (because
the region might be RealWorld, with other threads
Hello Tomasz,
Friday, February 03, 2006, 10:52:22 AM, you wrote:
>> Personally, I'm not sure about caseless underscore, concurrency, natural
>> numbers and parallel list comprehensions.
TZ> The design of Haskell was so great, that we could add concurrency as
TZ> a library without introdu
On Fri, Feb 03, 2006 at 10:20:01AM +0100, Tomasz Zielonka wrote:
> Even if concurrency is part of Haskell', it should still be clear
> that it doesn't affect the definition of non-concurrent Haskell' subset
> at all (is that true?). For example, all pure functions will be entirely
> thread-safe.
A
On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
> | Some experts (like Hans Boehm) argue, that concurrency can't be added
> to
> | the language as a library.
> | http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
> |
> | This is true for many imperative programming lan
On Fri, Feb 03, 2006 at 08:40:27AM -, Simon Peyton-Jones wrote:
> The interface can be a library, but (a) what libraries are available is
> part of the language definition and (b) it's hard to build a good
> implementation without runtime support. And the nature of the runtime
> support depend
| Some experts (like Hans Boehm) argue, that concurrency can't be added
to
| the language as a library.
| http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
|
| This is true for many imperative programming languages. Haskell seems
| to be an exception:
|
http://www.haskell.org//pipermail/
On Thu, Feb 02, 2006 at 01:05:57PM +, Ross Paterson wrote:
> Personally, I'm not sure about caseless underscore, concurrency, natural
> numbers and parallel list comprehensions.
There is one more reason to leave concurrency out of the standard.
Some experts (like Hans Boehm) argue, that concu
On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote:
> For the last few days, my mail-box has been full of mail about the M-R,
> lazy pattern
> matching, n+k patterns, comment syntax--it's just like the good old
> days! And that
> worries me.
>
> Each of these topics is a snake pit--a tricky ar
I'd like to see clearer priorities and a more focussed discussion--maybe the
> Wiki can be used to help?
As a small part of that, the tickets page has a tentative list of
"probably yes" changes.
Personally, I'm not sure about caseless underscore, concurrency, natural
nu
> Haskell'. It also uses multi-parameter classes and functional dependencies,
> although much less heavily.
My priorities for Gtk2Hs (the second most popular GUI toolkit in John
Hughes's survey) are very similar. We have adopted wxHaskell's style of
attributes which is what uses e
John Hughes wrote:
> The problem with Haskell 98 is that it *lacks* features which
> have become absolutely essential to Haskell programmers today. Those
> features are what really *need* discussion and energy spent on them.
Very well, but this looks like a discussion for implementors and
languag
ith
Haskell 98 is not its warts--it offers a very pleasant programming
experience
despite them. The problem with Haskell 98 is that it *lacks* features which
have become absolutely essential to Haskell programmers today. Those
features are what really *need* discussion and energy spent on them.
What a
42 matches
Mail list logo
