April 2003 - Haskell - Haskell.org

Re: Super Haddock (was Re: Literate Programming)
by Andy Moran 25 Apr '03

25 Apr '03

[ Simon moved the thread to cafe, but I note there is still some activity in the main list, hence the crosspost. ] On Friday 25 April 2003 02:34 am, Simon Marlow wrote: > Ketil Z. Malde writes: > > "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > Somebody else¹ wrote: > > >> This seems like a good way of transitioning from .lhs to > > >> haddock'd .hs. In the long run, I think we (meaning Simon :-) > > >> should to extend haddock to take the place of the .lhs style of > > >> documenting code. > > > > > > That's an interesting idea. It's not at all what Haddock > > > > was intended > > > > > for, but that's not to say it couldn't be done! > > > > I'm not sure I would like this. I guess I'm one of (the apparently > > very few?) who are using LaTeX lhs style (using \begin/\end{code}). > > Would a Haddock replacement give me the same kind of functionality in > > producing a nice printable copy? I definitely have grown attached to > > having math, footnotes, page headings, sections, and so on. > > Haddock isn't (intended to be) a literate programming system, so I don't > imagine it will replace full LaTeX literate source any time soon. The > suggestion is just that it could produce nicely-formatted source code > complete with lightly marked-up comments - which I think is a fine idea, > and not too difficult to implement using the existing framework. I just want to back Simon up here. My original post was intended to motivate a lightweight alternative to LaTeX lhs style, _not_ a replacement. I'm delighted that there are people that use literate Haskell. I don't: it's too unwieldy for my purposes. When documenting code for a small team of developers, when that code is fluid, and must be maintained, having professional, very attractive, browsable source code documentation is a wonderful thing. When you can produce that documentation with such minimal mark-up, it's going to get used. Cheers, Andy -- Andy Moran Ph. (503) 526 3472 Galois Connections Inc. Fax. (503) 350 0833 3875 SW Hall Blvd. http://www.galois.com Beaverton, OR 97005 moran(a)galois.com

1 0

[ OT ]: unsubscribe without password?
by oliver＠first.in-berlin.de 25 Apr '03

25 Apr '03

Hello, the listserv-help does not help me to unsubscribe. How can I unsubscribe, when I've forgotten my password (it's on an old hard-disk, which is not available now...)? Ciao, Oliver

1 0

problems invoking haddock
by Andre W B Furtado 25 Apr '03

25 Apr '03

I was not able to make Haddock run... Invoking it for a simple hello world example > module Main where > > main :: IO() > main = putStrLn "Hello World" gives me the following errors: Warning: module not found: Prelude Warning: Main: the following names could not be resolved: IO Prelude.() Fail: does not exist Action: openFile Reason: No such file or directory File: /usr/local/lib/haddock-0.4/haddock.css Using the option --no-implicit-prelude solves the first problem, but I wonder if this is the correct way to get around it. Using a specified stylesheet instead of the default one that comes with Haddock (--css=filename) solves the last problem, but introduces a new one: Fail: does not exist Action: openFile Reason: No such file or directory File: /usr/local/lib/haddock-0.4/haskell_icon.gif Putting /usr/local/lib/haddock-0.4 in the PATH does not solve the problem... Another attempt to invoke Haddock for other example such as module Test where test :: Int test = 3 gave me the problem: "Warning: Test: the following names could not be resolved: Int" Any ideas of what's going wrong? (My config: WindowsXP + GHC-5.04.2 + Cygwin) Thanks, -- Andre

1 0

Extracting values from several data constructors
by Steffen Mazanek 24 Apr '03

24 Apr '03

Hello. I am sure this question is not new. Even so, please give me the solution or point me to an old thread. How can I implement something like: data Test = T1 Int | T2 Int test::Test->Int test (_ x) = x Or is this impossible? In case of yes, why? This would save a lot of case differentiations in my application. Or is there an appropriate compiler option? Good night, Steffen

4 3

WAIT 2003: Deadline approaching
by WAIT 2003 24 Apr '03

24 Apr '03

---------------------------------------------------------------------- CALL FOR PAPERS 32 JAIIO - WAIT 2003 Argentinian Workshop on Theoretical Computer Science Buenos Aires - Argentina September 1-5, 2003 Deadline for reception of papers: May 4 ---------------------------------------------------------------------- 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

Literate Programming
by Steffen Mazanek 24 Apr '03

24 Apr '03

Hello. Simon Marlow wrote: >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 As far as I know (please correct me, if I err) one shortcoming of Haddock is its restriction to .hs-files. I think there are a lot of real literate programmers out there which would prefer a Haskell documentation tool for their literate Haskell scripts. Therefore I present the tool lhs2hs, which may seem very puristic and errorprone at this time (in fact it is). It transforms a .lhs-file into a .hs file. Furthermore tex-comments are used to pass information to e.g. Haddock: Example: %%Haddock:this function... %%Haddock:... >testfun... %%Haddock:another function... \begin{code} ... \end{code} This .lhs file becomes transformed to {-| this function... ... -} testfun... {-| another function... -} ... Ok, its simple, but it can be useful and it is extensible! I have attached the very first version. Type: ghc --make Main.lhs -package util -o lhs2hs ./lhs2hs -h Main.lhs haddock -h Main.hs latex Main.lhs Another idea to simplify literate programming with Haskell: allow XML (introduce a new file extension .xhs), e.g.: <hscomment describes="quicksort"> sorts a list </hscomment> <hsdecl defines "quicksort"> quicksort... </hsdecl> This would allow more transformations! Bye, Steffen

3 2

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