June 2010 - Haskell - Haskell.org

LOPSTR/PPDP 2010 Early Registration Deadline: June 21
by Temur Kutsia 15 Jun '10

15 Jun '10

[Apologize for multiple copies] ==================================================================== *** CALL FOR PARTICIPATION *** LOPSTR 2010 20th International Symposium on Logic-Based Program Synthesis and Transformation http://www.risc.jku.at/conferences/lopstr2010/ July 23-25, 2010 PPDP 2010 12th International ACM SIGPLAN Symposium on Principles and Practice of Declarative Programming http://www.risc.jku.at/conferences/ppdp2010/ July 26-28, 2010 Hagenberg, Austria ==================================================================== IMPORTANT INFORMATION Early registration deadline (for both conferences): June 21, 2010 -------------------------------------------------------------------- LOPSTR 2010 INVITED SPEAKERS: - Bruno Buchberger (RISC, Johannes Kepler University Linz, Austria) - Olivier Danvy (University of Aarhus, Denmark) - Johann Schumann (RIACS/NASA Ames Research Center, USA) LOPSTR 2010 PROGRAM: http://www.risc.jku.at/conferences/lopstr2010/program.html -------------------------------------------------------------------- PPDP 2010 INVITED SPEAKERS: - Maria Paola Bonacina (University of Verona, Italy) - Sumit Gulwani (Microsoft Research) PPDP 2010 PROGRAM: http://www.risc.jku.at/conferences/ppdp2010/program.html --------------------------------------------------------------------

1 0

Possible solution to the FGL naming/compatability issue
by Ivan Miljenovic 15 Jun '10

15 Jun '10

Last night (AEST), Edward Kmett semi-convinced (in the sense that I'm not sure whether his examples are really those that someone would want/need or just thinking of possible future problems) me that some users may have a need for FGL to keep having explicit graphs with kind * -> * -> *. With his prompting, I may have a possible solution: duplicate the classes. We would have an InductiveGraph class (call it the parametric version) that requires graphs to have kind * -> * -> *, and then another class (call it the extended version) that removes this restriction. The parametric version would be closer to a drop-in replacement to the current FGL setup (see below for more details) and the extended one would provide all of the functionality requested, with some kind of semi-automatic lifting/unlifting for graph types that are instances of both. Now, this parametric version will still not be a drop-in for the current FGL, for several reasons: * I want to have one overall InductiveGraph class rather than two separate Graph and DynGraph classes * Context will still be an actual data type rather than a 4-tuple and LEdge would be come (Edge, Label) rather than (Node, Node, Label) [I'm still debating whether to keep Edge as a datatype as needed for the Type Familiy version or if it should just be a tuple). * Some function names will be changed (e.g. fromContexts rather than buildGr). * The Data.Graph.Inductive.Query stuff is going to be split out into its own separate library, the Data.Graph.Inductive.Graphviz stuff is going to be removed, etc. * With the removal of the sub-libraries, I'm seriously considering moving the class definitions from Data.Graph.Inductive.Graph to just Data.Graph.Inductive. There are also some caveats/design decisions with this solution: * There will obviously be duplication. With that said, do we try to make the two classes semi-drop-ins (same class name, methods, etc. but with different types) or think up new method names for the extended version? * How transparently can/will we make the lifting/unlifting? * If we want the parametric version to still have the ability to specify a custom node type, then it will still need either MPTCs + fundeps or Type Families (i.e. extensions); otherwise we stick with the current "type Node = Int" (or maybe replace it with some opaque abstract type down the track as suggested by Heinrich Apfelmus). * If we want to provide the ability to restrict the types of the labels in the parametric version, then we would need MPTCs (Type Families won't work since the label types won't be part of the class definition then unless we use MPTCs, and in that case there's not really any point in using Type Families). Thus we once again need extensions. * My semi-end goal is to build a proper hierarchy of graph types/libraries, such that the only thing FGL provides is the extra aspect/concept of inductive graphs. If we extend this parametric vs extended split down to the set of base graph classes, then we're going to have even more duplication and this kind of setup (where "Foo depends on Bar" means "class (Bar a) => Foo a where ..."): - fgl-parametric will depend on graph-parametric - fgl-extended will depend on graph-extended - There will be lifting/unlifting between graph-parametric and graph-extended - There will be lifting/unlifting between fgl-parametric and fgl-extended As such, an FGL graph of kind * -> * -> * being treated as an extended graph will have two possible ways (depending on the function in question) will have two graph hierarchies two choose from, and two possible points at which it can be lifted/unlifted (at the graph level and the fgl level). This could get confusing. That said, there is one other benefit of this parametric vs extended split: the types of the mapping functions in http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs won't be as weird... So, what are people's thoughts/opinions on this kind of setup? Note that I haven't started coding it yet, so I'm not sure how well it will work in practice... -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

VSTTE 2010: Final Call for Poster Session Submissions
by Gudmund Grov 14 Jun '10

14 Jun '10

*** Apologies for multiple copies *** ************************ *** Final Call for POSTERS *** 3rd International Conference on Verified Software: Theories, Tools, and Experiments (VSTTE 2010) Edinburgh, Scotland August 16th-19th, 2010 http://www.macs.hw.ac.uk/vstte10 POSTER SESSION The complementary themes of Theories, Tools and Experiments makes VSTTE an unique conference. Through the introduction of a POSTER session at VSTTE 2010, we are aiming to widen the body of researchers that are involved in the Verified Software Initiative (VSI) and its related Challenges (more details on VSTTE & VSI are provided below). Limited financial support will be available if necessary to enable attendance of both MSc and PhD students whose posters are accepted. Specifically, we aim to attract students who are already engaged in theories or tools or experiments relevant to verification; and give them an opportunity to meet other students and researchers engaged in complementary experiments or theories or tools. Note that the POSTER session is open to all researchers, not just students. With regards to submissions, we require the following: 1. 1-page abstract of your research 2. Poster OR a poster plan 3. For students, a supporting statement from your supervisor Submissions should be sent electronically to vstte10(a)macs.hw.ac.uk. The timetable for POSTER authors is as follows: JUNE 18: Submission of abstract & poster (plan) deadline JUNE 30: Notification of decision JULY 31: Camera-ready abstract deadline AUGUST 17: Poster session Note that a collection of abstracts for the accepted posters will be distributed at the conference. Poster authors will be expected to bring their poster with them to the conference. Details of the size of the final posters will be provided in due course. Financial support will be allocated on a case-by-case basis, and will support around 30 partial/fully funded places, including 10 SICSA PhD funded places. If you have any queries, please direct them to vstte10(a)macs.hw.ac.uk MORE DETAILS ON VSTTE 2010 SPONSORS National Science Foundation (NSF) Engineering and Physical Sciences Research Council (EPSRC) Microsoft Research Scottish Informatics & Computer Science Alliance (SICSA) Altran Praxis Software Systems Engineering Initiative (SSEI) Formal Methods Europe (FME) WHAT IS THE HISTORY OF VSTTE? The Third International Conference on Verified Software: Theories, Tools, and Experiments follows a successful inaugural working conference at Zurich (2005) and a successful conference in Toronto (2008). This conference is part of the Verified Software Initiative (VSI), a fifteen-year, cooperative, international project directed at the scientific challenges of large-scale software verification. VSI also includes UKCRC's Grand Challenge 6, i.e. Dependable Systems Evolution. VSTTE is open to anyone who is interested in participating actively in the VSI effort. SCOPE The goal of this conference is to advance the state of the art in the science and technology of software verification through the interaction of theory development, tool evolution, and experimental validation. Authors are encouraged to submit work in progress, particularly if the work involves collaboration, theory unification, and tool integration. Topics of interest include requirements modeling specification languages specification/verification case-studies formal calculi programming languages language semantics software design methods software testing automatic code generation refinement methodologies type systems computer security verification tools (static analysis, dynamic analysis, model checking, theorem proving, satisfiability) tool integration benchmarks challenge problems integrated verification environments We also encourage researchers to submit challenges in theory, formalization, systems verification, code verification, and applications. Contributions relating to existing challenges will also be welcomed, i.e. * POPLMark (http://tinyurl.com/poplmark) * Tokeneer (http://www.adacore.com/home/products/sparkpro/tokeneer) * POSIX file system (http://tinyurl.com/qyzqk9) * medical devices (http://tinyurl.com/pnztqb) VENUE VSTTE 2010 is being hosted by Heriot-Watt University in Edinburgh. The conference dates coincide with the 2010 Edinburgh International Festival and the Edinburgh Festival Fringe -- collectively the largest annual arts festival on the planet! The technical programme will take place in the Edinburgh Conference Centre (Riccarton campus), where accommodation will be available at very competitive rates for festival time. Social events will be arranged within the city centre, making VSTTE an unique cultural and scholarly event for 2010! INVITED SPEAKERS * Tom Ball (Microsoft Research, Redmond) * Gerwin Klein (National ICT Australia) * Matthew Parkinson (University of Cambridge) WORKSHOPS In addition to the main conference, VSTTE will host two workshops on August 19th: * VS-Theory focuses on theoretical foundations of software verification. Topics range from the difficult and essential study of soundness of delicate proof methods, to the discovery of new specification techniques and proof methods, to dramatic simplification or unification of existing methods, to as yet unknown breakthroughs. * VS-Tools & Experiments focuses on the development of verification tools and their experimental evaluation. Possible topics include interfaces between tools, tool integration platforms, and case studies. The workshops will provide a forum to present new, possibly unfinished work and will also give the opportunity to propose research challenges, which will help form a research agenda for the Verified Software Initiative. Papers must be written in English using Springer LNCS style. The page limit is 10 pages for technical papers and 5 pages for proposals of verification challenges. The proceedings will be published as a technical report. SUMMER SCHOOL There will be a two-day summer-school preceding the main conference on the 14 and 15 August. The summer school will give a broad overview of software verification techniques, addressing both bottom-up and top-down approaches with a strong focus on the formal representation and reasoning themes. The school consists of eight introductory lectures, each concentrating on an unique aspect of one or both of the overall themes. The topics of the lectures include inductive theorem proving; SAT and SMT solving; proof planning and rippling; rely/guarantee conditions; separation logic; operating system verification; formal analysis of security. The following will present at the summer school: * Robert Atkey (University of Strathclyde) & Ewen Maclean (Heriot-Watt University) * Alan Bundy & Lucas Dixon (University of Edinburgh) * Jane Hillston (University of Edinburgh) * Cliff Jones (University of Newcastle) * Gerwin Klein (National ICT Australia) * J Strother Moore (University of Texas at Austin) * Natarajan Shankar (SRI) * Graham Steel (INRIA) The school is intended for PhD students and researchers working within one or both of these themes, however familiarity with any of the techniques is not a prerequisite. All lectures are meant to be introductory. For more information see: http://dream.inf.ed.ac.uk/events/ssfrr-2010/ COMPETITION A verification competition will be held at VSTTE 2010. The challenge is to develop a machine-verified piece of software with respect to a given specification. The competition will be conducted over a 2.5 hour period on some evening of the conference. The problem will be presented with a logical specification and test cases over .5 hours including time for discussion with 2 hours to construct a solution. Each competing team can feature up to three members. You can use any tool or combination of tools as well as libraries, but you cannot modify these tools. You can reinterpret the specification to suit your tools and methods, but you will be judged on the fidelity of your interpretation. The goal is to produce an executable program and a replayable proof that the program meets the specification. It will be possible to code the solution using integers and arrays. The solutions will be judged for soundness (absence of bugs) and completeness (presence of proofs). The three best solutions will be selected and the respective teams will be invited to make presentations at the tools/experiments workshop. You must register a copy of the verification system with the judges prior to the competition with instructions for replaying proofs and running the programs. CONFERENCE CHAIR Andrew Ireland (Heriot-Watt University; A.Ireland(a)hw.ac.uk) PROGRAM CHAIRS Peter O'Hearn (Queen Mary, University of London; ohearn(a)dcs.qmul.ac.uk) Gary T. Leavens (University of Central Florida; leavens(a)eecs.ucf.edu) Sriram Rajamani (Microsoft Research; sriram(a)microsoft.com) WORKSHOP GENERAL CHAIR Peter Mueller (ETH Zurich; peter.mueller(a)inf.ethz.ch) THEORY WORKSHOP CHAIRS David Naumann (Stevens Institute of Technology; dnaumann(a)stevens.edu) Hongseok Yang (Queen Mary, University of London; hyang(a)dcs.qmul.ac.uk) TOOLS & EXPERIMENTS WORKSHOP CHAIRS Rajeev Joshi (NASA JPL; rajeev.joshi(a)jpl.nasa.gov) Tiziana Margaria (Universitat Potsdam; margaria(a)cs.uni-potsdam.de) PUBLICITY CHAIR Gudmund Grov (Edinburgh University; ggrov(a)inf.ed.ac.uk) LOCAL ARRANGEMENT CHAIR Ewen Maclean (Heriot-Watt University; E.A.H.Maclean(a)hw.ac.uk) CONFERENCE PROGRAM COMMITTEE Ahmed Bouajjani Leo Freitas Philippa Gardner John Hatcliff Ranjit Jhala Joseph Kiniry Rustan Leino Xavier Leroy David Naumann Matthew Parkinson Wolfgang Paul Shaz Qadeer Andrey Rybalchenko Augusto Sampaio Zhong Shao Aaron Stump Serdar Tasiran Willem Visser Chin Wei-Ngan Stephanie Weirich Greta Yorsh STEERING COMMITTEE Tony Hoare Jay Misra Natarajan Shankar Jim Woodcock -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Announce: Properties-0.0.2
by Alberto G. Corona 13 Jun '10

13 Jun '10

http://hackage.haskell.org/package/properties-0.0.2 <http://hackage.haskell.org/package/properties-0.0.2>Properties can use QuickCheck properties in the same way than assertions are used, for causal debugging of real programs. It also add an human readable structure for grouping properties for classes or libraries. The properties can then be tested in the instance´s body or in programs as if they were assertions. The main advantage is that the compliance of properties can be done with the complete data range that the real application generates (hopefully, with an pleasant separation of real code and debug code). This is a simple example: stringProperty= [Property <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…> "length" (\(x, y)-> length (x++y)== length x + length y)] main= do let s= "hello " let s2= "world" print $ s++ s2 `verify <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>` stringProperty `with <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>`(s,s2) print "that's all!" It is possible to check quickCheck style properties. The same example with a quickCheck-style property: quickCheckProperty x y= length (x++y)== length x + length y main= do let s= "hello " let s2= "world" print $ s++ s2 `verify <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>` [Property "stringSumLength" $ uncurry quickCheckProperty] `with <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>`(s,s2) print "that's all!" The package include a more sophisticated example. I Hope that this would be useful Alberto

1 0

Workshop on Generic Programming (WGP) 2010 Final Call for papers!
by Bruno Oliveira 13 Jun '10

13 Jun '10

Dear all, This a final reminder that the deadline for WGP submissions is in one week! See the call for papers below: ====================================================================== CALL FOR PAPERS WGP 2010 6th ACM SIGPLAN Workshop on Generic Programming Baltimore, Maryland, US Sunday, September 26th, 2010 http://osl.iu.edu/wgp2010 Collocated with the International Conference on Functional Programming (ICFP 2010) ====================================================================== Goals of the workshop --------------------- Generic programming is about making programs more adaptable by making them more general. Generic programs often embody non-traditional kinds of polymorphism; ordinary programs are obtained from them by suitably instantiating their parameters. In contrast with normal programs, the parameters of a generic program are often quite rich in structure; for example they may be other programs, types or type constructors, class hierarchies, or even programming paradigms. Generic programming techniques have always been of interest, both to practitioners and to theoreticians, and, for at least 20 years, generic programming techniques have been a specific focus of research in the functional and object-oriented programming communities. Generic programming has gradually spread to more and more mainstream languages, and today is widely used in industry. This workshop brings together leading researchers and practitioners in generic programming from around the world, and features papers capturing the state of the art in this important area. We welcome contributions on all aspects, theoretical as well as practical, of * polytypic programming, * programming with dependent types, * programming with type classes, * programming with (C++) concepts, * generic programming, * programming with modules, * meta-programming, * adaptive object-oriented programming, * component-based programming, * strategic programming, * aspect-oriented programming, * family polymorphism, * object-oriented generic programming, * and so on. Organizers ---------- Co-Chair Bruno C. d. S. Oliveira, Seoul National University Co-Chair Marcin Zalewski, Indiana University Programme Committee ------------------- Alley Stoughton, Kansas State University Andrei Alexandrescu, Facebook Bruno C. d. S. Oliveira (Co-Chair), Seoul National University Doug Gregor, Apple Gilad Bracha, I am a Computational Theologist Emeritus Magne Haveraaen, Universitetet i Bergen Marcin Zalewski (Co-Chair), Indiana University Neil Mitchell, Standard Chartered Ralf Lämmel, University of Koblenz-Landau Shin-Cheng Mu, Academia Sinica Thorsten Altenkirch, University of Nottingham Ulf Norell, Chalmers University Important Information --------------------- We plan to have formal proceedings, published by the ACM. Submission details Deadline for submission: Sunday 2010-06-13 Notification of acceptance: Monday 2010-07-12 Final submission due: Tuesday 2010-07-27 Workshop: Sunday 2010-09-26 Authors should submit papers, in postscript or PDF format, formatted for A4 paper, to the WGP09 EasyChair instance by 13th of June 2010. The length should be restricted to 12 pages in standard (two-column, 9pt) ACM format. Accepted papers are published by the ACM and will additionally appear in the ACM digital library. History of the Workshop on Generic Programming ---------------------------------------------- This year: * Baltimore, Maryland, US 2010 (affiliated with ICFP10) Earlier Workshops on Generic Programming have been held in * Edinburgh, UK 2009 (affiliated with ICFP09) * Victoria, BC, Canada 2008 (affiliated with ICFP), * Portland 2006 (affiliated with ICFP), * Ponte de Lima 2000 (affiliated with MPC), * Marstrand 1998 (affiliated with MPC). Furthermore, there were a few informal workshops * Utrecht 2005 (informal workshop), * Dagstuhl 2002 (IFIP WG2.1 Working Conference), * Nottingham 2001 (informal workshop), There were also (closely related) DGP workshops in Oxford (June 3-4 2004), and a Spring School on DGP in Nottingham (April 24-27 2006, which had a half-day workshop attached). Additional information: The WGP steering committee consists of J Gibbons, R Hinze, P Jansson, J Jarvi, J Jeuring, B Oliveira, S Schupp and M Zalewski

1 1

Woes on MacOS 10.6 - linking issues
by Brett Giles 12 Jun '10

12 Jun '10

Hi Folks I seem to have Gtk2HS 0.11 installed, but not quite working. Interestingly, I can run a demo, such as the hello/World.hs example, directly in ghci. However, when I try to do a ghc --make on any code containing gtk2hs I get a link error like this: Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_close) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) (maybe you meant: _hs_iconv_open) ld: symbol(s) not found I do have libiconv installed as a universal library via macports. gtk, glade etc., are also universal installed via macports. I downloaded the OSX Haskell Platform package and am running ghc 6.12.1 Other programs seem to be having some issues as well though, For instance, a command line program seems to compile fine, but when it runs I get the message: $ emlqpl (<<<--- My "successfully" compiled program - batch only, no gtk items) dyld: Library not loaded: /opt/local/lib/libgtk-quartz-2.0.0.dylib Referenced from: /usr/local/bin/emlqpl Reason: image not found Trace/BPT trap Does anyone have any suggestions? Brett Giles Grad Student, Formal Methods, Category Theory, University of Calgary brett.giles(a)ucalgary.ca

3 2

ANNOUNCE: GHC version 6.12.3
by Ian Lynagh 12 Jun '10

12 Jun '10

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.12.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.12.2, so we recommend upgrading. Release notes are here: http://darcs.haskell.org/download/docs/6.12.3/html/users_guide/release-6-12… How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://darcs.haskell.org/download/download_ghc_6_12_3.html We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

1 0

ANNOUNCE: Sifflet visual programming language, release 0.1.7
by gdweber＠iue.edu 11 Jun '10

11 Jun '10

Sifflet 0.1.7 is now available on Hackage. This release has some changes in its package dependencies, notably for fgl. New in This Release ------------------- - Due to anticipated changes in the API for fgl, Sifflet now requires fgl < 5.4.2.3. - Similarly, I have added upper bounds on versions of some other packages that Sifflet depends on. There are no new features or bug fixes. Users who are staying with fgl 5.4.2.2 should not bother to upgrade sifflet at this time. About Sifflet ------------- Sifflet is a visual, functional programming language. Sifflet programmers define functions by drawing diagrams. Sifflet shows how a function call is evaluated on the diagram. It is intended as an aid for learning about recursion. * A picture explains Sifflet better than words: please see the screenshot showing how to evaluate 3!: http://mypage.iu.edu/~gdweber/software/sifflet/home.html * Features: - Visual editor. - Visual tracer/debugger which shows how recursive and other function calls, expanding the computation when the student requests it, to support active learning. - A tutorial with 31 pictures and about as many pages. - Number, string, and list data types. - Palette with a small number of primitive functions. - Runnable examples of compound functions. * Download: http://hackage.haskell.org/package/sifflet * Home page: http://mypage.iu.edu/~gdweber/software/sifflet/home.html * Tutorial: http://mypage.iu.edu/~gdweber/software/sifflet/doc/tutorial.html -- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550

4 3

Please check your dependencies on fgl
by Ivan Miljenovic 08 Jun '10

08 Jun '10

Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. As such, if your code uses fgl you should ensure that the specification of the package in your .cabal file has an explicit upper bound (or indeed just set "fgl == 5.4.2.2") to avoid any problems when we release 6.0.0.0 (we're trying to avoid the problems that plagued KDE-4 by not claiming in the slightest that the initial few versions are intended for end users). I have already directly emailed the maintainers of any and all packages I could find on Hackage (using Roel van Dijk's wonderful reverse-dependency mirror at http://bifunctor.homelinux.net/~roel/hackage/packages/hackage.html) but just in case I've missed one or there's an as-yet-unreleased package somewhere in the works, here is the official "heads up". -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

5 10

Re: [Haskell] Re: Please check your dependencies on fgl
by Don Stewart 08 Jun '10

08 Jun '10

Hey Robby, Yeah, two documents: The "PVP" http://www.haskell.org/haskellwiki/Package_versioning_policy The Package Addition Policy for the Haskell Platform http://trac.haskell.org/haskell-platform/wiki/AddingPackages robby: > Hi all. Just thought I'd poke my head in here (perhaps where I'm not > wanted...) to ask: is there a rationale and/or guidelines for how to > use version numbers in hackage somewhere that I could read? > > I ask because we worry that similar things to this discussion would > come up in PLaneT, the Racket package management scheme (if you're > curious see http://planet.racket-lang.org/ for the site or > http://docs.racket-lang.org/planet/index.html for the documentation). > > We preemptively resolved this kind of thing by tweaking the semantics > of version numbers. Specifically, if you ask for version 1.3, say, of > a package, PLaneT will give you the largest version that has the same > major version number, ie the largest 1.x (that is compatible with the > version of Racket you're using, that is). The idea was that when > changes to the functionality happen, the package maintainer would bump > the major number and feel safe that old uses would not break. This > seems to have worked pretty well in practice, fwiw (PLaneT has been > around for six years so far). > > (We took inspiration for this particular issue by the way we've seen > major version numbers move into package names in various linux > distributions.) > > Robby

1 0