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 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
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.
http://www.
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:
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 o
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
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
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
> Not a very good i
Jules Bean wrote:
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.
Woah!
Well, I understood *one* of thos
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
___
Hask
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
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 somet
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 f
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 correc
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
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, howeve
I notice that getDirectoryContents appears to return its results in
alphabetical order. Is this behaviour actually guaranteed?
Related: Is there a way to get rid of "." and ".." in the results?
(Obviously this causes directory recusion to malfunction.) I can of
course manually filter them out,
18 matches
Mail list logo
