Re: [Haskell-cafe] haddock: parse error in doc string
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?)
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?
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?
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?
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/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
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/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?
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?
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?
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 ?
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?)
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
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
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
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?
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
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?
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?
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?
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)
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/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
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
--- 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?
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?
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
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
