Re: [Haskell] Optimistic Evaluation?
On Sun, Aug 27, 2006 at 05:51:34PM -0400, Lajos Nagy wrote: > > I remember once reading a paper by SPJ about Optimistic Evaluation that > is somewhere between lazy and strict. If I remember correctly, they even > implemented it in GHC. Now, it seems that current version of GHC doesn't > support optimistic evaluation (not even as an optional feature), so my > question > is: what happened to OE? It was only ever in a branch of ghc 5.something. > Was it that it seemed like a good idea on paper > but not in reality? Or was it too costly to maintain? Or it didn't deliver > the goods it promised? I'm just curious. My understanding is that the benefit it gave didn't make up for the increased complexity of GHC's source code. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell - I/O] Problem with 'readFile'
L. J. wrote: > Hi, I use the operation 'readFile' for obtain information locates on > a file. When I try to write another information on the same file, I > obtain this error message: "openFile: permision denied". I found this: > "The readFile operation holds a semi-closed handle on the file until > the entire contents of the file have been consumed. It follows that an > attempt to write to a file (using writeFile, for example) that was > earlier opened by readFile will usually result in failure with > isAlreadyInUseError." in this web > http://www.haskell.org/onlinereport/io.html. > > How can I break that semi-closed handle for to write in the > preaviously readed file? Thank you. Since readFile reads the file lazily (on demand), you have to make sure that the whole file gets read by completely evaluating the result string. BTW, I think haskell-cafe is the more appropriate forum for questions like these. Cheers Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Optimistic Evaluation?
Hi, I remember once reading a paper by SPJ about Optimistic Evaluation that is somewhere between lazy and strict. If I remember correctly, they even implemented it in GHC. Now, it seems that current version of GHC doesn't support optimistic evaluation (not even as an optional feature), so my question is: what happened to OE? Was it that it seemed like a good idea on paper but not in reality? Or was it too costly to maintain? Or it didn't deliver the goods it promised? I'm just curious. Regards, Lajos Nagy ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Haddock/GHC SoC project over
Hi everyone, Here is a short status report of the "Port Haddock to use GHC" Summer of Code project, which is now over. Part 1), the GHC modifications, are finished and will be included in the GHC head repository as soon we have made sure that they don't cause any significant slowdowns. Part 2), the actual port of Haddock, is able to render the examples/Test.hs file from the original distribution. There are some problems however, most notably a GHC API panic that keep it from rendering docs for many packages. In terms of functionality, the port is at a very experimental stage, and work remains to render the full set of GHC syntax and to support more than just HTML rendering (e.g Hoogle output). To try the code out, grab these repositories: http://darcs.haskell.org/SoC/ghc.haddock http://darcs.haskell.org/SoC/haddock.ghc You have to compile and install ghc.haddock and then use it to compile and install haddock.ghc. If you want to help out, or just have questions, email me or ping me on #haskell. But maybe the best place to discuss would be [EMAIL PROTECTED], where everyone can follow. Big thanks to Google, haskell.org and Simon M! /David ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] AutoForms release 0.2
Hi all Haskeleers I am pleased to announce AutoForms release 0.2. AutoForms is a library to ease the creation of Graphical User Interfaces (GUI). It does this by using generic programming (SYB) to construct GUI components. See the full description at http://autoforms.sourceforge.net/ . Any comments will be much appreciated. Greetings, Mads Lindstrøm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[4]: [Haskell] [Haskell - I/O] Problem with 'readFile'
Hello John, Sunday, August 27, 2006, 5:45:21 PM, you wrote: >> return $! tail mates_str > But you need to evaluate the result of readFile all the way to the end--you > need to use a function that traverses the entire file contents. Otherwise > the file will be left open to read the bit you haven't traversed. Hence > length rather than tail. oh, sorry, i mean 'last' -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Re[2]: [Haskell] [Haskell - I/O] Problem with 'readFile'
Bulat Ziganshin wrote: > > length mates_str `seq` return () > > it's the same. i recommend you to use: > > return $! tail mates_str > > 'tail' should be slightly faster than 'len' ...but also slightly less correct. You probably meant 'last'. (But it's still an ugly and dangerous programming style.) Udo. -- Why is television called a medium? Because it is neither rare nor well-done. signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Re[2]: [Haskell] [Haskell - I/O] Problem with 'readFile'
Hello L.,
Sunday, August 27, 2006, 12:43:24 PM, you wrote:
> length s `seq` writeFile f ("hello"++s)
length mates_str `seq` return ()
it's the same. i recommend you to use:
return $! tail mates_str
$! defined as
f$!x = x `seq` f x
'tail' should be slightly faster than 'len'
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
But you need to evaluate the result of readFile all the way to the end--you
need to use a function that traverses the entire file contents. Otherwise
the file will be left open to read the bit you haven't traversed. Hence
length rather than tail.
John
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re[2]: [Haskell] [Haskell - I/O] Problem with 'readFile'
Hello L.,
Sunday, August 27, 2006, 12:43:24 PM, you wrote:
>> > length s `seq` writeFile f ("hello"++s)
> length mates_str `seq` return ()
it's the same. i recommend you to use:
return $! tail mates_str
$! defined as
f$!x = x `seq` f x
'tail' should be slightly faster than 'len'
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
On 8/27/06, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: djsenda: > Hi, I use the operation 'readFile' for obtain information locates on > a file. When I try to write another information on the same file, I > obtain this error message: "openFile: permision denied". I found this: > "The readFile operation holds a semi-closed handle on the file until > the entire contents of the file have been consumed. It follows that an > attempt to write to a file (using writeFile, for example) that was > earlier opened by readFile will usually result in failure with > isAlreadyInUseError." in this web > http://www.haskell.org/onlinereport/io.html. > > How can I break that semi-closed handle for to write in the > preaviously readed file? Thank you. Due to lazy IO, you'll need to either read the entire file first, before you can safely write to that file, (or explicitly close the Handle): import Control.Exception main = do s <- readFile "x" evaluate $ length s -- evaluate the list, reading it in writeFil e "x" (reverse s) GHCi says me that: evaluate is not in scope Here we use 'evaluate (length s)' to explictily force the entire file to be read, which will close the Handle, and allows us to safely write back to the same file. -- Don P.S. Learning Haskell questions are better addressed to haskell-cafe@haskell.org Ok, for another question I will write in this mailing list. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
On 8/27/06, L. J. <[EMAIL PROTECTED]> wrote:
On 8/27/06, John Hughes <[EMAIL PROTECTED]> wrote:
>
>
> > Hi, I use the operation 'readFile' for obtain information locates on
> > a file. When I try to write another information on the same file, I
> > obtain this error message: "openFile: permision denied". I found this:
> > "The readFile operation holds a semi-closed handle on the file until
> > the entire contents of the file have been consumed. It follows that an
> > attempt to write to a file (using writeFile, for example) that was
> > earlier opened by readFile will usually result in failure with
> > isAlreadyInUseError." in this web
> > http://www.haskell.org/onlinereport/io.html.
> >
> > How can I break that semi-closed handle for to write in the
> > preaviously readed file? Thank you.
>
> readFile returns an *unevaluated* list of characters from the file--as your
> program needs those characters, so they will be read from the file. Once
> they have all been read, then the file is closed. So to ensure that the
> file is closed, you just have to make sure your program reads all the
> characters. One way is to count them. So here's a function that reads a
> file, then rewrites it with "hello" added at the beginning:
>
> addHello f = do
> s <- readFile f
> length s `seq` writeFile f ("hello"++s)
>
> length s counts the characters in the file (forcing it all to be read), and
> the `seq` is like a semicolon in C: it forces length s to be computed before
> the writeFile is performed.
>
> John
Thanks you for your code. I try with it and it works well, but I can
not use it in my aplication because I read the file in one function, I
compute the results with the readed information and, finally, I wrote
this results in another function (in this moment I do not have the
readed string, I have my structured data). How can I use this `seq`
with different functions?
I solve the problem, but my method could not be the better
(methodologically speaking). I insert this code inmediately after read
the file (with readFile):
length mates_str `seq` return ()
Is it so bad this code? I think it works so well.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
L. J. wrote: > Hi, I use the operation 'readFile' [...] > > How can I break that semi-closed handle for to write in the > preaviously readed file? Thank you. Not at all. But you can get the same effect you get from 'readFile' if you use 'openFile' and 'hGetContents'. If you do the latter, you can really close the semi-closed handle by calling 'hClose'. However, chances are, that you will not have consumed the whole file at the point where you close it (lazy evaluation can^W will be tricky), you will find that you write a new file with empty content, because apparently you read an empty file when in fact it wasn't empty, and so on. In short: don't do that. Also, don't fight the error message, understand, that it saved you from trashing a perfectly good file. Instead, 'readFile' your data, 'writeFile' it into a new(!) file, then 'renameFile' the new over the old one. Before doing anything else, get a deep understanding of lazy IO. (And this understanding will basically be, that a database package (gdbm, Berkeley DB, you name it) will serve you better.) Udo. -- "The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding." -- Brandeis signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
On 8/27/06, John Hughes <[EMAIL PROTECTED]> wrote:
> Hi, I use the operation 'readFile' for obtain information locates on
> a file. When I try to write another information on the same file, I
> obtain this error message: "openFile: permision denied". I found this:
> "The readFile operation holds a semi-closed handle on the file until
> the entire contents of the file have been consumed. It follows that an
> attempt to write to a file (using writeFile, for example) that was
> earlier opened by readFile will usually result in failure with
> isAlreadyInUseError." in this web
> http://www.haskell.org/onlinereport/io.html.
>
> How can I break that semi-closed handle for to write in the
> preaviously readed file? Thank you.
readFile returns an *unevaluated* list of characters from the file--as your
program needs those characters, so they will be read from the file. Once
they have all been read, then the file is closed. So to ensure that the
file is closed, you just have to make sure your program reads all the
characters. One way is to count them. So here's a function that reads a
file, then rewrites it with "hello" added at the beginning:
addHello f = do
s <- readFile f
length s `seq` writeFile f ("hello"++s)
length s counts the characters in the file (forcing it all to be read), and
the `seq` is like a semicolon in C: it forces length s to be computed before
the writeFile is performed.
John
Thanks you for your code. I try with it and it works well, but I can
not use it in my aplication because I read the file in one function, I
compute the results with the readed information and, finally, I wrote
this results in another function (in this moment I do not have the
readed string, I have my structured data). How can I use this `seq`
with different functions?
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Exists any null instruction in Haskell?
On 8/27/06, Neil Mitchell <[EMAIL PROTECTED]> wrote: [Moving to haskell-cafe] Hi, > I want to know if it exists a null instruction (a instruction > that do anything Not really, since instructions don't "do anything" anyway - they only compute values. If you are in the IO monad then "return ()" is the do nothing. I need this answer. This is my case. Thanks you very much. In the function world, "id" is the do nothing. In recursive list processing, then something like [] is probably the "base case" in a recursive function, so stops the recursivity. If you give a more concrete example, then maybe we can give you a better answer. Thanks Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
