- Haskell - Haskell.org

ANNOUNCE: SourceGraph 0.5.2.0
by Ivan Lazar Miljenovic 02 Oct '09

02 Oct '09

Yes, this is yet another SourceGraph announcement, this time for version 0.5.2.0 [1]. [1] http://hackage.haskell.org/package/SourceGraph-0.5.2.0 The changes in this release are as follows: * Shift overall analysis to the top and per-module analysis to the end, as suggested by Duncan Coutts. * Graph drawing fixups: instances are now drawn correctly, and the module graph now has modules located in the correct directory. * Improve some graph drawing aspects (node margins, colours for module graphs, etc.). -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

New TMR editor
by Wouter Swierstra 01 Oct '09

01 Oct '09

Dear all, After several years at the helm, I've decided to step down as editor of the Monad.Reader. I am happy to announce that Brent Yorgey will take over my role as editor. I'd like to take this opportunity to thank Brent for helping to keep the Monad.Reader alive. I'm sure he'll do a fantastic job. Finally, I'd like to thank all the people who have contributed to the Monad.Reader over the last few years – you guys have made this publication, and my job as an editor, so much fun. All the best, Wouter

4 3

Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1
by Jonathan Daugherty 01 Oct '09

01 Oct '09

# Nice. This sure beats how I've been doing it in the past. Out of # curiousity, can you talk about what you're doing with it? Yeah, I'd like to use this to write an administration tool for my "dbmigrations" package. I started doing it in hscurses and decided I needed to be able to live with the code (and the process of writing it), so now I'm off in the weeds working on a UI library. :) On the way to work this morning I started working on a Scrollable class to generalize the List's scrolling capabilities and support scrolling of any widget rendered in constrained space. We'll see how that goes.. -- Jonathan Daugherty

1 0

Re: [Haskell-cafe] ANNOUNCE: vty-ui 0.1
by Jonathan Daugherty 01 Oct '09

01 Oct '09

> Am I correct in saying that the collection of widgets contains a > single widget type so far? ;-) Technically, four; vertical and horizontal boxes, a text string widget, and the List you mentioned. It only has a few types because I was just releasing early. I'm going to start using this in a project and add things as needed. > The list widget looks useful, does it handle multi-line strings (i.e. > strings with a "\n")? It currently only handles single-line strings but I'd actually like to generalize it to take a list of Widget instances (possibly with restrictions). -- Jonathan Daugherty

1 0

Testing polymorphic properties with QuickCheck
by Jean-Philippe Bernardy 01 Oct '09

01 Oct '09

----------------------------------------------------------------------- This message is a literate Haskell file, hence: > {-# LANGUAGE GADTs#-} -- a matter of style only > import Control.Monad.State hiding (mapM) > import Control.Applicative > import Data.Traversable > import Data.Foldable > import Data.Monoid > import Test.QuickCheck --------------------------------------------------------------------- Hello everyone, This message is my answer a common question coming from QuickCheck users: "How do I use QuickCheck on polymorphic properties?". The answer also applies to all test generators for Haskell (SmallCheck, ...). Consider the following polymorphic property: > prop_reverse_append :: Eq a => [a] -> [a] -> Bool > prop_reverse_append xs ys = reverse (xs ++ ys) == reverse xs ++ reverse ys Running QuickCheck on that property is possible, but... < quickCheck prop_reverse_append < ... 100 tests passed! Even though the property is false, it passes QuickCheck, because GHC has defaulted |a| to |()|, and the unit type cannot capture any difference in the content of the lists. The usual QuickCheck answer is to force using |Int| for |a|: > prop_reverse_append_Int :: [Int] -> [Int] -> Bool > prop_reverse_append_Int = prop_reverse_append While sound, this is highly unsatisfactory: 1. Many tests will be redundant. For example, if |prop_reverse_append [1] [2]| holds, then |prop_reverse_append [a] [b]| holds for any choice of a and b. So if the first test passes, it is useless to test |prop_reverse_append [1] [3]|, |prop_reverse_append [1] [4]|, etc. Unfortunately, QuickCheck does not realize this and may perform all these tests. 2. Some tests will be weaker than necessary. For example, testing |prop_reverse_append| with elements that are equal to each other is a waste: this might only hide bugs in the implementation, as when we used the unit type. In fact, one should test |prop_reverse_append| only once for each length of the input lists, and the elements in the lists should all be different from each other. Note that this observation applies not only to |prop_reverse_append|, but to all properties of the same type. In the remainder I will show how to generalize the argument, and give a systematic method to compute a monomorphic property which is as strong as a polymorphic one. This is done only by looking at the type of the property. The basic idea is to identify all the ways that the property can construct elements of the polymorphic type (say |a|), and represent this in a datatype. For example, the type |Eq a => [a] -> [a] -> Bool| tells us that the property can construct an element by picking any element from the first or the second list. This yields the datatype: > data A where > XsElement :: Int -> A > YsElement :: Int -> A > deriving (Eq, Show) Which we can substitute for the type variable. The gain comes from the fact that we also know how to fill in the input lists, yielding the monomorphic property: > prop_reverse_append_Mono :: [()] -> [()] -> Bool > prop_reverse_append_Mono xs ys > = prop_reverse_append (combine XsElement xs) (combine YsElement ys) where |combine f| replaces the |i|:th element in the list with |f i|. Generalization 1 ---------------- It is worth noting that "observations", that is, elements which do not return any |a|, do not play any role in the monomorphisation process. This is illustrated in the next example, about testing a filter-like function: > prop_filter :: Eq a => (a -> Bool) -> [a] -> Bool > prop_filter = error "add your definition here" > prop_filter_Mono :: (A -> Bool) -> [()] -> Bool > prop_filter_Mono p xs = prop_filter p (combine XsElement xs) Generalization 2 ---------------- Arguments which return |a| are turned into constructors of the monomorphic datatype, and then fixed. > prop_iterate :: Eq a => a -> (a -> a) -> Bool > prop_iterate = error "add your definition here" > data B where > Initial :: B > Next :: B -> B > deriving (Eq, Show) > prop_iterate_Mono = prop_iterate Initial Next Note that the more polymorphic the function is, the more the arguments become fixed. In the above case, all quantifiers disappear. Notes ----- Note that the technique works only for first order polymorphic arguments. We do not have a generalization for higher order ones. Also, extra care must be taken in the presence of type classes constraints: they may "hide" constructors. More examples and applications, together with the theory behind all this can be found in a paper I co-authored with Patrik Jansson and Koen Claessen: http://publications.lib.chalmers.se/cpl/record/index.xsql?pubid=99387 or direct link to the pdf: http://www.cse.chalmers.se/~bernardy/PolyTest.pdf Cheers, Jean-Philippe Bernardy. PS. Definition of |combine| ----------------------- > combine :: Traversable t => (Int -> a) -> t () -> t a > combine f t = evalState (Data.Traversable.mapM getValue t) 0 > where getValue _ = do i <- get > put (i+1) > return (f i) Example: < combine Just (Node (Leaf () ) () (Node (Leaf () ) () (Leaf ()))) < == (Node (Leaf (Just 0)) (Just 1) (Node (Leaf (Just 2)) (Just 3) (Leaf (Just 4)))) > data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a) deriving Show > instance Traversable Tree where > traverse f Empty = pure Empty > traverse f (Leaf x) = Leaf <$> f x > traverse f (Node l k r) = Node <$> traverse f l <*> f k <*> traverse f r > instance Foldable Tree where foldMap = foldMapDefault > instance Functor Tree where fmap = fmapDefault

1 0

ANNOUNCE: usb-0.1
by Bas van Dijk 01 Oct '09

01 Oct '09

Hello, I would like to announce the release of usb-0.1, a Haskell library for communicating with USB devices from userspace. usb is implemented as a high-level wrapper around Maurício C. Antunes' bindings-libusb which is a binding to the C library: libusb-1.* ( http://libusb.org ). All functionality from libusb is provided except for asynchronous IO. I'm still thinking about if and how I should add that. As usual, install usb using cabal: > cabal install usb Or download and install it manually from hackage: http://hackage.haskell.org/package/usb-0.1 Or get the development source using darcs: darcs get http://code.haskell.org/~basvandijk/code/usb Comments and patches are highly welcome. Note that this is the first release, so expect API changes in the future. Note that my brother uploaded 'usb-id-database' to hackage. A small library for associating usb identifiers like vendor, product, class, subclass or prototcol identifiers with their respective names and vice versa: http://hackage.haskell.org/package/usb-id-database This can be helpful when trying to find the right device to operate. In a short while, the package 'ls-usb' will be released. This is a simple program for showing all the usb devices currently attached to your system. It's a nice demonstration on how to use the library. regards, Bas

2 1

ANNOUNCE: SourceGraph 0.5.1.0
by Ivan Lazar Miljenovic 01 Oct '09

01 Oct '09

This is an updated version of my graph-theoretic static analysis tool for Haskell, SourceGraph. This version is available from http://hackage.haskell.org/package/SourceGraph-0.5.1.0 (now with docs on the Hackage page!). This version provides the ability to pass in a single Haskell source file rather than a Cabal file for analysis purposes. Note that the Cabal version is still preferred as it is better able to determine the project name and which modules are exported: when using a single source file, that file is presumed to be the only exported module and its module name is used as the overall project name. This feature was requested by Curt Sampson. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

ANNOUNCE: vty-ui 0.1
by Jonathan Daugherty 01 Oct '09

01 Oct '09

vty-ui is: An extensible library of user interface widgets for composing and laying out Vty user interfaces. This library provides a collection of widgets and a type class for rendering widgets to Vty Images. Get it from Hackage: http://hackage.haskell.org/package/vty-ui Or get the source with darcs: http://repos.codevine.org/vty-ui This package is motivated by the desire to create terminal user interfaces easily without having to worry about doing all of the structural book-keeping that so often comes with such an approach. Future releases will probably include more widget composition tools, more interesting widgets, and helper code for building interesting things. For now, the library contains some basic widgets (including horizontal and vertical box layout) and a List widget. See the vty-ui-demo program and source for an interactive demonstration of the available widgets. Future releases may also address performance, as I honestly don't have a very clear idea of how well my approach is going to scale for non-trivial interfaces. Please don't hesitate to send patches, feedback, and criticism directly to me at drcygnus AT gmail DOT com. Lastly, thanks a ton to the authors of Vty. It's a pleasure to use. Enjoy! -- Jonathan Daugherty

2 1

(Deadline extended to October 5th) APLAS 2009 Call for Posters
by Kiminori Matsuzaki 01 Oct '09

01 Oct '09

CALL FOR POSTER PRESENTATIONS The Seventh ASIAN Symposium on Programming Languages and Systems (APLAS 2009) December 14 - 16, 2009 Seoul National University, Seoul, Korea http://ropas.snu.ac.kr/aplas09/ FYI: The list of accepted papers is now on the webpage. FYI: APLAS 2009 will be co-located with the 13th Annual Asian Computing Science Conference (ASIAN 2009). APLAS 2009 will include a poster session during the conference. The session aims to give students and researchers an opportunity to present their research to the community, and to get responses from other researchers. SCOPE: Poster presentations describing research advances or experience with non-trivial systems are sought in all areas of programming languages and systems, including (but not limited to): - semantics, logics, foundational theory - type systems, language design - program analysis, optimization, transformation - software security, safety, verification - compiler systems, interpreters, abstract machines - domain-specific languages and systems - programming tools and environments FORMAT: A space of A1 paper size (594 mm wide and 841 mm high) will be provided for each presentation. If you need more space, contact the poster chair (kmatsu AT ipl.t.u-tokyo.ac.jp). To prepare a good poster, search the Web for "poster presentation" and you will find many useful resources. SUBMISSION: Each presenter should e-mail a 1-2 page abstract in PDF or PostScript to the poster chair (Kiminori Matsuzaki; kmatsu AT ipl.t.u-tokyo.ac.jp) by October 5th 2009. The abstract should include the title, author(s), affiliation(s), and summary of the work, and a LaTeX-template will be available at "http://ropas.snu.ac.kr/aplas09/aplas_poster_template.tex". The program of the poster session will be announced by October 10th, 2009. We hope to accommodate every poster, but may restrict presentations (based on relevance and interest to the community) due to space constraints. IMPORTANT DATES: - 1-2 page abstract October 5th, 2009 (Extended) - Notification October 10, 2009 - Conference December 14 - 16, 2009 CONTACT: For questions or requests, please contact the APLAS 2009 poster chair, Kiminori Matsuzaki (kmatsu AT ipl.t.u-tokyo.ac.jp). -- Kiminori MATSUZAKI, Ph.D. Email: kmatsu(a)ipl.t.u-tokyo.ac.jp

1 0

ANNOUNCE: SourceGraph-0.5.0.0
by Ivan Lazar Miljenovic 29 Sep '09

29 Sep '09

SourceGraph [1] is a tool to statically analyse your Haskell code by applying graph-theoretic techniques on the call graph. It utilised the Graphalyze [2] library to do so, both of which were originally written as part of my Honours thesis last year [3]. [1] http://hackage.haskell.org/package/SourceGraph [2] http://hackage.haskell.org/package/Graphalyze [3] http://ivanmiljenovic.wordpress.com/2008/11/03/graph-theoretic-analysis-of-… I have been meaning to update SourceGraph since last year, but was waiting for improvements to the graphviz [4] library first. Now that these are done and I have fewer excuses, I've started to improve upon it. [4] http://hackage.haskell.org/package/graphviz When I first released SourceGraph last year, several people (e.g. Gwern) wanted support for CPP and command-line options. Unfortunately, I haven't yet gotten around to that; what I have done is added support for type classes and data structures, something I originally said I wasn't going to do. This support isn't perfect, especially when dealing with type classes from outside the scope of the code base, but in most cases works (except that the virtual instance functions don't always get positioned in the correct spots for some reason). The produced graphs are now also much prettier, with various colours and shapes being used. The useful features that SourceGraph offers include: * Visualisation of each module, the relations between modules and the entire code base. * Finds functions that are exported from a module that isn't in exposed in the .cabal file. * Alternate module splits. Please note that SourceGraph is _not_ a refactoring tool: it is designed to give you the programmer more information about what is in your code. I'd appreciate it if people could give SourceGraph a whirl and at least check how well the conversion from Haskell code to the graph is, as I'm not that sure how well I've converted haskel-src-ext's [5] internal state to SourceGraph's state. Please note that there are already various aspects that I know don't work properly; these can be found in the ParsingProblems.txt file (KnownProblems.txt contains other non-parsing problems that I'm aware of). In particular, TH, etc. aren't supported. [5] http://hackage.haskell.org/package/haskell-src-exts-1.1.4 To use SourceGraph after it's been installed, at a prompt do the following: > SourceGraph path/to/project.cabal The resulting report will then be found in a directory called "SourceGraph" in the same directory as the cabal file. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

2 3