Re[4]: thread priorities?
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 higher priorities to consuming threads. Yes, but the Erlang implementation doesn't do anything about priority inversion. Also, I don't think Joel really wanted priorities, his problem could have been solved by using bounded channels. to be exact, his problem (1000 producers and one consumer) can be solved ONLY by using some bounded queue. but for typical usage when there are one or several producers and one consumer, priorities allow to solve problem: 1) in easier and more intuitive way, that is well known from other environments (Unix, for example) 2) without introducing new data structures - bounded channels, bounded priority queues and so on, so on (although it should be easy to construct them) 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. then other threads process these data. as you can see, first thread is I/O-bound while other is CPU-bound. of course, i want to give higher priority to the first thread so that it reads next portion of data as soon as previous read operation is complete (and there is free buffer). how can i accomplish it with current ghc implementation? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: thread priorities?
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 rather not deal with. Thread priorities are somewhere between important and necessary for hOp/House. I haven't seen them really required elsewhere though. -- I've tried to teach people autodidactism,| ScannedInAvian.com but it seems they always have to learn it for themselves.| Shae Matijs Erisson ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Re[2]: thread priorities?
On 31 March 2006 10:24, Bulat Ziganshin wrote: 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 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 Erlang, together with hint to assign higher priorities to consuming threads. Yes, but the Erlang implementation doesn't do anything about priority inversion. Also, I don't think Joel really wanted priorities, his problem could have been solved by using bounded channels. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
thread priorities?
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 ensure certain things get run, but the fairness guarentees of preemptive systems make them less important. Another reason to make them advisory in preemptive implementations is because they might be using OS level threads and hence not have their own scheduler to tweak priorities in. I am thinking threadSetPriority :: ThreadID - Int - IO () threadSetPriority = ... 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 be running. we should also say something about priority inheritance via MVars... but perhaps this is too complicated for the spec and should be left up to the implementations (or just make it always advisory). let me know what y'all think. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Priorities
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 standard. Well, mainly it would just be a really useful thing JM to have in general. If others think it is a good idea I can try to come JM up with a suitable API and submit it to the repo. i have delayed answering to this letter until i announced my Streams library. now i can say that such API already exists - in terms of my library you need just to write an transformer that intercepts vGetBuf/vPutBuf calls and pass them to the select/poll machinery. so you can write such transformer just now and every program that uses Streams will benefit from its usage. Converting programs that use Handles to using Streams should be also an easy task. of course, Streams library is not some standard just now, and moreover - it is not compatible with JHC. the greatest problem is what i using type classes extensions available in GHC/Hugs what is not in H98 standard. so, i'm interested in pushing Haskell' to accept most advanced possible extensions in this area and, of course, in actual implementing these extensions in the Haskell compilers. alternative way to make Streams available to wider range of Haskell compilers is to strip support of streams working in monads other that IO. if you can make select/poll transformer, at least for testing purposes, that will be really great. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 the standard. Well, mainly it would just be a really useful thing JM to have in general. If others think it is a good idea I can try to come JM up with a suitable API and submit it to the repo. i have delayed answering to this letter until i announced my Streams library. now i can say that such API already exists - in terms of my library you need just to write an transformer that intercepts vGetBuf/vPutBuf calls and pass them to the select/poll machinery. so you can write such transformer just now and every program that uses Streams will benefit from its usage. Converting programs that use Handles to using Streams should be also an easy task. I was actually asking for something much more modest, which was the routine needed to pass them to the select/poll machinery. but yeah, what you say is one of my expected uses of such a routine. Once a standard IO library settles down, then I can start working on the exact API such a routine would have. of course, Streams library is not some standard just now, and moreover - it is not compatible with JHC. the greatest problem is what i using type classes extensions available in GHC/Hugs what is not in H98 standard. so, i'm interested in pushing Haskell' to accept most advanced possible extensions in this area and, of course, in actual implementing these extensions in the Haskell compilers. alternative way to make Streams available to wider range of Haskell compilers is to strip support of streams working in monads other that IO. Don't take the absence of a feature in jhc to mean I don't like or want that feature. There are a lot of things I don't have but that I'd definitly want to see in the language simply because I was only shooting for H98 to begin with and was more interested in a lot of the back end stuff. You should figure out the nicest design that uses just the extensions needed for the design you want. it could help us decide what goes into haskell-prime to know what is absolutely needed for good design and what is just nice to have. if you can make select/poll transformer, at least for testing purposes, that will be really great. Yeah, I will look into this. the basic select/poll call will have to be pretty low level, but hopefully it will allow interesting higher level constructs based on your streams or an evolution of them. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Priorities
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 parallelism to mean two completely distinct concepts, as others have pointed out. Concurrency means structuring your program as multiple independent threads of control, which are independent of each other and can interact in non-deterministic ways. Parallelism means running computations simultaneously on multiple processors - you can run a concurrent program in parallel, but you can also use parallelism to speed up single-threaded programs. Well, I must admit to being confused at the present state of things. Right now, we have forkIO, which seems, to me, like a fancy wrapper around select or poll. It's very nice, really. I'm not clear, though, on how to integrate other C libraries that have their own async I/O systems into all of this. (For instance, LDAP or SQL libraries) We do have a nice story for all this, probably nicer than in any other language implementation you'll come across. GHC gives you both the performance from lightweight threads, combined with the ability to use OS-level concurrency for invoking FFI calls that might block, such as the SQL or LDAP libraries you refer to . In these cases you don't have to incorporate the library's file descriptors into one Giant Select, you just make a blocking call to the library. The runtime makes sure it happens in a different OS thread, so it doesn't block any of your Haskell threads. Lightweight threads by default, OS threads when needed. The exact interaction between FFI, forkIO, forkOS, etc. is, to me, extremely vague right now. It also seems much more complex than in other languages, and perhaps varies from one Haskell implementation to the next. There is only one Haskell implementation that really does concurrency. Hugs has cooperative concurrency, but that's pretty limited (I don't think it does I/O, for example). The story is more complex than in other languages, but I think it's largely a matter of documentation, the design has been very carefully thought out: http://www.haskell.org/~simonmar/papers/conc-ffi.pdf I'm glad you pointed out that you find the situation confusing, I'll definitely try to improve the documentation. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 concurrency library - the variables _are_ the synchronisation primitives. What about IORefs? They are not part of Haskell 98 ;-) The question is if they will be added to Haskell'? I guess they will, so you have a point here. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Priorities
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 doesn't have mutable variables, they are delivered in the concurrency library - the variables _are_ the synchronisation primitives. What about IORefs? TZ They are not part of Haskell 98 ;-) TZ The question is if they will be added to Haskell'? I guess they will, so TZ you have a point here. the _language_ anyway don't have mutables, it's a part of library Well, sort of. I suppose it's the same issue as with concurrency itself. It's a library with runtime support. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Priorities
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. JM Also, I can't think of any reason you would ever want to defer such a JM decision to run time. either your program needs concurrency and thus JM should fail at compile time if it isn't available or it just needs to be JM concurrent-safe in which case it will succeed and work portably because JM we have included the primitives needed to allow that. GHC's libs (including handling of Handles) check threaded at run-time just to have one common compiled library instead of two ones -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Priorities
| 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/glasgow-haskell-users/2005-December/00 9417.html 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 depends on what the library interface is. So a programmer asks can I write my Haskell' program using concurrency?. To answer that question, concurrency needs to be specified as part of Haskell', just as (say) Integer and its operations do. [Of course, we can choose not to; and then Haskell' programs will be single-threaded.] Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 depends on what the library interface is. If we had a good standard poll/select interface in System.IO then we actually could implement a lot of concurrency as a library with no (required) run-time overhead. I'd really like to see such a thing get into the standard. Well, mainly it would just be a really useful thing to have in general. If others think it is a good idea I can try to come up with a suitable API and submit it to the repo. My main issue with actually requiring concurrency is that it implies some very non-trivial runtime overhead. at least as implemented by ghc. of course, since ghc already uses indirect functions for all of its thunk evaluations, it effectivly gets the ability to do concurrency 'for free'. But this is certainly not true of all run-time models. There was an interesting paper on implementing abstract interpreters that showed on modern architectures although indirect function calls only are 5-10% of the instructions executed, they account for well more than half of the time spent in a program. in ghc generated assembling I am guessing they are more like 30-40% of calls (the fact that ghc gets such great performance despite this is quite promising for its future! I hope a common c-- back end can be developed and shared among haskell implementations that is particularly good at optimizing the type of code we like to produce. But I have limited myself to writing one compiler at a time for the time being :) .) What I would really like to see come out of this process as it relates to concurrency are: the ability to write thread-safe (but not thread using) libraries portably. which means MVars and foreign annotations but nothing more. A nice, well thought out standardized poll/select/asynchronous IO library as part of System.IO. this will fill a much needed gap between full concurrency and synchronous IO which is currently a void and will provide just enough run-time support for experimenting with portable concurrency libraries. a method of standardizing extensions independent of the language and getting them approved as official, optional features, concurrency is really interesting and I'd hate to bog it down by forcing it to evolve at the haskell standards pace :) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 languages. Haskell seems | to be an exception: | http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December/00 9417.html 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 depends on what the library interface is. I forgot about runtime support. My point is that you we able to introduce a library/runtime support without changing the semantics of the language, and it works well. So a programmer asks can I write my Haskell' program using concurrency?. To answer that question, concurrency needs to be specified as part of Haskell', just as (say) Integer and its operations do. [Of course, we can choose not to; and then Haskell' programs will be single-threaded.] Yes, you are right. I was not entirely serious in my argumentation ;-) 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. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Priorities
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 introducing any problems... but we have TZ concurrency in the standard anyway... concurrency should go into the Standard Library specification. there is just nothing to say about this in the _language_ standard -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: concurrency (was Re: Priorities)
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 modifying it). You can still reason about something of type ST s a, it's just with the proviso that the reasoning is only correct when it is (perhaps indirectly) invoked by runST. Cheers, Ganesh ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 we could add concurrency as TZ a library without introducing any problems... but we have TZ concurrency in the standard anyway... concurrency should go into the Standard Library specification. there is just nothing to say about this in the _language_ standard Agreed! Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 without runtime support. And the nature of the runtime support depends on what the library interface is. If we had a good standard poll/select interface in System.IO then we actually could implement a lot of concurrency as a library with no (required) run-time overhead. I'd really like to see such a thing get 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 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. the ability to write thread-safe (but not thread using) libraries portably. which means MVars and foreign annotations but nothing more. 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. A nice, well thought out standardized poll/select/asynchronous IO library as part of System.IO. this will fill a much needed gap between full concurrency and synchronous IO which is currently a void and will provide just enough run-time support for experimenting with portable concurrency libraries. Well, I must admit to being confused at the present state of things. Right now, we have forkIO, which seems, to me, like a fancy wrapper around select or poll. It's very nice, really. I'm not clear, though, on how to integrate other C libraries that have their own async I/O systems into all of this. (For instance, LDAP or SQL libraries) The exact interaction between FFI, forkIO, forkOS, etc. is, to me, extremely vague right now. It also seems much more complex than in other languages, and perhaps varies from one Haskell implementation to the next. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 into the Standard Library specification. there is just nothing to say about this in the _language_ standard Agreed! We should be careful to not take too narrow a view of the meaning of the word language, or at least not in the public output of this group. Many people would, for instance, consider the standard set of libraries in Java to be part of the language. The same could be said for Perl and Python. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 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. Aren't you thinking about Parallellism? http://en.wikipedia.org/wiki/Concurrency_%28computer_science%29 In computer science, concurrency is a property of systems which consist of computations that execute overlapped in time http://en.wikipedia.org/wiki/Parallel_programming Parallel computing is the simultaneous execution of the same task (split up and specially adapted) on multiple processors in order to obtain results faster. This agrees with what I have read in many texts on the subjects. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 language definition and (b) it's hard to build a good implementation without runtime support. And the nature of the runtime support depends on what the library interface is. If we had a good standard poll/select interface in System.IO then we actually could implement a lot of concurrency as a library with no (required) run-time overhead. I'd really like to see such a thing get 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. Yeah, it doesn't. however I thought I'd bring it up becauese it is related and is a hole in the current haskell set up. even on implementations with concurrency such a thing is useful as many tasks actually are easier to implement by hand this way when you need fine control over scheduling and whatnot. It's not so much that it's a more efficient way as its the only way for any serious application. GHCs concurrency is a nice interface to it, but it is quite high-level and access to the functionality at a medium level in a standardized way would be quite beneficial and allow all the state threaded style programs without necesarisy needing full blown concurrency. Also, providing hPoll is as simple as any FFI wrapper with no implemenation consequences othen than additions to the library so it is quite a bargain indeed for what you get. 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. this whole field is rife with ambiguous terminology. it has already been a source of confusion several times. I think 'state-threads' are the accepted term for this sort of thread, but am unsure. the ability to write thread-safe (but not thread using) libraries portably. which means MVars and foreign annotations but nothing more. 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. It would be odd to have routines in the standard that are only standardized to fail :). We couldn't include those in the standard without saying what their correct behavior is when they worked, which is exactly the task I don't think we can acomplish. Actually, I think it would be difficult to even specify what those primitives are, let alone their exact semantics. Also, I can't think of any reason you would ever want to defer such a decision to run time. either your program needs concurrency and thus should fail at compile time if it isn't available or it just needs to be concurrent-safe in which case it will succeed and work portably because we have included the primitives needed to allow that. Right now, we have forkIO, which seems, to me, like a fancy wrapper around select or poll. It's very nice, really. I'm not clear, though, on how to integrate other C libraries that have their own async I/O systems into all of this. (For instance, LDAP or SQL libraries) this is a well known issue even outside of haskell land. various solutions have evolved, the glib main loop, liboop, libevent, if ghc were to switch to one then that would allow some sort of interoperability but none are perfect, and each is mutually exclusive in general. this is another reason I feel a hPoll is important, because its low level control is often needed for interacting with other libraries in tricky situations like this. The exact interaction between FFI, forkIO, forkOS, etc. is, to me, extremely vague right now. It also seems much more complex than in other languages, and perhaps varies from one Haskell implementation to the next. I am positive it varies, even if there were a (somewhat odd) concerted effort to emulate ghcs behavior, I doubt others would get it right any time soon. It is just such a tricky field! All languages have issues here, some are better at hand waving them away though or just ignoring them. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 -- they're not doing more than one thing at a time. Aren't you thinking about Parallellism? No. http://en.wikipedia.org/wiki/Concurrency_%28computer_science%29 In computer science, concurrency is a property of systems which consist of computations that execute overlapped in time You're not doing anything simultaneously (overlapped in time) when you're using poll and select (only). To do something simultaneously in Unix, you'd have to either use fork() or start a thread. -- John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 personally believe its misleading to call it concurrency -- they're not doing more than one thing at a time. Aren't you thinking about Parallellism? No. http://en.wikipedia.org/wiki/Concurrency_%28computer_science%29 In computer science, concurrency is a property of systems which consist of computations that execute overlapped in time You're not doing anything simultaneously (overlapped in time) when you're using poll and select (only). To do something simultaneously in Unix, you'd have to either use fork() or start a thread. That was his point. Threading is a way of structuring a program. Parallelism is a strategy for exploiting that structuring (and others). -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Priorities
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 without introducing any problems... but we have TZ concurrency in the standard anyway... concurrency should go into the Standard Library specification. there is just nothing to say about this in the _language_ standard TZ Agreed! well, there is just one exception - _foreign_ functions should carry blockable specification. that will only emphasize imperfection of non-Haskell world :))) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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, but I personally believe its misleading to call it concurrency -- they're not doing more than one thing at a time. Aren't you thinking about Parallellism? No. http://en.wikipedia.org/wiki/Concurrency_%28computer_science%29 In computer science, concurrency is a property of systems which consist of computations that execute overlapped in time You're not doing anything simultaneously (overlapped in time) when you're using poll and select (only). To do something simultaneously in Unix, you'd have to either use fork() or start a thread. Concurrent computations can be sliced into smaller pieces and interleaved - so there is no need to perform many things simultaneously. That's how Unix works on uniprocessors - at every time point the CPU is executing at most one task. Are you arguing that uniprocessor Unix doesn't provide concurrency? There are some differences between Unix and GHC process scheduling (I think that in some special cases GHC's threads can't be preempted, eg. in tight loops without allocations), but they are not that big. The point is that on a uniprocessor everything is performed sequentially at some level. When we talk about Unix, it's the level of OS implementation, with GHC it's the level of RTS. Yet in both cases we get quite a good impression of concurrent execution, and it's rather more productive to think in terms of concurrency. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Priorities
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 area of language design, with many alternative possibilities and no clear winner. As such, they make great discussion topics--if you want to start a heated argument, just propose a change to one of these (mea culpa)! We've also been discussing most of them for sixteen years. Of course, it's worth raising them from time to time, in case new insight means we can find a solution that is clearly much better than we found before. But the risk is that we go over the same old arguments, perhaps the consensus is slightly different this time, we make a change to the language, and who knows, next time the language is revised, maybe it'll change back again! That's destructive. We shouldn't change these things unless we can very, very clearly make an improvement. The fact is, we've lived with the present design for over a decade in each case, and we can live with it for another decade if we have to. The problem with 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 are the top priorities for inclusion in a new standard? How can we identify them? I have some personal favourites, of course: ST state threads--absolutely essential. - but how to distinguish strict and lazy state? The present solution--importing a different module--sucks. Monad transformers - dramatically simplify constructing new monads - not a language feature in themselves, but demand extensions to work well. Multi-parameter classes with functional dependencies - used everywhere... for example in monad transformers... so *must* be included this time - omitted from Haskell 98 because the right design wasn't clear - it's still unclear! Functional dependencies *in some form* are essential, but associated types and datatypes look nicer in many ways! - is it too late, in practice, to replace fundeps by something else? How will we know? If we are to standardize on associated types instead, we need a major effort to *make sure* all important applications of fundeps can be represented. How will we organize that? Type system extensions--at least existential and rank-2 types. - should we go further? How will we know? My favourites may not be your favourites. How will we know what the most important features to discuss are? Here's a thought: Wouldn't it be nice if the most important Haskell tools and libraries, were actually written in standard-compliant Haskell'? One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in Haskell'. It also uses multi-parameter classes and functional dependencies, although much less heavily. What other tools must be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come? I'd like to see clearer priorities and a more focussed discussion--maybe the Wiki can be used to help? John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote: One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in 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 existential types. I should not that in both cases the use of existential types is not essential. It was done that way only because the symbol that people wnated to use ':=' happens to be a constructor operator. If '=:' were used instead then existential construcotr types would not be necessary. We might make use of MPC +FunDeps if they were standard but it is not at all crucial. Our main concern is namespace issues. As I've said before, Gtk2Hs is a very large library but with the current module system it must export a flat name space. wxHaskell solves this with somewhat of a hack. It defines many multi-parameter type classes to allow the same name to be used by different widgets (with hopefully the same general meaning). I think this would be better solved by using qualified names. We have been trying hard to avoid non-H98isms so that we can hope to work with compilers other than ghc. So having these features standardised would allow us to present a better api and allow us to remain portable. What other tools must be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come? Another gripe is in the FFI, in the handling of include files. The method preferred by GHC and the method preferred by the FFI spec are rather at odds. GHC prefers the file to be specified on the command line while the FFI spec prefers it to be specified in each and every FFI import declaration. If one does the latter then GHC refuses to inline foreign calls across modules. Other mundane but useful things include the ability to specify different FFI import decls for different platforms without using #ifdef's. This would allow a program using a Gtk2Hs GUI to be compiled to bytecode with YHC and run on different platforms, rather than having to be built differently on each platform. (The issue is that even for portable C libs, the calling convention and symbol names can differ across platforms. This is true to a minor degree with the Gtk+ library.) Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Thu, Feb 02, 2006 at 11:38:07AM +0100, 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. [...] 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 numbers and parallel list comprehensions. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
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 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/glasgow-haskell-users/2005-December/009417.html 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 concurrency library - the variables _are_ the synchronisation primitives. If we add concurrency to the standard, we'll be in a strange situation. In future discussions about language design and concurrency, all we will be able to say to highlight Haskell's strengths will be something like this: The design of Haskell was so great, that we could add concurrency as a library without introducing any problems... but we have concurrency in the standard anyway... ;-) Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
