[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
[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-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
[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
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
[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
[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-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: [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-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-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-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
[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-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
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-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
[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-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
LIP and the AAP project
Greetings, Now that I have at least gotten something started on the Library Infrastructure Project, I'm going to bend some of my energy toward the build/install issues for Haskell modules. The plan at this point, which is summarized on the project web site[1] is to attempt to leverage HMake's usefulness as a non-compiler-specific build system. Since I wrote the proposal, I've been made aware of the AAP project[2]. Does anyone have any experience with this? Does anyone have a sense for how it might fit in with LIP? I know that Peter Simons seems to think it might. I haven't read through all of the documentation, but I suspect it might help us out with the CPAN-style distribution stuff, and perhaps the building stuff. One big objection I have with using it would be that Haskell modules would depend on Python (!), but I thought I'd let everyone know about it anyway. Seems like an interesting project, and we could quite possibly learn something from it. peace, isaac [1] http://www.haskell.org/libraryInfrastructure/ [2] http://www.a-a-p.org/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: replacing guile with haskell?
David Roundy [EMAIL PROTECTED] writes: Do you want to embed Haskell code or to embed a Haskell interpreter? I actually would like to embed a Haskell interpreter. (snip) H. I may be able to get by without calling haskell functions from C. Most of the work would be done in C, and haskell would just be the glue language to let the user flexibly specify what he/she wants done. I've always wanted to see some way to do embed Haskell in an application the way you can for Guile. This would be great for Embedded Domain-Specific languages :) Is that what you've got here? peace, isaac ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
chance to help out on the wiki
Greetings. We added a page Fundamental Concepts to the wiki so that we might have a very specific reference to pass along to people with questions, and to add links to definitions throughout the wiki. http://www.haskell.org/hawiki/FundamentalConcepts A lot of concepts need to be filled in, and if you haven't participated in the Wiki yet, now is a good time :) If you've never used a wiki, you can read about it here: http://www.haskell.org/hawiki/HelpForBeginners You might model your explanations after a page I wrote for PatternMatching which has: - a reference to a tutorial - a reference to the haskell report - an explanation - some examples Feel free to extend and / or correct anything already there. The front page of the wiki is here: http://www.haskell.org/hawiki/FrontPage peace, isaac ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
SOE exercise
(I'm not sure why my postings seem somewhat anonymous, I'll mess with the headers in this post to see if that fixes it. I post to other mailman lists and haven't noticed this problem.) I'm working through Paul Hudak's SOE, and have a question about problem 9.4, which is to define a function applyEach. I've come up with several versions, but not one which usefully uses currying (the exercise doesn't explicitly say to use currying, but that's the only thing in this section). My real question is whether I should be trying to apply currying here. Solutions are welcome, but I can think of several good reasons not to post solutions to this forum. The behavior of applyEach should be obvious from my attempts below. Output: applyEach [(+1), (+3), (+2)] 1 = [2,4,3] :: [Integer] Recursive version: applyEach :: [a-b] - a - [b] applyEach [] _ = [] applyEach (h:t) x = (h x) : (applyEach t x) Now with higher order functions: applyEach' :: [a-b] - a - [b] applyEach' funs x = map applyx funs where applyx (fun) = fun x With Lambda: applyEach'' :: [a-b] - a - [b] applyEach'' funs x = map (\fun- fun x) funs With Currying: ? peace, isaac P.S. I'm enjoying this book a great deal :-) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe