- Haskell - Haskell.org

Call for Contributions - HC&A Report (May 2003 edition)
by C.Reinke 24 Apr '03

24 Apr '03

Dear Haskellers, following the early reminder in the preface of the last edition, you've probably been waiting already, contribution in hand, eager to send it in for the May edition of our report (hey, editors can have their dreams, too!-), so here it is: *your* invitation to contribute to the fourth edition of the Haskell Communities & Activities Report http://www.haskell.org/communities/ These bi-annual HC&A Reports should give a birds-eye view of Haskell development over the last 6 months, and perhaps an outlook over concrete plans for the next 6 months. The current plan is to get contributions in by the end of April, and to get the collective report out early next month (some of you will find this an excellent opportunity to collect your thoughts about what to submit to this year's Haskell Workshop, btw;-). The general idea is to update all existing summaries (these reports are really about recent/current activities), to drop any topics that haven't had any activity for two consecutive 6-month periods, and to add any new developments or topics for which no-one contributed summaries to the previous edition, while trying to keep the whole from blowing up (last time, we ended up with about 30 pages). New suggestions for current hot topics, activities, projects, .. are welcome - especially with names and addresses of potential contacts, but here is a non-exclusive list of likely topics: General Haskell developments; Haskell implementations; Haskell extensions; Standardization and documentation; Haskell tutorials, how-tos and wikis; Organisation of Haskell tool and library development; Haskell-related projects and publications; Feedback from specialist mailing lists to the Haskell community as a whole; Haskell libraries or tools; Applications of Haskell; Haskell announcements; .. all (recent) things Haskell Announcements: if you've announced anything new on the Haskell list over the last six months, you'll want to make sure that is reflected in this edition. Project pings: if you're maintaining a Haskell tool/library/.., you'll want to let everyone know that it is still alive and actively maintained, even if there may have been no new additions. Tutorials: if you've fought with some previously undocumented corner of Haskell, and have been kind enough to write down how you did manage to build that networking program, or if you've written a tutorial about some useful programming techniques/patterns, this is your opportunity to spread the word (btw, short, topic-specific, and hands-on tutorials that only show how to achieve a certain practical task would do a lot to make things easier for new Haskellers - Erlang and Perl folks seem to be good at this kind of thing, but why not have a similar effort for Haskell?) Applications: if you've been working quietly, using Haskell for some interesting project or application (commercial or otherwise), you might want to let others know about it, and about your experiences using the existing tools and libraries; are you using Haskell on your job? Feedback: if you're on one of the many specialist Haskell mailing lists, you'll want to report on whatever progress has been made there (GUI API discussions, library organisation, etc.) If you're unsure whether a contact for your area of work has come forward yet, have a look at the report's potential topics page, or get in touch with me. I've contacted last time's contributors, hoping they will volunteer to provide updates of their reports, and will update the contacts on the topics page fairly regularly. But where you don't yet see contacts listed for your own subject of interest, you are very welcome to volunteer, or to remind your local community/project team/mailing list/research group/etc. that they really ought to get their act together and let the Haskell community as a whole know about what they've been doing!-) A typical summary report about a tool/library/project/application/.. would be between 1 and 3 paragraphs of ASCII text (what's it about? major topics and results since the last report? current hot topics? major goals for the next six months?) plus pointers to material for further reading (typically to a home page, or to mailing list archives, specifications and drafts, implementations, meetings, minutes,..). Browsing through previous editions should give you a good idea. Looking forward to your contributions, Claus -- Haskell Communities and Activities Report (May 2003 edition) All contributions are due in by the end of April 2003! http://www.haskell.org/communities/

1 0

FW: Library infrastructure
by Simon Peyton-Jones 23 Apr '03

23 Apr '03

Gentle Haskellers Haskell has now got a decent, hierarchical module system, supported by GHC, Hugs and NHC, and the library structure is now quite well populated. For example, here are the "base" libraries shipped with GHC (similar libraries come with Hugs and Nhc): http://www.haskell.org/ghc/docs/latest/html/base/index.html Languages flourish when libraries are plentiful, reliable, and well documented. In an open-source community like the Haskell community, plentiful libraries depend on contributions from the community. The difficulty is that it is currently not obvious what Joe Programmer should do to contribute a library to the community. I think this difficulty is a major obstacle to Haskell's progress, perhaps even the largest single obstacle today. One route to getting a library widely distributed is to get it into the "libraries" source tree used by GHC, Hugs, and NHC. That has the merit that the library will be distributed with each of these compilers. But it's too much of a "cathedral" approach. There is no way to distribute libraries between releases, and it makes the distributions ever larger and more complex for the GHC/Hugs/Nhc teams to build. To complement this, there ought to be an easy "bazaar" way for Joe Programmer to implement a library, build distributions, put them up on his web site for others to download, and add a link to some central library index so that people can find it. Sadly this is not an entirely simple task, because (a) the library should work on all Haskell implementations, and (b) should be packaged for binary installation on a variety of platforms (Windows, Linux, OpenBSD, Mac etc). Indeed, since GHC, Hugs and Nhc have different packaging mechanisms, there's a kind of (a)*(b) product involved. The bottom line is that today the obstacles are high enough to discourage all but the most motivated. What is needed is some kind of software infrastructure to automate the common tasks, and to give clear instructions about the non-automatable parts. This infrastructure should not be part of the (complicated) GHC (or Hugs, or Nhc) build systems; indeed, while it will certainly contain implementation-specific parts, its structure should be implementation independent. Simon Marlow emitted a message a while ago about this, but discussion petered out: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-November/thr ead.html#4322 The lack of this library-building infrastructure is a serious problem. Solving it, or even partially solving it, would be a huge step forward. So this message is really to try to kick-start the process again. Is anyone willing to invest effort in making this happen? It's probably a task that is too big for one person. I think what we need is A library-infrastructure Czar, who will a) do the core design and implementation b) coordinate the whole thing to make sure progress happens A bunch of library-infrastructure Supporters, who are willing a) to contribute thoughtfully to the design b) to implement pieces of it, for example pieces specific to one implementation (e.g. GHC) or one target architecture (e.g. PowerPC) Perhaps the first thing to do is to assemble list of people who would be willing to contribute as supporters (in the above sense), hoping that a Czar may then emerge by popular acclaim. Would you like to reply, perhaps to the 'libraries(a)haskell.org' list, so indicate interest. I really think this is important. If we do not collectively evolve a way to develop libraries in "bazaar" mode, I think Haskell will at best develop more slowly, and at worst wither away. Simon PS1: This is all distinct from the question of library *content* --- that is, what the module name, discussion about the signature of the exported types and functions are --- which does seem be handled OK by the 'libraries' list. This message concerns library-building *infrastructure*. PS2: Another entirely-orthogonal question is where library source code *lives*. One possibility is to use the same CVS repository that GHC/Hugs/Nhc use for libraries, albeit in a separate subtree. Perhaps fptools/user-libs/joe-bloggs/*. Another possibility is SourceForge. Finding backed-up CVS space for source code is not a problem.

9 10

RE: FW: Library infrastructure
by Simon Marlow 23 Apr '03

23 Apr '03

> > NO CODE WITHOUT DOCUMENTATION. > > > > But that would rule out just about every current Haskell library :P. > (Parsec being a wonderful counter-example) > > *sigh* I don't think that's entirely fair. Most of the libraries that come with GHC (and Hugs, and soon Nhc) are documented. See for example http://www.haskell.org/ghc/docs/latest/html/base/index.html Cheers, Simon

6 6

Testing for NaN
by George Russell 23 Apr '03

23 Apr '03

The standard trick would be: isNaN d = (d /= d) This will not distinguish between quiet and signalling NaN's, on the other hand I wonder why on earth you might be getting signalling NaN's anyway. (A signalling NaN normally corresponds to "badly formatted float". Some compilers give float values initial values of signalling NaN, to make it clear they haven't been initialised; the only other reason I can think of why your program might start having signalling NaNs is because of a cast from some other type. I don't think any arithmetic operations should emit a signalling NaN, unless it was given one.)

3 3

Re: FW: Library infrastructure
by Yoann Padioleau 23 Apr '03

23 Apr '03

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > Gentle Haskellers > > Haskell has now got a decent, hierarchical module system, supported by > GHC, Hugs and NHC, and the library structure is now quite well > populated. For example, here are the "base" libraries shipped with GHC > (similar libraries come with Hugs and Nhc): > http://www.haskell.org/ghc/docs/latest/html/base/index.html > > Languages flourish when libraries are plentiful, reliable, and well > documented. In an open-source community like the Haskell community, > plentiful libraries depend on contributions from the community. > > The difficulty is that it is currently not obvious what Joe > Programmer > should do to contribute a library to the community. > > I think this difficulty is a major obstacle to Haskell's > progress, > perhaps even the largest single obstacle today. I always find cvs difficult to use, why not put a wiki website for the library code where everyone could *easily* contribute. There needs some control, but simply not allowing a user to add some code that does not compile can do the tricks. -- Yoann Padioleau, INSA de Rennes, France, Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**

3 2

Haskell's syntax
by Arjan van IJzendoorn 22 Apr '03

22 Apr '03

Hello everyone, I teach Haskell to our first-year students and I find that Haskell's syntax is confusing to many. Some examples: (1) You define data types with vertical bars (|) but in the world of expressions vertical bars (i.e. guards) are exactly what you can not use to discriminate between constructors. (2) Pattern-matching and guards are very often mixed up. Both are used for making choices and they overlap somewhat but not completely in expression power. For learning a language it would be nice if one construct did it all, guards including pattern guards maybe. (3) Types and expressions look very much alike. Say we have: data Tree a = Bin (Tree a) a (Tree a) | Nil. Around half (!) of the students now write (on a written test): size (Bin (Tree left) x (Tree right)) = ... mixing up the two worlds completely. Do other teachers have the same experience? Regards, Arjan

7 7

Re: How to define an operator to show a sequence of polymorphic things
by Derek Elkins 22 Apr '03

22 Apr '03

>From: Bernd Holzmüller <holzmueller(a)ics-ag.de> >To: Haskell(a)haskell.org >Subject: How to define an operator to show a sequence of polymorphic things >Date: Tue, 22 Apr 2003 17:11:34 +0200 > >Hi all, > >I'd like to have a better way for "showing" a list of things, e.g. > >show (f1 t) ++ show (f2 t) ++ show (f3 t) ++ .... > >I would love to just write: (f1 # f2 # f3) t but I do not see how to define >an operator like # in Haskell without applying show over again on the first >arguments (i.e. f1 and f2). Because polymorphic lists are not possible, I >can not define # as to write [f1,f2,f3] # t either. > >Any idea? > >Regards, Bernd > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell x # r = show x ++ r end = "" 1 # True # 'a' # end ==> "1True'a'" _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Re: Haskell's syntax
by Arjan van IJzendoorn 22 Apr '03

22 Apr '03

Hello Peter, > I don't know why you mind the bar. It always denotes disjoint union. signum x | x < 0 = -1 | x == 0 = 0 | otherwise = 1 The guards are not disjoint and '|' is not an operator, it *begins* a guarded expression. > data Tree a = Bin (Tree a) a (Tree a) | Nil > > directly represents the domain equation whose least solution is > the semantics of Tree a. It cannot be written more clearly. :-) We're talking first-year students here. Greetings, Arjan

1 0

Call for participation ICALP2003
by icalp2003＠TUE.nl 22 Apr '03

22 Apr '03

> ------------------------------Call For > Participation----------------------- > We apologize for the reception of multiple copies of this message. > -------------------------------------------------------------------------- > -- > > > ICALP2003 > > Thirtieth International Colloquium on Automata, Languages and > Programming > > > Eindhoven, The Netherlands, June 30 - July 4, 2003 > > http://www.win.tue.nl/icalp2003/ > > DEADLINE FOR EARLY REGISTRATION MAY 28 > > The 30th annual meeting of the European Association of TheoreticalComputer > Science > will be held in Eindhoven, The Netherlands, at the Technische Universiteit > Eindhoven. > > As with the journal Theoretical Computer Science (TCS), the scientific > program of the Colloquium will be split into two parts: Track A of the > meeting will cover Algorithms, Automata, Complexity and Games, while > Track B covers Logic, Semantics and Theory of Programming. The full > program, > containing 84 accepted papers and 6 invited contributions is now > available at the ICALP2003 website ( > http://www.win.tue.nl/icalp2003/Schedule.html ). > > Invited speakers > > Jan Bergstra: Polarized process algebra and program equivalence > Anne Condon: Problems in RNA secondary structure prediction and design > Amos Fiat: Some issues regarding search, censorship, and anonimity in > peer to peer networks > Petra Mutzel: The SPQR-tree data structure in graph drawing > Doron Peled: Model checking and testing combined > Moshe Vardi: Logic and automata, a match made in heaven > > Workshops and surrounding events > > In the weekends preceeding and following ICALP2003 several workshops of > interest to the EACTS-community will be held at the conference venue, a > list is available at conference website > ( http://www.win.tue.nl/icalp2003/Workshops.html ). In the week before > ICALP (June 24-27), two more international conferences in computer > science are hosted by the TU Eindhoven at the same venue: the 24th > International Conference on Application and Theory of Petri Nets, ATPN > 2003, and the Conference on Business Process Management, BPM 2003. > Besides these scientific events, a number of other activities such as > excursions, a social event, a festive award presentation, and an event > on education in theoretical computer science are part of ICALP2003. For > a complete overview, see the "Events" section of the website > ( http://www.win.tue.nl/icalp2003/Events.html ). > > Venue > > Eindhoven is the fifth largest city in the Netherlands, with good > railconnections to the rest of the country and neighbouring countries. > It can be reached by train from Schiphol, the main airport of the > Netherlands, > in only 1.5 hours. The campus of the Technische Universiteit Eindhoven is > located in the centre of the city, within walking distance of the train > station and the conference hotels. > > > Registration > > The important dates for registration are: > Deadline for early registration May 28 > Deadline for late registration June 20 > > The conference website contains an online registration form which also > allows you to make reservations at the conference hotels > ( http://www.win.tue.nl/icalp2003/Registration.html ) > > > Contact information > > ICALP2003 Office > Technische Universiteit Eindhoven > Department of Mathematics and Computing Science > P.O. Box 513 > 5600MB Eindhoven > The Netherlands > > Telephone: +31 40 2474124 > Fax: +31 40 2475361 > E-mail: icalp2003(a)tue.nl > URL: www.win.tue.nl/icalp2003/ > > > > > >

1 0

Help! catching a (1.#QNaN)
by Cesar Augusto Acosta Minoli 21 Apr '03

21 Apr '03

1 0