- Haskell - Haskell.org

WAIT 2003: Call For Papers
by WAIT 2003 14 Feb '03

14 Feb '03

---------------------------------------------------------------------- CALL FOR PAPERS 32 JAIIO - WAIT 2003 Argentinian Workshop on Theoretical Computer Science Buenos Aires - Argentina September 1-5, 2003 ---------------------------------------------------------------------- The Argentinian Workshop on Theoretical Computer Science (WAIT) has become an important Latin American forum for the exchange of ideas and the presentation of research in theoretical computer science and its applications. The workshop aims are to build a bridge between academic and applied research and to stimulate the exchange of ideas and experience between theory and practise in computer science. The meeting includes contributed and invited talks, and tutorials. Further, we are very pleased to announce that there will be a special issue of ENTCS (http://www.elsevier.nl/locate/entcs) dedicated to WAIT 2003 publishing a selection of outstanding contributions. WAIT 2003 (http://wait2003.famaf.unc.edu.ar) the 7-th workshop in the series, will be held in Buenos Aires during September 1-5 (2003) as part of the 32-nd Argentinian Conference on Informatics and Operations Research (32 JAIIO, http://www.jaiio2003.uade.edu.ar) Buenos Aires (http://www.buenosaires.gov.ar/areas/turismo/en/) is a cosmopolitan and modern urban centre easily accessible by plane from most mayor cities in the world. The city is characterised by the multiplicity of its artistic expressions, ranging from the great assortment of sculptures and monuments to streets and corners that surprise with their allegorical reliefs and murals. The climate of Buenos Aires ---oceanic and warm--- is mild all year round, allowing visitors to discover the city on foot in any season. The city offers all categories of accommodation, and food ---which is something of a cult--- is of high quality. TOPICS Submissions are welcome in all fields of Theoretical Computer Science. Specific topics of WAIT 2003 include (but are not limited to): * Logical and algebraic foundations of computer science (logics for computation, category theory, relation algebras, type theory); * Formal methods (formal specification of sequential and concurrent programs, analysis, verification and transformation of programs, model checking); * Algorithms and data structures (sequential, parallel, distributed and on-line computing, probabilistic algorithms); * Automata theory and computational complexity; * Symbolic and algebraic computation; * Quantum Computing; * Bioinformatics. Submissions are expected to contain original research and will be refereed by international experts. Research papers must contain previously unpublished results. They will be judged on the base of originality and importance of their contributions and clarity of presentation. Papers should not exceed 12 pages, including figures and references. PROGRAM COMMITTEE: Martin Abadi (University of California at Santa Cruz) Gilles Barthe (INRIA Sophia-Antipolis) Gabriel Baum (Universidad de La Plata) Veronica Becher (Universidad de Buenos Aires) Vincent Danos (CNRS, Paris VII) Peter Dybjer (University of Gothenburg) Roberto Di Cosmo (PPS, Paris VII) Esteban Feuerstein (Universidad de Buenos Aires) Marcelo Fiore (Cambridge University) (co-chair) Daniel Fridlender (Universidad de Cordoba) (co-chair) Joos Heintz (Universidad de Buenos Aires) Gonzalo Navarro (Universidad de Chile) Peter O'Hearn (QMW, University of London) Alfredo Viola (Universidad de la Republica) IMPORTANT DATES: Deadline for reception of papers.................................May 4 Notification of acceptance.....................................June 27 Deadline for reception of the final version....................July 18 INSTRUCTIONS FOR AUTHORS: To facilitate the dissemination of papers and results, authors are invited to submit their papers in English. However, papers in Spanish or Portuguese are also welcome. Accepted contributions will be published in the Proceedings of the 32 JAIIO. Further, a selection of outstanding contributions will be invited to be published (in English) in a special issue of ENTCS dedicated to WAIT 2003. Papers should respond to ENTCS format (obtainable from http://math.tulane.edu/~entcs/) or similar, and must be submitted electronically in PostScript format (ghostview-readable) or PDF to the following e-mail address: wait2003(a)famaf.unc.edu.ar. Authors should communicate in a separate e-mail (in ASCII format) the title of the paper together with a short abstract, name and affiliation of all co-authors and their e-mail addresses, phone and FAX numbers. The message should also contain a list of keywords describing the area of the paper. ----------------------------------------------------------------------

1 0

RE: Yet another weakly defined bug report
by Simon Marlow 14 Feb '03

14 Feb '03

> What is the limit on open files, and why? I think it'd be nice to > just schedule a huge amount of IO operations, and have them all be > performed when required (i.e. when the FM is first accessed). > Apparently, my addDir took the trouble to open the files, but not > generate the FMs -- any idea why? The limit is imposed by the OS, and is usally tunable. Try 'ulimit -a' on a Unix box (the command might be different depending on your shell; check the manpage). readFile must *open* the file strictly, because it has to raise an exception if any errors occur. But thereafter, all reading is done lazilly. If you also want the open to be lazy, then use unsafePerformIO. It's Your Funeral, as we say in GHC land ;-) Cheers, Simon

1 0

RE: Yet another weakly defined bug report
by Simon Marlow 14 Feb '03

14 Feb '03

> > These things are always tricky to understand, which is why > I recommend > > not using lazy I/O. File reading is not a pure operation: > running out > > of file descriptors is a good counter-example. > > Without saying wether I agree with lazy I/O or not, I suggest that > this particular problem may also be due to the runtime implementation: > If one tries to open a new file but the file descriptors are > exhausted, > the runtime system should first trigger a full GC because that might > free up some descriptors -- but maybe GHC is already doing this? GHC could do this, but it doesn't. Nevertheless, it wouldn't help in Ketil's example: no amount of GC is going to free up the file descriptors which are being held on to because the program hasn't completely evaluated the file contents yet. Cheers, Simon

1 0

FSTTCS'03 First Call for Papers (postscript version is attached)
by FSTTCS 13 Feb '03

13 Feb '03

[Our apologies if you receive this more than once.] ====================================================================== CALL FOR PAPERS 23rd conference on FOUNDATIONS OF SOFTWARE TECHNOLOGY AND THEORETICAL COMPUTER SCIENCE (FSTTCS '03) December 15--17, 2003 Indian Institute of Technology, Bombay, India ===================================================================== The Indian Association for Research in Computing Science, IARCS, announces the 23nd Annual FSTTCS Conference in Mumbai. The FSTTCS conference is a forum for presenting original results in foundational aspects of Computer Science and Software Technology. The conference proceedings are published by Springer-Verlag as Lecture Notes in Computer Science (LNCS). Authors are invited to submit papers presenting original and unpublished research in any area of Theoretical Computer Science or Foundational aspects of Software Technology. Representative areas include, but are not limited to: Automata, Languages and Computability Automated Reasoning, Rewrite Systems, and Applications Combinatorial Optimization Computational Geometry Computational Biology Complexity Theory Concurrency Theory Cryptography and Security Protocols Database Theory and Information Retrieval Data Structures Graph and Network Algorithms Implementation of Algorithms Logic, Proof Theory, Model Theory and Applications Logics of Programs and Temporal Logics New Models of Computation Parallel and Distributed Computing Programming language design Randomized and Approximation Algorithms Real-time and Hybrid Systems Semantics of Programming Languages Software Specification and Verification Static Analysis and Type Systems Theory of Functional and Constraint-based Programming In addition, there will be workshops at IIT Bombay following FSTTCS'03 on some current areas of research (topics to be announced on the conference web page). The following two conferences on related areas will be also be held in Mumbai between 9 and 13 December 2003: International Conference on Logic Programming (ICLP'03) and ASIAN'03. Submission Guidelines ===================== Authors may submit drafts of full papers or extended abstracts. Submissions are limited to 12 pages in LNCS style (see the conference site for full details). Proofs omitted due to space constraints may be put into a clearly marked appendix. Electronic submission is very strongly recommended. For details, please look at the conference site: http://www.fsttcs.org For an accepted paper to be included in the proceedings, one of the authors must commit to presenting the paper at the conference. Important Dates =============== Submission deadline: 1 July 2003 Notification: 15 August 2003 Final Version due: 15 September 2003 Conference Site: http://www.fsttcs.org/ ================ Program Committee: ================== R Alur (University of Pennsylvania) V Arvind (IMSc, Chennai) M Charikar (Princeton University) T Dey (Ohio State University) J Esparza (University of Stuttgart) S Ghosh (TIFR, Mumbai) M Halldorsson (University of Iceland) J Radhakrishnan (TIFR, Mumbai, co-chair) H Karloff (AT&T Labs--Research) K Lodaya (IMSc, Chennai) PB Miltersen (BRICS, Aarhus) J Mitchell (Stanford) P O'Hearn (Queen Mary, London) PK Pandya (TIFR, Mumbai, co-chair) S Prasad (IIT Delhi) SK Rajamani (Microsoft research, Redmond) S Sen (IIT Delhi) D Sivakumar (IBM, Almaden) G Sivakumar (IIT Bombay) Th Wilke (University of Kiel) U Zwick (Tel Aviv University) Communication: ============== Attn: FSTTCS School of Technology and Computer Science Tata Institute of Fundamental Research Mumbai 400 005 India fsttcs(a)tifr.res.in Phone: +91 22 2215 2971 Fax: +91 22 2215 2110

1 0

Re: Learning Haskell moved
by Matthew Donadio 13 Feb '03

13 Feb '03

>> I would add some significant papers, such as John Hughes' >> "Why functional programming matters", etc. > >I've added that paper to the introduction. Other suggestions are welcome. "Conception, Evolution, and Application of Functional Programming Languages", Paul Hudak, ACM Computing Surveys, Volume 21, Number 3, pp.359-411, 1989 This would probably be good, too. --Matthew Donadio (m.p.donadio(a)ieee.org)

1 0

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