- Haskell - Haskell.org

The 2006 ACM SIGPLAN Workshop on ML: Call for Participation
by Francois Pottier 11 Aug '06

11 Aug '06

********************************************************************* * The 2006 ACM SIGPLAN Workshop on ML * * * * September 16, 2006 * * * * Colocated with the 11th ACM SIGPLAN * * International Conference on Functional Programming (ICFP 2006), * * Portland, Oregon. * * * * Call for Participation * * * * http://gallium.inria.fr/ml2006/ * ********************************************************************* Programme 9:30-10:30: chaired by Andrew Kennedy Welcome Invited talk: Whole-Program Compilation for MLton Stephen Weeks 10:30-11:00 Break 11:00-12:30: chaired by Derek Dreyer ML Grid Programming with ConCert Tom Murphy VII Type-Safe Modular Hash-Consing Jean-Christophe Filliâtre and Sylvain Conchon Type-Safe Distributed Programming for OCaml John Billings, Peter Sewell, Mark Shinwell and Rok Strnisa 12:30-14:30 Lunch 14:30-16:00: chaired by Stephanie Weirich A Separate Compilation Extension to Standard ML David Swasey, Tom Murphy VII, Karl Crary and Robert Harper Leveraging .NET Meta-Programming Components in F# Don Syme Backtracking Iterators Jean-Christophe Filliâtre 16:00-16:30 Break 16:30-18:00: chaired by Matthew Fluet SEMINAL: Searching for ML Type-Error Messages Benjamin Lerner, Dan Grossman and Craig Chambers Type-Sensitive control-flow analysis John Reppy Ocsigen: Typing interaction with Objective Caml Vincent Balat Scope The ML family of programming languages, whose most popular variants are SML and OCaml, has inspired a tremendous amount of computer science research, both practical and theoretical, and ML continues to underpin a variety of applications, ranging from compilers and theorem provers to low-level system software. This workshop aims to provide a forum for discussion and research on existing and future ML and ML-like languages. Proceedings will be published by ACM Press and will appear in the ACM Digital Library. General Chairs and Program Chairs Andrew Kennedy Microsoft Research Ltd, 7 JJ Thomson Ave, Cambridge CB3 0FB, UK akenn(a)microsoft.com François Pottier INRIA Rocquencourt BP 105 78153 Le Chesnay Cedex FRANCE francois.pottier(a)inria.fr Programme Committee Derek Dreyer (Toyota Technological Institute at Chicago) Matthew Fluet (Cornell University) John Harrison (Intel Corporation) Haruo Hosoya (University of Tokyo) Andrew Kennedy (Microsoft Research Cambridge, co-chair) Eugenio Moggi (Università di Genova) Michael Norrish (National ICT Australia) François Pottier (INRIA Rocquencourt, co-chair) Ian Stark (University of Edinburgh) Alley Stoughton (Kansas State University) Jérôme Vouillon (CNRS and Université Paris 7) Stephanie Weirich (University of Pennsylvania)

1 0

ANN: hpc -- Haskell Program Coverage
by Colin Runciman 10 Aug '06

10 Aug '06

We are pleased to announce the first release of hpc, a new tool for Haskell developers. Hpc records and displays Haskell program coverage. It provides coverage information of two kinds: source coverage and boolean-control coverage. Source coverage is the extent to which every part of the program was used, measured at three different levels: declarations (both top-level and local), alternatives (among several equations or case branches) and expressions (at every level). Boolean coverage is the extent to which each of the values True and False is obtained in every syntactic boolean context (ie. guard, condition, qualifier). Hpc displays both kinds of information in two different ways: textual reports with summary statistics (hpc-report) and sources with colour mark-up (hpc-source). For further information and a tar-ball for hpc 0.2 see http://www.galois.com/~andy/hpc-intro.html Colin Runciman and Andy Gill

1 0

Smash your boiler-plate without class and Typeable
by oleg＠pobox.com 10 Aug '06

10 Aug '06

We describe a new generic programming approach, which is powerful enough to traverse a term and return another term of a different type, determined by the original term's type/structure. The example is a generic function that replaces all Floats with Doubles in an arbitrary term. The approach combines the features of the original `Scratch your boilerplate' (SYB1, presented at TLDI2003) and the third version SYB3 (ICFP05): -- like SYB1, our generic function is an ordinary function rather than a typeclass method. Unlike SYB3, the end user of our library defines no typeclasses. We do not need any extensions like recursive instances either. -- unlike SYB1, we need neither Typeable nor (safe) typecast -- unlike SYB1 and SYB3, we do not need higher-rank types -- like SYB3, the library needs overlapping and undecidable instances. Unlike SYB3, the end user needs no such extensions. In fact, the use of these extensions is confined to a small part of the library, namely, to the implementation of TypeEq. The essence of our approach is the _typelevel_ typecase. It is inspired by the deepest functor, which has http://okmij.org/ftp/Haskell/typecast.html#deepest-functor This message and code have greatly benefited from discussions with Chung-chieh Shan, who also suggested the title. Our generic function is composed of a specific and generic parts. A specific part tells us what to do if the input term happens to be of some particular type. The generic part tells us what to do with all other terms. The specific part is just an HList of ordinary functions, with different argument types. If the type of the input term matches the argument type of one of the functions in the list, we apply that function. If no specific function applies, we do the generic action, implicit in the traversal strategy (for example, apply the generic function to the subterms and reduce the results). Generic programming described in the original SYB1 paper introduced two fundamental ideas: -- generic functions like |gmapQl op seed f term|, which traverses an arbitrary term and applies the user-defined function f to each subterm and reduces the results with a left-associative operator op. -- generic function f that transforms arbitrary (sub)terms of arbitrarily types. That transformation is specified as a composition of specific transformations (which apply only to the values of some specific types) and a generic, default transformation for all other types. In SYB1, the function gmapQl is implemented as a method of a class Data; the SYB library provides instances for all (interesting) types. The function 'f', OTH, is essentially a `typecase' operator, to tell one specific type from the rest. SYB relies on a run-time typecase, depending on the run-time type representation -- which is provided by the typeclass Typeable. The typeclass also has the method `cast' for a safe cast from the value of `generic type' to the value of a specific type. We observe that the typecase, _on the type level_, has always existed in Haskell (although that fact was not perhaps realized until HList). That typecase, which does not need any `cast' operation, is the type equality predicate TypeEq. We consider here two classes of generic functions. The first class of generics takes a term and returns a value of some fixed type. The example is a generic size function, counting the number of data constructors in a term with the specific size measure assigned to values of particular types, e.g., strings. The second class of generics takes a term and returns a potentially different term -- in value as well as in type. For example, replacing Floats with Doubles or vice versa, or replacing all tuples of integers in a complex term with a 2-element array. Our first example uses a generic query function gmapq, which recursively traverses a term in the depth-first order, and applies reducer to the list of term's children. First, we define a function that counts the number of data constructors and values of primitive types in any term: > gsize a = gmapq SNil (\l -> 1 + sum l) a > test1 = gsize (1::Int) -- 1 > test2 = gsize [1::Int,2,3] -- 7 == 3 integers + three (:) + one [] > test3 = gsize "abc" -- 7, as above, with Char instead of Int > test4 = gsize ["abc"] -- 9: one extra (:) and one extra [] Now, we shall treat strings specially: we assign each string size 999. We only need a small modification to gsize': > gsize' a = gmapq (SCons (\ (_::String) -> (999::Int)) SNil) (succ . sum) a > test1' = gsize' (1::Int) > test2' = gsize' [1::Int,2,3] -- 7 > test3' = gsize' "abc" -- 999 > test4' = gsize' ["abc"] -- 1001 In a different example, we check if a given data structure contains somewhere the letter 'a' (or an integer with the 'a' code): > hasa a = gmapq (SCons (== 'a') (SCons (== (fromEnum 'a')) SNil)) or a > testh = (hasa ('x',False), > hasa ('x',97::Int), hasa 'a', hasa [[["cde"],["abc"]]]) > -- (False,True,True,True) For generic term transformations, we take the following term: > term1 = ([1::Int,2], (True,('2',[(3::Int,4::Int)]))) Let us increment all integers in that term: > inci a = gtmapq (HCons (\ (x::Int) -> x + 1) HNil) a > testi1 = inci term1 -- result: ([2,3],(True,('2',[(4,5)]))) Let us replace all Int tuples (x,y) with an array [x,y], and negate all booleans > p2l a = gtmapq (HCons (\ (x::Int,y) -> [x,y]) (HCons not HNil)) a > test_p2l = p2l term1 -- result: ([1,2],(False,('2',[[3,4]]))) Let us replace an Int with a Double everywhere > i2d a = gtmapq (HCons (fromIntegral::Int->Double) HNil) a > test_i2d = i2d term1 -- result: ([1.0,2.0],(True,('2',[(3.0,4.0)]))) The complete implementation along with the examples is available at http://okmij.org/ftp/Haskell/syb4.hs The following is the key part of the implementation of gmapq. First, we introduce a heterogeneous list of functions a->w where all functions in the list have the same return type w. The argument type 'a' varies from one list member to another. The property that each function in the list has the same result type is guaranteed by the construction of the datatype. > data SNil w = SNil > data SCons a b w = SCons (a->w) (b w) Given the datum of the type 'a', we check if any function in the list 'spec w' has the argument type 'a' and so can be applied. If there is such a function, we apply it. Otherwise, we return the default, the third argument of sapply. > class SApply spec a where > sapply :: spec w -> a -> w -> w > > instance SApply SNil a where > sapply _ _ deflt = deflt > > instance (TypeEq a a' bf, SApply' bf (SCons a' r) a) > => SApply (SCons a' r) a where > sapply = sapply' (undefined::bf) > > class SApply' bf spec a where > sapply' :: bf -> spec w -> a -> w -> w > > instance SApply' HTrue (SCons a r) a where > sapply' _ (SCons p _) x _ = p x > > instance SApply r a => SApply' HFalse (SCons a' r) a where > sapply' _ (SCons _ r) x deflt = sapply r x deflt

1 0

Foreign.Marshal.Alloc questions
by Chris Kuklewicz 09 Aug '06

09 Aug '06

For the allocation functions in Foreign.Marshall.Alloc, are the function contracts that return new pointers such that the pointers are never nullPtr, or is it prudent to always check the new ptr? I can see on GHC than allocaBytes uses newPinnedByteArray# but I have not tracked down the source file for that to read it. -- Chris Kuklewicz

1 0

AJAX applications in Haskell
by Dimitry Golubovsky 09 Aug '06

09 Aug '06

Hi, Pasqualino 'Titto' Assini wrote: =================== Assuming that the balance is positive, this naturally raises the question: why not doing the same <generate Javascript/Ajax application code to run in browser - DMG> with our favourite language? This would require to: - Retarget one of the existing Haskell compilers to generate JavaScript (other possible targets would be Flash or higher level UI languages such as OpenLaszlo that in turn compiles down to either Flash or JavaScript/HTML) =================== Joel Björnson wrote: =================== I am currently working on a Google Summer of Code project relating to some of this... The project is more or less bound to Haskell Server Pages ( http://www.cs.chalmers.se/~d00nibro/hsp/) enabling JavaScript code generation. The main difference compared to the Google Web Toolkit approach is that there are no special compiler magic added for compiling directly into JavaScript. =================== Looks like the idea is picked up by more and more people ;) I saw some notes on this (generation of Javascript from Haskell source) in Jared Updike's blog, and I got this idea myself independently from Jared in about the same time. I am trying to add some code to nhc98 (contrary to GHC its code is much smaller and better observable) to generate Javascript at the same time when STG tree is converted into bytecodes*. I am in the very beginning though, so I cannot show any results. OTOH I do not feel like I have a lot of time to dedicate to this, so if someone else is working on this, could we team up (possibly for a different (if shown better) approach because one I chose is still questionable optimization-wise, but generation of Javascript from bytecodes does not seem better to me at the time)? -------------- * Work in progress may be observed at http://www.golubovsky.org/repos/nhc98/ in particular in http://www.golubovsky.org/repos/nhc98/src/compiler98/STGJcode.hs but at the moment there is virtually nothing done. -- Dimitry Golubovsky Anywhere on the Web

1 0

Re: [Haskell] thread-local variables
by Frederik Eaton 08 Aug '06

08 Aug '06

> Furthermore, can we move this thread from the Haskell mailing list > (which should not have heavy traffic) to either Haskell-Café, or > the libraries list? Sure, moving to haskell-cafe. Frederik -- http://ofb.net/~frederik/

1 0

"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

deriving DeepSeq and deep strict fields proposals (Re[2]: [Haskell-cafe] How can we detect and fix memory leak due to lazyness?)
by Bulat Ziganshin 08 Aug '06

08 Aug '06

Hello Ki, Tuesday, August 8, 2006, 6:34:51 AM, you wrote: > Unfortunately seq and the strict data declaration is not helpful in general. > They are only helpful on base values such as Int or Bool. > What they do is just making sure that it is not a thunk. > That is if it was a list it would just evaluate to see the cons cell > but no further. > Someone wrote a deepSeq module for forcing deep evaluation, which is it was a proposal to add deepSeq to the language itself (just allow to automatically derive it by compiler, for example). we can add another proposal of implementing deep strict fields: data T = C !![Int] -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Contexts on Data Declarations
by Iavor Diatchki 05 Aug '06

05 Aug '06

Hello, I was just looking at the details of how contexts on datatypes work in Haskell'98 and I noticed the following. The report states that the context on a particular constructor should contain all those predicates that mention only variables that are in the fields of the constructor. This wording does not scale very well to mult-paramater type classes, and indeed Hugs (20050308) and GHC (6.4.1) do different things. Here is an example: > class C a b > > data C a b => T a b = Mk a According to Hugs, Mk :: a -> T a b, which follows the report: the constarint is not added because it mentions a variable, b, which is not in the fields of Mk. According to GHC, however, Mk :: C a b => a -> T a b, which also makes sense if we interpret the report to mean: "all those predicates that constrain a variable in the fields of the constructor". I know that contexts on data types are not a very popular part of the Haskell design, but it would be nice to be consistent. To me it seems that GHC's interpretation is the correct one. -Iavor PS: Appologies if this is fixed in later versions of Hugs, I don't have a newer version at the moment to try it out.

1 0

Call for Posters, APLAS 2006 (in Sydney, in November)
by Eijiro Sumii 03 Aug '06

03 Aug '06

CALL FOR POSTER PRESENTATIONS The Fourth ASIAN Symposium on Programming Languages and Systems (APLAS 2006) November 8-10, 2006 University of New South Wales, Sydney, Australia Deadline for Abstracts: September 11, 2006 APLAS 2006 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 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 (sumii AT ecei DOT tohoku DOT ac DOT jp). Links that may be useful for preparing good posters include: - http://www.kumc.edu/SAH/OTEd/jradel/Poster_Presentations/PstrStart.html - http://www.siam.org/siamnews/general/poster.htm REGISTRATION: Each presenter should e-mail a 1-2 page abstract in PDF or PostScript to the poster chair (sumii AT ecei DOT tohoku DOT ac DOT jp) by September 11th, 2006. The program of the poster session will be announced by September 22nd, 2006. We hope to accommodate every poster, but may restrict presentations (based on relevance and interest to the community) for the limitation of space. We may also need to cancel the session if there are too few presentations. IMPORTANT DATES: - 1-2 page abstract submission deadline September 11, 2006 - notification September 22, 2006 - conference November 8-10, 2006 CONTACT: For questions or requests, please contact the APLAS 2006 poster chair, Eijiro Sumii (sumii AT ecei DOT tohoku DOT ac DOT jp).

1 0