Re: [Haskell-cafe] haddock: parse error in doc string

2009-08-26 Thread Peter Verswyvelen
Ouch, with all the great Haskell parsers like Parsec around I think I was
expecting a line/column number :-)
But I see a ticket is already open for this
http://trac.haskell.org/haddock/ticket/83

http://trac.haskell.org/haddock/ticket/83On Wed, Aug 26, 2009 at 2:47 AM,
Gwern Branwen gwe...@gmail.com wrote:

 On Tue, Aug 25, 2009 at 8:30 PM, Peter Verswyvelenbugf...@gmail.com
 wrote:
  I'm getting the error mentioned in the subject, but without any
 indication
  where in my file this error occurs.
  What does this mean?
  Thanks,
  Peter

 It means exactly that - something in that file's comments is causing
 Haddock to choke. It could be using '*' inside some --s, it could be
 something else. Haddock won't really say. Your best bet is the old
 bisect/binary-search method: remove half the comments  retry,
 narrowing it down until you've found the offending line and then
 character. Then you can either remove it or read the Haddock manual
 and see what the right thing looks like.

 --
 gwern

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


Re: [Haskell-cafe] How to calculate de number of digits of an integer? (was: Is logBase right?)

2009-08-26 Thread Daniel Fischer
Am Mittwoch 26 August 2009 06:29:47 schrieb George Pollard:
 You could also fudge the input:

 {-# LANGUAGE NoMonomorphismRestriction #-}

 log10 = floor . logBase 10 . (0.5+) . fromIntegral

 numDigits n | n  0 = 1 + numDigits (-n)
 numDigits 0 = 1
 numDigits n = 1 + log10 n

 -- checked [0..10^8], finding a counter-example is left as an exercise :P

Prelude numDigits (10^15)
15


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


[Haskell-cafe] Suggestion: define a standard keyboard codes library?

2009-08-26 Thread Peter Verswyvelen
Several libraries define their own codes for they keyboard (GLFW, GTK, GLUT,
etc)
Maybe it would be nice to agree on a standard datatype for keys? This might
also include digital buttons on a joystick, etc...

The Windows API has virtual key codes for this.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Suggestion: define a standard keyboard codes library?

2009-08-26 Thread Yitzchak Gale
Peter Verswyvelen wrote:
 Several libraries define their own codes for they keyboard (GLFW, GTK, GLUT,
 etc)
 Maybe it would be nice to agree on a standard datatype for keys? This might
 also include digital buttons on a joystick, etc...
 The Windows API has virtual key codes for this.

X windows key symbols are used extensively in XMonad.
They are found in the X11 package, in the modules
Graphics.X11.Types and Graphics.X11.ExtraTypes.

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


Re: [Haskell-cafe] Suggestion: define a standard keyboard codes library?

2009-08-26 Thread Peter Verswyvelen
But should we use X11 as the standard library then, even on Windows or Mac?
It surely is better than nothing, but it feels a bit weird to install X11
just for using the key codes.

Maybe splitting these keys into a separate package would be a good idea?


On Wed, Aug 26, 2009 at 12:42 PM, Yitzchak Gale g...@sefer.org wrote:

 Peter Verswyvelen wrote:
  Several libraries define their own codes for they keyboard (GLFW, GTK,
 GLUT,
  etc)
  Maybe it would be nice to agree on a standard datatype for keys? This
 might
  also include digital buttons on a joystick, etc...
  The Windows API has virtual key codes for this.

 X windows key symbols are used extensively in XMonad.
 They are found in the X11 package, in the modules
 Graphics.X11.Types and Graphics.X11.ExtraTypes.

 -Yitz

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


Re: [Haskell-cafe] haddock: parse error in doc string

2009-08-26 Thread David Waern
2009/8/26 Peter Verswyvelen bugf...@gmail.com:
 Ouch, with all the great Haskell parsers like Parsec around I think I was
 expecting a line/column number :-)
 But I see a ticket is already open for this
 http://trac.haskell.org/haddock/ticket/83

Yes, and the line-number part of that ticket has been fixed in 2.4.2
and higher versions. So the best idea is to upgrade Haddock.

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


Re: [Haskell-cafe] haddock: parse error in doc string

2009-08-26 Thread Peter Verswyvelen
Oh, I just installed the Haskell platform.
I have
Haddock version 2.4.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008

But I noticed that my bad comments were in the description of the cabal
file, not the source file.

So that might be a new ticket?

On Wed, Aug 26, 2009 at 1:04 PM, David Waern david.wa...@gmail.com wrote:

 2009/8/26 Peter Verswyvelen bugf...@gmail.com:
  Ouch, with all the great Haskell parsers like Parsec around I think I was
  expecting a line/column number :-)
  But I see a ticket is already open for this
  http://trac.haskell.org/haddock/ticket/83

 Yes, and the line-number part of that ticket has been fixed in 2.4.2
 and higher versions. So the best idea is to upgrade Haddock.

 David

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


Re: [Haskell-cafe] How to calculate de number of digits of an integer? (was: Is logBase right?)

2009-08-26 Thread George Pollard
2009/8/26 Lennart Augustsson lennart.augusts...@gmail.com:
 Try 10^1000
Cheat :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Suggestion: define a standard keyboard codes library?

2009-08-26 Thread Yitzchak Gale
Peter Verswyvelen wrote:
 Several libraries define their own codes for they keyboard
 (GLFW, GTK, GLUT, etc)
 Maybe it would be nice to agree on a standard datatype
 for keys?
 ...The Windows API has virtual key codes for this.

I wrote:
 X windows key symbols...
 are found in the X11 package

 But should we use X11 as the standard library then,
 even on Windows or Mac?

Certainly not. X11 has its own philosophy of key virtualization.
You would likely encounter serious impedance mismatch on
other platforms.

 Maybe splitting these keys into a separate package would
 be a good idea?

No, they are an integral part of X. I would assume the same
is true for WinAPI VKeys, and whatever the corresponding
thing is on the Mac. That probably explains why each
graphics framework defines its own concept of key mapping,
to match its own concept of platform dependence.

Here's an example: suppose you want ^C to be copy in
your app. Well, what if the user currently has a Dvorak
layout - do you really want ^C, or do you want the third
physical key to the right of the left shift key? And what
if the current keyboard layout is Russian - which Cyrillic
letter should be copy? And what if we happen to be on
a mobile device or a tablet? Etc.

Each platform addresses these issues in its own way,
so the concept of a key code doesn't necessarily translate
directly from one to the other.

I don't think that key binding is so complicated that
it's impossible to come up with a reasonable one ring
that binds them all library. But it's not so simple as just
lining up key code charts with one another.

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


Re: [Haskell-cafe] Is it possible to prove type *non*-equality in Haskell?

2009-08-26 Thread Conor McBride

Hi all

Interesting stuff. Thanks for this.

On 26 Aug 2009, at 03:45, Ryan Ingram wrote:


Hi Dan, thanks for the great reply!  Some thoughts/questions follow.

On Tue, Aug 25, 2009 at 3:39 PM, Dan Doeldan.d...@gmail.com wrote:
Well, this isn't surprising; you wouldn't have it even in a more  
rigorous
proof environment. Instead, you'd have to make the return type  
something like


 Either (a == b) (a /= b)


Yes, and as you see I immediately headed in that direction :)


We know by parametricity that contradiction n p isn't inhabited as
its type is (forall a. a)


But in Haskell, we know that it _is_ inhabited, because every type is
inhabited by bottom. And one way to access this element is with  
undefined.


Of course.  But it is uninhabited in the sense that if you case
analyze on it, you're guaranteed not to reach the RHS of the case.
Which is as close to uninhabited as you get in Haskell.


I think that's close enough to make uninhabited a useful
shorthand.

Well, matching against TEq is not going to work. The way you do  
this in Agda,

for instance, is:

 notZeqS :: forall n - Not (TEq Z (S n))
 notZeqS = Contr (\())


Yes, I had seen Agda's notation for this and I think it is quite
elegant.  Perhaps {} as a pattern in Haskell as an extension?


Something of the sort has certainly been suggested before. At
the very least, we should have empty case expressions, with at
least a warning generated when there is a constructor case
apparently possible.

[..]


But right now it
seems that I need to make a separate notEq for each pair of concrete
types, which isn't really acceptable to me.

Can you think of any way to do so?


I think it's likely to be quite tricky, but you might be able
to minimize the burden by adapting an old trick (see my thesis,
or Eliminating Dependent Pattern Matching by Goguen, McBride,
McKinna, or A Few Constructions on Constructors by the same
authors).


Basically what I want is this function:
  notEq :: (compiler can prove a ~ b is unsound) = Not (TEq a b)

Sadly, I think you are right that there isn't a way to write this in
current GHC.


Perhaps it's not exactly what you want, but check this out. I've
used SHE, but I'll supply the translation so you know there's no
cheating.

 {-# OPTIONS_GHC -F -pgmF she #-}
 {-# LANGUAGE GADTs, KindSignatures, TypeOperators, TypeFamilies,  
FlexibleContexts,

 MultiParamTypeClasses, UndecidableInstances, RankNTypes,
 EmptyDataDecls #-}

 module NoConfusion where

Some type theorists call the fact that constructors are injective
and disjoint the no confusion property, and the fact (?) that
they cover the datatype the no junk property. In Haskell, junk
there is, but there is strictly no junk.

 import ShePrelude

 data Nat :: * where
   Z :: Nat
   S :: Nat - Nat
   deriving SheSingleton

The deriving SheSingleton bit makes the preprocessor build the
singleton GADT for Nat. From ShePrelude we have

  type family SheSingleton ty :: * - *

and from the above, we get

  data SheTyZ = SheTyZ
  data SheTyS x1 = SheTyS x1
  type instance SheSingleton (Nat) = SheSingNat
  data SheSingNat :: * - * where
SheWitZ :: SheSingNat  (SheTyZ)
SheWitS :: forall  sha0. SheSingleton (Nat ) sha0 - SheSingNat   
(SheTyS sha0)


Now, let's have

 newtype Naught = Naught {naughtE :: forall a. a}

Thanks to Dave Menendez for suggesting this coding of
the empty type.

 data EQ :: forall (a :: *). {a} - {a} - * where
   Refl :: EQ a a

It may look like I've given EQ a polykind, but after translation,
the forall vanishes and the {a}s become *s. My EQ is just the
usual thing in * - * - *.

OK, here's the trick I learned from Healf Goguen one day
in 1997. Define a type-level function which explains
the consequences of knowing that two numbers are equal.

 type family WhatNatEQProves (m :: {Nat})(n :: {Nat}) :: *
 type instance WhatNatEQProves {Z}{Z}= ()
 type instance WhatNatEQProves {Z}{S n}  = Naught
 type instance WhatNatEQProves {S m}  {Z}= Naught
 type instance WhatNatEQProves {S m}  {S n}  = EQ m n

Those type-level {Z} and {S n} guys just translate to
SheTyZ and (SheTyS n), respectively.

Now, here's the proof I learned from James McKinna, ten
minutes later.

 noConf :: pi (m :: Nat). pi (n :: Nat). EQ m n - WhatNatEQProves m n
 noConf m n Refl = noConfDiag m

 noConfDiag :: pi (n :: Nat). WhatNatEQProves n n
 noConfDiag {Z}   = ()
 noConfDiag {S n} = Refl

This pi (n :: Nat). ... is translated to

  forall n. SheSingleton Nat n - ...

which computes to

  forall n. SheSingNat n - ...

The expression-level {Z} and {S n} translate to
SheWitZ and (SheWitS n), accessing the singleton family.
Preprocessed, we get

  noConf :: forall m . SheSingleton ( Nat) m -  forall n .  
SheSingleton ( Nat) n -  EQ m n - WhatNatEQProves m n

  noConf m n Refl = noConfDiag m

  noConfDiag :: forall n . SheSingleton ( Nat) n -  WhatNatEQProves  
n n

  noConfDiag (SheWitZ)   = ()
  noConfDiag (SheWitS n) = Refl

James's cunning idea was to match on 

Re: [Haskell-cafe] Suggestion: define a standard keyboard codes library?

2009-08-26 Thread Marc Weber
Excerpts from Peter Verswyvelen's message of Wed Aug 26 12:15:14 +0200 2009:
 Maybe it would be nice to agree on a standard datatype for keys? This might
 also include digital buttons on a joystick, etc...

The synergy project (sourceforge) already does some mapping from Windows
- Linux - Mac AFAIK.

It forwards key input to the other system over network.
This could be a source of additional information. However I haven't
looked at the code yet.

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


[Haskell-cafe] Error during hlint install ?

2009-08-26 Thread Dusan Kolar

Hello all,

 Am I doing something wrong if I get the following error during cabal 
installation of hlint? Is there any way how to solve it?


I run on:
Linux pc 2.6.30-ARCH #1 SMP PREEMPT Fri Jul 31 07:30:28 CEST 2009 x86_64 
Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz GenuineIntel GNU/Linux

The Glorious Glasgow Haskell Compilation System, version 6.10.4

Error:
cabal install hlint
Resolving dependencies...
Configuring hlint-1.6.5...
Preprocessing executables for hlint-1.6.5...
Building hlint-1.6.5...
[ 1 of 25] Compiling Paths_hlint  ( 
dist/build/autogen/Paths_hlint.hs, 
dist/build/hlint/hlint-tmp/Paths_hlint.o )
[ 2 of 25] Compiling Parallel ( src/Parallel.hs, 
dist/build/hlint/hlint-tmp/Parallel.o )
[ 3 of 25] Compiling HSE.Generics ( src/HSE/Generics.hs, 
dist/build/hlint/hlint-tmp/HSE/Generics.o )
[ 4 of 25] Compiling HSE.NameMatch( src/HSE/NameMatch.hs, 
dist/build/hlint/hlint-tmp/HSE/NameMatch.o )
[ 5 of 25] Compiling Util ( src/Util.hs, 
dist/build/hlint/hlint-tmp/Util.o )
[ 6 of 25] Compiling HSE.Util ( src/HSE/Util.hs, 
dist/build/hlint/hlint-tmp/HSE/Util.o )
[ 7 of 25] Compiling HSE.Match( src/HSE/Match.hs, 
dist/build/hlint/hlint-tmp/HSE/Match.o )
[ 8 of 25] Compiling HSE.Bracket  ( src/HSE/Bracket.hs, 
dist/build/hlint/hlint-tmp/HSE/Bracket.o )
[ 9 of 25] Compiling HSE.Evaluate ( src/HSE/Evaluate.hs, 
dist/build/hlint/hlint-tmp/HSE/Evaluate.o )
[10 of 25] Compiling HSE.All  ( src/HSE/All.hs, 
dist/build/hlint/hlint-tmp/HSE/All.o )
[11 of 25] Compiling CmdLine  ( src/CmdLine.hs, 
dist/build/hlint/hlint-tmp/CmdLine.o )
[12 of 25] Compiling Type ( src/Type.hs, 
dist/build/hlint/hlint-tmp/Type.o )
[13 of 25] Compiling Hint.Naming  ( src/Hint/Naming.hs, 
dist/build/hlint/hlint-tmp/Hint/Naming.o )
[14 of 25] Compiling Hint.Bracket ( src/Hint/Bracket.hs, 
dist/build/hlint/hlint-tmp/Hint/Bracket.o )
[15 of 25] Compiling Hint.Lambda  ( src/Hint/Lambda.hs, 
dist/build/hlint/hlint-tmp/Hint/Lambda.o )
[16 of 25] Compiling Hint.Monad   ( src/Hint/Monad.hs, 
dist/build/hlint/hlint-tmp/Hint/Monad.o )
[17 of 25] Compiling Hint.ListRec ( src/Hint/ListRec.hs, 
dist/build/hlint/hlint-tmp/Hint/ListRec.o )
[18 of 25] Compiling Hint.List( src/Hint/List.hs, 
dist/build/hlint/hlint-tmp/Hint/List.o )
[19 of 25] Compiling Hint.Match   ( src/Hint/Match.hs, 
dist/build/hlint/hlint-tmp/Hint/Match.o )
[20 of 25] Compiling Settings ( src/Settings.hs, 
dist/build/hlint/hlint-tmp/Settings.o )
[21 of 25] Compiling Report   ( src/Report.hs, 
dist/build/hlint/hlint-tmp/Report.o )


src/Report.hs:49:22:
   Couldn't match expected type `String' against inferred type `Bool'
   In the second argument of `hscolour', namely `True'
   In the expression: hscolour False True 
   In the definition of `code': code = hscolour False True 
cabal: Error: some packages failed to install:
hlint-1.6.5 failed during the building phase. The exception was:
exit: ExitFailure 1


Regards

 Dušan


P.S.
Registered packages:
Cabal-1.6.0.3, HUnit-1.2.0.3, QuickCheck-1.2.0.0, array-0.2.0.0,
   base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1,
   cpphs-1.8, directory-1.0.0.3, (dph-base-0.3), (dph-par-0.3),
   (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3),
   (dph-seq-0.3), extensible-exceptions-0.1.1.0, filepath-1.1.0.2,
   (ghc-6.10.4), ghc-prim-0.1.0.0, haddock-2.4.2, haskell-src-1.0.1.3,
   haskell-src-exts-1.0.1, haskell98-1.0.1.0, hpc-0.5.0.3,
   hscolour-1.15, html-1.0.1.2, integer-0.1.0.1, mtl-1.1.0.2,
   network-2.2.1.2, old-locale-1.0.0.1, old-time-1.0.0.2,
   packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1,
   pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1,
   regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3,
   rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1,
   time-1.1.4, uniplate-1.2.0.3, unix-2.3.2.0, xhtml-3000.2.0.1

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


Re: [Haskell-cafe] How to calculate de number of digits of an integer? (was: Is logBase right?)

2009-08-26 Thread Uwe Hollerbach
Here's my version... maybe not as elegant as some, but it seems to
work. For base 2 (or 2^k), it's probably possible to make this even
more efficient by just walking along the integer as stored in memory,
but that difference probably won't show up until at least tens of
thousands of digits.

Uwe

ilogb :: Integer - Integer - Integer
ilogb b n | n  0  = ilogb b (- n)
  | n  b  = 0
  | otherwise  = (up 1) - 1
  where up a = if n  (b ^ a)
  then bin (quot a 2) a
  else up (2*a)
bin lo hi = if (hi - lo) = 1
   then hi
   else let av = quot (lo + hi) 2
in if n  (b ^ av)
  then bin lo av
  else bin av hi

numDigits n = 1 + ilogb 10 n

[fire up ghci, load, etc]

*Main numDigits (10^1500 - 1)
1500
*Main numDigits (10^1500)
1501
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Applicative and Monad transformers

2009-08-26 Thread Jeremy Shaw
Hello,

I have seen it said that all Monads are Applicative Functors because
you can just do:

instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure = return
(*) = ap

However, that instance for ReaderT does not exhibit the properties I
was hoping for. By substitution the definition of ap:

ap:: (Monad m) = m (a - b) - m a - m b
ap=  liftM2 id

liftM2  :: (Monad m) = (a1 - a2 - r) - m a1 - m a2 - m r
liftM2 f m1 m2  = do { x1 - m1; x2 - m2; return (f x1 x2) }

we see that it becomes:

instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure = return
f * x = do { f' - f; x' - x; return (f' x') }

What I would prefer is:

instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure a = ReaderT $ const (pure a)
f * a = ReaderT $ \r - 
  ((runReaderT f r) * (runReaderT a r))

I assume that only one version is correct, but I am having a hard time
figuring out which one. 

I have attached a file which shows my motivation for prefering the
second variation. There is a 'looker' function which does three
lookups and combines the results using the Applicative Functor.

With the first Applicative instance for ReaderT you will only get a
failure message for the first lookup that fails -- which is what you
expect with monadic behaviour. With the second instance, you get back
a list of all the lookups that failed, which seems like what I would
expect with Applicative Functor behaviour.

Thanks!
- jeremy

{-# LANGUAGE FlexibleContexts, FlexibleInstances #-}
module Main where

import Control.Applicative (Applicative((*), pure), ($))
import Control.Monad (Monad((=), return), ap)
import Control.Monad.Reader (MonadReader(ask, local), ReaderT(ReaderT, 
runReaderT))
import Data.Monoid(Monoid(mappend))


instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure = return
(*) = ap

{-
instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure a = ReaderT $ const (pure a)
f * a = ReaderT $ \r - 
  ((runReaderT f r) * (runReaderT a r))
-}
instance (Monoid e) = Applicative (Either e) where
pure = Right
(Left errF) * (Left errA) = Left (errF `mappend` errA)
(Left err)  * _   = Left err
_   * (Left err)  = Left err
(Right f)   * (Right a)   = Right (f a)

instance Monad (Either [String]) where
return = Right 
(Right a) = f = f a
(Left e) = f = (Left e)
fail str = Left [str]

lookupE :: (Eq a) = a - [(a,b)] - (Either a b)
lookupE a env =
case lookup a env of
  Just b - Right b
  Nothing - Left a

look :: String - ReaderT [(String,b)] (Either [String]) b
look a =
do env - ask
   case lookup a env of
 Just b - return b
 Nothing - fail a

looker :: ReaderT [(String, Int)] (Either [String]) (Int, Int, Int)
looker = ((,,) $ look foo * look bar * look baz)

test :: Either [String] (Int, Int, Int)
test =
runReaderT looker [(bar, 1)]



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


Re: [Haskell-cafe] Applicative and Monad transformers

2009-08-26 Thread Jeremy Shaw
Attached is as slight better test example which does not rely on the
'fail' method. Doesn't really change anything significant though.

{-# LANGUAGE FlexibleContexts, FlexibleInstances #-}
module Main where

import Control.Applicative (Applicative((*), pure), ($))
import Control.Monad (Monad((=), return), ap)
import Control.Monad.Reader (MonadReader(ask, local), ReaderT(ReaderT, 
runReaderT), mapReaderT)
import Data.Monoid(Monoid(mappend))

{-
instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure = return
(*) = ap

-}
instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure a = ReaderT $ const (pure a)
f * a = ReaderT $ \r - 
  ((runReaderT f r) * (runReaderT a r))

instance (Monoid e) = Applicative (Either e) where
pure = Right
(Left errF) * (Left errA) = Left (errF `mappend` errA)
(Left err)  * _   = Left err
_   * (Left err)  = Left err
(Right f)   * (Right a)   = Right (f a)

instance Monad (Either e) where
return = Right 
(Right a) = f = f a
(Left e) = f = (Left e)
--fail str = Left [str]

lookupE :: (Eq a) = a - [(a,b)] - (Either a b)
lookupE a env =
case lookup a env of
  Just b - Right b
  Nothing - Left a

look :: (Eq a) = a - ReaderT [(a,b)] (Either [a]) b
look a =
do env - ask
   case lookup a env of
 (Just b) - return b
 Nothing - asLeft a

asLeft :: a - ReaderT r (Either [a]) b
asLeft a =
mapReaderT (\m - case m of
(Left as) - Left (a:as)
(Right _) - Left [a])
   (return ())

looker :: ReaderT [(String, Int)] (Either [String]) (Int, Int, Int)
looker = ((,,) $ look foo * look bar * look baz)

test :: Either [String] (Int, Int, Int)
test =
runReaderT looker [(bar, 1)]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Applicative and Monad transformers

2009-08-26 Thread Martijn van Steenbergen

Jeremy Shaw wrote:

What I would prefer is:

instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
pure a = ReaderT $ const (pure a)
f * a = ReaderT $ \r - 
  ((runReaderT f r) * (runReaderT a r))


Right. This doesn't only go for ReaderT, it already goes for Either, 
too: you don't want the 'ap' implementation for * there either.


These are beautiful examples of how applicative style gives the caller 
less power, but the callee more information, allowing more information 
to be retained. In this case it allows you to concatenate errors using 
mappend.


Another example is parsing: I believe Doaitse's parsers allow more 
optimization if they are only used in applicative style (but I'm not 
sure of this).


This shows there can be several sensible implementations of a type 
class. You ask which instance is right--that depends entirely on what 
you want it to do! Setting (*) = ap is just one of them, one you 
happen to get for free if your functor is already a monad.


Hope this helps,

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


[Haskell-cafe] Network.Socket error in MacOS 10.5?

2009-08-26 Thread kenny lu
Hi,

I encountered a problem with Network.Socket in MacOS 10.5
Here is the code that I am testing,

-
-
module Main where

import qualified Network.Socket as Socket

main :: IO ()
main =
do { (hostname, _) - Socket.getNameInfo [] True False
(Socket.SockAddrUnix localhost)
   -- (hostname, _) - Socket.getNameInfo [] True False
(Socket.SockAddrInet 9000  (127 + 0 * 256 + 0 * 256^2 + 1 * 256^3))
   ; putStrLn (show hostname)
   }


Running the above code yields the following error
ghc --make -O2 TestSocket.hs
[1 of 1] Compiling Main ( TestSocket.hs, TestSocket.o )
Linking TestSocket ...
$ ./TestSocket
TestSocket: getNameInfo: does not exist (ai_family not supported)

If I switch to SockAddrInet instead, the error is gone.

I am using GHC 6.10.3 and Network 2.2.1

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


Re: [Haskell-cafe] Applicative and Monad transformers

2009-08-26 Thread Edward Kmett
On Wed, Aug 26, 2009 at 12:04 PM, Martijn van Steenbergen 
mart...@van.steenbergen.nl wrote:


 Another example is parsing: I believe Doaitse's parsers allow more
 optimization if they are only used in applicative style (but I'm not sure of
 this).


That is correct. When you glue together P_m's applicatively the applicative
P_f 'future' parser can be used, but when you use it monadically the context
sensitive parts are glued together using the monadic P_h 'history' parser.

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


Re: [Haskell-cafe] Suggestion: define a standard keyboard codes library?

2009-08-26 Thread Peter Verswyvelen
I would already be happy with a low level library that holds the union of
all keys, assigning them unique codes. So you would have keys like Apple,
Amiga, Windows, Start, Popup, LeftControl, RightControl, etc... No mapping
is done at the low level.
Then one would need an OS dependent interface to figure out which keys are
available.

Which keyboard bindings (like CTRL+C or CTRL+INSERT) are assigned to which
user interface commands is a high level binding, which in the perfect UI is
configurable anyway, although the OS dependent interface should provide a
lot of defaults (again different on each system)

However I only have experience with Windows, Amiga, a bit of OSX and tiny
bit of Linux, so I don't know all the details of all esoteric systems.

For now I will just use the bindings in the GLFW package.

On Wed, Aug 26, 2009 at 3:34 PM, Marc Weber marco-owe...@gmx.de wrote:

 Excerpts from Peter Verswyvelen's message of Wed Aug 26 12:15:14 +0200
 2009:
  Maybe it would be nice to agree on a standard datatype for keys? This
 might
  also include digital buttons on a joystick, etc...

 The synergy project (sourceforge) already does some mapping from Windows
 - Linux - Mac AFAIK.

 It forwards key input to the other system over network.
 This could be a source of additional information. However I haven't
 looked at the code yet.

 Sincerly
 Marc Weber
 ___
 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] Network.Socket error in MacOS 10.5?

2009-08-26 Thread Johan Tibell
On Wed, Aug 26, 2009 at 6:33 PM, kenny luhaskellm...@gmail.com wrote:
 Hi,

 I encountered a problem with Network.Socket in MacOS 10.5
 Here is the code that I am testing,

 -
 -
 module Main where

 import qualified Network.Socket as Socket

 main :: IO ()
 main =
     do { (hostname, _) - Socket.getNameInfo [] True False
 (Socket.SockAddrUnix localhost)
    -- (hostname, _) - Socket.getNameInfo [] True False
 (Socket.SockAddrInet 9000  (127 + 0 * 256 + 0 * 256^2 + 1 * 256^3))
    ; putStrLn (show hostname)
    }


 Running the above code yields the following error
 ghc --make -O2 TestSocket.hs
 [1 of 1] Compiling Main ( TestSocket.hs, TestSocket.o )
 Linking TestSocket ...
 $ ./TestSocket
 TestSocket: getNameInfo: does not exist (ai_family not supported)

 If I switch to SockAddrInet instead, the error is gone.

 I am using GHC 6.10.3 and Network 2.2.1

Is SockAddrUnix supposed to work on Mac OS X? Could you test it by
e.g. writing a small C program that uses it?

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


Re: [Haskell-cafe] Network.Socket error in MacOS 10.5?

2009-08-26 Thread Ross Mellgren
I don't think getNameInfo should work for for AF_UNIX -- the name  
given to SockAddrUnix is a file path, there is no name resolution.  
From the man page for getnameinfo(3) on OS X:


NAME
   getnameinfo -- socket address structure to hostname and service name

...

DESCRIPTION

...

   The sockaddr structure sa should point to either a sockaddr_in or  
sockaddr_in6 structure

(for IPv4 or IPv6 respectively) that is salen bytes long.



Similarly, from the man page for getnameinfo on my linux box:

...

The sa argument is a pointer to a generic socket address structure (of  
type sockaddr_in or sockaddr_in6) of size salen that holds the input  
IP address and port number.


-Ross
On Aug 26, 2009, at 2:07 PM, Johan Tibell wrote:

On Wed, Aug 26, 2009 at 6:33 PM, kenny luhaskellm...@gmail.com  
wrote:

Hi,

I encountered a problem with Network.Socket in MacOS 10.5
Here is the code that I am testing,

-
-
module Main where

import qualified Network.Socket as Socket

main :: IO ()
main =
do { (hostname, _) - Socket.getNameInfo [] True False
(Socket.SockAddrUnix localhost)
   -- (hostname, _) - Socket.getNameInfo [] True False
(Socket.SockAddrInet 9000  (127 + 0 * 256 + 0 * 256^2 + 1 * 256^3))
   ; putStrLn (show hostname)
   }


Running the above code yields the following error
ghc --make -O2 TestSocket.hs
[1 of 1] Compiling Main ( TestSocket.hs, TestSocket.o )
Linking TestSocket ...
$ ./TestSocket
TestSocket: getNameInfo: does not exist (ai_family not supported)

If I switch to SockAddrInet instead, the error is gone.

I am using GHC 6.10.3 and Network 2.2.1


Is SockAddrUnix supposed to work on Mac OS X? Could you test it by
e.g. writing a small C program that uses it?

-- Johan
___
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: [Hackathon] Edinburgh Meetup (Sat 29 Aug) and Hack Day (Sun 30 Aug)

2009-08-26 Thread Brent Yorgey
On Fri, Aug 14, 2009 at 05:04:00PM +0100, Eric Kow wrote:
 Dear Haskellers,
 
 Just a quick reminder that we will be having a Hack Day in Edinburgh
 on Sunday 30 August (ICFP venue).  That's in two weeks!
 
 For the interested, we will also be meeting up the day before 09:30
 Saturday 29 August just outside the RCPE (ie. the ICFP venue again).
 We'll have a quick wander and hopefully find some nice places to sit and
 chat, whip out the occasional laptop and fling a lambda or not being
 careful not to injure the passers-by.

I'll be there Saturday morning---looking forward to meeting people!

Also, I have purchased a ticket to hear a concert of some 16th-century
a capella 16th-century music at the Canongate Kirk at 5pm on Saturday:

  http://www.edfringe.com/ticketing/detail.php?id=13649

Just thought I'd mention it, so if there's anyone else coming to the
meetup day and 16th-century a capella sounds like your cup of tea, you
can get a ticket too and we can go together.

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


Re: [Haskell-cafe] haddock: parse error in doc string

2009-08-26 Thread David Waern
2009/8/26 Peter Verswyvelen bugf...@gmail.com:
 Oh, I just installed the Haskell platform.
 I have
 Haddock version 2.4.2, (c) Simon Marlow 2006
 Ported to use the GHC API by David Waern 2006-2008
 But I noticed that my bad comments were in the description of the cabal
 file, not the source file.
 So that might be a new ticket?

My guess is that Cabal passes the description via the --prologue flag
and Haddock doesn't print which file it was passed. I'll fix this for
the next release, you don't have to file a ticket.

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


[Haskell-cafe] ANN: scion 0.1

2009-08-26 Thread Thomas Schilling

Hello,

I am pleased to announce the first release of Scion.

Scion [1] is a Haskell library that aims to implement those parts of a
Haskell IDE which are independent of a particular front-end.  Scion
is based on the GHC API and Cabal.  It provides both a Haskell API and
a server for non-Haskell clients such as Emacs and Vim.

Scion is bundled with two front-ends, Emacs and Vim, and is used by
the Haskell Eclipse plugin EclipseFP.  Work on Yi support is underway.

Scion's current features include:

 - Opening (that is, typechecking) a component of a Cabal project or a
   single file [Emacs, Vim]. Error messages are highlighted in the
   source [Emacs].

 - Saving a file automatically typechecks the file [Emacs, Vim].
   This feature can be turned off.

 - Look up the type of any identifier (even local variables) [Emacs,  
Vim].

   Requires that the file typechecks.

 - Jump to definition of an identifier defined in the current project
   [Emacs].

For more details on the provided features and instructions of how to
set up a particular front-end see the README [2].

Patches are always welcome.  The main source repository is hosted on
Github [3].  If you find a problem please file a bug [4] and/or join
the developer's mailing list [5].

  [1]: http://code.google.com/p/scion-lib/
  [2]: http://github.com/nominolo/scion/blob/master/README.markdown
  [3]: http://github.com/nominolo/scion
  [4]: http://code.google.com/p/scion-lib/issues/list
  [5]: http://groups.google.com/group/scion-lib-devel

Thanks
--

The following people contributed to patches to this release:

Marc Weber
Thomas ten Cate
Sudish Joseph





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


[Haskell-cafe] Haskell Weekly News: Issue 128 - August 26, 2009

2009-08-26 Thread Brent Yorgey
---
Haskell Weekly News
http://sequence.complete.org/hwn/20090826
Issue 128 - August 26, 2009
---

   Welcome to issue 128 of HWN, a newsletter covering developments in the
   [1]Haskell community.

   New releases of haddock, gitit, jhc, formlets, and lots of other
   libraries and tools; Edinburgh Hack Day, ICFP, and HacPDX coming up;
   exciting times! The Google Summer of Code has also wrapped up. See
   below for final progress reports from this summer's Haskell
   participants.

   PS: Just as this was going to press, Thomas Ten Cate released the
   Scion library from his Google Summer of Code project; hence it
   isn't listed below but you should check it out anyway!

Announcements

   GLUT 2.2.1.0. Sven Panne [2]announced a new version of the [3]GLUT
   package. The package is now autoconf-free, with API entries are
   resolved dynamically at runtime; support for sRGB framebuffers has been
   added; and support for context profiles has been added.

   Potential Network SIG. Thomas DuBuisson [4]announced the formation of a
   SIG to hammer out a design for a new Network API, seeing as the current
   API, a straight-forward Berkeley binding, doesn't seem to please anyone
   in a Haskell context.

   epoll bindings 0.1.1. Toralf Wittner [5]announced the release of
   [6]epoll bindings 0.1.1. Epoll is an I/O event notification facility
   for Linux similar to poll but with good scaling characteristics.
   Currently the bindings are fairly low level and close to the C API, but
   there are plans to add some buffer or stream abstraction on top.
   Eventually, when GHC can make use of epoll/kqueue in addition to
   select, this library will not be needed anymore. Until then it might be
   useful for applications which monitor large numbers of file
   descriptors.

   gitit 0.6.1. John MacFarlane [7]announced the release of [8]gitit
   0.6.1, a wiki program that runs on happstack, the Haskell web
   application server stack, and stores pages and other content in a git
   or darcs filestore. The whole code base has been overhauled since the
   last release: gitit is now faster, more memory efficient, more modular,
   and more secure. It also has many new features, including page metadata
   and categories, atom feeds (sitewide and per-page), support for
   literate Haskell, a better configuration system, an improved caching
   system, a Haskell library exporting happstack wiki handlers, and a
   plugin system.

   jhc 0.7.1. John Meacham [9]announced the 0.7.1 release of the [10]jhc
   optimizing Haskell compiler. There have been a lot of changes since the
   last public release. Some notable ones include the use of a general
   compiler cache by default rather than object files; reworked library
   support; an updated manual, with clearer build instructions; support
   for writing pure C libraries in Haskell; numerous library updates;
   smart progress meters; typechecking before compilation; and various bug
   fixes and cross compilation improvements.

   rss2irc 0.3 released. Simon Michael [11]announced the release of
   [12]rss2irc version 0.3, an irc bot created by Don Stewart to watch rss
   feeds and announce new items on irc, now maintained by Simon. This
   version includes reliable http networking, irc flood protection, better
   error handling  reporting, extensive debugging output, Atom support,
   more useful defaults, precise control of irc output, and is now
   installable on OSX. Feedback and patches welcome.

   formlets 0.6. Chris Eidhof [13]announced that the formlets team has
   released a new version of [14]formlets, a library to build type-safe,
   composable web forms. Most notably, Mightybyte and Chris worked on the
   [15]massInput functionality, which is now ready for use!

   graphtype -- A simple tool to illustrate dependencies between Haskell
   types. Max Desyatov [16]announced the release of [17]graphtype, a tool
   for visualising type declarations in Haskell source files. It produces
   [18].dot-files for subsequent processing with graphviz.

   OAuth library in haskell. Diego Souza [19]announced the release of
   [20]hoauth, a library which helps you to deal with the [21]oauth
   protocol. Currently it supports only consumer side applications, but
   there are plans to add service providers support in near future.

   ByteString Nums. Jason Dusek [22]announced [23]bytestring-nums, a
   simple package for relatively careless parsing of numbers from
   ByteStrings. It works to parse out integer strings, floating point
   strings and hex strings.

   haskell-src-exts-1.1.3. Niklas Broberg [24]announced the release of
   [25]haskell-src-exts-1.1.3, a package for Haskell source code
   manipulation. It handles (almost) all syntactic extensions to the
   Haskell 98 standard implemented by GHC, and the parsing can be
   parametrised

Re: [Haskell-cafe] FFI link failing due to no main?

2009-08-26 Thread phil

Thanks for the reply!

I think this might be a Mac OS X issue.  I've stripped my rather  
longwinded example down to the simplest case (one Haskell source file  
to create a single shared library containing a single exported  
function) and this compiles (and ultimately runs) fine on Linux.  So  
I'm either doing something wrong which shouldn't really work on Linux  
(and I'm getting lucky!)... or something screwy is happening on Mac  
version:


This exports a single function which is then #included in CInterface.c  
to create a new pure-C wrapper to the function.


ghc -O2 -c HaskellFuncs.hs
ghc -O2 -no-hs-main --make -optl '-shared' CInterface.c  
HaskellFuncs_stub.o HaskellFuncs.o -o libCInterface.so


One Mac OS X I get the following error - but it works fine on Ubuntu.   
I'm using 6.10.4 on both machines:


Linking libCInterface.so ...
Undefined symbols:
  _ZCMain_main_closure, referenced from:
  _ZCMain_main_closure$non_lazy_ptr in libHSrts.a(Main.o)
  ___stginit_ZCMain, referenced from:
  ___stginit_ZCMain$non_lazy_ptr in libHSrts.a(Main.o)
ld: symbol(s) not found

Could anyone comment if I'm doing anything wrong, or is this a case of  
unsupported functionality on (PPC/Leopard) Mac OS X?  Has anyone  
succeeded in getting a similar example to work on Mac OS X?


I notice on Linux it is still very temperamental, if I play around  
with the arguments even slightly I get the same error there.



Cheers,

Phil.

On 26 Aug 2009, at 06:51, Yusaku Hashimoto wrote:


Missing -c option?

And -v option to see what's going on.

On Wed, Aug 26, 2009 at 10:37 AM, p...@beadling.co.uk wrote:

Hi,

After creating my stub objects etc using GHC, I'm trying to create  
a library
with a C interface to some Haskell functions.  I'm explicitly  
passing in

-no-hs-main yet the linker still fails due to missing main?

I'm sure I've had this working before with a slightly simpler  
example, but

can't work out what is wrong here.

If I give it a main (to humor it - it's not a solution), then it  
links and
produces an executable - so it looks to me like I'm not telling the  
linker

what I want correctly?

Any ideas?

Cheers,

Phil.


ghc -O2 --make -no-hs-main -package mtl   -package array -optl '- 
shared'

FFI/Octave/MyInterface.c FFI/Octave/OptionInterface_stub.o
FFI/Octave/OptionInterface.o ./FrameworkInterface.o ./Maths/Prime.o
./MonteCarlo/DataStructures.o ./MonteCarlo/European.o
./MonteCarlo/Framework.o ./MonteCarlo/Interface.o ./MonteCarlo/ 
Lookback.o

./Normal/Acklam.o ./Normal/BoxMuller.o ./Normal/Framework.o
./Normal/Interface.o ./Random/Framework.o ./Random/Halton.o
./Random/Interface.o ./Random/Ranq1.o   -o FFI/Octave/ 
libMyInterface.so

Linking FFI/Octave/libMyInterface.so ...
Undefined symbols:
 ___stginit_ZCMain, referenced from:
 ___stginit_ZCMain$non_lazy_ptr in libHSrts.a(Main.o)
 _ZCMain_main_closure, referenced from:
 _ZCMain_main_closure$non_lazy_ptr in libHSrts.a(Main.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

___
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] Network.Socket error in MacOS 10.5?

2009-08-26 Thread kenny lu
Thanks for the pointers. I will take a look.

Kenny

On Thu, Aug 27, 2009 at 2:20 AM, Ross Mellgren rmm-hask...@z.odi.ac wrote:

 I don't think getNameInfo should work for for AF_UNIX -- the name given to
 SockAddrUnix is a file path, there is no name resolution. From the man page
 for getnameinfo(3) on OS X:

 NAME
   getnameinfo -- socket address structure to hostname and service name

 ...

 DESCRIPTION

 ...

   The sockaddr structure sa should point to either a sockaddr_in or
 sockaddr_in6 structure
 (for IPv4 or IPv6 respectively) that is salen bytes long.



 Similarly, from the man page for getnameinfo on my linux box:

 ...

 The sa argument is a pointer to a generic socket address structure (of type
 sockaddr_in or sockaddr_in6) of size salen that holds the input IP address
 and port number.

 -Ross
 On Aug 26, 2009, at 2:07 PM, Johan Tibell wrote:

  On Wed, Aug 26, 2009 at 6:33 PM, kenny luhaskellm...@gmail.com wrote:

 Hi,

 I encountered a problem with Network.Socket in MacOS 10.5
 Here is the code that I am testing,

 -
 -
 module Main where

 import qualified Network.Socket as Socket

 main :: IO ()
 main =
do { (hostname, _) - Socket.getNameInfo [] True False
 (Socket.SockAddrUnix localhost)
   -- (hostname, _) - Socket.getNameInfo [] True False
 (Socket.SockAddrInet 9000  (127 + 0 * 256 + 0 * 256^2 + 1 * 256^3))
   ; putStrLn (show hostname)
   }


 Running the above code yields the following error
 ghc --make -O2 TestSocket.hs
 [1 of 1] Compiling Main ( TestSocket.hs, TestSocket.o )
 Linking TestSocket ...
 $ ./TestSocket
 TestSocket: getNameInfo: does not exist (ai_family not supported)

 If I switch to SockAddrInet instead, the error is gone.

 I am using GHC 6.10.3 and Network 2.2.1


 Is SockAddrUnix supposed to work on Mac OS X? Could you test it by
 e.g. writing a small C program that uses it?

 -- Johan
 ___
 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] Applicative and Monad transformers

2009-08-26 Thread Ralf Hinze
Hi Jeremy,

 I have seen it said that all Monads are Applicative Functors because
 you can just do:
 
 instance (Monad f, Applicative f) = Applicative (ReaderT r f) where
 pure = return
 (*) = ap
 
 However, that instance for ReaderT does not exhibit the properties I
 was hoping for.

OK, let's calculate. Here are the necessary definitions for the reader
monad (not the monad transformer).

m = k  =  \ x - k (m x) x

u * v  =  \ x - (u x) (v x)

return a  =  pure a  =  \ x - a

So, * is the S combinator and pure is the K combinator.

u = \ f - v = \ a - return (f a)
  = { definition of = }
\ x - (\ f - v = \ a - return (f a)) (u x) x
  = { beta }
\ x - (v = \ a - return ((u x) a)) x
  = { definition of = }
\ x - (\ a - return ((u x) a)) (v x) x
  = { beta }
\ x - return ((u x) (v x)) x
  = { definition of return }
\ x - (u x) (v x)
  = { definition of * }
u * v

Yes, both definitions are, in fact, equal.

So, what went wrong in your program? Observe that the first instance
declaration can be simplified to

instance (Monad f) = Applicative (ReaderT r f) where
  pure = return
  (*) = ap

which is suspicious.

Hope this helps, Ralf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe