- Haskell-Cafe - Haskell.org

Jane Street
by Matthias Görgens 17 Jul '09

17 Jul '09

If one of you knows something about working at Jane Street, I'd be happy to have exchange some mails. I am considering applying there. Thanks!

1 0

Alternative IO
by Cristiano Paris 17 Jul '09

17 Jul '09

As a joke, I wrote an instance of Alternative for IO actions: {-# LANGUAGE ScopedTypeVariables #-} module Main where import Control.Applicative import Control.Exception instance Alternative IO where empty = undefined x <|> y = handle (\ (_ :: SomeException) -> y) x This would allow to write IO code which failsafes to a value if the previous computation failed, i.e.: *Main Control.Applicative> undefined <|> print "Hello" "Hello" *Main Control.Applicative> print "Hello" <|> undefined "Hello" It seems a neat way to catch exception in some scenarios. What do you think? Why is not Alternative IO defined in Control.Applicative? Thanks, Cristiano

9 11

Python vs Haskell in tying the knot
by Cristiano Paris 17 Jul '09

17 Jul '09

On Fri, Jul 17, 2009 at 12:41 PM, Cristiano Paris<frodo(a)theshire.org> wrote: > ... > Now, to confirm my hypothesis, I wrote a slight different version of > fib, like follows: > > fib' n = 1:1:(fib' n) `plus` (tail $ fib' n) where plus = zipWith (+) > > i.e. I inserted a fictious argument n in the definition of fib'. > > Now, if I try "take 30 $ fib' 100", it takes significntly longer than > "take 30 fib": specifically, the latter is instantaneous, while the > former takes about 5 seconds to complete on my MacBook Pro. Is this an > evidence that the "tying the knot" process is going on in the first > version? BTW, after a -O2 compilation, fib' is apparently as fast a fib. Cristiano

2 1

Line drawing algorithm
by CK Kashyap 17 Jul '09

17 Jul '09

Hi All, I am working on a diagraming utility in Haskell. I started with line drawing. I am doing the basic stuff using the y = mx + c formula to draw a line between (x1,y1) and (x2,y2) Here's what I need to do - if dx > dy where dx = (x2 - x1) and dy = (y2 - y1) then I need to vary x between x1 and x2 and find the various y's however if dy > dx then I need to vary y beteen y1 and y2 and get various x's In the code below, I've only taken care of the situation where dx > dy - I was thinking if there was a better way to do it that takes care of the other condition as well without repeating the code. type Point = (Integer,Integer) line :: Point -> Point -> [Point] -- get all the points in the line line p1@(x1,y1) p2@(x2,y2) = line' start end start slope where (start,end) = reorderPoints p1 p2 slope = ((fromIntegral (y2-y1)) / (fromIntegral (x2-x1))) reorderPoints (px1,py1) (px2,py2) | px1 < px2 = (p1,p2) | otherwise = (p2,p1) line' :: Point -> Point -> Point -> Double -> [Point] line' start@(x1,y1) end@(x2,y2) point@(x3,y3) slope | x3 == x2 = [end] | otherwise = [point] ++ line' start end (newX,newY) slope where newX = x3 + 1 newY = y1 + round (slope * (fromIntegral (newX - x1))) hello = line (1,1) (10,10) Regards, Kashyap

2 2

Python vs Haskell in tying the knot
by Cristiano Paris 17 Jul '09

17 Jul '09

Hi, as pointed out in this list, it seems that a "tying the knot" example would be the one better explaining the power of Haskell's lazy-by-default approach against Python+Iterator's approach to laziness. So, in these days I'm trying to grasp the meaning of this "tying the knot" concept which seems to be quite hard to understand for me (at least as much as Monads and Delimited Continuations were). Specifically, I was looking for a very basic example of TTK and came up with this implementation of Fibonacci (again!) which might possibly be a TTK-flavored way for generation: fib = 1:1:fib `plus` (tail fib) where plus = zipWith (+) Of course, this was something I already encountered when exploring the Y-combinator. Anyhow, I tried to translate this implementation to Python using Iterators and this is what I wrote: def fib(): yield 1 yield 1 p = plus(fib(),tail(fib())) while True: yield p.next() def plus(x,y): while True: yield x.next() + y.next() print take(5,fib()) I've omitted the implementation for tail() and take() for brevity. Apart from the iterator machinery, this is an direct translation of the Haskell's fib implementation. More, it's quite modular because fib lives by itself and is composed with take to get the final result. The only caveat in the Python code is that it maintains an O(n^2) Iterator's states, thus making it a very poor implementation. So my considerations are: 1 - The Fibonacci generator is not an example of TTK at all and then it can be translated to Python. 2 - The Fibonacci generator is a too simple example of TTK, easy to be translated to Python. 3 - The O(n^2) state caveat is THE point making the difference between Haskell and Python, for which Haksell is much more efficient that Python while remaining very expressive and idiomatic (but that may not be the case for other TTK examples). I'm trying to implement myself the doubly linked list example from the Wikipage, which is "certified" to be a TTK example, but I'd like to have your comments on this. Thank you. Cristiano

6 6

Parsec for C or C++
by Roy Lowrance 17 Jul '09

17 Jul '09

I am working on a research language that is a variant of C. I'd like to use Parsec as the parser. Is there an existing Parsec parser for C or C++ (or Java) that could serve as a starting point? Thanks, Roy

4 6

Parallellizing array-based function
by Jon Harrop 17 Jul '09

17 Jul '09

Is it possible to parallelize array-based functions such as in-place quicksort in Haskell? If so, does anyone have a working implementation? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

1 0

PEPM'10 - Call for Papers (Deadline: 6 Oct 09) - Invited Speakers announced
by Janis Voigtlaender 17 Jul '09

17 Jul '09

=============================================================== CALL FOR PAPERS ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 =============================================================== INVITED SPEAKERS: * Lennart Augustsson (Standard Chartered Bank, UK) * Jeremy Siek (University of Colorado at Boulder, USA) IMPORTANT DATES: * Paper submission: Tue, October 6, 2009, 23:59, Apia time * Author notification: Thu, October 29, 2009 * Camera-ready papers: Mon, November 9, 2009 To facilitate smooth organization of the review process, authors are asked to submit a short abstract by October 1, 2009. SUBMISSION CATEGORIES: * Regular research papers (max. 10 pages in ACM Proceedings style) * Tool demonstration papers (max. 4 pages plus max. 6 pages appendix) TRAVEL SUPPORT: Students and other attendants in need can apply for a SIGPLAN PAC grant to help cover expenses. For details, see http://www.sigplan.org/PAC.htm. SCOPE: The PEPM Symposium/Workshop series aims to bring together researchers and practitioners working in the areas of program manipulation, partial evaluation, and program generation. PEPM focuses on techniques, theories, tools, and applications of analysis and manipulation of programs. The 2010 PEPM workshop will be based on a broad interpretation of semantics-based program manipulation in a continued effort to expand the scope of PEPM significantly beyond the traditionally covered areas of partial evaluation and specialization and include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, it covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to reach out to practitioners, there is a separate category of tool demonstration papers. Topics of interest for PEPM'10 include, but are not limited to: * Program and model manipulation techniques such as transformations driven by rules, patterns, or analyses, partial evaluation, specialization, program inversion, program composition, slicing, symbolic execution, refactoring, aspect weaving, decompilation, and obfuscation. * Program analysis techniques that are used to drive program/model manipulation such as abstract interpretation, static analysis, binding-time analysis, dynamic analysis, constraint solving, type systems, automated testing and test case generation. * Analysis and transformation for programs/models with advanced features such as objects, generics, ownership types, aspects, reflection, XML type systems, component frameworks, and middleware. * Techniques that treat programs/models as data objects including meta-programming, generative programming, deep embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Application of the above techniques including experimental studies, engineering needed for scalability, and benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, resource-limited computation, and security. We especially encourage papers that break new ground including descriptions of how program/model manipulation tools can be integrated into realistic software development processes, descriptions of robust tools capable of effectively handling realistic applications, and new areas of application such as rapidly evolving systems, distributed and web-based programming including middleware manipulation, model-driven development, and on-the-fly program adaptation driven by run-time or statistical analysis. PROCEEDINGS: There will be formal proceedings published by ACM Press. In addition to printed proceedings, accepted papers will be included in the ACM Digital Library. Selected papers may later on be invited for a journal special issue dedicated to PEPM'10. SUBMISSION GUIDELINES: Papers should be submitted electronically via the workshop web site. Regular research papers must not exceed 10 pages in ACM Proceedings style. Tool demonstration papers must not exceed 4 pages in ACM Proceedings style, and authors will be expected to present a live demonstration of the described tool at the workshop (tool papers should include an additional appendix of up to 6 extra pages giving the outline, screenshots, examples, etc. to indicate the content of the proposed live demo at the workshop). Authors using Latex to prepare their submissions should use the new improved SIGPLAN proceedings style (sigplanconf.cls). PROGRAM CO-CHAIRS: * John Gallagher (Roskilde University, Denmark, and IMDEA Software, Spain) * Janis Voigtländer (Technische Universität Dresden, Germany) PROGRAM COMMITTEE MEMBERS: * Wei-Ngan Chin (National University of Singapore, Singapore) * Michael Codish (Ben-Gurion University of the Negev, Israel) * Jim Cordy (Queen's University, Canada) * Nate Foster (University of Pennsylvania, USA) * Haifeng Guo (University of Nebraska at Omaha, USA) * Patricia Johann (University of Strathclyde, UK) * Oleg Kiselyov (FNMOC, USA) * Günter Kniesel (University of Bonn, Germany) * Viktor Kuncak (Ecole Polytechnique Fédérale de Lausanne, Switzerland) * Yanhong Annie Liu (State University of New York at Stony Brook, USA) * Andres Löh (Utrecht University, Netherlands) * Jan Midtgaard (Roskilde University, Denmark) * David Monniaux (National Center for Scientific Research (CNRS) and VERIMAG laboratory, France) * Akimasa Morihata (University of Tokyo, Japan) * Alberto Pettorossi (Università di Roma Tor Vergata, Italy) * João Saraiva (Universidade do Minho, Portugal) * Ganesh Sittampalam (Credit Suisse, UK) * Fausto Spoto (Università di Verona, Italy) * Harald Søndergaard (University of Melbourne, Australia) * Walid Taha (Rice University, USA)

1 0

A voyage of undiscovery
by Bernie Pope 17 Jul '09

17 Jul '09

2009/7/17 Andrew Coppin <andrewcoppin(a)btinternet.com>: > I've been working hard this week, and I'm stumbled upon something which is > probably of absolutely no surprise to anybody but me. > > Consider the following expression: > > (foo True, foo 'x') > > Is this expression well-typed? > > Astonishingly, the answer depends on where "foo" is defined. If "foo" is a > local variable, then the above expression is guaranteed to be ill-typed. > However, if we have (for example) > > foo :: x -> x > > as a top-level function, then the above expression becomes well-typed. Some useful reading material: Section 22.7 of the book "Types and Programming Languages" by Benjamin Pierce. The classic paper "Basic Polymorphic Typechecking" by Luca Cardelli: http://lucacardelli.name/Papers/BasicTypechecking.pdf Both of these are very readable introductions to the let-style polymorphism found in the Hindley/Milner type system. Haskell's type system is essentially an elaboration of that idea. Pierce's book shows how to achieve let-polymorphism by inlining non-recursive let bindings during type checking/inference, which is a nice way to understand what is going on.

1 0

Atom resources
by Thomas DuBuisson 17 Jul '09

17 Jul '09

The wiki [1] where Atom [2] once lived has been gone for some time now. The only resources I know for Atom are a couple blog posts, the haddock docs, and the Atom source on patchtag. Is anyone aware of other resources? Tom [1] http://funhdl.org/wiki/doku.php [2] http://hackage.haskell.org/package/atom

3 3