[Haskell-cafe] Software Engineer, Functional Programmer, Team/Project lead positions
Are you seeking an intellectually challenging position in which you'll be developing cutting edge software using functional programming technologies? Do you aspire to work with a team that shares your level of commitment and enthusiasm to develop tomorrow's high-assurance technology today? Do you want to take ideas and turn them into real-world products? If so, you might be just the person we're looking for. Galois Connections, Inc., located near Portland, Oregon, designs and develops high confidence software for critical applications using cutting edge methods and technology. Innovative and highly creative in the demanding application areas of security, information assurance, cross-domain platform development, and formal-methods engineering, Galois has earned a reputation of excellence in both private and government sectors. Galois has recently opened several positions for software engineers/ functional programmers and team leads who will participate in/lead projects from inception to product delivery. These people will work in a highly cooperative and collaborative team settings and will be responsible for ensuring the delivery of robust and fully functional products according to client expectations and potential certifying agencies. For more details about these exciting opportunities please go to: http://www.galois.com/join.php To learn more about Galois visit our website at http://www.galois.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Google summer of code
Bjorn Bringert [EMAIL PROTECTED] writes: On Mar 8, 2007, at 10:40 , Simon Marlow wrote: David House wrote: On 06/03/07, Malcolm Wallace [EMAIL PROTECTED] wrote: Well, our wiki to gather ideas is now up-and-running again: http://hackage.haskell.org/trac/summer-of-code We should probably remove projects that were succeessfully completed last year, along with the lists of interested students on every project. I did some general tidying up in the Trac yesterday, including closing some of the projects that were done last year. I'd urge others to go and take a look too; I didn't do a complete sweep. I think that it would be good if we this year would make a short(ish) list of the projects that we think are the most important, and let the students focus on applying for those. My impression from last year is that there were lots of project proposals, most of which could not be considered important enough to be one of the projects we pick, no matter how good the students were who wanted to do them. I really like this idea. I think we have some strategically important things that people could work on. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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] Haskell Packages 6.6?
Hello good Haskell Hackers. We're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database. Let's imagine something that would be awesome. A set of Haskell packages which are all known to work together with a particular version of cabal (the one that GHC comes with), and a particular version of GHC. GHC version 6.6 will be released soon, and I think we should try to make this happen. Currently, we have a set of 27 unstable packages. They may or may not work with each-other and such: http://hackage.haskell.org/packages/ I just created an empty directory testing. I propose that we start testing packages, starting with the cabal release candidate that'll go into GHC 6.6, and make sure they work nicely together. Once they're known to work, we can migrate them from the unstable directory to the testing directory. Once we have a sufficient collection of packages, and once ghc 6.6 is released, we can make a snapshot of this directory, call it stable-6.6 or something. Then if you have ghc 6.6 and cabal-install, you should be able to cabal-install p for any package, and it'll definitely work. So what will we need for this to happen? 1. An installed version of ghc 6.6 on the hackage/darcs server. Maybe in a chroot or something. Maybe from the nightly build tree or the previous snapshot? 2. Some initial set of packages (maybe just cabal-install) to start off. 3. Some script that goes through and builds all of the unstable packages in dependency order. I think cabal-install can do this already. In fact, it would be ideal if we used cabal-install for this. 4. The script should also run ./setup haddock and ./setup test. If the packages seem to work w/ 6.6 and the other packages in testing, it should get migrated from unstable to testing. 5. A web interface (lemmih is working on it) 6. A script to upload packages to unstable (Paolo is working on it). 7. Someone to spearhead all of this! peace, isaac p.s. here are the packages we have currently in the database: parsedate-2006.6.4 Haskell library for parsing dates and times cgi-2006.8.5 A Haskell library for writing CGI programs HDBC-odbc-1.0.1.0 lambdabot-4.0 bzlib-0.2Compression and decompression in the bzip2 format HDBC-sqlite3-1.0.1.0 hask-home-2006.3.23 Generate homepages for cabal packages XmlRpc-2006.6.26 hnop-0.1 Haskell No Operation fps-0.7 HDBC-postgresql-1.0.1.0 rss-2006.7.12A library for generating RSS 2.0 feeds. HTTP-2006.7.7 Crypto-3.0.3 DES, Blowfish, AES, SHA1, MD5, RSA, X.509 Identity and Attribute Certificates, General ASN.1 Support, Base64, PKCS8, PKCS1v15, Hexdump, Support for Word128, Word192 and Word256 and Beyond, PKCS5 Padding, Various Encryption Modes e.g. Cipher Block Chaining all in one package.plugins-1.0 fastcgi-2006.8.5 A Haskell library for writing FastCGI programs zlib-0.2 Compression and decompression in the gzip and zlib formats HDBC-1.0.1 xhtml-2006.7.5 A Haskell XHTML combinator library darcs-graph-0.1 gd-2006.7.12 A Haskell binding to a subset of the GD graphics library hmp3-1.1 Djinn-2005.12.14 A haskell proof generator iconv-0.2Perform character set conversion exif-2006.7.11 A Haskell binding to a subset of libexif HaXml-1.13.1 Utilities for manipulating XML documents ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Haskell Packages 6.6?
I'd like to trim the followup to cabal-devel@ or libraries@ so we don't cross-post to all lists. Lemmih [EMAIL PROTECTED] writes: On 10/4/06, Isaac Jones [EMAIL PROTECTED] wrote: Hello good Haskell Hackers. We're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database. I added a few more. We have 32 now. Cool! (snip) What about the packages that have external dependencies? They won't necessarily be buildable on the server. That's true. For such packages, we could install their dependencies by hand. Or we could exclude them as being too outside the system. I think an automagic solution for this problem is beyond the scope of cabal/hackage. (snip) 5. A web interface (lemmih is working on it) HackageDB is as good as it's gonna get for now. Btw, why is this step necessary? The web interface is important for both the unstable and stable collections. People need to be able to look at what's available on the server. People need to know where to go for the authoritative release of packages. Simon Peyton Jones also happens to think that a web interface that shows all of the packages is very important. Maybe he can go into some detail about why. Would anyone else like to take up hacking on the web interface? Lemmih's version is here: http://hackage.homedns.org 6. A script to upload packages to unstable (Paolo is working on it). 7. Someone to spearhead all of this! I have time. However, I also see a lot of problems. Like what? peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] 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 mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Standard: Please email me if you want to join the committee.
Greetings, As announced at the Haskell Workshop, the Haskell Prime process is running another committee selection round. We are specifically looking for people to write sections of the Haskell Report for the definitely in and probably in proposals, as described in: http://hackage.haskell.org/trac/haskell-prime/wiki/Status' Please email me if you think you would like to write sections of the report and be on the committee. Please tell me which of the definitely in or probably in sections you would like to help with writing. Also, anyone interested in the future of the language should sign up for the Haskell Prime mailing list if you aren't already: http://haskell.org/mailman/listinfo/haskell-prime peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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
[Haskell-cafe] Galois Connections seeking a developer
Galois is seeking a full-time candidate for software development and systems integration in the field of high assurance computing. A successful candidate should have a good understanding of the inner workings of databases, good development skills in a number of languages, including at least one functional language (preferably Haskell), and web development. The candidate should have excellent Linux and Unix skills. If the candidate does not know Haskell, they should be good at learning new programming languages, and can reasonably expect to be fluent in Haskell within a few months. Tasks: * Database analysis * Python and PHP web development * Learning and adapting Linux-related technologies including Xen, SELinux, and Knoppix * Creating or modifying Debian packages * Haskell development Knowledge: * Databases implementation internals * Web development, Services-Oriented Architectures * Fluent in Haskell or other functional languages * Grounding in computer security * XML * Linux and Unix Nice-to-have: * Extreme Programming (XP) development experience * Experience deploying software products * Open source software development experience * Ability to get US security clearance Education: * Masters degree or equivilent experience Please respond with a resume and a cover letter explaining your fit to [EMAIL PROTECTED] Feel free to forward to interested parties. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Haskell / Full-fledge verified OS
We at Galois are quite interested in formally verified software. An OS would be very exciting. We have offered Halfs, a Haskell filesystem, and would be delighted if someone worked to formally verify this. As the primary author, I'd be happy to tweak the Halfs code to make it easier for someone working to verify it. http://www.haskell.org/halfs peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] cabal specify a tested version, ghci target?
Duncan Coutts [EMAIL PROTECTED] writes: On Sat, 2006-08-12 at 03:52 +0200, Marc Weber wrote: 1.) I know I can use Build-Depends: lib == version, lib2 version, lib3 = version and so on. Do you think it would be useful to introducue some notation to indicate a tested with ? Reason, purpose: I think its sometimes the case that a author/ mantainer is quite busy with other projects and misses that some dependencies break things.. If you want to try out you're left with some compiler errors and a dependency and have to try out which version works. I would propose using this syntax: lib-1.3 =1.1 to indicate that lib 1.1 is required at leeast and tested with up to 1.3.. Cabal might then give a warning if you try to use 1.4 or greater using newer version than tested or similar.. What do you think? Would this be useful? Well there is actually already a tested-with: field that you can put in a .cabal file, however at the moment it refers only to the Haskell implementation, eg ghc-x.y, hugs-x.y etc not to versions of libraries. Yes, I think it's a quite reasonable argument to extend this to include exact versions of libraries that it has been tested with. What do others think? Sounds OK if someone wants to do it, but I don't think it should be a high priority... I'd rather see support for stuff like this built into HackageDB. I really want to have a stable, testing, and unstable sections in Hackage where testing and stable have packages that are known to work (or at least build) together. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] A road for Haskell into the kernel of a full-fledged OS
Joel Reymont [EMAIL PROTECTED] writes: On Jun 2, 2006, at 5:41 PM, [EMAIL PROTECTED] wrote: It is quite instructive to compare a device driver in Haskell with the original C driver -- it terms of length, speed, time to write, number of bugs, etc. I think this is an awesome idea. I believe the folks at Galois have customized the Haskell runtime for embedded devices but... I wonder if us mere mortals will spend more time fighting laziness (and thus high memory usage) than focusing on driver functionality. Another interesting Galois-related low-level project is the Halfs filesystem: http://www.haskell.org/halfs/ Oleg, did you happen to mention this to Andrew Tanenbaum? Do you think he'd be interested in looking at it? Should I drop him a line? peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: GHC vesrion 6.4.2
Some more bad news... The Cabal hooks interface from 6.4.2 is pretty different from the current darcs head. The differences were to make things more consistent and less likely to change in the future. I can't see really going back to the version that's in 6.4.2. I fear that'll make the problem worse in the long run. So for clarity, the problem with this difference is that folks who rely on the hooks may have trouble building their Setup files due to different interfaces between cabal versions. So having a version of GHC with a different cabal hooks interface from future versions will be a problem. But IMO using that interface in the long run will be a bigger problem, since it's not a particularly good interface. My inclination is to just go ahead and change it for 1.1.5 and greater... this will cause some pain for those who rely on the GHC 6.4.2 version of the interface (which we're calling cabal 1.1.4), but hopefully it won't be a huge number of packages. Opinions? peace, isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Haskell' status summary
Greetings! I'll try to update the Haskell community periodically on the status of the Haskell' language standard. As mentioned previously, we are currently focusing on two topics, concurrency and the class system. If you feel that you have anything important to contribute to those topics, now is the time to review the proposals, join in the Haskell' mailing list and let us know what you know! Stephanie Weirich has posted a summary of the class system discussion here: http://hackage.haskell.org/trac/haskell-prime/wiki/ClassSystem Stephanie says: This page is important because it lists all of the proposals not related to MPTCs as well as trying to capture the big picture about where we stand with respect to MPTCs. I've been trying to not duplicate text that appears elsewhere in the wiki, but just provide a consistent picture of the state of the discussions on the mailing list. Please take a look at this page and help me fill it out. In particular, 've been trying to take a pulse of where we stand on some of these issues, and some of you may not agree! Tell me if I'm off the wall. Also, I've (mostly) concentrated on issues that have tickets, so I may have missed some issues that were only discussed in the mailing list. Please let me know if there is anything I've forgotten. Simon Marlow has posted a summary of the concurrency discussion here: http://hackage.haskell.org/trac/haskell-prime/wiki/Concurrency Simon says: I have tried to summarise the various points that have arisen during the discussion. If anyone feels they have been mis-paraphrased, or I have forgotten something, please feel free to edit, or send me some text for inclusion. I don't want to include long gobs of text in here, though: just summarise the main points, and if necessary link to relevant mailing list posts. Thanks, Simon Stephanie for keeping things moving forward! peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell.org and Google Summer of Code 2006
Paolo, Thanks for your work in organizing this. Google wants an answer from me by Monday (I seem to be the point of contact). So if you have objections, let us know! Feel free to forward this to anyone you think would want a say in the matter. peace, isaac Paolo Martini [EMAIL PROTECTED] writes: Hello everybody, nice to meet you all. Last year I did work on an Haskell project during the first year of the Google Summer of Code programme[1]. I wrote the bindings to the Cairo Vector Graphics library and integrated them in Gtk2Hs. You can see last year's announcement on the website[2]. I had to take Google itself as my mentoring organization, in absence of a better-suited one, no wonder I was the only one with an Haskell project, eventually I got one of its 13 slots available -- Chris DiBona[3], the project leader, seem to like Haskell very much! They recently announced they would be running the programme again this year, and I thought we could surely do better! My idea is that the best way we are going to get more Haskell projects done is having Haskell.org as a mentoring organization this year. Let me briefly summarize how the project works; it starts with a number of mentoring organizations that support active open source projects. They are required to publish a list of projects for students to apply for, and some mentors which will take care of the pupils during their work. Part of the fun is of course that the students can propose their own projects too. Each successful applicant gets an initial $500, three months of coding time, a mid- term $2,000 of are doing well and a final $2,000 on successful completion of the project (The site[4] does explain it all.) I contacted many of the people who usually reside in the #haskell IRC channel asking for collaboration, and they promptly accepted, forming a quite big number of well organized people -- as now, those three people are in charge for the administrative work: - Isaac Jones http://www.syntaxpolice.org/, - Donald Bruce Steward http://www.cse.unsw.edu.au/~dons/, - David Himmelstrup http://darcs.haskell.org/~lemmih/aboutMe.html. Not surprisingly, since the people of the channel are known to be very kind and helpful, answering questions at every time of the day, I've got a good number of volunteers for mentoring too (which I'm very happy about): - David Himmelstrup, - John Goerzen http://www.complete.org/, - Cale Gibbard http://www.haskell.org/hawiki/CaleGibbard, - Einar Karttunen http://www.cs.helsinki.fi/u/ekarttun/, - Shae Matijs Erisson http://www.ScannedInAvian.com/, - Duncan Coutts http://haskell.org/gtk2hs/development/. - Andres L\¨oh http://www.iai.uni-bonn.de/~loeh, - Ian Lynagh http://web.comlab.ox.ac.uk/oucl/work/ian.lynagh/, And the list is getting bigger and bigger! Unsure about where to get an authoritative answer about things like this I have mailed Simon Peyton-Jones, he likes the idea (Thanks very much!) He explained to me that since the Haskell community is very decentralized I would better send a message to the Haskell mailing list to propose this project. I hope you will be as enthusisatic as I am. Hacking Haskell code during the summer, funded enough to keep up with the other things (and getting some pretty cool hardware lately), was a *great* experience. I sincerely hope that many students will apply for Haskell works. We need projects done! I'll be mailing you the url of the wikipage collecting projects and details. Thank you very much, Paolo. -- [1] http://code.google.com/summerofcode.html [2] http://haskell.org/gtk2hs/?p=30 [3] http://dibona.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announcing Halfs, a Haskell Filesystem
Halfs is a filesystem implemented in the functional programming language Haskell. Halfs can be mounted and used like any other Linux filesystem, or used as a library. Halfs is a fork (and a port) of the filesystem developed by Galois Connections. We've created a virtual machine to make using Halfs extremely easy. You don't need an extra partition or a thumb drive, or even Linux (Windows and Mac OS can emulate the virtual machine). For the impatient, go to the quick start: http://hackage.haskell.org/trac/halfs/wiki/QuickStart The Halfs web page is here: http://www.haskell.org/halfs/ Background: In the course of developing a web server for an embedded operating system, Galois Connections had need of a filesystem which was small enough to alter to our needs and written in a high-level language so that we could show certain high assurance properties about its behavior. Since we had already ported the Haskell runtime to this operating system, Haskell was the obvious language of choice. Halfs is a port of our filesystem to Linux, with some modifications. High assurance development is a methodology for creating software systems that meet rigorously-defined specifications with a high degree of confidence. That methodology comprises tools and practices. Its goal is to produce such systems reliably and effectively, with an ordinary degree of developer effort. Haskell is particularly well-suited to high assurance development. It is a high-level, fully-expressive, pure, functional language, with a powerful type system. One of the obligations of high assurance development is the demonstration of strong correspondence between high-level executable models and the eventual implementation. Haskell supports this directly: it can describe systems all the way from high-level executable models through to system implementations. The fact that Haskell is pure comes from its mathematical basis, and means that, by default, a function does not interfere with other functions. The type system is an automatic and scalable proof engine that can encode and enforce desirable properties. Together, these features allow the correctness of complex systems to be established, making Haskell ideal for high assurance development. The question was whether Haskell is well suited as the implementation language for a filesystem, which involves fixed sized buffers, lots of IO, and binary data structures. Though correctness is much more important to us than performance, we hoped that a Haskell filesystem would have acceptable performance, and that writing such low-level code would not be awkward or error-prone. We have developed a filesystem, Halfs, which aims to answer the above questions. One may mount a Halfs filesystem in Linux using the FUSE (Filesystem in Userspace) kernel module. We have created two new monads, FSRead and FSWrite which restrict the IO monad to reading and writing operations respectively. For performance, Halfs uses efficient mutable arrays for block IO, as well as caching for blocks and inodes. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Announcing Halfs, a Haskell Filesystem
Halfs is a filesystem implemented in the functional programming language Haskell. Halfs can be mounted and used like any other Linux filesystem, or used as a library. Halfs is a fork (and a port) of the filesystem developed by Galois Connections. We've created a virtual machine to make using Halfs extremely easy. You don't need an extra partition or a thumb drive, or even Linux (Windows and Mac OS can emulate the virtual machine). For the impatient, go to the quick start: http://hackage.haskell.org/trac/halfs/wiki/QuickStart The Halfs web page is here: http://www.haskell.org/halfs/ Background: In the course of developing a web server for an embedded operating system, Galois Connections had need of a filesystem which was small enough to alter to our needs and written in a high-level language so that we could show certain high assurance properties about its behavior. Since we had already ported the Haskell runtime to this operating system, Haskell was the obvious language of choice. Halfs is a port of our filesystem to Linux, with some modifications. High assurance development is a methodology for creating software systems that meet rigorously-defined specifications with a high degree of confidence. That methodology comprises tools and practices. Its goal is to produce such systems reliably and effectively, with an ordinary degree of developer effort. Haskell is particularly well-suited to high assurance development. It is a high-level, fully-expressive, pure, functional language, with a powerful type system. One of the obligations of high assurance development is the demonstration of strong correspondence between high-level executable models and the eventual implementation. Haskell supports this directly: it can describe systems all the way from high-level executable models through to system implementations. The fact that Haskell is pure comes from its mathematical basis, and means that, by default, a function does not interfere with other functions. The type system is an automatic and scalable proof engine that can encode and enforce desirable properties. Together, these features allow the correctness of complex systems to be established, making Haskell ideal for high assurance development. The question was whether Haskell is well suited as the implementation language for a filesystem, which involves fixed sized buffers, lots of IO, and binary data structures. Though correctness is much more important to us than performance, we hoped that a Haskell filesystem would have acceptable performance, and that writing such low-level code would not be awkward or error-prone. We have developed a filesystem, Halfs, which aims to answer the above questions. One may mount a Halfs filesystem in Linux using the FUSE (Filesystem in Userspace) kernel module. We have created two new monads, FSRead and FSWrite which restrict the IO monad to reading and writing operations respectively. For performance, Halfs uses efficient mutable arrays for block IO, as well as caching for blocks and inodes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
Re: [Haskell-cafe] planet.haskell.org? for Haskell blogs
Antti-Juhani Kaijanaho [EMAIL PROTECTED] writes: Antti-Juhani Kaijanaho wrote: Since nobody else seems to have volunteered, I'll try to set this up (if I can get the software working). If you want your blog listed, email me. I will not add people without their consent. Just tell me your RSS/Atom feed URI (try to pick one that will not contain non-English posts; but there is no need to restrict to just Haskell-related posts - half of the beauty is seeing what else people are doing and thinking). Now at http://antti-juhani.kaijanaho.fi/planet-haskell/ . This is obviously a temporary address (somebody set up a proper Haskell DNS for this; I can configure this to answer a particular domain name). Cool, if you think you want to manage this, we can probably host it on the hackage.haskell.org machine. What would you think of that? peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] planet.haskell.org? for Haskell blogs
I think someone should volunteer to set up Planet Haskell ala Planet Debian, Planet Gnome, Planet Perl, etc. These sites are Blog aggregators. Basically they just collect the RSS feeds of the community and post their blogs to a web page in a cute format (the gnome one is especially cute, but you probably could have guessed that). There's already software out there for this, so nothing new needs to be written. I think we need a volunteer to set this up somewhere? Preferably someone with their own server, and we'll worry about setting up the DNS later :) peace, isaac See: http://planet.debian.org/ http://planet.gnome.org/ http://planet.perl.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
[Haskell-cafe] Haskell' Status
I'll try to occasionally post an announcement of the the status of Haskell'[1], the next Haskell standard, so that you can all be aware of my thinking, and our current place in the timeline. There is a list of proposals and a strawman categorization of them on the wiki[2]. The categorization reflects someone's current thinking about what's in and out, but it's really just for discussion at this phase. The timeline for this effort is also on the wiki[4]. You'll notice that it's very aggressive; we plan to announce something at the next Haskell Workshop in September. Our current spot in the timeline is that we're meant to be brainstorming, discussing, and refining proposals. I've just posted some leading questions [3] in order to focus the discussion a bit. I can't help but notice that there is a lot of excitement (and support?) for a larger standard; one that would have a bigger impact. I think that part of the Haskell' effort should be to make a plan for moving forward. At the very least we should have a set of recommendations for what the community needs to work on between this and the next standard; what are the most promising proposals and what needs to happen to make them a reality. I think that the wiki will be a great resource for any future standard, and we should work to make it as nice as possible. Please reply to the Haskell' mailing list, and email me if you have any questions. peace, isaac [1] Haskell' Wiki: http://hackage.haskell.org/trac/haskell-prime [2] list of proposals and strawman categorization: http://hackage.haskell.org/trac/haskell-prime/report/9 [3] plan for moving discussion forward http://www.haskell.org//pipermail/haskell-prime/2006-February/000582.html [4] The TimeLine is here. Ascii text of the timeline follows (might not make sense unless you use a proportional font: http://hackage.haskell.org/trac/haskell-prime/wiki/TimeLine Write ReportReview | | Edit| Discuss / Refine--|--| | | | || | brainstorm--- | || | | | | | || | setup | | | || | | | | | || | --- 10 | 11 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 2005 2006 --- | | | | | | Face-To-Face? | StrawmanTrial Decision Announce @HW ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] System.FilePath survey
Wolfgang Jeltsch [EMAIL PROTECTED] writes: Am Freitag, 3. Februar 2006 12:03 schrieb Krasimir Angelov: [...] * Will you be happy with a library that represents the file path as String? The opposite is to use ADT for it. The disadvantage is that with the current IO library we should convert from ADT to String and back again each time when we have to do any IO. The ADT may have advantages for the internal library implementation. I would very much prefer an ADT. An ADT would describe the actual logical structure of a file path and this is something we should always try to achieve. Has anyone yet volunteered to do the hard work of defining an ADT and made a proposal for how it should interact w/ the System.IO functions? I think that lacking a FilePath module is a serious problem that is holding haskell back. Lots of languages use String for filepath, like Python, which is hugely popular for these uses, but has nothing on Haskell, IMO, except this single library. Lots of people have written home-grown FilePath modules. How long can we wait for an implementation to appear? peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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
[Haskell-cafe] darcs: the first haskell tool more popular than Haskell itself?
Greetings, Debian has a system called popularity-contest, which is an opt-in survey of package use. I was curious to see the ranking of darcs among Haskell implementations themselves. The results: Darcs ranks higher than ghc and hugs. #name is the package name; #inst is the number of people who installed this package; #vote is the number of people who use this package regularly; #old is the number of people who installed, but don't use this package # regularly; #recent is the number of people who upgraded this package recently; #no-files is the number of people whose entry didn't contain enough # information (atime and ctime were 0). #rank nameinst vote old recent no-files (maintainer) 138 darcs563 159 280 124 0 (Isaac Jones) (51) hugs 304 119 15728 0 (Isaac Jones) 321 ghc6 194818033 0 (Ian Lynagh) Hugs is listed in a different category, so the ranking is off. Ian Lynagh pointed me at this nice graph showing the historical installation of the three packages: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=ghc6,darcs,hugsshow_installed=onwant_percent=onwant_legend=onbeenhere=1 peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs: the first haskell tool more popular than Haskell itself?
Iavor Diatchki [EMAIL PROTECTED] writes: (snip) yet another thing (and this is debian specific) is that i use the darcs distributed with debian, which is old but works fine, The darcs shipped w/ Debian Stable might be oldish, but that's the darcs that was available when Debian was frozen. The Debian unstable version is 1.0.5 (the newest), and testing should be there soon. If you're using stable, you can configure your system so that you can say: apt-get install darcs/unstable So it'll just get the unstable darcs and keep everything else as stable. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Haskell': Kicking off the process of defining the next Haskell standard.
let haskell' = succ haskell98 in Announcing the Haskell' (Haskell-Prime) process. A short time ago, I asked for volunteers to help with the next Haskell standard. A brave group has spoken up, and we've organized ourselves into a committee in order to coordinate the community's work. It will be the committee's task to bring together the very best ideas and work of the broader community in an open-source way, and to fill in any gaps in order to make Haskell' as coherent and elegant as Haskell 98. Our task is broadly defined by our mission statement: The Haskell programming language is more-or-less divided into two branches. The Haskell 98 standard is the stable branch of the language, and that has been a big success. A lot of progress has been made over the last few years in the research branch of the Haskell language. It is constantly advancing, and we feel that it is time for a new standard which reflects those advancements. Haskell' will be a conservative refinement of Haskell 98. It will be the work of this committee to adopt a set of language extensions and modifications and to standardize a new set of libraries. We will strive to only include tried-and-true language features, and to define them at least as rigorously as Haskell 98 was defined. This standard will reflect the realities of developing practical applications in the Haskell language. We will work closely with the rest of the Haskell community to create this standard. Your Haskell' Committee is as follows (slightly munged email addresses follow): * Manuel M T Chakravarty chak at cse.unsw.edu.au * John Goerzen jgoerzen at complete.org * Bastiaan Heeren bastiaan at cs.uu.nl * Isaac Jones ijones at galois.com * John Launchbury john at galois.com * Andres Loeh loeh at iai.uni-bonn.de * Simon Marlow simonmar at microsoft.com * John Meacham john at repetae.net * Ravi Nanavati ravi at bluespec.com * Henrik Nilsson nhn at cs.nott.ac.uk * Ross Paterson ross at soi.city.ac.uk * Simon Peyton-Jones simonpj at microsoft.com * Don Stewart dons at cse.unsw.edu.au * Audrey Tang autrijus at gmail.com * Simon J. Thompson S.J.Thompson at kent.ac.uk * Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk * Stephanie Weirich sweirich at cis.upenn.edu The editors are Isaac Jones and John Launchbury. Feel free to contact any of us with any concerns or questions. If you don't know who to direct your questions to, email Isaac Jones [EMAIL PROTECTED] Community involvement is vital to our task, and there will be a way for members of the community to make formal proposals. In the opening phases, please use these more informal resources to help us coordinate Haskell': * The haskell-prime mailing list. All technical discussion will take place here, or (if other meetings take place) be reported here. Anyone can subscribe, and any subscriber can post questions and comments, and participate in discussions. Anyone can read the list archives. http://haskell.org/mailman/listinfo/haskell-prime * A wiki / issue tracking system to document consensus and to track ongoing tasks. This system is publicly readable, but only committee writable so that we may present it as the official output of the committee. If you ever feel that the wiki is not accurate as to the consensus, please alert the committee! http://hackage.haskell.org/trac/haskell-prime * A darcs code repository for experiments, proposed libraries,and complex examples. darcs is a decentralized system, so anyone can use it, but patches should be sent to Isaac Jones: http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode Please join us in making Haskell' a success. your, Haskell' Committee p.s. Please feel free to forward this announcement to appropriate forums. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Haskell': Kicking off the process of defining the next Haskell standard.
let haskell' = succ haskell98 in Announcing the Haskell' (Haskell-Prime) process. A short time ago, I asked for volunteers to help with the next Haskell standard. A brave group has spoken up, and we've organized ourselves into a committee in order to coordinate the community's work. It will be the committee's task to bring together the very best ideas and work of the broader community in an open-source way, and to fill in any gaps in order to make Haskell' as coherent and elegant as Haskell 98. Our task is broadly defined by our mission statement: The Haskell programming language is more-or-less divided into two branches. The Haskell 98 standard is the stable branch of the language, and that has been a big success. A lot of progress has been made over the last few years in the research branch of the Haskell language. It is constantly advancing, and we feel that it is time for a new standard which reflects those advancements. Haskell' will be a conservative refinement of Haskell 98. It will be the work of this committee to adopt a set of language extensions and modifications and to standardize a new set of libraries. We will strive to only include tried-and-true language features, and to define them at least as rigorously as Haskell 98 was defined. This standard will reflect the realities of developing practical applications in the Haskell language. We will work closely with the rest of the Haskell community to create this standard. Your Haskell' Committee is as follows (slightly munged email addresses follow): * Manuel M T Chakravarty chak at cse.unsw.edu.au * John Goerzen jgoerzen at complete.org * Bastiaan Heeren bastiaan at cs.uu.nl * Isaac Jones ijones at galois.com * John Launchbury john at galois.com * Andres Loeh loeh at iai.uni-bonn.de * Simon Marlow simonmar at microsoft.com * John Meacham john at repetae.net * Ravi Nanavati ravi at bluespec.com * Henrik Nilsson nhn at cs.nott.ac.uk * Ross Paterson ross at soi.city.ac.uk * Simon Peyton-Jones simonpj at microsoft.com * Don Stewart dons at cse.unsw.edu.au * Audrey Tang autrijus at gmail.com * Simon J. Thompson S.J.Thompson at kent.ac.uk * Malcolm Wallace Malcolm.Wallace at cs.york.ac.uk * Stephanie Weirich sweirich at cis.upenn.edu The editors are Isaac Jones and John Launchbury. Feel free to contact any of us with any concerns or questions. If you don't know who to direct your questions to, email Isaac Jones [EMAIL PROTECTED] Community involvement is vital to our task, and there will be a way for members of the community to make formal proposals. In the opening phases, please use these more informal resources to help us coordinate Haskell': * The haskell-prime mailing list. All technical discussion will take place here, or (if other meetings take place) be reported here. Anyone can subscribe, and any subscriber can post questions and comments, and participate in discussions. Anyone can read the list archives. http://haskell.org/mailman/listinfo/haskell-prime * A wiki / issue tracking system to document consensus and to track ongoing tasks. This system is publicly readable, but only committee writable so that we may present it as the official output of the committee. If you ever feel that the wiki is not accurate as to the consensus, please alert the committee! http://hackage.haskell.org/trac/haskell-prime * A darcs code repository for experiments, proposed libraries,and complex examples. darcs is a decentralized system, so anyone can use it, but patches should be sent to Isaac Jones: http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode Please join us in making Haskell' a success. your, Haskell' Committee p.s. Please feel free to forward this announcement to appropriate forums. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] please send your cabal bug reports, wishlist, and patches!
Greetings, I'm trying hard to get a better hold on the Cabal[1] project, and a more clear idea of all the outstanding work that needs to be done. I've gone through my mailbox to dig up stuff like this, but no doubt some has slipped between the cracks. I started a bug tracker / wiki a few weeks ago, and would like your help to make sure that it reflects _all_ of the work that needs to be done in Cabal. If you've sent me a feature request or bug report that hasn't been added to Cabal, can you please check if it is on the wiki, and if not, create a ticket (bug report) for it: Cabal Wiki Bug Tracker: http://hackage.haskell.org/trac/hackage/ If you're not sure, or don't want to use the bug tracker, just email me. This bug tracker is a great place to make more complex feature requests, as it has full wiki markup. See this ticket for a nice example: http://hackage.haskell.org/trac/hackage/ticket/27 Also, if you've sent me any patches that are not yet applied, please re-send them to me. peace, isaac [1] http://www.haskell.org/cabal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] using cabal? add your package to the list!
I started a list of packages using cabal (including those uplaoded to Hackage). Please either upload your packages to hackage, or add it here. I want this list so that I can try to figure out things like how much a given modification to Cabal will break stuff: http://hackage.haskell.org/trac/hackage/wiki/CabalPackages To add your package to the list, hit Edit Page at the bottom of the page. Feel free to make the page into a table, add links for the packages already there, reorganize, etc. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] formal methods functional programming
Abigail [EMAIL PROTECTED] writes: Hi, I have been searching papers about tha raltionship between formal methods in software engineering and functinal programmming, but i haven't found enough information. I don't think there are any papers, but Galois Connections employs Haskell and formal methods such as proof checkers in our work. You might email for more information: http://www.galois.com/ peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: Cabal support for djinn
Lennart Augustsson [EMAIL PROTECTED] writes: Thanks! It's in the next version. I'll also make the license less restrictive. (With no explicit copyright information in the files the default copyright applies, i.e., I have all rights.) I just grabbed the darcs version and uploaded it to hackage, the Haskell Package Database (Beta): http://hackage.haskell.org/ModHackage/Hackage.hs?action=view peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] cabal and ghcconfigure.h
Robert Dockins [EMAIL PROTECTED] writes: [snip] So you are listing extensions in the source files rather than the .cabal file, which should be OK (except that it's non-portable, of course). So cabal really shouldn't have anything to do with it. So it _should_ be all about how cabal is calling GHC... The question is, if the cpp flag is getting to ghc, why isn't ghc itself looking for the ghcconfig.h file? Looks like the difference is here: WORKING VERSION: /opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes (...) BROKEN VERSION: /usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend (...) Removing the -hide-all-packages flag from the command line causes the package to compile. Apparently if package base is not in scope, then GHC won't find ghcconfig.h in the preprocess phase. Ahh, I did not know that. Is there ever a reason for the base package not to be in scope? If cabal is going to add the -hide-all-packages flag, then perhaps it should also add -package base? Build dependencies have to be exact starting with GHC 6.4.1. We added the hide-all-package flag so that users will get exact build dependencies in their .cabal files instead of just relying on the packages they have on their systems. People may not want to depend on base, for instance if they just want to be haskell98, so that's why cabal doesn't automatically make a build dependency on base. Sorry that this was tricky to debug. Adding a Build-Depends clause to my cabal file with all my dependencies fixes the problem. Excellent! peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] cabal and ghcconfigure.h
Robert [EMAIL PROTECTED] writes:
On Dec 1, 2005, at 10:18 AM, Duncan Coutts wrote:
On Wed, 2005-11-30 at 22:48 -0500, Robert Dockins wrote:
I've just run across a problem with my cabal build system -- I'm not yet
sure
if this is a cabal problem or a system configuration problem.
Is this a public darcs repository so I can try this out on my own?
(snip)
$ runhaskell Setup.hs build -v
Preprocessing library Cmm-0.1...
/usr/bin/alex -g -o src/Language/Cmm/Parser/CmmLex.hs
src/Language/Cmm/Parser/CmmLex.x
/usr/bin/happy -agc -o src/Language/Cmm/Parser/CmmParser.hs
src/Language/Cmm/Parser/CmmParser.y
Preprocessing executables for Cmm-0.1...
Building Cmm-0.1...
/usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build
-hide-all-packages --make -i -isrc Language.Cmm.Frontend
It looks like you're not listing CPP as an extension, and therefore
Cabal is not doing anything whatsoever wrt cpp. It's not adding the
-cpp argument to ghc, and it's not preprocessing the sources
beforehand...
(snip)
Chasing modules from:
Language.Cmm.Frontend,Language.Cmm.Datatypes,Language.Cmm.Parser,Language.Cmm.Lint,Language.Cmm.Messages,Language.Cmm.Messages.EN,Language.Cmm.Parser.CmmLex,Language.Cmm.Parser.CmmParser,Language.Cmm.Parser.PPrSyntax,Language.Cmm.Parser.Syntax,Language.Cmm.Parser.Tokens,Language.Cmm.Parser.ParseMonad,Language.Cmm.Parser.ParserUtils,Language.Cmm.Parser.LexUtils,Language.Cmm.Lint.SymbolTable,Language.Cmm.Lint.BuildTables,Language.Cmm.Lint.LintMonad,Language.Cmm.Lint.Typecheck,Language.Cmm.Lint.LintProc,Language.Cmm.Lint.LintConstants,Language.Cmm.Lint.LintTop
src/Language/Cmm/Parser/CmmLex.hs:19: ghcconfig.h: No such file or
directory
There's the error...
The offending file has the same opening, which looks like:
-
{-# OPTIONS -fglasgow-exts -cpp #-}
So you are listing extensions in the source files rather than the
.cabal file, which should be OK (except that it's non-portable, of
course). So cabal really shouldn't have anything to do with it. So
it _should_ be all about how cabal is calling GHC... The question is,
if the cpp flag is getting to ghc, why isn't ghc itself looking for
the ghcconfig.h file? Looks like the difference is here:
WORKING VERSION:
/opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir
dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes
(...)
BROKEN VERSION:
/usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build
-hide-all-packages --make -i -isrc Language.Cmm.Frontend
(...)
But either way, it seems to work for me on my simple test cases, so I
can't reproduce it with cabal-head (1.1.4) or 1.1.3. Can you either
let me see your code or create a small test case that fails?
Another option is to try to construct a ghc command line which will
work on both machines. If you paste the working version onto the
command line on the broken machine, does it still not work?
Same versions of alex?
BTW, does cpphs do anything with ghcconfig.h? Should cabal be adding
that include path somewhere in the cases where it uses cpphs?
peace,
isaac
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Interest in helping w/ Haskell standard
At the end of the Haskell Workshop at ICFP, we had the traditional Future of Haskell discussion (chaired by Andres Loeh). One of the main topics was the perceived need of a new standard, because the Haskell 98 standard is quite old already, and Haskell has evolved in the meantime, leading to a situation where almost none of the actually existing Haskell programs is according to the 98 standard. No clear opinion was visible on what form a new standard would take. There was, however, considerable support for the idea to standardize an incremental and moderate extension to Haskell 98 (working name Haskell 06 or Industrial Haskell). This effort would then be separate from discussion about the Real Next Version (dubbed Haskell 2). John Launchbury asked for a show of hands of those who would be interested in helping out with the Haskell 06 standard. I think helping means willing to spend a non-trivial amount of time. That is, it's pretty well expected that most Haskellers will be willing to contribute to discussion on the mailing lists, but we're trying to get a list of those who want to take it to the next level. If you raised your hand, or if you think this describes you, please email John Launchbury at [EMAIL PROTECTED] peace, Isaac Jones Andres Loeh ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard
(Trimming CC list. Maybe we should take this to haskell-cafe?) Sebastian Sylvan [EMAIL PROTECTED] writes: (snip quotes) I'm wondering what incremental and moderate extension means? Does it mean completely backwards compatible or can it mean completely new features including ones which subsume existing ones (I'm specifically interested in seeing SPJ's records proposal included, and a new module system). I was intentionally not addressing that question, because it's pretty much The Question. I certainly don't know the answer; just trying to figure out who wants to get involved, as a first step. I think everyone is agreed, though, that any process is going to be a very open one. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard
(Trimming CC list. Maybe we should take this to haskell-cafe?) Sebastian Sylvan [EMAIL PROTECTED] writes: (snip quotes) I'm wondering what incremental and moderate extension means? Does it mean completely backwards compatible or can it mean completely new features including ones which subsume existing ones (I'm specifically interested in seeing SPJ's records proposal included, and a new module system). I was intentionally not addressing that question, because it's pretty much The Question. I certainly don't know the answer; just trying to figure out who wants to get involved, as a first step. I think everyone is agreed, though, that any process is going to be a very open one. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Missing docs on Debian?
Yitzchak Gale [EMAIL PROTECTED] writes: (on the Haskell Unsafe debian repository) For the benefit of other Debian users, Google took me here: http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html where I found the following lines to add to my /etc/apt/sources.list file: deb http://haskell-unsafe.alioth.debian.org/archive/i386 . unstable deb-src http://haskell-unsafe.alioth.debian.org/archive/i386 . unstable If you are using Debian stable, and you want the not-quite-as-old Haskell packages from testing, change unstable to stable in the above lines. You can do the same thing with Unstable; just add unstable entries to your /etc/apt/souces.list and add a preferences file that says you prefer to get everything from testing or stable or whatever. Then if you want something from Unstable, just say apt-get install ghc6/unstable. Unstable is more stable than unsafe, btw ;) peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: cannot compile ghc on Debian unstable
Yitzchak Gale [EMAIL PROTECTED] writes: Isaac Jones wrote: Aaron Denney writes: Isaac Jones wrote: Michael Vanier writes: Right now, the Debian unstable package for GHC 6.4 won't install due to some conflict with libgmp3... ...install the libgmp3 from stable... That might work? It should, but I have other packages that depend on a newer version of libgmp3... I believe that this is fixed now... ghc6 in unstable now depends on libgmp3c2 which conflicts with libgmp3. So, for example, ghc6 now conflicts with darcs. Believe me... I know. People are working on this problem. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Missing docs on Debian?
Yitzchak Gale [EMAIL PROTECTED] writes: Using Debian testing with the ghc6-doc package installed (version 6.4-3), It looks to me like this isn't the version from testing fwiw, but the version from unstable. You might want to make sure that your versions of ghc and ghc-doc are consistent. I just noticed that I only seem to have the Hierarchical Libraries manual, but not the User's Guide nor the Cabal docs (nor hslibs docs). Those links are broken on the index.html page that was installed. I'm using unstable w/ ghc6-doc version 6.4-4, and this link: file:///usr/share/doc/ghc6-doc/html/index.html Seems to give me access to each of the user's guide, hierarchical libraries, old hierarchical libraries, and cabal docs. Did I do something wrong, or is there a reason that those were omitted? First I would just check to see if this file exists: file:///usr/share/doc/ghc6-doc/html/users_guide/index.html If not, try upgrading to the new version (maybe Ian can say whether there's any fix between -3 and -4). If that doesn't fix it, then you might start to wonder why you have ghc 6.4 with testing; did you get this -doc package from the Haskell Unsafe repository, or from the unstable repository? Finally, file a bug report against the package with reportbug if none of the above works. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] [beta] cabal-get: install haskell packages automatically
Bulat Ziganshin [EMAIL PROTECTED] writes: Hello Isaac, Monday, September 05, 2005, 12:16:46 AM, you wrote: IJ We're looking for beta testers to try out cabal-get (for downloading IJ and installing) and cabal-put (for uploading to the central IJ repository). We're also looking for more developers to work on this. can i ask for some more abilities? specifically, about web interface to package/applications database We already have this, under the view link. and ability to include in this database other things related to Haskell, such as papers and peoples? That would be pretty interesting... we're not really set up for anything like this yet; the wiki could be used for some of this. I think Shae (cc'd) is working on something for papers. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hat support in Cabal (was: How to debug GHC)
Malcolm Wallace [EMAIL PROTECTED] writes: Isaac Jones [EMAIL PROTECTED] writes: 1. Hat requires users to restrict themselves to a certain small subset of the standard libraries, and to use hmake Also the issue of how libraries are distributed in Haskell is a little bit in flux at the moment, since Cabal is still being polished. This doesn't really have anything to do with Cabal as far as I know. Hat comes with pre-translated libraries for a subset of the GHC libraries. It's true that the libraries that come with the compilers may change in the future, partly due to Cabal, but I don't think this is the reason that Hat doesn't come with all the libraries. Hat doesn't even use Cabal, AFAIK, but hmake. Well, the hope is that, eventually, Hat should be able to take any Cabal-ised library and transparently build it for tracing. Or maybe it will be Cabal that will support building for tracing as one way amongst others (profiling, etc). In any case, the point is that Hat pre-dates Cabal and so has no support for it, that Cabal is still under development, and that eventually there should be a good story for using Cabal+Hat together, but it isn't there right now. I think the later is the way to go, add a way to cabal to build hat-enabled libraries. Cabal has all the information, the list of source files, extensions, which compiler you're building for (does that matter to hat?). This would be a great feature to add to Cabal :) But we don't really yet have a way to build a set of libraries in a particular way. It's _less_ painful now to build profiling libraries, but you still have to go through and build each one. Maybe cabal-get can help with that. One problem for GHC is that ghc-pkg doesn't have any sense of way afaik... if I build package A without profiling support, and package B depends on package A, cabal's configure stage for package B can't detect whether or not A is built with profiling support... well, maybe it could go look for the profiling libraries or something. We might have a similar problem w/ hat-enabled libraries, and maybe slightly worse... I know that GHC profiling libraries can live alongside non-profiling versions; if you build package B with profiling, GHC just looks for the right version of package A's library in a standard place. But for Hat, I'd guess we want to keep a separate hierarchy for Hat-enabled libraries, maybe even a different package database (hmmm!). In fact, that's probably what should happen for profiling and any other way which requires that all packages be built the same way. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [beta] cabal-get: install haskell packages automatically
Beta testers wanted! Lemmih (mostly) has been working on a tool which will download and install Haskell packages and their dependencies. This tool should work for any cabal-compatible package. We're looking for beta testers to try out cabal-get (for downloading and installing) and cabal-put (for uploading to the central repository). We're also looking for more developers to work on this. The home, for now is here: http://hackage.haskell.org/ModHackage/Hackage.hs?action=home and to get cabal-get, grab the bootstrapper: darcs get http://hackage.haskell.org/darcs/cabal-get-bootstrap And execute the Install.lhs file. You may have to modify it slightly if you don't like the defaults. After you install cabal-get, you should be able to install cabal-put by saying: cabal-get update cabal-get install cabal-put Darcs repositories for all the tools are here: http://hackage.haskell.org/darcs/ Questions or problems? Email me or Lemmih. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to debug GHC
Bernard Pope [EMAIL PROTECTED] writes: On Thu, 2005-09-01 at 14:48 -0700, Frederik Eaton wrote: (snip) Are the following correct? 1. Hat requires users to restrict themselves to a certain small subset of the standard libraries, and to use hmake Depends what you mean by standard libraries. As far as I know it supports all the libraries which are specified in the Haskell 98 Report. I believe it also supports some libraries in the new hierarchy that come with the compilers. Also, many libraries can be used by Hat, if you include them in your own source tree. Supporting all libraries that come packed with GHC would be nice, but there are numerous hurdles that need to be jumped over to get to that point. For instance, some libraries do not use portable Haskell code. Also the issue of how libraries are distributed in Haskell is a little bit in flux at the moment, since Cabal is still being polished. This doesn't really have anything to do with Cabal as far as I know. Hat comes with pre-translated libraries for a subset of the GHC libraries. It's true that the libraries that come with the compilers may change in the future, partly due to Cabal, but I don't think this is the reason that Hat doesn't come with all the libraries. Hat doesn't even use Cabal, AFAIK, but hmake. 2. Buddha doesn't work with GHC 6.4 True. This is a cabal issue, that I haven't had time to resolve. buddha is limited to even fewer libraries than Hat. Why is this a Cabal issue? Are you interested in adding Buddah support to Cabal? peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: cannot compile ghc on Debian unstable
Aaron Denney [EMAIL PROTECTED] writes: On 2005-08-30, Isaac Jones [EMAIL PROTECTED] wrote: Michael Vanier [EMAIL PROTECTED] writes: Right now, the Debian unstable package for GHC 6.4 won't install due to some conflict with libgmp3 (the package maintainer has been notified). The trick to getting this to work is to install the libgmp3 from stable. apt-get install libgmp3/stable #or grab it and install it with dpkg apt-get install ghc6 That might work? It should, but I have other packages that depend on a newer version of libgmp3. Well, I've held off on upgrading them, because of this. I believe that this is fixed now at least for i386. Try apt-get update and apt-get install ghc6. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] cannot compile ghc on Debian unstable
Michael Vanier [EMAIL PROTECTED] writes: Right now, the Debian unstable package for GHC 6.4 won't install due to some conflict with libgmp3 (the package maintainer has been notified). The trick to getting this to work is to install the libgmp3 from stable. apt-get install libgmp3/stable #or grab it and install it with dpkg apt-get install ghc6 That might work? peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] haskell and fuse
See also Jeremy Bobbio's fuse bindings here: http://cvs.haskell.org/darcs/hfuse/ I've been using them on the Halfs, the Haskell Filesystem that I'll be demoing at the Haskell Workshop. David Roundy [EMAIL PROTECTED] writes: (snip) The FuseIO module itself might be rather interesting for other projects (e.g. darcs), or even (one could imagine) as an alternative to the haskell standard IO libraries for filesystem access, since it'd allow you to write a function that is guaranteed by the typesystem to do nothing but read from a filesystem, and it'd also allow writing polymorphic filesystem access/modification code that could be applied outside the IO monad (e.g. to Slurpies). It would also allow one to use treat network objects (e.g. http or ftp) as filesystems. I haven't gotten a chance to really look at this yet, but it sounds really cool. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] PHI ¿ Python Haskell Interface
Gottfried F. Zojer [EMAIL PROTECTED] writes: Hello, Is anybody aware about the development status of PHI Python Haskell Interface Any time when I want to access I get a timeout http://page-208.caltech.edu/phi/ Any feedback welcomed I don't know anything about PHI, but there's a tool called missingpy that might do what you want: http://quux.org/devel/missingpy - What is MissingPy? - It's two things: 1. A Haskell binding for many C and Python libraries for tasks such as data compression, databases, etc. This can be found in the MissingPy module tree. 2. A low-level Haskell binding to the Python interpreter to enable development of hybrid applications that use both environments. This can be found in the Python module tree. The Haskell bindings above use this environment. MissingPy permits you to call Python code from Haskell. It does NOT permit you to call Haskell code from Python. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [EMAIL PROTECTED]: Re: -odir behaviour change in 6.4.1?]
Andres Loeh [EMAIL PROTECTED] writes: Hello again, (snip) Simon Says: Yes, this change was made for consistency (someone else reported the breakage). I've also patched Cabal, so perhaps you're using a version from before the fix? I must be doing something wrong, then. (snip) /usr/bin/ghc -odir dist/build/foo/foo-tmp/foo -hidir dist/build -c foo/foo.c That's the wrong part. /usr/bin/ghc -odir dist/build/foo/foo-tmp -hidir dist/build/foo/foo-tmp -o dist/build/foo/foo -hide-all-packages --make -i -i. -package base-1.0 dist/build/foo/foo-tmp/foo/foo.o Main.hs Chasing modules from: Main.hs Compiling Main ( Main.hs, dist/build/foo/foo-tmp/Main.o ) Linking ... gcc: dist/build/foo/foo-tmp/foo/foo.o: No such file or directory The file foo.o is at dist/build/foo/foo-tmp/foo/foo/foo.o ... Build.hs has this logic: odir | versionBranch ghc_vers = [6,4,1] = pref | otherwise = pref `joinFileName` dirOf c -- ghc 6.4.1 fixed a bug in -odir handling -- for C compilations. which is good, but it only does that for libraries, not executables. Damn. This needs to get refactored to share code. I think I fixed this. Should be in the latest darcs and CVS. Andres, can you try this and let me know? peace, isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cabal on OS X; ghc segfault?
Gregory Wright [EMAIL PROTECTED] writes: (snip) the failure is not related to what I am trying to build. It doesn't matter if I run the same command, runhaskell Setup.hs configure in the haskell-src-exts subdirectory. The failure is the same. The failure also occurs if I try to configure an simple homemade application using the cabal method on OS X. The same test application configures and builds correctly using cabal on FreeBSD 5.4 under ghc-6.4. Can you tell us what version of Cabal and GHC you are using? peace, isaac ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc and cabal
Serge D. Mechveliani [EMAIL PROTECTED] writes: (snip) I do have some difficulties with this, because Cabal-1.1.1 `README' suggests just to run `make install' as a root, I do not see any configureing possibility for the installation, and so on. Yes, perhaps the README should be tweaked to explain non-root installations. Actually, all you have to do is make setup and then install normally like any other package, except for the business of hiding the older version that's explained in the README. But, in principle, what is the relation between Cabal and GHC installation? In ghc-6.4.1.20050801, `ghci -package Cabal'says Cabal-1.0. I have read some of Cabal manual, about how to use runhaskell. But as I recall, I never installed Cabal. GHC has installed it itself. You can use runghc or runhugs you may or may not have runhaskell depending on your platform. Which Cabal version will be in official ghc-6.4.1 by default? It'll be 1.0 with some bug fixes (Simon: can you please make the version number '1.0.1'?) If it is 1.0, then ghc-6.4.1 will fail with `make' for profiling. So, the user needs to install another Cabal version and to link it to GHC, and this occurs difficult. This is likely to complicate the usage of GHC Yep. Profiling support won't be there, but some of the problems you faced in building a separate Cabal will hopefully be fixed in the new version of GHC. peace, isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] IO platform for testing
yin [EMAIL PROTECTED] writes: first I have to apologise for my English. Don't worry about that. ./bundle01 cmd arg1 arg2 ... I more apoarches, but no one worked. Now I tried this: m01_mod :: Int - Int - Int What's m01? You define b01 below: b01_mod a b = a mod b You must type that mod a b or a `mod` b. main = do (cmd:ss) - getArgs putStrLn ( if (cmd == mod) then do You don't need the do here. Since the type of the entire if statement is a String (not an IO String) this is an error. show (b01_mod (read (ss!!1)) (read (ss!!2))) else do unknown command!) Please, send me somethung like this (I need to understand it). I need runing more cmds and with various argument counts and types. All functions in a bundle should be in one file. Otherwise, looks roughly correct to me... The program will crash with a meaningless error if they don't enter any args. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO platform for testing
Matej 'Yin' Gagyi [EMAIL PROTECTED] writes: (snip) Please, send me somethung like this (I need to understand it). I need runing more cmds and with various argument counts and types. All functions in a bundle should be in one file. I need a module Main. So, when I write some function and save it in file funcsXX.hs and compile all the files, the result should be a program, which will execute my functions. I need it to test these functions, because I just started to learn Haskell. That is correct. I'm not sure what your question is. After writing this file (the beginning should read module Main where...) use GHC to compile it; lets call it yinTest: ghc --make YourFile.hs -o yinTest now hopefully ./yintest mod 4 2 will do the right thing! Otherwise, looks roughly correct to me... The program will crash with a meaningless error if they don't enter any args. Should I handle incorect situations? How does exception in Haskell work... When I'm writing a small program like this, I usually write something like: main = do args - getArgs case args of [] - helpMsg -- empty list [mod,arg1,arg2] - ... ... _ - helpMsg -- any other inputs helpMsg = error unknown command. Known commands are: 'mod' peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal --user question
Frederik Eaton [EMAIL PROTECTED] writes: Hi, How do I install a package in the user package.conf with cabal? It is not clear to me how to do this, looking at the output of 'configure --help'. There is an option --user to get dependencies from the user cabal file but this still, somewhat counterintuitively, tries to install the package in the global location (why would one want such behavior?). Specifying '--with-hc-pkg=ghc-pkg --user' doesn't seem to work either, when I do this then 'install' and 'unregister' complete without error but apparently have no effect. ./setup configure --user #if it depends on user-local packages ./setup build ./setup install --user Perhaps install --user should be the default if you configure --user. The user's guide is here: http://www.haskell.org/ghc/docs/latest/html/Cabal/ peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can't build module with ffi 'wrapper' by cabal (or ghc): unknown symbol
Evgeny Chukreev [EMAIL PROTECTED] writes: On Wed, 29 Jun 2005 22:05:49 +0400 /Evgeny/ /Chukreev/ [EMAIL PROTECTED] wrote me: EC gcc src/Codec/Mhash_stub.c -o ... EC /usr/bin/ar qv dist/build/libHSHMhash-0.1.a dist/build/src/Codec/Mhash.o EC /usr/bin/ar: creating dist/build/libHSHMhash-0.1.a EC a - dist/build/src/Codec/Mhash.o (why mhash_stub.o did not archived?) Does no answer to my question mean that there is no-one who knows what kind of bug it is (ghc/cabal/mine) or it is the fact that nobody cares (even the developers of ghc/cabal)? You posted to the wrong place. I don't follow this list as closely as [EMAIL PROTECTED] It would also help if you can describe your problem and only paste relevant details of your compiler interaction. Which version of Cabal are you using? Handling of _stub files is new in versions 1.0.1, which are not yet released, but you can get it from CVS / darcs or from the latest tarballs on the web page. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal with Alex and and Happy
Brian Smith [EMAIL PROTECTED] writes: Is there an example of how to build a Cabal package that has a lexer generated with Alex and a parser generated with Happy? As far as I can tell, the way to do this is to add Other-Modules: Module.Name.Of.Parser.y Module.Name.Of.Lexer.x to each executable/library stanza. But, when I try this, I get: No, they should just be Module.Name.Of.Parser and Module.Name.Of.Lexer. Could not find module `GHC.Exts': it is a member of package base-1.0, which is hidden The generated parser code contains: But your real problem is answered by the other replies on this thread. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] HaskellForge
Samuel Bronson [EMAIL PROTECTED] writes: (snip) I think we might actually be suffering from the invented here syndrome, namely because we got early exposure to darcs and many of us got hooked. I kinda disagree here. Haskell people were not using sourceforge way before we had Darcs :) It seems like there's a need for a self-organizing repository of libraries and tools. A CPAN-like Hackage might be enough, maybe we don't need a project hosting sight. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Haskell-related Job Posting, Portland OR area
Galois Connections does most of its development in Haskell, and this job may involve some Haskell development, so I felt it was on topic for this list. Senior Test Engineer Galois Connections, Inc., located near Portland, Oregon, designs and develops high confidence software for critical applications using cutting edge methods and technology. Innovative and highly creative problem-solving in the demanding application areas of security, information assurance and cryptography has earned Galois a reputation of excellence in both private and government sectors. Are you seeking an intellectually challenging position in which you'll own a mission-critical piece of a mission-critical product? Do you aspire to work with a team that shares your level of commitment and enthusiasm to develop tomorrow's high-assurance technology today? If so, you might be just the person we're looking for. Galois has recently opened a position for a Senior Test Engineer who will have end-to-end responsibility for the QA process, including planning, QA infrastructure, and assessments. This person will work in a highly cooperative and collaborative team setting and will be responsible for ensuring that our high-assurance projects deliver robust and fully functional systems according to client expectations and potential certifying agencies. For more details about this exciting opportunity please go to: http://www.galois.com/job_testengineer.php To learn more about Galois visit our website at http://www.galois.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Cabal problems
Sorry it took me so long to get back to you. I don't follow this mailing list as closely as I follow [EMAIL PROTECTED] Cabal bugs should be reported there or CC'd to me... Peter Simons [EMAIL PROTECTED] writes: Hi, I've run into a problem when trying to build a package with Cabal using a different GHC version than the one found in the $PATH. It looks like this: $ runghc Setup.lhs configure --with-compiler=/opt/ghc/bin/ghc-6.2.2 Warning: No license-file field. Configuring hsemail-0.0-2005-02-14... configure: looking for package tool: ghc-pkg near compiler in /opt/ghc/bin/ghc-6.2.2 Cannot find package tool: /opt/ghc/bin/ghc-pkg.2 Apparently there's some problem in the path manipulation code. Definitely sounds like a bug. I'll attack this ASAP. I also wonder why Cabal complains about a missing License field, because the file contains: License: GPL Is it complaining about the license-file field? It would like you to also provide a license file in order to be more legal. The license field is more for quick listing and automated tool uses, but who knows if its legally binding. Cabal warns you when you don't have a license-file field. Last but not least, Cabal fails when the package description file contains comments after the value. The entry Extensions: CPP -- some comment Yes, comments have to start at the beginning of the line, as the user manual says. Thanks for the bug report. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] haddock -cpp ? Cabal support for haddock ?
Johannes Waldmann [EMAIL PROTECTED] writes: What is the preferred way to generate haddockumentation from code that must be preprocessed (ghc -cpp)? Would Cabal support this? Cabal does support this. If you use the CPP extension, it'll preprocess the code before running haddock on it. I'd certainly welcome Cabal support for other haddock features as well (--source, --read-interface). I am not sure where to put all these arguments in the .cabal file. Cabal doesn't support these yet, though. Maybe in the future. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] cabal feature request
Benjamin Franksen [EMAIL PROTECTED] writes: I finally succeeded using cabal for a project that uses hsc2hs. My problem was/is I need to give special options to hsc2hs, for instance a different template header file to use. Cabal doesn't support this at the moment. I propose to give the user a bit more flexibility with regard to preprocessors, i.e. add some more tags to the .cabal file, like hsc2hs-options, cpp-options, ... I made the necessary changes for hsc2hs-options in a few minutes Did you alter the Cabal library itself? If so, then that won't work when you go to distribute it to others, since they won't have your altered cabal. You could do this in the UserHooks, by over-riding the hsc2hs preprocessor in your Setup.lhs file. If you grab the cabal source, there's an example in the tests directory called withHooks that might help. That, and looking at the cabal source itself :) (thanks to the nicely structured cabal libraries :). :) Another question: Is there a proposal how to (better) support test executables for a library package? (I remember that this topic has been discussed but can't remember any conclusion). With the latest (darcs / cvs) version of Cabal, you can add a UserHook for running tests, then there's a target ./setup test that'll execute that hook. We put the hook in Cabal 1.0, but forgot to add the command, so nothing calls it. Feel free to add the test hook so that people using newer versions of cabal can run your tests :) peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] haddock -cpp ? Cabal support for haddock ?
(CC'ing libraries) (snip) I'd certainly welcome Cabal support for other haddock features as well (--source, --read-interface). I am not sure where to put all these arguments in the .cabal file. Cabal doesn't support these yet, though. Maybe in the future. Dear Isaac, for the next release, I think *every* external program used by Cabal should get a xyz-options (free form) tag to give additional options. We already have them for linker, c-compiler, and hs-compiler, but not yet for preprocessors and doc generators (haddock). This is very easy to implement, does no harm at all, and greatly increases cabal's flexibility as a build tool. (BTW, I can send you a darcs patch if you are too busy at the moment.) And in the other thread you said: I made the necessary changes for hsc2hs-options in a few minutes You added hsc2hs-options to the package description? Cool. I'm happy to get a patch to add options fields to all the preprocessors and haddock and anything else we may have missed. There are basically 3 ways that people can customize their packages: - the .cabal file - the Setup script with UserHooks - flags to configure I was originally thinking of these extra flags as something to pass to configure, but actually putting them in the description file would be more consistent with what we have already... One trick, though, is to make sure that the parser test cases for cabal still run when you make the changes. It's all too common for someone to add a field and break the parser or pretty printer. The important thing is that when you parse it, pretty print it, and parse it again it comes out the same. Check out tests/ModuleTest.hs (BTW, I can send you a darcs patch if you are too busy at the moment.) I like patches whether I'm busy or not. It'll definitely get done faster ;) BTW, I'm tracking this feature request in the Debian bug tracking system for the haskell-cabal package. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
hi-boot and dependencies bug?
Greetings.
I haven't tested this with ghc 6.4 yet, and I don't know if this is a
known problem. I noticed this while building support for cabal.
I have two mutually recursive modules, prepared as described in the
GHC 6.2 user's manual: A and B
I create A.hi-boot
in B, in import {-source-} A
This works fine. But now I create C, which imports B (not A). When I
compile with --make, A does not get built, and I get a link-time
error.
However, if C imports A directly, it builds everything just fine.
I've attached a tarball with the example. Test it like this:
% ghc --make C.hs
Chasing modules from: C.hs
Compiling B( ./B.hs, ./B.o )
Compiling Main ( C.hs, C.o )
Linking ...
./B.o(.text+0x1b): In function `__stginit_B_':
: undefined reference to `__stginit_A_'
collect2: ld returned 1 exit status
peace,
isaac
p.s. please CC me on replies; i'm not subscribed to this mailing list
recursive.tgz
Description: GNU Unix tar archive
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A few questions on using Cabal
Niklas Broberg [EMAIL PROTECTED] writes: I've just started experimenting with the new Cabal system, and I must say it's really sweet. Thanks a lot to all involved! Yay! After trying it on some simple tasks I have collected a few questions: * What about 'setup uninstall'? Surely there should be an automatic way of uninstalling packages and executables? We'd like to do this eventually, but it doesn't work yet. A lot of people are using cabal as a layer under the OS package system (like in Debian) so the package manager handles removing the package itself. * Is there some way to direct the installation of a package to an auxiliary package-conf file, i.e. separate from the 'global' and 'user' package databases? E.g. 'runhaskell Setup.hs register --package-conf=foo.conf' (doesn't work) No way to do this yet either... patches welcome :) That should be a pretty easy thing to add; a half hour for someone who knows how the command-line parser works. * Is there some way to bundle several packages into a single installation unit? Similar to how you can specify several executables, or executables and a library package, I would want a way to say that a bundle will install several (possibly interrelated) packages at the same time. Nope. This is also on the todo list, but we're not sure how it'll look yet. We were calling such things shipments to distinguish them from packages. We wanted to get basic packages working first, and the next goal is to get the package database (Hackage) online. That's proceeding nicely, thanks to Lemmih. * If I specify a library package and an executable in the same cabal bundle, where the executable uses the library, the files that make up the library get compiled twice. Once when setting up the package, and then again when compiling the executable. How come? Beacuse this is a bit of a workaround. Don't complain too much or I think Ross will kick me. The right way to do this is probably with shipments. That's all for now, possibly more to come later. =) So the short answer is that there are still some things that make cabal less convinient than it could be, but we've got them in mind, and we're happy to accept patches to add them! peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Cabal 0.5 (GHC 6.4 release candidate)
This is a release-candidate for 0.6, which will be in GHC 6.4. http://www.haskell.org/cabal/download.html The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal IMPORTANT INFORMATION: See both the README file and the changelog for important interface changes. DOWNLOAD: The Haskell Cabal has reached pre-release stage. The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items to [EMAIL PROTECTED] and Isaac Jones: [EMAIL PROTECTED] ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: You cannot currently execute the setup scripts with ./Setup.lhs since Cabal Hugs support isn't ready-for-prime-time. You can compile it with ghc thusly: ghc -package Cabal Setup.lhs -o setup and then use the setup executable after that. This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: new Haskell hacker seeking peer review
John Goerzen [EMAIL PROTECTED] writes: Here's an alternative: module Main where (snip john's version) And what list would be complete without a points-free version. It doesn't operate on stdin, though like John's does: pointsFreeCat :: IO () pointsFreeCat = getArgs = mapM readFile = putStrLn . concat -- And a regular version for reference cat2 :: IO () cat2 = do a - getArgs lines - mapM readFile a putStrLn $ concat lines peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parse error in a package file
Dmitri Pissarenko [EMAIL PROTECTED] writes: Hello! I'm building the haskell-jvm-bridge (http://sourceforge.net/projects/jvm- bridge/). The final step of the building procedure is to install the package of haskell- jvm-bridge. When I enter ghc-pkg -a -f javavm.ghc-pkg I'm getting the error javavm.ghc-pkg: parse error in package config file (snip) Please tell me what's wrong with this package file. Looks like there are a bunch of mis-placed -Ls in the file. Maybe they need to be quoted? peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: library documentation
Peter Simons [EMAIL PROTECTED] writes: Isaac Jones writes: http://www.haskell.org/hawiki/LibraryDocsNeedingHelp This is a great idea. I have been thinking you know what would make contribution to the library efforts even simpler? If they were available in a Darcs repository. I can certainly understand Simon's wish to stay away from a split repository, one for GHC, one for libraries. What I'm doing for the cabal is keeping the _darcs directory in the same place as the CVS directory, and keeping them in sync by hand. This isn't too painful, if it were, I think there are some tools out there for this. Someone else suggested that someone maintain a darcs repository for the libraries and pull in documentatin changes, and then sync it all at once. I think that's a bad idea, because merging is never very easy, and is error prone. What might be good is if someone with CVS access would keep a darcs mirror of all of fptools (or just the libraries), and keep the darcs side automatically in sync w/ the CVS side (there are some tools for this). Then people could send darcs patches to this poor soul who would be sure to review them before committing them to CVS. I doubt that there would be too much traffic to handle, and if there were, then we could possibly put different people in charge of different components. Eventually, of course, everyone will realize that life would be simpler if we got rid of CVS altogether, and darcs will be mature enough to handle GHC, and we'll switch :) Saying darcs push after you've spontaneously added a ^ Probably darcs send if we're talking about letting the masses add documentation. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File path programme
Mark Carroll [EMAIL PROTECTED] writes: On Tue, 25 Jan 2005, Marcin 'Qrczak' Kowalczyk wrote: (snip) If problems are in the implementation but the interface is right, then the module should be provided. It can be fixed later. (snip) A lot of the Haskell libraries are sufficiently poorly documented that I work out what they do by experiment, or by resorting to reading the source. There should be a wiki page or some other list for libraries that need documentation to be added to them. I would be happy to add documentation here there. Anyone want to volunteer to create the page and list some libraries there? peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File path programme
You might be interested in the new FilePath module that's in the works. There's been a lot of work to make these functions portable. http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANN: Cabal 0.4
The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal IMPORTANT INFORMATION: See both the README file and the changelog for important interface changes. DOWNLOAD: The Haskell Cabal has reached pre-release stage, with a 0.4 version The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items to [EMAIL PROTECTED] and Isaac Jones: [EMAIL PROTECTED] ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: You cannot currently execute the setup scripts with ./Setup.lhs since Cabal Hugs support isn't ready-for-prime-time. You can compile it with ghc thusly: ghc -package Cabal Setup.lhs -o setup and then use the setup executable after that. This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/ -*-change-log-*- 0.4 Isaac Jones [EMAIL PROTECTED] Sun Jan 16 2005 * Much thanks to all the awesome fptools hackers who have been working hard to build the Haskell Cabal! * Interface Changes: ** WARNING: this is a pre-release and the interfaces are still likely to change until we reach a 1.0 release. ** Instead of Package.description, you should name your description files something.cabal. In particular, we suggest that you name it packagename.cabal, but this is not enforced (yet). Multiple .cabal files in the same directory is an error, at least for now. ** ./setup install --install-prefix is gone. Use ./setup copy --copy-prefix instead. ** The Modules field is gone. Use hidden-modules, exposed-modules, and executable-modules. ** Build-depends is now a package-only field, and can't go into executable stanzas. Build-depends is a package-to-package relationship. ** Some new fields. Use the Source. * New Features ** Cabal is now included as a package in the CVS version of fptools. That means it'll be released as -package Cabal in future versions of the compilers, and if you are a bleeding-edge user, you can grab it from the CVS repository with the compilers. ** Hugs compatibility and NHC98 compatibility should both be improved. ** Hooks Interface / Autoconf compatibility: Most of the hooks interface is hidden for now, because it's not finalized. I have exposed only defaultMainWithHooks and defaultUserHooks. This allows you to use a ./configure script to preprocess foo.buildinfo, which gets merged with foo.cabal. In future releases, we'll expose UserHooks, but we're definitely going to change the interface to those. The interface to the two functions I've exposed should stay the same, though. ** ./setup haddock is a baby feature which pre-processes the source code with hscpp and runs haddock on it. This is brand new and hardly tested, so you get to knock it around and see what you think. ** Some commands now actually implement verbosity. ** The preprocessors have been tested a bit more, and seem to work OK. Please give feedback if you use these. 0.3 Isaac Jones [EMAIL PROTECTED] Sun Jan 16 2005 * Unstable snapshot release * From now on, stable releases are even. 0.2 Isaac Jones [EMAIL PROTECTED] * Adds more HUGS support
Re: [Haskell] signature of when, unless
Frederik Eaton [EMAIL PROTECTED] writes: Wouldn't it be more useful if the type was when :: Monad m = Bool - m a - m () not when :: Monad m = Bool - m () - m () Seconded. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Books on Haskell
Dmitri Pissarenko [EMAIL PROTECTED] writes: What book can you recommend? shamelessPlugI reviewed The Haskell School of Expression on Slashdot a few months ago./shamelessPlug: http://books.slashdot.org/article.pl?sid=04/03/12/221232 peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unit testing in Haskell
Matthew Roberts [EMAIL PROTECTED] writes: I find that I don't need unit testing frameworks. A few features of Haskell and the associated interpreters (ghci and hugs) combine to make unit testing as you go really easy. I just write a few tests for each function I write and then some more module wide tests once the whole module is finished. Sometimes I need a little scaffolding to be able to output complex data types (or type synonyms), but often just deriving Show does the job! It seems to me that if you're going to take the time to craft some ad-hoc tests in the interpreter, you might as well take an extra few seconds to put them into HUnit tests so you can make sure they still pass later. This gives you more confidence while you are refactoring your code. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] more haskell in the news (for nerds)
(please followup-to haskell-cafe) This slashdot story mentions Haskell being used to solve puzzles: http://developers.slashdot.org/developers/04/12/04/0116231.shtml?tid=159tid=156 I did a quick search on slashdot to discover that Haskell has been in the topic of a slashdot story 4 times in the last 10 months (since march 2003). 5 times if you count a review of Purely Functional Data Structures. In the year before that, it was mentioned only once in passing. In 2001, it was the topic once, and mentioned once in passing. In 2000 there were several stories on functional programming that mentioned Haskell. Any way you look at it, Haskell has gotten a lot more attention on Slashdot lately than it has since the beginning of the archives. Here's a link to the stories: http://slashdot.org/search.pl?tid=query=haskellauthor=sort=1op=stories peace, isaac ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] more haskell in the news (for nerds)
(please followup-to haskell-cafe) This slashdot story mentions Haskell being used to solve puzzles: http://developers.slashdot.org/developers/04/12/04/0116231.shtml?tid=159tid=156 I did a quick search on slashdot to discover that Haskell has been in the topic of a slashdot story 4 times in the last 10 months (since march 2003). 5 times if you count a review of Purely Functional Data Structures. In the year before that, it was mentioned only once in passing. In 2001, it was the topic once, and mentioned once in passing. In 2000 there were several stories on functional programming that mentioned Haskell. Any way you look at it, Haskell has gotten a lot more attention on Slashdot lately than it has since the beginning of the archives. Here's a link to the stories: http://slashdot.org/search.pl?tid=query=haskellauthor=sort=1op=stories peace, isaac ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: proposal for ghc-pkg to use a directory of .conf files
Simon Marlow [EMAIL PROTECTED] writes: (snip) There's another thing that bothers me though: when you install a package using hc-pkg, a number of checks are made: 1. there isn't already a package with that name/version 2. If the package is to be exposed, then the modules provided by the package don't overlap with another exposed package. 3. if an older version of the package is already exposed, then the older one is supposed to be hidden in favour of the new one Since with the proposed change hc-pkg isn't running on the target system, it can't make any of these tests. GHC can detect at run-time that you have overlapping packages, but then it might not be possible to make changes to the package database (you might need to 'su' in order to do it). The systems that would want to do this kind of thing, such as Debian, have other mechanisms for deciding whether packages conflict, etc. Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque interface to the packaging system. What are the advantages to this? I'm going to write up a proposal about cabal interface changes, which is somewhat related, but also neutral to this. The only question to cabal proper is whether or not 'register' is guaranteed to run on the target. The rest of the LIP does indeed care about this, IMO, so we do need to decide. peace, isaac ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: proposal for ghc-pkg to use a directory of .conf files
Simon Marlow [EMAIL PROTECTED] writes: On 08 November 2004 18:47, Duncan Coutts wrote: We can use ghc-pkg at the build / install-into-temp phase to create the $(package).conf files under $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final installation is jsut merging files without any post-install calls to ghc-pkg to modify installed files (ie the global ghc package.conf file) So we can still keep the abstraction of $HC-pkg and gain simpler packaging stuff. Ok, sounds reasonable. I'm going to be working on the package support in ghc and ghc-pkg to improve support for Cabal, so let's do this at the same time. As a Debian packager, I like the idea of changing the way HC-PKG handles individual packages. The question in my mind is whether we want to execute any code on the install target. Previously, I have thought of ./setup register as being a step that happens on the target, no matter what. So if Marcus Makefile wants to do something specifically for the target at install time, this is where he could do it. If we go this route and have the package registration happen at install-in-temp time, then we don't have any standard way to run a post-install script. Some people may prefer that we never execute anything from Cabal on the target, but I would prefer to leave that ability. One solution would be to move the registration step into install-into-temp time, as above, but to add another standard command to Cabal like ./setup postinstall and maybe some others preinst, prerm, postrm as in Debian. This would solve both problems; haskell packages installed with a packaging system like Debian would usually just be moving files into place, but if Marcus or Angela really needed to run something on the target, this is how they'd do it. Thoughts? peace, isaac ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] 500 great lines of Haskell code?
This might be an interesting way to highlight the beauty and brevity of Haskell. Has anyone written a great 500-line Haskell program they want to submit? peace, isaac http://developers.slashdot.org/article.pl?sid=04/10/06/1530218tid=156tid=8 Be part of the Open Source Annual 2005 and enter our hacker contest for the best 500-line open source program. The best program will be printed in next year's issue of the book. Following lasts year's huge success with our Open Source Annual, a mostly German reader concerned with the various aspects of open source, we are currently busy compiling the second edition of the annual which will be released next March for the CeBIT 2005 in Hannover. Aside from articles on subjects like economics, law and open innovation, to name but a few, we plan to print the source code of an open source software program. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Announce: Cabal 0.1 (Library Infrastructure Project)
Much thanks to all who've made this possible :) The Haskell Cabal The Common Architecture for Building Applications and Libraries. DOWNLOAD: The Haskell Cabal has reached pre-release stage, with a 0.1 version The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here: http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items here: http://sourceforge.net/tracker/?func=addgroup_id=44807atid=440922 Or email Isaac Jones: [EMAIL PROTECTED] ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] new Library Infrastructure spec.
(followups to [EMAIL PROTECTED]) Hail Haskellers! A commonly-identified obstacle to the spread of Haskell libraries is that there is no standard way a) for authors to package a library or other tool for distribution to others b) for customers to install such a package Platforms vary. Haskell compilers vary. Packages have dependencies. Etc. Isaac Jones has coordinated an effort to address this problem. We've had a lot of discussion between him and (at least some of) the folk involved in the GHC, Hugs, and nhc implementations. This discussion has led to a new concrete proposed specification[1]. Here it is: http://www.haskell.org/libraryInfrastructure/proposal See also the project home page: http://www.haskell.org/libraryInfrastructure/ We would welcome your feedback, either as a potential library or tool author, or as a potential consumer, or both. The specification isn't complete in every detail, but it seems better to post it before investing in details that may be rendered void by subsequent discussion. We hope this will be an important spec, and will be with us for a long time. So now's the time to look at it. Send feedback to [EMAIL PROTECTED] (You can subscribe to this list at: http://www.haskell.org/mailman/listinfo/libraries .) Sincerely, Isaac Jones, Simon Marlow, Ross Paterson, Malcolm Wallace, Simon Peyton Jones [1] This specification differs from the previous proposal both in technical details, and in that it is the combined efforts of the undersigned. Those familiar with the previous proposal will not find large high-level differences, but some details have been made more concrete and some details have changed. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] new Library Infrastructure spec.
(followups to [EMAIL PROTECTED]) Hail Haskellers! A commonly-identified obstacle to the spread of Haskell libraries is that there is no standard way a) for authors to package a library or other tool for distribution to others b) for customers to install such a package Platforms vary. Haskell compilers vary. Packages have dependencies. Etc. Isaac Jones has coordinated an effort to address this problem. We've had a lot of discussion between him and (at least some of) the folk involved in the GHC, Hugs, and nhc implementations. This discussion has led to a new concrete proposed specification[1]. Here it is: http://www.haskell.org/libraryInfrastructure/proposal See also the project home page: http://www.haskell.org/libraryInfrastructure/ We would welcome your feedback, either as a potential library or tool author, or as a potential consumer, or both. The specification isn't complete in every detail, but it seems better to post it before investing in details that may be rendered void by subsequent discussion. We hope this will be an important spec, and will be with us for a long time. So now's the time to look at it. Send feedback to [EMAIL PROTECTED] (You can subscribe to this list at: http://www.haskell.org/mailman/listinfo/libraries .) Sincerely, Isaac Jones, Simon Marlow, Ross Paterson, Malcolm Wallace, Simon Peyton Jones [1] This specification differs from the previous proposal both in technical details, and in that it is the combined efforts of the undersigned. Those familiar with the previous proposal will not find large high-level differences, but some details have been made more concrete and some details have changed. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
panic in arrow code foo = returnA - []
The following malformed code causes a panic in ghc 6.2, and some folks
on IRC tried it in various CVS snapshots, where it also breaks.
module Main where
import Control.Arrow
foo = returnA - []
---
ghc -farrows Test.hs
ghc-6.2: panic! (the `impossible' happened, GHC version 6.2):
tcMonoExpr
ControlziArrow.returnA {- v r4a -} - GHCziBase.ZMZN {- d 6m -}
peace,
isaac
--
Isaac Jones [EMAIL PROTECTED]
Aetion
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: panic in arrow code foo = returnA - []
On Fri, 2004-03-12 at 13:47, Ross Paterson wrote: On Fri, Mar 12, 2004 at 01:30:58PM -0500, Isaac Jones wrote: The following malformed code causes a panic in ghc 6.2, and some folks on IRC tried it in various CVS snapshots, where it also breaks. module Main where import Control.Arrow foo = returnA - [] It's not legal to use - except inside proc, so the bug is that this isn't being rejected. Will check. In my own defense, I did say malformed code :) peace, isaac ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
