June 2003 - Haskell - Haskell.org

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

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

12 Jun '03

Dear Haskell Folks, Release Candidate 10 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 7, which was the last version circulated via haskell(a)haskell.org, is appended below. 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 RC9: * 1: Mentioning interaction with foreign threads as an open problem. * 2 & 3: Removed `threadsafe' again, as the proposal for thread support is still evolving and it is not yet clear whether a new safety level is required. * 5.5: Added the type synonym `FinalizerPtr' and rewrite the documentation of finalizers. * 5.6: Clarified the description of `StablePtr' * 5.8: Added `finalizerFree' * 6.2: All the types in CTypes must be newtypes that are exported abstractly. Changes since RC8: * 5.8: `MarshallAlloc.reallocBytes' is no longer permitted on memory allocated with `alloca' or `allocaBytes'. * 6.1: Deinitialisation of the RTS via `hs_exit()' followed by (re)initialisation with `hs_init()' must be supported. Changes since RC7: * Clarified the lexis of C identifiers and C header file names * In `ForeignPtr', added `mallocForeignPtrArray' and `mallocForeignPtrArray0' * Clarified spec of allocations functions adding constraints taken from the corresponding C routines * `mallocBytes' and `allocaBytes' must align memory sufficiently for any basic foreign type that fits into the allocated block * Removed typos in the description of the module `ForeignPtr' * Added Peter Gammie to the list of acknowledged people * `addForeignPtrFinalizer' guarantees that finalizers for a single foreign pointer are executed in the opposite order as they were added. * `Storable': Require that the size is divisible by the alignment * Added Ross Paterson to the list of acknowledged people * Added hs_free_fun_ptr() and hs_free_stable_ptr() * Changed order of arguments of `mkIOError' and `annotateIOError' to match with the current implementation in GHC's FFI libraries.

4 13

Stupid wuestion about Monads :)
by Filip 11 Jun '03

11 Jun '03

I have a question :) What should I do if I have something like "IO Bool" and I need "Bool" ?? And the same with other IO +something. Thank You :)

6 5

LOOP + HANDLE
by Filip 11 Jun '03

11 Jun '03

So how to write function that will wait until Handle is ready for reading ?? And is there something like "if" ??

3 2