Re: using less stack
From: Alastair Reid [EMAIL PROTECTED] Gertjan Kamsteeg [EMAIL PROTECTED] writes: You don't have to define cpsfold explicitly recursively since it can be expressed in terms of foldr: Hal Daume III [EMAIL PROTECTED] writes: Is this generally considered good design? [...] Three different attempts at an answer: As with all code-factoring it's in the eye of the beholder. If what you want to do is trace execution in detail, the less factored code is easier to understand. If what you want to do is understand the difference between 5 different recursive traversals of a list, then isolating those differences (by suppressing the invariant fact of recursion) is better. I agree. However, although *functionally* every list traversing function should be expressible in terms of foldr (because foldr represents the type theoretical elimination rule for lists in most type systems with inductive types (and without element depending types)), it's not just a matter of taste. Execution clearly *does* depend on how things are defined. When I said 'can be expressed', I meant extensionally equivalent, including behavior w.r.t. reductions. For example, if, in the Prelude, foldr had been defined in terms of foldl: foldr f a xs = foldl (\h x y - h (f x y)) id xs a my definition of cpsfold in terms of foldr wouldn't go through. That is, some stack would again overflow. What I wanted to say is that the fact that Amanda's answer1 (maximum in terms of foldr) didn't work wasn't caused by the definition of foldr in the Prelude. Besides, (re)factoring is fun. So, here's another one (foldl in terms of foldr): foldl f a xs = foldr (\x h y - h (f y x)) id xs a BTW, there may be another reason for expressing list traversing functions in terms of foldr: if one uses only functions representing 'standard' elimination rules, it is guaranteed that all reduction sequences eventually terminate. Gertjan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: using less stack
Hal Daume III writes: You don't have to define cpsfold explicitly recursively since it can be expressed in terms of foldr: Is this generally considered good design? That is, is it generally preferred to express functions in a nonrecursive style if that can be done using standard library functions like foldr and map and filter, etc? One answer that Alastair Reid did not mention is that the nonrecursive style usually benefits from the deforestation optimization whereas IIUC the explicitly recursive style never does in contemporary compilers. Another answer, which I give because the factor does not enter enough into the thinking of academic language designers, is that the nonrecursive style inhibits adoption of Haskell by making it slightly more difficult for the average programmer or programmer-wannabe to learn --slightly because with recursion, lists and monadic interfaces Haskell already has a lot of significant learning barriers to adoption, and the nonrecursive style of definition is easier to learn (get used to) than any one of those last 3. -- Richard Uhtenwoldt ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
a survey of language popularity
So, how popular is Haskell compared to other languages? Here are some Google search results that suggest how many web pages are devoted to particular langauges. (Google tells you how many pages match your query.) A better survey of language popularity would include newsgroup and mailing list traffic, but no time, no time. In this modest survey, Haskell is a little more popular than O'Caml, a little less popular than Eiffel (an OOPL) 5 to 6 times less popular than Smalltalk; 8 to 10 times less popular than Python, which is itself at least 2 and a half or 3 times less popular than Perl. On second thought, Eiffel and Smalltalk might be considerably more popular than suggested by page counts because the other languages surveyed have 100% open-source documentation. eg, in the GHC results I saw lots of duplicates of essentially the same document. This is characteristic of open-source-code-licensed content. In contrast, Eiffel and Smalltalk have commercial vendors, whose documentation is (I would think) underrepresented in this modest survey because of having licenses that restrict copying. perl 9,600,000 perl language OR program OR variable OR object 1,490,000. python -monty -snake -venom 809,000 python program OR language OR variable OR object 630,000 smalltalk 361,000 (say 10% false hits. 325,000 real.) lisp cmucl OR common lisp OR heap OR cdr OR cons OR lambda OR closure OR scheme 188,000 eiffel object OR program OR variable OR string -tower 74,700 (I say there's a few false hits there. 71,000 real hits.) ghc haskell OR compiler 63,100 ghc haskell OR compiler OR functional OR fp 66,800 haskell fp OR programming OR monad OR monadic OR functional OR lambda 63,600 haskell programming OR monad OR monadic OR functional OR lambda 55,500 (I say 63,000 is the most accurate) caml 88,700 (I can see some false hits) objective caml OR ocaml OR o'caml 41,700. (42,000) note that there is at least one open-source Linux package, unison, a file sync utility, written in O'Caml. no Linux packages written in Haskell except for Haskell compilers. other info useful for measuring language popularity. LIa href=http://www.dwheeler.com/sloc/redhat71-v1/summary;sloc in various RedHat 7.2 packages/a LIa href=http://upgrade-cepis.org/issues/2001/6/up2-6Gonzalez.pdf;lines of code in Debian/a LIa href=http://people.debian.org/~jgb/debian-counting/;Counting Debian ///a LIa href=http://www.eros-os.org/pipermail/e-lang/2001-February/004594.html; [E-Lang] popularity of programming languages among open source hackers // weak survey, of Sourceforge projects. see also Oct 2001 e-lang./a -- Richard Uhtenwoldt ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Announce: Gtk2Hs - A Haskell binding for Gtk2
Note: This is not gtk+hs. Gtk2Hs is a rewrite of gtk+hs. It is a binding to the recently released version of Gtk2 with a couple of improvements over gtk+hs: - Automatic memory management. - Nearly complete coverage of widget functions and their signals, including the new text and list widgets. - The convenience wrapper MoGuL (Monad Gui Library) makes it possible to create and lookup named widgets in a type safe way. - Unicode support. - Object-oriented calling convention for widget functions. - Pragmatically uses both c2hs and hsc acquire information about the C files. Automatically generates callback handlers and the widget type hierarchy. - Needs ghc version 5.00 or later, makes use of the --make flag and complies quite quickly (12 mins). I am currently only providing CVS access to the sources. Find them at: https://sourceforge.net/cvs/?group_id=49207 At the moment it does not compile on Solaris due to the 4 parameter restriction of GHC for dynamic callbacks. Feedback is very welcome, a good place to send it to is: [EMAIL PROTECTED] Share and enjoy, Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
http://haskell.org
Hi I visited http://haskell.org, and noticed that you're not listed on some search engines! I think we can offer you a service which can help you increase traffic and the number of visitors to your website. I would like to introduce you to TrafficMagnet.net. We offer a unique technology that will submit your website to over 300,000 search engines and directories every month. You'll be surprised by the low cost, and by how effective this website promotion method can be. To find out more about TrafficMagnet and the cost for submitting your website to over 300,000 search engines and directories, visit www.TrafficMagnet.net. I would love to hear from you. Best Regards, Christine Hall Sales and Marketing E-mail: [EMAIL PROTECTED] http://www.TrafficMagnet.net This email was sent to [EMAIL PROTECTED] I understand that you may NOT wish to receive information from me by email. To be removed from this and other offers, simply click here.
typeclasses
Cagdas Ozgenc writes: | Greetings. | | How can I make all types that belong to class A and instance of | class B, if the implementations of functions in class B can be | realized by only using the functions in class A? | | Thanks for taking time. Something like this, you mean? class A t where a::t class B t where b::t instance A t = B t where b = a That's not allowed in Haskell 98. Section 4.3.2 of the report says that the type in the instance declaration must consist of a type constructor applied to zero or more type variables, but in instance ... = B t where ... the type (t) is not of that form. Here are some ways to get around the restriction: - Remove class B, and turn its methods into ordinary functions with A in their contexts, or - Use an overlapping instances extension. I asked a similar question a couple of years ago. Here's the key response. http://www.mail-archive.com/haskell@haskell.org/msg05658.html Regards, Tom ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
(no subject)
subscribe Haskell Michelle Yu [EMAIL PROTECTED] __ === ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
