- Haskell - Haskell.org

Strafunski: New Edition
by Ralf Laemmel 08 May '02

08 May '02

Strafunski is a bundle that provides support for generic programming in Haskell, based on the concept of a functional strategy. Functional strategies are generic functions that (i) can be applied to any type, (ii) allow generic traversal into subterms, (iii) can be customized with type-specific behaviour, (iv) are first-class citizens. Strafunski consists of a combinator library (StrategyLib) and a precompiler (DrIFT-Strafunski). Release 2.0 of StrategyLib and release 1.4 of the Strafunski variation on DrIFT are now available from: http://www.cs.vu.nl/Strafunski/ Please refer to the above URL for documentation and download information. StrategyLib ----------- Changes with respect to the previous release include: * Added many combinators to the library, and split up the module StrategyLib into: - The top-level module StrategyLib which imports all other modules. - A range of `theme' modules into which combinators are grouped according to the concerns they address. Among these are the TraversalTheme, the FlowTheme, the EffectTheme, the KeyholeTheme, the FixpointTheme, and more. - A module StrategyOverloading that allows type-unifying and type-preserving combinators to be treated in uniform manner. - A module StrategyPrelude which defines basic combinators that can be defined in term of truly primitive ones. - Some modules that do not provide strategy combinators but general utilities functions, such as MonadicFunctions, and MonadRun. * The underlying term representation has been improved. Conversion to/from this representation during generic traversal is now more efficient. Also, instances of the Term class have been added for the basic types Char, Int, 2-tuples, Either and Ratio. * The various theme modules feature many of the combinators that illustrate the design patterns for functional strategic programming as presented in [1]. * Added a number of examples, including one that demonstrates strategic programming on the abstract syntax of Haskell. The new term representation was contributed by John Meacham. DrIFT-Strafunski ---------------- Changes with respect to previous versions include: * Merger of instances derivation rules with those of jDrIFT. In particular, the rule for Term now supports the term representation module based on Dynamic as available in StrategyLib version 2.0. * Instance derivation for the ATermConvertible class, as available in the Haskell ATerm Library. * Command line option -r for generating instances only, i.e. not repeating the contents of the input file itself. * Command line option -g that allows global directives to be specified on the command line instead of in the input file. The DrIFT-Strafunski package was based on the original implementation of DrIFT by Noel Winstanley and its updated implementation by Malcolm Wallace. The new instance derivation rule for Term was contributed by John Meacham. We hope DrIFT-Strafunski will soon be made redundant by John's unifying implementation: jDrIFT. Background ---------- The following papers provide useful background info: [1] Ralf Laemmel and Joost Visser Design Patterns for Functional Strategic Programming. http://www.cs.vu.nl/Strafunski/dp-sf/ This paper seeks to provide practicing functional programmers with pragmatic guidance in crafting their own strategic programs. It presents the fundamentals and the support from a user's perspective, and includes a catalogue of design patterns. Read this paper if you want to use Strafunski. [2] Ralf Laemmel and Joost Visser Typed Combinators for Generic Traversal http://www.cs.vu.nl/Strafunski/sf/ This paper introduces the concept of functional strategies. It shows how strategies are modelled inside Haskell, and it present the first version of StrategyLib. Read this paper if you want to know what makes Strafunksi work. [3] Ralf Laemmel A Polymorphic Symphony http://www.cwi.nl/~ralf/polymorphic-symphony/ This paper reconstructs functional strategies as an amalgamation of certain bits of parametric polymorphism, type case, polytypism, and overloading. Read this paper if you want to know how Strafunski can be generalized and how it may look in future. Feedback is much appreciated, and can be directed to the authors: * Ralf Laemmel (mailto:ralf@cwi.nl) * Joost Visser (mailto:Joost.Visser@cwi.nl) Have fun!

2 1

RE: Are Happy-generated parsers lazy?
by Simon Marlow 08 May '02

08 May '02

> I am running into trouble with the HaXml parser because it is > not lazy. > Hence I am considering to abondon the use of XML as data-exchange > format. Anyway, XML documents are too verbose. > > Now I wonder whether Happy-generated parsers are lazy? If you mean will it parse the input lazilly and return a lazy parse tree, then the answer is no. Happy uses LALR(1) parsing, which means that it needs to see the end of a syntactic object before reducing it. Cheers, Simon

2 1

Advanced Functional Programming: early registration one week away.
by Johan Jeuring 08 May '02

08 May '02

The early registration deadline for the AFP school is May 17. -- Johan Jeuring Summer School and Workshop on Advanced Functional Programming http://www.functional-programming.org/afp/afp4 St Anne's College, Oxford 19th to 24th August 2002 Overview In this school we want to bring computer scientists, in particular young researchers and programmers, up to date with the latest advanced functional programming techniques. We do this by using advanced functional programming techniques in "programming in the real world". Thus we hope to bridge the gap between results presented at programming conferences and material from introductory textbooks on functional programming. This is the fourth advanced functional programming school. The previous schools were held in Bastad (Sweden, LNCS 925), Olympia (Washington, USA, LNCS 1129), and Braga (Portugal, LNCS 1608). Each of these schools was considered an interesting and great experience by almost all participants. There will be a number of in depth lectures about advanced functional programming techniques, taught by the experts in the field. Lectures are aimed especially at showing new programming techniques, introducing new language constructs, and presenting interesting application areas. Another important goal is to provide that kind of information which enables participants to use functional programming in their daily life, after returning from the school. The lectures are accompanied by practical problems to be solved by the participants at the school: the school emphasises learning by doing. We expect that the ancient university town Oxford will add an extra dimension to the school. Lecturers Richard Bird and Jeremy Gibbons (University of Oxford): Arithmetic Coding with Folds and Unfolds Manuel Chakravarty (University of New South Wales): Fast Arrays in Haskell Matthias Felleisen (Northeastern University, Boston): Developing Interactive Web Programs in DrScheme Cédric Fournet (Microsoft Research) and Fabrice Le Fessant (INRIA Rocquencourt): Jocaml3, a Language for Concurrent, Distributed and Mobile Programming Paul Hudak (Yale University): Robots, Arrows and Functional Reactive Programming Koen Claessen (Chalmers University of Technology) and Colin Runciman (University of York): Testing and Tracing Lazy Functional Programs Philip Wadler (Avaya Labs): XQuery: A Typed Functional Language for Querying XML

1 0

Announce+Question: jDrIFT
by John Meacham 08 May '02

08 May '02

I often finding myself going back to good old trusty DrIFT, and have over the past few months made a number of changes to it, many of which i think people would appreciate. I was wondering what i should do to get my changes folded into the main drift, or even if there is a main drift any more? new working features I implemented include: * proper GetOpt command line handling, allows you to specify an output file (-o) as well as list all possible derivations this version can use (-l) and some others. * proper LINE pragmas in generated code * smarter error handling in some cases, parser smarter sometimes. * can deal with/ignore as appropriate some ghc extensions now * new rule to derive Typeable used by the Dynamic library. * new rule to derive Observable from the HOOD object debugger * rules to derive Term, a term representation for generic computation, can be used in a similar fashion to the Strafunski one, but has a number of advantages, fully lazy constant time implode/explode being the main one. (the external library is compatable with their work.) and some other patches that i collected from around the net jDrIFT -l lists the following: Binary, Typeable, Term, OldTerm, Implode, Explode, Observable, test, update, is, has, un, NFData, Eq, Ord, Enum, Show, Read, Bounded, Haskell2Xml features in the works: * smarter rule format, allow descriptions (help info) to be embedded, and options to be passed into the rule generators either from the command line or in the DrIFT pragmas themselves. among other things, the code generation should be able to find out what extensions you wish to let them use and let them fail gracefully if one doesnt exist that is needed. * MultiParameter typeclasses * smarter/rethought import chasing rules. * LibDrIFT, simply write your single rule, import libdrift and it will build to a DrIFT module. these modules can be used standalone executables and behave just like the original drift (with your extension), but if placed in a searchable spot, the main jDrIFT implementation will pick them up and integrate their rules into its capabilities. In Any case i made a prerelease of my modified version available at: http://homer.netmar.com/~john/computer/haskell/jDrIFT/ but would like to somehow merge with the main development tree of this tool, if one exists, if it doesnt look like that will happen then perhaps i will have to branch to a new maintained DrIFT inspired project. -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

4 4

LOPSTR'02 - Call for papers
by Michael Leuschel 08 May '02

08 May '02

--------------------------------------------------- International Workshop on Logic Based Program Development and Transformation LOPSTR'02 18 - 20 September 2002 --------------------------------------------------- CALL FOR PAPERS --------------------------------------------------- http://clip.dia.fi.upm.es/LOPSTR02/ --------------------------------------------------- Deadline for full papers: 15 June 2002 Deadline for short papers: 30 June 2002 --------------------------------------------------- The aim of the LOPSTR series is to stimulate and promote international research and collaboration on logic-based program development, and the workshop is open to contributions in logic-based program development in any language paradigm. LOPSTR'02 will be held at the Technical University of Madrid, co-located with International Static Analysis Symposium" (SAS'02) and APPIA-GULP-PRODE Joint Conference on Declarative Programming (AGP'02). Past workshops were held in Manchester, UK (1991, 1992, 1998), Louvain-la-Neuve, Belgium (1993), Pisa, Italy (1994), Arnhem, the Netherlands (1995), Stockholm, Sweden (1996), Leuven, Belgium (1997), Venice, Italy (1999), London, UK (2000), Paphos, Cyprus (2001). Since 1994 the proceedings have been published in the LNCS series of Springer-Verlag. LOPSTR also aims to be a lively, friendly forum for presenting and discussing work in progress, so it is a real workshop in the sense that it is also intended to provide useful feedback to authors on their preliminary research. Formal proceedings of the workshop are produced only after the workshop, so that authors can incorporate this feedback in the published papers. Scope of the Workshop We solicit full papers as well as extended abstracts describing work in progress. Topics of interest cover all aspects of logic-based program development, all stages of the software life cycle, and issues of both programming-in-the-small and programming-in-the-large. The following is a non-exhaustive list of topics: * specification * synthesis * verification * transformation * specialisation * analysis * composition * reuse * optimisation * applications and tools * component-based software development * agent-based software development * software architectures * design patterns and frameworks * program refinement and logics for refinement * proofs as programs Submission Guidelines * Authors can either submit extended abstracts describing work in progress or they can choose to submit full papers. Contributions should be written in English and should be submitted electronically in Postscript or PDF format to the program chairman at the following email address: mal(a)ecs.soton.ac.uk. Prospective authors who have difficulties for the electronic submission may contact the chairman. * Extended abstracts should not exceed 6 pages in llncs format and may describe work in progress. Promising abstracts relevant to the scope of LOPSTR will be selected for presentation at the workshop. The submission deadline for extended abstracts is June 30, 2002. * Full papers should not exceed 16 pages (including references) in llncs format. The submission deadline is June 16, 2002. These papers will be judged using ordinary conference quality criteria and accepted papers will have to be presented at the workshop and will automatically appear in the pre-proceedings as well as in the final collection of papers. * In both cases the notification of acceptance or rejection will be sent by July 15, 2002. Accepted papers and abstracts will be collected in informal pre-proceedings which will be available at the workshop. * After the workshop, authors of extended abstract which are judged mature for publication will be invited to submit full papers. These will be reviewed according to the usual refereeing procedures, and accepted papers will be published in a final collection of papers which are expected to be published in the Lecture Notes in Computer Science series by Springer-Verlag. All the full papers accepted before the workshop will automatically appear in that book as well; there will be no additional refereeing (although authors will be given a chance to revise their paper, if they so wish, based upon the feedback from the LOPSTR event). Programme Committee Jean Raymond Abrial Consultant, Marseille, France Elvira Albert Valencia, Spain Michael Butler Southampton, UK James Caldwell Laramie, Wyoming, USA Bart Demoen Leuven, Belgium Sandro Etalle Twente, The Netherlands Laurent Fribourg ENS Cachan, France Michael Hanus Kiel, Germany Andy King Kent, UK Kung-Kiu Lau Manchester, UK Michael Leuschel Southampton, UK C.R. Ramakrishnan Stony Brook, USA Olivier Ridoux Rennes, France Sabina Rossi Venice, Italy Wolfram Schulte Microsoft, USA Jens Peter Secher Copenhagen, Denmark Maurizio Proietti IASI-CNR, Rome, Italy German Puebla Madrid, Spain Julian Richardson Edinburgh, UK Michael Wooldridge Liverpool, UK Programme Chair Michael Leuschel, University of Southampton Department of Electronics and Computer Science Highfield, Southampton SO17 1BJ UK

1 0

Re: funny: the Almighty Monad
by Ashley Yakeley 08 May '02

08 May '02

At 2002-05-08 01:19, Bernard James POPE wrote: > "in the letters of the Christian Platonist Synesius, > God is described as the Monad of Monads." This reminds me of this: <http://www.livejournal.com/talkread.bml?journal=gmoryx&itemid=10481> ...wherein I use category theory to show that anyone who experiences angels cannot reasonably believe in God. Not serious, but frankly it makes at least as much sense as most Platonic and Gnostic philosophy I've ever come across. -- Ashley Yakeley, Seattle WA

1 0

funny: the Almighty Monad
by Bernard James POPE 08 May '02

08 May '02

Hi all, Next time someone asks you "What is a Monad?", just point them at this page: http://www.newadvent.org/cathen/10447b.htm My favourite quote is: "in the letters of the Christian Platonist Synesius, God is described as the Monad of Monads." For those who can't be bothered looking, the page is part of a Catholic Encyclopedia, and it describes in much detail some rather interesting aspects of the word Monad that I didn't know before. Its even quite insightful. Cheers, Bernie PS Should rename unsafePerformIO to sinfulPerformIO?

1 0

Haddock installing problems
by Andre W B Furtado 08 May '02

08 May '02

I was trying to install/compile Haddock 0.1 in my computer (Windows98 + Cygwin, GHC-5.02.3), but I got the following error message: You must install the version of Perl shipped with GHC (or a compatible one) in /bin. I though I already had a version of Perl in my computer, since HOpenGL (which uses it) was compiled succesfully. My /bin dir also contains a file called perl.exe and another dir called Perl (which contains perl.exe too). Can anyone help me? Thans a lot, -- Andre

1 0

Deforestration harmful?
by Shin-Cheng Mu 07 May '02

07 May '02

Hi all, We encountered a case where elimination of intermediate data structure seeems to have a bad impact on the overall performance and we were wondering why. Relationally, our program would be as simple as: f . g where g :: Seed -> Tree1 and f :: Tree1 -> Tree2. Basically g generate some kind of tree via an unfold and f map a Tree1 to some (usually 3 or 4) Tree2. In reality we have to implement relations as set (or list) valued functions, so it becomes concat . map f. g where g looks like g seed = [ z | (s1, s2) <- split seed, x <- g s1, y <- g s2, z <- join x y ] The relation f was almost as simple as a replacing each constructor in Tree1 with one or more coresponding constructors in Tree2. They two can be fused together and becomes fg seed = [ z | (s1, s2) <- split seed, x <- fg s1, y <- fg s2, z <- join' x y ] The intermediate datatype Tree1 was thus eliminated. The problem was: the fused program ran slower than the original one! At least if you measure the total running time (either via the UNIX time command or use the CPUTime module). The time reported in the GHC time profile indeed showed that the fused program is faster, though, if GC time is excluded. We were quite curious why and my guess was: since f maps a Tree1 to more than one Tree2, in the two list comprehensions, the list produced by (fg s2) is much longer than (g s2). The fused program thus has to keep a longer list in memory. Worse heap residency results in more GCs. (Luckily GHC did not attempt to automatically perform the fusion for us! :) ) An obvious thing to try was to increase the heap size. Again we were surprised. Indeed the GC time decreased but the running time in the profile (excluding the GC time) increased a bit. Our guess was that it might have something to do with the way GHC allocates new memory cells such that larger heap results in longer allocation time. It was quite tricky to find the best heap size at which the program runs at maximal speed. Are the above guesses are plausible? Is it a known phenomena? Thank you very much. sincerely, Shin-Cheng Mu

2 2

updating labelled fields
by Hal Daume III 07 May '02

07 May '02

Hi, I often create structures like: data MyData = MyData { foo :: ..., bar :: ..., .... } and most of the time i do one of two things: 1) read values from the structure, as in: let x = (foo myData) in ... 2) update values in the structure, as in: let myData' = myData { foo = (foo myData)+1 } Only very rarely (usually only during intializization) do I actually put values into the structure that *don't* depend on their previous value. I end up with expresions like: ... myData { foo = (foo myData) + 1 ; bar = (bar myData) ++ "bar" ; ick = (ick myData) ! n ; ... } I was wondering if there existed any sort of "update" syntax. Obviously not real update, but enough to get rid of the "(foo myData)" parts of my epxression which really serve to just clutter up with expression. Perhaps something like: ... myData { foo <- (+1) ; bar <- (++"bar") ; ick <- (!n) ; ... } or the like, where "x { ... y <- e ... } is translated to "x { ... y = e (y x) ... }" (i only use "<-" because that seems to be the default extension symbol, i guess because we don't want to trample symbols people might actually use.) Anyway, does such a thing exist, and, if not, is there any chance it could exist, or is it just syntactic salt to too many people? :) - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

3 3