- Haskell - Haskell.org

Re: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 02:30, Ashley Yakeley wrote: > stealHandle = withOpenFile "filename" ReadMode (\handle -> handle) > stealHandle >>= read Sorry, that should read stealHandle = withOpenFile "filename" ReadMode return stealHandle >>= read -- Ashley Yakeley, Seattle WA

1 0

Re: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 02:18, Hannah Schroeter wrote: >That's the problem. And I think your solution is overly complicated. > >Why not copy what Common Lisp does, just that Haskell can do it without >macros: > >withOpenFile :: FilePath -> IOMode -> (Handle -> IO a) -> IO a >withOpenFile name mode action = do > handle <- openFile name mode > result <- (action handle) `finally` (hClose handle) > return result > >Usage: > >count :: Handle -> IO Int >read :: Handle -> IO [Byte] > > fileLength <- withOpenFile "filename" ReadMode $ \handle -> > count handle > fileContent <- withOpenFile "filename" ReadMode $ \handle -> > read handle Doesn't fulfill condition 2: 2. no read or write operations are performed on file-handles that have not yet been opened, or that have already been closed. ...since you can do stealHandle = withOpenFile "filename" ReadMode (\handle -> handle) stealHandle >>= read -- Ashley Yakeley, Seattle WA

2 1

RE: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 01:27, Chris Angus wrote: >why not create an abstract datatype > >OpenFile a which is a monad > >data OpenFile a = OpenFile (Maybe FileHandle -> IO a) > >and create you operations in terms of this > >openFile :: String -> OpenFile () >count :: OpenFile Int >read :: Int -> OpenFile [Byte] > >then you could habe a run function > >runOF :: OpenFile a -> IO a > >which ran whatever you wanted for the file and ensured tahthe file was >closed correctly afterwards. This is a slight generalisation of my scheme, from which withFile :: OpenFile a -> String -> IO a withFile operation name = runOF (openFile name >> operation) >How we would do this with 2 files however I'm not so sure. Looks like you can't. This might work, however: read :: (Int,Int) -> OpenFile IO [Byte] write :: (Int,[Byte]) -> OpenFile IO () withFile :: OpenFile a -> String -> a copyFile :: OpenFile OpenFile IO () withFile (withFile copyFile "dest") "source" ...but I'm not sure how to write copyFile. -- Ashley Yakeley, Seattle WA

1 0

RE: Imperative Object Destruction
by Chris Angus 13 Nov '00

13 Nov '00

why not create an abstract datatype OpenFile a which is a monad data OpenFile a = OpenFile (Maybe FileHandle -> IO a) and create you operations in terms of this openFile :: String -> OpenFile () count :: OpenFile Int read :: Int -> OpenFile [Byte] then you could habe a run function runOF :: OpenFile a -> IO a which ran whatever you wanted for the file and ensured tahthe file was closed correctly afterwards. How we would do this with 2 files however I'm not so sure. > -----Original Message----- > From: Ashley Yakeley [mailto:ashley@semantic.org] > Sent: 13 November 2000 07:21 > To: Haskell List > Subject: Imperative Object Destruction > > > C++ provides a convenient mechanism for cleaning up stuff, the > destructor, which is guaranteed to get called when an object > passes out > of scope (or something). > > I'm wondering how to make a Haskell equivalent for imperative > code. For > instance, consider a simple file API, with these operations: > > open: given a string (the filename), open an existing file > with that > name, return a file-handle (or fail) > > count: given a file-handle, get the length of the file > > read: given a file-handle, offset into the file and a > number of bytes, > read the file returning a list of bytes (or fail) > > write: given a file-handle, offset into the file and a list > of bytes, > write the bytes to the file at the offset > > close: given a file-handle, close the handle > > In C++ I could simply create an OpenFile class, with the > close operation > in the destructor. The actual operations would be hidden from > OpenFile's > clients. > > I'd like to represent this API in Haskell so that the type-rules > guarantee that in any imperative action of type 'IO a', > > 1. every opened file gets closed exactly once > > 2. no read or write operations are performed on file-handles > that have > not yet been opened, or that have already been closed. > > My first guess was to create a function that encapsulated the entire > life-cycle of the file, passing in a function that would represent > whatever one wished to do on the file: > > count :: Handle -> IO Integer > read :: (Integer,Integer) -> Handle -> IO [Byte] > write :: (Integer,[Byte]) -> Handle -> IO () > withFile :: (Handle -> IO a) -> String -> IO a > > 'withFile operation name' would open the file called 'name', > perform the > operation 'operation', and then close the file. So for > instance, to get > the length of a file named "/home/ashley/foo": > > withFile count "/home/ashley/foo" > > Trouble is, one can easily pass a return function to withFile to get > ahold of the handle after it's been closed. > > My second guess was to use a special type to represent an imperative > operation that needed a handle: > > read :: (Integer,Integer) -> HandleOperation [Byte] > write :: (Integer,[Byte]) -> HandleOperation () > withFile :: HandleOperation a -> String -> IO a > > Of course, I'd then need to provide functions to compose/concatenate > HandleOperation values. But I can't help thinking this > problem is already > well-known and there's a straightforward solution... > > -- > Ashley Yakeley, Seattle WA > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 1

RE: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 00:58, Simon Peyton-Jones wrote: >| C++ provides a convenient mechanism for cleaning up stuff, the >| destructor, which is guaranteed to get called when an object >| passes out >| of scope (or something). > >Haskell doesn't but GHC has an extension (finalisers) that does. >There's a discussion of the issues in our paper about weak pointers >and finalisers > http://research.microsoft.com/~simonpj/#weak I assume you mean finalisers for ordinary Haskell values after they're no longer referenced. That's actually a separate issue, I'm more interested in doing finalisation in Haskell's existing monadic imperative model, something that shouldn't need any runtime extensions. -- Ashley Yakeley, Seattle WA

1 0

RE: Imperative Object Destruction
by Simon Peyton-Jones 13 Nov '00

13 Nov '00

| C++ provides a convenient mechanism for cleaning up stuff, the | destructor, which is guaranteed to get called when an object | passes out | of scope (or something). Haskell doesn't but GHC has an extension (finalisers) that does. There's a discussion of the issues in our paper about weak pointers and finalisers http://research.microsoft.com/~simonpj/#weak Simon

1 0

Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

C++ provides a convenient mechanism for cleaning up stuff, the destructor, which is guaranteed to get called when an object passes out of scope (or something). I'm wondering how to make a Haskell equivalent for imperative code. For instance, consider a simple file API, with these operations: open: given a string (the filename), open an existing file with that name, return a file-handle (or fail) count: given a file-handle, get the length of the file read: given a file-handle, offset into the file and a number of bytes, read the file returning a list of bytes (or fail) write: given a file-handle, offset into the file and a list of bytes, write the bytes to the file at the offset close: given a file-handle, close the handle In C++ I could simply create an OpenFile class, with the close operation in the destructor. The actual operations would be hidden from OpenFile's clients. I'd like to represent this API in Haskell so that the type-rules guarantee that in any imperative action of type 'IO a', 1. every opened file gets closed exactly once 2. no read or write operations are performed on file-handles that have not yet been opened, or that have already been closed. My first guess was to create a function that encapsulated the entire life-cycle of the file, passing in a function that would represent whatever one wished to do on the file: count :: Handle -> IO Integer read :: (Integer,Integer) -> Handle -> IO [Byte] write :: (Integer,[Byte]) -> Handle -> IO () withFile :: (Handle -> IO a) -> String -> IO a 'withFile operation name' would open the file called 'name', perform the operation 'operation', and then close the file. So for instance, to get the length of a file named "/home/ashley/foo": withFile count "/home/ashley/foo" Trouble is, one can easily pass a return function to withFile to get ahold of the handle after it's been closed. My second guess was to use a special type to represent an imperative operation that needed a handle: read :: (Integer,Integer) -> HandleOperation [Byte] write :: (Integer,[Byte]) -> HandleOperation () withFile :: HandleOperation a -> String -> IO a Of course, I'd then need to provide functions to compose/concatenate HandleOperation values. But I can't help thinking this problem is already well-known and there's a straightforward solution... -- Ashley Yakeley, Seattle WA

1 0

List types
by Richard 13 Nov '00

13 Nov '00

Eric Allen Wohlstadter writes: >I would like to be able to make a list that contains functions which take >arguments of a certain type 'a'. However I don't know how many 'a' >arguments there are. For example I'd like to be able to make a list of >f,g, and h. > >f::a->b >g::a->a->b >h::a->a->a->b >[f,g,h] > >My solution so far is declare a type Element like this: >data Element a b c d = One a | Two b | Three c | Four d >and then I can make my list like this, >[One f,Two g,Three h] Don't you mean this? data Element a b=One (a->b) |Two (a->a->b) |Three (a->a->b) >This gets very ugly. Do you guys have any ideas? I wish you would supply more context, so I could see where the ugliness comes in. Hard to fix a problem you cannot see.

1 0

RE: A prototype explorer for Haskell
by Simon Peyton-Jones 10 Nov '00

10 Nov '00

| 2) Why can't we as a community create "front-end" tools such as this | that can be used with several compiler back-ends? I must admit I was | disappointed when the grand "Hugs/GHC merger" was abandoned (I'm not | criticizing the decision, just expressing my disappointment). Me too. But don't worry: GHCi is showing signs of life, and it'll provide exactly the functionality that the Hugs/GHC merger was going to offer. | In fact, | whatever happened to the effort to add Haskell to one of languages | supported by Microsoft's Visual IDE? Daan Leijen did quite a lot, but I'm not sure where he's got to. Daan? Simon

1 0

The world's smartest i/o device for Haskell
by Jan Skibinski 10 Nov '00

10 Nov '00

Described in: http://www.numeric-quest.com/haskell/smartest.html Jan

3 5