February 2003 - Haskell

ANNOUNCE: Learning Haskell portal, version 0.1
by Arjan van IJzendoorn 13 Feb '03

13 Feb '03

Hello all, Often we see messages from people who want to learn Haskell (something we applaud), but don't know where to begin. The Haskell homepage offers a lot of information, links and papers, but there is no page aimed specifically at beginning programmers. That's why I started to collect some links and put them on one single webpage. I thought about what the target audience would be interested in: getting an implementation, buying a book, reading course material, looking up functions in references and so on. The page I have now is a first start and I will work on it more. I've probably overseen many good tutorials, maybe a book here or there, listed an incorrect pro or con of an implementation and what not. Please tell me about it. If you have useful contributions ( nice slides, exercises with(out) solutions, some handout you give to your students which everyone could benefit from ) tell me about it, too. Enough talk: http://www.cs.uu.nl/~afie/haskell/LearningHaskell.html Cheers, Arjan PS: As one of the people in the Helium team I would not recommend beginners to use Helium yet. The absence of classes which leads to simpler types and messages is just not compatible with the text books and other teaching materials. Our plan is to add enough support for classes so that you can use the books without modification. This can be expected this summer. From that moment on, I will definitely recommend Helium to beginners since the feedback from the system is really great.

2 2

ANN: C->Haskell 0.11.1 "Powder Snow"
by Manuel M T Chakravarty 13 Feb '03

13 Feb '03

I am pleased to announce version 0.11.1 "Powder Snow" of the C interface generator C->Haskell. This is a source-only testing release, which introduces two major features: * Arbitrary C pre-processor directives can be included into a Haskell binding module. These will be placed into a custom C header file generated by C->Haskell. Moreover, any CPP conditionals will be honoured by C->Haskell when generating Haskell code from the binding module. This enables maintaining bindings to multiple versions of a C library in one binding module. * C code may be inlined into a Haskell binding module. This code will be emitted into the custom header file along with the CPP directives (the relative order of these components in the binding module is preserved). Moreover, there is now a mailing list for C->Haskell at c2hs(a)haskell.org (Visit <http://haskell.org/mailman/listinfo/c2hs/> to subscribe.) Version 0.11.1 is a testing release, which I am sure has bugs. Please discuss those on c2hs(a)haskell.org and not on the main Haskell list. More information as well as the source code is available from http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ Happy Hacking! Manuel

1 0

Re: Yet another weakly defined bug report
by ketil＠ii.uib.no 13 Feb '03

13 Feb '03

ketil(a)ii.uib.no (Ketil Z. Malde) writes: ketil(a)ii.uib.no (Ketil Z. Malde) writes: > Prelude> :r > phase `Literate pre-processor' failed (exitcode = 1) > I've no idea what trigged this, perhaps running out of file handles? I forgot: GHC version 5.04.1. It seems that this is definitely trigged by running out of file handles, so apparently, I did have an idea. ==== The following code runs out of file handles, so I am seeking enlightenment as to why. > -- | add data from a file to the histogram > addFile :: FiniteMap String Int -> String -> IO (FiniteMap String Int) > addFile fm name = do > x <- readFile name > return (addHist fm x) > > -- | add data from all files in a directory to the histogram > addDir :: FiniteMap String Int -> String -> IO (FiniteMap String Int) > addDir fm dir = do > dc <- getDirectoryContents dir > fs <- filterM doesFileExist (map ((dir++"/")++) dc) > foldM addFile fm fs Running addDir on a directory with few hundred files trigs it. Shouldn't all of each file's contents be consumed by each addFile, and thus the handle be released? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Re: Time since the epoch
by George Russell 12 Feb '03

12 Feb '03

Jonathan Coxhead wrote (quoting me, snipped) >> Add 1 minute to 23:59:60 31st December 2003. I assume that this is a valid > time >> and that it will be a leap second; if not choose some other year. >> >> This is complicated since we have multiple overflows. First stage you get the >> invalid time >> >> 23:60:60 31st December 2003. > > But **HERE**, you add 60 seconds. Why? If you want to add "1 minute" to > 23:59:60 31st December 2003, and assuming still that it is a leap minute, then > to be consistent with the rule for months, I think you ought to add **61** > seconds---the number of seconds in *this* minute. > > If the problem had been to add "60 seconds", I would agree, but if the > problem is to add "1 minute", I think there's a flaw here. Your arithmetic is faulty. Because we are assuming 23:59:60 31st December 2003 is a leap second, there are 61 seconds until 00:01:00 1st January 2004, the time my method (eventually) produces.

1 0

Re: Time since the epoch
by George Russell 12 Feb '03

12 Feb '03

Peter wrote (snipped) > As far as I read ISO8601 (which also has a notation for durations) > this is unspecifed :-) And as far as I read TimeExts.lhs it does some > sort of rollover. My take would be to specify the behavior for adding > something like a TimeDiff to a base date in a consistent manner and > then cast that in stone. If there is a (reasonable) standard for this > kind of calculation, then this should be the basis for the specification. OK, what TimeExts does, I hope, is add the appropriate amount of the appropriate time unit (whatever it is) directly, then rely on the CalendarTime conversions to resolve any overflows. This probably isn't very clear, so I'll give some examples of what I think ought to happen. Add 1 month to 1st February 2003. This produces 1st March 2003. (with no overflow.) Add 1 month to 31st January 2003. Then we get 31st February 2003. This clearly requires an overflow; we note that February 2003 has 28 days, and so roll over to 3rd March 2003. Note that in this case "Add 1 month" is not a monotonic operation. Add 1 minute to 23:59:60 31st December 2003. I assume that this is a valid time and that it will be a leap second; if not choose some other year. This is complicated since we have multiple overflows. First stage you get the invalid time 23:60:60 31st December 2003. I don't know what TimeExts (or rather the CalendarTime conversions) do in this case, but what I think they *ought* to do is work from the most significant unit down, rolling around to produce a significant date at each time. When we roll around, we have to bump the next unit, and iterate. So: 2003 OK. 2003 December OK. 2003 December 31st OK. 2003 December 31st 23 OK. 2003 December 31st 23:60 NOT OK. We bump the next unit and subtract this one, then we have to iterate from the top down. So we replace 23:60 by 24:00. and get 2003 December 31st 24 not OK. Replaces "31st 24" by "32nd 00". 2003 December 32nd not OK 2003 Unidecimber (13th month) 1st not OK 2004 January OK 2004 January 1st OK 2004 January 1st 00 OK 2004 January 1st 00:00 OK 2004 January 1st 00:00:60 Not OK. Replace 00:60 by 01:00 and you eventually get 2004 January 1st 00:01:00

3 4

RE: time since the epoch
by Simon Marlow 12 Feb '03

12 Feb '03

[snip] > It is always a problem to lump things with different semantics into > the same type :-) What I'm arguing is that there should be only one > fixed-duration offset datatype and it should be in terms of (seconds, > picoseconds). > Other fixed durations can be easily defined in terms of this > datatype. > I'm still not sure that you actually want base-dependent offsets, but > again they can be easily defined on top of the fixed duration > datatype. And they should be specified separately from the base > functionality. [snip] I wrote a reply, but I don't really have anything new to say over what's been said already, so I'll keep it brief instead. The copy of ISO8601 that I looked at is here: http://www.astroclark.freeserve.co.uk/iso8601/index.htm, but from what you said I'm guessing you're looking at a different version. Anyway, to sum up: - I agree that there should be a constant-duration time offset type. However, TimeDiff does actually fuction perfectly well as one at the moment, since diffClockTimes only fills in the seconds and picoseconds fields. - I believe a reasonable interpretation of the other fields of TimeDiff is as base-dependent offsets. The current implementation in GHC doesn't do this, but you can use TimeExts which does. - Our implementation of ClockTime uses C's gettimeofday(), which apparently is based a broken definition of the epoch. Oh well :-) Cheers, Simon

3 2

Deadline extended: EuroPar 2003, Topic 10
by Ch. A. Herrmann 11 Feb '03

11 Feb '03

Apologies if you receive multiple copies of this message. ----------------------------------------------------------------------- ****************************************************** *** *** *** LAST CALL FOR PAPERS *** *** Submission Deadline: February 16, 2003 *** *** *** *** EURO-PAR 2003 Topic 10 *** *** Parallel Programming: Models, Methods and *** *** Programming Languages *** *** *** *** Klagenfurt, Austria *** *** August 26-29, 2003 *** *** *** *** http://europar-itec.uni-klu.ac.at/ *** *** *** ****************************************************** Description This topic provides a forum for the presentation of the latest research results and practical experience in the development of parallel programs. Advances in algorithmic and programming models, design methods, languages, and interfaces are needed to produce correct, portable parallel software with predictable performance on different parallel and distributed architectures. The topic emphasises results that improve the process of developing high-performance programs, including high-integrity programs that are scalable with both problem size and complexity. Of particular interest are novel techniques by which parallel software can be assembled from reusable parallel components without compromising efficiency. Related to this is the need for parallel software to adapt, both to available resources and to the problem being solved. Where appropriate, contributions should demonstrate quantitative performance results in support of their claims, and address applications not adequately handled by well-established approaches. Focus * Languages, libraries and interfaces for different parallel programming models (e.g. data-parallelism, task-parallelism, functional, object-oriented, logic, component-based etc.). * Implementation and optimisation techniques for innovative parallel languages and programming models (e.g. threads, dataflow, tiling, skeletons, declarative languages, and generalised data-parallel approaches, etc.). * Performance models and their integration into the design of efficient parallel algorithms and programs (e.g. BSP, LogP, CGM, N-half and their alternatives, cost calculi and static performance prediction, profile-driven approaches). * Parallel programming paradigms and tools, their comparison and integration (e.g. data-parallel vs. task-parallel, coordination programming, performance analysis and debugging). * Methodological aspects of developing, optimizing and validating parallel programs (formalisms, semantics, specification, design, transformations, verification, etc.). * Software engineering for parallel and distributed systems (design patterns, portability, robustness, standardization, etc.). * Systematic approaches and programming models to support effective program development in grid environments. * Domain-specific parallel libraries and languages (e.g. for simulation, irregular and unstructured meshes, computational geometry, etc.). ----------------------------------------------------------------------- KEY DATES November 8, 2002 First call for papers February 9, 2003 Final date for submissions May 1, 2003 Notification of acceptance July 15, 2003 Early registration deadline ----------------------------------------------------------------------- PC COMMITTEE Global Chair Prof. José C. Cunha New University of Lisbon, Portugal Email: jcc(a)di.fct.unl.pt Vice Chairs Dr. Marco Danelutto University of Pisa, Italy Email: marcod(a)di.unipi.it Prof. Peter H. Welch University of Kent, United Kingdom Email: P.H.Welch(a)ukc.ac.uk Local Chair Dr. Christoph Herrmann Universität Passau, Germany Email: herrmann(a)fmi.uni-passau.de ----------------------------------------------------------------------- SUBMISSION DETAILS Authors are requested to submit their papers by using our submission site http://europar-itec.uni-klu.ac.at/submission.html (please indicate TOPIC 10). The site will open not later than at the beginning of January 2003. All accepted papers will be available at the conference in the proceedings published by Springer-Verlag in the LNCS series. ----------------------------------------------------------------------- MISSION STATEMENT EURO-PAR Euro-Par is the annual series of international conferences dedicated to the promotion and advancement of all aspects of parallel and distributed computing. Euro-Par 2003 will represent 19 topics in the categories of hardware, software, algorithms and applications. The conference normally attracts more than 300 participants coming from universities, research centres and industry. ---------------------------------------------------------------------- We are looking forward to receiving your paper submissions. Best regards -- Dr. Christoph Herrmann Teaching and Research Assistant University of Passau, Germany http://www.fmi.uni-passau.de/~herrmann

1 0

CFP for RULE 2003
by RULE'03 workshop 11 Feb '03

11 Feb '03

********************************************************** *** RULE 2003: RPD workshop *** *** JUNE, 9, 2003 *** *** Valencia, Spain *** *** *** *** http://www.dsic.upv.es/~rdp03/rule/ *** ********************************************************** Scope: ------ The rule-based programming paradigm is characterized by the repeated, localized transformation of a shared data object such as a term, graph, proof, or constraint store. The transformations are described by rules which separate the description of the sub-object to be replaced (the pattern) from the calculation of the replacement. Optionally, rules can have further conditions that restrict their applicability. The transformations are controlled by explicit or implicit strategies. The basic concepts of rule-based programming appear throughout computer science, from theoretical foundations to practical implementations. Term rewriting is used in semantics in order to describe the meaning of programming languages, as well as in the implementation of program transformation systems. It is used implicitly or explicitly to perform computations, e.g., in Mathematica, OBJ, or ELAN, or to perform deductions, e.g., by using inference rules to describe or implement a logic, theorem prover or constraint solver. Extreme examples of rule-based programming include the mail system in Unix which uses rules in order to rewrite mail addresses to canonical forms, or the transition rules used in model checkers. Rule-based programming is currently experiencing a renewed period of growth with the emergence of new concepts and systems that allow a better understanding and better usability. On the theoretical side, after the in-depth study of rewriting concepts during the eighties, the nineties saw the emergence of the general concepts of rewriting logic and of the rewriting calculus. On the practical side, new languages such as ASM, ASF+SDF, BURG, Claire, ELAN, Maude, and Stratego, new systems such as LRR and commercial products such as Ilog Rules and Eclipse have shown that rules are a useful programming tool. The practical application of rule-based programming prompts research into the algorithmic complexity and optimization of rule-based programs as well as into the expressivity, semantics and implementation of rules-based languages. The purpose of this workshop is to bring together researchers from the various communities working on rule-based programming to foster fertilisation between theory and practice, as well as to favour the growth of this programming paradigm. We solicit original papers on all topics of rule-based programming, including but not restricted to * Languages for rule-based programming o Expressivity o Semantics o Implementation techniques * Applications of rule-based programming o Analysis of rule-based programs o Programming methods * Environments for rule-based programming o (Partial) Evaluation o Abstract machines for rewriting * Combination of rule-based programming with other paradigms * System descriptions Submission procedure and publication: ------------------------------------- Submission process will be open in April 2003. Papers (of at most 15 pages) should be submitted electronically as PostScript or PDF files to one of the program committee chairs: Jean-Louis Giavitto (giavitto(a)lami.univ-evry.fr) or Pierre-Etienne Moreau (Pierre-Etienne.Moreau(a)loria.fr) The message should also contain a text-only abstract and author information. Accepted papers will be published and available during the workshop. After revision, final copies of the accepted papers will be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science. This will be confirmed in the second call for papers. Program committee co-chairs: ---------------------------- Jean-Louis Giavitto, Evry Val d'Essone University, France Pierre-Etienne Moreau, LORIA-INRIA Nancy, France Program Committee members: -------------------------- James Cordy, Queen's University at Kingston, Canada Olivier Danvy, BRICS, Denmark Steven Eker, SRI International, USA Thom Fruehwirth, Ulm University, Germany Berthold Hoffmann, Bremen University, Germany Herbert Kuchen, Muenster University, Germany Oege de Moor, Oxford University Computing Laboratory, England Przemek Prusinkiewicz, Calgary University, Canada Patrick Viry, ILOG, France ----------------------------------------------------------------------- IMPORTANT DATES ----------------------------------------------------------------------- April 6th 2003 Submission of full paper May 5th 2003 Notification May 14th 2003 Final version due June 9th 2003 RULE 2003

1 0

FiniteMap performance
by Magnus Lindberg 10 Feb '03

10 Feb '03

Hello! I am using the FiniteMap datatype and since Haskell never modifies variables but rather copies them (?) I wonder what the performance of the FiniteMap type is in Haskell. Lookup is of course done in O(log n) but is insertion done in O(n) or O(log n)? For example, does the function addToFM :: Ord key => FiniteMap key elt -> key -> elt -> FiniteMap key elt belong to O(n) or O(log n) (where n is the size of the map) ? If it belongs to O(n), aren't the maps really really useless? If it belongs to O(log n), how is this achieved? (my guess is that it is O(n) of course : ) Best regards, Magnus Lindberg

4 4

Re: time since the epoch
by Peter Thiemann 10 Feb '03

10 Feb '03

SM> TimeDiff isn't a "duration", it's a way of specifying time offsets whose SM> duration depends on the base to which the offset is being added. If we SM> only had constant-duration offsets, then there would be no way to say SM> "give me a ClockTime for this time next Wednesday". [nitpicking] Oops, this is not the purpose stated in the library report: "The TimeDiff type records the difference between two clock times in a user-readable way." Anyway, the sort of specification that you are talking about is really a pain IMHO. Actually, you could not use TimeDiff to state it, either. [ISO8601 allows it but I think it's too imprecise to be useful] SM> The problem is really that all the different kinds of offset are lumped SM> into one type: there ought to be a TimeDiffSeconds, TimeDiffMonths, and SM> so on. TimeDiffSeconds is a constant-duration offset, but SM> TimeDiffMonths isn't. The problem with lumping them into one type is SM> that if multiple components are non-zero, you don't know in which order SM> to add them. It is always a problem to lump things with different semantics into the same type :-) What I'm arguing is that there should be only one fixed-duration offset datatype and it should be in terms of (seconds, picoseconds). Other fixed durations can be easily defined in terms of this datatype. I'm still not sure that you actually want base-dependent offsets, but again they can be easily defined on top of the fixed duration datatype. And they should be specified separately from the base functionality. Certainly, differences between clock times should be in terms of the fixed-duration datatype. SM> The TimeExts library gives you separate differences like SM> these, BTW. That sounds good, I'll look at it again (it's pretty much bare code, so I might have overlooked something). >> Unfortunately, with UTC, this goes on to make adding *anything* except >> seconds to certain ClockTimes (namely the instants of leap seconds, >> eg, what happens if you add 1 minute to 23:59:60 ? This is a perfectly >> legal UTC time on a day with a leap second) meaningless. SM> That's right, and here I'm not sure whether the right behaviour is to SM> raise an exception or to "roll over" to the next nearest date/time. I SM> believe TimeExts does some kind of rolling over, but I'm not sure of the SM> exact semantics (George?). As far as I read ISO8601 (which also has a notation for durations) this is unspecifed :-) And as far as I read TimeExts.lhs it does some sort of rollover. My take would be to specify the behavior for adding something like a TimeDiff to a base date in a consistent manner and then cast that in stone. If there is a (reasonable) standard for this kind of calculation, then this should be the basis for the specification. SM> Ok, ISO8601 seems to specify only constant-duration time intervals, but SM> allows them to be given in terms of years, months, days etc., where a SM> month is specified to be 30 days, it seems, and similar SM> approximations If I remember correctly, then ISO8601 specifies durations up to a day, but bails out at months and years. >> >> Agreed! So what is epoch? Is it >> "Seconds since 00:00:00 on 1 Jan 1970 [TAI]"? SM> I guess so... GHC's implementation will be whatever the C library uses, SM> which I assume is the one you specified above (at least on a decent SM> implementation). Unfortunately, if you are using time(2), then you'll get rubbish (from the manual page): DESCRIPTION time returns the time since the Epoch (00:00:00 UTC, Jan uary 1, 1970), measured in seconds. [...] NOTES POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of seconds between a specified time and the Epoch, according to a formula for conversion from UTC equivalent to conversion on the naïve basis that leap seconds are ignored and all years divisible by 4 are leap years. This value is not the same as the actual num ber of seconds between the time and the Epoch, because of leap seconds and because clocks are not required to be synchronised to a standard reference. The intention is that the interpretation of seconds since the Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further rationale. The problem is that this notion of time is discontinuous and sometimes not strictly increasing. See the various references pointed out by members of the list for why this can be a problem. -Peter PS, I see you are trying to follow-up to haskell-cafe, but I'm not subscribed to that list.

1 0