- Haskell-Cafe - Haskell.org

Mapping over Type Level Literals
by Dominic Steinitz 17 Sep '14

17 Sep '14

I was playing around with Haar functions and realised I could encode the constraints in the types > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE KindSignatures #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE Rank2Types #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > import GHC.TypeLits > > import Data.Proxy > > > data Haar (a :: Nat) (b :: Nat) = Haar { unHaar :: Double -> Double } > > > haar :: forall n k . > > (KnownNat n, KnownNat k, (2 * k - 1 <=? 2^n - 1) ~ 'True) => > > Haar n (2 * k - 1) > > haar = Haar g where > > g t | (k' - 1) * 2 ** (-n') < t && t <= k' * 2 ** (-n') = 2 ** ((n' - 1) / 2) > > | k' * 2 ** (-n') < t && t <= (k' + 1) * 2 ** (-n') = -2 ** ((n' - 1) / 2) > > | otherwise = 0 > > where > > n' = fromIntegral (natVal (Proxy :: Proxy n)) > > k' = 2 * (fromIntegral (natVal (Proxy :: Proxy k))) - 1 So now I can do e.g. > *Main> unHaar (haar :: Haar 3 7) 0.05 > 0.0 > *Main> unHaar (haar :: Haar 3 6) 0.05 > > <interactive>:359:9: > Couldn't match type ‘2 * k0’ with ‘7’ > The type variable ‘k0’ is ambiguous > Expected type: 'True > Actual type: ((2 * k0) - 1) <=? ((2 ^ 3) - 1) > In the first argument of ‘unHaar’, namely ‘(haar :: Haar 3 6)’ > In the expression: unHaar (haar :: Haar 3 6) 0.05 > In an equation for ‘it’: it = unHaar (haar :: Haar 3 6) 0.05 > *Main> unHaar (haar :: Haar 3 9) 0.05 > > <interactive>:360:9: > Couldn't match type ‘'False’ with ‘'True’ > Expected type: 'True > Actual type: ((2 * 5) - 1) <=? ((2 ^ 3) - 1) > In the first argument of ‘unHaar’, namely ‘(haar :: Haar 3 9)’ > In the expression: unHaar (haar :: Haar 3 9) 0.05 > In an equation for ‘it’: it = unHaar (haar :: Haar 3 9) 0.05 > *Main> So errors get rejected at compilation time as one would like and with moderately informative error messages. But now of course I would like to map over n and k but these are at the type level. Can this be done? I imagine unsafeCoerce would have to come into it somewhere. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

4 6

Re: [Haskell-cafe] Type union
by oleg＠okmij.org 17 Sep '14

17 Sep '14

Type unions are also necessary for extensible effects. In fact, they are the foundation of extensible effects. One implementation http://okmij.org/ftp/Haskell/extensible/TList.hs uses only common and uncontroversial extensions (No Typeable). It could be converted to closed type families. The other, more optimal implementation, relies on Typeable, so that injection and projection become constant time, regardless of the size of the union. The Typeable constraint can be dispensed with; see the HList implementation of type-indexed coproducts (TIC), which are essentially open unions.

1 0

Re: [Haskell-cafe] [QuickCheck] Fwd: an idea for improving 'shrink'
by Petr Pudlák 17 Sep '14

17 Sep '14

Hi Nick, you're right, this example is indeed problematic. I'll try to think about it how to get around that, keeping backward compatibility. Petr Dne 11. 9. 2014 21:37 "Nick Smallbone" <nicsma(a)chalmers.se> napsal(a): > Hi Petr, > > My attitude has always been "just use the shrink instance for tuples". > I don't think there's all that much difference between: > shrink (C x y) = [ C x' y' | (x', y') <- shrink (x, y) ] > and: > shrink (C x y) = C <$> shrink x <*> shrink y > The second is certainly nicer, but neither way is really very painful. > > However, your shrinkOne example shows a case where shrinking tuples > doesn't work and you really need a shrinking Applicative. > So this is a good reason to add a shrinking Applicative to QuickCheck > and I would probably like to do it at some point. > > There is a problem with your current patch, though. Namely the default > implementation of shrinkA: > shrinkA = pure > If someone defines shrink but not shrinkA, then shrinkA will not > shrink! In fact, one of your examples exhibits this bug: > shrinkA (Branch x l r) = > Branch <$> shrinkA x <*> shrinkA l <*> shrinkA r > If the Arbitrary instance for whatever x is defines shrink but not > shrinkA, then this will do the wrong thing. > > So we can't provide a default implementation for shrink in terms of > shrinkA, or vice versa, because we want the user to be able to define > either. We can't even define both in terms of the other because then > the default implementation will loop instead of returning []. > > Probably we would just have to move shrinkA outside of the Arbitrary > class. This does make using the Applicative more cumbersome, e.g.: > shrink (C x y) = fromShrink (C <$> shrinkA x <*> shrinkA y) > shrinkOne shr = fromShrink . traverse (Shrink . shr) > but maybe this would still be useful for defining trickier shrink > functions. > > Anyway, this is the only worry I have - how to integrate the > traditional and applicative-based shrinking without too much syntactic > overhead. If we can come up with a good solution for that then I'd be > very eager to add this to QuickCheck. Or maybe calling fromShrink > isn't so painful and we should add it anyway. I will think it over a > bit... > > Nick > > On Saturday 06 September, 2014 at 11:17 am, Petr Pudlák wrote: > > 2014-09-05 18:22 GMT+02:00 Bryan O’Sullivan <bos(a)serpentine.com>: > > > > > > > On Thu, Sep 4, 2014 at 1:06 PM, Petr Pudlák <petr.mvd(a)gmail.com> > wrote: > > > > > >> since I got no response from the QuickCheck mail address, so I'm > > >> resending it here, if someone wants to comment on the idea. > > >> > > > > > > I don't think it pays its way: it makes shrink a bit tidier, at the > cost > > > of breaking backwards compatibility in a widely used library. > > > > > That’s a problem. But I believe it the patch addresses it. QuickCheck > > always uses ‘shrink’, not ‘shrinkA’, and as the default implementation of > > ‘shrink’ is defined in terms of ‘shrinkA’, then it’s possible to define > > instances both using ‘shrink’ and using ‘shrinkA’. So both old code and > new > > code that wants to take advantage of the Applicative interface work. > > > > I believe that in the long term this change would pay off: Compare the > old > > code > > > > shrinkOne [] = [] > > shrinkOne (x:xs) = [ x':xs | x' <- shr x ] > > ++ [ x:xs' | xs' <- shrinkOne xs ] > > > > shrink (x, y) = > > [ (x', y) | x' <- shrink x ] > > ++ [ (x, y') | y' <- shrink y ] > > > > shrink (x, y, z) = > > [ (x', y', z') > > | (x', (y', z')) <- shrink (x, (y, z)) ] > > > > against the improved piece > > > > traverse shr xs -- replaces the whole shrinkOne > > shrinkA (x, y) = liftA2 (,) (shrinkA x) (shrinkA y) > > shrinkA (x, y, z) = liftA3 (,,) (shrinkA x) (shrinkA y) (shrinkA z) >

1 0

ANN: HacBerlin - Haskell Hackathon in Berlin, 26-28 Sep 2014
by Stefan Wehr 17 Sep '14

17 Sep '14

Hi everyone, this is just a quick reminder: The Haskell Hackathon in Berlin starts in 9 days and there are very few places left. Please register now: http://goo.gl/aLfnWu Where: Berlin, Germany When: Fri 26 - Sun 28 September 2014 We will do lots of Haskell hacking and listen to two excellent talks: * Beyond Parsec -- Revisiting Parser Combinators, by Andres Löh * Chordify: Advanced Functional Programming for Fun and Profit, by José Pedro Magalhães Meet in Berlin, discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! For all details, visit our wiki page (http://www.haskell.org/haskellwiki/HacBerlin2014) and make sure to register now! Cheers, Stefan

1 0

a question about cabal files
by Kazu Yamamoto 17 Sep '14

17 Sep '14

Hi cafe, I'm developing a library. In this package, some tools for development are included. I would like to compile these tools when I'm developing but I don't want users to compile them. Are there any ways to express such modes in cabal files? ("Executable" cannot be located under "if".) Or should I prepare a separated package for the development tools? Regards, --Kazu

2 2

Re: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a)
by trevor cook 17 Sep '14

17 Sep '14

Jason, John, Thanks for the in depth descriptions, it was just what I was looking for. Trevor

7 8

Hackage package "synopsis" sections
by Richard Lewis 17 Sep '14

17 Sep '14

Hi there, If any of you have ever used CPAN you may agree with me that the synopsis sections customarily included in each package's POD are generally invaluable for getting a quick overview of how to use the facilities provided by that package. I wonder if we might be able to encourage the Hackage community to do something similar? Perhaps in the cabal description authors could include a synopsis with a few code examples? Obviously, I ought to start the ball rolling but I don't actually have any code published on Hackage. Any thoughts? Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis @lewisrichard http://web.rjlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

12 28

Hello and type-level SKI
by Tslil Clingman 17 Sep '14

17 Sep '14

Greetings all, I've been reading this list for a short while and I thought I'd like to begin to contribute where possible. This message pretty much serves to say: - Hello, Haskell! - This community is great, and it's always been a great pleasure to read the newsgroup(s) - Here is a small and likely multiply re-re-discovered `proof' of why the type system is Turing Complete > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, > FlexibleInstances, FlexibleContexts, UndecidableInstances #-} > data S2 x y > data S1 x > data S > data K1 x > data K > data I > class Apply a b c | a b -> c > instance Apply K x (K1 x) > instance Apply S x (S1 x) > instance Apply (S1 x) y (S2 x y) > instance Apply I x x > instance Apply (K1 x) y x > instance (Apply x z xz, Apply y z yz, Apply xz yz a) => Apply (S2 x y) z a > -- The core function > apply :: (Apply a b c) => a -> b -> c > apply _ _ = undefined > -- Hereendeththelesson -- > -- For `ease of use', but not strictly necessary > data X > data Y > data Z > s = undefined :: S > k = undefined :: K > i = undefined :: I > x = undefined :: X > y = undefined :: Y > z = undefined :: Z > -- Example > reverse = apply (apply s (apply k (apply s i))) k I just thought I'd share this snippet here, but if this is not the right place, or it's too long or something please don't hesitate to let me know. Thanks for your attention, Yours &c., Tslil

8 20

Re: [Haskell-cafe] Temporarily taking over hdevtools on Hackage
by Schell Scivally 16 Sep '14

16 Sep '14

I talked with Erik the admin@hackage about taking over hdevtools and he suggested waiting another week before invading. In the meantime he suggested asking a hackage trustee to please upload this git branch to hackage (https://github.com/schell/hdevtools/tree/cabal-support-ghc7.8) Thank you and let me know if there is anything else I can do to help! -- Schell Scivally | github <https://github.com/schell> | twitter <http://twitter.com/schellsan> | blog <http://efnx.com> | wiki <http://wiki.zyghost.com>

3 3

Re: [Haskell-cafe] Hackage package "synopsis" sections
by Britt Mathis 16 Sep '14

16 Sep '14

I meant to post this about 30 minutes ago, but I accidentally sent it only to Michael Snoyman. It seems to me that there are two use cases here - documentation inside code and documentation that stands alone. I agree with you, Michael, that there is no reason why you shouldn't be able to use whichever documentation method you prefer in your readme file. Since it stands alone, it should be trivial to include support for a multitude of formats and display the resulting documentation on Hackage. I think where Mateusz' opinion differs is on the inclusion of markdown in source files (correct me if I am wrong): > More importantly, Markdown > is not suited for documenting code. We'd have to introduce new > identifiers if we wanted to link to some functions from our synopsis. > 16th standard aside, this is quickly starts looking like Haddock. As he says, there are problems with using markdown this way. I think it would be beneficial to have a defacto standard for documentation that lives inside source files - this would prevent it from changing from file to file and provide consistency across the community's code-base. Because the haskell community controls haddock it is in a better position to evolve to our needs. Some flavor of markdown that has a user-base outside the haskell community may not be willing to incorporate changes that make it a better fit for living inside haskell source files, so we would have to maintain our own fork of it anyway. Why duplicate the work that has already been done? I think if the community has a problem with haddock syntax that can be discussed and, if need be, changed. But I do believe that there should be consistency in source file documentation. The last problem I see is the cabal problem. It seems that cabal has trouble handling edge cases, and I think that is again something we can work on (I may even look into it myself - I have been looking for a project). It seems like it would be a good idea to only include small blurbs about the project in the .cabal file, and to separate the larger documentation into a README file, like is done on github. The reasoning behind this is two-fold: 1) Cabal files are human readable. They give us insight into the dependencies a project requires, and including full documentation here would make it harder to get a quick overview of the project (I know most people use hackage for this, but cabal was chosen over formats like XML specifically because it was meant to be read and understood by humans). 2) Separating the README file allows users to choose their favorite format, and be certain that it will be formatted as it was intended (cabal can't be expected to handle every edge case of every format - there are far too many, and Pandoc already does a great job translating between formats).

1 0