November 2002 - Glasgow-haskell-users

Re: Template metaprogramming for Haskell article.
by C.Reinke 25 Nov '02

25 Nov '02

> I am reading the article template meta-programming for haskell and am > wondering if > 1) this is already implemented in ghc. > 2) if not when this will be released answered in section 2.1 (GHC) and 3.6.1 (Template Haskell) of the Haskell Communities & Activities Report (November 2002 edition): http://www.haskell.org/communities/11-2002/html/report.html#sect2.1 http://www.haskell.org/communities/11-2002/html/report.html#sect3.6.1 Claus PS. Are there readers of ghc-users who don't read the main haskell list (I didn't want to spam all Haskell-related lists with the announcements, but keep getting the feeling that not everyone is following the main list anymore)?

1 0

RE: re-opening a closed stdin?
by Simon Marlow 25 Nov '02

25 Nov '02

> Simon Marlow wrote: > > > > Simon Marlow: > > > > [Lazy I/O] is nice, but it introduces too many problems. What > > > > happens to any I/O errors encountered by the lazy I/O? > They have to > > > > be discarded, which means you can't effectively use lazy I/O for > > > > robust applications anyway. > > > > > > Surely they are thrown as exceptions which can then be manipulated > > > in pure code using > > > > > > mapExceptions :: (Exception -> Exception) -> (a -> a) > > > > > > and caught in the IO monad using catch? > > > > No, the report clearly states that they are discarded. > > Could you please point out where? I couldn't find it with a > quick look. Section 11.2.1 in the Library Report, last paragraph. > > We could perhaps have our own versions of the lazy I/O > operations which > > throw exceptions, but this in itself is problematic because > these kind > > of exceptions would be asynchronous in nature. If lazy I/O > is allowed > > to raise exceptions, then we have a situation where > evaluating anything > > can raise an I/O exception. In theory this shouldn't be a > problem - we > > all ought to be writing asynchronous-excpetion-safe code anyway to > > protect against StackOverflow, but an I/O exception is > often one that > > you want to handle gracefully and recover from. I feel distinctly > > uncomfortable about I/O exceptions being thrown by pure > code, and even > > more uncomfortable about asynchronous I/O exceptions. > > Is even the following example from the library report (section 11.8.2) > problematic? > > import System > import Char( toUpper ) > > main = do > [f1,f2] <- getArgs > s <- readFile f1 > writeFile f2 (map toUpper s) It depends what you want to happen in the event of a I/O error in the file being read. If you want to reliably clean up, say remove f2 and emit a helpful message, then as Haskell 98 stands you can't do it. If we were to make the lazy I/O raise an exception in the event of an error, then you can do the cleanup, but you have to know which computations can force the lazy I/O and wrap appropriate exception handlers around them. Knowing which computations can force the I/O is problematic. There *is* a reasonable semantics for readFile: read the whole file immediately. You don't have to generate the Haskell String eagerly, just read the whole file into a cache and report any I/O errors. This doesn't work too well for large files, or for using readFile/getContents to write stream processors though. Cheers, Simon

1 0

RE: re-opening a closed stdin?
by Simon Marlow 25 Nov '02

25 Nov '02

> Simon Marlow: > > [Lazy I/O] is nice, but it introduces too many problems. What > > happens to any I/O errors encountered by the lazy I/O? They have to > > be discarded, which means you can't effectively use lazy I/O for > > robust applications anyway. > > Surely they are thrown as exceptions which can then be manipulated > in pure code using > > mapExceptions :: (Exception -> Exception) -> (a -> a) > > and caught in the IO monad using catch? No, the report clearly states that they are discarded. We could perhaps have our own versions of the lazy I/O operations which throw exceptions, but this in itself is problematic because these kind of exceptions would be asynchronous in nature. If lazy I/O is allowed to raise exceptions, then we have a situation where evaluating anything can raise an I/O exception. In theory this shouldn't be a problem - we all ought to be writing asynchronous-excpetion-safe code anyway to protect against StackOverflow, but an I/O exception is often one that you want to handle gracefully and recover from. I feel distinctly uncomfortable about I/O exceptions being thrown by pure code, and even more uncomfortable about asynchronous I/O exceptions. Cheers, Simon

3 2

Template metaprogramming for Haskell article.
by Immanuel Litzroth 25 Nov '02

25 Nov '02

I am reading the article template meta-programming for haskell and am wondering if 1) this is already implemented in ghc. 2) if not when this will be released Thanks in advance Immanuel *************************************************************************** His endeavours to improve these conditions by innovations in the current methods of teaching are fully described in his writings; these made him unpopular with his brethren in the order and led to his removals to the monastery of Pomposa near Ferrara, Italy. Here the same lot seems to have befallen him. About Guido of Arezzo Immanuel Litzroth Software Development Engineer Enfocus Software Kleindokkaai 3-5 B-9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Immanuell(a)enfocus.be web : www.enfocus.be ***************************************************************************

1 0

RE: re-opening a closed stdin?
by Simon Marlow 25 Nov '02

25 Nov '02

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > One reason, I think, is lazy I/O(*). It's to stop you accidentally > > [...] > > > (*) kill it! die! die! > > So you want > main = readFile "/dev/zero" >> return () > to terminate violantly rather than terminate peacefully? :) > > Seriously, I understand that the IO monad is the most intuitive and > robust when it is strict. But sometimes it is also nice if one could > map a file to a lazy string. It is nice, but it introduces too many problems. What happens to any I/O errors encountered by the lazy I/O? They have to be discarded, which means you can't effectively use lazy I/O for robust applications anyway. Cheers, Simon

3 2

RE: how can I use Posix in win32 cygwin ?
by Simon Peyton-Jones 25 Nov '02

25 Nov '02

We don't support Posix for Win32. It's probably not impossible to implement it, but we have not devoted the time to do so. Maybe you can? Simon | -----Original Message----- | From: Ahn Ki-yung [mailto:kyagrd@bawi.org] | Sent: 25 November 2002 06:37 | To: glasgow-haskell-users(a)haskell.org | Subject: how can I use Posix in win32 cygwin ? | | ghc 5.04.1 binary distribution for win32 does not contain Posix. | | How can I use the posix package in win32 cygwin platform ? | | thanks. | | -- | Ahn Ki-yung | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

how can I use Posix in win32 cygwin ?
by Ahn Ki-yung 25 Nov '02

25 Nov '02

ghc 5.04.1 binary distribution for win32 does not contain Posix. How can I use the posix package in win32 cygwin platform ? thanks. -- Ahn Ki-yung

1 0

Silly question about IORefs and MVars
by Nicolas Oury 23 Nov '02

23 Nov '02

Hello, I have a silly question about IORefs and MVars. When do we have to use MVars if a var is accessed by multiple threads. In fact, I wonder why IORefs updates aren't safe : it seems that preemptive scheduling takes place during memory allocation and I can't see where there could be an allocation (and so a switch) in a read or a write of an IORef. Related question : how less performant is a MVar comparated to simple ref. best regards, Nicolas Oury

2 1

Re: re-opening a closed stdin?
by Albert Lai 22 Nov '02

22 Nov '02

"Simon Marlow" <simonmar(a)microsoft.com> writes: > One reason, I think, is lazy I/O(*). It's to stop you accidentally [...] > (*) kill it! die! die! So you want main = readFile "/dev/zero" >> return () to terminate violantly rather than terminate peacefully? :) Seriously, I understand that the IO monad is the most intuitive and robust when it is strict. But sometimes it is also nice if one could map a file to a lazy string.

1 0

RE: -Werror Request
by Ashley Yakeley 21 Nov '02

21 Nov '02

At 2002-11-20 01:38, Simon Peyton-Jones wrote: >Done! Thanks! -- Ashley Yakeley, Seattle WA

1 0