Re: [Haskell-cafe] ANNOUNCE: Data.IVar 0.1

[Luke Palmer]

On Wed, Oct 8, 2008 at 12:20 AM, Don Stewart <[EMAIL PROTECTED]> wrote:

> lrpalmer:
> >Several very elegant FRP approaches are emerging, most visibly
> >FRP.Reactive, which rely on blocking on multiple variables at once,
> >continuing when the *first* of them is available. . . inside an
> >unsafePerformIO, so the beautiful STM "orElse" solution is not
> available.
> > The current solution is to race threads against each other, and have
> the
> >one that finishes first kill the other one.  This is implemented, for
> >example, in Data.Unamb.  However, our empirical tests have shown that
> the
> >GHC scheduler is not *quite* good enough to handle this efficiently,
> and
> >ends up introducing too much latency and nondeterminacy.
>
> Cool! Does you IVar implementation have anything in common with previous
> proposals for things called IVar (or say, 'ports',
> http://www.cse.unsw.edu.au/~chak/haskell/ports/
> )?


Yes, I picked up the name from haskell-cafe discussions a while back.
Various forms have been popping in and out of the reactive libraries.

I hadn't seen ports before.

What's the background for this abstraction?
>

So like I said, I'm not too sure, I just stole the name and vague idea from
discussions about it.  As is easily noticed from the jive above, it's
motivated by the continuous barrage of suboptimal FRP libraries.  While I'm
working on reactive from the top down, this is the beginning of one I have
planned, taking baby steps from the bottom up  (and it'll likely get
incorporated into reactive too).

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Data.IVar 0.1

[Don Stewart]

lrpalmer:
>Several very elegant FRP approaches are emerging, most visibly
>FRP.Reactive, which rely on blocking on multiple variables at once,
>continuing when the *first* of them is available. . . inside an
>unsafePerformIO, so the beautiful STM "orElse" solution is not available.
> The current solution is to race threads against each other, and have the
>one that finishes first kill the other one.  This is implemented, for
>example, in Data.Unamb.  However, our empirical tests have shown that the
>GHC scheduler is not *quite* good enough to handle this efficiently, and
>ends up introducing too much latency and nondeterminacy.

Cool! Does you IVar implementation have anything in common with previous
proposals for things called IVar (or say, 'ports',
http://www.cse.unsw.edu.au/~chak/haskell/ports/)?

What's the background for this abstraction?

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monadic parser with Happy and Alex

[Timothy Goddard]

On Sun, 05 Oct 2008 04:05:51 Manlio Perillo wrote:
> Hi.
>
> I have completed a draft of a CSS lexer, using Alex.
> http://hg.mperillo.ath.cx/haskell/webtools/file/tip/src/CSS/Lexer.x
>
> The lexer use the posn wrapper.
>
> Now I'm starting to write the parser with Happy, however for the final
> product I would like to:
> 1) Be able to do I/O in the lexer, for stylesheets inclusion
> (@import rule)
> 2) be able to keep state in the parser (or lexer?), for character
> transcoding (@charset rule)
>
>
> This should be possible with Happy (and there are some example), however
>   I don't find examples that make use of a lexer written with Alex.
>
> Should I write a lexer using only the Alex basic interface (without
> wrappers)?
>
>
>
> Thanks   Manlio Perillo
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Manlio,

You may be better off separating the parsing from the import process. You 
would first parse it in to internal data structures (including an option for 
import) then go through that and replace import statements with the parsed 
content of those files. Producing a list which is then consumed by an IO 
procedure is almost exactly equivalent to threading IO through the entire 
parser and is a lot tidier, more flexible and should be easier to maintain.

Cheers,

Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: Data.IVar 0.1

[Luke Palmer]

Several very elegant FRP approaches are emerging, most visibly FRP.Reactive,
which rely on blocking on multiple variables at once, continuing when the
*first* of them is available. . . inside an unsafePerformIO, so the
beautiful STM "orElse" solution is not available.  The current solution is
to race threads against each other, and have the one that finishes first
kill the other one.  This is implemented, for example, in Data.Unamb.
 However, our empirical tests have shown that the GHC scheduler is not
*quite* good enough to handle this efficiently, and ends up introducing too
much latency and nondeterminacy.

The 
Data.IVarmodule,
just uploaded to hackage, provides an alternative to thread racing
as a solution to this problem.  It provides *write-once* variables which can
be blocked on in parallel, without forking any threads or using STM (so it
is safe to use in unsafePerformIO).Example usage from the documentation:

import qualified Data.IVar as IVar
import Control.Concurrent

main = do
   iv <- IVar.new
   iv' <- IVar.new
   forkIO $ threadDelay 1000 >> writeIVar iv' "my spoon is too big"
   let merger = IVar.read iv `mplus` IVar.read iv'
   print =<< IVar.nonblocking merger   -- most likely "Nothing"
   print =<< IVar.blocking merger  -- waits a while, then prints
   writeIVar iv' "i am a banana"   -- throws error "IVar written twice"

Enjoy!

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[David Menendez]

On Mon, Oct 6, 2008 at 4:48 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> Andrew Coppin wrote:
>>
>> I have some longwinded code that works, but I'm still thinking about how
>> to do this more elegantly. It looks like what I really need is something
>> like
>>
>>  type M = StateT State (ResultSetT (ErrorT ErrorType Identity))
>>
>> Is that the correct ordering?

Pretty much.

> For reference, I humbly present ResultSet.hs:

There are actually several ways to make ResultSetT from ResultSet,
depending on how you want to handle the inner monad. There are two
popular ways to make a transformer variant of [], of which the easier
looks something like this:

newtype ListT m a = ListT { unListT :: m (Stream m a) }
data Stream m a = Nil | Cons a (m (Stream m a))

Using that and your code as a pattern, I've come up with the guts of a
similar transformer, included below. Like your code, it maintains a
list of answers at each depth. The effects of each depth are deferred
until some code (e.g., to_list) demands it, but the effects associated
with any answer at a given depth are linked. The resulting code, I
imagine, is not very efficient, but it shouldn't be too awful. I've
tried to keep things structurally similar to your code, to hopefully
make it clearer what is happening.

I also recommend trying alternatives like Oleg's FBackTrackT. In that
code, "mplus" corresponds to "union".





import Control.Monad

newtype ResultSetT m a = Pack { unpack :: m (Stream m a) }

data Stream m a = Nil | Cons [a] (m (Stream m a))

-- this is just the important parts, the rest should be fairly straightforward.

raw_lift :: (Monad m) => m a -> m (Stream m a)
raw_lift = liftM (\x -> Cons [x] (return Nil))

raw_union :: (Monad m) => Stream m a -> Stream m a -> Stream m a
raw_union Nil yss = yss
raw_union xss Nil = xss
raw_union (Cons xs xss) (Cons ys yss) = Cons (xs ++ ys) (liftM2
raw_union xss yss)


raw_bind :: (Monad m) => m (Stream m a) -> (a -> m (Stream m b)) -> m
(Stream m b)
raw_bind xss f = xss >>= work (return Nil)
where
work out Nil = out
work out (Cons xs xss) = do
yss <- foldr (liftM2 raw_union) out $ map f xs
return undefined
case yss of
Nil -> return $ Cons [] (xss >>= work (return Nil))
Cons ys yss -> return $ Cons ys (xss >>= work yss)


from_list :: (Monad m) => [[a]] -> ResultSetT m a
from_list = Pack . foldr (\xs xss -> return $ Cons xs xss) (return Nil)

to_list :: (Monad m) => ResultSetT m a -> m [[a]]
to_list (Pack m) = m >>= work
where
work Nil = return [[]]
work (Cons xs xss) = liftM (xs:) (xss >>= work)

limit :: (Monad m) => Int -> ResultSetT m a -> ResultSetT m a
limit n (Pack xss) = Pack (xss >>= work n)
where
work n (Cons xs xss) | n > 0 = return $ Cons xs (xss >>= work (n-1))
work _ _ = return Nil

-- 
Dave Menendez <[EMAIL PROTECTED]>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[Daniel Fischer]

Am Dienstag, 7. Oktober 2008 23:38 schrieb David Menendez:
> On Tue, Oct 7, 2008 at 5:07 PM, Daniel Fischer <[EMAIL PROTECTED]> 
wrote:
> > Am Dienstag, 7. Oktober 2008 22:09 schrieb Andrew Coppin:
> >> Daniel Fischer wrote:
> >> > Maybe it is as simple as
> >> >
> >> > raw_bind (xs:xss) f = do
> >> >  rsYs <- mapM f xs
> >> >  ~rsZ <- raw_bind xss f
> >> >  return (foldr union (cost rsZ) rsYs)
> >> >
> >> > then rsZ should only be evaluated when it's needed
> >>
> >> Ooo... "lazy pattern matching"? Can somebody explain to me, _very
> >> slowy_, exactly what that means?
>
> 
>
> >> If I'm not mistaken, the rsZ variable shouldn't be evaluated until
> >> needed *anyway*, so what is lazy pattern matching buying me here?
> >
> > That depends on how your Monad (and union) is implemented, it may or may
> > not make a difference. I must admit that I didn't really look at the code
> > you posted, so I don't know what would be the case here. It was just an
> > easy thing to try which *might* help.
>
> Unless you're pattern matching against a constructor, which rsZ is
> not, I think lazy pattern matching is no different from regular
> pattern matching.

I think you're right, I was being stupid. Oh, well, it's late here
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Linux binary dist problems

[Colin Fleming]

Ok, I tried nix but I couldn't get it to work. Initially I had a problem
since I was trying to get nix to install in my home directory and on the
host (Dreamhost) that's actually a symlink, which nix doesn't allow. Then
once I got it installed finally it didn't build - I can't remember the
details exactly. I then tried to generate hc files for 6.6.1 to install that
to bootstrap from, but I couldn't get ghc to build those on my machine -
looking around it seems to have a lot of problems building on Leopard. My
last resort is now to install Ubuntu in VMWare, install ghc, then generate
the hc files on that, get those on my host, bootstrap from that, and then
build 6.8.3 from source.

As an aside, is there any reason the tar of the hc files isn't available for
download for versions that support it? It would make this a lot easier.

Cheers,
Colin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[David Menendez]

On Tue, Oct 7, 2008 at 5:07 PM, Daniel Fischer <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 7. Oktober 2008 22:09 schrieb Andrew Coppin:
>> Daniel Fischer wrote:
>> > Maybe it is as simple as
>> >
>> > raw_bind (xs:xss) f = do
>> >  rsYs <- mapM f xs
>> >  ~rsZ <- raw_bind xss f
>> >  return (foldr union (cost rsZ) rsYs)
>> >
>> > then rsZ should only be evaluated when it's needed
>>
>> Ooo... "lazy pattern matching"? Can somebody explain to me, _very
>> slowy_, exactly what that means?

>> If I'm not mistaken, the rsZ variable shouldn't be evaluated until
>> needed *anyway*, so what is lazy pattern matching buying me here?
>
> That depends on how your Monad (and union) is implemented, it may or may not
> make a difference. I must admit that I didn't really look at the code you
> posted, so I don't know what would be the case here. It was just an easy
> thing to try which *might* help.

Unless you're pattern matching against a constructor, which rsZ is
not, I think lazy pattern matching is no different from regular
pattern matching.

-- 
Dave Menendez <[EMAIL PROTECTED]>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] newbie questions (read, etc., with Data.ByteString.Lazy.Char8)

[George Pollard]

On Mon, 2008-10-06 at 21:06 -0500, Mike Coleman wrote:
> There's a readInt method, which I guess I could use, but it returns a
> Maybe, and I don't see how I can easily strip that off.

You can use Data.Maybe's 'mapMaybe' function
"The mapMaybe function is a version of map which can throw out elements.
In particular, the functional argument returns something of type Maybe
b. If this is Nothing, no element is added on to the result list. If it
just Just b, then b is included in the result list."


So we change this:
> -- lazy version (doesn't compile)
> 
> -- file: ch08/SumFile.hs
> 
> import qualified Data.ByteString.Lazy.Char8 as L
> 
> main = do
>  contents <- L.getContents
>  print (sumFile contents)
>  where sumFile = sum . map read . L.words

To this:
import qualified Data.ByteString.Lazy.Char8 as B
import Data.Maybe (mapMaybe)

main = do
contents <- B.getContents
print (sumFile contents)
where sumFile = sum . map fst . mapMaybe B.readInt . B.words

Now, there is  a problem with this; the original version will not
read integers that are followed by garbage, whereas this one will.
The difference is between readInt and read:

(read "2a") will fail,
(readInt "2a") will return Just (2,"a")

readInt is really designed with parsers in mind. So, we need to filter
out anything readInt returns with a non-empty string in the right part
of the tuple. Ending up with this:

sumFile = sum . map fst . filter (B.null . snd) . mapMaybe B.readInt . B.words

Actually, after saying this, the original version probably
just dies when given garbage :P


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[Daniel Fischer]

Am Dienstag, 7. Oktober 2008 22:09 schrieb Andrew Coppin:
> Daniel Fischer wrote:
> > Am Dienstag, 7. Oktober 2008 20:27 schrieb Andrew Coppin:
> >> Basically, the core code is something like
> >>
> >>   raw_bind :: (Monad m) => [[x]] -> (x -> m (ResultSet y)) -> m
> >> (ResultSet y)
> >>   raw_bind [] f = return empty
> >>   raw_bind (xs:xss) f = do
> >> rsYs <- mapM f xs
> >> rsZ <- raw_bind xss f
> >> return (foldr union (cost rsZ) rsYs)
> >>
> >> As you can see, this generates all of rsZ before attempting to return
> >> anything to the caller. And I'm really struggling to see any way to
> >> avoid that.
> >
> > Maybe it is as simple as
> >
> > raw_bind (xs:xss) f = do
> >  rsYs <- mapM f xs
> >  ~rsZ <- raw_bind xss f
> >  return (foldr union (cost rsZ) rsYs)
> >
> > then rsZ should only be evaluated when it's needed
>
> Ooo... "lazy pattern matching"? Can somebody explain to me, _very
> slowy_, exactly what that means?
>
> If I'm doing this right, it seems that
>
>   rsZ <- raw_bind xss f
>   ...
>
> desugards to
>
>   raw_bind xss f >>= \rsZ -> ...
>
> If I'm not mistaken, the rsZ variable shouldn't be evaluated until
> needed *anyway*, so what is lazy pattern matching buying me here?

That depends on how your Monad (and union) is implemented, it may or may not 
make a difference. I must admit that I didn't really look at the code you 
posted, so I don't know what would be the case here. It was just an easy 
thing to try which *might* help.
I will take a look, can't guarantee any result.

>
> Also, suppose I stack ResultSetT on top of IO. In that case, "f" is
> allowed to perform externally-visible I/O operations. If there really
> *is* a way to delay the execution of certain calls until the data is
> needed... well that doesn't look right somehow. In fact, it looks like
> what I'm trying to do *should* be impossible. :-/ Oh dear...

To delay computations in IO until needed, you can use unsafeInterleaveIO:


uiSeq :: [IO Int] -> IO [Int]
uiSeq [] = do
putStrLn "End of list"
return []
uiSeq (a:as) = do
x <- a
putStrLn $ "got the value " ++ show x
xs <- unsafeInterleaveIO $ uiSeq as
return (x:xs)

verbRet :: Int -> IO Int
verbRet k = do
putStrLn $ "Returning " ++ show k
return k

*Main> fmap (take 3) $ uiSeq [verbRet k | k <- [1 .. 10]]
Returning 1
got the value 1
[1Returning 2
got the value 2
,2Returning 3
got the value 3
,3]
*Main> fmap (take 3) $ sequence [verbRet k | k <- [1 .. 10]]
Returning 1
Returning 2
Returning 3
Returning 4
Returning 5
Returning 6
Returning 7
Returning 8
Returning 9
Returning 10
[1,2,3]

But unsafeInterleaveIO doesn't have its first six letters without a reason, so 
be careful when you want to use it (in general, don't).
And of course you can't use it in generic monad transformer code, you might 
however be able to use

class Monad m => LazyMonad m where
lazyBind :: m a -> (a -> m b) -> m b
lazySequence :: [m a] -> m [a]

instance LazyMonad IO where
lazyBind  ma f = do
a <- unsafeInterleaveIO ma
f a
lazySequence [] = return []
lazySequence (a:as) = do
x <- a
xs <- unsafeInterleaveIO $ lazySequence as
return (x:xs)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[Andrew Coppin]

Daniel Fischer wrote:

Am Dienstag, 7. Oktober 2008 20:27 schrieb Andrew Coppin:
  

Basically, the core code is something like

  raw_bind :: (Monad m) => [[x]] -> (x -> m (ResultSet y)) -> m
(ResultSet y)
  raw_bind [] f = return empty
  raw_bind (xs:xss) f = do
rsYs <- mapM f xs
rsZ <- raw_bind xss f
return (foldr union (cost rsZ) rsYs)

As you can see, this generates all of rsZ before attempting to return
anything to the caller. And I'm really struggling to see any way to
avoid that.




Maybe it is as simple as

raw_bind (xs:xss) f = do
 rsYs <- mapM f xs
 ~rsZ <- raw_bind xss f
 return (foldr union (cost rsZ) rsYs)

then rsZ should only be evaluated when it's needed
  


Ooo... "lazy pattern matching"? Can somebody explain to me, _very 
slowy_, exactly what that means?


If I'm doing this right, it seems that

 rsZ <- raw_bind xss f
 ...

desugards to

 raw_bind xss f >>= \rsZ -> ...

If I'm not mistaken, the rsZ variable shouldn't be evaluated until 
needed *anyway*, so what is lazy pattern matching buying me here?


Also, suppose I stack ResultSetT on top of IO. In that case, "f" is 
allowed to perform externally-visible I/O operations. If there really 
*is* a way to delay the execution of certain calls until the data is 
needed... well that doesn't look right somehow. In fact, it looks like 
what I'm trying to do *should* be impossible. :-/ Oh dear...

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Cabal: error on configure

[Don Stewart]

dlb:
> OK, I suspect this is a real newbie error, but please have mercy.  I have 
> downloaded and installed cabal (at least it responds to the --help command 
> from the command line).  Yet when I do, say (to give a real example):
> 
> cabal configure parameterized_ data
> 
> (having done he fetch)  I get this error:
> 
> cabal.exe: Using 'build-type" Custom' but there is no Setup.hs or 
> Setup.lhs script.'
> 
> When I download the package manually and look, there is a perfectly 
> servicable Setup.hs script, which I call manually.
> 
> So what gives?
> 
> Dave Barton 

$ cabal update
Downloading package list from server
'http://hackage.haskell.org/packages/archive'

$ cabal install parameterized-data
Downloading parameterized-data-0.1.3...
Configuring parameterized-data-0.1.3...
Preprocessing library parameterized-data-0.1.3...
Building parameterized-data-0.1.3...
[1 of 2] Compiling Data.Param.FSVec ( src/Data/Param/FSVec.hs,
dist/build/Data/Param/FSVec.o )
[2 of 2] Compiling Data.Param   ( src/Data/Param.hs,
dist/build/Data/Param.o )
/usr/bin/ar: creating dist/build/libHSparameterized-data-0.1.3.a
Installing library in
/home/dons/.cabal/lib/parameterized-data-0.1.3/ghc-6.8.2
Registering parameterized-data-0.1.3...
Reading package info from "dist/installed-pkg-config" ... done.
Saving old package config file... done.
Writing new package config file... done.

Looks ok to me?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Cabal: error on configure

[David Barton]

OK, I suspect this is a real newbie error, but please have mercy.  I have 
downloaded and installed cabal (at least it responds to the --help command 
from the command line).  Yet when I do, say (to give a real example):


cabal configure parameterized_ data

(having done he fetch)  I get this error:

cabal.exe: Using 'build-type" Custom' but there is no Setup.hs or Setup.lhs 
script.'


When I download the package manually and look, there is a perfectly 
servicable Setup.hs script, which I call manually.


So what gives?

Dave Barton 


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[Daniel Fischer]

Am Dienstag, 7. Oktober 2008 20:27 schrieb Andrew Coppin:
> The good news: I managed to turn ResultSet into a monad transformer.
> Yay, me!
>
> The bad news: It generates the entire result set before returning
> anything to the caller.
>
> In other words, it works perfectly for finite result sets, and locks up
> forever on infinite result sets. Since the entire *point* of the monad
> is to handle infinite result sets correctly, that's kind-of a problem.
> And one that I see absolutely no way of fixing. :-(
>
> Basically, the core code is something like
>
>   raw_bind :: (Monad m) => [[x]] -> (x -> m (ResultSet y)) -> m
> (ResultSet y)
>   raw_bind [] f = return empty
>   raw_bind (xs:xss) f = do
> rsYs <- mapM f xs
> rsZ <- raw_bind xss f
> return (foldr union (cost rsZ) rsYs)
>
> As you can see, this generates all of rsZ before attempting to return
> anything to the caller. And I'm really struggling to see any way to
> avoid that.
>

Maybe it is as simple as

raw_bind (xs:xss) f = do
 rsYs <- mapM f xs
 ~rsZ <- raw_bind xss f
 return (foldr union (cost rsZ) rsYs)

then rsZ should only be evaluated when it's needed
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[Andrew Coppin]

The good news: I managed to turn ResultSet into a monad transformer. 
Yay, me!


The bad news: It generates the entire result set before returning 
anything to the caller.


In other words, it works perfectly for finite result sets, and locks up 
forever on infinite result sets. Since the entire *point* of the monad 
is to handle infinite result sets correctly, that's kind-of a problem. 
And one that I see absolutely no way of fixing. :-(


Basically, the core code is something like

 raw_bind :: (Monad m) => [[x]] -> (x -> m (ResultSet y)) -> m 
(ResultSet y)

 raw_bind [] f = return empty
 raw_bind (xs:xss) f = do
   rsYs <- mapM f xs
   rsZ <- raw_bind xss f
   return (foldr union (cost rsZ) rsYs)

As you can see, this generates all of rsZ before attempting to return 
anything to the caller. And I'm really struggling to see any way to 
avoid that.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Network.URI bug? (2.2.0.0)

[Bárður Árantsson]

Bárður Árantsson wrote:
> Hi all,
> 
[--snip--]

*Smacks forehead*

Apparently you absolutely need a trailing slash on the relative URIs.
So

  base = fromJust $ parseURI "http://localhost:9000";
  d1 = fromJust $ parseRelativeReference "d1/"
  d2 = fromJust $ parseRelativeReference "d2/"

  ...
  let u = base
  let u1 = fromJust $ d1 `relativeTo` base
  let u2 = fromJust $ d2 `relativeTo` u1

works as expected.

Apologies for the noise.

Cheers,

-- 
Bardur Arantsson
<[EMAIL PROTECTED]>

- You can't expect to wield supreme executive power just because
some watery tart threw a sword at you.
 Dennis / Monty Python and the Holy Grail

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Network.URI bug? (2.2.0.0)

[Bárður Árantsson]

Hi all,

I'm having a bit of difficulty with Network.URI -- unless I
misunderstand the documentation, the attached demo program is supposed
to produce:

   http://localhost:9000
   http://localhost:9000/d1
   http://localhost:9000/d1/d2

but it produces

   http://localhost:9000
   http://localhost:9000/d1
   http://localhost:9000/d2

Is this some sort of bug or am I not understanding the documentation
correctly?

Cheers,

-- 
Bardur Arantsson
<[EMAIL PROTECTED]>

The thing that's depressing about tennis is that no matter how
good I get, I'll never be as good as a wall.
Mitch Hedberg
import Network.URI
import Data.Maybe

base = fromJust $ parseURI "http://localhost:9000";
d1 = fromJust $ parseRelativeReference "d1"
d2 = fromJust $ parseRelativeReference "d2"

main :: IO ()
main = do
  let u = base
  let u1 = fromJust $ d1 `relativeTo` base
  let u2 = fromJust $ d2 `relativeTo` u1
  print $ u
  print $ u1
  print $ u2

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Random question

[Brent Yorgey]

On Tue, Oct 07, 2008 at 06:40:22PM +0100, Iain Barnett wrote:
> On 5 Oct 2008, at 7:06 pm, Henning Thielemann wrote:
>>
>> Instead of separate calls to 'take' and 'drop' you may prefer 'splitAt':
>>
>>  requeue z xs =
>> let (prefix,pivot:suffix) = splitAt (z-1) xs
>> in  prefix ++ suffix ++ [pivot]
>
> Thanks. Took me a while to get the function to shuffle properly again, but
>
> shuffle xs = shuffle' (length xs) xs
>
> shuffle' :: Int -> [a] -> IO [a]
> shuffle' 0 xs = return xs
> shuffle' (len + 1) xs = rand 0 len >>= \r -> shuffle' len $ requeue r xs
> where requeue z ys = let (prefix,pivot:suffix) = splitAt z ys
>  in prefix ++ suffix ++ [pivot]
>
> *Main> shuffle [11..18]
> [14,11,13,16,12,15,18,17]
>
> *Main> shuffle [11..18]
> [16,13,12,11,17,14,18,15]
>
>
> Until I master Quickcheck, that will do for me :)

Using QuickCheck is actually pretty easy.  It's made more difficult in
this particular case since the result of your shuffle function is in
the IO monad.  But assuming you split out the shuffling functionality
into a pureShuffle function which takes a random seed as an extra
parameter, you could make a property to test it as follows:

prop_shuffle :: Seed -> Seed -> [a] -> Bool
prop_shuffle s1 s2 l = sort (pureShuffle s1 l) == sort (pureShuffle s2 l)

Then you could test it by evaluating 'quickCheck prop_shuffle' at a
ghci prompt.  Nice and simple!

-Brent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hoogle? [Stacking monads]

[Andrew Coppin]

Mitchell, Neil wrote:
Well, as I said, replacing one term with another transforms 
one signature into the other. I guess you can't curry type 
constructors as easily as functions - or at least, Hoogle 
currently doesn't like it.



Yes, currying of type constructors is much less common, and entirely
unsupported by Hoogle. Is there a general need for Hoogle to deal with
curried type constructors? I'd not really considered it significantly.
  


And I had just "assumed" this would work. If I ask for a function x -> y 
Hoogle manages to offer my functions like k -> x -> y which can be 
curried to give me the thing I want, I just assumed that an equivilent 
type wouldn't phase it. Ah well.


What *does* Hoogle actually use for matching? Just a 
set of huristics and a metric for how "similar" two 
signatures are so it can order by approximate similarity? 
Or is it something more scientific than that?



It's more scientific than that, see
http://www.wellquite.org/anglohaskell2008/
  


I had a look at your slides. Looks like interesting stuff!

Irritating as it is that Hoogle didn't help me find the function I 
wanted on this occasion, I still think it's really neat that a program 
like Hoogle can actually exist in the first place. And considering that 
with parametric polymorphism, the type signature "almost" tells you what 
the function does... very useful stuff.


For my current troubles, it would be really useful if there were some 
program that you could feed some source code to, and it would tell you 
what the inferred types of each subexpression are. (Ideally it would be 
nice if you could use this on fragments that don't typecheck; being able 
to see what types are being inferred where could help explain why the 
type checker is unhappy, and ultimately where you went wrong. But I'm 
not sure how you could present the internal state in a digestible way.) 
I don't know if anybody has ever attempted such a tool...?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Random question

[Iain Barnett]

On 5 Oct 2008, at 7:06 pm, Henning Thielemann wrote:


Instead of separate calls to 'take' and 'drop' you may prefer  
'splitAt':


 requeue z xs =
let (prefix,pivot:suffix) = splitAt (z-1) xs
in  prefix ++ suffix ++ [pivot]


Thanks. Took me a while to get the function to shuffle properly  
again, but


shuffle xs = shuffle' (length xs) xs

shuffle' :: Int -> [a] -> IO [a]
shuffle' 0 xs = return xs
shuffle' (len + 1) xs = rand 0 len >>= \r -> shuffle' len $ requeue r xs
where requeue z ys = let (prefix,pivot:suffix) = splitAt z ys
 in prefix ++ suffix ++ [pivot]

*Main> shuffle [11..18]
[14,11,13,16,12,15,18,17]

*Main> shuffle [11..18]
[16,13,12,11,17,14,18,15]


Until I master Quickcheck, that will do for me :)



However, accessing list elements by index is pretty inefficient  
(linear time with respect to index). Is it possible to re-arrange  
the algorithm? Maybe using more efficient data structures?




Perhaps an array? I've not investigated any of the other list-like  
data structures in Haskell yet. I'll only be using it to try and  
create a few simple games in the beginning, cards and the like, so  
the performance aspect isn't high on the list (yet) due to the small  
sets being shuffled. Just trying to get things to work first!



Iain
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] After upgrade bytestring to 0.9.1.3, my program cannot run.

[Duncan Coutts]

On Mon, 2008-10-06 at 20:21 -0700, Don Stewart wrote:
> magicloud.magiclouds:
> > Just a simple text process program. When I runhaskell it. I got:
> > 
> > GHCi runtime linker: fatal error: I found a duplicate definition for symbol
> >   fps_minimum
> > whilst processing object file
> >   ~/.cabal/lib/bytestring-0.9.1.3/ghc-6.8.3/HSbytestring-0.9.1.3.o

> Or try compiling it , with ghc --make

The reason is that while the Haskell code uses versioned linker symbols,
the C code in the bytestring library does not. That means both versions
define fps_minimum and a few other functions.

The system linker does not care and just picks one. The GHCi linker is
more picky and complains when two object files define the same linker
symbol. That's why you get the problem with GHCi and not ghc --make.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Darcs / Git

[Miguel Mitrofanov]

Yes, I've used SSH key. Didn't think it would be different with a  
password.


On 7 Oct 2008, at 20:19, Mitchell, Neil wrote:





I use darcs on Windows every day and it works well. The

only problem

is that it is not very usable if you access your repository via SSH
and the authentication is via password.


Why not? It worked fine for me.


It's never worked for me, I always get a frozen darcs trying to read a
password, but not from my console.

If you connect with an SSH key its more secure and less typing -  
it's a

better way to go.

Thanks

Neil

= 
= 
= 
= 
= 
= 
= 
= 
==
Please access the attached hyperlink for an important electronic  
communications disclaimer:


http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
= 
= 
= 
= 
= 
= 
= 
= 
==


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Inferred type is less polymorphic than expected, depends on order

[Jason Dagit]

On Tue, Oct 7, 2008 at 8:02 AM, apfelmus <[EMAIL PROTECTED]> wrote:

> Jason Dagit wrote:
> > Ryan Ingram wrote:
> >> Jason Dagit wrote:
> >>> \begin{code}
> >>> badOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q
> >>> x))
> >>> badOrder sx sy = case sy of
> >>>  Sealed y -> case sx of
> >>>  Sealed x -> Sealed (f x y)
> >>> \end{code}
> >>>
> >>> \begin{code}
> >>> goodOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q
> >>> x))
> >>> goodOrder sx sy = case sx of
> >>>   Sealed x -> case sy of
> >>>   Sealed y -> Sealed (f x y)
> >>> \end{code}
> >> It may help if you transform this a bit closer to System F with
> >> existentials & datatypes:
> >> /\ = forall
> >
> >
> > Why is useful to replace forall with /\?
>
> Actually, the  forall's  should be left alone, the big lambda /\ lives
> on the value level, not the type level :) But this small typo aside,
> making all type applications explicit is the right thing to do to see
> what's going on.
>
> In the original System F - the basis for Haskell's type system -
>
>  http://en.wikipedia.org/wiki/System_F


Thanks, I'll be reading up on that.


>
>
> all type applications are explicit. For instance
>
>  id 'c'in Haskell
>
> would be written
>
>  id Char 'c'   in System F
>
> the type is an explicit argument to a polymorphic function. The
> definition of  id  would be
>
>  id : ∀a. a -> a
>  id = Λa.λx:a.x
>
> So, first supply the type and then compute something. In Haskell, the
> compiler figures out which type argument to apply where and this can get
> confusing like in Jason's example.


Ah, okay, so this rule of first supplying the type is what keeps my example
from being confusing about the order of @y.  That makes a lot of sense.


>
>
> (By the way, I found the "Proofs and Types" book references in the
> wikipedia page to be a very readable introduction to System F and the
> Curry-Howards isomorphism in general.)


Okay, thanks.


>
>
>
> In System F, the example reads as follows (for clarity, we prefix type
> variables with an @ when they are applied)
>
>  foo : ∀p,q,x,y,z.p x y -> q y z -> q x z
>  foo = ...
>
>  goodOrder : ∀p,q,x.
>Sealed (p x)
>-> (∀b.Sealed (q b))
>-> Sealed (q x)
>  goodOrder = Λp.Λq.Λx. λsx:Sealed (p x).λsy:(∀b.Sealed (q b)).
>  case sx of
> Sealed @y (pxy:p x y) -> case sy @y of
>Sealed @z (qyz:q y z) ->
>   Sealed @z (foo @p @q @x @y @z pxy qyz)
>
>  badOrder  : ...
>  badOrder  = Λp.Λq.Λx. λsx:Sealed (p x).λsy:(∀b.Sealed (q b)).
>  case sy ??? of
> Sealed @z (qyz:q ??? z) -> case sx of
>Sealed @y (pxy:p x y) ->
>   Sealed @z (foo @p @q @x @y @z pxy qyz)
>

Thanks, that's quite illustrative.

In the second case, there's no way to know what type to choose for  b
> unless you evaluate  sx  first. However, the following would work:
>
>  badOrder  : ∀p,q,x.
>   Sealed (p x)
>-> (Sealed (∀b. q b))
>-> Sealed (q x)
>  badOrder  = Λp.Λq.Λx. λsx:Sealed (p x).λsy:(Sealed (∀b.q b)).
>  case sy of
> Sealed @z (qyz:∀b.q b z) -> case sx of
>Sealed @y (pxy:p x y) ->
>   Sealed @z (foo @p @q @x @y @z pxy (qyz @y))
>
> In other words,  (Sealed (∀b.q b)) and  (∀b.Sealed (q b)) are quite
> different types. But this is not surprising. After all, this "Sealed"
> thing is the existential quantifier


Oh right, but yes this changes things considerably.  I think your point with
this example is that this more closely matches my expectation, but I know
from experience and your explanation that this is not what I want.
Therefore, I should accept the behavior I'm seeing from the type checker :)

Thank you,
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inferred type is less polymorphic than expected, depends on order

[Jason Dagit]

On Tue, Oct 7, 2008 at 1:13 AM, Ryan Ingram <[EMAIL PROTECTED]> wrote:

>
> You may think it doesn't matter, because you could instantiate it to
> anything after the fact, but it's possible that the result of the case
> statement depends on the choice of instantiation for sy; consider if
> sy had an additional constraint:
>
> > Sealed (fromInteger) :: forall t. Num t => Sealed ((->) Integer)
>
> Now the result of the case statement is the concrete implementation of
> fromInteger for whatever type it gets instantiated at.


Thanks, I was  indeed hoping to see examples of things that break if the
type checker behaved the way I wanted.

Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Darcs / Git

[Mitchell, Neil]

> > I use darcs on Windows every day and it works well. The 
> only problem 
> > is that it is not very usable if you access your repository via SSH 
> > and the authentication is via password.
> 
> Why not? It worked fine for me.

It's never worked for me, I always get a frozen darcs trying to read a
password, but not from my console.

If you connect with an SSH key its more secure and less typing - it's a
better way to go.

Thanks

Neil

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Darcs / Git

[Miguel Mitrofanov]

On 7 Oct 2008, at 12:11, Krasimir Angelov wrote:


I use darcs on Windows every day and it works well. The only problem
is that it is not very usable if you access your repository via SSH
and the authentication is via password.


Why not? It worked fine for me.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type classes question

[Bulat Ziganshin]

Hello Roly,

Tuesday, October 7, 2008, 4:13:25 PM, you wrote:

> I'm reasonably well versed in Haskell but fairly new to defining type classes.

http://haskell.org/haskellwiki/OOP_vs_type_classes may be useful

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Inferred type is less polymorphic than expected, depends on order

[apfelmus]

Jason Dagit wrote:
> Ryan Ingram wrote:
>> Jason Dagit wrote:
>>> \begin{code}
>>> badOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q
>>> x))
>>> badOrder sx sy = case sy of
>>>  Sealed y -> case sx of
>>>  Sealed x -> Sealed (f x y)
>>> \end{code}
>>>
>>> \begin{code}
>>> goodOrder :: (Sealed (p x)) -> (forall b. (Sealed (q b))) -> (Sealed (q
>>> x))
>>> goodOrder sx sy = case sx of
>>>   Sealed x -> case sy of
>>>   Sealed y -> Sealed (f x y)
>>> \end{code}
>> It may help if you transform this a bit closer to System F with
>> existentials & datatypes:
>> /\ = forall
> 
> 
> Why is useful to replace forall with /\?

Actually, the  forall's  should be left alone, the big lambda /\ lives
on the value level, not the type level :) But this small typo aside,
making all type applications explicit is the right thing to do to see
what's going on.

In the original System F - the basis for Haskell's type system -

  http://en.wikipedia.org/wiki/System_F

all type applications are explicit. For instance

  id 'c'in Haskell

would be written

  id Char 'c'   in System F

the type is an explicit argument to a polymorphic function. The
definition of  id  would be

  id : ∀a. a -> a
  id = Λa.λx:a.x

So, first supply the type and then compute something. In Haskell, the
compiler figures out which type argument to apply where and this can get
confusing like in Jason's example.

(By the way, I found the "Proofs and Types" book references in the
wikipedia page to be a very readable introduction to System F and the
Curry-Howards isomorphism in general.)


In System F, the example reads as follows (for clarity, we prefix type
variables with an @ when they are applied)

  foo : ∀p,q,x,y,z.p x y -> q y z -> q x z
  foo = ...

  goodOrder : ∀p,q,x.
Sealed (p x)
-> (∀b.Sealed (q b))
-> Sealed (q x)
  goodOrder = Λp.Λq.Λx. λsx:Sealed (p x).λsy:(∀b.Sealed (q b)).
  case sx of
 Sealed @y (pxy:p x y) -> case sy @y of
Sealed @z (qyz:q y z) ->
   Sealed @z (foo @p @q @x @y @z pxy qyz)

  badOrder  : ...
  badOrder  = Λp.Λq.Λx. λsx:Sealed (p x).λsy:(∀b.Sealed (q b)).
  case sy ??? of
 Sealed @z (qyz:q ??? z) -> case sx of
Sealed @y (pxy:p x y) ->
   Sealed @z (foo @p @q @x @y @z pxy qyz)

In the second case, there's no way to know what type to choose for  b
unless you evaluate  sx  first. However, the following would work:

  badOrder  : ∀p,q,x.
   Sealed (p x)
-> (Sealed (∀b. q b))
-> Sealed (q x)
  badOrder  = Λp.Λq.Λx. λsx:Sealed (p x).λsy:(Sealed (∀b.q b)).
  case sy of
 Sealed @z (qyz:∀b.q b z) -> case sx of
Sealed @y (pxy:p x y) ->
   Sealed @z (foo @p @q @x @y @z pxy (qyz @y))

In other words,  (Sealed (∀b.q b)) and  (∀b.Sealed (q b)) are quite
different types. But this is not surprising. After all, this "Sealed"
thing is the existential quantifier

  Sealed f = ∃x.f x

and both types read

  Sealed (∀b.q b) = ∃x.∀b.q b x
  ∀b.Sealed (q b) = ∀b.∃x.q b x

The latter is broader because it might yield different  x  for different
 b  while the first one has to produce one  x  that works for all  b  at
once. Here's an example for natural numbers that illustrates the difference:

  ∀m.∃n.n > m  -- we can always find a larger number (sure, use n=m+1)
  ∃n.∀m.n > m  -- we can find a number larger than all the others!




Regards,
apfelmus

PS: The wikibook has a chapter

  http://en.wikibooks.org/wiki/Haskell/Polymorphism

that is intended to explain and detail such issues and the translation
from Haskell to System F, but it's currently rather empty.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Darcs / Git

[Thomas Schilling]

GHC uses http://darcs.haskell.org/bin/darcs-to-git which is a fork of
http://github.com/purcell/darcs-to-git

It's not very fast, but it works well enough.  I tried tailor only
briefly but it failed on its own test suite and I didn't bother to
investigate any further.

2008/10/6 Dominic Steinitz <[EMAIL PROTECTED]>:
> Not really a Haskell question but I'm not sure where else to go.
>
> What's the preferred method of converting a darcs repository to git? And
> is there a way of converting from git to darcs?
>
> The reason I ask is that my colleague cannot get darcs to work on his
> Windows box.
>
> Thanks, Dominic.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: New System.Process

[Simon Marlow]

john lask wrote:


Something that has irked me in the past about System.Process is the inability 
to obtain an OS system handle from the haskell Process handle. Such a facility 
would greatly enhance the interoperabity of c and haskell libraries.

Provision is made (although not standardised) to obtain OS specific handles 
from haskell File Handles which is very useful. The same should be provided for 
Haskell Process handles. The main barrier to such a facility is the variability 
between OS representations of such a type (aka windows Handles, unix PID).

comments anyone.


You can get at the underlying process handle using 
System.Process.Internals, but that's not a documented interface of 
course.  If you really need to do OS-specific stuff, I suggest using 
System.Posix or System.Win32 instead.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type classes question

[Ryan Ingram]

On Tue, Oct 7, 2008 at 1:13 PM, Roly Perera
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm reasonably well versed in Haskell but fairly new to defining type classes.
> In particular I don't really understand how to arrange for all instances of X
> to also be instances of Y.
>
> It's quite possibly that my question is ill-posed, so I'll make it as concrete
> as possible: in the following code, I define a Stream class, with two
> instances, Stream1 and Stream2.  How do I arrange for there to be one
> implementation of Functor's fmap for all Stream instances?  I currently rely 
> on
> delegation, but in the general case this isn't nice.

With your current implementation, you can't.  You get lucky because
all of your instance declarations are of the form
> instance Stream (X a) a
for some type X.

But it's just as possible to say

> newtype Stream3 = S3 [Int]

> instance Stream Stream3 Int where
>   first (S3 xs) = head xs
>   next (S3 xs) = tail xs
>   fby x (S3 xs) = S3 (x:xs)

Now the only valid fmap_ is over functions of type (Int -> Int).

If you really want all your instances to be type constructors, you
should just say so:

> class Stream f where
>first :: f a -> a
>next :: f a -> f a
>fby :: a -> f a -> f a

Now, with this implementation what you want is at least somewhat
possible, but there's a new problem: there's no good way in haskell to
define superclasses or default methods for existing classes.  There is
a standing "class aliases" proposal [1], but nobody has implemented
it.

The current recommended practice is to define a "default" and leave it
to your instances to use it.  It's kind of ugly, but thems the breaks:

> class Functor f => Stream f where -- you said you want all streams to be 
> functors, so enforce it!
>first :: f a -> a
>next :: f a -> f a
>fby :: a -> f a -> f a
>
> fmapStreamDefault f = uncurry fby . both (f . first) (fmap_ f . next)
>
> instance Functor Stream1 where fmap = fmapStreamDefault
> instance Stream Stream1 where
>first (x :< _) = x
>next (_ :< xs) = xs
>fby = (:<)

Here's another possible solution:

> newtype AsFunctor s a = AF { fstream :: (s a) }
> instance (Stream f) => Functor (AsFunctor f) where
> fmap f (AF s) = AF (fmapStreamDefault f s)

Now to use fmap you wrap in AF and unwrap with fstream.

None of the existing solutions are really satisfactory, unfortunately.

   -- ryan

[1] http://repetae.net/recent/out/classalias.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [darcs-users] announcing darcs 2.1.0pre3

[Iain Lane]

On Thu, Oct 2, 2008 at 1:07 PM, Eric Kow <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> The third pre-release of darcs 2.1 is now available at
> http://darcs.net/darcs-2.1.0pre3.tar.gz
> [...]
> --
> Eric Kow 
> PGP Key ID: 08AC04F9
>
> ___
> darcs-users mailing list
> [EMAIL PROTECTED]
> http://lists.osuosl.org/mailman/listinfo/darcs-users
>
>

Hi all,

Packages of this release for Ubuntu Hardy and Intrepid are available
in my PPA at [0]. Bugs with the packaging to me, bugs with Darcs not
to me. ;)

Thanks,
Iain

[0] https://edge.launchpad.net/~laney/+archive
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad transformers [Stacking monads]

[Dougal Stanton]

On Mon, Oct 6, 2008 at 9:48 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> Andrew Coppin wrote:
>>
>> I have some longwinded code that works, but I'm still thinking about how
>> to do this more elegantly. It looks like what I really need is something
>> like
>>
>>  type M = StateT State (ResultSetT (ErrorT ErrorType Identity))
>>
>> Is that the correct ordering?
>>
>> If so, I guess that means I have to somehow construct ResultSetT. Is there
>> an easy way to do that, given that I already have ResultSet? For example, if
>> I put ResultSet into Traversable, would that let me do it?
>
> ...and again I'm talking to myself... :-/
>
> So after much experimentation, I have managed to piece together the
> following facts:
>
> - It appears that the outer-most monad transformer represents the inner-most
> monad. So "StateT Foo ListT" means a list of stateful computations, while
> "ListT (StateT Foo)" means a stateful list of computations.

Have you read "Monad Transformers Step by Step" [1] by Martin
Grabmueller? It's a fantastic introduction to these beasties, leading
the reader through a series of transformations from pure code to using
about 4 different monads/transformers for all sorts of extra features.

Seriously recommend it.

[]: 



Cheers,

D
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Type classes question

[Roly Perera]

Hi,

I'm reasonably well versed in Haskell but fairly new to defining type classes.  
In particular I don't really understand how to arrange for all instances of X 
to also be instances of Y.  

It's quite possibly that my question is ill-posed, so I'll make it as concrete 
as possible: in the following code, I define a Stream class, with two 
instances, Stream1 and Stream2.  How do I arrange for there to be one 
implementation of Functor's fmap for all Stream instances?  I currently rely on 
delegation, but in the general case this isn't nice.

I guess I'm either misunderstanding what it is I'm trying to achieve, or how to 
do this kind of thing in Haskell.  Any help would be greatly appreciated.

many thanks,
Roly Perera



{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, 
ExistentialQuantification, FunctionalDependencies #-}

module Test where

---
-- Just some helpers.
---

-- Product map.
prod :: (a -> b) -> (c -> d) -> (a, c) -> (b, d)
f `prod` g = \(a, c) -> (f a, g c)

-- Diagonal.
diag :: a -> (a, a)
diag x = (x, x)

-- Mediating morphism into the product.
both :: (a -> b) -> (a -> c) -> a -> (b, c)
both f g = prod f g . diag

---
-- "Abstract" stream.
---
class Stream s a | s -> a where
first :: s -> a
next :: s -> s
fby :: a -> s -> s

-- I want every Stream to be a Functor.
fmap_ :: Stream s' b => (a -> b) -> s -> s'
fmap_ f = uncurry fby . both (f . first) (fmap_ f . next)

---
-- Implementation 1.
---
data Stream1 a = a :< Stream1 a

instance Functor Stream1 where
fmap = fmap_

instance Stream (Stream1 a) a where
first (x :< _) = x
next (_ :< xs) = xs
fby = (:<)

---
-- Implementation 2.
---
data Stream2 a = forall b . S b (b -> a) (b -> b)

instance Functor Stream2 where
fmap = fmap_

instance Stream (Stream2 a) a where
first (S x c _) = c x
next (S x c i) = S (i x) c i
fby y s = S (y, s) fst (uncurry (,) . both first next . snd)




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] I'll do USB in Haskell - tips?

[Marc Weber]

>  Thanks,
>  Maurício

Hi Maurício,

that's good news :-)

However I personally would be scared by the amount of work and testing
which is needed. I guess I would prefer wiriting some bindings to a nexisting
library.. But if you manage to write it I might become a user in the
future..

Marc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] newbie questions (read, etc., with Data.ByteString.Lazy.Char8)

[Bulat Ziganshin]

Hello wman,

Tuesday, October 7, 2008, 8:44:48 AM, you wrote:

> btw, why is the example #2
> (http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=ghc&id=2)
> (which kicks collective asses of all other participants) not
> considered in the shootout ? Too much optimizations ?

it's cheating - application code written in low-level style instead of
using library functions (if you will write in the same style in C it
will probably even several times faster)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] newbie questions (read, etc., with Data.ByteString.Lazy.Char8)

[Bulat Ziganshin]

Hello Brandon,

Tuesday, October 7, 2008, 7:59:06 AM, you wrote:

> is there a reason why -O2 shouldn't be made the default (and
> allowing to turn off optimizations by -O0 perhaps) ?

it compiles ~2x slower and firces more recompilation (because it does
inter-module inlining). so it's not perfect for edit-compile-debug
runs


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inferred type is less polymorphic than expected, depends on order

[Ryan Ingram]

On Mon, Oct 6, 2008 at 10:27 PM, Jason Dagit <[EMAIL PROTECTED]> wrote:
> Why is useful to replace forall with /\?

To make it look more like a capital lambda, just like \ is notation
for lambda.  It's a lambda abstraction over a type instead of a value;
that's how polymorphism works in GHC's core language.

>> @t = type application, with the rule:
>>
>> (a :: forall x. b) @t :: (replace occurrences of x in b with t)
>
> How do you know how to apply this rule in general?
>
> For example, (a :: forall x y. x -> y) @t, would mean what?

As written,

(a :: forall x y. x -> y) @t :: (forall y. t -> y)

But it doesn't matter, as you can write:
   /\y. /\x. (a :: forall x y. x -> y) @y @x  :: forall y x. x -> y

which allows you to arbitrarily reorder the foralls; the compiler does
this when it wants to instantiate a variable in the middle of a group
of foralls.

This is similar to
   flip f x y = f y x
which allows you to reorder the arguments of a function.

>> -- the quantified type "x" gets packed into the data
>> -- and comes out when you pattern match on it
>> data Sealed s where
>>Sealed :: /\t. s t -> Sealed s
>
> By 'x' you mean 't' right?

Yes, oops.  Although it doesn't matter because you can rename bound
variables, which is what I did when writing the message; I just forgot
to update the documentation! :)

>> goodOrder = \sx :: Sealed (p x) -> \sy :: (/\b. Sealed (q b)) ->
>>case sx of (Sealed @y pxy) ->
>>case (sy @y) of (Sealed @z qyz) ->
>>Sealed @z (f pxy qyz)
>
> You have the expression (Sealed @y pxy), but I don't understand what that
> signifies.  Are you just saying that by doing a pattern match on 'sx' that
> you're going to bind the existentially quantified variable to 'y'?  This
> notation confuses me, but I can happily accept that we are binding the
> existential type 'y' somewhere.

It's just like any other data constructor/destructor; it's just that
the constructor for Sealed takes an additional argument: the type that
the existential is bound at.  So when you pattern match on it, you get
that type back out.

> Assuming, I understand that, correctly, the expression (Sealed @z qyz) is
> binding 'z' to an existential.  Why do you say, (sy @y).  What does that
> mean?  That makes 'b' unify with 'y' that was bound in the first case?

Yes, that's correct.

> goodOrder works as I expect, so I'm happy with this.
>
>> badOrder = \sx :: Sealed (p x) -> \sy :: (/\b. Sealed (q b)) ->
>>-- in order to pattern-match on sy, we need to give it a type
>>-- so we just pick an arbitrary type "unknown" or "u" distinct
>> from any other type we know about
>>case (sy @u) of (Sealed @z quz) ->
>>case sx of (Sealed @y pxy) ->
>>Sealed @z (f pxy quz) -- doesn't typecheck!
>>
>> In the good order, you have already unpacked the existential for sx,
>> so you know what type to instantiate sy at.  In the bad order, you
>> don't know what type to instantiate sy at.
>
> We instantiate 'u' to be the existential in sy.  OK.  But, my understanding
> is that 'u' is unconstrained at this point, we said, forall b. Sealed (q b),
> afterall.  So, when we bind 'y' in the second case, what prevents 'u' from
> unifying with 'y'?

Sort of, but not exactly.  Here's an example at the value level:

f x = (5 * x, \y -> y + x)

g x = case f x of (v, g) ->
 \y -> (v, g y)

h y = case f ?? of (v, g) ->
 \x -> plug in x to the f above, then (v, g y)

Your "badorder" is similar to h; you have to instantiate the type
variable before you can evaluate the case statement.

You may think it doesn't matter, because you could instantiate it to
anything after the fact, but it's possible that the result of the case
statement depends on the choice of instantiation for sy; consider if
sy had an additional constraint:

> Sealed (fromInteger) :: forall t. Num t => Sealed ((->) Integer)

Now the result of the case statement is the concrete implementation of
fromInteger for whatever type it gets instantiated at.

> For what it's worth, in my real program where this came up, sy was created
> by a recursive call like this:
> foo :: Sealed (p x) -> Sealed (q b)
> foo = do
>   p <- blah
>   q <- foo
>   return (Sealed (f p q))
>
> Because the b doesn't appear on the LHS of the function arrow, I understand
> it to have the same polymorphic properties as the 'forall b.' in the type
> signature of goodOrder and badOrder.  Indeed, this example seems to
> re-enforce that.  We had to reorder the binding of p and q to get this to
> type check.

Yes, that's correct; consider the simpler example of "const"

const :: forall a b. a -> b -> a

foo = const "hello"

which becomes

foo :: forall b. b -> String
foo = /\b. const @String @b "hello"
  = /\b. \x :: b. "hello"

 -- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Darcs / Git

[Krasimir Angelov]

I use darcs on Windows every day and it works well. The only problem
is that it is not very usable if you access your repository via SSH
and the authentication is via password.



On Mon, Oct 6, 2008 at 9:11 PM, Dominic Steinitz
<[EMAIL PROTECTED]> wrote:
> Not really a Haskell question but I'm not sure where else to go.
>
> What's the preferred method of converting a darcs repository to git? And
> is there a way of converting from git to darcs?
>
> The reason I ask is that my colleague cannot get darcs to work on his
> Windows box.
>
> Thanks, Dominic.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Hoogle? [Stacking monads]

[Mitchell, Neil]

> Actually, I was thinking more along the lines of 
> Data.Traversable.sequence, which has
> 
>   sequence :: (Traversable t, Monad m) => t (m a) -> m (t a)
> 
> > Are you expecting c1 (:: * -> * -> *) to unify with [] (:: * -> *)? 
> > That seems kind incorrect at the very last. Additionally, 
> those types 
> > don't look all that close.
> >   
> 
> Well, as I said, replacing one term with another transforms 
> one signature into the other. I guess you can't curry type 
> constructors as easily as functions - or at least, Hoogle 
> currently doesn't like it.

Yes, currying of type constructors is much less common, and entirely
unsupported by Hoogle. Is there a general need for Hoogle to deal with
curried type constructors? I'd not really considered it significantly.

> > But, let's briefly consider unification (and why Hoogle 
> doesn't used 
> > it). Consider the search:
> >
> > Eq a => [(a,b)] -> a -> b
> >
> > What the user wants is lookup, which sadly doesn't unify. However, 
> > undefined unifies perfectly.
> >   
> 
> I see...
> 
> I notice that x -> y doesn't unify with y -> x in any way, 
> shape or form, but Hoogle has absolutely no problem with 
> that.

Hoogle has a problem with it, but not a severe problem. If you use the
command line version you can type --verbose to get a list of the penalty
points Hoogle has applied to a match.

> What *does* Hoogle actually use for matching? Just a 
> set of huristics and a metric for how "similar" two 
> signatures are so it can order by approximate similarity? 
> Or is it something more scientific than that?

It's more scientific than that, see
http://www.wellquite.org/anglohaskell2008/

There will be a paper on Hoogle type matching at some point!

Thanks

Neil

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe