Henning Thielemann wrote:
Although it is possible to hide packages by GHC options, we should not
do this, because several libraries might use different Hash tables and
it would not be possible to write a program which uses many of these
libraries. It's better to add a distinguishing part to
--- On Sat, 8/16/08, Andrew Coppin [EMAIL PROTECTED] wrote:
Although it is possible to hide packages by GHC options, we should not
do this, because several libraries might use different Hash tables and
it would not be possible to write a program which uses many of these
libraries.
I writed a little program to test forkIO. in fact, I want to know how to
implement the 'select' system call in haskell:
module Main where
import Control.Concurrent.Chan
import Control.Concurrent
import System.IO
main = do
chan - newChan
handles - mapM ((flip openFile) ReadMode)
On 2008 Aug 16, at 5:00, Andrew Coppin wrote:
What to do at the module level is less obvious. Having several
packages provide different implementations of the same thing is
arguably useful. (E.g., I know Gtk2hs provies an SOE module. What
about wxHaskell? If the interface is standard
On 2008 Aug 16, at 12:22, Changying Li wrote:
test.hs: /tmp/b: hGetChar: end of file
test.hs: /tmp/c: hGetChar: end of file
I think the thread will be blocked when /tmp/b has nothing.
but it get EOF, why ?
Because FIFOs are odd. Open them for read/write to avoid unexpected
EOFs and
Robert Greayer wrote:
This seems to be a common approach, but it runs counter to the objective of
separating 'provenance' from module naming. 'Coppin' is (part of, sans
version) the provenance of the hashtable implementation, so I'm not sure how
this sort of scheme is better than just
On 2008 Aug 16, at 13:22, Andrew Coppin wrote:
Yeah, as I said, it's not immediately obvious exactly what the best
solution is. Maybe we just need to get everybody to come up with
more inventive names than just hashtable or binary. (E.g., We
have several parsers already, but they all have
I tried to replace a permutation generator with one that generates
each permutation from the previous one, in a stream-like fashion. I
had hoped the stream-based algorithm would be more efficient because I
use only one permutation at a time, so only the permutation and the
previous one need be in
John D. Ramsdell wrote:
Straight forward permation algorithm.
permutations :: Int - [[Int]]
permutations n
| n = 0 = []
| n == 1 = [[0]]
Btw. I think that case is redundant.
| otherwise =
concatMap (insertAtAllPos (n - 1)) (permutations (n - 1))
where
Jason Dagit wrote:
On Wed, Aug 6, 2008 at 11:09 AM, Andrew Coppin
[EMAIL PROTECTED]wrote:
I just (re)discovered that I can do things like
data Foo x = Foo Int Int
Now Foo Int and Foo Double are, as far as the type checker cares, two
completely different types, even though in fact they
Haskellers,
I'm slowly porting XCB (the X C Bindings) to Haskell, and I would like
input from any interested parties.
The following is a summary of my plan so far. I'm interested in
hearing any suggestions or concerns about what a Haskell library for
writing X clients should look like. This is
John D. Ramsdell schrieb:
Try deleting it and see what happens.
Erm, yes, this case is wrong:
| n = 0 = []
There is _one_ permutation with no elements, namely [], thus it must be
| n == 0 = [[]]
___
Haskell-Cafe mailing list
-- Announcing: logfloat 0.8.5
New official release of the logfloat package for manipulating log-domain
floating numbers. This is primarily a maintenance release updating the
documentation and with minor
13 matches
Mail list logo
