nemesis <nam### [at] gmailcom> wrote:
> Besides, the always-close-after-open thing in languages like C is a non-issue
> when you use code templates and the likes...

  In a way his approach to opening and reading the contents of a file seems
too simplistic:

  I agree: If what you are going to do is to read the entire contents of
the file into a string which you can then manipulate, the language offering
you a simple, easy and completely safe way to do this is a good thing.
  Given that languages like haskell use lazy evaluation, even if you are
only going to read part of the file and not the entire file, the haskell
compiler might probably be able to optimize it so that only that part of
the file is indeed read.

  However, I'm wondering what happens with huge files (which won't fit
in memory) and which you read thoroughly. It could be, for example, a
video file (which could be, for example, 3 gigabytes big, while your
computer has only eg. 1 gigabyte of RAM).
  The usual way of doing this is to read a bunch of data from the file
(for example some megabytes), process it, discard it, read a new bunch
of data from the file, etc.

  What I'm wondering is what a language like haskell will do in this case,
even though it has lazy evaluation. In fact, lazy evaluation is of no
help here because you are, after all, reading the entire file. If you
use the completely abstract way you could end up having the haskell
program trying to read the entire file into memory, thus running out of it.

  You have to somehow be able to tell it that you are only going to need
small bunches at a time, and after they have been processed, they can be
discarded. I wonder if there's a really abstract way of saying this in
haskell, or whether you need to go to ugly low-level specifics.

-- 
                                                          - Warp

Post a reply to this message