News:
- Because of the number of requests for extensions, the deadline of
PADO-II is extended uniformly until Friday 1st of December.
- A satellite workshop on Implicit Computational Complexity, ICC'01,
is now co-located with PADO-II and MFPS XVII.
--
C
| Actually, the July2000 release hasn't been noted on
| http://haskell.org/hugs -- is there somewhere else I should be looking
| to keep track of it?
There is/was no July 2000 release of Hugs; Jeff put out a snapshot
from the CVS archive for the convenience of Redhat 7.0 users and
used the July 2
On Mon, 13 Nov 2000, Ashley Yakeley wrote:
> Well, it doesn't solve the problem I'm interested in. The file-handling
> is just an example, I'd like to solve it for any kind of object
> destruction, so that this kind of error is always caught at compile-time.
I don't think it's possible without
> >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
At 2000-11-13 02:39, Hannah Schroeter wrote:
>And that yields an exception, as the handle is definitely closed.
>
>Is there any *real* problem with this?
Well, it doesn't solve the problem I'm interested in. The file-handling
is just an example, I'd like to solve it for any kind of object
dest
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
__
Hello!
On Mon, Nov 13, 2000 at 02:30:17AM -0800, Ashley Yakeley wrote:
> [...]
> 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
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 ->
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 =
Hello!
On Mon, Nov 13, 2000 at 09:27:07AM -, 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:: Ope
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 functio
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'
| 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 po
13 matches
Mail list logo
