Hello Andrew,
Friday, October 12, 2007, 9:21:07 PM, you wrote:
I notice that getDirectoryContents appears to return its results in
alphabetical order. Is this behaviour actually guaranteed?
on NTFS filesystem, files are stored in directory alphabetically
sorted. on FAT disks the order may be
Yitzchak Gale wrote:
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Please no.
The last thing haskell needs is more dangerous semantically broken
non-referentially-transparent lazy IO structures.
Jules
___
I wrote:
...a tool for recursing through directories...
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Bryan O'Sullivan wrote:
See System.FilePath.Find in
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.2
Not a very good idea.
I wrote:
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Jules Bean wrote:
Please no.
The last thing haskell needs is more dangerous semantically broken
non-referentially-transparent lazy IO structures.
Agreed. I would definitely not want it to be a
I wrote:
...a tool for recursing through directories...
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Bryan O'Sullivan wrote:
See System.FilePath.Find in
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.2
-- List all directories
Hi Yitzchak,
On Sun, Oct 14, 2007 at 11:33:38AM +0200, Yitzchak Gale wrote:
Here it is critical that ListT be taken from
http://haskell.org/haskellwiki/ListT_done_right
and not the broken implementation that comes with mtl.
(Finally fixed in 6.8? Please?)
mtl is not part of GHC
Yitzchak Gale wrote:
Your library is very nice. But - it suffers from the
same problem. You use unsafe IO operations to build
a lazy IO list, and we all know what grief that can
lead to.
This is little different from the approach taken by Python's os.walk,
which lazily yields the contents of
Hi Bryan,
You wrote:
This is little different from the approach taken by Python's os.walk,
which lazily yields the contents of a directory tree as it traverses it.
I'm a little unclear on why one appears good in your eyes, while the
other is not, beyond perhaps the depth/breadth knob and
Yitzchak Gale wrote:
I do think that it is much better to provide IO laziness
using monad transformers (or whatever) rather than
unsafe IO.
That's fair enough. I think it would be great if you were to turn your
ideas into a library and provide a few examples of its use.
b
On Sun, 14 Oct 2007, Bryan O'Sullivan wrote:
Yitzchak Gale wrote:
I do think that it is much better to provide IO laziness
using monad transformers (or whatever) rather than
unsafe IO.
That's fair enough. I think it would be great if you were to turn your ideas
into a library and provide
Andrew Coppin wrote:
Is there a way to get rid of . and .. in the results?
Brandon S. Allbery wrote:
Manual filtering is always required, whether C, Perl, Haskell, etc.
I dunno, maybe python filters them for you or something.
Correct, Python filters them out. This is clearly the correct
On Sat, 13 Oct 2007, Yitzchak Gale wrote:
Andrew Coppin wrote:
Is there a way to get rid of . and .. in the results?
Brandon S. Allbery wrote:
Manual filtering is always required, whether C, Perl, Haskell, etc.
I dunno, maybe python filters them for you or something.
Correct, Python
On Sat, Oct 13, 2007 at 23:27:13 +0200, Yitzchak Gale wrote:
Andrew Coppin wrote:
Is there a way to get rid of . and .. in the results?
Brandon S. Allbery wrote:
Manual filtering is always required, whether C, Perl, Haskell, etc.
I dunno, maybe python filters them for you or something.
Yitzchak Gale wrote:
Python also has os.walk, a very convenient functional (sort of)
tool for recursing through directories. (It sounds trivial, but
it is not, there are enough annoying details that this function
saves huge amounts of time.) Very embarrassing that Haskell
is missing this.
See
All these questions are actually Windows-centric; the answers are
different on Unix.
On Oct 12, 2007, at 13:21 , Andrew Coppin wrote:
I notice that getDirectoryContents appears to return its results in
alphabetical order. Is this behaviour actually guaranteed?
There is no guarantee,
On Fri, 12 Oct 2007 18:21:07 +0100, you wrote:
I notice that getDirectoryContents appears to return its results in
alphabetical order. Is this behaviour actually guaranteed?
This is a Windows thing. All of the NT-based operating systems list
files in alphabetical order by default. You see the
16 matches
Mail list logo
