Re: [Haskell-cafe] Re: System.Random StdGen read fails on some strings? [also continues: Random/StdGen/read: there is something unclear (or misunderstood!)]
On 3/19/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: Zara Good point. It's a bit stupid that 'read' fails utterly on strings shorter than 6. I don't thin StdRandom has an "owner" at the moment. There's a process for proposing library changes, described under "guidelines for developers" here http://haskell.org/haskellwiki/Libraries_and_tools That's the way to get your change adopted. There's already a thread about this on the libraries list: http://www.haskell.org/pipermail/libraries/2007-March/007052.html Ian commented with a proposal for fixing it, and no one has followed up yet. That would probably be a good place to direct any more discussion. Cheers, Kirsten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Random/StdGen/read: there is something unclear (or misunderstood!)
This does seem to be a bug; see: http://www.haskell.org/pipermail/libraries/2007-March/007034.html (from a few minutes ago) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "and the things I'm working on are invisible to everyone"--Meg Hutchinson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for Accessibility
On 3/6/07, Tom Hawkins <[EMAIL PROTECTED]> wrote: I love programming in Haskell, yet even its concise expressions have not saved my tendons from chronic RSI. Has anyone put any thought into building an accessible Haskell development interface for those who may not be able to use a keyboard? One inspirational program is Dasher (http://www.inference.phy.cam.ac.uk/dasher/). Not only is it godsend for people with a wide range of disabilities, Dasher is also a lot of fun to use. There's also the Harmonia project: http://harmonia.cs.berkeley.edu/harmonia/index.html which has the advantage of being a programming-language specific project. From their web page: "Harmonia is an open, extensible framework for constructing interactive, language-aware programming tools. Program source code is represented by annotated abstract syntax trees augmented with non-linguistic material such as whitespace and comments. The analysis engine can support any textual language that has formal syntactic and semantic specifications. ...New languages can be easily added to Harmonia by giving the system a syntactic and semantic description, which is compiled into a dynamically loadable extension for that language. Among the languages for which descriptions exist are Java, Cool (a teaching language), XML, Scheme, Cobol, C, and C++. Other languages are being added to Harmonia as resources permit." So adding a Haskell module might not be difficult. They also have a recent paper on voice-recognition-based input for programming environments. I haven't actually used Harmonia myself, but I know some of the people who've been involved, and as a fellow RSI sufferer, I'd also love to see these tools get wider exposure. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "I broke my watch when I put up my calendar / I left my map on the roof of my car / I need somebody to make it seem worth it / To search for a light switch or reach for a star" -- Dom Leone ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recursion
On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Does the following code increase the level of recursion once for each input line or is the recursive construct converted to an iteration? As was pointed out, tail recursion in Haskell isn't straightforward. The answer may also depend on which implementation of Haskell you're using. But I assume you mean GHC. If you want to know for sure, I suggest reading the intermediate code produced by GHC for this example (or perhaps an even smaller version of your example that retains the recursive structure but doesn't do IO). For some help with that, check out the manual's section on "How to read Core Syntax": http://www.haskell.org/ghc/docs/latest/html/users_guide/options-debugging.html#id3151366 and ask on this mailing list if you have any questions. Depending on why you're asking, actually reading the intermediate code may be overkill, but since you didn't say why you wanted to know, I assume you're just curious. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] LGPL libraries
On 3/5/07, Neil Mitchell <[EMAIL PROTECTED]> wrote: As others have said though, I wouldn't worry overly about it. The whole concept of static linking being wrong, but dynamic linking being fine, when you can flip between the modes just by changing compiler, is just silly. You don't infringe (or uninfringe) copyright with a command line flag. I am not a lawyer, but there are a couple of important points getting missed in this thread: (1) Few people have ever claimed that copyright law in the United States made any rational sense. Even so, Americans are subject to it, anybody who uses GPLed software may be subject to it, and given that the general trend is toward international treaties that subject their member nations to the copyright requirements of the nation with the most restrictive intellectual property laws, it may be safe to say that everyone is subject to it. "That's just silly" isn't a defense. (2) To paraphrase Eben Moglen, the legal basis for copyrighting software in the US is predicated on the notion that certain large numbers can be copyrighted. Thus, if you can infringe copyright by adding one to a large number, it suddenly doesn't seem so absurd that you can infringe copyright by setting a command line flag. (3) The GPL has never been tested in court, so debates about whether or not static linking can result in a GPL violation are ultimately academic, at least insofar as the real question is whether it's prudent for a company to use GPLed libraries in proprietary software (as the real question usually is). If someone is asking about GPL issues in the first place, it's probably because their boss told them "our lawyers say we're not allowed to use anything GPLed," and thus "trust me, we're not going to sue you" isn't the answer they're looking for, even if it's a completely accurate answer. Since there are people reading this list who release their software under various flavors of the GPL, and who thus presumably care that the free software they sweat over will remain free in perpetuity, hopefully this reply isn't entirely off-topic! Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] MPTCs and rigid variables
On 3/5/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: 4. The "rigid type variable" thing isn't just an implementation question. What *would* you like the error message to say when you write f :: ([a], Int) -> Int f (x:xs, y) = x+y Here we unify 'a' with Int, which is wrong. What would a nicer error message say? IMO, the "rigid type variable" error message is confusing for two reasons: (1) it doesn't suggest to the user (or at least the novice-to-intermediate user) what they should do to solve the problem, and (2) it makes the user feel like they need to go read six papers on type inference before they can make any progress when all they wanted to do is add two numbers. In this particular case, something like "Suggested fix: change 'a' in the type signature to 'Int'" would be an improvement: it addresses reason (1), and putting it ahead of the "rigid type variable" part (e.g., textually highlighting the more newbie-friendly portion of the error message) addresses reason (2). (I realize that the same error might occur in cases where the type variable isn't bound by a user type signature, but it's common enough for users to insert type signatures when the code isn't compiling that I think it's worth it to treat that as a special case, even if there isn't a more general way to improve the error message.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "And I have grown with each disappointment through the years" -- Great Big Sea ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Laziness and the IO Monad (randomness)
[redirecting to haskell-cafe] On 3/1/07, Dave Tapley <[EMAIL PROTECTED]> wrote: However this latter case gets stuck in an infinite loop, terminating on a stack overflow. My question asks why this is the case, when laziness should ensure only the first 10 cases need to be computed. You didn't say which function you had narrowed down the stack overflow to, but I suspect it's here: firstTen :: IO [Int] firstTen = do infiniteNums <- iterateM addRand randNum return (take 10 infiniteNums) In order for IO to work the way you'd expect, you have to be able to specify which IO operations happen in what order, which is exactly what a do-block within the IO monad specifies. But specifying the order of operations also means specifying in what order evaluation happens. So, the code you've written means "evaluate infiniteNums fully (in order that we might do whatever IO operations it involves before the return statement), then return the first 10 elements of its result." Since you're forcing evaluation of an infinite list, the program loops infinitely. If you find this counter-intuitive, you wouldn't be the first, but there's no other sensible interpretation for the code you've written. Deferring evaluation of infiniteNums in this case would mean that IO would happen in a strange and unpredictable order (or if it actually wouldn't, then the compiler isn't smart enough to know that.) I would solve this problem by writing a version of iterateM that takes the length of the desired list as an argument (e.g., 10 in your example), which sadly breaks modularity, but as I explained above, working within the IO monad necessitates that. Someone more l33t than me may be able to suggest a more elegant solution, though. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "They killed, they maimed, and they called information for numbers they could easily look up in the book." -- Woody Allen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting Hairs Over Terminology
On 2/26/07, P. R. Stanley <[EMAIL PROTECTED]> wrote: Back to the comma, surely, syntax sugar fulfills the role of an operator, a function, or a sequence of low-level procedures, either in part or comprehensively. In C, for example, iteration could be implemented using the if construct with the dreaded goto command. So, strictly speaking, the while loop could be classed as syntax sugar. Yet, the while loop is a well-recognized construct in its own right. I hope you can see what I'm driving at. It's useful to see the square-bracket-and-comma list notation in Haskell as syntactic sugar because you don't need to worry about what it means; you just need to know how to mentally translate it into applications of cons and nil, and you already know what those means. Indeed, Haskell compilers are based on that same principle. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Apathy at the individual level translates into insanity at the mass level." -- Douglas Hofstadter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting Hairs Over Terminology
On 2/26/07, Dan Weston <[EMAIL PROTECTED]> wrote:
P. R. Stanley wrote:
> In C, for example, iteration could be implemented using the if construct
> with the dreaded goto command. So, strictly speaking, the while loop
> could be classed as syntax sugar. Yet, the while loop is a
> well-recognized construct in its own right.
> I hope you can see what I'm driving at.
Syntactic sugar is fully desugared at compile time. A while loop with
constant limits *could* be considered syntactic sugar if the compiler
can statically unroll the loop. Variable limits are definitely beyond
this definition, since they can only be evaluated at runtime.
I think what P.R. meant is that while loops in C can be desugared like this:
while(condition) {
stuff
}
more_stuff
=>
loop:
if(!condition)
goto exit;
stuff
goto loop;
exit:
more_stuff
No static unrolling of the loop happens. So in the sense of "syntactic
sugar" that means "a construct that can be defined in terms of other
language constructs", while is syntactic sugar in C.
Not sure what the original point was, though.
Cheers,
Kirsten
--
Kirsten Chevalier* [EMAIL PROTECTED] *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] Delaling with State StateT and IO in the same function
On 2/26/07, Alfonso Acosta <[EMAIL PROTECTED]> wrote: On 2/27/07, Kirsten Chevalier <[EMAIL PROTECTED]> wrote: > I may be missing something, but why are you using both State and > StateT? Maybe I don't understand your code, but it seems like you > could be using StateT everywhere you're currently using State. Well, as far as I know using "StateT s IO a" for the input functions would force the state and value of their monad to stay within IO. That restriction dissapears by using barely "State s a" Ah, ok. So what if you changed your netlist function so that the type sig would be: netlist :: DT.Traversable f => (State s (S HDPrimSignal) -> State s v ) -> -- new (State s (Type,v) -> S v -> State s ()) -> -- define State s (f HDPrimSignal) -> -- the graph IO (State s ()) I didn't follow your code well enough to be sure that this would help, but I think it might. Or why not: netlist :: DT.Traversable f => (State s (S HDPrimSignal) -> State s v ) -> -- new (State s (Type,v) -> S v -> State s ()) -> -- define State s (f HDPrimSignal) -> -- the graph IO s which seems to me like it would be even simpler, unless you're planning on composing calls to netlist together (and from the code you gave, I can't tell whether you are.) If your code is such that refactoring it to have either of those types wouldn't make sense, stating the reasons why should clarify things for the rest of us. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Delaling with State StateT and IO in the same function
On 2/26/07, Alfonso Acosta <[EMAIL PROTECTED]> wrote: The returned type is a StateT and the only way in which I succesfully managed to internally work with both State and StateT is converting from the former to the later one using this function (not elegant at all) I may be missing something, but why are you using both State and StateT? Maybe I don't understand your code, but it seems like you could be using StateT everywhere you're currently using State. Also, your type signatures would be easier to read if you defined a type synonym for your instantiation of StateT, e.g.: type AlfonsoM s = StateT s IO () and then everywhere you write (StateT s IO ()) now, you could write (AlfonsoM s) instead. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "...People who mind their own business die of boredom at thirty."--Robertson Davies ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] [Fwd: Re: Computer Language Shootout]
[redirecting to haskell-cafe, since this is getting to be a long discussion] On 2/26/07, Andrzej Jaworski <[EMAIL PROTECTED]> wrote: The examples I pointed to seem to share strong and relatively consistent logic of a program. In case of large GA (e.g. Royal Road Problem) and IFP (e.g. ADATE) SML was exhaustively proved to predict this logic much better. Can you clarify what you mean by this? How do you formally prove that a programming language (rather than a specific implementation of one) performs better for a given problem? Or do you mean that a specific implementation of this problem in SML performed better than a specific implementation of it in Haskell? In case of Algebraic Dynamic Programming C compiler seems to address specific properties of a program more adequately which leads to substantial improvements in optimization. It is important to stress that we deal in ADP with strong logic of the domain application. Handcrafting C code for regular applications does not show that kind of advantage, so it wouldn't leave Haskell in the dust. In general declarative nature has the edge over C craftsmanship (see: http://www.clip.dia.fi.upm.es/papers/carro06:stream-interpreter-TR.pdf). I've read a few of your posts and I still don't understand what you mean by a compiler "address[ing] specific properties of a program". Can you give an example of the kinds of program properties you're talking about, and explain how C compilers exploit them in a way that Haskell compilers currently fail to do? Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Religion is just a fancy word for the Stockholm Syndrome." -- lj user="pure_agnostic" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: LugRadio talk
On 2/16/07, Kirsten Chevalier <[EMAIL PROTECTED]> wrote: On 2/15/07, Kirsten Chevalier <[EMAIL PROTECTED]> wrote: > So which date was this infamous show where they talked trash about > Haskell, anyway? I want to hear this firsthand, but the tables of > contents given on their web sites don't seem to list "talking trash > about Haskell" as an item :-) > For anyone else who might be wondering (and who, like me, can't resist a trainwreck), I answered my own question: http://www.lugradio.org/episodes/68 (January 2, 2007), about 0:10:00 into the podcast. Also: http://www.lugradio.org/episodes/70 (January 29, 2007) at 1:13:16, if you want to hear them (mis)quote from Simon's reply to the above. -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Daylight savings never saved me anything / and Thanksgiving time never gave me anything / and Autumn's peak only made me wish for spring / and the daylight, and the wealth of time" -- Eddie From Ohio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: LugRadio talk
On 2/15/07, Kirsten Chevalier <[EMAIL PROTECTED]> wrote: So which date was this infamous show where they talked trash about Haskell, anyway? I want to hear this firsthand, but the tables of contents given on their web sites don't seem to list "talking trash about Haskell" as an item :-) For anyone else who might be wondering (and who, like me, can't resist a trainwreck), I answered my own question: http://www.lugradio.org/episodes/68 (January 2, 2007), about 0:10:00 into the podcast. -- Kirsten Chevalier* [EMAIL PROTECTED] *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] new member
On 2/16/07, P. R. Stanley <[EMAIL PROTECTED]> wrote: Hi Paul here - new member - checking to see my account is fully functional. Does the list know of another list where I can post questions on functional programming and the related mathematics? I'm assuming Haskell Cafe is mainly for discussions on Haskell programming and not so much the underlying theory. comp.lang.functional on Usenet would probably be a good place. Or the fora on Lambda the Ultimate: http://lambda-the-ultimate.org/forum Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "The astonishment of life is the absence of any appearance of reconciliation between the theory and practice of life."--Emerson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: LugRadio talk
So which date was this infamous show where they talked trash about Haskell, anyway? I want to hear this firsthand, but the tables of contents given on their web sites don't seem to list "talking trash about Haskell" as an item :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Like the rest of the human race, you are one of a kind."--Ani DiFranco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange memory consumption problems in something that should be tail-recursive
On 2/13/07, Jefferson Heard <[EMAIL PROTECTED]> wrote: Argh, bitten by the scheme bug! Right -- NO tail recursion... So that leaves me with some rather non-intuitive strategies for achieving execution time efficiency. Anyone care to point me in the direction of a document on efficiency in Haskell? There really should be one! (Although there may be something on the wiki already.) Profiling can help, though. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] questions about core
On 2/12/07, Robert Dockins <[EMAIL PROTECTED]> wrote: At the risk of sounding self-promoting, I'd like to point out that the research paper I recently announced defines an intermediate language that is similar to GHC's core in some respects (they are both based on System F_omega). I give a full (call-by-name) operational semantics and type system for the language in my report [1]. You won't find any proofs in the paper, but they're on my medium-term agenda. There is also source code for an interpreter/ bytecode-compiler/shell for this intermediate language [2]. [1] http://www.cs.tufts.edu/tr/techreps/TR-2007-2 [2] http://www.eecs.tufts.edu/~rdocki01/masters.html I was also neglectful in not mentioning this paper: http://www.cse.unsw.edu.au/~chak/papers/SCPD07.html System F with Type Equality Coercions Martin Sulzmann, Manuel M. T. Chakravarty, Simon Peyton Jones, and Kevin Donnelly. In G. Necula, editor, Proceedings of The Third ACM SIGPLAN Workshop on Types in Language Design and Implementation, ACM Press, 2007. which describes System FC, which is the current incarnation of Core in GHC, and in fact that paper *does* give an operational semantics for it. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "It's important for us to explain to our nation that life is important. It's not only life of babies, but it's life of children living in, you know, the dark dungeons of the Internet." -- George W. Bush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions about core
On 2/12/07, Dougal Stanton <[EMAIL PROTECTED]> wrote: Quoth Joel Reymont, nevermore, > > Are these two different Simons? :-) > I'm beginning to wonder if Simon is less a name and more a title, meaning "strong in the lambda force" or somesuch. Let's hope they don't go over to the dark side ;-) I read that "Simon" means "one who listens to or obeys God." Tying this together with Stefan's post, maybe God is sort of like the unwritten denotational semantics for Haskell. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Would you be my clock if I promise not to hang you / Too close to the window or the picture of the pope? / I won't set you back and I won't push you forward / I just want to look in your face and see hope" -- Dom Leone ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] questions about core
On 2/11/07, Matt Roberts <[EMAIL PROTECTED]> wrote: - Exactly what are the operational and denotational semantics of core? Since I don't think this question has been answered yet, here's a mailing list post from Simon PJ that probably answers it: http://www.haskell.org/pipermail/glasgow-haskell-users/2003-February/004849.html That's from 2003, but I don't think the answer has changed since then. If you wrote down a precise operational and/or denotational semantics for Core, you'd probably have a research paper. (Especially if you proved that GHC actually obeys that semantics...) (Disclaimer: my name isn't Simon.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Very fast loops. Now!
On 2/10/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: To everyone's surprise, GHC 6.6 beats GCC (3.3.5) here, at least the two test machines: $ ghc -O -fexcess-precision -fbang-patterns -optc-O3 -optc-ffast-math -optc-mfpmath=sse -optc-msse2 A.hs -o a $ time ./a 3.33 ./a 0.96s user 0.01s system 99% cpu 0.969 total ^ Versus gcc 3.3.5: $ gcc -O3 -ffast-math -mfpmath=sse -msse2 -std=c99 t.c -o c_loop $ time ./c_loop 3.33 ./c_loop 1.01s user 0.01s system 97% cpu 1.046 total ^ There's no doubt that GHC is doing well here, but is that really a statistically significant difference? Certainly, it's great that GHC and GCC are doing at least about equally well, but I wouldn't conclude just from that data that GHC *beats* GCC. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Ninety-nine percent of everything that is done in the world, good and bad, is done to pay a mortgage. The world would be a much better place if everyone rented." -- Christopher Buckley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] still wrestling with io
On 2/8/07, Martin DeMello <[EMAIL PROTECTED]> wrote: Code here: http://zem.novylen.net/anagrid.html I've got an instance of IO appearing unexpectedly and I can't figure out where from. It throws up the following error: $ ghc --make test.hs Chasing modules from: test.hs Compiling Main ( test.hs, test.o ) test.hs:38:15: Couldn't match `StaticText ()' against `IO (StaticText ())' Expected type: StaticText () Inferred type: IO (StaticText ()) In the application `staticText p [text := (labelText a b)]' In the definition of `textOf': textOf p a b = staticText p [text := (labelText a b)] Hi, Martin-- I didn't know what staticText did, so I looked it up in the wxHaskell documentation (http://wxhaskell.sourceforge.net/doc/index.html, for anyone who might be following along at home.) As it turns out, staticText returns an IO action that returns a StaticText(), so that explains your error: the type signature you gave for textOf says that it returns something in the StaticText monad, but the body of textOf consists of a call to staticText, which returns something in the IO monad. So textOf also has to have an IO type for its return type. (Intuitively, that's because creating the GUI object that represents the label is a side-effecting operation, at least with the way wxHaskell is designed.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "make them believe, if not in magic, in money well spent" -- Annie Gallup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] External Core
On 2/6/07, Ricky Barefield <[EMAIL PROTECTED]> wrote: I've tried running Happy on these files but get the error `Not enough type arguments for the type synonym "P"' when I try to run the resultant Parser.hs in Hugs and similar errors when run in GHC. What I'm trying to achieve is to read the hcr files into a Haskell data type which I could work with, if anyone could give me any help with using the files for manipulating Core I would be very grateful. External Core isn't currently working correctly in the HEAD. Aaron Tomb was working on this, I know (as per mailing lists posts on cvs-ghc from November and December), but I don't know if he still is. glasgow-haskell-users is a better place to discuss this. Your best bet if you want to be able to use External Core may be to fix it yourself. I know that's what I had to do! But, people on glasgow-haskell-users and cvs-ghc will probably be happy to discuss it with you. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "I saw no reason then why hell should not have, so to speak, visible branch establishments throughout the earth, and I have visited quite a few of them since."--Robertson Davies ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OT: any haskell-friendly / functional programming friendly comp sci programs? (for a 30s guy who did his undergrad in liberal arts)
On 2/5/07, Paul Johnson <[EMAIL PROTECTED]> wrote: If you are already a hacker then "the right kinds of people" to start a company with may not be the ones you find in a Masters or Bachelor comp-sci course. Different people have different views on this, of course. Yeah, actually, I have to agree with that comment. Based on my own experiences at least, students in an undergrad CS program are likely to be looking for a cushy job where they'll get spoon-fed everything (unless you're at an excellent university, which has its own problems); students in a terminal master's CS program are going to be much the same. For the networking opportunities, you might be much better off hanging around on #haskell IRC for a while, and maybe even going to some conferences, and eventually, if you're *looking* for restless people who would want to get involved in a company that does FP stuff, you may find they'll stick to you like glue. But someone has to take the initiative. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Well-behaved women rarely make history." --Laurel Thatcher Ulrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How did you stumble on Haskell?
On 1/28/07, Alexy Khrabrov <[EMAIL PROTECTED]> wrote: How do people stumble on Haskell? I was thinking that my story wasn't particularly interesting, but then again, I may be the only person on this list who can actually give a properly-cited publication as an answer to the question "how did you learn Haskell?": Patricia Johann and Franklyn Turbak, Lumberjack Summer Camp: A Cross-Institutional Undergraduate Research Experience in Computer Science, Computer Science Education 11(4), Dec. 2001. - http://cs.wellesley.edu/~fturbak/pubs/cse01.pdf The shorter answer is, "I got paid to learn it," when I was an undergrad, and so I find those of you with real jobs and real lives who learn new languages in their copious free time with no particular extrinsic motivation for it to be particularly admirable. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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
Re: [Haskell-cafe] Re: Channel9 Interview: Software Composability and theFu ture of Languages
On 1/31/07, Bill Wood <[EMAIL PROTECTED]> wrote: On Wed, 2007-01-31 at 19:51 +1100, Donald Bruce Stewart wrote: . . . > foldl (\water dish -> wash water dish) soapywater dishes :: [Dishes] Nice example. First, note that you can't get close with map -- you need accumulation across the dishes. Second, the correctness of this plan depends on the rather strong frame axiom that no entity in the environment is changed during a step of the fold, so no broken dishes. Finally, that doesn't work so well when there are constraints on the order that the dishes are washed, for example when washing the cruddiest dishes first while there are more suds. It also assumes that there's necessarily a natural decomposition on the dishes, and if you think there is, you haven't seen my kitchen! -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Sleeping is a gateway drug / to being awake again" -- They Might Be Giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 1/28/07, Chris Kuklewicz <[EMAIL PROTECTED]> wrote: > I think many of the users of Haskell forget that there are a lot of > people out there who are not career academics working with pure > mathematics day-in and day-out. GHC seems to be developed by several people at Microsoft Research. They are not career academics. I am less familiar with the other compilers. There's no need for the "seems to be". The excellent "History of Haskell" paper: http://research.microsoft.com/~simonpj/papers/history-of-haskell/index.htm discusses the history of every extant Haskell compiler, in section 9. If I'm reading correctly, every one of these compilers (except possibly for jhc, it's not clear) began as an academic research project at a university -- that includes GHC, which was developed by academics at the University of Glasgow (hence the "G" in "GHC"), and it was only later that some of them moved to MSR. Be careful about conflating "academic" with "not practical". It's true that academics haven't always had time to explain the useful, practical techniques they discover in ways that are understandable by programmers who don't have formal mathematical backgrounds (and be careful about conflating "having a PhD" with "having mathematical background or experience", too). In the same way that programmers have jobs to do and thus have limited time to puzzle out new languages, academics have jobs that don't tend to reward them for spending time making those puzzles clearer to practitioners. As a challenge to everyone posting on this thread: rather than excoriating academia for its sins, why not start creating the documentation (or tutorials or libraries or applications) you wish to see? Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "No one's actually said 'O great America, thank you for saving us from the evil communist bug-eyed aliens, and, can we have fries with that?' yet have they?" -- Debra Boyask ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
On 1/26/07, Collin Winter <[EMAIL PROTECTED]> wrote: You have a PhD in computer science from Princeton, so your measure of what's "hard" and what isn't in this regard is nearly worthless. I find it incredibly insulting for you to assert that people who complain about Haskell's difficulty are too lazy and aren't really interested in a better solution. Maybe they just don't want to have to take graduate-level classes in category theory to get their job done. I've never taken a graduate-level class in category theory, or any course on category theory, and I'm a Haskell implementor. So perhaps the people who think they need to taken graduate-level classes in category theory in order to use Haskell are barking up the wrong tree (or perhaps I'm not a very good Haskell implementor, which is always possible.) Maybe they want a solution that meets them half-way, one that doesn't require that they understand how to build their own resistors and capacitors in order to make their TV work again (to use your analogy). That's what Meijer means when he says that Haskell is too hard. On the other hand, Meijer also has a PhD in computer science... is his judgment on Haskell's difficulty or lack thereof worthless, too? If not, then surely, judgments about whether Haskell is too hard can't have much to do with who has a PhD and who doesn't. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Would you be my clock if I promise not to hang you / Too close to the window or the picture of the pope? / I won't set you back and I won't push you forward / I just want to look in your face and see hope" -- Dom Leone ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] [Fwd: Re: Computer Language Shootout]
On 1/25/07, Neil Mitchell <[EMAIL PROTECTED]> wrote: We have the nofib suite, it could do with some attention, but it is (or was) a pretty good performance tester. Yes, I've spent enough time staring at nofib results that I understand just how random and un-representative the programs in nofib are. nofib consists of whatever people have submitted for nofib, and moreover, its contents are more or less the same now as they were in 2002. A lot has changed about the ways in which people use Haskell in those past four years -- in 2002, GHC was the only big Haskell application out there, and I don't think that's true anymore. So personally, I have zero faith in nofib results to tell me anything about how helpful optimizations will be except on a very large scale of granularity. The problem is that something like GHC is very complex, with lots of transformations. When transformations are firing other transformations, which in turn fire other transformations, it doesn't take a great deal to disrupt this flow of optimisation and end up with a result which doesn't accurately reflect the particular change you made. Better knowledge of the end effects on a program isn't necessarily going to translate to better knowledge of the optimisations effect. Sorry for being unclear. I agree with your comments on GHC, and one thing I was suggesting was that somebody should think about profiling tools for improving our understanding of how those transformations interact with each other, not just profiling tools for understanding the end result. Everyone says that optimization is a black art, but I remain to be convinced that understanding the interactions between different optimizations isn't a problem that would submit to appropriate amounts of effort. Maybe if we had a greater number and variety of optimising compilers we'd be able to more freely experiment with optimisation techniques in different settings. At the moment GHC is all there is (with Jhc not ready for mainstream use yet) I agree that there should be more diversity in compilers, but I think even sticking to GHC, there's a lot that could be done when it comes to improving understanding of just what the optimizer is doing. Anything better than staring at intermediate code would be an improvement, since time spent staring at intermediate code usually is time spent narrowing down the 2 lines out of 1000 that are relevant. Maybe it's possible to design tools that could help with that narrowing-down process. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "by God I *KNOW* what this network is for, and you can't have it."--Russ Allbery ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] [Fwd: Re: Computer Language Shootout]
On 1/25/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: The degradation is due to two things: * several entries have been disqualified (some fairly, some unfairly) Fix: fix is to submit more * the shootout haskellers stopped submitting once it was clear we'd need bytestrings to do signifcantly better. Fix: bytestring is now on the shootout machine, so we can resume I don't think there is any fundamental issue exposed, other than that we stopped updating entries, while other languages decided they should try harder. I have to disagree with this. That is, I don't object to Don's explanation of why the shootout entries degraded in this particular case, but I do think that Andrzej was right to point this out: "Perhaps making a collective effort towards benchmarking Haskell programs and analyzing the results in some methodic way could prove helpful?" and I think that he *is* pointing out a fundamental issue here. Maybe it's just me, but as someone who has some amount of experience with implementing optimizations for Haskell, I find it nearly impossible to precisely understand and measure exactly how those optimizations improve (or degrade) program performance. The tools we have just aren't adequate. And so, at least for me, implementing optimizations feels more like fumbling around in the dark than like using anything approaching the scientific method. This is, of course, because everybody has limited resources and implementing good profiling tools for implementors hasn't been a high priority. And Alexey Rodriguez's recent work on using hardware counters is a step in the right direction. But, I think the time is now to put more effort into profiling and benchmarks for Haskell. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "I wish people weren't so set on being themselves, when that means being a bastard." -- Robertson Davies ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] readFile problem
On 1/8/07, Stefan Aeschbacher <[EMAIL PROTECTED]> wrote: There are many things i do not understand. Why the different behaviour on Linux and Windows? Shouldn't an exception be thrown on Linux instead of a core dump? I don't use any unsafePerformIO or foreign calls. Why the changed path? I never change working directory in my code. Why is a function (-> reading the config file) re-evaluated at a later point in time? How can I debug such a problem? My environement is ghc 6.6 on Ubuntu or Windows XP. It may be difficult to say without seeing your code. Is it possible for you to post it, or at least a minimal test case that would illustrate the different errors on the different OSes? What Unix toolkit are you using when running ghc on Windows, if any (cygwin, mingw, both, neither?) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "What is research but a blind date with knowledge?" -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does the wiki search facility not work properly?
On 1/7/07, Paul Moore <[EMAIL PROTECTED]> wrote: On 07/01/07, Kirsten Chevalier <[EMAIL PROTECTED]> wrote: > I don't know, but I would suspect that the page isn't linked from > anywhere, and that's why it's not showing up in the search results. MediaWiki has a concept of namespaces - Talk:SantaClausProblem is in the "Talk" namespace - maybe that namespace isn't searched by default? The Haskell wiki doesn't run on MediaWiki, though, does it? In any case, if there *is* a checkbox for searching the Talk namespace (and I forget whether there is), then yes, be sure you have it checked. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "What is research but a blind date with knowledge?" -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does the wiki search facility not work properly?
I don't know, but I would suspect that the page isn't linked from anywhere, and that's why it's not showing up in the search results. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "What is research but a blind date with knowledge?" -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Literate Haskell source files. How do I turn them into something I can read?
[redirecting to the mailing list] On 12/31/06, Michael T. Richter <[EMAIL PROTECTED]> wrote: On Sat, 2006-30-12 at 23:48 -0800, Kirsten Chevalier wrote: > I'm probably not the right person to explain why David Roundy chose to > write his code the way he did, since I've never even met him. However, > since as of 12/8/2006 there were 115 contributors to darcs, perhaps > reading the source code isn't as difficult as you seem to think it is. What's the secret then? pdflatex vomits. unlit generates a few dozen pages of whitespace per five-line block of code. I'm at a loss to take this "literate" format and turn it into something which I can read. The secret lies in adjusting your perspective. The literate format is readable by humans as is. If there are specific things about it that you find difficult, you can post about them here with *specific* examples you find perplexing. But one reason why you may feel like people aren't being helpful is that your question isn't specific enough. > > I fail to see how making code which can't be read makes it more... > > readable. > "Can't" is an awfully strong word, isn't it? Nope. The source files as they are are gibberish. Again, that's an awfully strong statement. Clearly, there exist any number of people who can read them without finding them gibberish. Perhaps it might be better to listen to what they are telling you than to make contradictory declarations. There's some kind of markup (of a type I can't identify) mixed up with Haskell source. Given that I can't identify the markup and I'm a little hazy on Haskell at this point (part of the point of this exercise was to learn to read Haskell as it's used in real projects), the net effect is executable line noise. You know, like a perl program written circa 3.0. Right, if you're trying to learn to read Haskell as it's used in real projects, reading the .lhs files as they are is the way to go. Again, if you find specific things hard to comprehend, ask here, or on the IRC channel. A general "all Haskell looks like line noise!" complaint is hard for us to answer. > I can only explain how I did it myself, which was through practice. OK. How do you read the literate source code? Which tools do you use to separate the code from the commentary? Which tools actually work to turn .lhs files into something human-readable? (pdflatex failed on the GHC code as well.) My eyes. And brain. I'm sorry that I can't be more helpful, but that's what most other people I've watched reading Haskell code use, too. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Memo to myself: Do the dumb things I gotta do. Touch the puppet head." -- They Might Be Giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[8]: [Haskell-cafe] Strange type behavior in GHCi 6.4.2
On 12/31/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: this don't say anything place. and these rules have their own source: it's hard to optimize using your path. but when program optimization is just adding a few options/pragmas to the program, it' becomes cheap enough to change these rules. didn't you thought about it? In my experience, adding pragmas and toying with options without insight into what they do is not "cheap", because it takes up the programmer's time, and time is more important than anything else. Every minute spent typing in pragmas is a minute lost that could have been spent thinking about how to write your code more elegantly, and in my experience -- and again, maybe it's just that I'm slow -- adding pragmas doesn't help. When it comes to inlining and specializing, GHC tends to be smarter than I am. (Once more, maybe it's just that I'm slow.) I'd rather focus my energies on doing the things GHC can't (usually) do, like replacing an O(n^2) algorithm with an O(log n) algorithm. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Happy is all in your head / When you wake up and you're not dead / It's a sign of maturation / That you've lowered your expectations..."--Barbara Kessler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Strange type behavior in GHCi 6.4.2
On 12/30/06, Grady Lemoine <[EMAIL PROTECTED]> wrote: I tried compiling, but I got a linker error: /usr/lib/ghc-6.4.2/libHSrts.a(Main.o): In function `main': (.text+0x2): undefined reference to `__stginit_ZCMain' /usr/lib/ghc-6.4.2/libHSrts.a(Main.o): In function `main': (.text+0x16): undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status You need to either define a "main" function in your module (e.g., "main = putStrLn "Hello world!") or add -c to your compile flags. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "I wanna live for life and no other / cause I don't ever wanna be like my mother I wanna learn to walk on the water / cause I don't wanna be like my father" -- Noe Venable ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Literate Haskell source files. How do I turn them into something I can read?
On 12/29/06, Michael T. Richter <[EMAIL PROTECTED]> wrote: I'm trying to wrap my mind around the darcs source code as a preliminary to looking into GHC's guts. All of darcs is written as .lhs files which have bizarre mark-up in them which distracts me from the actual Haskell source I'm trying to figure out and get used to. Apparently the GHC compiler can take .lhs files, strip them with "unlit" (a utility which I finally found buried deep in the GHC installation -- off-path) and then compile them normally. The problem I have is that unlit leaves behind instead these huge gaping (and highly distracting) stretches of whitespace while it takes out the markup. Speaking of bizarre markup, I gently suggest using plaintext rather than HTML, and wrapping your lines, when you post to this list. In any case, I'm surprised that you find the Literate Haskell aspect of it to be the *most* bizarre thing about darcs's sources, but anyway, I really do suggest turning the code into PDFs as Cale suggested rather than trying to strip out the literate markup. Sometimes, documentation really does help one understand code, and the entire point of literate programming is to make code more readable. A little effort spent learning now could save you a whole lot of effort later. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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: Re[4]: [Haskell-cafe] Strange type behavior in GHCi 6.4.2
On 12/30/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: Hello Kirsten, Friday, December 29, 2006, 6:30:22 PM, you wrote: > I suggest *not* using these pragmas unless a combination of profiling > and reading intermediate code dumps suggests that foo -- and its > un-specialized nature -- is truly a bottleneck. it's a matter of taste - and experience. may be it's simpler to add a huge number of INLINE pragmas than to profile and especially read code dumps? I agree that profiling and reading code dumps can be daunting, but in my opinion, it's better to learn these skills once and for all (and unfortunately, these skills are still necessary given the current level of Haskell technology) and gain insight into how to use the compiler to get the code you want than to practice cargo-cult programming in the form of wanton pragmas. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Religion is just a fancy word for the Stockholm Syndrome." -- lj user="pure_agnostic" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Strange type behavior in GHCi 6.4.2
On 12/29/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
i propose you to use INLINE pragma:
{-# INLINE foo #-}
unless your function is recursive. in this case, you should use SPECIALIZE
pragma:
{-# SPECIALIZE foo :: Double -> Double -> Double #-}
I suggest *not* using these pragmas unless a combination of profiling
and reading intermediate code dumps suggests that foo -- and its
un-specialized nature -- is truly a bottleneck. Excessive amounts of
SPECIALIZE pragmas can make your code ugly without actually improving
performance if you optimize prematurely (and I speak from experience).
Think *first*, add pragmas later; again, people on the mailing lists
and IRC channel are usually happy to provide guidance with this.
Cheers,
Kirsten
--
Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt
"To be free is not to have the power to do anything you like; it is to be able
to surpass the given towards an open future..."--Simone de Beauvoir
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange type behavior in GHCi 6.4.2
On 12/28/06, Grady Lemoine <[EMAIL PROTECTED]> wrote: One question I have, though, for anyone on the list who knows the answer -- if I give a function a polymorphic type signature, can it affect performance? That is, if I write two functions with the same definitions but different user-specified type signatures, foo1 :: (Floating a) => a -> a foo1 = ... and foo2 :: Double -> Double foo2 = ... when I apply foo1 to a Double, will the compiler (GHC, specifically) generate code that is just as efficient as if I used foo2? As with so many things, the answer is "it depends". The simple answer to "if I give a function a polymorphic type signature, can it affect performance?" is "no, because type information is erased before code generation". However, if by "polymorphic type signatures" you mean ones involving class-based overloading, like the ones you wrote, then the answer is "maybe" -- functions that have classes involved in their types are desugared by the compiler into functions that take extra "dictionary" arguments, which can make performance worse. GHC does "specialization" to try to negate some of the performance impact of this, but it doesn't always do what you want it to. The best thing to do is to make sure you compile your code with -O2 and if profiling seems to imply that overloaded functions are causing you bottlenecks, seek help on this list or on Haskell IRC (and there should be a pretty good body of previous discussion on the subject in the list archives). Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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: [Haskell-cafe] Is there a printable copy of the (GHC) library references anywhere?
On 12/27/06, Paul Moore <[EMAIL PROTECTED]> wrote: I'd like to print out a copy of the GHC manuals, for reference. I've got the Haskell 98 report, and the GHC user guide, but the only documentation I've found for the hierarchical libraries is in HTML format (generated from Haddock). Is there a printable (preferably PDF) form of the library documentation? Either all of it, or alternatively reasonably large subsets? There may be an easier way, but if nothing else, you could download the HTML.tar.gz file for the library docs and then use latex2html to generate TeX to generate a PDF. (Personally I wouldn't find it at all useful to have a printed copy of the library docs, even though I do like printed manuals, because I only ever consult them to look up a specific function or type, which is a lot easier to do in the hypertext version -- but YMMV.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "All we can ever do is lay a word in the hands of those who have put one in ours." -- Richard Powers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Followup on writing "Haskell for Dummies..."
I think I've decided that this isn't the right time for me to take the lead on this book-writing project, and in addition, I've come to think that maybe the things *I'd* like to say about Haskell hacking can't be transmitted so easily in book form. However, if any others would like to organize the writing of one (or several) books based on any of the ideas brought up in the mailing list discussion, they should feel free to step forward and do so, and know that they won't be duplicating work (or at least not my work). Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "You can't learn everything you need to know legally."--John Irving ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/13/06, Justin Bailey <[EMAIL PROTECTED]> wrote: On 12/12/06, Joachim Durchholz <[EMAIL PROTECTED]> wrote: > Agreed. > Something along the lines of "The Art of Functional Programming". +1 . I would love to read something that is the equivalent of 'design patterns', but for functional languages. I thought Osasaki's book "Purely Functional Data Structures" would have that, but it was little too focused on proving properties of algorithms. As someone in industry, that wasn't so important to me. I want to learn how to "think" functionally. Check out this paper by Jeremy Gibbons, "Design Patterns as Higher-Order Datatype-Generic Programs": http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/index.html#hodgp If you want to learn how to "think" functionally, forget you ever heard the words "design pattern". There shouldn't be patterns in your programs. If there are, that means that either your language isn't providing you with enough abstractions or that you aren't using the abstractions that are available (or possibly both). Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Anyone who spends their life on a computer is pretty unusual." -- Bill Gates ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a hacker? [was: Mozart versus Beethoven]
On 12/14/06, Benjamin Franksen <[EMAIL PROTECTED]> wrote: Kirsten Chevalier wrote: > (Since, of course, > one should never apply the term "hacker" to oneself.) Who told you that? The Jargon File. But yes, I can anticipate more or less all of the possible responses to *that*, and, point taken. Calling oneself 'hacker' is a sign of healthy self-respect; to the contrary, I don't know anyone who would call themselves wannabe-hacker. Well, I hope so, since I contradict my own advice and call myself a hacker anyway :-) Being a hacker is a matter of attitude and self-definition more than knowledge and experience. A hacker, even if young and lacking experience, reads books for hackers (if at all) not 'how do I become a hacker' books. The attitude is 'gimme the knowledge so i can go ahead and start doing real stuff', not 'oh, there is so much to learn, maybe after 10 years of study and hard work people will finally call me a hacker'. Very reasonable. Very sane. Speaking of the term "hacker" and of various subcultures, the way in which Haskell and the open-source community seem to have met each other this year just makes me melt with joy. I know it wasn't like that six years ago; the Haskell community was small, and there wasn't exactly such a thing as the "open-source community" (and please let's not have a "free software" vs. "open source" debate, because I've heard that all before, too). I don't know exactly what happened in the meantime, besides the miracle of this vast series of tubes that we cann the Internet, but someone should really be writing a sociology paper about it. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Aim Of Haskell
On 12/13/06, Claus Reinke <[EMAIL PROTECTED]> wrote: > The reason why Haskell is academic-centric is that it was originally > conceived by academics, and they were interested in doing research > into language design and implementation .. shouldn't we make this "used to be academic-centric"? I think that's still slightly premature, although it seems like a ton of progress has been made just this year. > People outside academia who might be inclined to take on some of > those more practical questions are just beginning to notice that Haskell > could be useful for them too. .. although "just beginning to notice" may be accurate on a historical scale, I have the feeling that the actual development is further along than this. at least, there have been sufficiently many and active early adopters for long enough to make a substantial difference. so those practical questions are not being raised, but several of them are actually being addressed. Certainly, and not to in any way denigrate the early adopters' work (and I am, I guess, an early adopter, though not one who's actually contributed much). I guess I was just trying to say to the poster I was replying to that if you're still not happy with the level of practicality of Haskell tools now, either jump in and help improve them yourself, or if you don't want to do that, have a little patience -- they'll get there soon enough. one of the most exciting aspects of Haskell is that pragmatic interest in the language has been growing steadily without academic interest in it declining in any way. as a result, we have a language that represents an interesting mixture of good and useful, although it is not entirely clear yet how long this nice balance will hold. we have had lots of languages that were intended to be well-designed (good, beautiful, ..), but never much used in practice, and we have also had lots of languages that were intended to be pragmatic (practical, useful, ..), without much interest in theoretical beauty. but how many languages are there where the two aspects have converged, with both communities still actively interested in the result? I'm interested to see what's going to happen, too. To answer your question with another, how many languages are there that have quite the same kind of people committed to them that Haskell does? :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Happy is all in your head / When you wake up and you're not dead / It's a sign of maturation / That you've lowered your expectations..."--Barbara Kessler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing "Haskell For Dummies ...)
On 12/13/06, minh thu <[EMAIL PROTECTED]> wrote: Another difference with music that strikes me is the level of abstraction : a note is a note. A line of code (especially in a imperative setting) is much more than a line of code. Ok, one can argue that notes interact together but, imo, not in the same way line of code can do. Programming is complex, you have to layer code on codeon code. Music is quite 'direct', you hear it without thinking. I'm not sure that's right, though. Just as a line of code seems to be simple but what's going on at the hardware level is very complex, a musical note is simple but what goes in inside your brain when you hear one is extremely complex, poorly understood, and the details of it aren't accessible to you consciously. You say "you hear it without thinking" -- exactly, you feel like you're "not thinking" because of all of the amazingly complicated things that are going on inside. No program is nearly that complex! I suppose I must be channeling Hofstadter. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "One of these days and it won't be long / Going down in the valley and sing my song Gonna sing it loud, sing it strong / Let the echo decide if I was right or wrong" -- Bob Dylan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On 12/13/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: Hello Joachim, Wednesday, December 13, 2006, 2:17:08 AM, you wrote: > Actually, it's quite simple: following the ideology de jour and > teaching-relevant support. are you remember title of Wirth's book? "algorithms + data structures = programs". i think that Haskell is ideal language for teaching programming now (like Pascal was in 80's), because it teaches how to develop algorithms instead of focusing on implementation details. of course, you are right that fashion and availability drives actual teachers selection That's a good point too. Actually, though, my original comment about understanding the reasons for programming language adoption was not just meant to refer to adoption in an educational context, but also to the reasons why people adopt the languages they do for commercial (or research or free software) projects, as well; so, I don't think it's quite *that* simple, although I should have been more clear. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Aim Of Haskell
On 12/13/06, Kaveh Shahbazian <[EMAIL PROTECTED]> wrote: I think this is going out of the way. Excuse me, but the main discussion was not about pascal! This list is exactly for off-topic discussions :-) And thanks again to all. Now I think there is a bigger whole between current situation of Haskell and using It as a real tool, than what I thought before. But any way; I still have a hope for rising a new folk of thinkers in software world that will put ideas to work more practically. Haskell got academic-centric-being syndrome, as JAVA got perfectionism syndrome (see elegant and useless design patterns and architectures there!). I can not imagine a pure and clear vision about this new folk that IT world lakes now. If anyone helps me with clarification of this thing, It will be great to me! The reason why Haskell is academic-centric is that it was originally conceived by academics, and they were interested in doing research into language design and implementation and also had jobs to take care of and all of this doesn't leave much time for being a language evangelist or for figuring out what the practical issues might be (not to mention sleeping at night). People outside academia who might be inclined to take on some of those more practical questions are just beginning to notice that Haskell could be useful for them too. The reason this didn't happen earlier was that there was no marketing budget. It had to happen in a grassroots fashion, and IMO it couldn't have happened until after the rise of distributed open-source development (which, I remind you, didn't start gaining a lot of momentum until not that long ago). You could become one of those "new folk of thinkers". Be the change you wish to see. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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: a cabal/database lib experience (was: [Haskell-cafe]Trivialdatabase access in Haskell)
[trimmed replies] On 12/12/06, Paul Moore <[EMAIL PROTECTED]> wrote: On 12/12/06, Claus Reinke <[EMAIL PROTECTED]> wrote: > the difference, as far as it is relevant for getting going, is often just > context, which can be rectified by surprisingly small steps, such as > collecting the assumptions in one obvious-to-find file. Indeed. I can now confirm that it's *not* hard to get takusen set up - it's just a bit hard to find out it's not hard :-) If you generalize from "takusen" there, I think you'll understand a lot about Haskell :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Aim Of Haskell
On 12/12/06, Andreas Rossberg <[EMAIL PROTECTED]> wrote: Claus Reinke wrote: > > but on the Pascal note: is there anything in Pascal that Haskell doesn't > provide, and improves on (nested procedures, procedure parameters, > distinguishing in and out parameters, types, ..)? Subrange types, maybe? But I'm sure Oleg will show us that Haskell already has them. :-) Maybe the real question should be: is there anything in Pascal that Haskell's type system doesn't provide? Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Other than to amuse himself, why should a man pretend to know where he's going or to understand what he sees?" -- William Least Heat Moon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On 12/12/06, Brian Hulley <[EMAIL PROTECTED]> wrote: Kirsten Chevalier wrote: > since it's not as if anyone programs in Pascal anymore. Yet I'm sure most people who did a computer science degree some decades ago remember the old joke about passing things by name or value for what it's Wirth... :-) I was kidding slightly. My first programming language was Pascal, but I guess I should be grateful that I didn't take the same course a year later, because then my first language would have been Java. In fact, a comment from Lyn Turbak, who taught the second-semester computer science class I took at Wellesley, is in some sense or another half of the reason why I'm participating in this discussion today -- a student (not me) asked him, "why are we learning Pascal if you hate the language so much?" and he explained, "Historical accident..." and talked about the reasons why Pascal ended up being a popular teaching language. Much later, I'm amazed at how few students ask this kind of question and how few teachers talk about the answers to them. I think this relates back to the point of the original discussion. People (except people on this mailing list, and a few similar fora) don't talk much about the reasons for choosing programming languages. When they do talk about it, it's usually very prescriptively oriented rather than descriptively oriented. I think that it would serve this community well if somebody was able to achieve a better understanding of the social reasons why some programming languages are adopted and some aren't. I think all of us already know that the reason isn't "because some are better than others," but it might be time for someone to go beyond that. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "THEY CAN KILL YOU, BUT THE LEGALITIES OF EATING YOU ARE QUITE A BIT DICIER" --David Foster Wallace ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On 12/12/06, Arie Peterson <[EMAIL PROTECTED]> wrote: > Haskell is just too similar to Pascal. This makes me wonder how people pronounce "Pascal". It's probably because I'm from Europe, but I put the stress on the second syllable. Pronouncing it like "rascal" is, well, funny :-). For whatever it's worth, I'm American and have mainly heard Americans pronounce it with the stress on the second syllable -- however, when I mention programming in Haskell to other Americans, I get the "oh, you mean Pascal?" response sometimes too, even though I pronounce "Haskell" with the stress on the first syllable. I'm not sure why, since it's not as if anyone programs in Pascal anymore. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Never wear shorts with the name of your town across the ass if you live in Needham." -- Beth Murphy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Andy Georges <[EMAIL PROTECTED]> wrote: Hi, > Actually, the more I think of it, the more I think we should rename > the language altogether. It seems like people say "Haskell" with > stress on the first syllable if they were either on the committee or > learned it inside academia, and "Haskell" with stress on the second > syllable if they learned it from online sources. And we really don't > need more pronunciation-based class distinctions. If you'd all speak West-Flemish, the problem would solve itself :-) Didn't this discussion originally start out as a warning not to say "If you'd all speak [or program in] _____, the problem would solve itself"? :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Aim Of Haskell
On 12/12/06, Brian Hulley <[EMAIL PROTECTED]> wrote: Neil Mitchell wrote: > Maybe we > should try and hijack the phrase functional programming - Haskell is > just too similar to Pascal. This reminds me of when I was getting an X-ray a few months ago and I struck up a conversation with the radiologist who turned out to be an ex-computer programmer so he asked what language I was using so I said "Haskell" and he said something like "Oh yeah Pascal I know that..." Perhaps we need a tutorial on how to pronounce the word "Haskell" so that it doesn't sound like "Pascal" :-) (eg "Hiskll") Actually, the more I think of it, the more I think we should rename the language altogether. It seems like people say "Haskell" with stress on the first syllable if they were either on the committee or learned it inside academia, and "Haskell" with stress on the second syllable if they learned it from online sources. And we really don't need more pronunciation-based class distinctions. "Curry" would have avoided this problem. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "It was cold in the house so I slept in my car / And I steamed up the windows, then it started to rain / And I dreamed about sex and I dreamed about peppers / Woke up doing 85 in the passing lane" -- Ed's Redeeming Qualities ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: -- Don "If it ain't pure, it ain't functional" Stewart Oh, so you're saying that we should trademark the phrase "functional programming" so that no language with uncontrolled side effects would be allowed to use it? -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Aim Of Haskell
On 12/12/06, Tomasz Zielonka <[EMAIL PROTECTED]> wrote: On Tue, Dec 12, 2006 at 10:58:18AM +, Kirsten Chevalier wrote: > Functional programming people have a reputation for arrogance -- > whether that impression is fair or not and whether that arrogance is > merited or not, the impression exists, and some people find it a > turn-off. Aren't you talking about the LISP community? ;-) That's exactly the problem! For most people there *is* no difference. You say "functional programming" to most people, even professional programmers, and usually the only chance you have of getting them to understand what what you mean is by asking "so, have you heard of Lisp, or Scheme?" Avoiding the question of whether the Lisp community deserves that reputation, *we* need to be sure to avoid acquiring the same. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Mozart versus Beethoven (was: Writing "Haskell For Dummies ...)
On 12/12/06, Patrick Mulder <[EMAIL PROTECTED]> wrote: Not sure whether this is the right place to discuss computers and programming in general: You're implying that there's a *more* appropriate forum somewhere for discussing analogies between music composition and programming languages? If so, I'd like to know what it is! But Dijkstra's metaphor is suggesting, that while Beethoven learned by experiment and debugging compositions, Mozart did not have a need for reflection while writing down music ? I've been thinking about this. Are there really any programmers who are like Mozart in the way you describe? Donald Knuth might be one, or at least, he wrote that he wrote and debugged all of TeX on paper before entering it into a computer and "only found 13 more bugs" (or something like that), once he did. I don't remember if it was 13 exactly, but "13 more bugs" might be the closest that any programmer gets to Mozart, or at least any programmer in the 20th or early 21st century. But, can you imagine waking up in the middle of the night, sitting down, and writing a compiler from start to finish? Well, of course, easily, undergrads do it all the time during finals period. But, one that works, and that contains original ideas? I know some awesome programmers, but I don't think any of them are quite that awesome. Whereas it's conceivable to imagine somebody writing a piece of music that way, or a poem. Does that just mean that computer science has a long way to go in maturation? Or does it mean something else? PS I like the idea of a book "Hakell for Hackers" Maybe "Haskell for People Who Want to Be Hackers"? (Since, of course, one should never apply the term "hacker" to oneself.) I'm not sure whether it's best to aim at people who might be already hackers who want to learn Haskell, or people who are already programmers who want to be Haskell hackers, in particular. I suppose that the first group of people is probably larger. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "What is research but a blind date with knowledge?" -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Kaveh Shahbazian <[EMAIL PROTECTED]> wrote: So you still want to pay your developers for checking "NULL" values, correctness of "INTERFACES", writing "IF ELSE" and "SELECT CASE"s full of side effect and junks (Something that can be simply implemented by "Pattern Matching"), continuing OO world that has not even a accurate calculus for describing things (and came from industrial engineering), code that may crash through exceptions and very stupid-complex execution paths, checking array out-of rang things, handling and passing and dereferencing pointers correctly...H! Just calculate that how % of developer's time is being consumed by this stupid tasks? You know; this will be a big-bang for commercials! (If their stupid consultants can understand). Yes. It's always hard to convince people that they've been doing something the wrong way, though. "People" includes smart academic types, sometimes, too. I think you're absolutely right, but if you have ideas for what to say in those commercials, you can post them here :-) And of course it's not quite as simple as "people have been doing it the wrong way", because sometimes there are reasons even for the kinds of code that look the most horrible on the surface. Functional programming people have a reputation for arrogance -- whether that impression is fair or not and whether that arrogance is merited or not, the impression exists, and some people find it a turn-off. Avoid being the overenthusiastic convert. I am a usual developer, not smart and academic as you, and not as stupid ones to pretend to know something better than all. Even this kind of programming still is very hard for me. I am still struggling with monads and monad transformers! So I am choosing the hard path - even very hard one. Why? Because I am sure every mean developer like me can be productive in functional programming in 6 to 12 months. And imagine that huge bunch of stupid things that we are handling everyday : Just wast of life and money without any joy and honor. This is my vision : FIVE YEARS ... I hope so! And I think if you got to know at least *some* of the smart and academic types, you would find that they struggle sometimes too. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "What is research but a blind date with knowledge?" -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trivial database access in Haskell
Now you're getting somewhere! (Even though it may not seem like it.) At this point, this is probably a better place to ask: http://www.haskell.org/cabal/ In particular, it says where to ask questions. I haven't used Cabal much myself and I suspect that the people who know about Cabal are more likely to notice your question if you ask somewhere other than on this list, which is noisy. Good luck. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "I'm sick of my genitalia being used as an insult. Are you?" -- Bitch and Animal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: G'day all. Quoting Kirsten Chevalier <[EMAIL PROTECTED]>: > I suppose I should have clarified that I meant a dead-trees book with > a real publisher, [...] Something more like this, then: http://phptr.com/perens Maybe we should come up with an outline and a sample chapter or two, then talk to Bruce? That looks interesting. I'm not sure we fit in, but then, I'm not sure whether this idea fits in, as such, anywhere. I think there are a few things to figure out before we get to the point of writing an outline, but it's a reasonable thing to write in any case. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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] Trivial database access in Haskell
On 12/11/06, Paul Moore <[EMAIL PROTECTED]> wrote: The point I was trying (badly!) to make was that without sample code on how to do "trivial" queries, I can't work out which library is closest to what I want. And without installation instructions, I can't try them out. Well, if anyone has that sample code, someone who is reading this mailing list probably does. But if you can't find even simple sample code, that's probably a sign that not a lot of people have tried to write large database applications in Haskell using the existing libraries, or at all. I may be wrong, but I suspect that that's true. Somebody has to be first. So this is your cue to RTFS. And I'm trying to say "RTFS" in the nicest possible way in which I can say it. With an "F" that stands for "friendly" although I suspect that the code is going to look to you like anything but. This is my first real experience with trying to obtain and use a 3rd party library with Haskell, so I apologise if these are newbie-level dumb issues. I'm not trying to complain, but I do suspect there is an issue here with easy library availability that the Haskell community could look at. Python was in a similar situation for a long time, and I suspect it's just a bit further down the track. Certainly from what I've seen of Cabal, it's similar in philosophy to Python's distutils. But this is going off on a tangent - maybe I'll revisit it when I've got some more experience under my belt with installing DB libraries :-) Don't apologize; you're not being dumb. But, you have to realize that if you're using Haskell at all, you *are* the Haskell community. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "...I thought the secret of life was obvious: be here now, love as if your whole life depended on it, find your life's work, and try to get hold of a giant panda." -- Anne Lamott ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
I think this might be a good time to step back and make some general comments of my own. I learned Haskell in the summer of 2000. I see that that's exactly when SOE was published. I didn't have a copy. (I did acquire a copy of SOE about two years later, when I didn't need it anymore :-) I did have another book whose name I won't mention that I didn't find entirely helpful (I won't mention its name since I don't remember entirely for sure which book it was). I remember sitting in a windowless office trying to figure out why I couldn't seem to find any function that had the type IO a -> a. I'm thinking about that now because I hope to be able to not forget what it was like to be in that frame of mind. I'm sure SOE answers that question early on. But newbies on #haskell still ask it pretty often anyway. Obviously, there will always be people who don't know how to pick up a book, but on the other hand, I don't think that the problem of how to explain Haskell to beginners is solved yet. So the book that I want to write, hopefully with help from a few other people (maybe some of the people who've been contributing to the discussion so far, maybe others) would be aimed at a beginner (not a beginning programmer, but someone who's starting *perhaps* because they want to contribute to an open-source project that's written in Haskell, because there are such projects now that aren't Haskell compilers) who wants to get to the point where they can get real work done. And I'm not thinking of it as a textbook. Maybe this is way too ambitious. But I know that I managed to get from wondering where the IO a -> a function was to writing my own monad transformers, mostly by fumbling around in the dark, and I can't help thinking that there might be a possible book that would -- if not make it that much *easier* for somebody else to do the same -- at least allow *more* people to do the same. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "and the things I'm working on are invisible to everyone"--Meg Hutchinson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trivial database access in Haskell
On 12/11/06, Paul Moore <[EMAIL PROTECTED]> wrote: I've looked at the various database access libraries for Haskell, but they all seem to be missing a couple of key pieces if I want to use them: 1. Simple documentation of how to install the library (starting from a vanilla GHC installation on Windows, plus Oracle software, to the point where I can use the library in my code). All I need is Oracle access, so other database client libraries can be ignored. I'd rather not use ODBC, but will if required. 2. Simple examples on how to actually run a query. For example, how do I code the follwing SQL*Plus code (should be pretty self-explanatory) in Haskell: connect scott/[EMAIL PROTECTED] select * from emp; (Connect to the database "mydb" as user "scott", password "tiger", and issue the query "select * from emp"). Ideally, I'd like the Haskell code to not be *too* much more verbose than this (although I can accept that Haskell, beng a general language, won't be able to be quite as concise as a special tool can manage). Without this basis, I don't really have a way to evaluate the various libraries available... This is when you write that documentation :-) And I say that without knowing anything about any of the Haskell database libraries -- I just suspect that if you can't find any good documentation for them, that's your cue to write it. This might not seem like a helpful answer, but often it's the best answer anyone can give. I realize that you only have so many hours in the day, but only a few people get paid to work on Haskell full-time. So if you really wanted to find out whether the existing libraries would work for your purposes, try it, and write up what you found so that other people can benefit from it. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "We used to say that our love was like hemp rope / Three times as strong as the rope that you buy domestically." -- Dar Williams ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, Andrew Wagner <[EMAIL PROTECTED]> wrote: Ok, well I think we can all agree that such a book is a good idea. I suggest we take the discussion to some kind of collaboration tool. It's pretty hard to do just on this mailing list. There are a lot of options, such as finding a forum somewhere, creating a wiki book somewhere and having a mailing list too, using google's collaborative authoring tool, or whatever. Suggestions? Yes, I think it's quite clear now that there's enough interest in this, and we shouldn't get distracted by the licensing equivalent of bikeshed-coloring. I should have enough web hosting space to set up a wiki and a mailing list for discussion, so I'll go ahead and do that sometime over the next couple of days, and follow up here. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, Andrew Wagner <[EMAIL PROTECTED]> wrote: Well, I'm not opposed at all to a written final form. I guess I just don't see that and using a wikibook to assist in our collaboration as mutually exclusive. I think the confusion is my fault. I assumed that you (if it was you who originally used the word "wikibook"... it's been a long day) meant wikibook as in the Wikimedia Foundation Wikibooks site, but it seems you meant it as a generic term instead. Sorry. Anyway, I'd love to help in any such project. By the way, I seem to be messing up the threads. What is considered the "correct" way to reply to a particular thread? I've been copying and pasting the subject line and writing to [EMAIL PROTECTED] I think if you're going to do that, you also need to copy the cross-reference headers, and I don't know if Gmail lets you do that. (I gave up on trying to make that work, and got out of digest mode :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one." -- Paul Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, Matt Revelle <[EMAIL PROTECTED]> wrote: What do you mean by "real publisher"? As long as the quality of the final product is good, does it really matter what publishing company has their name stamped on it? It matters to me; if I'm going to put work into this, then that's what I want the result to be. I'm happy, of course, for projects that I am not involved in to use whatever publishing mechanisms that the people involved in those projects prefer. If you want to help with the writing project that I have in mind, then discuss that on the list. If you want to start another writing project whose primary goal is to produce an open-content, electronic book, then announce that on the list too. If you want to debate the merits of open-content versus traditional publishing, well, I'd love to have that debate too, but this list probably isn't the right forum for that. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "There are many places in computer science where it's actually helpful to procrastinate." -- Eric Brewer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, Andrew Wagner <[EMAIL PROTECTED]> wrote: Well, perhaps if nothing else, we could use a wikibook to collaboratively work on the structure of such a book, and then from that you could publish a "real" book. I don't really know the legal issues, though. I am thinking of several books though which have been written and released both as full paper books, and as free digital books. Could we do something similar? I definitely think using a wiki to work on the book would be a good idea. I just wouldn't want to imply that that meant it would necessarily be a public wiki or that it would be around forever. The legal issues are basically that publishers don't want to publish books that people can get for free off the web (whether or not you agree with this logic). There are exceptions to this, like Lessig's _Free Culture_, but it's my impression that they usually involve authors who have enough sway that publishers will let them get away with whatever they want. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Who needs reasons when you've got the root password?"[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, Matt Revelle <[EMAIL PROTECTED]> wrote: A quick search turned up Lulu (http://www.lulu.com/). >From the Lulu site: "Publish and sell easily within minutes. No set-up fees. No minimum order. Keep control of the rights. Set your own price. Each product is printed as it is ordered. No excess inventory." Looks like they offer hardcover and paperback and are fine with "open-source" books. I suppose I should have clarified that I meant a dead-trees book with a real publisher, but again, if other people want to organize something different based on this thread, they should go ahead! I can only do so much :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "...There is no mystery; there is only paradox, the incontrovertible union of contradictory truths." -- Edward Abbey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, Andrew Wagner <[EMAIL PROTECTED]> wrote: I think there are some great ideas here, and it would be a fantastic project to do as a community, via a wikibook. I, for one, have been studying haskell for several months, and am just starting to see a little bit of light when it comes to monads. I think it would be beneficial to work through a non-trivial construction of a new monad, and the larger examples given would be good opportunities to do that. If you (or anyone else who's been participating in the discussion, or anyone else) would like to do a wikibook, that would be great. Personally, I'd like to write / be involved in organizing the writing of a dead-trees book. (In theory, it could be both, but it seems to me like short of being Larry Lessig, there's not really a way to get a publisher to publish something that's already released under a free documentation license -- but correct me if I'm wrong.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "There's no money in poetry, but there's no poetry in money, either." --Robert Graves ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
On 12/11/06, Patrick Mulder <[EMAIL PROTECTED]> wrote: In my opinion it would be important to increase the understanding about "semantics" and "processes". And it would be good to introduce the concepts in a similar way as Profokiev introduces the sound of classical music in "Peter and the Wolf". If my suspicion is correct, functional programming would be very close to composing classical music (or concurrent algorithms and processes). Has anyone of you similar thoughts on music and programming ? What are the basic ingredients for making abstractions (like in music rythm, keys, tempo, ...) ? It would be useful to express different ways of expression by explaining first "semantics" of processes and abstractions. I love the analogy, though it's been at least eleven years since I tried to compose any music. (Coincidentally, eleven years ago was when I learned to program...) I've often thought that reading code (if it's well-written code) is a little like reading a poem, which of course is also a little like listening to classical music. There's certainly a sense of rhythm involved in how you choose variable names: that's why nobody likes variable names like theHashTableThatStoresMappingsBetweenNamesAndEmails. I'm not sure what the analogy with keys would be. Maybe writing in a point-free versus a pointed style is sort of like transposing a melody into another key. For the potential book, I definitely think a Peter-and-the-Wolf-like idea is good. (The wolf would be unsafePerformIO, obviously.) Probably any metaphors that assume any knowledge of music should be left for a different piece of writing that assumes a different audience, but pursuing it would be fun. I've been thinking a lot lately about how to present computer science (and programming languages) to a popular audience, too. I don't remember who originally posed the question of "who's going to be the Carl Sagan of computer science?", but it's a question somebody should try to answer. (The answer isn't "Douglas Hofstadter", because obviously somebody needs to be out there explaining why languages with static type systems are cool, too.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *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
[Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"
It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. I'm willing to take the lead in at least thinking about what such a book might look like. I'm potentially about to have some free time for such things, and am still young and foolish enough to think that writing a book would be a good idea. Of course, there are many good Haskell books out there already, but many of them are intended as class textbooks or are aimed at more theoretical-minded people. There's nothing wrong with that, but I think that it would be nice if a friendly, conversational, informal book about Haskell existed, since after all this is such a friendly and informal community. (If there already is a book like this, point it out, but I get the impression there's not.) There's also excellent Haskell documentation available on the web already, but people like to buy books and they like to have an artifact that they can hold in their hands without getting laser printer toner all over themselves. But if I were going to do this, I'd need all the help I could get, so if you're interested in working with me on this, email me off-list and we'll talk. Don't feel like you need to be named "Simon" for this; I don't think you need to be a Haskell guru to contribute to a book like this (I know I'm not one), though it wouldn't hurt. Being interested in good writing and explaining things to a wider audience is more important. And, the more people who are interested in working on this, the more we can all pool our various talents to create something awesome. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "Everyone's too stupid." -- _Ghost World_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 40, Issue 27
On 12/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Message: 2 Date: Mon, 11 Dec 2006 08:18:44 +0100 From: Andy Georges <[EMAIL PROTECTED]> Subject: Re: [Haskell-cafe] Aim Of Haskell To: Haskell-cafe Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, > one particular thing that we still lack is something like book > "Haskell in > real world" We need a 'Dive into Haskell' book. "Head First Haskell"? Or perhaps it should be "unsafeHead First Haskell". Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt "The miracle of life is that, despite the best grip we can get on reality, it continuously manages to surprise us. The beauty of science is that, notwithstanding all our tacit assumptions, these surprises can get through." --Evelyn Fox Keller ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 38, Issue 22
On 10/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Meanwhile, if you want to use External Core, but can't because it doesn't work properly for you, don't be afraid to yell. (E.g. File a Trac bug report.) I don't want to promise an immediate fix, but the more people that use it the keener we are to get it done. I did file a bug on this nine months ago: http://hackage.haskell.org/trac/ghc/ticket/670 but haven't had a chance to work on it. Cheers, Kirsten -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt "That's the thing about people who think they hate computers. What they really hate is lousy programmers."-- Larry Niven and Jerry Pournelle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
