[Haskell] haskell logo for webmasters
i created two haskell logos for websites to spread Haskell. http://xahlee.org/haskell/haskell-logo.html it's in public domain. suggestions welcome. Thanks. Xah [EMAIL PROTECTED] ∑ http://xahlee.org/ ☄ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Monads vs. continuations
On Oct 31, 2005, at 9:37 AM, Ben Rudiak-Gould wrote: I don't know if this helps, but there's a straightforward way to understand the IO monad in terms of continuation passing. You can think of a value of type IO a as being a CPS expression with a hole in it; the hole is to be filled with a continuation which expects a value of type a. The only way to fill the hole is by using >>=, whose second argument is a continuation with another (nested) hole in it. So effectively with >>= you build a CPS expression from the outside in. The final continuation, which takes () and aborts the program, is ultimately filled in by the runtime system. This viewpoint doesn't work for other monads, since they always provide some sort of destructuring operations on monadic values, e.g. runState or the standard list deconstructors. But it works fine for IO provided you ignore the existence of unsafePerformIO and friends. -- Ben No, that's definitely helpful. The analogy in the case of IO was obvious, but I had a sense that it was getting in the way of understanding what a monad is (i.e., by leading me to focus on the wrong issues). === Gregory Woodhouse [EMAIL PROTECTED] "One must act on what has not yet happened." --Lao Tzu ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Monads vs. continuations
On Oct 31, 2005, at 3:02 AM, Cale Gibbard wrote:
Perhaps you're referring to a monoid. Since you seem to have some
familiarity with category theory, check out
http://en.wikipedia.org/wiki/Monad_%28category_theory%29 for a formal
definition of monads and some background. Translating between
notation, μ = join and η = return in Haskell. The application of the
functor T to functions is called fmap, or liftM, which should always
be equivalent.
The functor behind a monad is always an endofunctor, that is, from the
category to itself. In this case, you'll be interested in the category
of Haskell types and Haskell-definable functions between them.
This was actually quite helpful. If someone had told me that a monad
was a functor in the first place, this would all have been much less
mysterious. (BTW, I have indeed encountered adjoint functors, Hom and
Tensor, in the context of algebraic topology, so the article did
leave me with a bit more of a sense of having my feet on the ground.)
For a much gentler description and one way in which monads relate to
programming, check out
http://www.haskell.org/hawiki/MonadsAsContainers which is an article
that I wrote.
This is an excellent article! I found it extremely useful and lucid.
To be sure, it's going to take a bit more time to let all these ideas
sink in, but I liked the approach of focusing on fmap and join (>>=
always seemed mysterious). Believe it or not, though I've read that
lists are monads, this is perhaps the first time I've seen it spelled
out just how.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"It is foolish to answer a question that
you do not understand."
--G. Polya ("How to Solve It")
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Monads vs. continuations
I don't know if this helps, but there's a straightforward way to understand the IO monad in terms of continuation passing. You can think of a value of type IO a as being a CPS expression with a hole in it; the hole is to be filled with a continuation which expects a value of type a. The only way to fill the hole is by using >>=, whose second argument is a continuation with another (nested) hole in it. So effectively with >>= you build a CPS expression from the outside in. The final continuation, which takes () and aborts the program, is ultimately filled in by the runtime system. This viewpoint doesn't work for other monads, since they always provide some sort of destructuring operations on monadic values, e.g. runState or the standard list deconstructors. But it works fine for IO provided you ignore the existence of unsafePerformIO and friends. -- Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Monads vs. continuations
On 31/10/05, Gregory Woodhouse <[EMAIL PROTECTED]> wrote: > Newbie alert: > > I have some superficial familiarity with continuations as they occur > in traditional denotational semantics, but certainly not a deep > understanding. I also have a special interest in distributed and/or > concurrent processing, so it only seemed natural to me that the monad > concept was one I'd want to confront head on. Now, I warn you: I am > quite new to Haskell (though I have some prior exposure to Scheme and > a background in mathematics). Now, I've just started reading through > Thompson's text and came across this example: > > goUntilEmpty :: IO () > goUntilEmpty > = do line <- getLine > if (line == []) > then return () >else (do putStrLn line > goUntilEmpty) > > Okay, this seems sensible enough. Loosely speaking, I see this code > as getting a line, checking to see if it's empty. If it is, it just > quits (returning the "empty" value). Otherwise, it prints line, and > invokes itself through a *new* do statement. That seems awfully like > using a continuation to track the input stream as part of the > environment. But it seems obvious to me that here is something I'm > not understanding here. I think of the do as providing an appropriate > continuation (one in which the line just read is gone) to pass to the > next call. > > Okay, maybe I'm taking things a bit too literally here, but I seem to > recall that a monad is an algebraic object with right and left > identity and an associative composition. I understand the monad here > takes a value (()) and returns an object IO (), and do becomes a > functor of sorts, taking ordinary functions and mapping them to new > functions having their codomain in a new category (an instance of a > monad?) This is where it seems to me that I must be getting the > terminology wrong. Can someone help me out here? Perhaps you're referring to a monoid. Since you seem to have some familiarity with category theory, check out http://en.wikipedia.org/wiki/Monad_%28category_theory%29 for a formal definition of monads and some background. Translating between notation, μ = join and η = return in Haskell. The application of the functor T to functions is called fmap, or liftM, which should always be equivalent. The functor behind a monad is always an endofunctor, that is, from the category to itself. In this case, you'll be interested in the category of Haskell types and Haskell-definable functions between them. For a much gentler description and one way in which monads relate to programming, check out http://www.haskell.org/hawiki/MonadsAsContainers which is an article that I wrote. For a different perspective on the programming aspects than presented by my article (both are important in practice) check out http://www.nomaware.com/monads/html/ Do notation is a shorthand for a bunch of algebraic operations which make the code look like imperative code. Desugaring goUntilEmpty results in something along the lines of: goUntilEmpty :: IO () goUntilEmpty = getLine >>= \line -> if line == [] -- better written as "null line" then return () else putStrLn line >>= \x -> goUntilEmpty where x >>= f = join (fmap f x), to write it in terms of the operations defined on wikipedia. Hope these links are useful to you :) - Cale ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Writing large n-dim un-boxed array of Int32 quickly?
From: Bulat Ziganshin <[EMAIL PROTECTED]> Hello Rene, Monday, October 31, 2005, 11:13:30 AM, you wrote: RdV> I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And RdV> also read it back later). how about fileWriteBuf/fileReadBuf? Hello Bulat, How does this work? (is this from NewBinary, I don't have the sources with me). How do I convert my array to a buffer? Rene. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Writing large n-dim un-boxed array of Int32 quickly?
From: Ketil Malde <[EMAIL PROTECTED]> Rene de Visser wrote: I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And also read it back later). hGetArray/hPutArray? To do this I need to cast my 5 dimensional array to a 1 dimensional array? Does this work? i.e. how do I know that GHC uses a flat array representation for multidemsional arrays (rather than a nested model using pointers). Rene. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Writing large n-dim un-boxed array of Int32 quickly?
Hello Rene, Monday, October 31, 2005, 11:13:30 AM, you wrote: RdV> Hello, RdV> I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And RdV> also read it back later). how about fileWriteBuf/fileReadBuf? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] FM'06 Announcement and Call for Submissions
FM'06: 14TH INTERNATIONAL SYMPOSIUM ON FORMAL METHODS 21 - 27 August 2006 McMaster University, Hamilton, Ontario, Canada http://fm06.mcmaster.ca/ ANNOUNCEMENT AND CALL FOR SUBMISSIONS FM'06 is the fourteenth in a series of symposia organized by Formal Methods Europe, http://www.fmeurope.org, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. The symposia have been notably successful in bringing together innovators and practitioners in precise mathematical methods for software development, industrial users as well as researchers. Submissions are welcomed in the form of original papers on research and industrial experience, proposals for workshops and tutorials, entries for the exhibition of software tools and projects, and reports on ongoing doctoral work. FM'06 welcomes all aspects of formal methods research, both theoretical and practical. We are particularly interested in the experience of applying formal methods in practice. The broad topics of interest of this conference are: * Tools for formal methods: tool support and software engineering, environments for formal methods. * Theoretical foundations: specification and modelling, refining, static analysis, model-checking, verification, calculation, reusable domain theories. * Formal methods in practice: experience with introducing formal methods in industry, case studies. * Role of formal methods: formal methods in hardware and system design, method integration, development process. TECHNICAL PAPERS Full papers should be submitted via the web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Accepted papers will be published in the Symposium Proceedings, to appear in Springer's Lecture Notes in Computer Science series, http://www.springeronline.com/lncs . Submitted papers should have not been submitted elsewhere for publication, should be in Springer's format, (see Springer's web site), and should not exceed 16 pages including appendices. A prize for the best technical paper will be awarded at the symposium. INDUSTRIAL USAGE REPORTS One day will be dedicated to sharing the experience -- both positive and negative -- with using formal methods in industrial environments. The Industry Day is organized by ForTIA, the Formal Techniques Industry Association, http://www.fortia.org . This year's Industry Day investigates the use of formal methods in security and trust. Invited papers on organizational and technical issues will be presented. Inquiries should be directed to the Industry Day Chairs; see the web site for details. WORKSHOPS We welcome proposals for one-day or one-and-a-half-day workshops related to FM'06. In particular, but not exclusively, we encourage proposals for workshops on various application domains. Proposals should be directed to the Workshop Chair. TUTORIALS We are soliciting proposals for full-day or half-day tutorials. The tutorial contents can be selected from a wide range of topics that reflect the conference themes and provide clear utility to practitioners. Each proposal will be evaluated on importance, relevance, timeliness, audience appeal and past experience and qualification of the instructors. Proposals should be directed to the Tutorial Chair. POSTER AND TOOL EXHIBITION An exhibition of both research projects and commercial tools will accompany the technical symposium, with the opportunity of holding scheduled presentations of commercial tools. Proposals should be directed to the Poster and Tools Exhibition Chair. DOCTORAL SYMPOSIUM For the first time, FM'06 will feature a doctoral symposium. Students are invited to submit work in progress and to defend it in front of "friendly examiners". Participation for students who are accepted will be subsidized. Submissions should be directed to the Doctoral Symposium Chair. SUBMISSION DATES Technical Papers, Workshops, Tutorials: Friday, February 24, 2006 Posters and Tools, Doctoral Symposium: Friday, May 26, 2006 NOTIFICATION DATES Technical Papers: Friday, April 28, 2006 Workshops, Tutorials: Friday, March 10, 2006 Posters and Tools, Doctoral Symposium: Friday, June 9, 2006 ORGANIZATION General Chair: Emil Sekerinski (McMaster) Program Chairs: Jayadev Misra (U. Texas, Austin), Tobias Nipkow (TU Munich) Workshop Chair: Tom Maibaum (McMaster) Tutorial Chair: Jin Song Dong (NUS) Tools and Poster Exhibition Chair: Marsha Chechik (U. Toronto) Industry Day Chairs: Volkmar Lotz (SAP France), Asuman Suenbuel (SAP US) Doctoral Symposium Chair: Augusto Sampaio (U. Pernambuco) Sponsorship Chair: Juergen Dingel (Queens U.) PROGRAM COMMITTEE Jean-Raymond Abrial (ETH Zurich) Alex Aiken (Stanford U.) Keijiro Araki (Kyushu U.) R
Re: [Haskell] Writing large n-dim un-boxed array of Int32 quickly?
Rene de Visser wrote: I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And also read it back later). hGetArray/hPutArray? -k ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Writing large n-dim un-boxed array of Int32 quickly?
Hello, I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And also read it back later). What I tried so far is import NewBinary.Binary ... mapM_ (put bin) $ elems array ... but this was exceedlying slow. The array contains about 10 000 000 entries. Any suggestions? Rene. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
