do-and-if-then-else modification
Iavor and I just made the trivial modification for DoAndIfThenElse syntax as described here: http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse You can see the change here: http://darcs.haskell.org/haskell-prime-report/report/haskell-report-html/exps.html (Is there anything else that needs to change?) As always, we provide a quick view of the status of Haskell' here: http://hackage.haskell.org/trac/haskell-prime/wiki/Status%27 Any comments on this modification? How do people feel about the suggestion that we do it for case statements as well? peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
self moderation (or, what is Haskell' about)
Folks, We all love to talk about fun and exciting new things, and I really don't like to change the subject, as it were, of a mailing list conversation unless it's very necessary. This list is unmoderated, and will stay unmoderated. Anyone can post whatever they want, and it's up to the community of the list to decide what's appropriate and what's off topic. If you see stuff that you think is off topic, please invite that discussion to move over to haskell-cafe or what-have-you. If you start a discussion about something core to Haskell', especially the definitely in topics, and the conversation wanders into strange and unknown territory, please, please re-focus your thread to get back to the important topics. Start a new thread if necessary with a summary of the discussion so far and the open questions. We've had a lot of people unsubscribing from the list in the last few days, for what it's worth. People get a mistaken impression about What Haskell' is about based on the discussions of the list, and sometimes it scares people :) So just be aware that the unmoderated list is _not_ a good way to get a sense of what's going on in Haskell'. Watch for announcements from the committee and requests for help from me and others for actually writing the report. Also, keep an eye on the status page of the wiki: http://hackage.haskell.org/trac/haskell-prime peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-report): pattern_guard_list_comprehension_footnote
Fri Jan 19 15:23:01 PST 2007 'Ravi Nanavati [EMAIL PROTECTED]' * pattern_guard_list_comprehension_footnote M ./report/exps.verb -1 +3 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-report): some notes on how to build it.
On Mon, 2007-01-08 at 13:42 +, David House wrote: On 08/01/07, Simon Marlow [EMAIL PROTECTED] wrote: Mon Jan 8 03:11:48 PST 2007 Simon Marlow [EMAIL PROTECTED] * some notes on how to build it. M ./README -6 +26 Using the flex version 2.5.31, straight out of apt, I get the following error: flex -t -8 verbatim.lex verbatim.c || ( rm -f verbatim.c exit 1 ) verbatim.lex:75: warning, rule cannot be matched cc -c verbatim.c -o verbatim.o stdout:561:25: error: macro yywrap passed 1 arguments, but takes just 0 make: *** [verbatim] Error 1 Using the flex-old package, which is version 2.5.4a, it works. I guess this means our flex files are legacy. Could they be updated to work with the latest flex? This has been fixed :) It turns out that not all mods are posted to the mailing list, due to subscription requirements. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
pattern guards: recent changes to draft haskell prime report
Greetings! We've been working to add pattern guards to the Haskell' report, and doing some cleanup work on the repository. Not all of the emails are making it to the list, sadly, but here's a list of recent changes from the report. You can view the report itself here (I couldn't think of a good place to put it): http://hackage.haskell.org/~ijones/haskell-prime-report/report/haskell98-report-html/ peace, isaac Fri Jan 12 16:32:28 PST 2007 [EMAIL PROTECTED] * moved rules for guards in a separate figure because the old figure didn't fit on a page Fri Jan 12 16:21:46 PST 2007 [EMAIL PROTECTED] * fixed rule (g) of pattern semantics to avoid duplicating the evaluation of e' Fri Jan 12 16:13:50 PST 2007 [EMAIL PROTECTED] * added rules for pattern guards to the formal semantics of case Fri Jan 12 14:53:30 PST 2007 [EMAIL PROTECTED] * gneralized function bindings to support pattern guards, not just boolean guards Thu Jan 11 16:59:30 PST 2007 [EMAIL PROTECTED] * reworking the informal explanation of pattern gaurds Modified the syntax again to talk about guards (which are pattern guards, boolean guards, and let expressions) . Moved the Pattern guards section I created before into the Case Expressions section. Thu Jan 11 15:51:14 PST 2007 [EMAIL PROTECTED] * update pattern binding translation for pattern guards (with Iavor's help!) Mon Jan 8 10:21:14 PST 2007 Andres Loeh [EMAIL PROTECTED] * turn macro into function -- makes it work with newer flex versions Mon Jan 8 09:50:40 PST 2007 Andres Loeh [EMAIL PROTECTED] * don't include extension in \includegraphics (to make compatible with pdflatex) Mon Jan 8 09:20:29 PST 2007 Andres Loeh [EMAIL PROTECTED] * typo: change \r to \tr ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-report): update pattern binding translation for pattern guards (with Iavorapos; s help!)
Thu Jan 11 15:51:14 PST 2007 [EMAIL PROTECTED] * update pattern binding translation for pattern guards (with Iavor's help!) M ./report/decls.verb -7 +9 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-report): very rough draft of informal pattern-guard (qualifiers) explanations
Sun Jan 7 19:26:27 PST 2007 [EMAIL PROTECTED] * very rough draft of informal pattern-guard (qualifiers) explanations This is a very rough draft in order to get some discussion going, and does not touch the semantic explanations, which will still need to be done. M ./report/exps.verb -48 +63 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
very rough draft of informal pattern-guard (qualifiers) explanations
I just pushed a very rough draft of the plain, informal text for pattern guards. I'm also attaching the patch. http://darcs.haskell.org/haskell-prime-report/report/exps.verb I'd like some feedback about the approach I'm taking, which varies slightly from the description in the 2000 HW paper. Since pattern guards are defined basically as in list comprehensions, I've pulled a bit of that text into its own section. In the list comprehensions section, pattern guards are referred to as qualifiers, so I've kept that name. (From Simon's original memo, it seems that the generators within the qualifiers are pattern guards.) So now there's a section that explains qualifiers, including the nested environment nature. In many places, I've removed references to guards and replaced them with references to qualifiers. I've also consolidated text that explains guards, which was previously found in various locations, into that single section as above. I haven't touched the more semantic bits yet; I'd like some feedback on my overall approach first. I've brashly pushed these changes into our darcs repository of the report in the hopes that others on the committee (or indeed, within the community) will begin to be a bit more brash. Alas, I'm unable to actually build the report at the moment. If anyone knows how, please add instructions to the repository, or send them to me and I'll add them. peace, isaac p.s. the pattern guard wiki page is here: http://hackage.haskell.org/trac/haskell-prime/wiki/PatternGuards p.p.s. http://www.haskell.org/pipermail/cvs-ghc/2007-January/033592.html ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Haskell' Status Report
Ravi Nanavati has very helpfully put together a status report for the Haskell Prime process. Please see this link, or read the pasted text below: http://hackage.haskell.org/trac/haskell-prime/wiki/Status' peace, isaac Summary: Since the Haskell Workshop last year, the Haskell community has documented (on this wiki) over 70 proposals for changes to Haskell 98. In March of this year, two subcommittees were established to focus on concurrency and the class system - two difficult areas that are important to the success of Haskell'. The committee has also used StrawPolls to filter and discuss the universe of proposals that has been gathered. Based on the most recent straw poll, 12 proposals (listed in the table at the bottom of the page) have been identified that are expected to get into Haskell' (over 2/3 of the committee in favor). An additional 19 proposals seem likely to get into Haskell' (based on slightly weaker criteria). Members of the committee conflict on 9 of the remaining proposals, and their status will be determined during the writing process. The remaining proposals are not expected to be part of Haskell'. Concurrency: The concurrency support in Haskell' will be based on the Control.Concurrent library, with minor modifications. There will be a thread-safe interface for mutable state, suitable for use in library code that does not otherwise use concurrency (though what it will be based on is an open issue). There will also be independent FFI annotations for specifying whether foreign calls are concurrent (with other Haskell threads) and reentrant. Bound threads will not be required by the concurrency standard, but they will be an allowed extension with a specified meaning. Open issues include whether standard will require preemptive concurrency, the syntax of the new FFI annotations and the memory-model semantics of IORefs. Class system: The work on the class system has focused on resolving the MultiParamTypeClassesDilemma. The core of the dilemma is that multi-parameter typeclasses are a popular extension that is strongly desired for Haskell'. However, many important uses of MPTCs (like the monad transformer library) require additional extensions to resolve ambiguities in their typechecking. Historically, FunctionalDependencies have been used for this purpose, but they are very tricky to implement and are also difficult to specify in a way that guarantees the termination of typechecking. AssociatedTypes are a possible replacement, but our current implementation experience with them is very limited. The subcommittee has explored several ways to resolve this dilemma (including restricted FDs, fast-tracked ATs and FDs as a blessed extension), but, so far, no consensus has emerged. Our current plan is to focus on writing other parts of the Haskell' standard, in the hopes that additional implementation experience with ATs will clarify the situation. Libraries: Thus far, libraries have been an underemphasized portion of the Haskell' effort (only 7 of the 70+ proposals have significant library content). However, there is a consensus that a revised standard library is an important part of the Haskell' effort. The current plan is to focus on starting to write the language portions of the standard first, since we have a substantial amount of work to do there which requires focused attention. After that effort is well underway, a companion library effort will begin. Several members of the committee have volunteered for this effort and additional volunteers will be needed. definitely-in Proposal Status: Description (Those volunteering to write this section): add some kind of Concurrency (IJ, SM) add ForeignFunctionInterface (MC, SM) add multi-parameter type classes (MS) add RankNTypes or Rank2Types (AL) add PolymorphicComponents (AL) add ExistentialQuantification (existential components) (AL, MS, SJT) add HierarchicalModules (IJ, BH, MW) add EmptyDataDeclarations (BH, HN) DoAndIfThenElse (SM, HN) fix comment syntax grammar (SM) add PatternGuards (RN, DS) add InfixTypeConstructors (BH, AL) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Trac Ticket Component Field?
On Wed, 2006-09-27 at 16:27 -0700, Ashley Yakeley wrote: What do the various values of the Component field mean? Most issues have Proposal, but some have HaskellPrime. If it is a proposal for something to go into/be removed from the language, then it should be listed as proposal. If it's some task that we have to perform (write a library API or something), then the component might be something else. Proposal is the main one, though. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
writing / status teams - call for volunteers
Greetings, There are just a few days to go before the Haskell Workshop, and I'd like to be able to present the community with a report on our progress. With that in mind, I'm looking for some help during this busy time of year. The Haskell' committee has been voting on the wiki about the relative strength of various proposals. We're trying to find a group of proposals that is definitely in so that we can start the hard work of writing the report. Here's the survey: http://hackage.haskell.org/trac/haskell-prime/wiki/StrawPoll-2 The idea is that we want to make some tangible progress on actually writing the report, so we have selected some pretty non-controversial proposals. This is also to get a better idea of where there is and is not consensus. Below is the list of so-called definitely-in proposals, which is probably not quite correct. For instance, I don't think it's clear that MPTCs are definitely in, but the others look pretty good. Beside the proposal name is the group of committee members who have volunteered to write sections for so-called definitely in features. I have several requests for volunteers, which can be within or not within the committee: Would anyone else like to volunteer to write a section of the report for specific proposals below? Can anyone volunteer to do a survey of the current status of each of these proposals? We should try to figure out how far from done we are on all of them. I imagine that some things like concurrency are far from done, while other things like hierarchical modules and empty data declarations are pretty much done. Will anyone volunteer to write a status report for the community, with the goal of finishing the status report by the time of Haskell Workshop. This obviously isn't something fancy, just a summary of the items discussed, the current status on them, etc. This should all be on the list archives and on the wiki. A committee member is probably best suited for this, but anyone following the process closely should be able to do it :) Also, everyone should please think about this list as a whole; apply your right brain to consider whether it's a coherent and elegant set of proposals. In == #74: add some kind of concurrency: SM, HN, IJ #35: add ForeignFunctionInterface: MC, SM #49: add multi parameter type classes: MS #60: add RankNTypes or Rank2Types: AL #57: add polymorphic components: AL #26: add ExistentialQuantification (existential components): AL, MS, SJT #24: add HierarchicalModules: BH, IJ #25: add EmptyDataDeclarations: BH, HN #23: fix common pitfall with the do-notation and if-then-else: SM, HN, #42: fix comment syntax grammar: SM #56: add Pattern Guards: :( #78: Add infix type constructors: BH, AL Help w/ libraries (yay!): IJ, BH, SM, RP, DS peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
postponing discussion on exceptions and deepSeq
I'd like to ask the list to postpone discussion on exceptions and deepSeq until a later iteration. While these are two topics that are of deep importance to me, I would prefer to focus on the other two topics at hand until they are solved. That is, concurrency, and the class system. I'm still postponing opening up another topic since I find that the class system isn't being as enthusiastically discussed as I had hoped. Let's all focus our energies on these topics, I promise that the others won't be forgotten. Ross has asked for use cases for functional dependencies and so far has only two replies. Surely there are those on this list who have use of functional dependencies? peace, isaac -- isaac jones [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: concurrency (was Re: important news: refocusing discussion)
On Tue, 2006-03-28 at 11:05 +0100, Malcolm Wallace wrote: (snip) * IORef is inherently thread-unsafe, and so we should eliminate IORefs from the language. That's not quite true, as you can have an IORef guarded by an MVar. Why would you want such a thing? For instance, you might write a library with two IORefs and one MVar instead of two MVars in order to reduce the possibility of deadlock. Is it the case that a library is thread-safe as long as it doesn't use IORefs, though? I trolled around base looking for libraries that might not be thread-safe and found only that HashTable uses an IORef, and indeed there's a FIXME that says it should use an MVar. I didn't look very hard, though. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: MPTCs and functional dependencies
On Tue, 2006-03-28 at 14:32 +0100, Simon Peyton-Jones wrote: My current take, FWIW. * MPTCs are very useful. They came along very rapidly (well before H98). I think we must put them in H' * But MPTCs are hamstrung without FDs or ATs * FDs and ATs are of the same order of technical difficulty, as Martin says * ATs are (I believe) a bit weaker from the expressiveness point of view (zip example), but are (I believe) nicer to program with. * BUT we have way more experience with actually programming with FDs. ATs fail the well-established test by a mile. * Largely due to Martin's work, we now have a much better handle on just what restrictions on FDs make type inference tractable. So I believe there is a solid MPTC+FD story that we could embody in H'. * Medium term, I think ATs may *at the programming-language level* displace FDs, because they are nicer to program with. But that's just my opinion, and we don't have enough experience to know one way or the other. This analysis is similar to what I have here: http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma Could someone flesh out the wiki w/ Simon's data and links to the new information from Martin? peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: bringing discussions to a close
On Tue, 2006-03-28 at 21:16 -0500, Jim Apple wrote: On 3/28/06, isaac jones [EMAIL PROTECTED] wrote: The only topics that should remain open are concurrency and the class system. What happene to bullet 3, perhaps standard libraries? We're still trying to figure out exactly what the 3rd topic should be. I don't want to hold up discussion on the other topics, though. Standard libraries is at the top of my list right now because it has hardly been discussed. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: important news: refocusing discussion
On Sat, 2006-03-25 at 13:17 +0300, Bulat Ziganshin wrote: Hello Ross, Saturday, March 25, 2006, 4:16:01 AM, you wrote: On Fri, Mar 24, 2006 at 02:47:09PM -, Simon Marlow wrote: I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it. Essential for many applications, certainly, but central? How can you say that? it becomes central language feature just because it's much easier to write concurrent programs in Haskell than in other languages and because ghc's implementation of user-level threads is blazing fast, outperforming closest competitor in hundreds (!) times in the Language Shootout concurrency testing I don't think central to the language is a particularly helpful concept here. Let's try to frame debates like this in terms of interests, not positions. That is, an interest is we should be able to write thread-safe libraries and a position is Haskell' should have concurrency. Once we understand each-others' interests, we can look to find solutions that satisfy a compelling set of interests. I'll try to frame some interests that various folks seem to have expressed, and I admit that I may miss some and be wrong, so please add to or correct the list below (maybe it should go on the wiki): Possible Interests: 1. I can write tools like filesystems, web servers, and GUIs in Haskell' 2. Libraries that I use are thread-safe 3. I can compile my code with any Haskell' compiler 4. Tools such as debuggers and tracers that claim to support Haskell' actually work on my code. 5. That there not be too many Haskell's 6. That there be a diversity of Haskell' implementations 7. That concurrency be reasonable to implement for existing compilers/interpreters. 8. That it be reasonable to implement for new compilers/interpreters. 9. Show off how effective Haskell can be in this area (possibly attracting new users). By 5 I mean that it might be nice to have a core Haskell and a bunch of addenda. But this could cause no two Haskell' implementations to be the same. (My Haskell' might have concurrency and FFI, but no class system, or something.) The more optional addenda we have, the more we actually fracture the language. We could be in the same situation we're in today. Isaac's Interests * 1-6, 9 Simon's Interests: * He's mentioned 9, I'm sure that there are others. Ross and John Meacham I think have both expressed worry about 7 and 8. I have no idea if it would work, but one solution that Simon didn't mention in his enumeration (below) is that we could find a group of people willing to work hard to implement concurrency in Hugs, for example, under Ross's direction. That might satisfy interest number 7. Please help me to build this understanding of various folks' interests, an solutions to satisfy them. peace, isaac Simon Marlow Wrote: It boils down to a choice between: (1) Haskell' does not include concurrency. Concurrent programs are not Haskell'. (2) Haskell' includes concurrency. Concurrent programs are Haskell', but there are some compilers that do not implement all of Haskell'. (3) There are two variants of Haskell', Haskell' and Haskell'+Concurrency. Compilers and programs choose which variant of the language they implement/are implemented in. (4) The same as (3), but the two variants are Haskell' and Haskell'-Concurrency (where -Concurrency is a negative addendum, an addendum that subtracts from the standard). -- isaac jones [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
important news: refocusing discussion
Greetings, While discussion on this mailing list has been coming fast furious, actual tangible progress, even as measured on the wiki, has not been as fast. To remedy this, we propose to focus immediately and intently on a few of the most critical topics, and to focus all of our energies on them until they are done. We'd like to go so far as to ask folks to drop discussion on other items until these are solved. The goal of this approach is that we will spend the most time on the critical (and hard) stuff, instead of leaving it for last. We know that we can spend a _lot_ of time and energy discussing relatively small things, and so we want to make sure that these relatively small things don't take up all of our time. We will tackle them later. The topics that John and I feel are critical, and rather unsolved, are: * The class system (MPTC Dilemma, etc) * Concurrency * (One more, perhaps standard libraries) The logic here is that Haskell' will be accepted by the community if we solved these problems, and if we go with some of the most robust and uncontroversial extensions already out there. We will probably partition the committee into subcommittees to focus on each topic. Our goal will be to bring these topics to beta quality by mid April. That is, something that we could be happy with, but that perhaps needs some polishing. After that, we may try to pick the next most critical topics with the goal of having everything at beta quality by the face-to-face we're hoping to have at PLDI in June. With an eye toward considering related proposals together, we've added a topic field to the wiki, and a new query to the front page which groups the proposals by topic: http://hackage.haskell.org/trac/haskell-prime/query?status=newstatus=assignedstatus=reopenedgroup=topiccomponent=Proposalorder=priority I'd like to ask folks to please bring currently open threads to a close and to document the consensus in tickets. Anyone can edit tickets, so please don't be shy. your chairs, Isaac Jones John Launchbury -- isaac jones [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On Tue, 2006-03-21 at 15:27 -0800, Ashley Yakeley wrote: isaac jones wrote: The topics that John and I feel are critical, and rather unsolved, are: * The class system (MPTC Dilemma, etc) * Concurrency * (One more, perhaps standard libraries) Could you summarise the current state of these? AFAIK, the class system is summarized on this page: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/MultiParamTypeClassesDilemma Although there are some proposals here that are not really covered by that topic, they should probably be considered together: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/query?status=newstatus=assignedstatus=reopenedgroup=topiccomponent=Proposalorder=priority Concurrency is summarized here: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency and libraries have not really been discussed much at all. peace, isaac -- isaac jones [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
Henrik Nilsson [EMAIL PROTECTED] writes: Dear all, John Mecham wrote: Yeah, I have been coming to the same conclusion myself. it pains me a lot. (monad transformers! I need thee!) but its not like fundeps will go away, they will just still be experimental so it isn't the end of the world. But isn't the whole point of Haskell' to standardise those features that are agreed to be necessary for writing real-world applications and libraries in a reasonable way? My concern is not that I fear not being able to compile my programs after Haskell' is done. I'm worried about too much code not being Haskell' compliant in the end, and, worse, too many people deciding that they still have to rely on extensions beyond Haskell' for writing real applications and libraries. I am very concerned about this as well. In most of my production code, I avoid extensions, but MPTC and functional dependencies are two that I have not been able to avoid. Any time I use the class system, I use MPTC, anytime I use MPTC, I use fundeps. The trouble with blessing fundeps is that they might not pan out in the end, and it would be a shame to add them to Haskell' and then remove them again for Haskell'' (if there were such a thing) in favor of associated types, for instance. How do we solve this dilemma? Some proposals that have come up: - Simon has proposed that we examine a limited version of functional dependencies. - Another option, though a scary one at this point, is to look closely at associated types. - Another option is to punt; we declare them as an extension and figure out a way to bless extensions (beyond Cabal, I guess). - Any others? Can someone put together a wiki page these choices with trade-offs? Ravi, Manuel? peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
objective data on use of extensions
I would like to strive to find objective data on the use of extensions. I started a table here which summarizes how popular extensions are in real-life code. We need more data points, though. http://hackage.haskell.org/trac/haskell-prime/wiki/ExtensionsExperiment I have a short program which queries the hackage database, gets some details about all of the packages there, and summarizes them into a table. Right now, there really aren't that many packages on HackageDB, but hopefully more will appear. HackageDB is here: http://hackage.haskell.org/ModHackage/Hackage.hs?action=home You can upload packages with Cabal-Put, but it's pretty hackish right now. I put detailed installation instructions on the wiki: http://hackage.haskell.org/trac/hackage/wiki/CabalPut A list of cabal packages that might be good for uploading is here: http://hackage.haskell.org/trac/hackage/wiki/CabalPackages The more packages we get into HackageDB, the more accurate objective data we can build. Let me know if you want to help! peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: module system/namespaces: separate with/use, allow local use
Simon Marlow [EMAIL PROTECTED] writes: On 30 January 2006 09:03, Simon Peyton-Jones wrote: With the module system, we should make a distinction between declaring (1) that we want to use a module (2) how to bring the module's names into scope Perhaps 'import' should be allowed anywhere among definitions. Indeed. Requiring the import clauses to be at the top, and the fixity declarations, makes them easy to find -- but we don't require that for type signatures or class declarations etc. It'd be more consistent to allow imports and fixity declarations anywhere. This'd be a backward compatible change, but it's an utterly un-forced one. It's not something that people complain about much. I vaguely remember suggesting this for Haskell 98 or Haskell 1.4 (can't remember which) but nobody saw the need for it back then. (snip pros cons summary) Can one of you add a ticket / wiki page with this summary? I'd like to track things like this in case they come up again. Johannes, if you have any more specific proposals you'd like to make, please do so on the mailing list, then add a ticket once some consensus emerges. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
