March 2006 - Haskell - Haskell.org

Announcing Djinn, version 2004-12-11, a coding wizard
by Lennart Augustsson 07 Apr '11

07 Apr '11

Howdy, y'all! I've written a small program that takes a (Haskell) type and gives you back a function of that type if one exists. It's kind of fun, so I thought I'd share it. It's probably best explained with a sample session. calvin% djinn Welcome to Djinn version 2005-12-11. Type :h to get help. # Djinn is interactive if not given any arguments. # Let's see if it can find the identity function. Djinn> f ? a->a f :: a -> a f x1 = x1 # Yes, that was easy. Let's try some tuple munging. Djinn> sel ? ((a,b),(c,d)) -> (b,c) sel :: ((a, b), (c, d)) -> (b, c) sel ((_, v5), (v6, _)) = (v5, v6) # We can ask for the impossible, but then we get what we # deserve. Djinn> cast ? a->b -- cast cannot be realized. # OK, let's be bold and try some functions that are tricky to write: # return, bind, and callCC in the continuation monad Djinn> type C a = (a -> r) -> r Djinn> returnC ? a -> C a returnC :: a -> C a returnC x1 x2 = x2 x1 Djinn> bindC ? C a -> (a -> C b) -> C b bindC :: C a -> (a -> C b) -> C b bindC x1 x2 x3 = x1 (\ c15 -> x2 c15 (\ c17 -> x3 c17)) Djinn> callCC ? ((a -> C b) -> C a) -> C a callCC :: ((a -> C b) -> C a) -> C a callCC x1 x2 = x1 (\ c15 _ -> x2 c15) (\ c11 -> x2 c11) # Well, poor Djinn has a sweaty brow after deducing the code # for callCC so we had better quit. Djinn> :q Bye. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. For the curious, Djinn uses a decision procedure for intuitionistic propositional calculus due to Roy Dyckhoff. It's a variation of Gentzen's LJ system. This means that (in theory) Djinn will always find a function if one exists, and if one doesn't exist Djinn will terminate telling you so. This is the very first version, so expect bugs. :) Share and enjoy. -- Lennart

8 13

Haskell-mode 2.0
by Stefan Monnier 02 Feb '09

02 Feb '09

I have recently taken over maintainership of Haskell-mode, and after making a bunch of changes, I figured it would be a good idea to make a new release. You can find this new release at: http://www-perso.iro.umontreal.ca/~monnier/elisp/ If you think it should also be found at http://www.haskell.org/haskell-mode/, then please tell John Peterson to get back to me (my email to him seem to go straight to the bitbucket. John?). This release has several changes that have all been only lightly tested, especially w.r.t compatibility with various Emacsen. See appended the NEWS file that describes some of the notewirthy changes. Stefan Changes since 1.45: * keybindings C-c <char> have been replaced by C-c C-<char> so as not to collide with minor modes. * The following modules are now automatically activated without having to add anything to haskell-mode-hook: haskell-font-lock (just turn on global-font-lock-mode). haskell-decl-scan (just bind `imenu' to some key). * In recent Emacsen, haskell-doc hooks into eldoc-mode. * haskell-hugs and haskell-ghci are superceded by inf-haskell. * Indentation rules have been improved when using layout inside parens/braces. * Symbols like -> and \ can be displayed as actual arrows and lambdas. See haskell-font-lock-symbols. * Tweaks to the font-lock settings. Among other things paren-matching with things like \(x,y) should work correctly now. * New maintainer <monnier(a)gnu.org>.

3 6

Compilation of big, computed tables
by Stefan Karrmann 24 Oct '06

24 Oct '06

Dear all, can ghc compile huge tables into efficient code if they are constant at compile time? Two examples may clearify the question: big1 :: UArray Int Char big1 = array (0,1000) $! map (\i -> (i,toEnum i)) [0..1000] big2 = sum [0..10000]::Int -- == 50005000 == n*(n+1)/2 where n = 10000 Both values are constant at compile time. As they are given by pure functions, the compiler could evaluate them and write the *result* into the object file 'foo.o'. This would save code size and run time. I peeked into 'foo.hc' but I didn't found 0x2fb0408 nor an array {0, 1, 2, 3, ..., 1000} or similar things. The function in big2 should show that the computation of the value could be very time consuming. If the compiler does not compute it, the source file could be generated by a helper program (or template Haskell?). The function in big1 should show that the conversion of the data into an array could be run-time, code-size and heap-size consuming. (You need the list (maybe explicitly - think of 1000 fixed pseudo-random numbers) and convert it into an array.) If the compiler generates the unboxed array directly it could be rather efficient. PS: I compiled with: ghc6 -c -O2 -keep-tmp-files -keep-hc-files foo.hs Regards, -- Stefan Karrmann

9 12

"strange" behavior of Implicit Parameters
by Eike Scholz 08 Aug '06

08 Aug '06

Hi, I have just a short question, about the semantics of Implicit parameters on GHC 6.4. Given the following code: > (???) x f > = let ?foo = 1337 > in f x > fun :: (?foo::Int,Show x) => x -> String > fun x = "x = "++(show x)++"; ?foo = "++(show ?foo) > test = let ?foo = 23 > in 42 ??? fun I would expect: test == "x = 42; ?foo = 1337" Because I thought, that it gets reduced like: let ?foo = 23 in 42 ??? fun ~> let ?foo = 23 in (let ?foo = 1337 in fun 42) ~> ... ~> "x = 42; ?foo = 1337" however I get "x = 42; ?foo = 23" in ghci. Is there a special reason, why the implicit parameter is reduced first? Could it be a bug? Reducing it my way would be very useful for combinator-libraries, since it could be used passing around state info, or simple debug text, that tells where a Runtime-error occured? an odd example: > undef = error ?errstr > (<?>) x s = let ?errstr = ?errstr++"\n"++s in x -- annotate error tags so error annotations will accumulate and it would be easy to resolve runtime errors. best regards Eike Scholz

14 38

Scheme Workshop 2006
by Robby Findler 31 Mar '06

31 Mar '06

Dear all, I'm writing to let you know about the upcoming Scheme and Functional Programming workshop -- specifically that the submission deadline is June 9, about 2 months from now. The workshop will be held Portland Oregon on September 17, the day before ICFP. We look forward you your submissions! Best, Robby ============================================================ The purpose of the workshop is to discuss experience with and future developments of the Scheme programming language, as well as general aspects of computer science loosely centered on the general theme of Scheme. http://scheme2006.cs.uchicago.edu/ IMPORTANT DATES Submission deadline: Friday June 9 Author notification: Friday June 30 Final versions due: Friday July 14 Workshop: Sunday September 17, the day before ICFP CALL FOR PAPERS Papers are invited concerning all aspects of the design, semantics, theory, application, implementation, and teaching of Scheme. Some example areas include (but are not limited to): * Language design Scheme's simple syntactic framework and minimal static semantics has historically made the language an attractive lab bench for the development and experimentation of novel language features and mechanisms. Topics in this area include modules systems, exceptions, control mechanisms, distributed programming, concurrency and synchronisation, macro systems, and objects. Past, present and future SRFIs are welcome. * Type systems Static analyses for dynamic type systems, type systems that bridge the gap between static and dynamic types, static systems with type dynamic extensions, weak typing. * Theory Formal semantics, calculi, correctness of analyses and transformations, lambda calculus. * Implementation Compilers, runtime systems, optimisation, virtual machines, resource management, interpreters, foreign-function and operating system interfaces, partial evaluation, program analysis and transformation, embedded systems, and generally implementations with novel or noteworthy features. * Program-development environments and tools The Lisp and Scheme family of programming languages have traditionally been the source of innovative program-development environments. Authors working on these issues are encouraged to submit papers describing their technologies. Topics include profilers, tracers, debuggers, program understanding tools, performance and conformance test suites and tools. * Education Scheme has achieved widespread use as a tool for teaching computer science. Papers on the theory and practice of teaching with Scheme are invited. * Agile Methogologies Dynamic languages seem to share a symbiotic relationship with agile software development methodologies. In particular, the dynamic type checking of Scheme clearly benefits from test-driven development, but that same dynamic checking makes the software more easily adapted to changing requirements. * Applications and experience Interesting applications which illuminate aspects of Scheme experience with Scheme in commercial or real-world contexts; use of Scheme as an extension or scripting language. * Scheme pearls Elegant, instructive examples of functional programming. A Scheme pearl submission is a special category, and should be a short paper presenting an algorithm, idea or programming device using Scheme in a way that is particularly elegant. Following the model of earlier workshops, experience papers need not necessarily report original research results; they may instead report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! ORGANIZERS Program Chair Robby Findler, University of Chicago Program Committee John Clements, Cal Poly Sebastian Egner, Philips Research Robby Findler, University of Chicago Cormac Flanagan, UC Santa Cruz Erik Hilsdale, Google Eric Knauel, University of Tubingen Steering Committee William D. Clinger, Northeastern University Marc Feeley, University of Montreal Robby Findler, University of Chicago Dan Friedman, Indiana University Christian Queinnec, University Paris 6 Manuel Serrano, INRIA Olin Shivers, Georgia Tech Mitchell Wand, Northeastern University

1 0

Network advice needed
by Andreas Marth 31 Mar '06

31 Mar '06

Hallo! While I am not a Haskell newbie I am a network newbie and need your advice. A few years ago I coded some business logic in Haskell which is used in an application. The application mainly consists of a GUI which calls the Haskell program. The whole application is installed at the computer it is used on. Now it shall be possible to use it from any computer within the company net. (They use Windows and any kind of scripting or ActiveX is okay when needed.) Because response time is an issue I think a client/server solution is not feasible. What I need to know now is if it is possible to pull the application from a server and run it locally. What would be required? What is the way to go? Which kind of complications are to be expected? (To clarify a bit more I am not concerned about the GUI that will be reimplemented - probably in JAVA - I am concerned about the business logic.) Any help, hints, thoughts are really appreciated. :-) Andreas

2 1

CFP: Multithreading in Hardware and Software... TV06, post CAV workshop Aug 21-22, 2006
by Simon Marlow 31 Mar '06

31 Mar '06

[posting on behalf of Ganesh <ganesh(a)cs.utah.edu>] Workshop on Multithreading in Hardware and Software: Formal Approaches to Design and Verification TV 2006 A FLoC'06 / CAV Affiliated Workshop August 21-22, 2006, Seattle, WA Scope of Workshop The use of threading is already widespread, and will experience explosive growth moving into the future, given that tomorrow's performance / energy goals will be met through the increased use of threads and "multicores" (chip level multiprocessors). Unfortunately, the correctness problems in this arena are daunting, as well as are far from being solved. TV06 invites papers addressing the tussle between correctness, reliability, and performance in this space. It is clear that well-engineered solutions in this space will require paying adequate attention to several areas, including (but clearly not limited to): * analysis, testing, and verification techniques for threaded systems * experience building reliable and high-performance threaded systems * case studies of verifying threaded systems * language design and formal semantics pertaining to threading * logics and models of concurrency, including transaction memories * model checking multithreaded programs * shared memory consistency models at the hardware, language, and library levels * runtime verification for multithreaded programs and systems * threading issues in multicore systems and chips * designing formally well-specified high-performance thread libraries * understanding threading issues in specific areas such as high-performance computing (e.g., OpenMP), general purpose libraries (e.g., PThreads), and languages (e.g., C#, Java) We invite researchers and engineers working on all aspects of threading, especially the above, to submit a paper as per specifications below. TV06 is hosted by the premier CAV conference, which is part of FLoC 2006 (Federated Logic Conference). which encompasses 6 conferences and over 30 workshops, and will be held in August in Seattle. Please visit http://research.microsoft.com/floc06 for a full description of these events, as well as a catchy poster. This location, setting, and timing promises ample opportunities for ample intellectual and social interactions. We especially welcome practitioners and system designers to describe a roadmap of priorities, given that many challenging problems need to be solved in short order. Invited Speakers * Vijay Saraswat, IBM T.J. Watson Research Labs, Yorktown Heights, NY * Maurice Herlihy, Brown University, Providence, RI Program Committee * Arvind MIT CSAIL, USA * Hans Boehm HP, USA * Ching Tsun Chou Intel,Santa Clara,USA * Byron Cook Microsoft Research, Cambridge,UK * Robert P. Cook Georgia Southern University, USA * Cormac Flanagan UC Santa Cruz, USA * Mike Kirby University of Utah, USA * Timothy G. Mattson Intel, DuPont, USA * John Regehr University of Utah, USA * Scott Stoller SUNY at Stony Brook, USA * Shaz Qadeer Microsoft Research, USA * Yue Yang Microsoft, USA Important Dates Deadline for submissions: May 1, 2006 Notification of acceptance: June 9, 2006 Final manuscript due: July 15, 2006 Workshop: August 21-22, 2006 Paper Submission Submissions must be made electronically in PDF format, following the instructions on the TV06 Web site, which is http://www.cs.utah.edu/tv06. Submissions must use the ACM SIG Proceedings format with letter-size paper (see http://www.acm.org/sigs/pubs/proceed/template.html for details). Two categories of papers will be accepted: * long : 10-15 pages, describing in-depth investigations * short: 4-6 pages, describing a tool, position statement, etc. Papers should contain a concise abstract of approximately 150 words, clearly stating the nature of the contributions. At least one author of each accepted paper is required to register for TV06 (registration information coming soon at http://www.cs.utah.edu/tv06) as well as give a presentation at the workshop. Papers should be self-contained, and describe original work, but may be based on (and may contain) portions from a previously published paper, provided it also includes substantial new work. A journal special issue based on selected papers from this workshop is under consideration. Email questions, if any, to tv06(a)cs.utah.edu Organizers Ganesh Gopalakrishnan, School of Computing, University of Utah, Salt Lake City, UT 84112, USA John W. O'Leary, Strategic CAD Labs, Intel Corporation, Hillsboro, OR, USA -- For questions and other information, please email tv06(a)cs.utah.edu or check http://www.cs.utah.edu/tv06 ---

1 0

(CFP) Workshop on Logic-based Programming Environments
by Wim Vanhoof 31 Mar '06

31 Mar '06

----------------------------------------------------------- WLPE' 06 - CALL FOR PAPERS Workshop on Logic-based Methods in Programming Environments (satellite workshop of ICLP’06) August 16, 2006 Seattle (Washington), USA http://lml.ls.fi.upm.es/~susana/Conferences/WLPE06/ ----------------------------------------------------------- Aim and Scope ------------- The 16th Workshop on Logic-based methods in Programming Environments will take place in Seattle (Washington), USA, as a satellite workshop of ICLP'06, the 22th International Conference on Logic Programming. This workshop will continue the series of successful international workshops on logic programming environments held in Ohio, USA (1989), Eilat, Israel (1990), Paris, France (1991), Washington, USA (1992), Vancouver, Canada (1993), Santa Margherita Ligure, Italy (1994), Portland, USA (1995), Leuven, Belgium and Port Jefferson, USA (1997), Las Cruces, USA (1999), Paphos, Cyprus (2001), Copenhagen, Denmark (2002), Mumbai, India (2003), Saint Malo, France (2004) and Sitges, Spain (2005). The workshop aims at providing an informal meeting for the researchers working on logic-based tools for development and analysis of programs. This year we want to emphasize two aspects: on one hand we want to discuss the presentation, pragmatics and experiences of such tools; on the other one, we want to shift the traditional focus on environment tools for logic programming to logic-based environmental tools for programming in general. Specific topic areas relevant to the workshop include, but are not limited to: * tools for debugging and testing * tools for static and dynamic analysis * systems for program verification and validation * code generation from specifications * termination and non-termination analyzers * reasoners on occurs-check freeness and determinacy * profilers and performance analyzers * systems for types and modes analyzes * module systems * optimization tools. In addition to papers describing more conceptual work on environmental tools, we solicit papers describing the implementation of and experimentation with such tools. Submission guidelines --------------------- Length of papers can range from 2 to 17 pages, preferably in LNCS format. Authors are requested to submit their paper using the submission webpage at http://vampire.cs.man.ac.uk/WLPE-06/ Alternatively, authors can send a copy of their paper (in pdf or ps format) to the workshop coordinator (wva(a)info.fundp.ac.be) An informal proceedings will be published as a technical report of the University of Namur and distributed at the workshop. After the workshop, the proceedings will be publicly available on-line in the Computing Research Repository (CoRR). Important dates --------------- Submission: May 15, 2006 Notification: June 15, 2006 Camera-ready: July 10, 2006 Workshop: August 16, 2006 Workshop organizers ------------------- Susana Muñoz-Hernández (Universidad Politécnica de Madrid, Spain) Wim Vanhoof (coordinator) (Univeristy of Namur, Belgium) Program Committee ----------------- María Alpuente (Universidad Politécnica de Valencia, Spain) Mireille Ducassé (INSA/IRISA, Rennes, France) John Gallager (Roskilde University, Denmark) María García de la Banda (Monash University, Australia) José Manuel Gómez-Pérez (ISOCO Madrid, Spain) Gopal Gupta (University of Texas at Dallas, U.S.A) Moreno Falaschi (Università di Udine, Italy) Pat Hill (University of Leeds, U.K.) Michael Leuschel (Heinrich-Heine-Universitat Düsseldorf, Germany) Fred Mesnard (Université de La Réunion, France) Susana Muñoz-Hernández (Universidad Politécnica de Madrid, Spain) Kostis Sagonas (Uppsala University, Sweden) Alexander Serebrenik (Technische Universiteit Eindhoven, The Netherlands) Zoltan Somogyi (University of Melbourne, Australia) Wim Vanhoof (University of Namur, Belgium)

1 0

RE: [Haskell] Haskell as a disruptive technology?
by Tim Harris 30 Mar '06

30 Mar '06

Hi, > I had to chuckle at this one in particular, since the implementation > of transactions in Haskell was based on experiences with prototype > software TM in Java and C#! In truth, Haskell adds a few things to > the mix that make STM dramatically better. Most important are STM > and STRef---it's no longer possible to accidentally commingle > transactional and non-transactional access to the same storage, or to > do I/O in the middle of a transaction by mistake. I don't think that the Haskell STM implementation is as closely based on the Java / C# work as it appears... Before Simon Marlow's SMP extensions we relied on there being only a single thread running in an STM operation in the RTS at any time, so the STMCommit operation could run without interference. Even with SMP support, and the possibility of multiple threads in the RTS, we've never aimed for non-blocking progress because we assume that the number of OS threads will be tuned to the number of available cores. As well as the use of the STM monad to separate out IO/tx/non-tx access, I think the big thing that we learnt from the Haskell work was the retry/orElse abstractions for composable blocking. BTW, I've put a copy of another recent STM-Haskell paper online at http://research.microsoft.com/~tharris/drafts/2006-invariants-draft.pdf. It's about defining invariants over transactionally-managed data structures -- feedback's very welcome! Cheers, Tim

2 1

Re: [Haskell] Haskell as a disruptive technology?
by Paul Johnson 30 Mar '06

30 Mar '06

Sorry to have been out of the discussion for so long. I've just upgraded to Fedora Core 5. Multimedia and the proprietary NVidia 3d driver have yet to be added, but at least email is now up. Robert Dockins wrote: > FWIW, I'd like to voice my agreement with this view. The hardware manufacturers are > hard at work building the perfect niche for Haskell -- all of commodity desktop computing! > Moore's law is still packing more transistors onto the silicon, and it seems like people have > run out of ideas for what to do with them, so they just start duplicating cores ;-) All we > have to do is be ready for it when it arrives. When people see that, using Haskell, they > can write programs using 1) fewer man-hours with 2) fewer bugs which 3) scale effortlessly > to highly parallel hardware to beat the pants off C/C++/Java/what-have-you, they'll be > beating down the doors to get it. Sorry. I really wish I could agree, but I don't. Like I said earlier, it doesn't matter how good your technology is, if you go up against the incumbents you will lose every time. Here is how I see it playing out: 1: People start to complain that effective use of multicore CPUs is very hard. The trade press editorialize on the problem: is this the end of the computer performance revolution. 2: Sun and Microsoft bring out support for STM in Java and C# respectively. The trade press editorialize on this wonderful new technology. Haskell may get a mention as the original prototype, "but now its ready for mainstream use". 3: The Java and C# support turns out to be unsafe, partial and inefficient. Long articles are written in the trade press about how to make sure your programs use it properly. Programmers with proven experience in these flavours get big pay rises. 4: We sit around wondering what happened. "Its not fair: we had this years ago and done right. Why is everyone using the broken stuff?" I've seen this happen before, with Eiffel. From around 1989 I was telling people that Eiffel was the way to go. It was better than C++ in every way, and garbage collection was a great win. Nobody would try Eiffel. They said GC was inefficient, and anyway real programmers didn't need it. Then Java came out, and a couple of years later a project manager who had previously ignored my enthusiasm about Eiffel told me how great it was to have GC in Java, and how few bugs they were getting as a result. I managed a weak smile. Getting good concurrency support on SMP is important, of course. But its not going to beat Java and C++ on their home turf. That is the point of disruptive technologies: they start out in a niche and then spread. First find a niche. One of the lessons Clayton Christensen draws from his study of disruptive technologies is that the market for them is unknown and unknowable. As a rule you don't identify and analyse it, you notice it by accident and have the agility to exploit it. One example from the book: Honda initially tried to sell its motorcycles by competing head-on with incumbents like Harley Davidson. They got nowhere, but when the frustrated marketroids took their sample bikes out on the sand dunes for some fun, friends asked where they could get one. So the marketroids got a few as a favour to their friends. And *their* friends asked for some too, and it eventually dawned on Honda that there was a whole new market for light recreational sport bikes that their model was just right for. So it is with Haskell. I've spent some time looking for niches where Haskell might fit. I've got a couple of ideas (test harnesses and experimental simulations), but if I or anyone else laid out a marketing programme based on those ideas then it would very likely be wrong in some important way. What we need to do is to look for lots of similar sorts of software: marginal opportunities that are poorly served by the big incumbents, but where Haskell can shine. When you find something like that then push Haskell and see if it fits. If you win then spread the word, and get your new converts to do the same *in their speciality*. Then we will be going places. Paul.

2 1