Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Wed, Oct 6, 2010 at 8:14 PM, Brent Yorgey byor...@seas.upenn.edu wrote: One (slightly off-topic) question: at the top of the site it says the meeting place for professional Haskell programmers. Is this supposed to be geared towards Haskell programmers who get paid (or want to get paid) to write Haskell? If so, fine; if not, in my opinion the word professional ought to be dropped. The fact is that the site has two functions: on the one hand, it's simply a social network for anyone connected to the Haskell world. In that sense, the word professional is inaccurate. However, the second function is to encourage Haskell usage in industry, by showing a large number of highly qualified Haskell programmers. In this sense, the word professional is very apt. I hope the word professional isn't scaring off the hobbyists; I would definitely want them to be signing up on the site as well. But as far as the marketing of the site goes, I think our main goal should be impressing industry. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
2010/10/7 Michael Snoyman mich...@snoyman.com: On Wed, Oct 6, 2010 at 8:14 PM, Brent Yorgey byor...@seas.upenn.edu wrote: One (slightly off-topic) question: at the top of the site it says the meeting place for professional Haskell programmers. Is this supposed to be geared towards Haskell programmers who get paid (or want to get paid) to write Haskell? If so, fine; if not, in my opinion the word professional ought to be dropped. The fact is that the site has two functions: on the one hand, it's simply a social network for anyone connected to the Haskell world. In that sense, the word professional is inaccurate. However, the second function is to encourage Haskell usage in industry, by showing a large number of highly qualified Haskell programmers. In this sense, the word professional is very apt. I hope the word professional isn't scaring off the hobbyists; I would definitely want them to be signing up on the site as well. But as far as the marketing of the site goes, I think our main goal should be impressing industry. Hi, Does this mean it is possible to accurately distinct a hobbyist and a highly qualified professional within the site? Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Thu, Oct 7, 2010 at 12:42 AM, Bas van Dijk v.dijk@gmail.com wrote: Feature suggestion: Allow users to provide their location and show it (and the aggregate of all Haskellers) in a (Google) map. (I Just uploaded my initial profile) Bas I like it, I'll get on it soon. Maybe I can use some of them fancy HTML 5 geolocation APIs ;). Also, just to let everyone know: since no one is really getting back a list of skills they'd like to see, I'm just going to give everyone permission on the site to add new skills. If it gets out of hand, I can start requiring moderation of the entries, but I think we're all pretty mature here. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Wed, Oct 6, 2010 at 2:11 AM, Michael Snoyman mich...@snoyman.com wrote: Hi all, After finally getting OpenID 2 support worked out, I've now put up the Haskellers.com website[1]. Not all features are implemented yet, but the basics are in. One of the most important features is going to be the user profiles, and I wanted some community input on the kind of stuff they'd like to see. For now, I collect email address (spam-protected, don't worry), website, number of years of Haskell experience, and a free-form description. I've also added a skills section, but have purposely not added many. I wanted community input on the kinds of skills. Some ideas: Is it possible to change the years of experience to allow us to enter when we started learning Haskell and let the website calculate years of experience? It's unlikely that people will remember to update the years of experience I think. Of course, that doesn't work so well for people who have gaps in their experience. So allowing date ranges would probably be even better. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ordering vs. Order
Hi all, I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). My dictionaries tell me that order (besides other meanings) denotes an ordered structure on elements and ordering (as only meaning) denotes some request that I made at some entity. So, to me it seems that calling the type class Ordering is wrong ;) However, I do know that there are many publications about ordered structures which use the word ordering (most of which I'm aware of, not by native speakers). What do native speakers have to say about that? best regards chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
On Oct 7, 2010, at 1:02 AM, Christian Sternagel wrote: Hi all, I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). My dictionaries tell me that order (besides other meanings) denotes an ordered structure on elements and ordering (as only meaning) denotes some request that I made at some entity. So, to me it seems that calling the type class Ordering is wrong ;) However, I do know that there are many publications about ordered structures which use the word ordering (most of which I'm aware of, not by native speakers). What do native speakers have to say about that? They're pretty much synonymous. Given a specific context, an order is the relation that orders a set, whereas an ordering is a relation that orders a set. For example, a set with three elements can be ordered in three different ways. Each of them is an ordering. But none is THE order. (If the elements are integers, then they can inherit THE integer order, if you wanted the set to inherit that notion of an order) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Excerpts from Gregory Collins's message of Wed Oct 06 19:44:44 -0400 2010: I've got the month of October off, and one of the things I've been planning on working on is a compliant HTML5 parser for Haskell -- something which is sorely needed! I will ping the list back if/when I get it finished. I've heard that some of the existing HTML parsers in Haskell were already HTML5 compliant (this topic came up when I was complaining that there were some algorithms that you absolutely had to have state for, because that was how they were specified.) I never verified this assertion though. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Edward Z. Yang ezy...@mit.edu writes: Excerpts from Gregory Collins's message of Wed Oct 06 19:44:44 -0400 2010: I've got the month of October off, and one of the things I've been planning on working on is a compliant HTML5 parser for Haskell -- something which is sorely needed! I will ping the list back if/when I get it finished. I've heard that some of the existing HTML parsers in Haskell were already HTML5 compliant (this topic came up when I was complaining that there were some algorithms that you absolutely had to have state for, because that was how they were specified.) I never verified this assertion though. If there's already a library which *correctly* parses html5 documents into DOM trees, could someone please let me know so I can use it instead of wasting a bunch of time writing one? Thanks, G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
Chris, I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). Irrelevant to your struggle, but note that the *type class* is dubbed Ord, while the Prelude provides a *type* Ordering: class ... = Ord a where ... data Ordering = LT | EQ | GT deriving ... Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Packaging a Gtk2hs based program for Windows
Hello, haskellers. Recently I stumbled upon a problem. It may sound quite off-topic for this list, but, I'm sure, almost every haskell programmer runs into it sooner or later. It sounds: How to make a neat Windows installer for a nice Gtk2hs program I wrote last week? How to solve the problem of dependency on GTK? Should I ask my users to install a GTK package or it would be better to package all the dynamic libraries needed along with my program? Are there any troubles with different character encodings used in Windows? How to change the application icon? And so on.. I understand, there is no ultimate answer, but I hope there is some wisdom to share. I've been a Linux user for more then five years and now I've found myself completely illiterate on how to make my code easily accessible for a nontechnical Windows user. I would appreciate any thoughts and advises Best wishes, Dmitry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Notes from Haskell takes over the world BoF at ICFP
On 07/10/2010 02:45, Jason Dagit wrote: + well documented workflow for lightweight changes + heavy weight process for major work. + bugs, tickets. + Simon Marlow contributions are going up, and process is working well That's reassuring. Is their workflow documented for the benefit of other Haskell projects and the greater FOSS community in general? We have pretty extensive instructions on how to contribute to GHC here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions If you find anything missing, or something that could be improved, please let us know! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packaging a Gtk2hs based program for Windows
2010/10/7 Dmitry V'yal akam...@gmail.com: It sounds: How to make a neat Windows installer for a nice Gtk2hs program I wrote last week? How to solve the problem of dependency on GTK? Should I ask my users to install a GTK package or it would be better to package all the dynamic libraries needed along with my program? Are there any troubles with different character encodings used in Windows? How to change the application icon? And so on.. It is better to copy GTK libraries with your application. If you ask user to install GTK libraries they can install incompatible version (and certainly will). ;) We didn't encountered difficulties with different character encodings. You have to look on gcc documentation (ld part of it) where you can specify resource file with application icon. Don't forget -mwindows key for ld. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lazy evaluation from Why Functional programming matters
Have you seen Potential (http://intoverflow.wordpress.com/2010/05/21/announcing-potential-x86-64-assembler-as-a-haskell-edsl/)? Quote: The language’s goal is to provide a solid foundation for the development of a useful (multi-tasked, multi-processor, etc) microkernel Which sounds like it's exactly what you want. Also, see Harpy (http://uebb.cs.tu-berlin.de/harpy/). Thank you very very much Neil for pointing me to Potential. I'll take a look at it. -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com profiles: advice requested
On Thu, Oct 7, 2010 at 8:41 AM, Vo Minh Thu not...@gmail.com wrote: 2010/10/7 Michael Snoyman mich...@snoyman.com: On Wed, Oct 6, 2010 at 8:14 PM, Brent Yorgey byor...@seas.upenn.edu wrote: One (slightly off-topic) question: at the top of the site it says the meeting place for professional Haskell programmers. Is this supposed to be geared towards Haskell programmers who get paid (or want to get paid) to write Haskell? If so, fine; if not, in my opinion the word professional ought to be dropped. The fact is that the site has two functions: on the one hand, it's simply a social network for anyone connected to the Haskell world. In that sense, the word professional is inaccurate. However, the second function is to encourage Haskell usage in industry, by showing a large number of highly qualified Haskell programmers. In this sense, the word professional is very apt. I hope the word professional isn't scaring off the hobbyists; I would definitely want them to be signing up on the site as well. But as far as the marketing of the site goes, I think our main goal should be impressing industry. Hi, Does this mean it is possible to accurately distinct a hobbyist and a highly qualified professional within the site? No. Firstly, there can be a very fine line between hobbyist and professional. At my previous job, I did 95% of my coding and SAS and VBA (the lovely insurance industry). However, they had one project where we needed fast parsing of large binary files and I used Haskell for it. I would have considered myself at the time a Haskell hobbyist, but it's not really clear. Secondly, the only information which is verified on the Haskellers site right now is email address. I have plans to add badges so that people can be verified, but I'm hesitant to do so right now. You can get an idea of how professional a Haskeller someone is right now based on their years of experience and their description field. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: EDSL for Makefile
which looks somewhat nicer. This example also defines runTest and a test function (which calls the shell command echo to print some lines) you can try in ghci by typing runTest test... [1] http://gist.github.com/614246 Thank you very much Steffen for taking the time out for the example ... I'll study the code. -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
On Thu, Oct 07, 2010 at 12:29:51AM +0200, Christopher Done wrote: On 6 October 2010 23:26, Vincent Hanquez t...@snarc.org wrote: I'ld like to announce the tls package [1][2], which is a native implementation of the TLS protocol, client and server. It's currently mostly supporting SSL3, TLS1.0 and TLS1.1. It's got *lots* of rough edges, and a bunch of unsupported features, but it's humming along, and at each iteration it's becoming more tighly secure and featureful. Wow, great! So might we be able to combine this with Network.HTTP some day? I am interested in moving away from C libraries (curl) to pure Haskell libraries, for a safer, richer Haskell ecosystem and for solving the interesting problems. That's one of the goal of this library. Ultimately I want something more flexible than usual APIs in traditional libraries; TLS can do lots of things, that are not typically exposed by others libraries. Otherwise more pratically, there's michael's http-enumerator. I hope i'll see more package depending on tls in the future instead of gnutls/openssl bindings. Will you eventually add benchmarks? This is on my TODO list but the priority is quite low; I'm trying to focus on correctness and security for now. However I suspect what does make the biggest difference is the crypto implementation that is used, and the current dependencies should be all reasonable (cryptohash is close to C performance level with hashes, the AES package has a pretty fast implementation, ghc seems quite good with big number benefiting RSA, ..). -- Vincent Hnquez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Eta-expansion destroys memoization?
Hi all, See below for this message from one of my students which has me stumped. Just when you think you understand Haskell... ;) I've cc'ed him on this message; please include him on any replies as I don't think he is subscribed to -cafe. -Brent - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Date: Tue, 5 Oct 2010 21:23:57 -0400 To: Brent Yorgey byor...@seas.upenn.edu Subject: store evaluated values Hi, Anthony (or Brent): Last time (in Anthony's TA office hour) we talked about how to store evaluated values in the program for later used. I googled for a while and wrote some code. But I still encountered two problems. Can you take a look? Thanks. First, let's write the naive fib function: naive_fib 0 = 0 naive_fib 1 = 1 naive_fib n = trace(show(n)) naive_fib (n - 1) + naive_fib (n - 2) this works good except it tries to calculate the same expression many times. So when we evaluate it ghci will show the following: *Main naive_fib 5 5 4 3 2 2 3 2 5 Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) When we evaluate the same expression we can see it does not evaluate the redundant expression over and over: *Main fib 5 5 4 3 2 5 The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. But After I change that, *Main fib 5 5 4 3 2 2 3 2 5 So why does the x here matters? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Haskell XML Toolbox 9.0.0 I would like to announce a new version of the Haskell XML Toolbox. HXT has grown over the years. Components for XPath, XSLT, validation with RelaxNG, picklers for conversion from/to native Haskell data, lazy parsing with tagsoup, input via curl and native Haskell HTTP and others have been added. This has led to a rather large package with a lot of dependencies. To make the toolbox more modular and to reduce the dependencies on other packages, hxt has been split into various smaller packages since this version. Information about this release, about the new packages, changes and incompatibilities to older versions can be found at HXT home: http://www.fh-wedel.de/~si/HXmlToolbox/index.html; and on the Haskell wiki page about HXT http://www.haskell.org/haskellwiki/HXT; The source repo has been moved to GitHub: http://github.com/UweSchmidt/hxt; Downloads and installation is available from hackage. Please email comments, bugs, etc. to hxmltool...@fh-wedel.de or s...@fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
Christian Sternagel c.sterna...@gmail.com writes: recently I was wondering about the two words order and ordering I would use ordering to mean the relation or function that orders (ranks) elements, and I'd use order to refer the actual progression. So by applying an ordering, you get elements in a particular order. My dictionary lists them as synonyms for this, but order has the unfortunate potential to be confused with the verb, and generally seems to have more possible meanings than ordering. I'm not a native English speaker Me neither. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Michael Snoyman mich...@snoyman.com writes: As far as I know, Neil Mitchel's tagsoup[1] parses according to the HTML 5 parsing rules, but it just generates a list of Tags[2], so you'd have to build the DOM tree up from there. I personally have had great experience with tagsoup. It's even the core of HTML-scraping technology powering searchonce[3]. Yep, someone else wrote me privately to say this (that tagsoup respects the html5 lexing rules). So I'll be using this as the basis of an html5 DOM parser. Stay tuned! G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
2010/10/7 Gregory Collins g...@gregorycollins.net: Edward Z. Yang ezy...@mit.edu writes: Excerpts from Gregory Collins's message of Wed Oct 06 19:44:44 -0400 2010: I've got the month of October off, and one of the things I've been planning on working on is a compliant HTML5 parser for Haskell -- something which is sorely needed! I will ping the list back if/when I get it finished. I've heard that some of the existing HTML parsers in Haskell were already HTML5 compliant (this topic came up when I was complaining that there were some algorithms that you absolutely had to have state for, because that was how they were specified.) I never verified this assertion though. If there's already a library which *correctly* parses html5 documents into DOM trees, could someone please let me know so I can use it instead of wasting a bunch of time writing one? As far as I know, Neil Mitchel's tagsoup[1] parses according to the HTML 5 parsing rules, but it just generates a list of Tags[2], so you'd have to build the DOM tree up from there. I personally have had great experience with tagsoup. It's even the core of HTML-scraping technology powering searchonce[3]. Michael [1] http://hackage.haskell.org/package/tagsoup [2] http://hackage.haskell.org/packages/archive/tagsoup/0.11.1/doc/html/Text-HTML-TagSoup.html#t:Tag [3] http://www.search-once.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 6:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. Semantically, yes. And it's possible that ghc -O is clever enough to notice that. But at least under ghci's naive evaluation strategy, lambdas determine the lifetime of expressions. Any expression within a lambda will be re-evaluated each time the lambda is expanded. Thus: fib = (map fib' [0..] !!)-- fast fib = \x - map fib' [0..] !! x-- slow fib = let memo = map fib' [0..] in \x - memo !! x -- fast The section works because (a %^) (for some operator %^) is short for (%^) a and (%^ a) is short for flip (%^) a. Sections don't expand into lambdas. In other words, in the middle expression, there is a new map fib' [0..] for each x, whereas in the others, it is shared between invocations. Does that make sense? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 8:44 AM, Luke Palmer lrpal...@gmail.com wrote: On Thu, Oct 7, 2010 at 6:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. Semantically, yes. And it's possible that ghc -O is clever enough to notice that. But at least under ghci's naive evaluation strategy, lambdas determine the lifetime of expressions. Any expression within a lambda will be re-evaluated each time the lambda is expanded. Thus: fib = (map fib' [0..] !!) -- fast fib = \x - map fib' [0..] !! x -- slow fib = let memo = map fib' [0..] in \x - memo !! x -- fast The section works because (a %^) (for some operator %^) is short for (%^) a and (%^ a) is short for flip (%^) a. Sections don't expand into lambdas. In other words, in the middle expression, there is a new map fib' [0..] for each x, whereas in the others, it is shared between invocations. Does that make sense? In general, f is not semantically equivalent to \x - f x in Haskell. However, that is not what Brent said. The Report -defines- (m !!) as \x - m !! x. GHC simply does not follow the Report here. You can witness this via: (() `undefined`) `seq` 0. By the Report this should evaluate to 0, in GHC it evaluates to undefined. As for the rest... The operational behavior of the above is implementation dependent, but GHC, and I imagine most implementations, more or less do the natural thing. The Report gives no way to control sharing behavior, but being able to control it is rather important, so predictable behavior here is desirable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 1:44 PM, Luke Palmer lrpal...@gmail.com wrote: The section works because (a %^) (for some operator %^) is short for (%^) a and (%^ a) is short for flip (%^) a. Sections don't expand into lambdas. According to the report they do: http://haskell.org/onlinereport/exps.html#sections http://haskell.org/onlinereport/haskell2010/haskellch3.html#x8-33.5 but GHC is different, I think: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#postfix-operators I'm not sure if the significance of this difference is explored anywhere, but notice that: ghci (() `undefined`) `seq` () *** Exception: Prelude.undefined ghci (`undefined` ()) `seq` () () ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thursday 07 October 2010 14:17:18, Brent Yorgey wrote: Hi all, See below for this message from one of my students which has me stumped. Just when you think you understand Haskell... ;) I've cc'ed him on this message; please include him on any replies as I don't think he is subscribed to -cafe. -Brent cf. http://www.haskell.org/pipermail/haskell-cafe/2009-October/067811.html If fib is defined without a type signature, the monomorphism restriction also kicks in, when fib is bound via a function binding, fib x = ... fib has polymorphic type (Num a) = Int - a and that prevents sharing the list (since there are lists for all Num types). If bound via a simple pattern binding, fib = (map fib' [0 .. ] !!) where ... and the MR is not disabled, fib gets the monomorphic type Int - Integer and that allows the list to be shared. If you give fib an explicit monomorphic type fib :: Int - Integer the list will still not be shared if it's bound via a function binding because fib' and the list are bound inside the lambda: fib = \k - let fib' ... in (map fib' [0 .. ] !!) k fib' is not a constant, so it's not floated out of the lambda, so it's not shared (and a fortiori map fib' [0 .. ] isn't shared). if fib is bound via a simple pattern binding (and no explicit lambda is given), fib' and the list are bound outside the lambda and hence shared: fib = let fib' = ...; lst = map fib' [0 .. ] in \k - lst !! k Note however that using the list as map fib' [0 .. ] is more brittle than giving it a name and binding it explicitly in the where clause: fib :: Int - Integer fib = (fibList !!) where fibList = map fib' [0 .. ] fib' 0 = 0 ... For the time being, GHC treats both the same, but the latter is less likely to break. - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Date: Tue, 5 Oct 2010 21:23:57 -0400 To: Brent Yorgey byor...@seas.upenn.edu Subject: store evaluated values Hi, Anthony (or Brent): Last time (in Anthony's TA office hour) we talked about how to store evaluated values in the program for later used. I googled for a while and wrote some code. But I still encountered two problems. Can you take a look? Thanks. First, let's write the naive fib function: naive_fib 0 = 0 naive_fib 1 = 1 naive_fib n = trace(show(n)) naive_fib (n - 1) + naive_fib (n - 2) this works good except it tries to calculate the same expression many times. So when we evaluate it ghci will show the following: *Main naive_fib 5 5 4 3 2 2 3 2 5 Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) When we evaluate the same expression we can see it does not evaluate the redundant expression over and over: *Main fib 5 5 4 3 2 5 The source code seems to be easy to read, but I don't think I understand that. For me I think if I change the first line from fib = ((map fib' [0 ..]) !!) to fib x = ((map fib' [0 ..]) !!) x It should do the same thing since I think the previous version is just an abbreviation for the second one. But After I change that, *Main fib 5 5 4 3 2 2 3 2 5 So why does the x here matters? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ordering vs. Order
On Thu, 07 Oct 2010 10:02:20 +0200, you wrote: I'm not a native English speaker and recently I was wondering about the two words order and ordering (the main reason why I write this to the Haskell mailing list, is that the type class Ordering does exist). My dictionaries tell me that order (besides other meanings) denotes an ordered structure on elements and ordering (as only meaning) denotes some request that I made at some entity. So, to me it seems that calling the type class Ordering is wrong ;) Considering them both used as nouns, I would say that in normal usage, there is a difference in their active/passive connotation. If you have a collection of things, they have an order, whether or not that order was imposed on them (it could be that they just fell out of the box in a certain order). On the other hand, if they possess an ordering, it implies that someone or something put them in that order; i.e., that it was a purposeful act. I think the reason for this conceptual distinction can be traced to the derivation of ordering as the gerund form of the verb order, in that it implies that an action has occurred (or is still occurring). -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
What people seem to be missing here is that the location of the where-binding with respect to the lambda changes in each case. As a result, I think the forgoing explanations were rather confusing; there's no magic going on here. On Thu, Oct 7, 2010 at 8:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) This is indeed equivalent to: fib = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) But adding the argument embeds the let inside the function call: fib x = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) Now we create a new fib' for each invocation of fib. Not efficient at all! (Much *less* efficient the the recursive fib). There's no evaluation magic here---all that's happening is GHC is executing the program exactly as written. It can't float the list out of the function, as that can lead to unexpected space leaks (if you didn't intend to keep the list of fibs around forever). -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
On Thu, Oct 7, 2010 at 9:33 AM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: There's no evaluation magic here---all that's happening is GHC is executing the program exactly as written. It can't float the list out of the function, as that can lead to unexpected space leaks (if you didn't intend to keep the list of fibs around forever). To echo Jan-Willem a bit, the impact of let floating can be seen by compiling the eta expanded version (i.e. fib x = map fib' [0..] !! x) with different options. $ ghc --make -O -fforce-recomp FibMemo.hs [1 of 1] Compiling Main ( FibMemo.hs, FibMemo.o ) Linking FibMemo ... $ ./FibMemo 5 3 2 4 5 $ ghc --make -O -fforce-recomp FibMemo.hs -fno-full-laziness [1 of 1] Compiling Main ( FibMemo.hs, FibMemo.o ) Linking FibMemo ... $ ./FibMemo 5 3 2 4 2 3 2 5 My understanding is that this is just a case where GHCi is able to float a binding in the partial application formulation because the dependency analysis is trivial due to there being no name for the binding. Looking at the core for the optimized version of the eta expanded code, there is a a top-level function for building a list of fibonacci numbers, a top-level value of type [Type.Integer] set to an application of the builder function to zero, and finally the fib function that indexes into that list. The version with -fno-full-laziness leaves the let binding under the lambda as expected. So the optimizer is clever and can see through the lambda, but we make the interpreter's job easier by not putting a lambda over its eyes to begin with. Anthony On Thu, Oct 7, 2010 at 9:33 AM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: What people seem to be missing here is that the location of the where-binding with respect to the lambda changes in each case. As a result, I think the forgoing explanations were rather confusing; there's no magic going on here. On Thu, Oct 7, 2010 at 8:17 AM, Brent Yorgey byor...@seas.upenn.edu wrote: - Forwarded message from Yue Wang yulew...@gmail.com - From: Yue Wang yulew...@gmail.com Then there is a clever way to do that on haskell wiki: fib = ((map fib' [0 ..]) !!) where fib' 0 = 0 fib' 1 = 1 fib' n =trace(show(n)) fib (n - 1) + fib (n - 2) This is indeed equivalent to: fib = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) But adding the argument embeds the let inside the function call: fib x = let fib' 0 = 0 fib' 1 = 1 fib' n = fib (n-1) + fib (n-2) in (map fib' [0..] !!) Now we create a new fib' for each invocation of fib. Not efficient at all! (Much *less* efficient the the recursive fib). There's no evaluation magic here---all that's happening is GHC is executing the program exactly as written. It can't float the list out of the function, as that can lead to unexpected space leaks (if you didn't intend to keep the list of fibs around forever). -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
Hi, On 06.10.2010, at 22:43, Sterling Clover wrote: On Oct 6, 2010, at 5:39 AM, Simon Marlow wrote: A slightly different suggestion from Simon PJ and myself (we agreed on something syntax-related :-) is the following: \case 1 - f 2 - g where the two-token sequence '\ case' introduces a new optional layout context, the body of which is exactly the same as in a case expression. So you could also write \case { 1 - f; 2 - g } if you want. Guards are allowed of course. * a bit more noisy than just \: I'm not sure what the ramifications of having \ introduce a layout context on its own would be, but I suspect there would be difficulties. Certainly some existing code would fail to parse, e.g. (case e of [] - \x - x+1; (x:xs) - \x - x+2) \ introducing a layout context is a no-go because, as in the example given, it breaks too much code. However, \case as described is somewhat less powerful. In particular, \ with a layout context lets us have multi-argument pattern matching, while both \case and case of give only single argument pattern matching. I don't know if the extra functionality is that important, but I don't see why we can't provide for it anyway, as in: \case (x:xs) n - go xs; _ n - n; Then, there is an inconsistency between lambda-case and traditional case and people will start complaining about that. Haskell98 is a very well thought out language with very few syntactiv warts. I'd avoid introducing new language extensions which do introduce new warts. Backwards compatibility is not so important, because GHC will hopefully make it optional. Even when an extended \{ p1 - e1; p2 - e2 } is part of Haskell 2012 GHC will probably support Haskell 2011 as well. Therefore, I'd worry less about backwards compatibility, but concentrate more on consistency and elegance. I.e I'll favor \p1 p2 - e1 p3 p4 - e2 Just my 2 cents. -- Jean___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CFP MSCS Issue: Dependently Typed Programming
(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)- (p:P s)* OPEN CALL FOR PAPERS for a Special Issue of MATHEMATICAL STRUCTURES in COMPUTER SCIENCE in association with the workshop DEPENDENTLY TYPED PROGRAMMING 2010 editors: Thorsten Altenkirch (Nottingham), Conor McBride (Strathclyde) 2011 timeline: submission Jan 31; notification May 31; final version June 30 (s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)-(p:P s)*(s:S)- (p:P s)* Thorsten Altenkirch and Conor McBride are delighted to invite contributions to a Special Issue of the journal Mathematical Structures in Computer Science (Cambridge University Press), in association with the Workshop on Dependently Typed Programming, which we organised on 9 and 10 July 2010 in Edinburgh, as part of FLoC, associated with LiCS. The workshop had a packed programme of exciting developments, reflecting the strength of work on this topic at this time. More recent workshops and conferences have exhibited a significant contribution from researchers in this area. We are grateful to Editor-in-Chief Giuseppe Longo and to Editor Eugenio Moggi for the opportunity to reflect these welcome developments in the pages of MSCS, and we encourage researchers to consider submitting a paper. submission deadline: January 31 2011 notification: May 31 2011 final versions due: June 30 2011 We invite full journal articles concerning Dependently Typed Programming or related topics, from authors at work in this area. Submissions are particularly welcome from but not limited to contributors to the workshop, and the same journal-standard peer review process will apply in any case. Please feel free to address any enquiries about scope and suitability to the guest editors, Thorsten Altenkirch (University of Nottingham) and Conor McBride (University of Strathclyde). Submissions should usually not exceed 35 pages. Authors should adhere to the guidelines issued by Cambridge University Press for MSCS contributors: http://assets.cambridge.org/MSC/MSC_ifc.pdf. These include directions to the relevant LaTeX resources. We very much look forward to hearing from you. Thorsten and Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Lambda-case / lambda-if
On Tue, 2010-10-05 at 17:10 -0700, Evan Laforge wrote: +1 for something to solve the dummy - m; case dummy of problem. Here are the possibilities I can think of: Might be off-topic here, but I have wondered for a while why Haskell doesn't support something like follows: do case (- m) of ... With the more general rule being: do ... e (- m) g = ... m = \tmp - e tmp g Reasons: * - is already sugary, and the transformation is similar. Just removes the need for the user to define a throw-away name. * Better than liftMX and the Applicative operators. As shown, this is more flexible while requiring less magic operators as a bonus. Also makes more clear where the sides effects actually are. * Goes well with the spirit of getting the good parts of imperative coding where it potentially makes the code more concise. Can be abused, obviously, but I have also seen a lot of code that I feel could be written better using this. Anything I am overlooking here? I tried to find a discussion about something like this, but didn't really know what to look for... Greetings, Peter Wortmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Could you explain to me why HXT uses arrows? I have never been able to figure out what advantage this gives your library over monads. Since your arrows in practice implement ArrowApply, they are really just monads anyway, so it seems to me that using arrows instead of monads only serves to add complexity to the library without adding any benefit. Furthermore, by using arrows instead of monads people cannot use the many standard monad libraries out there, but have to instead write their own generalizations of them to arrows. Is there some benefit that your library gets out of using arrows that I missed which makes these costs worth it? Cheers, Greg On 10/7/10 5:28 AM, Uwe Schmidt wrote: Haskell XML Toolbox 9.0.0 I would like to announce a new version of the Haskell XML Toolbox. HXT has grown over the years. Components for XPath, XSLT, validation with RelaxNG, picklers for conversion from/to native Haskell data, lazy parsing with tagsoup, input via curl and native Haskell HTTP and others have been added. This has led to a rather large package with a lot of dependencies. To make the toolbox more modular and to reduce the dependencies on other packages, hxt has been split into various smaller packages since this version. Information about this release, about the new packages, changes and incompatibilities to older versions can be found at HXT home: http://www.fh-wedel.de/~si/HXmlToolbox/index.html; and on the Haskell wiki page about HXT http://www.haskell.org/haskellwiki/HXT; The source repo has been moved to GitHub: http://github.com/UweSchmidt/hxt; Downloads and installation is available from hackage. Please email comments, bugs, etc. to hxmltool...@fh-wedel.de or s...@fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
Отправлено с iPhone Oct 7, 2010, в 21:03, Peter Wortmann sc...@leeds.ac.uk написал(а): On Tue, 2010-10-05 at 17:10 -0700, Evan Laforge wrote: +1 for something to solve the dummy - m; case dummy of problem. Here are the possibilities I can think of: Might be off-topic here, but I have wondered for a while why Haskell doesn't support something like follows: do case (- m) of ... I think it'd be better to write just 'case (- m) of', without 'do'. With the more general rule being: do ... e (- m) g = ... m = \tmp - e tmp g Reasons: * - is already sugary, and the transformation is similar. Just removes the need for the user to define a throw-away name. * Better than liftMX and the Applicative operators. As shown, this is more flexible while requiring less magic operators as a bonus. Also makes more clear where the sides effects actually are. * Goes well with the spirit of getting the good parts of imperative coding where it potentially makes the code more concise. Can be abused, obviously, but I have also seen a lot of code that I feel could be written better using this. Anything I am overlooking here? I tried to find a discussion about something like this, but didn't really know what to look for... Greetings, Peter Wortmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] I'm still having challenges to get a Haskell GUI to work under Windows 7
I'm still having challenges to get a Haskell GUI to work under Windows 7; even after various instructions on the web. e.g. Haskell Platform 2010.2.0.0, wxWidgets-2.9.1, wxHaskell 0.12.1.6 Similar challenges with GTK+ and gtk2hs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is there a more recent paper or article than Can GUI Programming Be Liberated From The IO Monad
Is there a more recent paper or article than Can GUI Programming Be Liberated From The IO Monad? :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTML library with DOM?
Yes, I don't think I've officially announced a version of TagSoup that has had HTML 5 parsing, but it now does as standard for the last few releases. The HTML 5 spec is still changing, so it's entirely possible something is incorrect in a corner case, but please let me know and I'll fix it. Thanks, Neil 2010/10/7 Gregory Collins g...@gregorycollins.net: Michael Snoyman mich...@snoyman.com writes: As far as I know, Neil Mitchel's tagsoup[1] parses according to the HTML 5 parsing rules, but it just generates a list of Tags[2], so you'd have to build the DOM tree up from there. I personally have had great experience with tagsoup. It's even the core of HTML-scraping technology powering searchonce[3]. Yep, someone else wrote me privately to say this (that tagsoup respects the html5 lexing rules). So I'll be using this as the basis of an html5 DOM parser. Stay tuned! G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
On Thu, 07 Oct 2010 18:03:48 +0100, Peter Wortmann sc...@leeds.ac.uk wrote: On Tue, 2010-10-05 at 17:10 -0700, Evan Laforge wrote: +1 for something to solve the dummy - m; case dummy of problem. Here are the possibilities I can think of: Might be off-topic here, but I have wondered for a while why Haskell doesn't support something like follows: do case (- m) of ... With the more general rule being: do ... e (- m) g = ... m = \tmp - e tmp g Reasons: * - is already sugary, and the transformation is similar. Just removes the need for the user to define a throw-away name. * Better than liftMX and the Applicative operators. As shown, this is more flexible while requiring less magic operators as a bonus. Also makes more clear where the sides effects actually are. * Goes well with the spirit of getting the good parts of imperative coding where it potentially makes the code more concise. Can be abused, obviously, but I have also seen a lot of code that I feel could be written better using this. Anything I am overlooking here? I tried to find a discussion about something like this, but didn't really know what to look for... Your notation feels very tempting, however it relies a lot on finding the do to put the bind. Recall that do is just syntax, and that it has no more meaning than its desugaring. Imagine these examples: do {a; b (- c) d; e} = do {a; x - c; b x d; e} do {a b (- c) d; e} | +-- do {x - c; a b x d; e} | +-- do {a; x - c; b x d; e} Imagine that b can be equal to b1 b2 and so where placing the x - c is non obvious and it should be. On the other hand case (- m) of {...} being translated into m = \x - case x of {...} is non-ambigous. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Notes from Haskell takes over the world BoF at ICFP
Hi Digressing a little, can anyone interested in doing so merge hoogle and Hayoo and make them part of Hackage? I am currently working on this in my spare time. I hope to have something to show in the next month. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there a more recent paper or article than Can GUI Programming Be Liberated From The IO Monad
Of related interest, there have been more recent papers by the Clean developers on Arrow GECS and iData but they are about Clean where this is no IO monad. Maybe Haskell cannot be liberated from IO after all... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
On Thu, Oct 07, 2010 at 02:45:58PM -0700, Nicolas Pouillard wrote: On Thu, 07 Oct 2010 18:03:48 +0100, Peter Wortmann sc...@leeds.ac.uk wrote: Might be off-topic here, but I have wondered for a while why Haskell doesn't support something like follows: do case (- m) of ... With the more general rule being: do ... e (- m) g = ... m = \tmp - e tmp g Your general rule doesn't subsume your case example, since a case expression is not an application. I think you mean something like do C[(- m)] = m = \tmp - C[tmp] where C is an arbitrary expression context. It could further be generalized to allow several (- ...) subterms in an expression, with implied left-to right sequencing. Frankly, that seems like a very attractive way to make the do-notation into a more practical imperative sub-language. This should probably also cover binding, i.e. do { p - C[(- m)]; ... } should also work. Imagine these examples: do {a; b (- c) d; e} = do {a; x - c; b x d; e} do {a b (- c) d; e} | +-- do {x - c; a b x d; e} | +-- do {a; x - c; b x d; e} To my understanding no rule would produce this latter variant. do {a; b} is transformed into a do {b}, not the other way around. The proposed transformation rule seems clear to me: the context covers the entire expression-statement, including of course expressions containing monadic operations: do {a b (- c) d; e} = c = \x - a b x d e and if you want a to go before c, you have to do do {a; b (- c) d; e)= a c = \x - b x d e Imagine that b can be equal to b1 b2 and so where placing the x - c is non obvious and it should be. I don't see what this has to do with anything. All we are interested in is the syntax of do-expressions. The do-transformation is completely oblivious to monadic operations within the statements, it only produces some more monadic operations. Cheers, Lauri ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A model theory question
On Sep 30, 2010, at 1:39 AM, Patrick Browne wrote: I think my original question can be rephrased as: Can type classes preserve satisfaction under the the expansion sentences (signature/theory morphisms inducing a model morphism). According to [1] expansion requires further measures (programming?) which you demonstrated. But this raises are further question. Does Haskell’s multiple inheritance represent a model expansion where the classes in the context of an instance are combined in the new bigger model? In principle, the answer is yes (I think). But I kept running into walls when I tried. It is almost as if there is too big a gap to be filled between compile-time and run-time. At least for the approaches I tried. I have two suggestions though. First, monadism is a great way to approach this problem from a run-time level. Indeed, a monad is an interpreter, which comes with the associated notions of a free algebra/ model and the like. Injecting a new axiom amounts to creating a new monadic action. Monad transformers can do lifting and lowering in a fairly straight forward way. Another suggestion is to check out the OOHaskell paper. I know they use type level forcing to get stuff done, but I guess they used a different cluster of extensions than I tried. http://homepages.cwi.nl/~ralf/OOHaskell/ Sorry for the delay in responding. -Alex___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Eta-expansion destroys memoization?
Brent Yeu, I recently ran into the same question. You can see the thread[1] which includes lots of references to papers that describe the behavior you're seeing along with examples. Implementations of call-by-name lambda calculus all tend to have the same runtime behavior that you're describing. It's usually called sharing. You can look at how ghc reduces expressions like this directly(see [2] and [3]). However, this is really low level and doesn't help us understand the way other Haskell implementations work. John Launchbury[4] came along and said hey, these denotational definitions of call-by-name lambda calculus don't help us understand the runtime of current implementations. He developed a high level operational semantics for call-by-name that correctly, and simply, accounts for sharing across all implementations. I found the paper accessible and very helpful when analyzing the sometimes mysterious runtime behavior of Haskell. Ariola et. all[5] improved upon on Launchbury's work and made an even more high level operational semantics for call-by-name which they called, confusingly enough, call-by-need. This paper is not as accessible as Launchbury, but presents a clever way to describe how sharing works without using a heap construct. If you read carefully through the thread I mentioned in the beginning and Launchbury's paper, you should be equipped to write down reductions by hand that illustrate the different runtime behaviors of your semantically equivalent expressions. David [1] http://comments.gmane.org/gmane.comp.lang.haskell.cafe/81029 [2] http://www.haskell.org/haskellwiki/Ministg [3] http://research.microsoft.com/en-us/um/people/simonpj/Papers/eval-apply/index.htm [4] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.2016 [5] http://homepages.inf.ed.ac.uk/wadler/papers/need/need.ps -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
Does native mean Haskell only - without FFI? -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe