September 2001 - Haskell

Haskell Communities Survey - Call for Contacts (update)
by C.Reinke 21 Sep '01

21 Sep '01

First, a big thanks to those of you who immediately volunteered to act as contact persons to their communities. That means that five of the areas are already covered. ******************************************* *** keep those contact offers coming!-) *** ******************************************* *** if you can't cover a whole area, status reports for any of *** *** the sub-areas listed can still be a good starting point *** To avoid duplication of work, and to remind everyone which areas are still looking for contact persons, here is my current list (note that there are more topics covered than contacts;-): Generic Programming/Generic Haskell [contact: Johan Jeuring] Hierarchical library proposal [contact: Simon Marlow] Happy [contact: Simon Marlow] Concurrent Haskell [contact: Simon Marlow] GHC [contact: Simon Peyton-Jones] Thanks also for the positive feedback - it seems that many of you have waited for something in this direction. There have been a few alternative suggestions as well, all of which could be pursued, if someone is willing to make a start. So I would like to pass on those suggestions to the list, with a few comments. - Tom Pledger points out the inevitable problems of a hierarchical structure, and suggests a keyword/phrase glossary instead, with definitions and links to project summaries, tending towards Wiki. I think Jan Sibinsky had started a nice glossary - unfortunately, he still seems to be offline? Has someone saved his work? As for Wikis, I've never been impressed with their apparent inability to self-organise, but we do have a Haskell Wiki, so everyone is welcome to prove me wrong there! Other structures for presenting the information might work (we'll see), but from my experience, it takes some active prodding and definite goals to get others to contribute. Hence the present structure for a start. - Ketil Malde suggests a web zine, with a group of people monitoring and summarising mailing list traffic. I'm not so sure about that specific mode (any volunteers out there?), but I do think that functional programming as a whole would profit from some kind of magazine-style publication, to bridge between the academic forums and the increasing number of (would-be) Haskell practitioners out there who have no need to conform to academic quality guidelines but would still want a quality forum more permanent and organised than mailing lists. Such a magazine would collect, edit and archive contributions about Haskell (or other FPLs) in practice, how to design, how to solve all those problems that are not really scientific in nature, but still need to be solved. I think many academics would be happy to contribute as well, focussing on their own role as practitioners. Many of those nice explanations on the mailing lists would no longer be lost to mailing list archives, and volunteer (that word again) reporters could write about interesting projects, events, etc.. That would still need some good and active editors in place (and twice a year there could be a special issue on Haskell, including the Haskell communities report;-). So a Haskell or FP web zine is a good idea, and complementary to the report we are trying to get together now. - Last, but certainly not least, Andrei Serjantov supports the idea of a separate mailing list for applications of Haskell discussions, pointing out that some potential posters to the current lists are unsure whether their own questions and contributions have any place amongst those highly technical discussions about advanced language extensions or recent implementation details. AFAIC, those "other" contributions are welcome as well on the current lists, but a separate applications list would still make a lot of sense (I would subscribe). Just remember that anything good needs volunteers to get things started (without them, we wouldn't have the language&library reports, not to speak of implementations). And that means you, dear reader!-) I'll be at IFL next week, but keep those contact offers coming! Claus

1 0

Re: Prelude and (:) and []((:), []) bugs?
by Marcin 'Qrczak' Kowalczyk 21 Sep '01

21 Sep '01

20 Sep 2001 12:37:36 -0600, Alastair David Reid <reid(a)cs.utah.edu> pisze: >> Ah, I forgot that you can't export a constructor on its own. > > You can't? > > I probably knew this once but looking at it now, it seems kinda > surprising. Haskell's module system is supposed to be just namespace > control --nothing more-- so why is it preventing me from doing > something which is perfectly safe and well-defined? It's ambiguous whether you mention a value constructor or a type constructor / class. They are in separate namespaces and distinguished by context in normal source, but the export list doesn't provide the context. There is a strange exception that you can *hide* value constructors directly. Hiding a name beginning with uppercase applies to all relevant namespaces. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Prelude and (:) and []((:), []) bugs?
by Marcin 'Qrczak' Kowalczyk 21 Sep '01

21 Sep '01

Thu, 20 Sep 2001 13:32:54 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > (:) is allowed in an export list; it is just a normal operator. Not quite, it's a reservedop. "Notice that a colon by itself, ":", is reserved solely for use as the Haskell list constructor; this makes its treatment uniform with other parts of the list syntax, such as "[]" and "[a,b]"." (Haskell 98) -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Prelude and (:) and []((:), []) bugs?
by Simon Peyton-Jones 21 Sep '01

21 Sep '01

It's hard to distinguish a constructor from a class in an export list. S | -----Original Message----- | From: Alastair David Reid [mailto:reid@cs.utah.edu] | Sent: 20 September 2001 19:38 | To: Simon Marlow | Cc: Ian Lynagh; haskell(a)haskell.org; hugs-bugs(a)haskell.org | Subject: Re: Prelude and (:) and []((:), []) bugs? | | | | > Ah, I forgot that you can't export a constructor on its own. | | You can't? | | I probably knew this once but looking at it now, it seems | kinda surprising. Haskell's module system is supposed to be | just namespace control --nothing more-- so why is it | preventing me from doing something which is perfectly safe | and well-defined? | | I'll readily agree that there's no strong motivation for | exporting a constructor on its own (I think the only reason | Hugs allows it is just so we can export (:) from the Prelude) | but what is the motivation for disallowing it? | | -- | Alastair Reid reid(a)cs.utah.edu | http://www.cs.utah.edu/~reid/ | | | _______________________________________________ | Hugs-Bugs mailing list | Hugs-Bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/hugs-bugs |

1 0

Problem: "invalid argument" emitted by sendTo
by mgross＠dorsai.org 21 Sep '01

21 Sep '01

Found the error. No need to follow up. Apologies to anyone who objects to mail that turns out not to need answering. Murray Gross mgross(a)dorsai.org

1 0

Problem: "invalid argument" emitted by sendTo
by mgross＠dorsai.org 21 Sep '01

21 Sep '01

I am using SocketPrim to send a udp packet to each of 254 addresses on a network. The message packets have been preconstructed and placed in a list, whose content has already been checked for correctness and appear to meet the specifications in the appropriate RFC. When I go through the list (using mapM_), sending a packet to each address with sendTo, I get a valid return code from sendTo (used trace to check that) for the addresses from 10.129.129.1 through 10.129.129.239. Address 10.129.129.240, however, fails with the messages Fail: invalid argument Action: sendTo Reason: invalid argument The message "invalid argument" does not appear within the source of SocketPrim, but it does appear in several of the binary files in the library. I've begun to dig around in the source code, but I've taken to hoping that someone out there in Haskell land may be able to point me directly to where (and for what) I should be looking to determine just what triggered those messages. Oh, yes, verson info: ghc-5.00.2, linux (debian testing). Thanks in advance for attention. Murray Gross mgross(a)dorsai.org

1 0

Haskell Communities Survey - Call for Contacts
by C.Reinke 20 Sep '01

20 Sep '01

Dear fellow Haskellers, the recent (and eternal) questions about GUIs and future Haskell developments are closely related to a general problem: trying to keep up to date with what is going on within the Haskell community as a whole while the breadth of interests in that community keeps expanding. For the sin of pointing out this problem at this year's Haskell workshop, I was volunteered to try and organise some way of getting summaries of what the various (sub-)communities are working on and posting the results to the main Haskell list as well as on haskell.org. Below, you'll find (I) a summary of the problem, (II) my slightly revised suggestion on what to do about it, and (III) a preliminary grouping of Haskell communities by topic (some of which do not have their own mailing lists right now, or are really dispersed over several more specific lists). What I need from you now is (a) a look at the list of topics/communities at the end of this email -- it is meant as a starting point, likely to be incomplete, so if anyone feels left out, if you can confirm some of the topics as dead, or anything else is wrong, let me know. (b) a contact person in each of the communities, willing to put together a brief, representative summary of that community's work and interests (see part II below for what would be useful). Being brief, the individual reports won't require a lot of work for someone actively interested in one of the topics. In fact, they might have to be shorter than you would like them to be - feel free to include pointers to more extensive documentation. The plan is to get this set up over the next weeks, and to give the contact persons a little bit of time to get feedback on their status reports from their communities. As soon as the individual reports start flowing into my mailbox, I'll try to edit them together. Optimistically, we could have the whole report ready for the main Haskell list before October is gone (famous last words..), realistically, we'll wait and see what happens. Ultimately, the aim is to have two yearly updates of the status report, covering all active Haskell communities (sorted by topic); one update in time for the yearly Haskell workshops and one in between. The first go doesn't have to cover everything, we can add or remove topics and fine-tune the level of detail once we get going. The report will - help to keep experienced Haskellers updated - give newcomers some orientation about current activities - help communities to attract collaborators I'll step back now to make room for the volunteers;-) Claus --------------------------------------------------- THE PROBLEM: 1. The Haskell community continues to grow in size and in the variety of interests. [this is good:-] 2. Sub-communities have formed, often with their own mailing lists, to work on specific issues or just to provide foci for specialist discussion. [this is necessary to get some work done] 3. Both specialists and the "just a Haskell user" find it difficult to keep track of what is going on behind the scenes of the main list. In fact, some folks have opted out of much of the main list (the discussions were factored into the "haskell-cafe" list) and only follow the announcements part (the "haskell" list). Few people can afford spending their days reading through all of the dozens of Haskell-related mailing lists (this is not a joke: you'll find about a dozen "real" lists plus a similar number of cvs-watchlists hosted at haskell.org alone, and that isn't counting the lists hosted elsewhere or the communities that use small meetings to coordinate their work). [this is bad, and we can try to do something about it] --------------------------------------------------- THE SUGGESTION: My initial proposal at the workshop was to collect summaries from contacts on the various mailing lists every six months or so and to edit them for the main Haskell list and for a page on haskell.org. However, having combed through the list of mailing lists I am aware of so far, I am more and more convinced that the current proliferation of very narrowly focussed and often shortlived (in terms of activity) mailing lists is part of the problem, not part of the solution. Not to mention that certain important topics, such as GUIs do not even have their own mailing list yet.. My current suggestion is to come up with a broader topical grouping of Haskell communities (see below), and then to solicit brief summaries from contacts in those communities every six months, taking the yearly Haskell workshop as one of the reference points: - twice a year, everyone gets a snapshot of what's happening with Haskell. In the meantime, the communities can get on with their interests without having to bother with summaries too often (it is always difficult to find volunteers..). - six months is enough time to make some real progress and have something worth summarizing. After half a year, the summaries definitely need to be brought up to date, if only to state which groups have dissolved and which are still active. - the summaries should be brief (rough idea: a paragraph each for looking back and for looking ahead, plus pointers to current documents or other deliverables), as they will be collated into overviews of the Haskell community as a whole, but could contain references to more extensive documents or other deliveries. As a side-effect, this cuts down the work for the contact persons. - having status reports grouped by topic should give a more useful and homogeneous picture; it might also encourage people on related mailing lists to cooperate more closely, or people with related interests to set up a mailing list. Where this is perceived necessary, a status report on any given area can be amended by additional paragraphs covering individual mailing lists or projects in that area. - keeping the collected summaries on a page at haskell.org should give both newcomers and experienced Haskellers a rough idea of what is going on, and which sub-communities they might want to join. ----------------------------------------------- What's in a summary? That is really up to you: what do you think Haskellers in general should know about what is going on in your part of the field? Whom would you like to join your efforts? Think of it as an executive summary with pointers to more details. Here is a rough outline: + major topics and results since the last report (~1 paragraph) + current hot topics (some keywords) + major goals for the next six months (~1 paragraph) + pointers to material for further reading (group charter, group home page, how to join, mailing list archives, specifications and drafts, implementations, meetings, minutes,..) So a minimal report is 2-3 paragraphs, plus pointers. If you like, add extra paragraphs for subtopics in your area. That's it! ---------------------------------------------- TOPICS/COMMUNITIES: Below, the major "communities" (as defined by common areas of interest) are grouped into a small number of top-level categories. Most of the communities are themselves spread over several mailing lists or projects, and some topics appear in several categories, with different emphasis (e.g., FFI development depends on a small set of language extensions, on top of which foreign function interfaces can be built as a combination of tools and libraries; also, applications may center around a set of libraries; language extensions are more interesting if implemented, etc.). It would be easiest for me to get status reports for the major groupings, but that might not be feasible (apart from Haskell implementers, I hope; applications, someone?). So: ** I need contact persons for each of the topics ** who are willing to produce a summary report for their own community, with additional paragraphs per sub-group as appropriate (of course, if any of those sub-groups would like to present their own, separate summary instead, feel free to suggest a separate contact person;-). It is quite likely that some of your own topics/communities are not yet on the list -- let me know about such omissions. |what follows is an outline; a slightly more detailed list, with |links, can currently be found at: | | http://www.ukc.ac.uk/people/staff/cr3/tmp/Communities/ | |Note the "tmp" - this list should move to haskell.org later. Haskell Communities, by topics ============================== Haskell implementers -------------------- : irregular meetings, visits, email, separate mailing-lists - what's up with each implementation (ghc,nhc,hugs,hbc???)? - what's in store across implementations (implementer's meetings)? Language and implementation extensions -------------------------------------- : separate sub-communities + FFI foreign function interface for Haskell + Libraries hierarchical module namespaces for Haskell + Non-sequential Haskell concurrent, parallel, and distributed Haskell + Type systems extensions and variants of all kinds and types + Generic Haskell generic programming for Haskell (Generic Haskell, Polyp, Strafunski, generalised deriving, Drift, ..) + O'Haskell objects and concurrency for Haskell + Meta Haskell Metaprogramming support ala Meta ML + Haskell modules (re-)emerging interest in a lightweight redesign + Arrows towards built-in support for Libraries --------- : current core priorities are high-level FFI, GUIs, and overall library reorganisation (using hierachical namespaces), + Libraries organisation and collection of libraries (hslibs, nofib, ..) + FFI (Foreign, CForeign, ..) + GUIs (Gtkhs, iHaskell, FranTk, Fudgets, Haggis, Fruit,..) [no separate forum for GUIs yet??] + computer algebra Tools ----- : widely dispersed, small and sometimes short-lived communities, as many tools are still implementation-specific, most of the discussion is currently mixed into the main implementation lists [a combined Haskell-Tools forum might be more appropriate; many tools share similar problems, such as program analysis, etc.; tools should be visible independent of the implementations they depend on, and indeed portable tools would seem to be an important topic..] + FFI (greencard, hdirect, c2hs) + Debuggers [dormant? probably too limited in scope?] + Development tools (tracing, profiling, pre-processors, editor modes, IDEs, testing, ..) + Documentation/Publishing (automated documentation generation tools, source code browsers, literate programming; HaskellDoc, HDoc, Habitat, ..) Applications ------------ : no separate forum yet, but might deserve one separate from the general discussions list? + Haskell for teaching other topics, teaching haskell + stock markets, computer algebra, numerical algorithms, hardware,.. + FRP functional reactive programming [list at yale, dormant?] (robotics, vision, animation, stage lightning, ..)

3 2

RE: Prelude and (:) and []((:), []) bugs?
by Simon Marlow 20 Sep '01

20 Sep '01

Ian Lynagh writes: > On Thu, Sep 20, 2001 at 01:32:54PM +0100, Simon Marlow wrote: > > (:) is allowed in an export list; it is just a normal operator. > > An export is > > export -> qvar > | qtycon [(..) | ( qcname1 , ... , qcnamen )] (n>=0) > | qtycls [(..) | ( qvar1 , ... , qvarn )] (n>=0) > | module modid > > and we need to match (:). We can clearly reduce this to [ proof that this isn't possible deleted ] Ah, I forgot that you can't export a constructor on its own. In which case, I would like to submit a bug report for Hugs: Hugs allows constructors to be named in an export list, and it shouldn't (see Section 5.2 in The Report, point 2 in the enumerated list). Cheers, Simon

2 1

RE: Prelude and (:) and []((:), []) bugs?
by Simon Marlow 20 Sep '01

20 Sep '01

> As far as I can tell, the report doesn't allow (:) or []((:), > []) in the > export list, yet the hugs prelude has the first and the GHC > prelude has > the second. Have I missed something that allows them or is > this a bug in > the preludes or the report? (:) is allowed in an export list; it is just a normal operator. GHC has a couple of extensions to export lists: we allow gcon instead of just qcon, and gtycon instead of qtycon. These are quite natural extensions, and just reduce the amount of built-in compiler magic needed to express the Prelude. Cheers, Simon

2 1

mouse & HOpenGL
by Andre W B Furtado 19 Sep '01

19 Sep '01

Does anybody know if (H)OpenGL can recognize a mouse movement even if the mouse cursor doesn't move? For example, suppose the mouse cursor is placed at the top left corner of the screen, and I move my mouse to the top left corner direction. The mouse cursor won't move, although the mouse WAS moved. Unfortunately, the "motionFunc" and "passiveMotionFunc" are related to the new position of the mouse cursor, rather than the mouse movement... (in the Allegro library, this is solved by a thing called "mouse mickeys"). Thanks a lot, Andre W B Furtado

1 0