Re[2]: Priorities

2006-02-08 Thread Bulat Ziganshin
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: Re[2]: Priorities

2006-02-05 Thread Cale Gibbard
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

2006-02-04 Thread Bulat Ziganshin
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[2]: Priorities

2006-02-03 Thread Bulat Ziganshin
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[2]: Priorities

2006-02-03 Thread Bulat Ziganshin
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