Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
Thank you all for the hard work. The new features are already of great help to me! Cheers, Darren On 2013-09-04 2:13 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of dependency hell and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-install-v1.18.0 (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors. ___ 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] Subclass or no subclass?
Here's another thought (not my own): Abstractions can be classified based on where responsibility lies. Popular languages implementing interface composition expect the caller to know almost nothing about the concrete details while the callee has to handle all concrete permutations. Conversely, the sort of abstraction we see in typeclasses, much like those in c++ template programming, require the client to dictate concrete details that satisfy the callee requirements. Cheers, Darren On 2013-07-01 9:08 AM, Patrick Browne patrick.bro...@dit.ie wrote: On 30/06/13, *Dan Burton * danburton.em...@gmail.com wrote: I am not trying to say every building is a shelter, rather anything that is a building must provide sheltering services. Well if it walks like a shelter and quacks like a shelter... /shrug One of the nice things about OO is the intuitive nature of the is-a relation between class and instance (forgetting hierarchies for the moment). I suggest that an intuitive interpretation of the Haskell class–instance relation might be *acts-as*. For example, a car or a bus could afford transport once they have a move operation. This is an intuitive view for design; it does not reflect the language level function of handling ad-hoc polymorphism. Also it reifies the type class, which AFAIK does not exist at run time. Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ 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] question about indentation conventions
Hi Richard, This page helped me when starting out: http://en.wikibooks.org/wiki/Haskell/Indentation On 2013-06-30 4:55 PM, Richard Cobbe co...@ccs.neu.edu wrote: I hope I'm not starting a holy war with this, but I'm curious about an aspect of coding style that's been bugging me for a while, and I'm not finding much discussion of this question on the web or in the mailing list archives. Two questions: 1) Are there wide-spread conventions in the Haskell community for how to indent an application expression that's split across multiple lines? For how to indent an expression that uses infix operators? Or does everyone pretty much do their own thing? 2) If there is such a convention, how do I make Emacs's haskell-mode do it? By default, in most cases Emacs's haskell-mode with turn-on-haskell-indentation does function firstArgument (second argument) thirdArgument Personally, I'd prefer some indentation on the 2nd and 3rd lines to indicate that they're continuing an expression begun on a previous line. I can use parens around the entire application to force haskell-mode to indent subsequent lines (and of course this is necessary in some contexts, like a 'do' expression), but haskell-mode only indents that by a single space: do (function firstArgument (second argument) thirdArgument) nextAction I'd find a larger indent---even just 2 spaces---to be more readable. My inclination to indent the second and following lines of a multi-line application expression is informed by my long experience in Scheme, Racket, and Lisp, whose S-expressions lend themselves to fairly straightforward (and automatable!) indentation conventions. If the Haskell community does things differently, though, I'm happy to adapt. This is the sort of thing that one picks up from the community, as in other languages. I don't, however, have a whole lot of contact with that community outside this list -- thus the post, despite the dangers inherent in discussing subjective stuff like this that people often feel strongly about. Thanks, Richard ___ 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] Promoting Haskell via Youtube movies
Third. I really like the hands on approach. Cheers, Darren On 2013-06-17 12:09 PM, Taylor Hedberg t...@tmh.cc wrote: AlanKim Zimmerman, Mon 2013-06-17 @ 20:38:55+0200: This looks like quite a good series https://www.youtube.com/user/jekor Seconded. I have really enjoyed his videos so far and it seems like he's regularly producing more. ___ 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] Fwd: Backward compatibility
Just to be clear, is WASH beyond redemption, or would it be worth reviving again? If so, why? Cheers, Darren On 2013-05-05 1:48 PM, Alberto G. Corona agocor...@gmail.com wrote: The case of WASH is a pity. Architecturally It was more advanced that many recent haskell web frameworks. The package would have been a success with little changes in the DSL syntax. I suspect that there are many outstanding packages with great ideas abandoned, like WASH 2013/5/5 Brandon Allbery allber...@gmail.com On Sun, May 5, 2013 at 7:55 AM, Raphael Gaschignard dasur...@gmail.comwrote: Forgive me if I'm wrong, but I feel like I've seen such suggestions in GHC errors before. If so, does that mean there's some sort of mechanism in the compiler already in place for such error recognition? Like some simple pattern stuff? If not, I think that it might not be bad to consider this stuff (misused packaged, changed semantics that create compiler errors), and to put something into place for future modifications. This could make it a lot easier to deal with unmaintained code. There's some very limited capability now; the GHC folks are tossing around ideas for something more general like that. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alberto. ___ 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] Type classes, collections, sum types, closures, and a massive headache
On Mon, Jan 28, 2013 at 5:43 PM, Bob Hutchison hutch-li...@recursive.cawrote: Now, this is how I got caught: it seems to be impossible to have collections of things with a common type class if they have different types. How is it that I've written that many lines of code in Haskell and I'm just noticing this now? (If I wasn't so annoyed, I'd look for something clever to reflect how loc count obviously doesn't mean much… but clever seems to be beyond me today). Is this true? Are there any GHC extensions that will let me around this? I just encountered this recently myself. There is a GADT extension [1][2] that may help. The greater abstraction appears to lie in existential types [3]. That being said, I'm a beginner as well and haven't yet used these extensions. So far I have found that my code is simplified by redefining heterogeneous types in terms of homogeneous functions. If I have a class that implements common methods, I will reorganize lists by common function types rather than by class. Cheers, Darren --- [1] http://www.haskell.org/haskellwiki/GADT [2] http://www.haskell.org/haskellwiki/GADTs_for_dummies [3] http://www.haskell.org/haskellwiki/Existential_type ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Leksah 0.13.1.1 (a bit experimental)
Thank you kindly for this release! System-wide package metadata is working with my platform install now. :) Cheers, d On Sun, Jan 6, 2013 at 9:34 PM, Hamish Mackenzie hamish.k.macken...@gmail.com wrote: I fixed some annoying issues with 0.13.1.0 and added Panes-HLint. OS X (using Gtk3) - Choose the version that matches your installed GHC http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.dmg (probable needs OS X 10.7) Windows (still Gtk2) Choose the version that matches your installed GHC http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.exe On 6 Jan 2013, at 15:16, Hamish Mackenzie hamish.k.macken...@gmail.com wrote: This has mostly bug fixes, GHC 7.4.2, GHC 7.6.1 and Gtk3 support. I have not uploaded it to Hackage as it uses Gtk2Hs patches that are not in Hackage. New features include View-Dark (OS X only) and View-Fullscreen. Linux - Follow the steps in the .travis.yml file... https://github.com/leksah/leksah/blob/master/.travis.yml Should go something like this... https://travis-ci.org/leksah/leksah ___ 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] Cabal failures...
Why not? Either way, I am chiming in as a programmer of many years. Unless using osx I stick with windows to avoid half-day forays into nettling technical issues that are not related to the work I am paid to perform. I would love for Haskell to work better there. On Nov 20, 2012 5:21 PM, Johan Tibell johan.tib...@gmail.com wrote: On Tue, Nov 20, 2012 at 5:14 PM, Albert Y. C. Lai tre...@vex.net wrote: On 12-11-20 05:37 PM, Gregory Guthrie wrote: No; the first sentence says that someone else had reported that testing on Windows was hard to do because of (a perceived) lack of access to Windows by Haskell developers... The implication is that Haskell developers (only/mainly) use *nix. I commented that if true this lack of Windows testing could limit the availability of Haskell to the largest market share of users. Clearly, since 90% of computers have Windows, it should be trivial to find one to test on, if a programmer wants to. Surely every programmer is surrounded by Windows-using family and friends? (Perhaps to the programmer's dismay, too, because the perpetual I've got a virus again, can you help? is so annoying?) We are not talking about BeOS. Therefore, if programmers do not test on Windows, it is because they do not want to. This logic is flawed. More than 90% of computers having Windows doesn't imply that 90% of all computers in a given household runs Windows. What's the probability that your household has a Windows computer if you're a programmer that don't live with your parents? What if that programmer is an open source contributor. Surely not 90%. ___ 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] code length in Haskell, a comparison
I find myself wondering where Rebol would stand in this. On Nov 19, 2012 8:35 PM, KC kc1...@gmail.com wrote: I am leery of code comparisons (but not Timothy Leary of them). Clojure being a JVM language has the advantage of the massive Java class libraries. If Haskell could tie in fairly seamlessly to the Java class libraries ... If more developers learned the need for finer grained abstraction ... On Mon, Nov 19, 2012 at 7:55 PM, Gregory Guthrie guth...@mum.edu wrote: There is some interesting data in the article at: Code Length Measured in 14 Languages http://blog.wolfram.com/2012/11/14/code-length-measured-in-14-languages/ basically comparing program lengths in various languages, and some ensuing discussion of how this relates to language expressiveness, etc. (He does all of his analysis in Mathematica, which is the goal of the article.) It is interesting to see how well Haskell showed in the data; and it would also be interesting to see how well it could replicate the analysis example which was a nice example of web data scraping! The data is the length of a series of programs written in a number of languages (data from: http://rosettacode.org/wiki/Rosetta_Code). (The columns don't map well to text only, Haskell column marked with (Why doesn't this list support HTML?)). See nicer version at: http://pastehtml.com/view/ciy7woohv.rtxt The average for Haskell of 1.89 means that on the average the same program in Haskell takes ~2x in the other languages. Given the correlation of size to clarity, complexity, effort, and errors, this is a good thing! :-) Massive Snip! Overall Ranking: Clojure 0.41 Haskell 0.83 R0.85 MATLAB 1.14 JavaScript 1.27 Ruby 1.36 Common Lisp 1.56 Python 1.61 C++ 1.68 C# 1.85 Pascal 1.86 Fortran 2.33 C++ 2.58 C4.09 --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Regards, KC ___ 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] ANNOUNCE: Sylvia, a lambda calculus visualizer
On Wed, Sep 26, 2012 at 11:51 PM, Chris Wong chrisyco+haskell-c...@gmail.com wrote: Hello all Some of you in the audience may have read Dave Keenan's paper, [To Dissect a Mockingbird][]. A subset of that may have wondered if it was possible to generate those pretty pictures programmatically. For that subset, I can answer to you -- yes, yes you can. [To Dissect a Mockingbird]: http://dkeenan.com/Lambda/ Sylvia is a lambda calculus visualizer. It takes in an expression in the untyped lambda calculus and spits out a pretty picture. This is still in very early alpha, but it renders a fair number of combinators correctly. I plan to add animated reduction (once I figure out how to do it), and eventually develop this into a sandbox game of some sort. I'm hoping to get some comments and ideas on how I can take it from here. Obligatory links Hackage: http://hackage.haskell.org/package/sylvia Source: https://github.com/lfairy/sylvia Documentation: https://github.com/lfairy/sylvia/wiki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe This is actually a lot of fun, thanks for sharing! I am looking forward to the animated reductions. :) Cheers, Darren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
