Re: [Haskell-cafe] IO and Cont as monads
2011/4/12 Burak Ekici : > Dear List, > > I am quite new in Haskell's categorical manner of programming. However I > have enough knowledge in Category Theory. > I want to ask a question, maybe very well-known one by some of you, about > monads of Haskell. > > For the type constructors like Maybe and [], I managed to prove that > together with 2 natural transformations (bind + return), both of these > triples construct a monad. But when I try to prove that IO and Cont type > constructors with the same natural transformations (bind + return) are > monads as well, it was failed. > > Here my question is: Is there anyone who knows how to prove that IO and Cont > are monads with satisfing following properties: IO doesn't obey the monad laws, due to the presence of seq in Haskell. Sad but true... Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Debugging with gdb?
On Tue, Apr 12, 2011 at 11:59 PM, Svante Signell wrote: > Hi, > > As I don't know anything about Haskell, can I make a stupid question: Is > there any method to create debug symbols for a Haskell program, and is > it possible to debug with gdb? > You can run gdb on a Haskell program, but it's unlikely you'll learn anything useful unless you're a compiler writer trying to debug your compiler or runtime system. ghci (the interactive version of GHC) has a built-in debugger that may be the closest thing to what you're used to with gdb. There is also a small cottage industry of debuggers that are more tailored to the process of debugging a functional program. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: hplaylist-0.1
Hello, hplaylist is a very simple command-line utility, written in Haskell, for automatically syncing an iTunes playlist to a non-Apple-manufactured MP3 player (anything that mounts as a USB drive should work in principle). For example, if I have an iTunes playlist called "Songs about cheese", hplaylist allows me to type: $ hplaylist "Songs about cheese" which automatically copies the named playlist, and all music files included in the playlist, to my device. Download at: http://hackage.haskell.org/package/hplaylist-0.1 or https://github.com/catamorphism/hplaylist Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proving correctness
On Sat, Feb 12, 2011 at 6:08 AM, C K Kashyap wrote: > Anyway, how can one go about explaining to an imperative programmer with no > FP exposure - what aspect of Haskell makes it easy to refactor? I think you just said it: typechecking, typechecking, typechecking. In Haskell, you can change one line of code and be confident that the compiler will force you to change every other line of code that's rendered nonsensical by your change. You just can't do that in C. It really liberates your mind and makes you less committed to your own design mistakes, since refactoring doesn't come with gut-wrenching worry that you'll introduce a silent error as a result. That said, I find that explaining Haskell's or ML's type system to someone used to a language with a much weaker type system is difficult. Many such people believe that type errors are trivial errors by definition and the compiler doesn't give them any help finding significant errors, which is true for the languages they've used (they may even believe that typecheckers get in their way by forcing them to correct errors). What's important is not just that Haskell has static typing, but that algebraic data types are a rich enough language to let you express your intent in data and not just in code. That helps you help the compiler help you. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ($) not as transparent as it seems
On Thu, Feb 3, 2011 at 2:03 PM, Luke Palmer wrote: > This is probably a result of strictness analysis. error is > technically strict, so it is reasonable to optimize to: > > let e = error "foo" in e `seq` error e > Yes, and you can see this in the Core code that Don posted: in version (A), GHC optimized away the outer call to error. But in version (B), the demand analyzer only knows that ($) is strict in its first argument -- it's not strict in its second. So it's not obviously safe to do the same optimization: the demand analyzer doesn't "look through" higher-order function arguments IIRC. (You can confirm this for yourself if you also want to read the demand analyzer output.) If ($) were getting inlined, the code would look the same coming into demand analysis in both cases, so you wouldn't see a difference. So I'm guessing you're compiling with -O0. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsmagick on OSX 10.6
On Thu, Feb 3, 2011 at 10:43 AM, Max Cantor wrote: > Just out of curiosity, has anyone gotten this to work? I'm getting bus > errors whenever I call readImage. > > If anyone out there has gotten it working and would tell me which versions > they're using of the relevant bits, that would be very much appreciated. > Also, I'll post all my debug info if there's someone who's gotten this to > work. > Hi Max -- I know that several people have used hsmagick successfully, but I don't have Mac OS 10.6 (I use 10.5.8), so I can't try to reproduce your problem. Vincent Gerard is taking over maintainership of the library, so you may want to cc him on any emails. In general it's not too safe to assume that any particular library maintainer reads haskell-cafe regularly :-) Cheers, Tim (hsmagick maintainer) -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ($) not as transparent as it seems
On Thu, Feb 3, 2011 at 12:44 PM, Steffen Schuldenzucker wrote: > > Dear cafe, > > does anyone have an explanation for this?: > >>>> error (error "foo") > *** Exception: foo > >>>> error $ error "foo" > *** Exception: *** Exception: foo > Have you read the intermediate Core (using -ddump-simpl) for each variation? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for children? Any experience?
On Thu, Jan 27, 2011 at 7:28 AM, aditya siram wrote: > Ye gods! A B & D [1] language for kids? At least give them a fighting > chance [2] at becoming future developers. > > Haskell's immutability is good for mathematics but doing anything else > takes a great deal of up-front patience and perseverance, two very > rare qualities in that demographic if my own childhood is any > indication. > > BTW I want to be wrong so if you do succeed with this I will feast on > crow with gusto. > IMO, the "two very rare qualities" part is a self-fulfilling prophecy. Didn't a lot of us spend endless hours tinkering with Linux configurations or seeing how many ways there were to use the debugger to make the computer crash when we were teenagers (if we were lucky enough to have computers as teenagers, anyway)? Kids -- and other people -- do amazing things when no one tells them it's hard. To the OP, I think teaching Haskell to 11-13 year olds should if anything be easier than teaching it to undergrads. At that age, they're less likely to have absorbed social "math is hard" messages and less likely to have absorbed Real-Programmer-ish ideas about what languages they're supposed to be programming in or what languages are practical. Sounds like a joy! Also, if you haven't, check out the book _Mindstorms_ by Seymour Papert -- the particular programming paradigm he advocates is different, but there should be some good fundamental ideas to inspire you. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building Haskell Platform on PowerPC?
Hello, For reference, I'm wondering whether there's an easier way to build the current version of the Haskell Platform on a PowerPC Mac running Mac OS 10.5.8 than the way in which I documented at: http://tim.dreamwidth.org/1715938.html I was installing the platform from scratch as a favor for a colleague who didn't have any version of GHC installed on his machine, and I just couldn't find a simpler way than installing two other versions of GHC first. Just curious if anyone has done it. I realize PPC is unsupported. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: extcore 1.0
On Sun, Jan 16, 2011 at 9:32 AM, Permjacov Evgeniy wrote: > On 01/13/2011 10:45 PM, Tim Chevalier wrote: >> Hello, >> >> I've recently released version 1.0 of extcore, a library for >> processing code in GHC's text-based External Core format. extcore >> includes a parser, prettyprinter, typechecker, and interpreter for >> External Core, as well as modules for computing module dependencies >> and combining multiple Core modules into a single module. > > May be a stupid quesion, but does interpreter allow reasonably easy way > to expose some haskell functions and data types to interpreted code as > 'primitives' ? such an interpreter may be yet another scripting > language, yet quite verbose one. > Maybe? I'm not sure I understand your question, but take a look at the evalPrimop function in Language/Core/Interp.hs and see if that answers your question. I have to admit that the interpreter is the most bit-rotted part of the External Core tools and its main function right now is to give an operational semantics for Core rather than to actually execute Core programs. I'd welcome any help with that! Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: extcore 1.0
On Thu, Jan 13, 2011 at 11:45 AM, Tim Chevalier wrote: > Hello, > > I've recently released version 1.0 of extcore, a library for > processing code in GHC's text-based External Core format. extcore > includes a parser, prettyprinter, typechecker, and interpreter for > External Core, as well as modules for computing module dependencies > and combining multiple Core modules into a single module. The library > was originally written by Andrew Tolmach and was part of the GHC > distribution. After becoming its maintainer, about a year ago I moved > the library to Hackage. Since in the past year, the library has > acquired some users but has received no fatal bug reports, I thought > it was time for a 1.0 release. > > You might be interested in using this library if you're a compiler or > tool writer who wants to write a tool that processes the output of > GHC's front-end and simplifier -- that is, code in the Core > intermediate language, a typed functional language in which many of > Haskell's features have been desugared into a polymorphically typed > lambda-calculus (extended with type coercions, as are necessary to > support type system features such as GADTs). Such tools might include > alternative back-ends or new program transformations. Using the > extcore library allows tool writers to experiment with implementing > new compiler features without modifying GHC itself. While the GHC API > is also a route to adding new stages to the GHC pipeline, using > extcore has the advantage that External Core is well-specified (read > on) and less subject to change than GHC's internal Core format. The > library has been tested on External Core produced by GHC 6.10.* and > GHC 6.12.*. It has not yet been tested on External Core produced by > GHC 7.*. > > Documentation for the External Core format itself lives at > http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf - but Oops, that'll learn me not to check links before I send email. The correct URL for the documentation is: http://www.haskell.org/ghc/docs/latest/core.pdf > documentation for the library is limited, and I would welcome > documentation or other patches. Currently the best source of > documentation for the library is the README file, found in the > distribution. To get the distribution, please visit > http://hackage.haskell.org/package/extcore or cabal install extcore. > > Please direct replies to glasgow-haskell-us...@haskell.org, with me > CCed. Please make sure not to reply to hask...@haskell.org. > Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: extcore 1.0
Hello, I've recently released version 1.0 of extcore, a library for processing code in GHC's text-based External Core format. extcore includes a parser, prettyprinter, typechecker, and interpreter for External Core, as well as modules for computing module dependencies and combining multiple Core modules into a single module. The library was originally written by Andrew Tolmach and was part of the GHC distribution. After becoming its maintainer, about a year ago I moved the library to Hackage. Since in the past year, the library has acquired some users but has received no fatal bug reports, I thought it was time for a 1.0 release. You might be interested in using this library if you're a compiler or tool writer who wants to write a tool that processes the output of GHC's front-end and simplifier -- that is, code in the Core intermediate language, a typed functional language in which many of Haskell's features have been desugared into a polymorphically typed lambda-calculus (extended with type coercions, as are necessary to support type system features such as GADTs). Such tools might include alternative back-ends or new program transformations. Using the extcore library allows tool writers to experiment with implementing new compiler features without modifying GHC itself. While the GHC API is also a route to adding new stages to the GHC pipeline, using extcore has the advantage that External Core is well-specified (read on) and less subject to change than GHC's internal Core format. The library has been tested on External Core produced by GHC 6.10.* and GHC 6.12.*. It has not yet been tested on External Core produced by GHC 7.*. Documentation for the External Core format itself lives at http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf - but documentation for the library is limited, and I would welcome documentation or other patches. Currently the best source of documentation for the library is the README file, found in the distribution. To get the distribution, please visit http://hackage.haskell.org/package/extcore or cabal install extcore. Please direct replies to glasgow-haskell-us...@haskell.org, with me CCed. Please make sure not to reply to hask...@haskell.org. Cheers, Tim Chevalier -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memoization/call-by-need
On 9/15/10, Alex Rozenshteyn wrote: > I feel that there is something that I don't understand completely: I have > been told that Haskell does not memoize function call, e.g. > > slowFib 50 > will run just as slowly each time it is called. However, I have read that > Haskell has call-by-need semantics, which were described as "lazy evaluation > with memoization" > > I understand that > > fib50 = slowFib 50 > will take a while to run the first time but be instant each subsequent call; > does this count as memoization? > Hi, Alex -- Haskell's informal semantics dictate that if we evaluate the expression: let fib50 = slowFib 50 in fib50 + fib50 then the expression (slowFib 50) will be evaluated only once, not twice, because it has a name. On the other hand, if you wrote: let fib50 = slowFib 50 in fib50 + (slowFib 50) then (slowFib 50) would be evaluated twice, because there's no principle requiring the compiler to notice that (slowFib 50) is the same expression as the one bound to fib50. An optimization called "full laziness" can accomplish the kind of stronger memoization you were suggesting in some cases, but GHC doesn't do it consistently, as it can make performance worse. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Both of them are to world religions what JavaScript is to programming languages." -- Juli Mallett, on Satanism and Wicca ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Good US Grad schools for functional languages?
On 5/13/10, Job Vranish wrote: > Anybody know of a good grad school in the US for functional languages? > (good = has Ph.D. program that covers functional languages, type systems, > correctness proofs, etc...) At Portland State, faculty include Andrew Tolmach, Jim Hook, Mark Jones, Tim Sheard, and Sergio Antoy, all names that should be familiar to anyone who knows the functional programming literature. We have faculty members who have served as program chairs and general chairs for ICFP; who have given invited talks at ICFP; who have co-organized the ICFP programming contest in two different years; who have served on the Haskell committee; and who are slated to or have lectured at the Oregon Programming Languages Summer School and the Advanced Functional Programming workshop. The first three names on that list of faculty members are members of the HASP group (High Assurance Systems Programming), which is an active research group focused on developing a call-by-value Haskell variant for systems programming. More info at http://hasp.cs.pdx.edu/ We currently have seven Ph.D students (including myself) and room (including funding) for more. Prospective students should use the contact info given on the above-linked web page (or contact me if you would prefer to talk to a current grad student). Tim Sheard also has funding for Ph.D students to work on the development of a new dependently typed language (this is a joint project with Stephanie Weirich at Penn and Aaron Stump at Iowa). For a bit of history, PSU absorbed many of the computer science faculty members who left the Oregon Graduate Institute in 2003-2004 when OGI shut down most of its computer science department (this group includes Jones, Sheard, and Hook). As a third-year grad student, I can attest that it's a top-quality and collegial department, full of people who have a passion for functional programming. Portland as a whole has an enthusiastic FP community outside academe -- for example, with the pdxfunc study group ( http://groups.google.com/group/pdxfunc ) and public talks at Galois ( http://www.galois.com/blog/ ). tl;dr: Portland State wants you! See http://hasp.cs.pdx.edu/ and/or contact me (or the people listed on that page) for more details. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's never too early to start drilling holes in your car." -- Tom Magliozzi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC core packages: same core?
On 10/13/09, Dimitry Golubovsky wrote: > Max, > > Thanks for the explanation. So, the extcore library is expected to > match the spec in > http://www.haskell.org/ghc/docs/6.10.4/html/ext-core/core.pdf and the > core itself can be produced with -fext-core, correct? I think it might > be interesting for people working on alternative backends (inlcuding > myself). > Hi Dimitry, Sorry for the late reply, but the External Core produced by any version of GHC newer than 6.10.4 should match the document you cite, and if it doesn't, I'd like to know about; in that event, please file a bug report or post to the glasgow-haskell-users list with me CCed. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The higher you climb, the more you show your ass." -- Alexander Pope ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure Haskell implementation of Float type?
On 1/20/09, Lennart Augustsson wrote: > Do you have Integer? > Yes (with the integer-simple library -- I was hoping there was some analogue of integer-simple for Float, although Don didn't think there was one). -t -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Having the gumption to live different *and* the sense to let everybody else live different. That's the hardest thing, hands down." -- Alice Venable Middleton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure Haskell implementation of Float type?
On 1/20/09, Don Stewart wrote: > catamorphism: > > > Hello, > > Is there a pure Haskell implementation of Floats, i.e., one that > > (unlike GHC.Float) doesn't use foreign calls for things like > > isFloatNegativeZero? I don't care about performance; I'm just looking > > for something that doesn't use foreign calls. > > > > > Huh, what's the use case? > I'm implementing a compiler that doesn't support foreign calls (yet). Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I cannot remember a time when I did not take it as understood that everybody has at least two, if not twenty-two, sides to him." -- Robertson Davies ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pure Haskell implementation of Float type?
Hello, Is there a pure Haskell implementation of Floats, i.e., one that (unlike GHC.Float) doesn't use foreign calls for things like isFloatNegativeZero? I don't care about performance; I'm just looking for something that doesn't use foreign calls. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It is easy to keep secrets by being honest in an ironic tone of voice." -- Andrew Solomon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, Oct 3, 2008 at 7:24 PM, Luke Palmer <[EMAIL PROTECTED]> wrote: > Well, unboxed tuples are not really lifted nor unlifed, since you > can't even pass one to a function. > It's true that unboxed tuples are not first-class. But what I mean by "unlifted" is that the type (# Int, Int #), when interpreted as a set, does not contain _|_ as an element (and I'm purposely conflating the unlifted/liftedness distinction with the unboxed/boxness distinction here). Is that what you mean, or do you mean something else? > I like to pretend tuples are unlifted. Here's how I do it: > Sure. But the compiler won't check that assumption for you. I don't know whether that has anything to do with the original question, though :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If you don't understand the causes, it is impossible to come up with a solution." -- Joe Biden ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcing OneTuple-0.1.0
On Fri, Oct 3, 2008 at 2:29 PM, Jason Dusek <[EMAIL PROTECTED]> wrote: > Lennart Augustsson <[EMAIL PROTECTED]> wrote: >> But (a) is not a lifted version of a, whereas (a,b) is a lifted >> version of the a b product. >> So it's not consistent, and thereby wrong. > > Well, we can't represent the unlifted product in Haskell, > right? You have to use some constructor. So if we just say we > are using tuples to represent unlifted products, what's so bad > about that? > Unless I'm confused, unboxed tuples represent unlifted products. In a sense this is "[using] some constructor", but in a sense not, since an unboxed tuple constructor has no runtime representation. > The last two messages in this thread suggests this has more to > do with the internals of Haskell than they do with consistent > semantics -- so I am perhaps missing the point. I think most Haskellers try their best to keep the first subservient to the second. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If you don't understand the causes, it is impossible to come up with a solution." -- Joe Biden ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Fwd: profiling in haskell]
On Fri, Sep 12, 2008 at 2:30 PM, Vlad Skvortsov <[EMAIL PROTECTED]> wrote: > How do I figure out what exactly in 'serialize' takes so much time? > At this point, I don't know any more -- I can't see what inherited costs serialize could have that don't come from one of the cost centres you've inserted, either. Perhaps you could try the glasgow-haskell-users mailing list, where people interested in this are more likely to be reading carefully... Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Fwd: profiling in haskell]
On Wed, Sep 10, 2008 at 12:31 PM, Vlad Skvortsov <[EMAIL PROTECTED]> wrote:
> Hmm, that's a good point! I didn't think about it. Though how do I make GHC
> link in profiling versions of standard libraries? My own libraries are built
> with profiling support and I run Setup.hs with --enable-library-profiling
> and --enable-executable-profiling options.
When you build your own code with -prof, GHC automatically links in
profiling versions of the standard libraries. However, its profiling
libraries were not built with -auto-all (the reason is that adding
cost centres interferes with optimization). To build the libraries
with -auto-all, you would need to build GHC from sources, which is not
for the faint of heart. However, the results of doing that aren't
usually very enlightening anyway -- for example, foldr might be called
from many different places, but you might only care about a single
call site (and then you can annotate that call site).
Just from looking, I would guess this is the culprit:
> termToStr t il =
> {-# SCC "termToStr" #-} ((:) ("t " ++ t ++ " " ++ (foldl ilItemToStr ""
> il)))
>
If you want to be really sure, you can rewrite this as:
termToStr t il =
{-# SCC "termToStr" #-} ((:) ("t " ++ t ++ " " ++ ({-# SCC
"termToStr_foldl" #-} foldl ilItemToStr ""
il)))
and that will give you a cost centre measuring the specific cost of
the invocation of foldl.
> Data.Map.foldWith key is implemented with foldr[1], however I'm not sure I'm
> getting how foldr is superior to foldl here (foldl' I understand). Could you
> shed some light on that for me please?
>
I meant the call to foldl in termToStr. There's a good explanation of this at:
http://en.wikibooks.org/wiki/Haskell/Performance_Introduction
(look for "foldl").
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Fwd: profiling in haskell]
2008/9/8 Vlad Skvortsov <[EMAIL PROTECTED]>:
> Posting to cafe since I got just one reply on [EMAIL PROTECTED] I was
> suggested to
> include more SCC annotations, but that didn't help. The 'serialize' function
> is still reported to consume about 32% of running time, 29% inherited.
> However, functions called from it only account for about 3% of time.
>
If "serialize" calls standard library functions, this is probably
because the profiling libraries weren't built with -auto-all -- so the
profiling report won't tell you how much time standard library
functions consume.
You can rebuild the libraries with -auto-all, but probably much easier
would be to add SCC annotations to each call site. For example, you
could annotate your locally defined dumpWith function like so:
dumpWith f = {-# SCC "foldWithKey" #-} Data.Map.foldWithKey f []
docToStr k (Doc { docName=n, docVectorLength=vl}) =
(:) ("d " ++ show k ++ " " ++ n ++ " " ++ (show vl))
Then your profiling report will tell you how much time/memory that
particular call to foldWithKey uses.
By the way, using foldl rather than foldl' or foldr is almost always a
performance bug.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell core definition
On Tue, Sep 9, 2008 at 8:34 AM, Justin Bailey <[EMAIL PROTECTED]> wrote: > This paper is a bit old but still very relevant: > > An External Representation for the GHC Core Language > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.1755 > Or: http://www.haskell.org/ghc/docs/papers/core.ps.gz Note that External Core, as specified in this paper, is similar to but not entirely the same as the version of Core that GHC prints out for debugging purposes. GHC 6.10 will be able to produce External Core with a flag again, and at that point Section 5.15 of the users' guide will point to a new version of the documentation -- so if you upgrade to 6.10 when it is released and are still poring over Core code then, be sure to get the new documentation. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On Fri, Sep 5, 2008 at 7:23 PM, Derek Elkins <[EMAIL PROTECTED]> wrote: > > This attitude is wrong. Many potentially significant performance > problems can easily be spotted and solved during construction without > affecting the readability of the code, problems that would be much > harder to diagnose at the end running a profiler. This is especially > crucial for library code. The users of the library may be the ones that > find the easily resolved space leak your profiling didn't reveal and now > they can't do anything about it until a new version is released e.g. > Data.Map.insertWith. A performance problem that renders your code > unusable is a bug and catching it early or not making it in the first > place is much better than catching it late. > Library writers don't write applications that use their code as part of the testing process? > A (highly related) analogy would be telling Scheme programmers (or > Haskell programmers for that matter) not to use to tail recursive code > until a profiler tells them to and transforming to a tail recursive > style is much more intrusive than adding a strictness annotation. > Tail recursion isn't always a win in Haskell. I'm not much in touch with the Scheme world, so can't speak to that. > Highly competent Haskell programmers add strictness annotations > relatively systematically. The details of mixing eager and lazy code is > one of the significant contributions to the pragmatics of programming > lazy functional languages have made. At another extreme, things like > Chris Okasaki's data structures rely on a specific balance of eagerness > and laziness. > > Also, it is easier (as in not impossible) to turn a strict in the > elements data structure into a lazy one than the other way around. > > Eager by default or lazy by default are both have (actually dual) > pitfalls that are best solved by a laziness or strictness annotation > respectively. There is no need to walk into those pitfalls with your > eyes wide open. That may be, but are the holes that one falls into due to unexpected laziness and the ones that one falls into due to unexpected strictness equally numerous? Are they equally deep? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On 9/4/08, John Dorsey <[EMAIL PROTECTED]> wrote: > I'm no master either, but I'd argue that if we promise new programmers > that they don't need to care about strictness, we thereby ensure that > default laziness is treacherous. > > A year or two ago, ISTR that *most* of the newbie-generated traffic in > the cafe was about atrocious performance of naive programs due to > strict/lazy concerns. I think it was scaring people away. > I think it's debatable what the various causality relationships might be here. > Adding strictness can improve asymptotic space performance, as an example. > Is there a reason to think this won't always be true? Honest question, > since I don't know nearly enough about strictness analysis to guess > how good it'll be some day. Adding strictness can also worsen asymptotic space (and time) performance. That's one reason why we use a lazy language at all. Strictness analysis is an approximation to the problem of determining what parts of a program can be evaluated strictly without changing their meaning, because if we had a perfect solution to that problem, we could solve the halting problem. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "There are no difficult problems, just unfortunate notations." -- Alfonso Gracia-Saz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On 9/4/08, Jake Mcarthur <[EMAIL PROTECTED]> wrote: > Two lazy algorithms tend to compose well and result in a lazy > algorithm. A lazy algorithm can compose with a strict algorithm in two > different ways. One way is for the lazy algorithm to control the > strict algorithm, in which case the strict algorithm is either invoked > or not invoked, resulting in a lazy algorithm. The other way is for > the strict algorithm to control the lazy algorithm, in which case the > strict algorithm requests the data it needs from the lazy algorithm as > it needs it, resulting in a strict algorithm. Finally, two strict > algorithms may also compose, which results in a strict algorithm. > > No matter how you slice it, none of the above scenarios are > necessarily bad. Each of the four permutations of laziness and > strictness for two composed algorithms are necessary for different > situations. Laziness and strictness work in tandem with each other to > construct whole programs. > You say lazy algorithms are good because they compose well. In Haskell, does an algorithm that operates on data structures that have strict components have that property? > We Haskellers like laziness by default because we find that it > encourages us to consider laziness to solve our problems more often > than in call-by-need languages, not because it is somehow "superior" > to strictness. That is the strongest argument I can think of to be > made in favor of lazy-by-default. > So you don't believe that laziness is superior to strictness, or versa; I don't, either. But you do say it's good to be encouraged to use laziness more often. Why? You mention compositionality above as a possible reason, in reply to which, see above. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The future is not google-able." -- William Gibson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On 9/4/08, Jake Mcarthur <[EMAIL PROTECTED]> wrote: > I'm no master either, but how about these simple examples? > > data Stream a = Cons !a (Stream a) > data Vector3 a = Vector3 !a !a !a > > The compiler will certainly be able to infer the strictness itself in > most uses, so obviously the purpose for these annotations is not for > optimization, but I still would find these annotations useful. This is > much like explicitly giving the type for a function. It guides the > reader of the program, and just happens to also assist the compiler a > little bit. > But why not write your types like: data Stream a = Cons a data Vector3 a = Vector3 a a a in a hypothetical call-by-value language where the <> annotation denotes a lazily evaluated data structure? Does it matter? If it does, then why? If it doesn't, then what would you conclude about whether a language should encourage laziness or strictness? > If optimization is the only reason to worry about strictness, then > default laziness really _is_ treacherous. Luckily this is not the > case. Laziness is not useful without strictness, otherwise there would > never be any evaluation. Understanding how to apply laziness and > strictness in different situations is critical to writing efficient > but meaningful code in Haskell. True, but both laziness and strictness exist in strict languages, as well. What if, as a thought experiment, you tried substituting "laziness" for "strictness" in that paragraph of your essay? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The Internet wasn't created for mockery, it was created to help researchers at different universities share data sets." -- Homer Simpson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On 9/4/08, Jake Mcarthur <[EMAIL PROTECTED]> wrote: > My guess would be that a master usually adds strictness annotations as > documentation rather than as optimizations. > I'm no master, but I've never encountered a situation where strictness annotations would be useful as documentation, nor can I imagine one. That's because optimization *is* the only reason why programmers should care about strictness information. IMO, arguing that programmers should care at all amounts to conceding that default laziness is treacherous. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Stupidity combined with arrogance and a huge ego will get you a long way." -- Chris Lowe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On 9/3/08, wren ng thornton <[EMAIL PROTECTED]> wrote: > If you want the datatype to be strict in state and rec, then you should add > strictness annotations to those fields directly: > > data Query state rec = Query !state !rec The novice programmer scatters strictness annotations to and fro like dust in the wind. The average programmer understands that annotating a field's strictness injudiciously is like discarding the finger pointing at the moon when you might still need it to scratch yourself. The master programmer does not add strictness annotations, for she has not yet run the profiler. Cheers, TIm -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Science fiction is not predictive; it is descriptive." --Ursula K. Le Guin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: wavconvert 0.1.1
On 8/19/08, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote: > Tim Chevalier wrote: > > > The trouble is that .wav files don't have metadata (ID3 tags) that > > specify artist, album and track names. > > > WAV files can't have ID3 tags, but they most definitely can support > metadata including all the ones you mention and much more in an > LIST/INFO chunk. > > libsndfile (http://www.mega-nerd.com/libsndfile) supports TITLE, > COPYRIGHT, SOFTWARE, ARTIST, COMMENY, DATE, ALBUM and LICENSE > fields. > I stand corrected. However, some CD ripping programs don't fill in the metadata when creating WAV files. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Being a nerd, which is to say going too far and caring too much about a subject, is the best way to make friends I know." --Sarah Vowell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: wavconvert 0.1.1
Hi all, I uploaded to Hackage a little program I wrote to organize my music file collection in the hopes that someone else might find it useful too: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert I had a directory tree full of .wav files that I ripped from CDs at times when I didn't want to wait for an .mp3 or .ogg encoder to run. The trouble is that .wav files don't have metadata (ID3 tags) that specify artist, album and track names. So, wavconvert takes a directory tree as an argument, and converts any .wav files in it to .ogg (using an external OGG encoder) while filling in the ID3 tags based on the directory names. The name is a bit misleading, since this is not an OGG encoder written in Haskell; it just handles invoking an existing encoder with the right flags to set the metadata. I'd welcome any patches to make this more generally useful (as it is, it assumes a particular file structure and OGG encoder.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Research is what I'm doing when I don't know what I'm doing."--Wernher von Braun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best book/tutorial on category theory and its applications
I've only read the beginning, but I recommend _Conceptual Mathematics_ by Lawvere and Schanuel for a *very* gentle introduction (seriously, you could probably teach category theory to ten-year-olds out of this book.) Nothing about applications there, though. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I haven't got the slightest idea how to change people, but still I keep a long list of prospective candidates just in case I should ever figure it out." --David Sedaris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI C Structs
On 7/18/08, Aleš Bizjak <[EMAIL PROTECTED]> wrote: > PS: An example of a haskell binding like this would be even more useful, if > anyone knows of such. I don't know that it's good for much else besides serving as an example of an FFI binding that uses structs (and possibly as an example of what not to do), but you could look at my half-finished GraphicsMagick binding: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsmagick Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Good memories make me feel bad / Bad memories make me feel small" --Dom Leone ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: The Disciplined Disciple Compiler - alpha 1
On 3/20/08, Ben Lippmeier <[EMAIL PROTECTED]> wrote: > > Hi Wolfgang, > Rest assured it really is a Haskell project. Apart from the way it > does field projections, DDC will compile a significant number of > Haskell programs with no modifications. > Can you elaborate on "a significant number of Haskell programs"? Do you expect that DDC can compile any Haskell (98?) program except some weird corner cases, or are you aware of a particular class of Haskell programs it currently can't compile? (I'm asking in order to find out whether DDC would potentially be useful for my work, not so as to question whether it should be on haskell.org (I don't care about that :-)) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's easy to consider women more emotional than men when you don't consider rage to be an emotion." -- Brenda Fine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] intersection of sets
[ccing to list] On 3/18/08, Walt Potter <[EMAIL PROTECTED]> wrote: > Tim, > > We're using -O2 to optimize, but not changing the heap size. We're > trying to get the profiling running on our file. > The sets have about 25 million elements each. Each element is a sequence > of length 16. > > We'll want to compute larger examples! > > I do not know how intersection works in Data.Set. I'm worried that we're > having problems with stack overflow due to recursion. We'll try to > remove the lazy stuff. > Run profiling before you "try to remove the lazy stuff". There's no point in trying to optimize code until you know what's actually taking up space. If you have problems with profiling, then ask on the glasgow-haskell-users mailing list. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Aw, honey, you can keep what's in my pockets, but send me back my pants." --Greg Brown ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] intersection of sets
On 3/18/08, Walt Potter <[EMAIL PROTECTED]> wrote: > All, > We're running out of space when we intersect two large sets. We've > imported Data.Set. > Any suggestions? > What optimization and other compiler flags (heap size, etc.) are you using? Have you tried profiling? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Live fast, love hard, and wear corrective lenses if you need them." --Webb Wilder ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An offer to any haskell projects out there.
On 3/12/08, Don Stewart <[EMAIL PROTECTED]> wrote: > One of the best things you could do would be to submit patches against > the core library set where documentation is missing. Starting > with things in base, array, containers, directory, filepath, pretty, > time etc. > > That would likely help the largest number of users. > > Patches to these libraries can be submitted to the [EMAIL PROTECTED] > list. > To elaborate ever so slightly on what Don said: A lot of libraries only have type signatures for functions in the libraries as "documentation". What's missing is English descriptions of what the functions really do. You yourself may not know what the functions do, but you can learn by experimenting with the libraries (writing little programs that use the functions) and by asking on this mailing list (and reading old posts in the archive), if necessary. It would be really useful if you decided to put time into this. Thanks in advance! Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "You never have to aspire to difficulty, darling. It arrives, uninvited. Then it stays for dinner."--Sue Miller ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parody of Darcs patch theory from 1981
On 3/2/08, Paul Johnson <[EMAIL PROTECTED]> wrote: > I was looking through my old copy of "The Devil's DP Dictionary" by Stan > Kelly-Bootle, and came across the entry for Stepwise Refinement. I > thought "I've seen this before: this is a parody of Darcs patch > theory". It included the Null patch, chains of patches, inverse > patches, and pseudo-inverse patches. But the book was published in 1981. > > I've got the pages scanned, but I can't upload them to Wikimedia because > they are still in copyright. However I'm quite sure that limited > distribution would fall into "fair use" (non-commercial, small part of > work, no impact on market, academic relevance). The total file size is > about 520kBytes. Assuming people would like to see them, does anyone > have any ideas beyond "email to requestors"? I would be entertained, but perhaps this might be more on-topic on the darcs-users mailing list (and interested parties might be more likely to see it there, since not everyone can keep up with haskell-cafe) :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jeff Raskin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
On 2/8/08, Matthew Naylor <[EMAIL PROTECTED]> wrote: > it in for an efficient program. However, to my knowledge, it is an > unwritten rule of Haskell compilers that sharing *is* preserved, and > that they do perform *graph* reduction. Clean, a similar language to I'm not sure that programmers ought to be relying on this rule. Sure, all Haskell compilers I know of preserve sharing and do graph reduction. But conventional wisdom is not the same thing as an unwritten rule. Someday, someone might come along and write a Haskell compiler that isn't based on graph reduction and doesn't preserve sharing at the implementation level (while still preserving the informal semantics of Haskell). A programmer who had written code that failed to compile correctly under this hypothetical compiler would be a very naughty Haskell programmer indeed. > Haskell, indeed has a semantics based on graphs. So I don't believe Haskell doesn't have a semantics, graph-based or not... or at least not a formal one, and if not a formal one, I don't know what you mean :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "There are no sexist decisions to be made. There are antisexist decisions to be made. And they require tremendous energy and self-scrutiny, as well as moral stamina..." -- Samuel R. Delany ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Extensible records: Static duck typing
[redirecting to haskell-cafe] On 2/6/08, Barney Hilken <[EMAIL PROTECTED]> wrote: > This is what I was trying to do with the wiki page. I stopped because > the only other contributor decided he could no longer contribute, and > I felt I was talking to myself. If we want to be rational about the > design, we need real examples to demonstrate what is genuinely useful, > and I don't have that many of them. It's obvious that records are a language feature that people besides just you care about. And so everybody would benefit from your effort if you chose to continue adding more examples to the wiki page. Records clearly seem to be an important issue if so many people have replied to your thread, and your comment expressing frustration at "arbitrary decisions" getting made about design seems to suggest you have some passion about the issue. On the other hand, if you can't think of real examples offhand, and no one else can either, maybe it's not that important... (Examples don't have to be very complicated to be useful, by the way. Simpler is better.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If pots couldn't call kettles black, there'd be a lot less talking going on." -- Larissa Ranbom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FP and Quality
On 2/4/08, PR Stanley <[EMAIL PROTECTED]> wrote: > Hi folks > I'm thinking of writing a little essay arguing the case for the > advantages of FP for producing quality software. Can the list > recommend any papers/articles which I can use as sources of my > argument? I have access to the IEEE database too although earlier I > couldn't find anything on the subject. Try: Philip Wadler. An angry half dozen. SIGPLAN Notices 33(2):25--30, February 1998. [NB. http://citeseer.ist.psu.edu/article/wadler98angry.html ] Also look for the schedules for the 2007 and 2006 CUFP (Commercial Users of Functional Programming) workshops. The schedules have links to slides from talks by people using FP in industry. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Not only would I never want to belong to any club that would have me for a member -- if elected I would wear street shoes onto the squash court and set fire to the ballroom curtains."--Michael Chabon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Who started 42, and when?
To pre-empt the next couple of questions, the numbers 17 and 23 are from _The Illuminatus! Trilogy_ by Robert Shea and Robert Anton Wilson, and the number 37 is from the Jersey Trilogy of movies by Kevin Smith. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I'm a nonbeliever, but I believe in your smile." -- Laura Nyro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/29/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Oh, people! > I try hard to degenerate this discussion into a pure delirium traemens, and > you still keep its serious intellectual contents intact! I bet that you > don't even smile, writing your terrible off-topic postings! Damn, I was trying to be wacky and off-topic too. I guess I must have failed at that goal. Time to start talking about applicative functors as used to explain how to use monad comprehensions to compile Perl into Unlambda, I guess. > > If you wish so... > Tim, there cannot be any USUAL CONVENTION, unless you are conditioned by > your anglo-saxon keyboard. > I don't know what you mean by this exactly. I assume that your first name is not meant to be pronounced like the name of the isle of Jersey, even though that's what it looks like to me (an ignorant American). So if we met, I would try to pronounce it the way you said it. That's the "convention" that I see as applying. > There is no truly established way to translate non-standard diacritics. > Even without, there are pronunciation variants, look how many versions > of "Mustapha" names there are in the world. Try to transmit my family > name to a Japanese, using Katakana (which, being syllabic, gives you many > choices...) > The information world today is far from a purely oral tradition. I think > that the only sane attitude is just let people distort everything as they > wish, and don't get nervous. Those distortions are unavoidable, languages > are evolving creatures. > True, but this is more to do with text rather than speech. > ... And a good part of English has been established by those Francophone > Vikings who won the battle of Hastings in 1066, beginning their campaign > from where I usually live and work. > ... Not forgetting that before them there were Danish Vikings, coming from > the place where I sit now... Indo-European turtles all the way down. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The geeks shall inherit the earth." -- Karl Lehenbauer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/29/08, PR Stanley <[EMAIL PROTECTED]> wrote: > I didn't know Haskell was an English name. Haskell Curry was an American, and I think the usual convention is to pronounce names in the manner of the language that the person who has the name speaks. (Preferably just to pronounce people's names the way they say them.) (The first convention doesn't work with my last name, though the second one does.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Living with depression is like trying to keep your balance while you dance with a goat -- it is perfectly sane to prefer a partner with a better sense of balance." -- Andrew Solomon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/29/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On the other hand, is better not to try Curry, since the French pronounce > it: Queue-rhrhrh. This is for me absolutely inacceptable and scandalous, > since thus, they confuse him with Madame Curie, who was Polish, and I am > a patriot. And after a few years, people from some Other Respectable > Cultures will think that Haskell discovered Radium (for French: Hhhhudiomm). > Not to mention that there's already a programming language called "Curry". > Thank you for this inspiring and awfully useful discussion. > I live to serve. > Some more messages on this subject, and I will have really to call an > ambulance so they can take me away, far from Internet... > Have them stop at my place next... Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Yeah. Okay. Yeah. Basically, swingers meet ISO 9000." -- DF, on cuddle parties ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Why isn't there a FAQ? (was: Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?)
On 1/28/08, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote: > > On Jan 28, 2008, at 21:54 , Tim Chevalier wrote: > > > I thought that the .wav file that Jeremy linked to should go in the > > Haskell FAQ, if there was one, but it doesn't seem to exist. > > http://www.haskell.org/haskellwiki/Category:FAQ > > but it took me too much effort to find it, and it needs a fair amount > of work besides IMO. > Yes, the usual convention for FAQs is for them to be structured as a list of questions, possibly including answers. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Relax. I'm weird, not violent."--Brad Boesen, _Disturbed_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Why isn't there a FAQ? (was: Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?)
I thought that the .wav file that Jeremy linked to should go in the Haskell FAQ, if there was one, but it doesn't seem to exist. There's a comp.lang.functional FAQ (that isn't maintained anymore) with a section on Haskell, and a GHC FAQ, but no general Haskell FAQ. A google search for "haskell faq" turns up this as one of the first ten hits: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01153.html which is hardly current. So somebody should write one. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "What you call 'lying', other people would call 'abstraction'." -- Alex Aiken ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/28/08, Anton van Straaten <[EMAIL PROTECTED]> wrote: > Tim Chevalier wrote: > > I suppose you would really want to ask Haskell Curry how *he* > > pronounced his name, but it's a bit late for that. > > Someone could ask Alonzo Church, Jr. how his one-time date pronounced > her father's name: > > http://importantshock.wordpress.com/2007/08/21/haskell-curry-yes-i-dated-his-daughter/ > That is an excellent blog post, but according to one of the comments, Alonzo Church, Jr. is also no longer with us. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's never too early to start drilling holes in your car." -- Tom Magliozzi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/28/08, Dan Weston <[EMAIL PROTECTED]> wrote: > Jeremy Shaw wrote: > > I would say the best description of how I pronounce it (which may or > > may not be right): is like 'rascal' but with an h. Though, perhaps > > different people pronounce rascal differently than I do. > > I think to ease the acceptance of Haskell in the broader world we should > spell it "Hascal" and stress the second syllable. :) > I think to ease the acceptance of Haskell in the broader world, we should just change the name to Schönfinkel. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If you live in a society that wishes you didn't exist, anything you do to make yourself happy disrupts its attempts to wipe you out, or at the very least, make you invisible." -- Patrick Califia ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/28/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Well, unless you are French. Then you don't pronounce "H". The remaining > letters are pronounced according to the Règlements de l'Académie. Fair enough. I wouldn't want to be culturally insensitive, and should have said that my statement was only directed at people who were speaking some dialect of English. > On the other hand, the name "Chevalier" is pronounced as it should be. > I can pronounce my own name better than more or less any other American, but -- sadly -- quite a bit worse than anyone who actually grew up speaking French. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Now I'm trying to get back to what I know that I should be / hoping to God that I was just a temporary absentee" -- Gerard McHugh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/28/08, Tim Chevalier <[EMAIL PROTECTED]> wrote: > On 1/28/08, Jeremy Shaw <[EMAIL PROTECTED]> wrote: > > Hello, > > > > If my sources are to be believed, the following clip contains Simon > > Peyton Jones saying 'Haskell' several times. > > > > http://www.n-heptane.com/nhlab/spj-haskell.wav > > > > I have listened to Simon (and other equally sage folks) say "Haskell" > on a few occasions and I believe that it's more like what I tried to > render in text. Perhaps you've listened equally carefully but > disagree; perhaps neither of us is wrong. the English language is > weird that way. > > I suppose you would really want to ask Haskell Curry how *he* > pronounced his name, but it's a bit late for that. > I should really read more carefully -- I see now that you weren't trying to disagree with me by posting that clip, but the person who *did* disagree with me was also named "Jeremy". How confusing. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "People. Can't live with 'em, can't legally set fire to 'em." -- Sheree Schrager ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/28/08, Jeremy Shaw <[EMAIL PROTECTED]> wrote: > Hello, > > If my sources are to be believed, the following clip contains Simon > Peyton Jones saying 'Haskell' several times. > > http://www.n-heptane.com/nhlab/spj-haskell.wav > I have listened to Simon (and other equally sage folks) say "Haskell" on a few occasions and I believe that it's more like what I tried to render in text. Perhaps you've listened equally carefully but disagree; perhaps neither of us is wrong. the English language is weird that way. I suppose you would really want to ask Haskell Curry how *he* pronounced his name, but it's a bit late for that. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Work is there when love is gone" -- Greg Brown ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
On 1/28/08, Jeremy Apthorp <[EMAIL PROTECTED]> wrote: > On 29/01/2008, Tim Chevalier <[EMAIL PROTECTED]> wrote: > > "Haskell", stress on the first syllable; the first syllable is like > > the word "has" and the second syllable is pronounced with a schwa > > where the "e" is written. > > > > Sometimes you will hear people stress the second syllable, but that is > > not Preferred. > > > > "Hass" (like in "hassle") "kell" (to rhyme with "fell") > That is not correct. The second syllable does not rhyme with "fell". In fact, the correct pronunciation sounds like "hassle" with a 'k' inserted between the two syllables of that word. (And when I say it's not correct, I'm comparing to the speech of a few People Who Should Know.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "pointing out ridiculous attitudes about every actual thing in the world ever is not a crime" -- Tony Gies ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"?
"Haskell", stress on the first syllable; the first syllable is like the word "has" and the second syllable is pronounced with a schwa where the "e" is written. Sometimes you will hear people stress the second syllable, but that is not Preferred. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "They say the world is just a stage you're on...or going through." --Jim Infantino ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to organize code
On 1/27/08, L.Guo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> How do you organize code ?
>
> Here is a sample.
> Acturally, I am thinking about using this plan.
>
> Any suggestions ?
>
> > -- BasicalType.hs
> > type Position = (Int,Int)
> > data Box = Box { pos :: Position }
> > data Chain = Chain { pos :: [Position] }
>
> > -- Object.hs
> > import BasicalType
> > class Object o where
> > pos :: o -> [Position]
>
> > -- Type.hs
> > import BasicalType
> > import Object
> > instance Object Box where
> > pos = return . BasicalType.pos
> > instance Object Chain where
> > pos = BasicalType.pos
>
> > -- Main.hs
> > import Type
> > ...
>
Be careful not to confuse Haskell's type class system with the idea of
a "class" in object-oriented programming. I suggest you read this
article:
http://trevion.blogspot.com/2007/02/snowball-chance.html
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"...It's a thin line between amateur and professional, a line mostly
emphasized by insecure professionals." -- Bob Franke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: The programming language market (was Re: [Haskell-cafe] Why functional programming matters
opted -- if you think that it's elegant but will never be practical -- it's going to be hard for you to sell it to a 300-person hall full of undergrads, most of whom are likely to start checking email the moment you say something that bores them. Disclaimer: This entire message consists of my personal opinions and does not represent the opinions of anybody else, and probably won't represent my opinions either in another day or two. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "don't you understand / in the day to day / in the face to face / i have to act just as strong as i can / just to preserve a place where i can be who i am" -- Ani DiFranco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: The programming language market (was Re: Why functional programming matters
On 1/26/08, Stefan Monnier <[EMAIL PROTECTED]> wrote: > >> * Say "computers are cheap but programmers are expensive" whenever > >> explaining a correctness or productivity feature. > > This is true only if talking to people in high-income nations. > > Is it? Maybe you're right. > Yes -- consider the OLPC project (and its competitors). In some developing nations, $200 for a laptop is still a *lot* to pay (the laptop I'm typing this on cost $1400, purchased on a government grant, and that purchase was treated as nothing.) Labor is a lot cheaper in those places. And there's not much in the way of big government funding (whether for universities or companies) to pay for any of it. > But historically, computers have been available at all kinds of price > ranges, so people chose the price point that fit them. So, for the last > 15 years or so already computers have been chosen (in the wealthy > countries) to be cheaper than programmers. > > Is there any reason to think that the same forces aren't at play in > lower-income nations? After all, cheap (typically second hand) > computers are easy to come by. Not with the same amount of computing power that computers that run modern application tend to have; a lot of places don't even have reliable *electricity* (so in that case, lots of people and limited machines could be *good*, if the machines aren't working all the time), etc. I don't really know enough to give a more complete answer to your question. But my original point is that saying labor is always expensive and hardware is always cheap by comparison is a culturally biased statement, at least right now, on January 26, 2008. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I eat too much / I laugh too long / I like too much of you when I'm gone." -- Ani DiFranco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: The programming language market (was Re: [Haskell-cafe] Why functional programming matters
On 1/26/08, Paul Johnson <[EMAIL PROTECTED]> wrote: > Tim Chevalier wrote: > > This is true only if talking to people in high-income nations. > > > Even in low-income nations, its only false in the short term. If you > have skilled programmers with computers and Internet connections then > their wages inflate to the world norm. IIRC India is seeing 20%/year > wage inflation for comp-sci graduates. And thats without the impact of > H1-B and related programmes around the world. > It's true that India seems to be going in that direction, but personally I don't feel I have the background or temerity to suggest that it will definitely happen for the rest of the world. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "We're born, we live for a brief instant, and we die. Technology is not changing it much, if at all."--Steve Jobs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: The programming language market (was Re: [Haskell-cafe] Why functional programming matters
On 1/26/08, Paul Johnson <[EMAIL PROTECTED]> wrote: > * Say "computers are cheap but programmers are expensive" whenever > explaining a correctness or productivity feature. This is true only if talking to people in high-income nations. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "We should not be simply fighting evil in the name of good, but struggling against the certainties of people who claim always to know where good and evil are to be found." -- Tzvetan Todorov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Internships at GHC HQ
On 1/25/08, Dan Licata <[EMAIL PROTECTED]> wrote: > A further plug: > > I did an internship with Simon PJ last summer (implementing view > patterns in GHC, among other things), and this is a great opportunity if > you're interested in PL research. There is a lot of interesting work > going on at MSR Cambridge, the atmosphere is very friendly, and > Cambridge is a lovely place to spend a summer. > > If anyone wants an "intern's-eye" view of the experience, feel free to > e-mail me! > I second most parts of this (including the "feel free to email me part"). I hear that the summer is busiest with respect to interns, but those who can arrange it with their graduate programs ought to consider applying for an internship during the school year. I don't know what things are like now, but I found that there were plenty of other interns around to keep me company even during the fall, and Cambridge is a lovely place to spend an autumn as well. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The more you talk, the more I get / a sense of something that hasn't happened yet / The more you talk, the more I want to know / the way I'll remember you when I go." -- Ani DiFranco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why functional programming matters
On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote: > Other things did not seem that great for me from the beginning. For > example: referential transparency - just enforces what you can take care > not to do yourself ...if you never make mistakes, that is. > (e.g. in C# you just cannot be sure some function is > referentially transparent even when comment claims so - which of course > sucks because programmers are not disciplined). But if that's the point you're trying to make, I agree that a lot of programmers seem to think they don't make mistakes, and thus might not be receptive to the siren song of referential transparency :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "You never have to aspire to difficulty, darling. It arrives, uninvited. Then it stays for dinner."--Sue Miller ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Re: Wikipedia on first-class object
On 12/29/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > oh, Dennett isn't only source of wisdom. i proposed you this task > because i've my own understanding of it. as i've said in other letter, > both computers and humans may be described using mathematics and > therefore equivalent - as far as we say about theoretical immortal > man and Turing machine He's not the only source of wisdom, but as a rule, it does tend to be good to be as familiar as possible with what has been written before on a subject that you're talking about. Isn't that one of the reasons this mailing list exists, after all? :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "...It's wonderful that I can trust you not to spit in my milk, but what's the point if you're going to drink from the bottle?" -- Sarah Barton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Wikipedia on first-class object
On 12/29/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > Hello Tim, > > Saturday, December 29, 2007, 9:42:48 PM, you wrote: > > > The only thing that computers can do that humans can't is to work > > without getting bored. > > ok, please compute 2^2^30 before continuing discussion. it seems that > you just use "i'm too bored" and "i can't" as synonyms. if computer > will answer "i'm too bored" to any question he can't answer - will it > be enough to give him human rights? > Well, that's why I recommended the Dennett essay. The difference between "I'm too bored" and "I can't" is actually an interesting philosophical question, and people have written about it in detail before. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Instant gratification takes too long."--Carrie Fisher ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wikipedia on first-class object
On 12/29/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > > just imagine compiling of this program without pencil and paper and > you will draw conclusion that computers have power of deduction that > humans definitely doesn't have. and it's only one aspect which doesn't > take into account duration of human life (of course if we want to > say about *real humans* and not abstract mathematical model of immortals), > difference between people's abilities (it's common mistake to compare > abilities of one concrete computer with MAXIMUM of abilities of all > people, including whose in all future generations), don't take into > account that human by itself, at the moment of birth doesn't know > anything about mathematics and even can't speak - he is programmed by > society to acquire these skills > I haven't been following this thread, but anyone interested in this question might want to read Daniel Dennett's essay "Fast Thinking", in his book _The Intentional Stance_. > so, computers are definitely more advanced devices - they was created > to. we (humanity) just don't yet finished development of the program > which at some moment will make them able to further develop itself > without our help. if you believe that human is superior to computer > you should also believe that bacterium is superior to human > The only thing that computers can do that humans can't is to work without getting bored. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's mad to be in love with someone else / When you're in love with him, she's in love with me / But you know as well as I do I can never think of anyone but you" -- Pet Shop Boys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: #haskell works
On 12/20/07, Simon Marlow <[EMAIL PROTECTED]> wrote: > > That's not entirely true - there is a fairly decent linear-scan register > allocator in GHC > > http://darcs.haskell.org/ghc/compiler/nativeGen/RegAllocLinear.hs > > the main bottleneck is not the quality of the register allocation (at > least, not yet). > > The first problem is that in order to get good performance when compiling > via C we've had to lock various global variables into registers (the heap > pointer, stack pointer etc.), which leaves too few registers free for > argument passing on x86, so the stack is used too much. This is probably > why people often say that the register allocator sucks - in fact it is > really the calling convention that sucks. There is some other stupidness > such as reloading values from the stack, though. > [snipped further reasons] Thanks for enlightening me. (I had been opting to believe the various rumor and hearsay floating around rather than actually reading the source :-) One reason why I care about this is that over the summer I was trying to do some performance measurements for House. One of the experiments I did was measuring how long it took to run a loop of Haskell code that just did a no-op FFI call. This was still ten times slower than a loop in C that called the same no-op function. I looked at the generated code (with the native-code backend), noticed the issues you mentioned above (reloading values from the stack, and so on), and concluded that there was probably a good reason why the backend was being worked on actively. The -fvia-C code wasn't much better. However, this was with GHC 6.2, so obviously this suggests that porting House to a newer GHC version might be worthwhile for us to do :-) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Dare to be naive."--R. Buckminster Fuller ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OOP'er with (hopefully) trivial questions.....
On 12/17/07, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote: > This is not a generalization of what you talked about. Why should the tuple > type be unboxed? Tuple types are boxed, meaning there is a difference > between _|_ and (_|_,…,_|_). If you write > > newtype X = X (A, B, C) > > then X doesn't add another level of indirection but the level of indirection > introduced by the tuple constructor remains, of course. So you could write > the above newtype declaration instead of > > data X = X A B C. > I interpreted Evan's question as "why can't you have newtypes with multiple fields?" -- i.e., newtype X = X A B C -- and that's the question I was answering. But maybe I misunderstood. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "After three days without programming, life becomes meaningless." -- James Geoffrey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OOP'er with (hopefully) trivial questions.....
On 12/17/07, Evan Laforge <[EMAIL PROTECTED]> wrote: > Oops, nevermind, I just saw the other thread and link to > http://www.haskell.org/haskellwiki/Newtype. Ok, so that seems like a > pretty subtle diffenence... I'm assuming the rationale behind > differentiating between a single constructor data and newtype is so > that data types don't suddenly change their behaviour around undefined > when they have only one constructor. I would find example y3 > surprising if I came across it in real code! It's not that subtle if you think about what newtype is for. Newtype is like "type", except that you're not just declaring a type synonym, but asking the typechecker to check that you don't use the synonym interchangeably with the type it's standing in for. Types declared with newtype and with type are supposed to act exactly the same way at runtime. In order to act exactly the same way at runtime, if you write newtype X = X A, X _|_ has to be indistinguishable from _|_ at runtime. In other words, the data constructor X has to be strict. In types declared with "data", constructors are lazy -- if they weren't, you wouldn't be programming in Haskell. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "People. Can't live with 'em, can't legally set fire to 'em." -- Sheree Schrager ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OOP'er with (hopefully) trivial questions.....
On 12/17/07, Evan Laforge <[EMAIL PROTECTED]> wrote: > I'm sure there's a trivial explanation for this, but here's something > that I've always kind of wondered about: Given a single constructor > type like "data X = X A B C" can't that be transformed into "newtype X > = X (A, B, C)"? There must be some difference, because if there > weren't we could transform all single constructor types that way, and > dispense with newtype entirely. Strictness. In newtype X = X A, the A field is strict. In data X = X A, the A field is lazy. So the compiler can't just turn all single-constructor "data" types into "newtypes". (To generalize, if you were going to allow newtypes like "newtype X = X (A, B, C)", the tuple would be unboxed, and you'd have the same strictness/laziness distinction.) This is explained in section 4.2.3 of the H98 Report: http://www.haskell.org/onlinereport/decls.html Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Do we learn from our mistakes? I surely hope not / Takes all the fun out of making them again."--Trout Fishing In America ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] #haskell works
On 12/15/07, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: > While this is true in general, loop optimisations are not a particularly > good example, IMO. For them to be effective, you often have to consider > things like instruction scheduling and register pressure which you can't > really do on the Core level. Fair enough for loop optimizations in general, but I think the point about loop unrolling from the "Secrets of the GHC Inliner" paper that I was referring to gives a counterexample to that. In imperative languages, loop unrolling and inlining would be thought of as distinct and very different optimizations -- in a pure functional language, they can be unified. It seems to me that working in a pure functional language makes it easy to write high-level optimizations that can be specified very simply on a level like the level of Core that can then be amplified by a smart backend that takes things like instruction scheduling into account. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Stupidity combined with arrogance and a huge ego will get you a long way." -- Chris Lowe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[6]: [Haskell-cafe] #haskell works
On 12/15/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > i see your point - it's easy to implement everything in GHC. probably > its authors was sleeping last 15 years :) > As you well know, implementing things in GHC isn't always easy for people who aren't named "Simon", and people who are named "Simon" are often busy not so much with sleeping as with coming up with things that will lead to new papers rather than implementing straightforward things that are already pointed out in existing papers :-) (I know it's dangerous to call optimzations "straightforward" before you try to implement them, but even so.) > and ghc was so genuine that it was implemented general case without > implementing special one :) > Isn't implementing the general case and leaving the users to use it to implement the special ones what functional programming is about? :-) > > That's not true in C. The simplicity of Haskell (or rather, > > Core) means it's easy to implement a lot of things with a great deal > > of generality, an advantage that gcc doesn't have. > > Core language has the same complexity for generating good code as C, C-- or > LLVM > Sorry, I don't know what you mean here; I assume by "complexity" you don't mean "time complexity" or "space complexity", and anyway, I don't know what those would mean as applied to a programming language. Care to elaborate? > you may believe in what you want. i prefer to say about real > situation. if it will be possible to quickly write good Haskell > compiler, it was be written many years ago > As others have pointed out, I think that's false. Resources, financial and human, have been thrown at C compilation that have not been thrown at Haskell compilers. As hard-working as the people who work on Haskell compilers are, there aren't very many of them and none of them have "writing Haskell compilers" as a job description. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "The blues isn't about feeling better, it's about making other people feel worse, and making a few bucks while you're at it." -- Bleeding Gums Murphy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: #haskell works
On 12/15/07, Peter Hercek <[EMAIL PROTECTED]> wrote: > Tim Chevalier wrote: > > Try the -Rghc-timing flag. > > Interesting, that one does not work in my program compiled with > ghc 6.8.1 (looks like ghc runtime does not consume it but passes > it to my haskell code). +RTS -tstderr works but its usability is > limited since it provides only elapsed time and not the process > cpu times. > Sorry, my mistake -- it's an RTS option, so: ./program +RTS -Rghc-timing -RTS and I guess you have to compile with -prof. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Live fast, love hard, and wear corrective lenses if you need them." --Webb Wilder ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] #haskell works
On 12/15/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > (I suppose I could try writing a nop program and timing it. But > personally I don't have any way of timing things to that degree of > accuracy. I understand there are command line tools on Unix that will do > it, but not here.) Try the -Rghc-timing flag. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "and there's too much darkness in an endless night to be afraid of the way we feel" -- Bob Franke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] #haskell works
On 12/15/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > Hello Tim, > > Saturday, December 15, 2007, 7:10:26 AM, you wrote: > > >> with support of loop unrolling, > > > GHC calls this "inlining". > > 1. loop unrolling means generating several iterations of loop body, > so that, say, 100 iterations of *p++=*q++ becomes 25 iterations of > *p++=*q++; *p++=*q++; *p++=*q++; *p++=*q++; > I know what loop unrolling means. In a pure functional language, it reduces to inlining, because recursion is used instead of loops, and the inliner can do the job of inlining (a fixed number of) iterations of a recursive function -- I don't know if it does this now, but it would be easy to implement. You don't have to believe me -- read section 4.6 of the inliner paper: http://research.microsoft.com/~simonpj/Papers/inlining/ > 2. actually, ghc can't inline tail-recursive functions at all > (although i don't checked this after 6.4) > It may be that GHC *doesn't* inline tail-recursive functions, but as I pointed out above (which I'm just getting directly from the paper), it would be easy to flip a switch and let it inline a fixed number of iterations of them. > there are also many more optimization tricks. i don't think that > modern compiler with optimization level comparable to gcc can be > delivered without many man-years of development > I think that's an awfully definite statement to make, given that C and Haskell are very different languages, given how many high-level optimizations are possible in Haskell that aren't in C, and given how much higher programmer productivity is in Haskell than C. For example, as above, loop unrolling turns out to be just a special case of inlining. That's not true in C. The simplicity of Haskell (or rather, Core) means it's easy to implement a lot of things with a great deal of generality, an advantage that gcc doesn't have. Or, I mean, feel free to insist things are impossible, but try not to stand in the way of the people who are doing them while you say so. :-) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "It's easy to consider women more emotional than men when you don't consider rage to be an emotion." -- Brenda Fine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] #haskell works
On 12/14/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > There have been some great improvements in array handling recently. I > decided to have a look at the assembly language generated by some > simple array manipulation code and understand why C is at least twice > as fast as ghc 6.8.1. One the one hand it was disappointing to see > that the Haskell register allocator seems a bit inept and was loading > data into registers that should never have been spilled out of > registers in the first place. Someone who knows the backend better than I do can correct me if I'm wrong, but it's my understanding that GHC 6.8.1 doesn't even attempt to do any register allocation on x86. So -- register allocator? What register allocator? But this is being actively worked on; I understand there's code for it in the HEAD. > On the other hand, the code wasn't > fundamentally doing anything weird (eg. it wasn't doing graph > reductions or anything like that, it looked like the sort of loop you > might get from a C compiler). It was a few seconds of fairly mindless > work to fix up the assembly language and make it much faster. And if I > can do it, it means that the next generation of Haskell compiler > should be able to do it too, after all, good freely available methods > to allocate registers do exist. So I'm looking forward to the next > version of GHC matching C's performance for inner loops of array > manipulation code :-) It sounds like Team GHC is thinking about the exact same things you are here: http://hackage.haskell.org/trac/ghc/wiki/Status/Nov07 Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Science fiction is not predictive; it is descriptive." --Ursula K. Le Guin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] #haskell works
On 12/14/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > Hello Dan, > > Friday, December 14, 2007, 11:57:38 PM, you wrote: > > > to allocate registers do exist. So I'm looking forward to the next > > version of GHC matching C's performance for inner loops of array > > manipulation code :-) > > with support of loop unrolling, GHC calls this "inlining". > smart register allocation, This is being worked on actively, AFAIK. > strength reducing Easy to implement (in theory) with GHC rewrite rules, AFAIK (or at least, Simon PJ suggested that that might be so in a mailing list post a few months ago.) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "People tell me I look down / but I'm always standing sixty-six inches off the ground." -- Carrie Bradley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] #haskell works
On 12/14/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > Well anyway, a few years ago we didn't have fusion, This is not true. Shortcut deforestation (fusion) has been in GHC for at least fourteen years: http://citeseer.ist.psu.edu/gill93short.html It's true that we didn't have stream fusion a few years ago. > and we didn't have ByteString. (true.) [snip] > All I know is that once again, it seems Haskell isn't as fast as I thought... > *sigh* No, what you know is that *one particular implementation* of Haskell isn't as fast as you thought. [snip] > A few years ago, the program would have taken 0.35 seconds. > The end. I would be careful about making this statement if I were you. Did you actually try running the same code in GHC 5.0? It's not as if GHC didn't implement *any* optimizations in 2003 (you said above that "0.35 seconds" was the result you got with -O0.) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Now, don't bother to flame me, because by the time you read this post I will be a different person from the one who wrote it. You cannot step in the same river twice." -- Sarah Barton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: Parsing integers [was: Re: [Haskell-cafe] help]
[reply forwarded to list]
-- Forwarded message --
From: Ryan Bloor <[EMAIL PROTECTED]>
hi
sorry for vagueness.
I am writing a basic Parser from scratch. So far I have functions;
# removeSpaces
# match - which checks if a string is a substring of another
# orParser which combines two parser's abilities
# Basic pasrers like... parseInt, parseTrue, parseFalse, parseBool
using the orParser on True and False.
What I want to do now is have a parseBinaryOp that recognises:
parseBinaryOp "+" "(5 + 2) if" >>>gives>>
[(EInt 5, EInt 2, "if")]
So I think that I have to split the initial string into four parts.
"+" becomes op
'(' becomes tokenF
')' becomes tokenB
"5" becomes e1
"2" becomes e2
parseBinaryOp :: String -> String -> [(Expr, Expr, String)]
parseBinaryOp op str = let (tokenF,e1,op,e2,tokenB) =
I am not sure how to go about separating the string for how I need it
using my other functiuons.
Ryan
> Date: Sun, 9 Dec 2007 13:07:23 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Parsing integers [was: Re: [Haskell-cafe] help]
> CC: haskell-cafe@haskell.org
>
> On 12/9/07, Ryan Bloor <[EMAIL PROTECTED]> wrote:
> >
> > hi
> >
> > I have a function parseInt... which needs an error guard for when the input
> > is not an Int.
> >
> > parseInt :: Parser
> > parseInt [] = []
> > parseInt xs = let (digits, rest) = span isDigit (removeSpace xs)
> > in [(EInt (read digits), removeSpace rest)]
> >
> > Also... I have a function that does this... parseBinaryOp "+" "(5 + 2) if"
> > gives...[(Int 5, Int 2, "if")]
> > so, op is '+' or "&&". I am unsure of how to begin...
> >
> > parseBinaryOp :: String -> String -> [(Expr, Expr, String)]
> > parseBinaryOp op str
> >
>
> Check out:
> http://www.haskell.org/haskellwiki/Homework_help
>
> If this isn't homework, try posting again and phrasing your question
> in the form of a question; saying "I am unsure of how to begin"
> doesn't help us help you think about the problem.
>
> Cheers,
> Tim
>
> --
> Tim Chevalier * catamorphism.org * Often in error, never in doubt
> "[Teaching children to read] will make America what we want it to be,
> a literate country and a hopefuller country." -- George W. Bush
Are you the Quizmaster? Play BrainBattle with a friend now!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Parsing integers [was: Re: [Haskell-cafe] help]
On 12/9/07, Ryan Bloor <[EMAIL PROTECTED]> wrote: > > hi > > I have a function parseInt... which needs an error guard for when the input > is not an Int. > > parseInt :: Parser > parseInt [] = [] > parseInt xs = let (digits, rest) = span isDigit (removeSpace xs) > in [(EInt (read digits), removeSpace rest)] > > Also... I have a function that does this... parseBinaryOp "+" "(5 + 2) if" >gives...[(Int 5, Int 2, "if")] > so, op is '+' or "&&". I am unsure of how to begin... > > parseBinaryOp :: String -> String -> [(Expr, Expr, String)] > parseBinaryOp op str > Check out: http://www.haskell.org/haskellwiki/Homework_help If this isn't homework, try posting again and phrasing your question in the form of a question; saying "I am unsure of how to begin" doesn't help us help you think about the problem. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "[Teaching children to read] will make America what we want it to be, a literate country and a hopefuller country." -- George W. Bush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
On 12/5/07, Ivan Miljenovic <[EMAIL PROTECTED]> wrote: > How I envisage it happening is that a parser would be used to find all > "functions" in the given code, treat these as nodes in the graph and > then use directed edges to indicate which functions call other > functions. aka a "call graph". This is called "control flow analysis" and the classic paper on it is Olin Shivers' dissertation, "Control Flow Analysis of Higher Order Languages" (http://repository.readscheme.org/ftp/papers/shivers-diss.ps.gz ). > This resultant graph can then be analysed in various ways > suitable to the context (e.g. find that a library module can be split > into two since there are two completely separate trees present in the > graph that don't interact at all, or if a function is only ever called > by one other function then it can be subsumed into it). > One example of an analysis like this is done by GHC's inliner. See the paper "Secrets of the Glasgow Haskell Compiler Inliner" by Peyton Jones and Marlow (http://research.microsoft.com/~simonpj/Papers/inlining/). > So, here is the question I ask of all of you: is this feasible? Do > you know if anything like this has ever been attempted before? I know > there are some other usages of graph theory related to source code > (e.g. McCabes complexity metric [1]), but I couldn't seem to find > anything related to what I'm proposing. I intend to code this up in > Haskell (possibly using FGL: I know of it, but haven't really looked > at it) and use Haskell as my primary target for analysis, so in a > sense the resultant graph could be seen as a Haskell equivalent to > UML. > This is very well-trodden ground, but if you familiarize yourself with the literature on the subject, then who knows, you may discover something new. And you can take pleasure in knowing that you've already independently conceived of an idea that lots of smart people have seen fit to put a lot of time into :-) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "It's true I don't want to join the Army or turn lathes in precision parts factories, I'm nearsighted and psychopathic anyway. America I'm putting my queer shoulder to the wheel." -- Allen Ginsberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible Improvements
On 12/2/07, Don Stewart <[EMAIL PROTECTED]> wrote: > prstanley: > > Hi > > data Tree = Leaf Int | Node Tree Int Tree > > > > occurs :: Int -> Tree -> Bool > > occurs m (Leaf n) = m == n > > occurs m (Node l n r) = m == n || occurs m l || occurs m r > > > > It works but I'd like to know if it can be improved in any way. > > You could probably get away with: > > data Tree = Leaf !Int | Node Tree !Int Tree > > but that's a minor issue. > IMO, there's no reason to even think about putting in the strictness annotations unless you've identified this datatype as part of a performance bottleneck in production code. Otherwise, there's no need to clutter your code and your mind with them :-) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Base eight is just like base ten, really... if you're missing two fingers." -- Tom Lehrer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] who develops and maintains the Unix package?
On 12/2/07, Galchin Vasili <[EMAIL PROTECTED]> wrote: > Hello, > > I am starting to get in the groove related to runhaskell -- > config/builds on top of cygwin (I haven't had time to carve up hard drive > and install Linux). > > In any case, I really want to get the Unix package to build on > cgywin (as advertised at > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.2.0.0). > When i do "runhaskell Setup.lhs configure" > things seem to go fine, .log fine is clean, and pertinent cygwin include > files like times.h are found, but when i do a "runhaskell Setup.lhs build" > then the include files that are allegedly found during the configure > "probe" cannot be found. > > > 1) During the "runhaskell Setup.lhs build" step, what human readable > file > is used and contains paths to the cygwin Posix include file > directories? 2) thatis foloowing is a better approach for me .. => > > 2) Somebody obviously put " (except under Cygwin)". Can you point at > who made this claim and why? > When in doubt, email [EMAIL PROTECTED] with library questions (indeed, the Hackage page for the unix package lists libraries@ as the maintainer.) It doesn't surprise me that the unix package wouldn't work on Cygwin. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Are you aware that rushing toward a goal is a sublimated death wish? It's no coincidence we call them 'deadlines'." -- Tom Robbins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] AmeroHaskell
On 11/17/07, Derek Elkins <[EMAIL PROTECTED]> wrote: > Don mentioned that. However, something specifically Haskell and aimed > at a wider audience than just the Portland area is desirable. It's also > a different tone than a user group. Hopefully, there would be a reprise > next year in a different location. That said, I imagine many of those > going to pdxfunc would be interested in AmeroHaskell and certainly it > could be set up as a pdxfunc meeting++. At this point building momentum > for AmeroHaskell is what I'd like. > Oh, ok, I think I probably just read your post too quickly. So you're going for something roughly equivalent to AngloHaskell? Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "...Losing your mind, like losing your car keys, is a real hassle." -- Andrew Solomon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] AmeroHaskell
On 11/17/07, Derek Elkins <[EMAIL PROTECTED]> wrote: > However, to put things in motion for something concrete at all, we're > hoping to put together a meeting taking place in the Portland area as > that seems most convenient to the most people who had registered > interest in AmeroHaskell and an easy place to find a venue. In that > vein, while no plans have been made, something aimed for the > January/February time-frame and probably hosted by Galois, if they are > willing, has been discussed. > In Portland, we've already had the first pdxfunc meeting: http://groups.google.com/group/pdxfunc While billed as a functional programming user group rather than a Haskell-specific group, we shouldn't duplicate effort. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "I don't know whether I believe in me, but I still believe in my friends" -- Nerissa Nields ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small optimisation question
On 11/17/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > Suppose I write something like this: > > foo :: [Int] > foo = concat (replicate 4 [4,7,2,9]) > > The value of "foo" is completely determined at compile-time. So, will > the compiler generate calls to concat and replicate, or will it just > insert a large list constant here? > To add to what others have said, you might want to read the Simons' paper "Secrets of the Glasgow Haskell Compiler Inliner": http://research.microsoft.com/~simonpj/Papers/inlining/ It's pretty accessible, and talks about the various knobs that can be twiddled in order to influence the black art of inlining. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "'There are no atheists in foxholes' isn't an argument against atheism, it's an argument against foxholes." -- James Morrow ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FP design
On 11/5/07, Levi Stephen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm was wondering how most people work during when designing a functional
> program. Do you create data structures/types first? Do you work from some type
> signatures?
>
> For example, take a blog. Is the first step likely to be something like:
>
> data BlogEntry = BlogEntry {
> title::String,content::String,comments::[Comment] }
> type Blog = [BlogEntry]
>
> or more likely thinking about what functions will be required:
>
> addEntry :: BlogEntry -> Blog -> Blog
> displayBlog :: Blog -> HTML
> displayEntry :: BlogEntry -> HTML
>
I don't know how you can do one without the other. I would probably
start in a case like this by writing down a few basic types, then
trying to start to write down the function type signatures, which will
probably point to more types that need to be defined, iterating until
I reach a fixed point. I can't write type signatures unless I know
what the types are. But I don't know what the types should look like
unless I know what the interface should look like, either.
One thing that's for sure, though -- I always write type signatures
for top-level definitions. I can't think straight unless I write the
type signature before writing the code.
Cheers,
Tim
--
Tim Chevalier * catamorphism.org * Often in error, never in doubt
"Thus spake the Master Programmer: When you have learned to snatch the
error code from the trap frame, it will be time for you to leave."--J.
Geoffrey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monte Carlo Pi calculation (newbie learnings)
On 11/5/07, Alex Young <[EMAIL PROTECTED]> wrote: > > randList :: Int -> [IO Int] > randList n = randListTail [] n > > randPairs :: Int -> [(IO Int, IO Int)] > randPairs n = zip (randList n) (randList n) [snip] > > doCountPair :: (IO Int, IO Int) -> IO Int > doCountPair (a, b) = do >x <- a >y <- b >return (pairIsInside x y) > > fSumListTail :: Int -> [(IO Int, IO Int)] -> IO Int > fSumListTail total [] = do >return total > fSumListTail total (x:xs) = do >y <- doCountPair x >fSumListTail (total+y) xs > > fSumList :: [(IO Int, IO Int)] -> IO Int > fSumList l = fSumListTail 0 l > It's unusual to return a list of IO actions or to take a list of pairs of IO actions as an argument. You should think about whether there's a reason you're doing this. For example, why not rewrite randList as: randList :: Int -> IO [Int] randList n = sequence $ randListTail [] n (for example)? > piAsDouble :: Int -> Int -> Double > piAsDouble a b = >(fromInteger (toInteger a)) / (fromInteger (toInteger b)) > This can be rewritten as: fromIntegral a / fromIntegral b (I think -- not tested. The above isn't tested either.) Those are just a couple things that jump out at me. fSumListTail looks like it should be expressible using a foldM as well. In fact, fSumListTail looks like it ought to be a pure function. Think about how you can isolate the parts of the code that do IO so that most functions are pure. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Faith, faith is an island in the setting sun / But proof, yes, proof is the bottom line for everyone."--Paul Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The question of ByteString
On 11/2/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > > 1. Why do I have to type "ByteString" in my code? Why isn't the compiler > automatically performing this optimisation for me? (I.e., is there some > observable property that is changed? Currently the answer is yes: the > ByteString interface only provides "trancated" Unicode characters. But, > in principle, that could be changed.) That's an interesting question; one property the compiler would have to prove in order to replace a String with a ByteString is that the given String will be fully evaluated strictly (e.g., not just that it will be evaluated to WHNF, but that each of its elements will be demanded). Currently, GHC's demand analyzer doesn't look inside lists (it only looks inside things that have product types), but it's not unimaginable. It would be a matter of whether the potential payoff justifies the complexity of the imagined analysis, as always. > > 2. ByteString makes text strings faster. But what about other kinds of > collections? Can't we do something similar to them that makes them go > faster? > > As I understand it, ByteString is faster due to several factors. First > of all, it's stricter. Secondly, it's an "unboxed" structure (so you > eliminate layers of indirection and there's less GC load). Third, it's > implemented as an array that looks like a linked list. Given how > ubiquitous lists are in Haskell, "array that looks like a linked list" > sounds like one seriously useful data type! Yet ByteString seems to be > the only implementation of this concept - and only for lists on unboxed > bytes. (Not even unboxed Word16 or anything else, *only* Word8.) If I > understand this correctly, a ByteString is actually a linked list of > large array chunks. (This presumably yields fastER random access than a > plain linked list?) Also, it seems to be possible to create a new array > which is merely a subrange of an existing one, without any copying; the > standard array API doesn't seem to provide this, yet it sounds damn useful. > > These are the things I'm thinking about. Is there some deep theoretical > reason why things are the way they are? Or is it merely that nobody has > yet had time to make something better? ByteString solves the problem of > text strings (and raw binary data) very nicely, it's just a pitty we > can't apply some of that know-how more widely... > I don't think there's a deep theoretical reason why this doesn't exist, but I also don't think it's necessarily *just* a matter of no one having had time yet. As always, there are trade-offs involved, and people try to avoid introducing *too* many special cases into the compiler. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "I give fellowship advice, not relationship advice." -- Michael Sacramento ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The question of ByteString
On 11/2/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > Somewhat related to the discussions about Haskell's performance... > > String. ByteString. Do we really need both? Can one replace the other? You can't get rid of "String" because a String is just a [Char]. Requiring the element type of a list to be "anything except Char" would be silly. In addition, it's useful to have a String that you can apply arbitrary list operations to when performance isn't a concern (i.e., most of the time). Finally, removing String would break existing code. > Why is one faster? Can't we make *all* lists this fast? [insert further > variations here] ByteString takes advantage of the fact that the elements are, well, bytes. The operations are optimized for reading large amounts of text, but not necessarily for other applications. Lists are a parameterized type, so the elements of a list are pointers to arbitrary data. So that's why the same tricks as ByteString don't apply to general lists. That isn't to say that there aren't possible optimizations which haven't yet been dreamed of. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "It is a defect of God's humour that he directs our hearts everywhere but to those who have a right to them." -- Tom Stoppard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type inference problem with division (/)
On 10/30/07, Felipe Lessa <[EMAIL PROTECTED]> wrote: > On 10/30/07, Tim Chevalier <[EMAIL PROTECTED]> wrote: > > ppos = pi/len2; pi and len2 are both Ints, so dividing them gives you > > an Int. To convert to a Double, write ppos = fromIntegral (pi/len2). > > (Type :t fromIntegral in ghci to see what else fromIntegral can be > > used for.) > > You mean pi / fromIntegral len2, right? > You're right, that's what I meant. Sorry for the confusion. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Unfortunately, there is no algorithm for making human relationships work." -- Robin Williams ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type inference problem with division (/)
On 10/30/07, noa <[EMAIL PROTECTED]> wrote: > > Hi! > > I have the following function: > > theRemainder :: [String] -> [String] -> Double > theRemainder xs xt = sum( map additional (unique xs) ) > where > additional x = poccur * (inf [ppos,pneg]) --inf takes [Double] > where > xsxt = zip xs xt > pi = countPos xr -- countPos returns an Int > ni = (length xr) - pi > len = length xs > len2 = length xr > ppos = pi/len2 -- THESE ARE THE PROBLEM > pneg = ni/len2 -- THESE ARE THE PROBLEM > poccur = (pi+ni)/len > xr = (filter ((\y -> (fst y)==x)) (xsxt)) > > And I am getting this error message with ghc: > > matrix.hs:54:31: > Couldn't match expected type `Double' against inferred type `Int' > In the expression: ppos > In the first argument of `inf', namely `[ppos, pneg]' > In the second argument of `(*)', namely `(inf [ppos, pneg])' > > How can I change the declaration of ppos nad pneg so they are treated as > Double for the inf function? > ppos = pi/len2; pi and len2 are both Ints, so dividing them gives you an Int. To convert to a Double, write ppos = fromIntegral (pi/len2). (Type :t fromIntegral in ghci to see what else fromIntegral can be used for.) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "After three days without programming, life becomes meaningless." -- James Geoffrey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Image manipulation
On 10/29/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote: > The OP specified that the images are around 5M in size, and need to be > rescaled, so we're talking about quite a bit of computation per shellout > (tens to hundreds of megacycles). Are context switches that slow? > I don't know. I'd have to do the experiment before I could give an answer to that. But yeah, if I were the OP, I would probably start by trying to write a shell script (or a simple Haskell program with calls to "system") to do what I wanted, and see if that was adequate. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Work a little bit harder on improving your low self-esteem, you stupid freak" -- "Weird Al" Yankovic ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Image manipulation
[redirecting to haskell-cafe] On 10/29/07, Brent Yorgey <[EMAIL PROTECTED]> wrote: > Haskell is a wonderful language, so I hate to say this...but personally I > don't see the benefit of using Haskell here, unless the manipulations you > want to do are very complex. Some simple shell (or > perl/python/ruby/whatever) scripts to glue together some calls to convert > (or possibly other ImageMagick utilities) ought to do the job just fine. > If you're doing many image transformations, invoking an external program like convert will get expensive due to context-switching. So that's why something like the (not-yet-existent) bindings for ImageMagick-as-a-library might be useful. I agree that laziness probably isn't going to be helpful, but there may be interesting things to be done that are enabled by purity and higher-order-functions. I'm working on the ImageMagick bindings because I'm curious to find out. There are obvious things like being able to define compositions of transformations -- which is easy to do when you're calling library functions in-memory, and less so if you're using a separate executable -- but maybe there are more interesting applications too. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Thus spake the Master Programmer: When you have learned to snatch the error code from the trap frame, it will be time for you to leave."--J. Geoffrey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fusion for fun and profi (Was: newbie optimization question)
On 10/28/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote: > On Sun, Oct 28, 2007 at 01:43:07PM -0700, Don Stewart wrote: > > stefanor: > > > IO blocks unboxing in GHC. How fast is your mock-C code refactored to > > > do IO outside of the loops only? > > > > It doesn't! The above code yields: > > > > Main.$wloop :: GHC.Prim.Int# > >-> GHC.Prim.State# GHC.Prim.RealWorld > >-> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) > > > > $wgo_rMK :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> > > GHC.Prim.Int# > > where > > $s$wgo_rMI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# > > Ah, interesting. I was reading something too general from > http://hackage.haskell.org/trac/ghc/ticket/1592#comment:5. > Right, unboxing is successful here because the arguments are marked as strict with (!) annotations. The IO hack described in that bug report would only be a problem if the arguments were not marked strict, and were used in code that has to be executed after an IO call. Although I don't think all of the strictness annotations are even necessary here. In any case, loop must evaluate i before the call to print; there would only be an issue if it called an IO function before doing anything that demands i. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Accordingly, computer scientists commonly choose models which have bottoms, but prefer them topless." -- Davey & Priestley, _Introduction to Lattices and Order_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function Types
On 10/22/07, PR Stanley <[EMAIL PROTECTED]> wrote: > f x = x > x :: a > f x :: b > therefore f :: a -> b > x = a and x = b > therefore a = b > therefore f :: a -> a > Simple mappings are easy to work out. It's the more detailed stuff > I'm not sure about. > f g x y = g x (y x) > Benjamin Pierce's _Types and Programming Languages_ has some good chapters on type inference. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Ever wonder why 'bus error core dump' is the standard C program crap out? Because C freely hands out random pointers to anyone that asks. Slut." -- Olin Shivers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS Abstraction module??
On 10/22/07, Neil Mitchell <[EMAIL PROTECTED]> wrote: > The key thing to note about this is that whether a program is running > on Windows or Posix is fixed at compile time. Things like classes can > do some of what you seem to be after, but it tends to be easier to > reach for the C pre processor. > Although there's also the System.Info.os function if you want to avoid CPP: http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-Info.html However, since it just returns a string, it may not be too much better than using CPP... Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "We have no knowledge and so we have stuff / but stuff without knowledge is never enough to get you there" -- Greg Brown ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS Abstraction module??
On 10/22/07, Galchin Vasili <[EMAIL PROTECTED]> wrote: > > ^^ how? If I define something like "class OS where " and define a > POSIX instance of "class OS" and a Win32 API instance.. function calls will > be to the instances and hence the OS APIs are visible. Yes? I'm not sure what you mean. We don't have classes in Haskell (we do have something called "type classes", which don't have much to do with the OO notion of a "class".) I almost never have occasion to import the POSIX or Win32 API modules when writing Haskell code. As Neil implied, Haskell code is portable by default, and if you want to make it non-portable, you have to go to a lot of effort. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "I don't care too much for money/Money can't buy me TeX." -- Jason Reed ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS Abstraction module??
On 10/22/07, Galchin Vasili <[EMAIL PROTECTED]> wrote: > Hi Neil, > > I am really talking about a module or perhaps a Haskell class that > provides notion for multiple threads of execution, semaphores, .. that > "hides" POSIX vs Win32 APIs .. i.e. the underlying OS APIs would be totally > hidden. The reason I bring this up is that OS abstraction layers are very > common in "mainstream" languages like C++. Any code written using an OS > abstraction layer is absoutely portable. IMO if Haskell (or say OCaml) want > to be accepted by industry this kind of functionality is absolutely > critical. Sure, that would be Concurrent Haskell: http://haskell.org/haskellwiki/GHC/Concurrency If that's not what you're looking for, post again. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "in a recent future, this is past" -- James Keelaghan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
On 10/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Dan Weston writes: > > > I find the mathematics is more accurate on > > > > http://www.conservapedia.com > > > > Their facts get checked by the Almighty Himself! ;) > > Since decent people here pointed out how my sarcasm may be blessing and > useless, I must ask (living so far from the Bible Belt that I miss all > standard American connotations...) > > Are you serious? > (Not about the checking by the Lord, but concerning the quality of that > conservapathologia?) > I think he might have been being sarcastic. But I can't be sure. Anyway, regarding the original question about WIkipedia: I don't "trust" anything on Wikipedia (or in textbooks, or the ICFP proceedings, or when someone's telling it to me...) -- I apply critical reasoning to what I read there, same as with everything else. If you've read enough Wikipedia articles, you know when things "smell bad". Citations (doesn't have to be a lot, but every article should have at least one) to reasonable published sources are a good tip-off that an article is legitimate. And as others have said, math articles don't tend to attract a lot of the kinds of people who would insert deliberately wrong information. As with the Haskell mailing list, you just have to watch out for unintentionally wrong information (and enough people watch the math articles that this probably tends to get fixed quickly.) Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "There are no sexist decisions to be made. There are antisexist decisions to be made. And they require tremendous energy and self-scrutiny, as well as moral stamina..." -- Samuel R. Delany ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stack overflow in ghci
On 10/17/07, Maurício <[EMAIL PROTECTED]> wrote: > Hi, > > I get this error message when testing a function > in ghci: > > *** Exception: stack overflow > > I admit I didn't care about efficiency when I > wrote that function, but I'm almost sure it is not > supposed to eat all my memory. Do I need to say > something to ghci if I want it to use all > available memory? > You can start ghci with the -K option to increase the stack size -- ghci +RTS -K256m -RTS for example, sets the maximum stack size to 256 MB. However, stack overflows are usually (though not always) a sign of buggy code, as they're often caused by infinite recursion, and you want to be notified of that sooner rather than later. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Live fast, love hard, and wear corrective lenses if you need them." --Webb Wilder ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
