Re: [Haskell-cafe] Building gtk on OS/X with platform 2012.2.0.0
This is a known issue ([1]), and my guess, according to [2], is that it is fixed in the latest version ([3]), which has not been uploaded to hackage yet. What happens if you install gtk from that repo instead? You may want to try to apply the patch to the version of gtk2hs that is available on hackage instead. -- Ivan. [1] http://hackage.haskell.org/trac/gtk2hs/ticket/1245 [2] http://comments.gmane.org/gmane.comp.lang.haskell.gtk2hs.devel/1298 [3] http://code.haskell.org/gtk2hs/ On 5 June 2012 01:05, Stuart Hungerford stuart.hungerf...@gmail.com wrote: Hi, Has anyone successfully cabal installed gtk (from gtk2hs) on OS/X Lion with platform 2012.2.0.0? I setup a new Lion instance with latest XCode and command line tools and Homebrew. I installed gtk+, Cairo, pango etc successfully with Homebrew. The following install log for gtk2hs-buildtools and gtk shows a compilation error (line 5431): http://hpaste.org/69521 I'm probably doing something wrong, so any advice much appreciated. Stu ___ 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] Building gtk on OS/X with platform 2012.2.0.0
On Tue, Jun 5, 2012 at 5:12 PM, Ivan Perez ivanperezdoming...@gmail.com wrote: This is a known issue ([1]), and my guess, according to [2], is that it is fixed in the latest version ([3]), which has not been uploaded to hackage yet. What happens if you install gtk from that repo instead? You may want to try to apply the patch to the version of gtk2hs that is available on hackage instead. Thanks Ivan -- that's an excellent suggestion, which I'll try out. Stu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Install a script with Cabal?
Rogan Creswick cresw...@gmail.com writes:
I have a small project that installs a couple of Haskell tools and a
script that uses these. Cabal will of course build and install the
Haskell programs, but how can I get Cabal to install the script as
well? There's a host of UserHooks available¹, but it'd probably be
better to have an example than to try to experiment with the right
configuration.
I don't have an example handy, but I think you'll want preInts,
instHook, or postInst. I'd probably go with postInst unless you need
data provided by instHook's type that isn't passed to preInst or
postInst.
I found an example¹ using copyHook. However, this seems to be the wrong
thing, at least I am unable to get cabal to ever call this hook (or
preCopy, etc).
LocalBuildInfo /probably/ has the details you need (eg: installDirTemplates).
I just printed out the contents of LocalBuildInfo, but that's 33 pages
(I counted) of output. Redirected to a file, it makes it easier to
search to find the relevant needles in this haystack.
Okay, looking at installDirTemplates, I see `bindir` can extract this
data member. It's of course an InstallDirTemplate, not a FilePath, but
I found 'fromPathTemplate', which has the right type. Except it only
dumps the template, with $prefix and all.
Hoogle doesn't seem to know about any of the Cabal stuff, Hayoo has a *very*
annoying behavior where it cleans out everything you did if you use the
back button, and the source links it advertises seem to point into
the wide blue 404. But using the latter, I managed to find a link to
'substPathTemplate', worked out that the PackageIdentifier it needs is a
member of PackageDescription, and tried to use that. Except it gives
the same result, and doesn't appear to substitute anything. I guess the
fact that it is undocumented is a hint that it's the wrong thing to use.
Reading some more, maybe 'absoluteInstallDirs' is what I'm looking for?
In addition to the usual heap of huge config structs, it needs a
CopyDest, though. Since I have no idea what to use, I just put
NoCopyDest there. Does that make sense? Okay, it works now, in the
sense that I ran it once on my laptop, and it copied the file to
~/.cabal/bin. Here is the code, comments welcome:
#!/usr/bin/env runhaskell
import Distribution.Simple (defaultMainWithHooks,
simpleUserHooks,UserHooks(..))
import Distribution.Simple.Setup (InstallFlags,CopyDest(..))
import Distribution.Simple.Utils (rawSystemExit)
import Distribution.PackageDescription (PackageDescription())
import Distribution.Simple.LocalBuildInfo (LocalBuildInfo(..),
InstallDirs(..), absoluteInstallDirs)
import Distribution.Verbosity (normal)
main :: IO ()
main = defaultMainWithHooks simpleUserHooks
{ instHook = \pd lbi uh ifs - myinst pd lbi uh ifs instHook
simpleUserHooks pd lbi uh ifs }
myinst :: PackageDescription - LocalBuildInfo - UserHooks - InstallFlags
- IO ()
myinst pd lbi _uh _fs = do
let bin = bindir $ absoluteInstallDirs pd lbi NoCopyDest
rawSystemExit normal cp [asmeval, bin]
PS: This was a rather frustrating excercise, and after wallowing through
a wilderness of modules, types, records and functions, I can't help but
feel that Cabal is a bit overengineered. Surely including a script or
similar in a package isn't all that outlandish? Could there conceivably
have been a simpler way? Or at least, better documented? I suspect the
fact that - with the sole exception of the link below -- I could find *no*
examples to help me out indicates that it is a bit too complicated.
-k
¹ http://blog.ezyang.com/2010/06/setting-up-cabal-the-ffi-and-c2hs/
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arithmetic expressions with GADTs: parsing
Very useful to get a gadt back to monotype without an existential, which would mean to use classes for future uses of it with its load of object oriented thinking. Thanks for sharing. paolino 2012/6/4 Ryan Ingram ryani.s...@gmail.com Another option is to reify the type so that you can get it back somehow. Here's a few diffs to your file (I've attached the full code): A new type: data Typed f where TDouble :: f Double - Typed f TBool :: f Bool - Typed f runT :: (f Double - a) - (f Bool - a) - Typed f - a runT k _ (TDouble x) = k x runT _ k (TBool x) = k x New version of pExpr that can parse both expression types, by tagging with the type -- pExpr = pArit | pBool | pEqual pExpr = (TDouble $ pArit) | (TBool $ pBool) | (TDouble $ pEqual) and now main: main = do line - getLine case parse pExpr line of Left msg - putStrLn (show msg) Right e - putStrLn (runT (show . eval) (show . eval) e) What I'm doing here is reifying the possible types of top level expressions and then providing a handler in main which works on all possible types. There are other ways to do this (embed any expression in an existential, for example), but this makes it really clear what is going on, and shows the way forward for parsing a larger typed language. -- ryan On Wed, May 2, 2012 at 6:08 AM, j.romi...@gmail.com wrote: On Wed, May 02, 2012 at 03:02:46PM +0300, Roman Cheplyaka wrote: * j.romi...@gmail.com j.romi...@gmail.com [2012-05-02 08:03:45-0300] [...] The alternatives given to | must be of the same type. In your case, one is Expr Double and one is Expr Bool. Inclusion of pBool in pFactor is probably a mistake — unless you're going to multiply booleans. You are right in the sense that I cannot mix Expr Bool and Expr Double in a (O op l r) expression. But the parser should be able to parse any form of expressions. So I rewrite my program to take this into account. The new versions still does not compile: Expr.hs:27:23: Couldn't match expected type `Double' with actual type `Bool' Expected type: ParsecT String () Data.Functor.Identity.Identity (Expr Double) Actual type: ParsecT String () Data.Functor.Identity.Identity (Expr Bool) In the first argument of `(|)', namely `pBool' In the second argument of `(|)', namely `pBool | pEqual' Romildo ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fundeps and overlapping instances
On Tue, Jun 5, 2012 at 4:18 AM, Etienne Laurin etie...@atnnn.com wrote: Thanks for the idea. Here it is. http://hackage.haskell.org/trac/ghc/wiki/TFvsFD I posted my comments on the matter along with many additional comments and examples that I found. Thanks! One part is confusing me. In the section on Partial application, you write: Type synonyms can manipulate constraint kinds but can not use them. The following code doesn't make sense. class (f :$: a) ~ b = FMap (f :: * - * - Constraint) a b where type f :$: a instance FMap f (HJust a) b where type f :$: (HJust a) = f a b = b The class definition looks like it's meant to parallel the earlier FDs version of FMap by using the standard encoding of FDs with TFs, but the instance declaration doesn't. Is it meant to be demonstrating something else? The encoded version would be: instance (f a b) = FMap f (HJust a) (HJust b) where type f :$: (HJust a) = HJust b and I think this actually demonstrates a *different* limitation, namely that The RHS of an associated type declaration mentions type variable `b' All such variables must be bound on the LHS which means that the standard encoding doesn't work for this case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: hquantlib-0.0.2.3
Hi Cafe, I'm pleased to announce that HQuantLib has been released recently after a year of sleep. This is mainly a technical release to clean up dependencies and refresh build infrastructure. The library is intended to be a functional port of QuantLib (http://quantlib.org), a free/open-source library for quantitative finance. Also I'd like to thank Nicholas Pezolano for contributing copulas to the library. Business changes highlights: -- 1. Copulas in math methods. (CDS and CDO are expected in the next release) 2. Priceable interface for Instruments. (Option pricing to be done in further releases) == Technical changes highlights: -- 1. Version upgrade to recent GHC 7.4.1. 2. Dependency clean-ups. 3. Unit-test infrastructure. (HUnit + QuickCheck 2) == SCM: https://github.com/paulrzcz/hquantlib Hackage: http://hackage.haskell.org/package/hquantlib Best regards, Pavel Ryzhov http://paulrz.cz signature.asc Description: Message signed with OpenPGP using GPGMail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Install a script with Cabal?
I spent quite some time going through the cabal docs to generate some
files automatically with hails. I totally feel your pain :)
What I'm going to suggest is not really a solution to your problem,
but since modifying the hooks to install specific programs is not the
best solution either, you might want to try and write your script in
Haskell (using HSH, for instance). That way you would have a
multi-platform script that can be installed just like any other
Haskell program.
Regarding the general problem, the best I can think of would be adding
a field Bin-files: to the cabal file format, and have Cabal process
it properly. Maybe some of the maintainers of cabal can comment on
that.
Two more suggestions. If you are going to modify the hooks:
1) Do not call cp directly. Use copyFile if possible. cp is *nix dependent.
2) Read the name of the file to be copied from a configuration file.
It is much more likely that others (and you) will be able to reuse
your code if you do.
Cheers,
Ivan.
[1] http://hackage.haskell.org/package/HSH
On 5 June 2012 12:28, Ketil Malde ke...@malde.org wrote:
Rogan Creswick cresw...@gmail.com writes:
I have a small project that installs a couple of Haskell tools and a
script that uses these. Cabal will of course build and install the
Haskell programs, but how can I get Cabal to install the script as
well? There's a host of UserHooks available¹, but it'd probably be
better to have an example than to try to experiment with the right
configuration.
I don't have an example handy, but I think you'll want preInts,
instHook, or postInst. I'd probably go with postInst unless you need
data provided by instHook's type that isn't passed to preInst or
postInst.
I found an example¹ using copyHook. However, this seems to be the wrong
thing, at least I am unable to get cabal to ever call this hook (or
preCopy, etc).
LocalBuildInfo /probably/ has the details you need (eg: installDirTemplates).
I just printed out the contents of LocalBuildInfo, but that's 33 pages
(I counted) of output. Redirected to a file, it makes it easier to
search to find the relevant needles in this haystack.
Okay, looking at installDirTemplates, I see `bindir` can extract this
data member. It's of course an InstallDirTemplate, not a FilePath, but
I found 'fromPathTemplate', which has the right type. Except it only
dumps the template, with $prefix and all.
Hoogle doesn't seem to know about any of the Cabal stuff, Hayoo has a *very*
annoying behavior where it cleans out everything you did if you use the
back button, and the source links it advertises seem to point into
the wide blue 404. But using the latter, I managed to find a link to
'substPathTemplate', worked out that the PackageIdentifier it needs is a
member of PackageDescription, and tried to use that. Except it gives
the same result, and doesn't appear to substitute anything. I guess the
fact that it is undocumented is a hint that it's the wrong thing to use.
Reading some more, maybe 'absoluteInstallDirs' is what I'm looking for?
In addition to the usual heap of huge config structs, it needs a
CopyDest, though. Since I have no idea what to use, I just put
NoCopyDest there. Does that make sense? Okay, it works now, in the
sense that I ran it once on my laptop, and it copied the file to
~/.cabal/bin. Here is the code, comments welcome:
#!/usr/bin/env runhaskell
import Distribution.Simple (defaultMainWithHooks,
simpleUserHooks,UserHooks(..))
import Distribution.Simple.Setup (InstallFlags,CopyDest(..))
import Distribution.Simple.Utils (rawSystemExit)
import Distribution.PackageDescription (PackageDescription())
import Distribution.Simple.LocalBuildInfo (LocalBuildInfo(..),
InstallDirs(..), absoluteInstallDirs)
import Distribution.Verbosity (normal)
main :: IO ()
main = defaultMainWithHooks simpleUserHooks
{ instHook = \pd lbi uh ifs - myinst pd lbi uh ifs instHook
simpleUserHooks pd lbi uh ifs }
myinst :: PackageDescription - LocalBuildInfo - UserHooks - InstallFlags
- IO ()
myinst pd lbi _uh _fs = do
let bin = bindir $ absoluteInstallDirs pd lbi NoCopyDest
rawSystemExit normal cp [asmeval, bin]
PS: This was a rather frustrating excercise, and after wallowing through
a wilderness of modules, types, records and functions, I can't help but
feel that Cabal is a bit overengineered. Surely including a script or
similar in a package isn't all that outlandish? Could there conceivably
have been a simpler way? Or at least, better documented? I suspect the
fact that - with the sole exception of the link below -- I could find *no*
examples to help me out indicates that it is a bit too complicated.
-k
¹ http://blog.ezyang.com/2010/06/setting-up-cabal-the-ffi-and-c2hs/
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
[Haskell-cafe] Extending constraints
Hello,
I have the following program:
--
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE ScopedTypeVariables #-}
import Data.Proxy (Proxy)
import Data.Typeable (Typeable, TypeRep, typeOf)
data ProxyWrapper constraint =
forall a. constraint a = ProxyWrapper (Proxy a)
typeOfInnerProxy :: ProxyWrapper constraint - TypeRep
typeOfInnerProxy (ProxyWrapper p) = typeOfArg p
typeOfArg :: forall t a. Typeable a = t a - TypeRep
typeOfArg _ = typeOf (undefined :: a)
--
Type checking this gives the following expected type error:
ProxyWrapper.hs:12:37:
Could not deduce (Typeable a) arising from a use of `typeOfArg'
from the context (constraint a)
bound by a pattern with constructor
ProxyWrapper :: forall (constraint :: * - Constraint) a.
(constraint a) =
Proxy a - ProxyWrapper constraint,
in an equation for `typeOfInnerProxy'
Is there a way to extend the 'constraint' with the 'Typeable'
constraint in the type signature of 'typeOfInnerProxy'?
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending constraints
Hi Bas. I haven't thought about this for long, but ... data ProxyWrapper constraint = forall a. constraint a = ProxyWrapper (Proxy a) I'm assuming adding Typable a in ProxyWrapper is not an option for you? So then what about: class (c1 a, c2 a) = Ext c1 c2 a instance (c1 a, c2 a) = Ext c1 c2 a typeOfInnerProxy :: ProxyWrapper (Ext Typeable constraint) - TypeRep typeOfInnerProxy (ProxyWrapper p) = typeOfArg p This will certainly require all sorts of undecidable instances :) But does it work for you? Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending constraints
On 5 June 2012 17:52, Andres Löh and...@well-typed.com wrote: Hi Bas. I haven't thought about this for long, but ... data ProxyWrapper constraint = forall a. constraint a = ProxyWrapper (Proxy a) I'm assuming adding Typable a in ProxyWrapper is not an option for you? No, I would rather keep that type as unconstrained as possible. So then what about: class (c1 a, c2 a) = Ext c1 c2 a instance (c1 a, c2 a) = Ext c1 c2 a typeOfInnerProxy :: ProxyWrapper (Ext Typeable constraint) - TypeRep typeOfInnerProxy (ProxyWrapper p) = typeOfArg p This will certainly require all sorts of undecidable instances :) But does it work for you? It works. Thanks a lot! Cheers, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Installation of the New Haskell Platform
As Brent said, each version of GHC needs to build its own copy of the packages you use in your projects. Conveniently, these are all kept in separate directories by GHC version, so you can leave your old ones around as you compile new ones with the new platform. However... Most users don't want multiple versions installed at once. The Mac Haskell Platform installer, since 2011.4.0.0, installs a command uninstall-hs on your system. You can use that command to uninstall prior versions of GHC and the Platform. You can safely run it either before or after your installation of 2012.2.0.0. It is a very cautious program, and you can just safely run it on the command line - it won't remove anything until explicitly instructed. Pay attention to it's output, including the last few lines which will explain how to proceed with actual removal. -Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] attoparsec double precision, quickCheck and aeson
The double parser provided by Data.Attoparsec.ByteString.Char8 looses precision around the 13-15th decimal place (http://hackage.haskell.org/packages/archive/attoparsec/0.10.2.0/doc/html/Data-Attoparsec-ByteString-Char8.html#v:double). Unfortunately this reeks havoc with my attempts to write a quickCheck test that validates print-read equivalence for a program that uses Aeson. I have tried compensating for this round-off error in my quickCheck generator using a function like this: roundDouble :: Double - Double roundDouble d = let Right v = A8.parseOnly A8.double (C.pack (show d)) in v which helps in many cases, but for some the parsing seems bi-stable, alternating between two imprecise double values and causing the test to fail. I was wondering if anyone could suggest a better work-around for this problem, or explain why Attoparsec's double parser can't be isomorphic to haskell's. Thanks, Warren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending constraints
On 5 June 2012 17:57, Bas van Dijk v.dijk@gmail.com wrote: It works. It turns out it doesn't work exactly as I want. Say I have this ProxyWrapper of Nums: p :: ProxyWrapper Num p = ProxyWrapper (Proxy :: Proxy Int) then the following would give a type error: oops :: TypeRep oops = typeOfInnerProxy p Couldn't match expected type `Ext Typeable constraint0' with actual type `Num' Expected type: ProxyWrapper (Ext Typeable constraint0) Actual type: ProxyWrapper Num In the first argument of `typeOfInnerProxy', namely `p' In the expression: typeOfInnerProxy p Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending constraints
What you want seems a bit tricky. p :: ProxyWrapper Num p = ProxyWrapper (Proxy :: Proxy Int) At this point, all you know about p is that it is a Num. You don't know that it is Typeable, because you choose to forget about that. You could give p the type 'ProxyWrapper (Ext Typeable Num)' and it would work. then the following would give a type error: oops :: TypeRep oops = typeOfInnerProxy p Yes, and correctly so. Because Typeable isn't even a superclass of Num. So there's no way to know that p actually contains a Typeable proxy. Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
On Tue, Jun 5, 2012 at 9:12 AM, Warren Harris warrensomeb...@gmail.com wrote: which helps in many cases, but for some the parsing seems bi-stable, alternating between two imprecise double values and causing the test to fail. You want to perform your test as d1 - d2 epsilon where epsilon is derived from the relative error you're willing to accept (e.g. 0.01% error.) You can't use an absolute epsilon because if you pick e.g. epsilon = 0.1 but your input are also very small, you'll end up accepting a big relative error. Comparing floating points values for equality is asking for trouble. I was wondering if anyone could suggest a better work-around for this problem, or explain why Attoparsec's double parser can't be isomorphic to haskell's. Thanks, I think attoparsec uses a slightly less exact but much much faster double parser. I believe it's described in the attoparsec haddock docs somewhere. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending constraints
On Tue, Jun 5, 2012 at 5:29 PM, Bas van Dijk v.dijk@gmail.com wrote:
Hello,
I have the following program:
--
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE ScopedTypeVariables #-}
import Data.Proxy (Proxy)
import Data.Typeable (Typeable, TypeRep, typeOf)
data ProxyWrapper constraint =
forall a. constraint a = ProxyWrapper (Proxy a)
I must be missing something, but this seems a bit useless to me. You
have a phantom type parameter on Proxy, and then you're hiding it. So
when you pattern match on ProxyWrapper you recover the fact that there
was a type which satisfies the constraint, but you don't know what
type it was, and neither do you know about any values which are of the
type. What are you trying to do?
That said, if you want to be able to recover a Typeable constraint, I
don't see any way except for using 'ProxyWrapper (Ext Typeable
constraint)' as Andres says or putting 'forall a. (constraint a,
Typeable a)' in the definition of ProxyWrapper.
typeOfInnerProxy :: ProxyWrapper constraint - TypeRep
typeOfInnerProxy (ProxyWrapper p) = typeOfArg p
typeOfArg :: forall t a. Typeable a = t a - TypeRep
typeOfArg _ = typeOf (undefined :: a)
--
Type checking this gives the following expected type error:
ProxyWrapper.hs:12:37:
Could not deduce (Typeable a) arising from a use of `typeOfArg'
from the context (constraint a)
bound by a pattern with constructor
ProxyWrapper :: forall (constraint :: * - Constraint) a.
(constraint a) =
Proxy a - ProxyWrapper constraint,
in an equation for `typeOfInnerProxy'
Is there a way to extend the 'constraint' with the 'Typeable'
constraint in the type signature of 'typeOfInnerProxy'?
Regards,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
On Jun 5, 2012, at 9:38 AM, Johan Tibell wrote: You want to perform your test as d1 - d2 epsilon What's the best way to do this though, since aeson's Value type already provides instance Eq? I guess I can write my own suite of equality comparisons, but these aeson values are the leaves of an extensive grammar and it seems a shame to mimic everything that Eq does (without the benefits of deriving) just to compare doubles differently. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
On Tue, Jun 5, 2012 at 9:51 AM, Warren Harris warrensomeb...@gmail.com wrote: On Jun 5, 2012, at 9:38 AM, Johan Tibell wrote: You want to perform your test as d1 - d2 epsilon What's the best way to do this though, since aeson's Value type already provides instance Eq? I guess I can write my own suite of equality comparisons, but these aeson values are the leaves of an extensive grammar and it seems a shame to mimic everything that Eq does (without the benefits of deriving) just to compare doubles differently. I don't think applying == to something that contains floating point values at the leaves makes much sense. You want some approxEq function that uses approximate equality on floating point value or you want to equality function that ignores the floating point values. Probably not the answer you like, but I don't know how to define Eq in a robust way for types that include floating point values. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Install a script with Cabal?
On Tue, Jun 5, 2012 at 4:28 AM, Ketil Malde ke...@malde.org wrote:
Rogan Creswick cresw...@gmail.com writes:
I have a small project that installs a couple of Haskell tools and a
script that uses these. Cabal will of course build and install the
Haskell programs, but how can I get Cabal to install the script as
well? There's a host of UserHooks available¹, but it'd probably be
better to have an example than to try to experiment with the right
configuration.
I don't have an example handy, but I think you'll want preInts,
instHook, or postInst. I'd probably go with postInst unless you need
data provided by instHook's type that isn't passed to preInst or
postInst.
I found an example¹ using copyHook. However, this seems to be the wrong
thing, at least I am unable to get cabal to ever call this hook (or
preCopy, etc).
I'm not sure if/when copy hooks are used during the typical cabal
configure/build/install process; I suspect they are not used. There
is, however, a `cabal copy` command, which I believe does. Not that
that helps you right now, but that may explain the behavior you saw.
LocalBuildInfo /probably/ has the details you need (eg: installDirTemplates).
This was harder than I thought.
Here's an example (I hacked an example on to the cabal-dev Setup.hs,
so there are extra imports you won't necessarily need -- full Setup.hs
is in the linked gist, the email only contains the relevant exceprts):
Gist: https://gist.github.com/2876277
main = defaultMainWithHooks $
simpleUserHooks { hookedPrograms = [cabalInstallProgram]
, postInst = postInstCp (postInst simpleUserHooks)
}
type PostInstHook = Args - InstallFlags - PackageDescription -
LocalBuildInfo - IO ()
postInstCp :: PostInstHook - Args - InstallFlags -
PackageDescription - LocalBuildInfo - IO ()
postInstCp oldHook args iflags pDesc lbi = do
let -- The filename to copy from:
inFile :: FilePath
inFile = srcFileName.sh
-- The filename to copy to:
outFile :: FilePath
outFile = destFileName.sh
prefix = fromFlag $ installDistPref iflags
-- Make a concrete binDir from the LocalBuildInfo PackageDescription:
instBinDir :: FilePath
instBinDir = bindir $ absoluteInstallDirs pDesc lbi
(fromFlag $ copyDest
defaultCopyFlags)
-- layer of indirection, in case we wanted to get a specific
-- src directory from the cabal file:
src :: FilePath
src = inFile
-- qualify the destination.
dest :: FilePath
dest = instBinDir / outFile
-- Do the copy, creating outFile in the bin dir:
copyFile src dest
-- now invoke the old hook:
oldHook args iflags pDesc lbi
--Rogan
I just printed out the contents of LocalBuildInfo, but that's 33 pages
(I counted) of output. Redirected to a file, it makes it easier to
search to find the relevant needles in this haystack.
Okay, looking at installDirTemplates, I see `bindir` can extract this
data member. It's of course an InstallDirTemplate, not a FilePath, but
I found 'fromPathTemplate', which has the right type. Except it only
dumps the template, with $prefix and all.
Hoogle doesn't seem to know about any of the Cabal stuff, Hayoo has a *very*
annoying behavior where it cleans out everything you did if you use the
back button, and the source links it advertises seem to point into
the wide blue 404. But using the latter, I managed to find a link to
'substPathTemplate', worked out that the PackageIdentifier it needs is a
member of PackageDescription, and tried to use that. Except it gives
the same result, and doesn't appear to substitute anything. I guess the
fact that it is undocumented is a hint that it's the wrong thing to use.
Reading some more, maybe 'absoluteInstallDirs' is what I'm looking for?
In addition to the usual heap of huge config structs, it needs a
CopyDest, though. Since I have no idea what to use, I just put
NoCopyDest there. Does that make sense? Okay, it works now, in the
sense that I ran it once on my laptop, and it copied the file to
~/.cabal/bin. Here is the code, comments welcome:
#!/usr/bin/env runhaskell
import Distribution.Simple (defaultMainWithHooks,
simpleUserHooks,UserHooks(..))
import Distribution.Simple.Setup (InstallFlags,CopyDest(..))
import Distribution.Simple.Utils (rawSystemExit)
import Distribution.PackageDescription (PackageDescription())
import Distribution.Simple.LocalBuildInfo (LocalBuildInfo(..),
InstallDirs(..), absoluteInstallDirs)
import Distribution.Verbosity (normal)
main :: IO ()
main = defaultMainWithHooks simpleUserHooks
{ instHook = \pd lbi uh ifs - myinst pd lbi uh ifs instHook
simpleUserHooks pd lbi uh ifs }
myinst :: PackageDescription - LocalBuildInfo - UserHooks - InstallFlags
- IO ()
myinst pd lbi _uh _fs = do
let bin = bindir $ absoluteInstallDirs pd lbi NoCopyDest
Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
On Jun 5, 2012, at 9:57 AM, Johan Tibell wrote: I don't think applying == to something that contains floating point values at the leaves makes much sense. You want some approxEq function that uses approximate equality on floating point value or you want to equality function that ignores the floating point values. Probably not the answer you like, but I don't know how to define Eq in a robust way for types that include floating point values. I buy that in general for comparing floats (those that result from arithmetic operations), but this is a case where attoparsec's parser is munging the value. I would like to have a law that says parse . print == id ... which is why this seems more like a bug than the usual floating point concerns. This law seems to hold for haskell's double parser: quickCheck (\d - read (show d) == d) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
On Tue, Jun 5, 2012 at 9:12 AM, Warren Harris warrensomeb...@gmail.comwrote: which helps in many cases, but for some the parsing seems bi-stable, alternating between two imprecise double values and causing the test to fail. I was wondering if anyone could suggest a better work-around for this problem, or explain why Attoparsec's double parser can't be isomorphic to haskell's. If you need the full precision, use rational instead. The double parser is there because parsing floating point numbers is often a bottleneck, and double intentionally trades speed for precision. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Extending constraints
On 5 June 2012 18:46, Gábor Lehel illiss...@gmail.com wrote: I must be missing something, but this seems a bit useless to me. You have a phantom type parameter on Proxy, and then you're hiding it. So when you pattern match on ProxyWrapper you recover the fact that there was a type which satisfies the constraint, but you don't know what type it was, and neither do you know about any values which are of the type. What are you trying to do? I need a list of types that satisfy a certain constraint. I would like to have the static guarantee that types that don't satisfy the constraint can't be put in the list, as in: nums :: [ProxyWrapper Num] nums = [ ProxyWrapper (Proxy :: Proxy Int) , ProxyWrapper (Proxy :: Proxy Double) , ProxyWrapper (Proxy :: Proxy String) -- not allowed ] fracs :: [ProxyWrapper Fractional] fracs = [ ProxyWrapper (Proxy :: Proxy Double) , ProxyWrapper (Proxy :: Proxy Float) , ProxyWrapper (Proxy :: Proxy Int) -- not allowed ] That said, if you want to be able to recover a Typeable constraint, I don't see any way except for using 'ProxyWrapper (Ext Typeable constraint)' as Andres says or putting 'forall a. (constraint a, Typeable a)' in the definition of ProxyWrapper. Indeed, I'm now going for the latter option. Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
On Tue, Jun 5, 2012 at 10:51 AM, Bryan O'Sullivan b...@serpentine.com wrote: If you need the full precision, use rational instead. The double parser is there because parsing floating point numbers is often a bottleneck, and double intentionally trades speed for precision. Relevant code in https://github.com/bos/attoparsec/blob/master/Data/Attoparsec/ByteString/Char8.hs -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
On Jun 5, 2012, at 10:51 AM, Bryan O'Sullivan wrote: On Tue, Jun 5, 2012 at 9:12 AM, Warren Harris warrensomeb...@gmail.com wrote: which helps in many cases, but for some the parsing seems bi-stable, alternating between two imprecise double values and causing the test to fail. I was wondering if anyone could suggest a better work-around for this problem, or explain why Attoparsec's double parser can't be isomorphic to haskell's. If you need the full precision, use rational instead. The double parser is there because parsing floating point numbers is often a bottleneck, and double intentionally trades speed for precision. I'm actually using Aeson and the parser it provides, so I don't really have the option of using rational.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tests by properties: origin?
As far as I'm aware: - property-based testing wasn't new (think 'assertions' and then think 'branch coverage') - randomly generated test cases weren't new (look up 'fuzz testing') and there were tools like DGL to generate random test cases in a controlled sort of way + the *type-driven* approach making it nearly effortless to test a property once stated was new. As soon as I met QuickCheck, I knew what it was for and how to use it. The truly astonishing thing was how _easy_ it was to get started. It is true that other languages have since picked up the idea (like Erlang), but without Haskell's type system to drive it, it's not nearly so easy to get started. The Haskell implementation of QuickCheck was a couple of pages of code. The first Erlang implementation is a serious proprietary product. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] converting functional dependencies to type families
Hi all, when I reported a typechecker performance problem related to functional dependencies http://hackage.haskell.org/trac/ghc/ticket/5970 I promised to try to convert from functional dependencies to type families. Thus I converted my code and the llvm package to type-families: http://code.haskell.org/~thielema/llvm-tf/ Here are some of my experiences: == Advantages of TypeFamilies == * Speed For what I did the type families solution was considerably faster than the functional dependencies code at least in GHC-7.4.1. Thus the bug in ticket 5970 does no longer hurt me. (In GHC-6.12.3 the conversion to type families made the compilation even slower.) * Anonymous type function values One of the most annoying type classes of the llvm package was the IsSized class: class (LLVM.IsType a, IsPositive size) = IsSized a size | a - size where size is a type-level decimal natural number. Many llvm functions require that an LLVM type has a size where the particular size is not important. However, I always have to name the size type. I also cannot get rid of it using a subclass, like class (IsSized a size) = IsAnonymouslySized a where The 'size' type is somehow sticky. The conversion of this type class to type families is straightforward: class (IsType a, PositiveT (SizeOf a)) = IsSized a where type SizeOf a :: * Now I have to use SizeOf only if needed. I can also easily define sub-classes like class (IsSized a) = C a where * No TypeSynonymInstances At the right hand side of a 'type instance' I can use type synonyms like type instance F T = String without the TypeSynonymInstance extension. This feels somehow more correct than refering to a type synonym in a class instance head like in instance C T String where The compiler does not need to analyze String in order to find the correct instance. * No FlexibleInstances The same applies to instance C (T a) (A (B a)) which is a flexible instance that is not required for type instance F (T a) = A (B a) * No MultiParamTypeClass, No UndecidableInstances I have some type classes that convert a type to another type and a tuple of types to another tuple of types where the element types are converted accordingly. With functional dependencies: class MakeValueTuple haskellTuple llvmTuple | haskellTuple - llvmTuple where instance (MakeValueTuple ha la, MakeValueTuple hb lb) = MakeValueTuple (ha,hb) (la,lb) The class is a multi-parameter type class and the instance is undecidable. This is much simpler with type families: class MakeValueTuple haskellTuple where type ValueTuple haskellTuple :: * instance (MakeValueTuple ha, MakeValueTuple hb) = MakeValueTuple (ha,hb) where type ValueTuple (ha,hb) = (ValueTuple ha, ValueTuple hb) Thus summarized: Type families may replace several other type extensions. If I ignore the associated type functions then many classes become Haskell 98 with Haskell 98 instances. This is good because those instances prevent instance conflicts with other non-orphan instances. == Disadvantage of TypeFamilies == * Redundant instance arguments I have to write the type arguments both in the instance head and in the function argument. This is especially annoying in the presence of multi-parameter type classes with bidirectional dependencies. E.g. class (a ~ Input parameter b, b ~ Output parameter a) = C parameter a b where type Input parameter b :: * type Output parameter a :: * process :: Causal p (parameter, a) b instance (...) = C (FilterParam a) v (FilterResult v) where type Input (FilterParam a) (FilterResult v) = v type Output (FilterParam a) v = FilterResult v With functional dependencies it was: class C parameter a b | parameter a - b, parameter b - a where process :: Causal p (parameter, a) b instance (...) = C (FilterParam a) v (FilterResult v) where * Bidirectional dependencies In GHC-6.12.3 it was not possible to write class (a ~ Back b, b ~ Forth a) = C a b where Fortunately, this is now allowed in GHC-7. But bidirectional dependencies are still cumbersome to work with as shown in the example above. * Equality constraints are not supported for newtype deriving Not so important, just for completeness: http://hackage.haskell.org/trac/ghc/ticket/6088 == Confusions == * Upper case type function names Why are type function names upper case, not lower case? They are not constructors after all. Maybe this is one reason, why I forget from time to time that type functions are not injective. Sure, lower-case type variables are implicitly forall quantified in Haskell 98. In the presence of lower-case type functions we would need explicit forall quantification. * Why can associated types not be exported by C(AssocType) syntax? Why must they be exported independently from the associated class? * FlexibleContexts The context (Class (TypeFun a)) requires
[Haskell-cafe] [ANNOUNCE] cereal-0.3.5.2
Hi Everyone, I'm happy to announce version 0.3.5.2[1] of the cereal serialization library. This is a bugfix release, mostly improving performance characteristics of the library. One noteable change is with runGetLazy, which will now perform as expected when a parser attempts to consume more input than is available. Happy hacking! --trevor [1] http://hackage.haskell.org/package/cereal-0.3.5.2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Typing Judgments for Haskell2010++
Hi Haskell Cafe! To develop Haskell-Type-Exts (HTE) [1,2], I need to have typing judgments for each language construct in Haskell 2010 with two extensions: RankNTypes and local assumptions (GADTs, Type Functions and etc). Since I could not find any academic paper describing a type system supporting both local assumptions [3] and RankNTypes [4], we tried to combine the two systems. We also tried to extend the type system to support Patterns and some other constructs. The result (in a very sketchy state) is posted at: http://cleantypecheck.wordpress.com/2012/06/06/typing-judgment-rules-14/ Now before I start to implement these rules in HTE, I need to make sure of their validity. Therefore, I'd highly appreciate if experts would take a closer look at these judgement rules and comment. Considering the fact that HTE is a Google SoC project and me being just a motivated student (limited knowledge/experience), the success of this project strongly relies on Haskell community's support. Thanks! /Shayan [1] http://www.google-melange.com/gsoc/project/google/gsoc2012/shayannajd/18001 [2] http://cleantypecheck.wordpress.com/2012/05/03/kickoff/ [3] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) – Modular type inference with local assumptions [4] S. Peyton Jones, D. Vytiniotis, S. Weirich, and M. Shields. Practical type inference for arbitrary-rank types. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Introducing FP Complete
You might have seen a few post by me mentioning FP Complete and asked yourself the question: Who is this guy and what is FP Complete? I haven't been active in the Haskell community, as I'm a relative newcomer to Haskell. I am better known in the C++ community where I've been promoting functional-style programming and the use of Haskell for modelling difficult aspects of template metaprogramming. I've been involved in discussing the support for concurrency and parallelism in C++; which, by the way, is ages behind what Haskell has to offer. It was therefore natural for me to join a newly founded company, FP Complete, whose goal is to commercialize Haskell. I believe that now is the right time for Haskell to become a strong software industry player, especially that functional programming is being widely recognized as the answer to the recent multicore and GPU explosion. I can't be much more specific about what the role of FP Complete will be in making Haskell an industrial success because our plans are still evolving. We should be ready to makes some announcement shortly. I should mention that the support from the part of the Haskell community that we have so far contacted has been overwhelmingly positive. We have Simon P-J's blessing, we are in close collaboration with Well Typed, we have friends at Galois, Parallel Scientific, Amgen, and many other Haskell shops. Hopefully you will hear from and about us more often in the future. -- [:Bartosz Milewski:] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Introducing FP Complete
Welcome to the community Bartosz. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Have you seen this functor/contrafunctor combo?
newtype Q p a = Q (p a - a) instance ContraFunctor p = Functor (Q p) where fmap h (Q w) = Q (h . w . cmap h) using cmap for contravariant map. For instance, p a = u - a. instance ContraFunctor p = Applicative (Q p) where pure a = Q (pure a) Q fs * Q as = Q (\ r - let f = fs (cmap ($ a) r) a = as (cmap (f $) r) in f a) I've checked the functor laws but not the applicative laws, and I haven't looked for a Monad instance. Or extend to a more symmetric definition adding a (covariant) functor f to the contravariant functor p. newtype Q' p f a = Q' (p a - f a) A (law-abiding) Functor instance is easy, but I don't know about an Applicative instance. Have you seen Q or Q' before? They look like they ought to be something familiar useful. -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
