Re: [Haskell-cafe] Best idiom for avoiding Defaulting warnings with ghc -Wall -Werror ??
I've been going over my code trying to get it all to compile with ghc -Wall -Werror I recently ran across what may be a good reason not to use -Wall in combination with -Werror (and similar combinations in other compilers), at least not as the standard build switches for software you intend to distribute. It causes bitrot, because -Wall will in the future turn on warnings that don't even exist yet today, and -Werror will turn those warnings into errors. The upshot is that you can write code that entirely follows the standard that defines whatever language you're using (e.g. Haskell 98), and still have it break in the future, even if future compilers adhere to the standard. If you are serious about writing portable and durable code, you may want to avoid this. (I ran into this problem while trying to resurrect an excellent but unmaintained compiler written in lots of OCaml and a little C. Both ocaml and gcc have grown many new warnings in the last few years.) -- /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] csv library
This is an announcement of something so tiny (about 100 lines of code including comments), I'd feel bad posting it to the haskell list, so it'll go on haskell-cafe. This was pretty much just a project for me to learn cabal and hackage, but it may very well actually come in useful some day. csv 0.1.0 CSV loader and dumper This library parses and dumps documents that are formatted according to RFC 4180, The common Format and MIME Type for Comma-Separated Values (CSV) Files. This format is used, among many other things, as a lingua franca for spreadsheets and for certain web services. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/csv-0.1.0 -- /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Yi (and wider Cabal stuff)
On Sunday 17 June 2007 08:26:45 Michael T. Richter wrote: I'm trying to build Yi (from the darcs repository) to take a look at it. The README that comes with it says it's a standard Cabal project so do what you normally do (paraphrased slightly). GNU autotools comes with a standard boilerplate INSTALL file to include with your projects. There is some command you run in the process of autoconfiscation that inserts it automatically. Maybe there should be a standard boilerplate INSTALL file to be included with Cabal packages. Yesterday, I wrote and uploaded a simple Cabal package called csv (mostly as an exercise, since it's only a screenful of code, really, but it is actually a somewhat useful library because it saves you the trouble of reading an RFC). I included the following INSTALL file: To install the package, use the standard Cabal incantations: runhaskell Setup.hs configure runhaskell Setup.hs build runhaskell Setup.hs install If you want to install into a nonstandard directory, do runhaskell Setup.hs configure --prefix /bla/di/bla If you want documentation, try runhaskell Setup.hs haddock I think that simply adding those instructions would probably lower the hurdle a bit. Maybe the Cabal could look into automatically inserting an instructions file like that if it doesn't exist yet. Another idea for making things more accessible is to include a shell script called configure and a Makefile called Makefile, both of which just print the above instructions when executed. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
Well, since we're on the subject and it's only the Cafe list, what is it that you find messy about Linux that you would want to be solved by some hypothetical Haskell OS? The hypothetical Haskell OS, especially if it were targeted toward 64 bit machines, could keep processes from messing with each other by way of language based security, and run them all in a single memory space. (The first system to do this, I believe, was the MULTIPOP timesharing system, but there are other precedents, too.) This would eliminate or simplify lots of context switches and buffer copies and memory management and other nastiness that now goes into kernels. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
Normally I've seen capabilities used so that you can't access anything you can't name. Can you elaborate a little? He's saying that the language itself prevents programs from writing outside their address spaces Yep. Capabilities are usually not actually unforgeable, they are just picked from a largish key space. You can guess at them if you want to bother. Somewhere in the Exokernel papers, there is some discussion of this, and reference to the fact that a 64 bit capability is at least as secure as an 8 byte UNIX password, which I suppose is a fair assessment of the situation. With language based security, you can have unforgeable capabilities, though. An example of a system based on that idea, although expressed in different words, is http://mumble.net/~jar/pubs/secureos/secureos.html An alternative approach to unforgeable capabilities is to build them into the hardware using a tagged architecture. There is a paper by Tom Knight (mastermind of the original Lisp Machine) and Jeremy Brown that is relevant here, although it actually deals with the somewhat different problem of data dissemination control (think DRM but more for military applications and suchlike): http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-15.pdf Note that earlier tagged architectures, including the Knight Machine and the K-machine, used tags mostly to speed up Lisp and not to enforce any sort of type discipline. Which is a nice theory, but is dependent on the runtime not being buggy (I think some problems have been demonstrated with large arrays in GHC...). There are three ways to deal with this. The first is the aforementioned tagged architecture in hardware. The second is running everything within a virtual machine that has a tagged architecture. In both of these cases, there would be a trusted security kernel, but you could make it pretty damn small. Unfortunately hardware is expensive and virtual machines are slow (although people keep claiming that they're getting better, and FPGAs are getting faster and cheaper all the time). The third way is to have a compiler that compiles Haskell, or any other typesafe language, into a typed assembly language with a sufficiently expressive type system. You can then feed TAL-annotated binaries to the (trusted) loader. This way, you can also support multiple programming languages while still maintaining language based security and a small trusted security kernel, viz. the TAL type checker. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS design FP aesthetics
Every capability system I've seen works like Unix file descriptors. The kernel assigns capability numbers, and since the numbers are only valid in one process, and the only valid capability numbers are to capabilities your have, there is no danger caused by guessing. You know, when I typed that, I knew I really ought to qualify it a bit, because the word capability is used in several ways. You are, of course, right to say that this is a common implementation of capabilities in operating systems with multiple memory spaces, but it does not work in a single memory space design without language security where user processes can access the kernel tables. /jaap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
