June 2010 - Haskell-Cafe

dirs in Emacs/Vim in Cabal
by Chris BROWN 01 Jul '10

01 Jul '10

Dear Haskellers, I am in the process of creating a cabal HaRe and I have run into a minor problem. I have an emacs and a vim script that HaRe uses to invoke the refactorer from the two editors. In those scripts, I point HaRe to a directory containing some libraries it needs to chase the imports of the modules. Cabal installs these libraries as data files into whatever prefix the user requests at install time. However, the problem I have is that it then requires a manual user intervention to manually configure emacs/vim to point to this new directory in the 'customizable' panel of HaRe. My question is: Is it possible to allow the emacs/vim scripts that I have know where this directory is automatically? I hope someone can help, Kindest regards, Chris Brown.

2 1

ANNOUNCE: HaRe, the Haskell Refactorer 0.6
by Chris BROWN 30 Jun '10

30 Jun '10

Dear Haskellers, As part of our project on Refactoring Functional Programs http://www.cs.kent.ac.uk/projects/refactor-fp/ we are pleased to announce the availability of HaRe 0.6 (also known as HaRe 28/06/2010), a snapshot of our Haskell Refactorer prototype. Apart from bug-fixes, there are major changes since HaRe 0.5 and HaRe 0.4: A number of new refactorings have been added to HaRe. Some of these include: Adding and removing fields and constructors to data-type definitions, folding and unfolding against as-patterns, merging and splitting, converting between let and where constructs, introduce pattern matching, generative folding, and a clone detection and elimination tool. We have evolved the ongoing architecture of HaRe and derived an API (documented using Haddock) for program analysis and transformation. This allows HaRe to serve as a framework for end-users to build their own refactorings or just program transformations (or analyses). HaRe is available to download directly from here: http://www.cs.kent.ac.uk/projects/refactor-fp/hare/HaRe_28062010.tar.gz You can get HaRe 0.6 and the documentation about how to build your own refactorings via: http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Please see the README.txt for build/use instructions and known issues, and let us know about any problems, bugs, suggestions or additional platforms you can confirm as working. You will need: 1. ghc-6.12.1 2. hint-0.3.2.3 (available from cabal) 3. unix/gnu tools (or cygwin tools, if on windows) 4. vim or emacs (we've tested with gvim 6.2 and with emacs 21.4) 5. If you intend on running the test suite, HUnit-1.0. Happy Refactoring! The HaRe Team (Chris Brown, Huiqing Li, Simon Thompson) Project email: refactor-fp at kent.ac.uk<http://www.haskell.org/mailman/listinfo/haskell> Background: Refactoring is the process of changing the structure of programs without changing their functionality, i.e., refactorings are meaning-preserving program transformations that implement design changes. For more details about refactoring, about our project and for background on HaRe, see our project pages. HaRe - the Haskell Refactorer: HaRe is our prototype tool supporting a collection of refactorings for Haskell 98 (see README.txt for known issues and limitations). It is implemented as a separate refactoring engine (on top of Programatica's Haskell frontend and Strafunski's generic traversal strategy library), with small scripting frontends that call this engine from either Vim or Emacs. Currently supported refactorings: Introduce Pattern Match : place cursor over pattern variable Introduce Sub pattern : place cursor over pattern variable Introduce Case Expression : place cursor over pattern variable Generative Fold : highlight expression to fold. Must have equation in comment directly before definition of highlighted expression. Clone Analysis : select from menu Clone Extraction : highlight clone from the clone class to extract, follow step-by-step instructions. Converting Let to Where : place cursor at start of identifier whose definition is to be moved Converting Where to Let : place cursor at start of identifier whose definition is to be moved. create type signatures : select from menu remove redundant declarations : highlight definition to clean up add constructor to data type : place cursor at start of data type, you'll be prompted to add the new Constructor name, followed by any Type parameters as a complete string Split a tuple : place cursor at start of top level definition that returns a tuple. Slicing based on a subexpression : highlight sub-expression to extract. Instantiate a general pattern : select a function equation and enter the new instances for each pattern in the argument set. Extract an expression : highlight an expression within a definition Convert data type to newtype : place cursor at start of data type add definition to merge : place cursor at start of definition that is to be merged merge definitions : use "add definition for merge" for each definition to be merged. then choose merge definitions from menu. fold function definition : highlight function equation to fold against. fold constant definition : highlight constant equation to fold against. convert pattern to an as pattern : highlight pattern to convert. unfold references to as patterns : place cursor over as pattern name. remove field from a data type : place cursor at start of field to remove. add field to data type : place cursor over start of constructor. enter new field name. add debug information : add trace calls to function by placing cursor at the start of the function to trace rename : place cursor at start of identifier to be renamed, you'll be prompted for a new name Lift def to top level : place cursor at start of identifier whose definition is to be moved Lift def one level : place cursor at start of identifier whose definition is to be moved Demote : place cursor at start of identifier whose definition is to be moved Introduce new def : highlight expression to be named, you'll be prompted for a new name Unfold def : place cursor at start of identifier where its definition is to be unfolded Generalise def : place cursor at start of identifier where its definition is to be unfolded Remove def : place cursor at start of identifier whose definition is to be removed Duplicate def : place cursor at start of identifier whose definition is to be duplicated, you'll be prompted for a new name Add one parameter : place cursor at start of identifier whose definition is to be modified, you'll be prompted for a new name rm one parameter : place cursor in formal parameter which is to be removed Move def to another module : place cursor at start of the identifier whose definition is to be moved, you'll be prompted for the module name Clean imports : cursor position does not matter, just choose the command from the refactor menu Make import explicit : place cursor at the start of the module name in the import declaration Add to export : place cursor at start of the identifier which is to be added to the export Remove from export : place cursor at start of the entry to be removed in the export list From concrete to abstract data type: place cursor at start of the data type name Add field names : place cursor at start of the data type name Add discriminators : place cursor at start of the data type name Add constructors : place cursor at start of the data type name Eliminate nested patterns : place cursor at start of the data type name Eliminate patterns : place cursor at start of the data type name Create an ADT module : place cursor at start of the data type name Eliminate intermediate list: cursor position does not matter, just choose the command from the menu. Caveats (see also README.txt): Please keep in mind that this is a prototype, so we do not recommend to use it on your productions sources just yet. Just play with it to get an idea of tool-supported refactoring in Haskell, and send us your feedback and bug-reports. Our goal is to develop this into a tool that many of you will find indispensable for Haskell development. Regards, The HaRe team.

4 11

zlib or digest package installation
by Daniel Kahlenberg 30 Jun '10

30 Jun '10

Hi, when installing pandoc package, which has digest somewhere in dependencies the usual cabal install stucks because zlib.h is missing, so I explicitly installed zlib package first, then installing digest (can also replace that directly with pandoc here) with the --extra-include-dirs parameter set: Prelude System.Cmd> > rawSystem "cabal" ["install", "digest", "-v3", "--user", "-- > build-log=d:/temp/log/build-$$pkgid-$$compiler-msys.log", "--reinstall", "--data > dir=$$prefix/haskell-pkgdata", "--extra-include-dirs=C:\\Users\\daniel\\AppData\ > \Roaming\\cabal\\zlib-0.5.2.0\\ghc-6.12.1\\include"] Is there something to improve in one of the packages cabal file to overcome the need to explicitly specify the header file locations of already installed packages or is that a consequence of not installing them as developer packages simply, so i. e. to have the header file zlib.h at the specified location is more a bonus to have in that situation? Greetz Daniel

3 2

Haskell Bangalore
by C K Kashyap 30 Jun '10

30 Jun '10

Hi, I was wondering if it would be a good idea for the folks interested in Haskell in Bangalore to get together. Especially if there are folks at EGL, perhaps we could just meet up at pyramid. I've been trying to learn Haskell for a while and currently am trying to work through SPJ's "implementation of Functional Programming languages". It would be good to bounce off ideas (in person) with like minded folks. -- Regards, Kashyap

4 3

Kate: Haskell and Literate Haskell syntax files
by Nicolas Wu 30 Jun '10

30 Jun '10

Dear all, I've just finished implementing a complete rewrite of the Haskell and Literate Haskell files for Kate. This improves the previous version in many ways: * Operators are now supported (++, !, >>=, and any other combination of legal operator characters) * Special symbols are recognised (=>, <-, ->, ::, ..) * Unicode support for →, ←, ∷, ‥,⇒, ∀, ∃ * Support for qualified module functions (List.sort, etc) * Support for qualified module types * Refactored Literate Haskell using IncludeRules * Support for literate code (using > and \begin{code} \end{code}) * Support for literate specifications (using < and \begin{spec} \end{spec}) You can find the most recent snapshot in my github repository [1], and examples of highlighted syntax using these files at my website [2]. Please let me know if there are any further improvements you can think of, Nick [1] http://github.com/zenzike/kate-haskell [2] http://zenzike.com

1 0

Re: [Haskell] Second draft of the Haskell 2010 report available
by Henk-Jan van Tuyl 30 Jun '10

30 Jun '10

On Tue, 29 Jun 2010 17:01:54 +0200, Simon Marlow <marlowsd(a)gmail.com> wrote: > Comments on the draft report are welcome, before I finalise this and > sign off on Haskell 2010. Subsection 12.3, "Language extensions", mentions the FFI as a language extension, but FFI is now part of the standerd; the same goes for the "extensions" mentioned at the end of the subsection. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

2 1

whine and solution about programmers not respecting documentations
by Albert Y.C.Lai 29 Jun '10

29 Jun '10

Some docs are in a miserable state of being incomplete. And then some programmers are in a miserable state of not respecting docs when the docs are complete. Why should anyone expect deleteBy (>=) 5 [0..10] to accomplish anything meaningful, if he/she respects the written docs? Today someone on #haskell expected it to accomplish something meaningful, even something mind-reading. The said person has been around for more than a year, not eligible for the "newbie" excuse. The said person is just the tip of an iceberg. The doc of deleteBy states: "The deleteBy function behaves like delete, but takes a user-supplied equality predicate." A precondition is that the user-supplied predicate is an equality predicate. (>=) is not an equality predicate, be it in the layperson sense of "it isn't analogous to (==)" or the mathematical sense of "it isn't an equivalence relation". If you respect the precondition or the authors of the doc, you should just never use deleteBy (>=) 5 [0..10], much less expect any meaningful result. I propose this solution: For each of deleteBy, groupBy, unionBy... we can usually conceive at least two implementations, behaving pretty much the same (answer, speed, space) when given an equivalence relation (modulo some rare concern when the equivalence relation has assymetric strictness properties), but behaving different when not, and their code sizes are pretty much the same. With more imagination and allowing some code bloat, perhaps we can conceieve more implementations. But two suffices, really. I propose that at each minor version of base, someone picks an implementation randomly. Here is a more radical, less labour-intensive solution, if you don't mind a judicious, correctness-preserving use of unsafePerformIO: at the first invocation of the process lifetime, pick an implementation randomly. The result frustrates people who disrespect the docs. My purpose is exactly that. The goal is to give people an incentive to not disrepect the docs. (If you think this is a nasty "stick, not carrot" incentive, on first thought I would agree. On second thought, it is not adding a stick, it is just removing a carrot. Programmer's carrot means his/her code "works" consistently. When deleteBy (>=) "works" consistently, you are giving out undeserved free carrots --- incentive to write more wrong code. I am proposing to remove undeserved free carrots.)

12 22

Call for comments: neither package
by Michael Snoyman 29 Jun '10

29 Jun '10

Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither

6 8

specifying package name in ghci import?
by Michael Vanier 29 Jun '10

29 Jun '10

Hi, Quick question about ghci: when I do this at the prompt: ghci> :m +Control.Monad.Cont I get Ambiguous module name `Control.Monad.Cont': it was found in multiple packages: mtl-1.1.0.2 monads-fd-0.0.0.1 Is there any way to fix this from within ghci (i.e. not involving mucking with ghc-pkg)? What I have in mind might be e.g. ghci> :m + "mtl" Control.Monad.Cont or something similar. Thanks, Mike

2 1

Re: [Haskell-cafe] Call for comments: neither package
by Antoine Latter 29 Jun '10

29 Jun '10

It looks like good work, but I would be hesitent about depending on a package which pulled in both mtl and tranformers. Maybe that's just superstition - I haven't tried it. Antoine On Jun 28, 2010 5:51 PM, "Michael Snoyman" <michael(a)snoyman.com> wrote: Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

3 4