December 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

from array update algorithm to nice Haskell code
by Wolfgang Jeltsch 10 Jan '04

10 Jan '04

Hello, I have an algorithm which updates one or more arrays in a loop. The update operations depend on the (old) contents of the arrays, so I cannot use accumArray. I want to implement this algorithm without mutable arrays in Haskell. Are there any possibilities to do so efficiently? Are there some hints about how to do this? Wolfgang

3 8

class ??? with Haddock
by Wolfgang Jeltsch 07 Jan '04

07 Jan '04

Hello, I have a datatype Relation element1 element2 which derives an Eq instance. In the Haddock-generated documentation the instances section of Relation says (Ord element1, Ord element2, ??? element1 element2) => [...]. Why does Haddock generate this mysterious ??? element1 element2 context? Wolfgang

2 4

no continuations
by Scott 01 Jan '04

01 Jan '04

Why does Haskell have no continuations? (http://www.haskell.org/hawiki/CoMonad) If continuations are incompatible with non-strict semantics, I'd appreciate an explanation.

6 7

safe array freezing?
by John Meacham 31 Dec '03

31 Dec '03

so, A common idiom when using Control.Monad.ST is to do some complicated, state using computation to compute a big array which is then used purely functionally as a read-only array in the rest of the program. to avoid the cost of copying the array at the end, we are forced to use 'unsafeFreeze'. it occurs to me that this particular idiom can actually be done safely, by adding the following... runSTArray :: (forall s . (ST s (STArray s i e))) -> Array i e runSTUArray :: (forall s . (ST s (STUArray s i e))) -> UArray i e now, since these discard 's' and hence the ability to modify the arrays they return, they may safely use the final arrays directly as if they were immutable. the routines are also very easy to implement: runSTArray st = runST $ st >>= unsafeFreeze runSTUArray st = runST $ st >>= unsafeFreeze so, is my logic correct? that runSTArray and runSTUArray need not be considered unsafe? if so, perhaps we should add these (or some better generalization that someone comes up with) to the standard libraries, as it would be nice to be able to use this idiom without resorting to trickery. (well, user visible trickery at least) John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 1

long lines of code with Haddock
by Wolfgang Jeltsch 31 Dec '03

31 Dec '03

Hello, Haddock 0.6 produces output where code generated from non-comment source (like the declarations in the synopsis) is not split across multiple lines. Since my type declarations are rather long, the Haddock-produced lines get much larger than my screen when shown in a web browser. How can I make Haddock split these lines and maybe even indenting lines to produce a nice layout? The documentation of the hierarchical libraries seems to use an automatic line breaking feature. Wolfgang

2 1

efficiency of FiniteMap and Set
by Wolfgang Jeltsch 31 Dec '03

31 Dec '03

Hello, is there some documentation about the complexity of the FiniteMap and Set operations? Wolfgang

2 1

Re: no continuations
by Amr A Sabry 30 Dec '03

30 Dec '03

Kevin S. Millikin <kmillikin(a)atcorp.com> wrote: > Oh, sure. I didn't mean to quibble with the idea that continuations > are computational effects. Just wanted to point out that (I think) you > can't macro express mutation with call/cc, unless you've already got > mutation anyway. That's right: call/cc alone can't express assignments. But shift + reset will give you assignments. See Gunter, Remy, and Riecke, FPCA 95 for a clever encoding. --Amr

1 0

RE: no continuations
by Kevin S. Millikin 30 Dec '03

30 Dec '03

On Tuesday, December 30, 2003 3:10 PM, Ben Rudiak-Gould [SMTP:benrg@dark.darkweb.com] wrote: > Interesting. > > This still violates referential transparency, though. (c 'get) returns > a value or errors out depending on whether (c 'set) has been called yet. Oh, sure. I didn't mean to quibble with the idea that continuations are computational effects. Just wanted to point out that (I think) you can't macro express mutation with call/cc, unless you've already got mutation anyway. > And take a look at this! > > > (define c (make-cell)) > > (define d c) > > ((d 'set) 9) > > (d 'get) > > Error in car: #<procedure> is not a pair. > Type (debug) to enter the debugger. > > Something very nasty is going on here. I'm not sure exactly what it > is, but I think at least one of the define statements is getting executed > at least twice. Yup. If you do that, you can use d as your setter and c as your getter: > (define c (make-cell)) > (define d c) > ((d 'set) 9) > (c 'get) 9 > ((d 'set) 17) > (c 'get) 17 Does this help?: > (define c (let ((cell (make-cell))) (display "Hi, Ben.") (newline) cell)) Hi, Ben. > (define d c) > ((d 'set) 9) Hi, Ben.

1 0

RE: no continuations
by Kevin S. Millikin 30 Dec '03

30 Dec '03

On Tuesday, December 30, 2003 12:39 PM, Ben Rudiak-Gould [SMTP:benrg@dark.darkweb.com] wrote: > > With letrec and unrestricted call/cc you can implement ML-style refs: With an *implementation of letrec that uses mutation* and unrestricted call/cc, you can implement ML-style ref cells: Petite Chez Scheme Version 6.0a Copyright (c) 1998 Cadence Research Systems > (define-syntax letrec^ (syntax-rules () ((_ ((Var Exp)) Body Bodies ...) (let ((Y (lambda (f) ((lambda (g) (f (g g))) (lambda (g) (f (lambda (x) ((g g) x)))))))) (let ((Var (Y (lambda (Var) Exp)))) Body Bodies ...))))) > (letrec^ ((fact (lambda (n) (if (zero? n) 1 (* n (fact (- n 1))))))) (fact 5)) 120 > (define (make-cell) (call/cc (lambda (return-from-make-cell) (letrec^ ((state (call/cc (lambda (return-new-state) (return-from-make-cell (lambda (op) (case op ((set) (lambda (value) (call/cc (lambda (return-from-access) (return-new-state (list value return-from-access)))))) ((get) (car state))))))))) ((cadr state) 'done))))) > (define c (make-cell)) > ((c 'set) 3) > (c 'get) 3 > ((c 'set) 7) done > (c 'get) 3

2 1