November 2003 - Haskell

CfP: SNPD'03 Workshop on High-Level Approaches to Parallel and Distributed Computing
by Clemens Grelck 08 Jul '04

08 Jul '04

Please apologize in case you receive multiple copies of this information. ========================================================================== CALL FOR PAPERS Workshop on High-Level Approaches to Parallel and Distributed Computing held in the context of the Fourth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD'03) October 16th - 18th, 2003 Luebeck, Germany http://www.isp.uni-luebeck.de/snpd03/Workshop/ws02/index.htm ========================================================================== Scope and Topics: ================== Today parallel and distributed computing systems are readily available and provide a continuously improving price/performance ratio. However, this technological breakthrough in hardware is not accompanied by similar progress in software technology. Parallel and distributed programming is still dominated by low-level techniques such as explicit message passing. This low level of abstraction makes programming these systems exceedingly difficult, time-consuming, and error-prone. Hence, parallel and distributed computing requires new programming models which liberate programmers from low-level concerns and increase programming productivity while maintaining reasonable trade-offs between level of abstraction and runtime performance. Topics of interest include, but are not limited to - methodologies for high-level parallel programming, - parallel programming languages, - high-level libraries for parallel computing, - compilers and runtime systems for parallel computing, - implementation aspects of high-level parallel programming environments, - compiler-based optimization and parallelization, - experience with high-level parallel programming environments, - support for debugging and performance analysis, - concurrent array programming, - programming concepts for the grid. This workshop provides a forum for researchers and practitioners interested in the design, implementation, and evaluation of high-level parallel programming concepts. It aims at creating some focus within the otherwise broad spectrum of the SNPD'03 conference. Workshop Chair and Organizer: ============================== Clemens Grelck University of Luebeck Institute of Software Technology and Programming Languages Seelandstr. 1A 23569 Luebeck, Germany E-Mail: grelck(a)isp.uni-luebeck.de Papers and Publication: ======================== Original, unpublished papers in English not exceeding 8 pages in ACIS double column format are solicited. For detailed formatting instructions see the SNPD'03 conference web site at http://www.isp.uni-luebeck.de/snpd03/index.htm Please send your papers as PDF documents by electronic mail directly to the workshop chair: grelck(a)isp.uni-luebeck.de Please indicate your paper submission by the subject SNPD03 WORKSHOP SUBMISSION Accepted papers will be published in the conference proceedings with ISBN. A selection of excellent papers presented at the conference including its workshops will be published in a special issue of the International Journal of Computer and Information Science. Important Deadlines: ===================== Full paper submission due: August, 30th Notification of acceptance: September, 10th Camera-ready papers due: September, 24th

1 3

Fundeps discrepancy
by Ken Shan 18 Dec '03

18 Dec '03

Hello again, Please pardon another question on functional dependencies. GHC and Hugs behave differently on the following code: class Tr tr a b | tr -> a b where f :: tr -> a -> b class (Tr m a b, Tr n b c) => TrPair m n a c The type variable b on the second line does not appear in the head, but is determined by m and n in the head via the functional dependency declared for Tr. Hugs accepts this code, while GHC doesn't. The original fundeps paper (Mark Jones, ESOP 2000) seems silent on this point. Taking a step back, is there a formal description of type inference for functional dependencies in Haskell type classes? A set of typing rules, or something written along the lines of John Peterson and Mark Jones's "Implementing type classes" (PLDI 1993) or Mark Jones's "Typing Haskell in Haskell", would be wonderful to have. Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Tax the rich! new journal Physical Biology: http://physbio.iop.org/ What if All Chemists Went on Strike? (science fiction): http://www.iupac.org/publications/ci/2003/2506/iw3_letters.html

2 1

ANNOUNCE: Hugs98 November 2003 release
by Ross Paterson 03 Dec '03

03 Dec '03

We are pleased to announce a new release of Hugs98, an interpreter and programming environment for developing Haskell programs. Sources and binaries are freely available on the World-Wide Web. (Contributions of binary packages for other platforms would be welcome.) Feature highlights of this new release are: - More of the hierarchical libraries, including imprecise exceptions and unboxed arrays, giving greater compatibility with GHC. For now, compatibility with the old libraries is provided by stub modules, but users are encouraged to migrate to the new libraries. - The Double type is now double-precision on most architectures. - The -e, -f, -i, -N, -W and -X options are gone, as is the :project command. - Integrated .NET support (on Windows). - The beginnings of a User's Guide (still somewhat incomplete). - Numerous bug fixes since the previous major release in Nov 2002. The home page for Hugs is at http://haskell.org/hugs. Send email to hugs-users-request(a)haskell.org to join the hugs-users mailing list. Bug reports should be sent to hugs-bugs(a)haskell.org. Send email to hugs-bugs-request(a)haskell.org to subscribe to the hugs-bugs list. ------------------------------------------------------------------------------ The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the Yale Haskell Group, and the OGI School of Science & Engineering at OHSU, 1994-2003, All rights reserved. It is distributed as free software under the license in the file "License", which is included in the distribution. ------------------------------------------------------------------------------

5 6

ANN: H98 FFI Addendum 1.0, Release Candidate 16
by Manuel M T Chakravarty 01 Dec '03

01 Dec '03

Dear Haskell Folks, Release Candidate 16 of the H98 FFI Addendum 1.0 is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ Since the last version of the Addendum announced on <haskell(a)haskell.org>, namely RC12, the FFI Task Force decided on a slight generalisation of the interface to finalizers as well as the addition of some support for string marshalling for characters sets beyond ASCII. A detailed change log is at the end of this message. I'd like to propose RC16 as the final form of Version 1.0 of the FFI Addendum. If you find any problems with this version, please raise them within the next two weeks. Cheers, Manuel -=- Changes since RC15: * 6.3: Footnote regarding __STDC_ISO_10646__ added to text introducing `CWString'. Changes since RC14: * 6.2: CWChar -> CWchar * 6.3: - CWChar -> CWchar - Stated explicitly that memory allocated by `newCString' and friends can be deallocated by `MarshalAlloc.free' - Improved documentation Changes since RC13: * 5.3: Fixed typo * 5.7: Fixed a mistake in the type of `peekByteOff' and `pokeByteOff' (the type variable constrained by `Storable' must be different from the parameter of the `Ptr') * 6.3: Improved documentation Changes since RC12: * Acks : Added John Meacham * 4.1.5: Bug fix courtesy of Wolfgang Thaller * 5.5 : Added `FinalizerEnvPtr', `newForeignPtrEnv', and `addForeignPtrFinalizerEnv' * 6.3 : Added John Meacham proposal for `wchar_t' support as well localised string marshalling; in particular, this adds `CWString' and `CWStringLen' as well as the `CWString' and the `CAString' family of marshalling routines. In addition, `charIsRepresentable' was added.

1 1

Why are strings linked lists?
by Ben Escoto 30 Nov '03

30 Nov '03

Hi, can someone tell me why Haskell strings are linked lists? I have had some problems with Haskell strings: 1. Today I spend a few hours trying to track down a memory leak. It turns out I just didn't realize how much space a string takes up. On my machine "replicate 5000000 'a'" will use 90MB of space! 2. They are extremely slow for most operations like writing to disk, adding something to the end, concatenation, etc. 3. They make learning Haskell harder. Lazy IO functions like hGetContents are kind of slick in a shallow way, but I was confused about the Haskell IO model because I thought of this as the normal way IO was done, not something you could only set up through unsafeInterleaveIO or similar. Python's strings are also immutable, but they work great and are really convenient. They are apparently implemented as variable length arrays. -- Ben Escoto

20 33

Incomplete output when hPutStr is lifted
by andrew cooke 29 Nov '03

29 Nov '03

Hi, If I compile and run the code below, the file "foo" contains 10 lines of output (as I would expect), but the file "bar" contains just 9 - the final line is missing. If I add a "join", as in the comment, then all 10 lines appear. I don't understand why, completely - my best guess is that it's related laziness and the final result of the fold not being used. However, in that case, I'm worried that the "join fix" isn't guaranteed to work. Please could someone explain what is happening and how I should guarantee that the output is "complete". Thanks, Andrew $ cat test.hs main :: IO() main = do h <- openFile "foo" WriteMode foldM (printer h) 1 [1..10] hClose h h <- openFile "bar" WriteMode foldM (liftM2 (printer h)) (return 1) $ map return [1..10] -- join $ foldM (liftM2 (printer h)) (return 1) $ map return [1..10] hClose h printer :: Handle -> Int -> Int -> IO Int printer h n i = do hPutStr h (show n) hPutStr h ":" hPutStr h (show i) hPutStr h "\n" return (n+1) $ ghc test.hs $ ./a.out $ diff foo bar 10d9 < 10:10 -- personal web site: http://www.acooke.org/andrew personal mail list: http://www.acooke.org/andrew/compute.html

2 2

System.Posix (symbolic links)
by Johannes Goetz 29 Nov '03

29 Nov '03

Hi! Sorry for posting this message twice. Last message had wrong subject. Calling isSymbolicLink always returns False... (ghc-6.0.1linux binary tarball) It doesn't make a difference whether the symbolic link points to a regular file or a directory. Test code: #ln -s test link #ghc Test.hs -o test #./test False # Test.hs: module Main(main) where import System.Posix main = do status <- getFileStatus "link" print (isSymbolicLink status) Johannes

2 1

RE: How to best add logging/debugging code?
by Simon Marlow 28 Nov '03

28 Nov '03

> Manuel M T Chakravarty wrote: > > > There is `Debug.Trace.trace' for this: > > > > http://haskell.org/ghc/docs/latest/html/base/Debug.Trace.html > > > > However, if you want to log as opposed to debug, you may > > want to have the output go to somewhere else but stdout. > > Hence, it might be useful to have a variant of the `trace' > > that takes an explicit file handle in the library. > > Is there a list of problems anywhere with using trace? For > example does it affect evaluation order? You can think of the meaning of trace like this: trace e1 e2 <=> foldr seq () e1 `seq` e2 in other words, it deepSeqs the first argument and then behaves as the second argument. If you insert a trace with a literal string into your program, eg. trace "calling f" (f x) then it has no effect on the meaning of the program. Trace will only have an effect on the semantics of the program when you print out a value in the program: trace ("calling f with " ++ show x) (f x) in which case it will cause the value (x in this case) to be evaluated earlier than it would otherwise. If x turned out to be _|_, then the program might fail when it otherwise might not have. Cheers, Simon

3 2

Functional dependencies interfere with generalization
by Ken Shan 27 Nov '03

27 Nov '03

Hello, Consider the following code, which uses type classes with functional dependencies: {-# OPTIONS -fglasgow-exts #-} module Foo where class R a b | a -> b where r :: a -> b -- 1 rr :: (R a b1, R a b2) => a -> (b1, b2) rr a = (r a, r a) -- 2 data RAB a = RAB (forall b. (R a b) => (a, b)) mkRAB :: (R a b) => a -> b -> RAB a mkRAB a b = RAB (a, b) Neither 1 nor 2 passes the type-checker (GHC 6.0.1). The error messages are similar: Inferred type is less polymorphic than expected Quantified type variable `b2' is unified with another quantified type variable `b1' When trying to generalise the type inferred for `rr' Signature type: forall a b1 b2. (R a b1, R a b2) => a -> (b1, b2) Type to generalise: a -> (b1, b1) When checking the type signature for `rr' When generalising the type(s) for `rr' Inferred type is less polymorphic than expected Quantified type variable `b' escapes It is mentioned in the environment: b :: b (bound at Foo.hs:17) In the first argument of `RAB', namely `(a, b)' In the definition of `mkRAB': mkRAB a b = RAB (a, b) In both cases, the compiler is failing to make use of functional dependencies information that it has at its disposal. Specifically, it seems to me that, if two type variables b1 and b2 have been unified due to functional dependencies, making two constraints in the context identical, then the inner constraint ("inner" with respect to the scope of quantified type variables) should be ignored. Is there a technical reason why the type checker should reject the code above? Would it be possible to at least automatically define a function like equal :: forall f a b1 b1. (R a b1, R a b2) => f b1 -> f b2 for every functional dependency, with which I would be able to persuade the type checker to generalize (Baars and Swierstra, ICFP 2002)? I suppose I can use unsafeCoerce to manually define such a function... is that a bad idea for some reason I don't see? Thank you, Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Tax the rich! new journal Physical Biology: http://physbio.iop.org/ What if All Chemists Went on Strike? (science fiction): http://www.iupac.org/publications/ci/2003/2506/iw3_letters.html

2 2

Test
by onemind555 27 Nov '03

27 Nov '03

....

1 0