- Haskell - Haskell.org

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

Prototyping language extention
by Dmitry Malenko 10 Feb '03

10 Feb '03

Hi, All! As part of my research I'm going to create prototype system implementing some extentions concerning at most module system to the language and to toy with it a little. So I wonder what is the best way to do that? Should I cope with compiler sources, or write an interpeter from scratch, or maybe something else? Any thoughts or pointers would be apprciated. -- Best regards, Dmitry Malenko. +----------------------------------------------------+ Registered Linux user #258004 ALT Linux Team http://www.altlinux.ru +----------------------------------------------------+ Staff meeting in the conference room in %d minutes.

2 1

RE: filter and Prelude index in H98 report?
by Simon Peyton-Jones 10 Feb '03

10 Feb '03

No there isn't. Its in the revised version at http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-repor t-html/index.html I'll ask John to upload it. Simon | -----Original Message----- | From: Antony Courtney [mailto:antony@apocalypse.org] | Sent: 07 February 2003 22:04 | To: haskell(a)haskell.org | Subject: filter and Prelude index in H98 report? | | Hi all, | | Is there any deep reason why "filter" does not appear in the "Index of | the Haskell 98 Prelude", found at: | | http://www.haskell.org/onlinereport/prelude-index.html | | Thanks, | | -antony | | -- | Antony Courtney | Grad. Student, Dept. of Computer Science, Yale University | antony(a)apocalypse.org http://www.apocalypse.org/pub/u/antony | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

[OT] Teaching Haskell in High School
by Hal Daume III 09 Feb '03

09 Feb '03

Hi all, Before getting in to this, let me preface my question(s) with a note that I have checked through the Haskell in Education web page and have found various links off there of interest (and I've googled, etc. In short: I've done my homework). That said, I've been in rather close correspondence with my math/computer science teacher from high school. When I first took CS there, they taught Pascal (a year early they had been teaching Scheme). They switched over to VB (alas) recently and have been teaching that for a few years now. The teacher really wants to get away from VB, but is having a somewhat difficult time deciding what to go to. The two most promising options are Haskell and Java. Aside from hype, etc., the primary advantage to Java is that the Advanced Placement (AP) tests are in Java. For those of you unfamiliar with these, high school students can take AP tests and then (typically) skip out of first semester college courses. They're essentially proficiency exams. The way the computer science curriculum is set up at my old school is essentially as either (a) an elective or (b) a replacement for senior year math. The students in the course are usually about 2/3 juniors (16 year olds) taking it as an elective and 1/3 seniors who want to get our of senior year math :). Either way, they've both taken differential calculus, algebra, etc. Note, however, that high school math in the states is very rudimentary when it comes to things like "induction" and "proofs" and things of this sort. Due to the fact that CS is essentially an alternative math course, I think it would be interesting to teach Haskell. It would enable the instruction of things the students wouldn't have come across in their ordinary math studies, etc. However, I'm also well aware that Haskell is very difficult to learn (and, I'd imagine, to teach). Given that this would in large part be a first language for them and that they won't have a college-level math background, do you think it would be too much to attempt to teach Haskell at this level, and stick with Java? I'm really interested in any comments/experience/etc. that people have that might assist the teacher (and, to some extent, me) make this decision. Thanks in advance! - Hal

7 16

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

09 Feb '03

>>>>> "SM" == Simon Marlow <simonmar(a)microsoft.com> writes: >> Ha! After playing with this, I discovered that only the seconds were >> set and all other fields remained untouched. At least in ghc's >> implementation. Interestingly, TimeDiff derives Eq and Ord, but I'd >> better not ask for their implementation... SM> TimeDiff has a perfectly well-defined meaning for Eq and Ord: one SM> TimeDiff is equal to another iff all the fields are respectively equal. Yes, sure, Eq and Ord are defined by deriving (Eq, Ord, ...) but this does not make much sense if the representation for a particular duration is not unique. All I'm asking for is a unique representation for a duration and I do not see how you can do this using not uniquely defined terms like "month" and "year". As an aside, you can easily define convenience functions that map your (application's) idea of months and years to seconds, but it would be much harder the other way round. >> There is also a more fundamental problem with the TimeDiff data >> type. While seconds, minutes, hours, and days are clearly specified >> amounts of time, the duration of a month or a year may vary depending >> on the reference point where the time difference is applied. SM> This isn't a problem with the spec, I think. A TimeDiff of "1 month" is SM> precisely a difference, which, when added to a given ClockTime, produces SM> a ClockTime which is one month later (with respect to some timezone, SM> presumably UTC since it isn't specified otherwise). That is, January SM> 12th 12:00 UTC becomes February 12th 12:00 UTC, and so on. Adding one SM> month to certain ClockTimes is meaningless: eg. adding one month to SM> January 31st doesn't work. 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. My take would be to look at an established standard for expressing time durations (eg, ISO8601) and just adhere to that (but not the POSIX standard, please!). Personally, I think that it is unacceptable to make something like addToClockTime a partial function. SM> At least, that's how I believe it is supposed to work. GHC's SM> implementation *is* completely wrong (which is perhaps where some of the SM> confusion comes from), but the TimeExts library can be used instead of SM> TimeDiffs. Well, so you agree that the behavior of the Time module is unspecified! Of course, I'm not blaming GHC's implementation which cannot be right under these circumstances. >> My conclusion is that time differences really should be measured in >> seconds and picoseconds. >> >> type TimeDiff = (Integer, Integer) SM> We already have this kind of TimeDiff: just don't use anything except SM> the seconds and picoseconds fields. Indeed, I found by experimentation that diffClockTimes only fills in these two fields so that my attempt to compare the result with TimeDiff{ 0... tdDay = 14 ... 0 } was doomed. Unfortunately, the tdSec field has type Int, so its range is too small to be useful. SM> I agree with John Meacham in that it ought to be possible to get a raw SM> time in terms of seconds/picoseconds since the epoch, and indeed GHC SM> lets you do that: importing System.Time lets you get at the SM> representation of ClockTime: SM> data ClockTime SM> = TOD Integer -- Seconds since 00:00:00 on 1 Jan 1970 SM> Integer -- Picoseconds with the specified second SM> This is a perfectly reasonable definition of absolute time, we don't SM> need to talk about TAI at all, except to define what the epoch means. Agreed! So what is epoch? Is it "Seconds since 00:00:00 on 1 Jan 1970 [TAI]" ?

2 1

RE: time since the epoch
by Simon Peyton-Jones 09 Feb '03

09 Feb '03

| the haskell 98 time library is horribly broken, if you are using ghc, | you can deconstruct the time constructor which has an Integer containing | the number of seconds since epoch... otherwise you can use | ... | I dont supose this could be considered a typo in the haskell 98 report? | it is an embarasing thing for a language to not be able to do... Alas, no. CUP is, even as I type, printing the Haskell 98 Report. We'll have to think about how to accumulate further bugs/suggestions for H98. Meanwhile, I suspect there's an opportunity for someone (or a small group) to suggest a new Time library that really does the business, and provide an implementation. If it's sufficiently persuasive, all the implementations will adopt it and it can become a de-facto standard. The implementation is important because Time is a weird enough thing that only an expert can implement the spec! I think the current Time library suffered because no one who Really Cared about time was involved in its design or implementation. Simon

7 8