IMPORTANT NOTE: Registration is now available at: http://www.cs.ioc.ee/tfp-icfp-gpce05/ CUFP 2005 THE SECOND ACM SIGPLAN COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING WORKSHOP http://www.galois.com/cufp/ Talinn, Estonia September 24th 2005 Co-located with ICFP http://www.brics.dk/~danvy/icfp05/ ---------------------------------------------------------------------- Important dates Early registration deadline July 29, 2005 Late registration deadline September 2, 2005 Workshop September 24, 2005 Registration is available at: http://www.cs.ioc.ee/tfp-icfp-gpce05 ---------------------------------------------------------------------- The goal of CUFP is to build a community for users of functional programming languages and technology, be they using functional languages in their professional lives, in an open source project (other than implementation of functional languages), as a hobby, or any combination thereof. In short: anyone who uses functional programming as a /means/, but not an /end/. ---------------------------------------------------------------------- Schedule The meeting will last a full day, with a mix of invited presentations and discussion sessions. This year, we have the following confirmed speakers: * Atrijus Tang; talking about PUGS, a Perl6 implementation, written in Haskell; * Fabrice Le Fessant; talking about MLDonkey, a popular multi-platform, multi-network P2P client written in OCaml. * Michael Sperber; talking about uses of Scheme in the banking industry. * David Roundy; talking about darcs, a popular and flexible revision control system well-suited to highly distributed development, written in Haskell. * Jim Grundy; talking his experiences with functional programming at Intel's Strategic CAD Labs. * Robert Boone; talking about his experiences at FreeScale. * Jonathan Soebel; talking about lessons the FP community can learn from the OMG's Model Driven Architecture (MDA) and its related marketing efforts. We will also be having two working sessions, where lively debate and brainstorming will be the order of the day: * FP, Education, and Industry: industry folks complain that there aren't enough FP folks being produced by schools, and educators complain that students don't see any point in studying FP if there are no jobs to be had. How can we break this stalemate? Simon Thompson of Functional and Declarative Programming in Education (FDPE05) will be joining us, and we'll be debriefing at FDPE05. * Stimulating a CUFP Community: we'd like the buzz and excitement surrounding CUFP to persist beyond the workshops. What would such a community look like? How do we make it happen? The session will kick off with two separate but complimentary starting points: a proposed "Users of FP" community web site and a proposed "Haskell Consortium" web site. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. A full report of last year's workshop appeared in the Functional Programming column of the December 2004 issue of SIGPLAN Notices, and we plan to do the same this year. -- Andy Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran@galois.com
Hi, i have the following f :: [a] -> IO a f xs = do m <- newMVar c1 <- forkIO f1 xs m c2 <- forkIO f2 xs m c3 <- forkIO f3 xs m c<- takeMVar m killThread c1 killThread c2 killThread c3 return c co (x:xs) Šc == 1 = 1: co xs Šotherwise = (-1): co xs where c = unsafePerformIO (f (x:xs)) is it safe to use unsafePerformIO that way ? Please tell me why if it is not. Cheers _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters
On Friday 29 Jul 2005 4:01 pm, Dinh Tien Tuan Anh wrote:
Hi, i have the following
f :: [a] -> IO a f xs = do m <- newMVar c1 <- forkIO f1 xs m c2 <- forkIO f2 xs m c3 <- forkIO f3 xs m c<- takeMVar m killThread c1 killThread c2 killThread c3 return c
co (x:xs) c == 1 = 1: co xs otherwise = (-1): co xs where c = unsafePerformIO (f (x:xs))
is it safe to use unsafePerformIO that way ? Please tell me why if it is not.
It depends on whether or not f behaves like a function. AFAICS it is safe provided.. f always returns the same value for a given argument list and.. f has no observable side effects. It looks to me like what you're trying to do is run three parallel evaluation algorithms and take the answer from whichever one delivers an answer first (via the MVar, which should be empty initially). So as long as.. f1,f2,f3 all deliver the same answer (if they deliver an answer at all) and that answer depends on nothing but xs and none of them have any observable side effects then I guess you're probably safe. Regards -- Adrian Hey
AFAICS it is safe provided.. f always returns the same value for a given argument list and.. f has no observable side effects.
What are called "side effects" ?
It looks to me like what you're trying to do is run three parallel evaluation algorithms and take the answer from whichever one delivers an answer first (via the MVar, which should be empty initially).
Yes, thats what im trying to do
f1,f2,f3 all deliver the same answer (if they deliver an answer at all) and that answer depends on nothing but xs and none of them have any observable side effects then I guess you're probably safe.
depends on value of the first two elements of the list, f1, f2 and f3 will return three different values. So is it safe ? _________________________________________________________________ Winks & nudges are here - download MSN Messenger 7.0 today! http://messenger.msn.co.uk
On 8/1/05, Dinh Tien Tuan Anh
depends on value of the first two elements of the list, f1, f2 and f3 will return three different values. So is it safe ?
If "f xs" always returns the same value for a given xs, then it's safe. Doesn't look like that's the case here, though, since depending on the GHC runtime scheduler f1 may finish first in one case, and then the next time f2 may finish first, meaning that f xs will return two different results for the same xs. So that's not safe, and thus it should be in the IO monad. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
So that's not safe, and thus it should be in the IO monad.
How can i handle a lazy list with IO monad. For example, function co (x:xs) Šc ==1 = 1:co (xs) Šc == 2 = 0:co (xs) where c = unsafePerformIO(f (x:xs)) will be written without unsafePerformIO: co' (x:xs) = do c1 <- co' xs c<- f (x:xs) if (c==1) then return 1:c1 else return 0:c1 AFAICS, co' does not do lazy evaluation, so wont print any element of the list. Can lazy evaluation be integrated with IO monad ? Cheers TuanAnh _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/
"Dinh Tien Tuan Anh"
will be written without unsafePerformIO: co' (x:xs) = do c1 <- co' xs c<- f (x:xs) if (c==1) then return 1:c1 else return 0:c1
You might want to use unsafeInterleaveIO :: IO a -> IO a. It allows IO computation to be deferred lazily. In the particular example co' (x:xs) = do c1 <- unsafeInterleaveIO (co' xs) c <- f (x:xs) if (c==1) then return (1:c1) else return (0:c1) - Einar Karttunen
participants (5)
-
Adrian Hey -
Andy Moran -
Dinh Tien Tuan Anh -
Einar Karttunen -
Sebastian Sylvan