August 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

RE: How overload operator in Haskell?
by Hal Daume 06 Nov '03

06 Nov '03

What you want to do is make your Vector an instance of the Num(eric) type class. For instance: instance Num Vector where (+) v1 v2 = zipWith (+) v1 v2 (-) v1 v2 = zipWith (-) v1 v2 negate v1 = map negate v1 abs v1 = map abs v1 (*) v1 v2 = ... fromInteger i = ... signum v1 = ... I've left the last three blank because it's unclear what should go there. Since (*) has type Vector->Vector->Vector (in this instance), you can't use dot product or something like that. signum :: Vector->Vector could be written and just return [-1], [0] or [1], I suppose. fromInteger :: Integer->Vector is a little harder. Perhaps just 'fromInteger i = [fromInteger i]' would be acceptable. Or you could leave these undefined. -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of Liu Junfeng > Sent: Wednesday, July 09, 2003 7:25 AM > To: haskell(a)haskell.org > Subject: How overload operator in Haskell? > > > I've learned haskell months, but I still can't understand the > type system very well. > I can only write: > ----------------------------------- > type Vector = [Double] > vadd,vsub :: Vector->Vector->Vector > v1 `vadd` v2 = zipWith (+) v1 v2 > v1 `vsub` v2 = zipWith (-) v1 v2 > svmul :: Double->Vector->Vector > s `svmul` v = map (s*) v > ------------------------------------ > Tough it works, it is not convenient to use. How to create a > Vector type and overload > mathematical operators? > Thanks for your help. > > Liu Junfeng > liujf(a)softhome.net > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

12 14

Enum on Float/Double
by George Russell 23 Oct '03

23 Oct '03

The situation with Enum on Ratio is pretty bad but at least it's not hopeless, since rational numbers are at least exact. But for Float/Double it seems to be a total disaster area. Since it seems to be impossible to abolish Enum Float/Double altogether, would it at least be possible to make it rather more useful, by making succ x return the next representable float after x (or x if x is non-finite) and pred x the previous representable float. This would (a) be useful; (b) make mathematical sense; (c) is tricky to implement with the existing primitives. Before someone else points it out, this is of course unimplementable should someone in the future implement infinite-precision reals in Haskell, but as (barring a solution to the halting problem) Eq would be as well, that does not bother me. My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Feri wrote > Everybody working with floats should know their quirks While in an ideal world, everyone who represented a mouse position or anything else as a float should have a PhD in numerical analysis, in practice they do not. Indeed I think the Haskell Library Report contains quite a few examples of floating point code which a numerical analyst would have written rather better. So I don't think it's good enough to treat every Float/Double operation as if it had an implicit "UNSAFE" flag indicating that the compiler was entitled to wierd behaviour only comprehensible to experts, as seems to be the case with floating enumerations now.

8 11

Haskell for non-Haskell's sake
by Hal Daume III 10 Sep '03

10 Sep '03

Hi fellow Haskellers, I'm attempting to get a sense of the topology of the Haskell community. Based on the Haskell Communities & Activities reports, it seems that the large majority of people use Haskell for Haskell's sake. If you use Haskell for a purpose *other than* one of those listed below, I'd love to hear. I don't need a long report, anything from a simple "I do" to a paragraph would be fine, and if you want to remain anonymous that's fine, too. Purposes which I consider "Haskell for Haskell's sake" include: - writing Haskell compilers/interpreters - developing libraries for Haskell - writing Haskell debuggers, tracers, profilers or other tools - more or less anything with matches /.*Haskell.*/, other than /in Haskell$/ :) Thanks, - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

27 29

proving the monad laws
by Steffen Mazanek 01 Sep '03

01 Sep '03

Hello, consider the following monad (which is a slight adaptation of the one used in "Typing Haskell in Haskell") as given: data Error a = Error String | Ok a data TI a = TI (Subst -> Int -> Error (Subst, Int, a)) instance Monad TI where return x = TI (\s n -> Ok (s,n,x)) TI f >>= g = TI (\s n -> case f s n of Ok (s',m,x) -> let TI gx = g x in gx s' m Error s->Error s) fail s = TI (\_ _->Error s) Now I would like to verify the monad laws. It is really easy to show that return is both a left- and a right-unit. But I got stuck with associativity: m@(TI mf) >>= (\a->f a >>= h) = = TI (\s n -> case mf s n of Ok (s',m,x) -> let TI gx = (\a->f a >>= h) x in gx s' m Error s->Error s) = ... = ((TI mf) >>= f) >>= h Is there someone outside who is willing to tell what fills the gap? A hint may be sufficient already. Or is there a tool, which finds such derivations? I have read the tutorial "All about Monads", but there only is mentioned, that there is an obligation for the programmer to prove these laws. It would be helpful as well, to provide an example! I was wondering, if it is possible to simplify: "let TI gx = f x >>=h in ...". But the "a" may occur in "h"? Thank you. Steffen

2 1

Re: Haskell for non-Haskell's sake
by Arun Kumar S Jadhav 31 Aug '03

31 Aug '03

Hi, Well, some time back I implemented PRE (Partial Redundancy Elimination) for C program in Haskell. The algorithm is fairly straightforward but involved some issues regarding how to represent the basic block information, graph etc. The haskell program itself can be improved though, but I'll take it up during december when my current term ends. Regards, Arun On Saturday 30 August 2003 06:09, Hal Daume III wrote: > Hi fellow Haskellers, > > I'm attempting to get a sense of the topology of the Haskell > community. Based on the Haskell Communities & Activities reports, it > seems that the large majority of people use Haskell for Haskell's sake. > > If you use Haskell for a purpose *other than* one of those listed below, > I'd love to hear. I don't need a long report, anything from a simple "I > do" to a paragraph would be fine, and if you want to remain anonymous > that's fine, too. > > Purposes which I consider "Haskell for Haskell's sake" include: > > - writing Haskell compilers/interpreters > - developing libraries for Haskell > - writing Haskell debuggers, tracers, profilers or other tools > - more or less anything with matches /.*Haskell.*/, other than > /in Haskell$/ :) > > Thanks, > > - Hal -- Arun Kumar S Jadhav Masters Student, SIC-309, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk ***************************** Never negotiate out of fear Never fear to negotiate ***************************** ------------------------------------------------------- -- Arun Kumar S Jadhav Masters Student, SIC-309, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk ***************************** Never negotiate out of fear Never fear to negotiate *****************************

1 0

Re: Haskell for non-Haskell's sake
by b.i.mills＠massey.ac.nz 31 Aug '03

31 Aug '03

I do research into parsing algorthms, and find that I can convert the theory into practice most easily in Haskell. A lot of the material is just (careful) transliteration of the original definitions. And more generally I go along with Vincenzo (aka Nick Name), > I use haskell when I have to write a program myself and quickly. but add to that "and robustly". I do write the occasional GUI in it, but mainly as an exercise to show I can do it in Haskell. In practice I write GUIs in C. But, even when I don't write in Haskell, I still use habits I've picked up from Haskell in other code. I think that practice in Haskell can improve clarity of programming in other languages. Regards, Bruce.

1 0

Subject: Re: unsafeInterleaveIO ordering
by Robert Ennals 30 Aug '03

30 Aug '03

[resending this mail from a different address as it didn't seem to get through the first time. I apologise if you see multiple copies.] [snip] > If you're using an eager haskell implementation which does some > speculative evaluation of things that look cheap and that you might want > to evaluate, the answer is probably no. (Because, having decided to do > some speculative work in the absence of a demand, it might decide it has > done enough work after the first action, and then later it would finish > the job when the result is actually demanded.) Actually speculative/optimistic evaluation should be fine. Optimistic Evaluation refuses to speculate IO for exactly this reason. If a speculative computation attempts to call unsafePerformIO or evaluate the IO from an unsafeInterleaveIO then the speculation is immediately aborted. IO is never speculated. Anyone wanting to find out more about optimistic evaluation is encouraged to download the ICFP'03 paper from here: http://www.cl.cam.ac.uk/users/rje33/publications.html Threads are still an issue, but that can be dealt with using locking. -Rob

1 0

RE: Haskell-report, chapter 3 - Expressions
by Simon Marlow 30 Aug '03

30 Aug '03

> I do not completely understand the first part of chapter 3 of the > Haskell-report. > Concretely I am stumbling about the notation of nonterminals > indexed by > their precedence > level. This should be a number ranging from 0 to 9. But what > about this exp^{10} production rule? The grammar is written using a kind of macro syntax, such that you can obtain the full grammar by expanding each of the rules for nonterminals with a superscript 'i' for each 'i' in the range 0 to 9. These rules then cover the grammar for expressions containing infix operators with precedences between 0 and 9. The '10' in the 'exp10' nonterminal doesn't refer to the precedence of an operator, it is there purely as a clue to to the reader that these expressions bind tighter than all the infix operators. Hope this helps. Cheers, Simon

2 1

unsafeInterleaveIO ordering
by Hal Daume 30 Aug '03

30 Aug '03

if i say: foo = do putStrLn "a" unsafeInterleaveIO (putStrLn "b" >> putStrLn "c") putStrLn "d" is it guarenteed that nothing will happen between putting "b" and "c"? that is, while the place/time at which the (putStrLn "b" >> putStrLn "c") is unspecified, is it the case that the whole thing will be done at once? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

4 3