- Haskell - Haskell.org

a dream of databases
by John Meacham 13 Jun '03

13 Jun '03

so, I have been wanting to implement serialize to database functionality for haskell in a certain way which may or may not be possible.. what would be nice is if I could dump an entire complex haskell data structure (perhaps cyclic, but not infinite) to a hash-table database (like berkeley db). pointers would be swizzled into hash keys and each haskell thunk would become an entry in the database. loading the database would return the haskell structure just as it was put into the database but it would be demand loaded. meaning that evaluating a data thunk will actually grab that entry out of the database (like with lazy file reading) and entries that have not been accessed in a while would be transparently reclaimed by the garbage collector (and reloaded later if needed) And of course, these haskell data structures should be albe to be arbitrary and would look no different from other haskell data structures. they would just have appropriate instances derived for them by DrIFT (or perhaps template haskell). now. I am pretty sure I can do the demand loading bit with some goddawful code (inspired by HOODs internals) using unsafePerformIO and Weak pointers in truly nefarious ways. The dumping to the database bit is straightforward when working with trees. but I can't figure out a way to do it for potentially complex datastructures. perhaps someone out there has an idea? perhaps some template haskell tricks can be pulled to make it happen? I realize that any solution will be quite hacky and unlikely to be very portable. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

3 2

Re: what dreams may come ...
by Jon Awbrey 13 Jun '03

13 Jun '03

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o john, with no particular reference to haskell, but just generically speaking, this sounds vaguely similar to what i worked on all through the 80's in lisp and pascal, when ut-lisp used to pull a hal 9k about cyclic d-structures so i had to start redoing everything from scratch on my own recognizance in turbo pascal, no really. vide my recent, very slow attempts to document this work at my inquiry list: http://stderr.org/pipermail/inquiry/ http://stderr.org/cgi-bin/mailman/listinfo/inquiry here are the anchors of some pertinent threads: http://stderr.org/pipermail/inquiry/2003-March/000100.html -- exposition http://stderr.org/pipermail/inquiry/2003-March/000115.html -- source code http://stderr.org/pipermail/inquiry/2003-March/000120.html -- commentary http://stderr.org/pipermail/inquiry/2003-March/000141.html -- motivation it may be another year or so before i can finish (or even get back to) the te deums of documentality, but if anybody is remotely tantalized i will do my level best to explain what's going on there. jon awbrey o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o > Message: 10 > Date: Thu, 12 Jun 2003 19:02:55 -0700 > From: John Meacham <john(a)repetae.net> > Subject: a dream of databases > To: haskell(a)haskell.org > > so, I have been wanting to implement serialize to database functionality > for haskell in a certain way which may or may not be possible.. > > > what would be nice is if I could dump an entire complex haskell data > structure (perhaps cyclic, but not infinite) to a hash-table database > (like berkeley db). pointers would be swizzled into hash keys and each > haskell thunk would become an entry in the database. > > loading the database would return the haskell structure just as it was > put into the database but it would be demand loaded. meaning that > evaluating a data thunk will actually grab that entry out of the > database (like with lazy file reading) and entries that have not been > accessed in a while would be transparently reclaimed by the garbage > collector (and reloaded later if needed) > > And of course, these haskell data structures should be albe to be > arbitrary and would look no different from other haskell data > structures. they would just have appropriate instances derived for them > by DrIFT (or perhaps template haskell). > > now. I am pretty sure I can do the demand loading bit with some > goddawful code (inspired by HOODs internals) using unsafePerformIO and > Weak pointers in truly nefarious ways. The dumping to the database bit > is straightforward when working with trees. but I can't figure out a way > to do it for potentially complex datastructures. perhaps someone out > there has an idea? perhaps some template haskell tricks can be pulled to > make it happen? I realize that any solution will be quite hacky and > unlikely to be very portable. > > John > > --------------------------------------------------------------------------- > John Meacham - California Institute of Technology, Alum. - john(a)foo.net > --------------------------------------------------------------------------- o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o

1 0

ANNOUNCE: GHC version 6.0
by Simon Marlow 13 Jun '03

13 Jun '03

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 6.0 ============================================================ We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 6.0. As with all ".0" releases, this release should be considered beta-quality; if you want real stability, then stick with 5.04.3 for the time being. Highlights of this release include: * Template Haskell, a new metaprogramming extension. * More hierarchical libraries. * Conformance with the latest FFI specification. * Sweeping internal changes to switch the evaluation model from "push/enter" to "eval/apply". See the release notes for a full list of the changes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998, and revised in December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

5 7

RE: Problems with working with Handles (PS)
by Simon Marlow 13 Jun '03

13 Jun '03

> (moderator, can you please include this mail at the bottom of my > previous mail?) > > PS: I think the next example shows pretty well what goes wrong when > you're not closing the read-handle: > > ------- > test = do writeFile' "123.txt" "blaat" > > appendFile' "123.txt" " 1" > z <- readFile' "123.txt" > > appendFile' "123.txt" " 2" > s <- readFile' "123.txt" > appendFile' "123.txt" " 3" > t <- readFile' "123.txt" > putStr ("\n\n") > putStr (z ++ "\n" ++ s ++ "\n" ++ t) > > ------- > > Instead of "blaat 1 > blaat 1 2 > blaat 1 2 3" > > three lines of "blaat 1 2 3" are outputted. Note that on a conforming Haskell 98 system, the above program (with the primes deleted) will fail. For example, GHC responds: Fail: resource busy Action: openFile Reason: file is locked File: 123.txt This is because Haskell 98 specifies that the IO system should implement multiple-reader/single-writer locks on a per-file basis. Cheers, Simon

1 0

ADV: Haskell-related postdoc positions at Chalmers University
by John Hughes 13 Jun '03

13 Jun '03

Post-doctoral Fellowships at Chalmers University ================================================ We are seeking one or two postdoctoral research fellows to work at the Department of Computing Science on the CoVer project (COmbining VERification methods), a collaboration between the functional programming, formal methods, and programming logic groups. The goal of the project is to integrate testing and formal verification methods in a program development environment for Haskell programs. We have been awarded 8MSEK (about 870,000 euros) by the Swedish Foundation for Strategic Research to fund this work. The project leaders are John Hughes, Mary Sheeran, Peter Dybjer, and Thierry Coquand. We are looking for well qualified candidates with a recent doctorate in a related area, and with proven system building skills, to spend up to two years with us as Research Fellows. We are looking for candidates familiar with some or all of these areas: * functional programming, especially using Haskell * dependent types and logic * proof editors * automated theorem provers * program analysis and transformation Responsibilities will include system development in Haskell. Further information on the CoVer project is available at http://dilbert.cs.chalmers.se/Cover/ Successful applicants will receive a tax-free fellowship of around 16,000 SEK per month (about 1,750 euros), which is sufficient to live comfortably in Göteborg. Swedish tax law restricts these fellowships to people coming from abroad: those presently working in Sweden are not eligible. Start date is negotiable from 1 September to 1 January 2004. Gothenburg is an attractive city on the Swedish west coast, offering an excellent quality of life. It has all the cultural amenities you would expect of Sweden's second city, and the easy access to unspoiled nature of a country with less than 10% the population density of the UK! A good starting point for information on the city is http://www.goteborg.com/default.asp?id=4293 Candidates are welcome to contact any of the Principal Investigators with questions. Please email an application letter, together with your CV and a copy of *one* relevant publication to cover(a)cs.chalmers.se, by Sunday June 29th at the latest. Your application letter should specifically address your system building skills as well as your research experience. Attached documents should be Postscript or PDF. John Hughes rjmh(a)cs.chalmers.se Mary Sheeran ms(a)cs.chalmers.se Peter Dybjer peterd(a)cs.chalmers.se Thierry Coquand coquand(a)cs.chalmers.se

1 0

Re: Typesafe MRef with a regular monad
by cwitty＠newtonlabs.com 13 Jun '03

13 Jun '03

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > | Conjecture: It's impossible to implement RefMonad directly in Haskell > | without making use of built-in ST or IO functionality and without > unsafe or > | potentially diverging code (such as unsafeCoerce). > > A more concrete way to formulate a problem that I believe to be > equivalent is this. Implement the following interface > > module TypedFM where > data FM k -- Abstract; finite map indexed by keys > of type k > data Key k a -- Abstract; a key of type k, indexing a > value of type a > > empty :: FM k > insert :: Ord k => FM k -> k -> a -> (FM k, Key k a) > lookup :: Ord k => FM k -> Key k a -> Maybe a > > The point is that the keys are typed, like Refs are. But the finite map > FM is only parameterised on k, not a, so it can contain (key,value) > pairs of many different types. > > I don't think this can be implemented in Haskell, even with > existentials. But the interface above is completely well typed, and can > be used to implement lots of things. What I *don't* like about it is > that it embodies the finite-map implementation, and there are too many > different kinds of finite maps. > > There is, I guess, some nice language extension that would enable one to > program TypedFM, rather than provide it as primitive; but I don't know > what it is. Here's a hand-waving argument that you need either Typeable (or something else that has a run-time concrete representation of types) or ST/STRef (or something else, probably monadic, that can track unique objects) to do this. (Warning: there may be Haskell syntax errors in the following; I haven't written Haskell for a while.) Consider the following: let (m, _) = insert empty "key" "val" (_, k1) = insert empty "key" 'V' (_, k2) = insert empty "key" "val" in (lookup m k1, lookup m k2) This gives a value of type (Maybe Char, Maybe String); I think the intended semantics are that the value should be (Nothing, Just "val"). (Maybe the first lookup should throw an exception instead of returning Nothing? Surely it should not return (Just 'V') or (Just ((unsafeCoerce# 'V') :: String)). (The second lookup must return (Just "val"); otherwise, you're breaking referential transparency.) Now, imagine what the map looks like in memory. Suppose it is just a standard association list. The key cannot be just the string "key", or the pair ("key",1) (where 1 means it's the first thing inserted into the map); it must somehow depend on the type of the value. Hence, you need to use Typeable or some other run-time representation of types. The above argument convinces me that you need run-time types to program TypedFM. The problem in the above example is that you can create a key in one map and attempt to use it in another map. If you could prohibit such an attempt (or even detect it), then you wouldn't need Typeable. But what does it mean to use a key in "the same map"? In let (m1, k) = insert empty "key" "val" (m2, _) = insert m1 "key2" "val2" in lookup m2 k you must allow the lookup of k in m2, even though m1 and m2 are different maps (one has a key "key2" and the other doesn't). Somehow, a key must be usable with the map it was created in, and with "descendents" of that map, but not with siblings of that map. In an impure language, this could be done with some sort of tag on the map, but I don't see how to do so in a pure language. Following the above chain of reasoning, we could create an version of TypedFM that was based in the IO monad. There would be a global variable that you could use to dole out TypedFM tags; each map that you created (in the IO monad, of course) would have a unique tag, and keys of a map would have the same tag. You could only use the maps in a single-threaded fashion (i.e., within the IO monad); otherwise there would be "sibling" maps and we would be back to needing Typeable. We could try to associate keys with their maps in some other way. For instance, we could use the "ST" approach, and give keys and their maps a dummy type parameter that would have to match. Even then, we would need something monad-like to single-thread the maps. To summarize, I believe that you need either a run-time representation of types (like Typeable) or some way to single-thread access to your map objects (like the ST monad) to implement something like TypedFM. We've seen an implementation using Typeable/Dynamic. An implementation in the ST monad might be more difficult, depending on the intended semantics of TypedFM (what's supposed to happen if you insert the same key with values of different types?); but for my imagined uses of TypedFM, you could just use the ST monad with STRef's directly. If Typeable is necessary (and Dynamic is sufficient), or the ST monad is necessary (and the ST monad is sufficient), then that doesn't leave a lot of room for nice new language extensions (unless somebody can come up with some way to single-thread objects that's even more clever than the ST monad). Carl Witty

3 2

Re: Problems with working with Handles (PS)
by Niels Reyngoud 13 Jun '03

13 Jun '03

(moderator, can you please include this mail at the bottom of my previous mail?) PS: I think the next example shows pretty well what goes wrong when you're not closing the read-handle: ------- test = do writeFile' "123.txt" "blaat" appendFile' "123.txt" " 1" z <- readFile' "123.txt" appendFile' "123.txt" " 2" s <- readFile' "123.txt" appendFile' "123.txt" " 3" t <- readFile' "123.txt" putStr ("\n\n") putStr (z ++ "\n" ++ s ++ "\n" ++ t) ------- Instead of "blaat 1 blaat 1 2 blaat 1 2 3" three lines of "blaat 1 2 3" are outputted. The strange thing is that using "putStr z", "putStr s", and "putStr t" after each call of readFile' solves the problem, but using seq (even though it's already called in the function readFile' in our module). before appending a new character to the file, like "seq z (appendFile "123.txt" "2") doesn't work. Best regards, Niels Reyngoud

1 0

IOError
by Filip 12 Jun '03

12 Jun '03

Hi, I wrote something like "let t = try (hGetLine h1)" and I would like to check is it EOFError or not. How can I do this ?? Thanks

3 3

RE: problems with working with Handles
by Markus.Schnell＠infineon.com 12 Jun '03

12 Jun '03

> main = do --let inputfile = "input.txt" > let inputtext = "testit" > let outputfile = "output.txt" > writeFile outputfile "" > handle2 <- openFileEx outputfile (BinaryMode WriteMode) > hPutStr handle2 (inputtext ++ " extra") > > handle3 <- openFileEx outputfile (BinaryMode ReadMode) > inputtext2 <- hGetContents handle3 > handle4 <- openFileEx outputfile (BinaryMode WriteMode) > hPutStr handle4 (inputtext ++ " extra2") Here's my guess: You open outputfile four times but never close it. Markus

1 0

ANN: H98 FFI Addendum 1.0, Release Candidate 11
by Manuel M T Chakravarty 12 Jun '03

12 Jun '03

Dear Haskell Folks, Release Candidate 11 of the H98 FFI Addendum 1.0 is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ The change log since RC 10 is appended below. Again, please review this specification carefully. If no suggestion that leads to a serious change is made within two weeks, I will freeze version 1.0. Thanks, Manuel -=- % Changes since RC10: % * 3.3 : Clarified use of foreign functions of pure type % * 4.1.1: Clarified the meaning of foreign imports without a "&" that have a % non-functional type in Haskell % * 5.1 : Clarified the scope of safe use of unsafePerformIO % * 5.5 : "pre-emptive" dropped in footnote regarding finalizers; added % `newForeignPointer_' and renamed `foreignPtrToPtr' to % `unsafeForeignPtrToPtr' % * Typos throughout

1 0