The FileManip package provides expressive functions and combinators for
searching, matching, and manipulating files.
It provides three modules.
System.FilePath.Find lets you search a filesystem hierarchy efficiently:
find always (extension ==? .rb) = mapM_ remove
Bryan O'Sullivan wrote:
The FileManip package provides expressive functions and combinators for
searching, matching, and manipulating files.
As seems to be my habit, I forgot something important, namely where to
get FileManip from.
The FileManip package provides expressive functions and combinators for
searching, matching, and manipulating files.
hi Brian,
i'm a fan of find | xargs, so a portable haskell replacement unencumbered
by viral licenses would be very welcome. i have no intention to participate
in
Duncan Coutts wrote:
On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote:
So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you
just need:
hs-source-dirs: test-src, src
No, that's not enough, I also have to add the following lines to make
the executable compile and link:
On Wed, 2007-05-02 at 09:59 +0100, Claus Reinke wrote:
The FileManip package provides expressive functions and combinators for
searching, matching, and manipulating files.
hi Brian,
i'm a fan of find | xargs, so a portable haskell replacement unencumbered
by viral licenses would be
Hi
Could we have a collective thought, and decide whether we wish to
either kill off all compilers that don't start with a G, or could
people at least do minimal benchmarking on Hugs? I'm not quite sure
what the solution is, but it probably needs some discussion.
I don't think doing
i'm a fan of find | xargs, so a portable haskell replacement unencumbered
by viral licenses would be very welcome. i have no intention to participate
in yet-another-licencing-discussion, i would just like to ask whether those
limitations of your offering are an accident or intended?
On Mon, 30 Apr 2007, Denis Volk wrote:
Hello all,
I am trying to make a (turn-based) game in Haskell and need to pass
around quite a bit of information, so using the State monad seems most
appropriate. My question is, which is a better idea:
The famous Why functional programming matters
On Wed, 2007-05-02 at 12:00 +0100, Claus Reinke wrote:
i'm a fan of find | xargs, so a portable haskell replacement unencumbered
by viral licenses would be very welcome. i have no intention to participate
in yet-another-licencing-discussion, i would just like to ask whether
those
These Haskell lists seems to have a problem of having to many elitist
pricks on it admittedly I am probably in this category as well so I will
help you guys and by eliminating one prick and remove myself from the
list good luck with the rest of them
Troy
-Original Message-
From: [EMAIL
no need to get all touchy-feely about this.
Perl is popular so it must have some merit.
So is Crack. I still won't smoke it, though.
I don't subscribe to the
flawed reasoning that Perl Hackers just don't know any better or that
they are dumb, or intellectual inferior in some
Hi
no, i browsed the license file before asking my question (no non-restrictive
license needs to be longer than a page). if i wanted to use that library for
anything i want to distribute, my only chance to avoid the source
re-distribution
and advertising clauses would be dynamic linking
Hi Andrew,
Thanks for the comments, it really helps to have someone else's
opinion on my code. I'll be applying what you've said as soon as I
get a chance and I'm sure I'll have some more questions then. I'll
certainly look more closely at the Set interface and try and duplicate
all the parts
On May 2, 2007, at 7:00 , Claus Reinke wrote:
my question. similarly for the unix dependency - it could be
inherent in the
design, or an accident of the author's current platform.
The Haskell libraries don't currently provide a platform-independent
way to do most file tests. I
On Wed, May 02, 2007 at 10:08:41 +0100, Simon Marlow wrote:
[..]
IMO we shouldn't allow both a library and an exe in the same package.
I think I argued against this originally, and my understanding is that
doing this is deprecated, although perhaps not visibly enough.
Whenever the question of what
Hello Neil,
Wednesday, May 2, 2007, 2:48:16 PM, you wrote:
the right answer always, then I think its a much nicer choice. For
the particular case of ByteString, type ByteString=String means you
roughly import Data.List - not that much additional work or
maintenance.
then Binary library want
Claus Reinke wrote:
i have no intention to participate
in yet-another-licencing-discussion, i would just like to ask whether
those limitations of your offering are an accident or intended?
I didn't use the LGPL by accident. However, I might be amenable to
persuasion, perhaps more so if you
Claus Reinke wrote:
if i wanted to use that library
for
anything i want to distribute, my only chance to avoid the source
re-distribution
and advertising clauses would be dynamic linking
I believe that the magical protective properties of dynamic linking
amount to no more than folklore.
Simon Peyton-Jones wrote:
| I like the strong static type system of Haskell for various
| reasons. One reason is, that it makes easier to understand new
| code. I.e. when I read code I type ':t foo' in ghci/hugs from
| time to time, to check my own idea of the type signature, if it
| is not
i have no intention to participate
in yet-another-licencing-discussion, i would just like to ask whether
those limitations of your offering are an accident or intended?
I didn't use the LGPL by accident. However, I might be amenable to
persuasion, perhaps more so if you climb down from that
I think Simon is right, and not just from a Haskell point of view.
Allowing a package to contain a both a library and an executable
makes the behavior of the package system less obvious. That's not to
say that it can't behave correctly, but that it can't behave both
correctly and in a
Jules Bean [EMAIL PROTECTED] wrote,
concerning the problem of getting at the types of local definitions:
Simon Peyton-Jones wrote:
The principal difficulties here are to do with what do we want
rather the implementation challenges.
1. Should the compiler print the type of every
On 2 May 2007 16:16:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
* It would be nice if this worked inside the do-notation, too:
do x :: Ordering
x - m
(This is curently a syntax error.)
I think the following works with -fglasgow-exts:
do (x :: Ordering) - m
--
-David
* It would be nice if this worked inside the do-notation, too:
do x :: Ordering
x - m
(This is curently a syntax error.)
I think the following works with -fglasgow-exts:
do (x :: Ordering) - m
I know, but it is not as nice!
;-)
Wolfram
I'd love to post an ANN: Chicago Haskell user group, but i want to
make sure there's more than one of me.
-johnnn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[EMAIL PROTECTED] wrote:
Jules Bean [EMAIL PROTECTED] wrote,
concerning the problem of getting at the types of local definitions:
Simon Peyton-Jones wrote:
The principal difficulties here are to do with what do we want
rather the implementation challenges.
1. Should the compiler
On Wed, May 02, 2007 at 04:16:57PM -, [EMAIL PROTECTED] wrote:
Now the compiler gives you wonderful error messages
``cannot match type `x y z' against Ordering'' ---
so you replace ``Ordering'' with ``x y z''.
You could just use a rigid type variable:
foo :: a
foo = ...
(What is the
G'day all.
Quoting Michael T. Richter [EMAIL PROTECTED]:
Ummm... Udo? Just what the fuck did you hope to accomplish with this
kind of talk?
Guys, could we keep it civil on the list, please?
And for the record:
http://www.perl.com/pub/2000/12/advocacy.html
Cheers,
Andrew Bromage
ajb:
G'day all.
Quoting Michael T. Richter [EMAIL PROTECTED]:
Ummm... Udo? Just what the fuck did you hope to accomplish with this
kind of talk?
Guys, could we keep it civil on the list, please?
And for the record:
http://www.perl.com/pub/2000/12/advocacy.html
I'd like
29 matches
Mail list logo
