- Haskell-Cafe - Haskell.org

Type families - how to resolve ambiguities?
by DavidA 25 Aug '10

25 Aug '10

Hi, The code below defines a type synonym family: {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-} data Vect k b = V [(b,k)] deriving (Eq,Show) data TensorBasis a b = T a b deriving (Eq, Ord, Show) type family Tensor k u v :: * type instance Tensor k (Vect k a) (Vect k b) = Vect k (TensorBasis a b) class Algebra k v where -- "v is a k-algebra" unit :: k -> v mult :: Tensor k v v -> v instance Algebra Integer (Vect Integer [Int]) where unit 0 = V [] unit x = V [([],x)] mult (V ts) = V [(g++h,x) | (T g h, x) <- ts] Naively I think of the type instance declaration as saying that the two types are synonyms, so I should be able to use one in a context where the other is expected. However, when I try to use the code, I don't seem to be able to get the type inferencer to recognise an object as being of both "types" at the same time. For example: *> mult $ (V [(T [1] [2],3)] :: Vect Integer (TensorBasis [Int] [Int])) <interactive>:1:8: Couldn't match expected type `Tensor k v v' against inferred type `Vect Integer (TensorBasis [Int] [Int])' NB: `Tensor' is a type function, and may not be injective In the second argument of `($)', namely `(V [(T [1] [2], 3)] :: Vect Integer (TensorBasis [Int] [Int]))' In the expression: mult $ (V [(T [1] [2], 3)] :: Vect Integer (TensorBasis [Int] [Int])) In the definition of `it': it = mult $ (V [(T [1] [2], 3)] :: Vect Integer (TensorBasis [Int] [Int])) *> mult $ (V [(T [1] [2],3)] :: Tensor Integer (Vect Integer [Int]) (Vect Integer [Int])) <interactive>:1:8: Couldn't match expected type `Tensor k v v' against inferred type `Vect Integer (TensorBasis [Int] [Int])' NB: `Tensor' is a type function, and may not be injective In the second argument of `($)', namely `(V [(T [1] [2], 3)] :: Tensor Integer (Vect Integer [Int]) (Vect Integer [Int]))' In the expression: mult $ (V [(T [1] [2], 3)] :: Tensor Integer (Vect Integer [Int]) (Vect Integer [Int])) In the definition of `it': it = mult $ (V [(T [1] [2], 3)] :: Tensor Integer (Vect Integer [Int]) (Vect Integer [Int])) Are type families the right mechanism to express what I'm trying to express? If so, what am I doing wrong, and how do I fix it?

2 1

Re: [Haskell-cafe] Hackage on Linux
by Mathew de Detrich 25 Aug '10

25 Aug '10

I used to use archlinux packages however it became a pain for the following reasons - packages on archlinux don't auto update when cabal does. This becomes really annoying when package X gets updated on cabal but not on arch and causes conflicts with other packages - in some situations doing a general update with arch (through clyde or packer) breaks ghc (last time it happened packer tried to uninstall/update arch packages which failed because those packages had dependencies. The files got removed but since unregister failed ghc thought they still existed) Apart from base/required packages, unless your linux distro has proper metapackages its in my opinion just better off using cabal install (and only use arch packages for binaries) On 23/08/2010 2:21 AM, "Brandon S Allbery KF8NH" <allbery(a)ece.cmu.edu> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/22/2010 07:19 AM, Jonas Almström Duregård wrote: >> Now, you say it's preferable to use the na... No, the Windows and OSX installers are just that. They provide no facilities for finding packages, identifying the package a given file came from, or dependency tracking. OSX's installer doesn't even have uninstall support; it records the installed files, but provides no mechanism for undoing configuration changes such as removing package-installed kernel modules. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla -... iEYEARECAAYFAkxxTmoACgkQIn7hlCsL25VNsQCfZKJIz+KONa4yWAI97QYyttGU ITMAnjoAhcj3kMrWxnsSxWb5jraFBu1r =ERlI -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org ...

5 10

Function signatures and type class constraints
by Oscar Finnsson 25 Aug '10

25 Aug '10

Hi, I'm wondering why I have to repeat the class constraints at every function. If I got the data type > data (Eq a, Show a, Data a, Eq b, Show b, Data b, Eq c, Show c, Data c) => Foo a b c = Foo a b c and then a function from Foo to String I have to supply the signature > bar :: (Eq a, Show a, Data a, Eq b, Show b, Data b, Eq c, Show c, Data c) => Foo a b c -> String even though it should be clear that a, b and c *must* fulfill the constraints already so I should be able to just supply the signature > bar :: Foo a b c -> String Another related problem I got is that even though I can create the type > type B = (Eq a, Show a, Data a, Eq b, Show b, Data b, Eq c, Show c, Data c) => Foo a b c I cannot use it like > bar :: B -> String so my type class constraints got a tendency become huge! It is possible to work around this somehow? I'm in a situation at the moment where I got a data type with four fields each with three constraints (Show, Eq, Data), so I have to repeat 12 constraints at every function signature... :( Finally is there some way to bundle type class constraints, something like > data {Eq, Show, Data} {a, b, c} => Foo a b c = Foo a b c -- make believe syntax so I don't have to repeat every constraint and variable all the time? -- Oscar

3 4

Code that writes code
by Andrew Coppin 25 Aug '10

25 Aug '10

I'm working on a small Haskell package. One module in particular contains so much boilerplate that rather than write the code myself, I wrote a small Haskell program that autogenerates it for me. What's the best way to package this for Cabal? Just stick the generated file in there? Or is there some (easy) way to tell Cabal how to recreate this file itself?

11 12

Re: ANNOUNCE: darcs 2.5 beta 4
by Benjamin Franksen 25 Aug '10

25 Aug '10

Benjamin Franksen wrote: > I have trouble building this latest beta. I found that the build uses ghc-6.8.3 which, I think, is no longer supported for building darcs, IIRC. Sorry for the noise. Cheers Ben

2 1

Re: [Haskell-cafe] Fwd: Semantics of iteratees, enumerators, enumeratees?
by John Lato 25 Aug '10

25 Aug '10

From: John Millikin <jmillikin(a)gmail.com> > > Here's my (uneducated, half-baked) two cents: > > There's really no need for an "Iteratee" type at all, aside from the > utility of defining Functor/Monad/etc instances for it. The core type > is "step", which one can define (ignoring errors) as: > > data Step a b = Continue (a -> Step a b) > | Yield b [a] > > Input chunking is simply an implementation detail, but it's important > that the "yield" case be allowed to contain (>= 0) inputs. This allows > steps to consume multiple values before deciding what to generate. > > In this representation, enumerators are functions from a Continue to a > Step. > > type Enumerator a b = (a -> Step a b) -> Step a b > > I'll leave off discussion of enumeratees, since they're just a > specialised type of enumerator. > > ------------- > > Things become a bit more complicated when error handling is added. > Specifically, steps must have some response to EOF: > > data Step a b = Continue (a -> Step a b) (Result a b) > | Result a b > > data Result a b = Yield b [a] > | Error String > > In this representation, "Continue" has two branches. One for receiving > more data, and another to be returned if there is no more input. This > avoids the "divergent iteratee" problem, since it's not possible for > Continue to be returned in response to EOF. > Is this really true? Consider iteratees that don't have a sensible default value (e.g. head) and an empty stream. You could argue that they should really return a Maybe, but then they wouldn't be divergent in other formulations either. Although I do find it interesting that EOF is no longer part of the stream at all. That may open up some possibilities. Also, I found this confusing because you're using Result as a data constructor for the Step type, but also as a separate type constructor. I expect this could lead to very confusing error messages ("What do you mean 'Result b a' doesn't have type 'Result'?") > > Enumerators are similarly modified, except they are allowed to return > "Continue" when their inner data source runs out. Therefore, both the > "continue" and "eof" parameters are Step. > > type Enumerator a b = (a -> Step a b) -> Step a b -> Step a b > I find this unclear as well, because you've unpacked the continue parameter but not the eof. I would prefer to see this as: type Enumerator a b = (a -> Step a b) -> Result a b -> Step a b However, is it useful to do so? That is, would there ever be a case where you would want to use branches from separate iteratees? If not, then why bother unpacking instead of just using type Enumerator a b = Step a b -> Step a John

2 1

[CUFP 2010] Birds of a Feather sessions
by Anil Madhavapeddy 25 Aug '10

25 Aug '10

===================================================================== Birds of a Feather sessions (BOFs) Commercial Uses of Functional Programming Workshop (CUFP 2010) http://cufp.org/bofs-2010 Baltimore, Maryland, September 30 - October 1 ===================================================================== This year, the Commercial Uses of Function Programming (CUFP) workshop has a new feature to bring industry and academics together to promote real-world uses of functional programming. Birds of a Feature (BoF) sessions provide a place for our community to gather informally at ICFP and reach consensus on matters of importance. Any CUFP attendee can propose a BoF session, and grab one of the spare rooms in the evening slots below. Attendance in the evening is open to all. BoF sessions facilitate ad-hoc discussions and provide a place to gather and start off the chat, before moving on during the evening to a local Baltimore restaurant or pub. We particularly encourage "cross-language" discussions that might not otherwise happen at one of the bigger workshops. Please see http://cufp.org/bofs-2010 for details on how to propose a slot or confirm attendance at one of them. There are a couple of sessions already which may be of interest to Haskell developers: Thu 30th Sep 6pm-8pm, Haskell for the Real World, Bryan O'Sullivan and Johan Tibell http://cufp.org/bofs-2010#haskellrw Fri 1st Oct 6pm-8pm, Cross Language Serialisation, Anton Lavrik http://cufp.org/bofs-2010#xlangserial =====================================================================

1 0

Fwd: Semantics of iteratees, enumerators, enumeratees?
by Conal Elliott 25 Aug '10

25 Aug '10

For anyone interested in iteratees (etc) and not yet on the iteratees mailing list. I'm asking about what iteratees *mean* (denote), independent of the various implementations. My original note (also at the end below): With the encouragement & help of Conrad Parker, I've been looking at > iteratees, enumerators, enumeratees. I can find plenty written about them, > but only about benefits and implementation. In sifting through chunks, > error/control messages, and continuations, I find myself longing for a > precise semantic basis. I keep wondering: what simpler & precise semantic > notions do these mechanisms implement? Has anyone worked out a denotational > semantics for iteratees, enumerators, enumeratees -- something that > simplifies away the performance advantages & complexities? I've worked out > something tentative, but perhaps I'm covering old ground. > - Conal ---------- Forwarded message ---------- From: Conal Elliott <conal(a)conal.net> Date: Sun, Aug 22, 2010 at 11:02 PM Subject: Re: Semantics of iteratees, enumerators, enumeratees? To: John Lato <jwlato(a)gmail.com> Hi John, I just remembered: Luke Palmer wrote an accessible & helpful description of this approach to library design. See his post *Semantic Design<http://lukepalmer.wordpress.com/2008/07/18/semantic-design/> *. (I've switched to using the more specific term "denotational design", since I specifically intend denotational semantics, not operational.) Denotational design is at the heart of most of what I do, particularly including the three pieces of work you mentioned: functional images (Pan), FRP, and automatic differentiation. My main goal is simplicity with precision. Without the precision, I can't tell whether the simplicity is real or illusory. We functional programmers have a strong advantage over imperative programming (including OO) in that we can achieve semantic precision. I want to see us exploit this advantage! And not settle for being a power tool for generating semantically inscrutable imperative computations. Regards, - Conal On Sun, Aug 22, 2010 at 10:43 PM, John Lato <jwlato(a)gmail.com> wrote: > Hi Conal, > > I've always regarded your work in essentially the same category as Edward > Kmett's (and most of Oleg's): stuff that's incredible powerful and concise, > but I can't understand at all what it means. I've admired a lot of your > work, particularly on Pan, FRP, and automatic differentiation, but most of > the rest I couldn't understand at all. > > I'll take a look at your *Denotational Design* paper again; maybe now that > I have a lot more experience I'll be able to make sense of it. > > John > > > On Sun, Aug 22, 2010 at 8:18 AM, Conal Elliott <conal(a)conal.net> wrote: > >> Hi John, >> >> Thanks for the reply. A denotational semantics would be independent of >> any implementation, so it would apply to any of them, as long as they have >> the same programming interface. The purpose is to simply & precisely say >> what the types and their building blocks (API) mean by providing a precise, >> implementation-independent, and simple-as-possible math model. Such a >> semantics can be used to prove properties and to define correctness of any >> implementation. It also gives clear feedback on how elegant or inelegant a >> library design is. >> >> For instance, given a type, Map k v, of finite maps, we might say the >> meaning is the type of partial functions from k to v, either k -> v (where >> absent is _|_) or k -> Maybe v (where absent is Nothing). Then we'd give >> the meaning of each Map operation as a function of the meanings of its >> arguments. This example and several others are given in the paper *Denotational >> design with type class morphisms<http://conal.net/papers/type-class-morphisms/> >> *. >> >> Regards, - Conal >> >> On Sun, Aug 22, 2010 at 8:31 PM, John Lato <jwlato(a)gmail.com> wrote: >> >>> Hi Conal, >>> >>> To my knowledge, nobody has attempted this. Oleg may have some ideas, >>> but I don't think he's written about it. I really don't know anything about >>> denotational semantics, so I couldn't do this myself. For some time I've >>> thought it would be good if somebody were able to put together a formal >>> semantics for iteratees, so I'd be very interested if you'd share what you >>> have so far. >>> >>> Would a denotational semantics apply equally to multiple implementations, >>> or would it be tied to a specific implementation? >>> >>> John >>> >>> On Sun, Aug 22, 2010 at 3:47 AM, Conal Elliott <conal(a)conal.net> wrote: >>> >>>> With the encouragement & help of Conrad Parker, I've been looking at >>>> iteratees, enumerators, enumeratees. I can find plenty written about them, >>>> but only about benefits and implementation. In sifting through chunks, >>>> error/control messages, and continuations, I find myself longing for a >>>> precise semantic basis. I keep wondering: what simpler & precise semantic >>>> notions do these mechanisms implement? Has anyone worked out a denotational >>>> semantics for iteratees, enumerators, enumeratees -- something that >>>> simplifies away the performance advantages & complexities? I've worked out >>>> something tentative, but perhaps I'm covering old ground. >>>> >>>> - Conal >>>> >>>> _______________________________________________ >>>> Iteratee mailing list >>>> Iteratee(a)projects.haskell.org >>>> http://projects.haskell.org/cgi-bin/mailman/listinfo/iteratee >>>> >>>> >>> >> >

9 20

Re: [Haskell-cafe] Fwd: Semantics of iteratees, enumerators, enumeratees?
by John Lato 25 Aug '10

25 Aug '10

> > From: "C. McCann" <cam(a)uptoisomorphism.net> > > What sets an iteratee-style design apart from something conventional > based on a State monad is that the iteratee conceals its internal > state completely (in fact, there's no reason an iteratee even has to > be the "same" function step-to-step, or have a single consistent > "state" type--almost has an existential flavor, really), but is at > another function's mercy when it comes to actually doing anything. > > All of which doesn't really shed too much light on the denotation of > these things, I suppose, as there's barely anything there to talk > about; the iteratee automaton itself is a terribly simple construct, > relying on an underlying monad to perform actions, on an external > "push" data source to recurse, and being given only bite-size chunks > of data at each step. It's little more than foldl with a "pause" > button attached. > This is how I think of them. I particularly your description of them as a foldl with a "pause" button. Maybe it would be helpful to consider iteratees along with delimited continuations? John

3 2

Re: [Haskell-cafe] Hackage on Linux
by Mathew de Detrich 25 Aug '10

25 Aug '10

In all honesty I think the issue is that archlinux AUR packages are being generated in a very naive way (and not a Archlinux philosophy in general). The whole point of AUR is that its supposed to make it very easy for people to upload packages/libraries. In my opinion putting such packages in AUR in the first place (apart from the 'required' and 'basic' packages) was a mistake in the first place. I had numerous issues with AUR haskell libraries before (because those packages being in AUR kind of gives the impression they are supposed to be used over cabal) The thing is, libraries at least should be automated. There are just way too many packages in Hackage for someone to go through and manually check if something goes wrong, and you get the issues described previously in conflicts of latest version and outdated versions of libraries installed through AUR/cabal (and in my case having to manually go through and use cabal2arch to fix things was taking up way too much time). C/C++ libraries can be checked by hand because there aren't many of them (as mentioned earlier) where as the 'Haskell' way of doing things is using lots of smaller modularized libraries. If people just wanted an auto udpate version of cabal that works through arch's package management, then there should have just been a pacman wrapper which when you install/update haskell libraries/packages, it creates a local package through cabal2arch instead of using AUR. You either have everything properly updated (assuming it doesn't fail building for w/e reason) or if you want to 'clone' cabal onto AUR, then only do it for the necessary/base/required packages which is easy to keep track of On Wed, Aug 25, 2010 at 3:01 PM, Ivan Lazar Miljenovic < ivan.miljenovic(a)gmail.com> wrote: > On 25 August 2010 14:56, Mathew de Detrich <deteego(a)gmail.com> wrote: > > Thanks for clearing the stuff up. The issue is Ivan, that the archlinux > aur > > packages are auto generated (even the "official ones"). The only packages > > that I believe were ever done by hand was gt2hs (old gtk version) and > since > > its changed to gtk that isn't the case anymore > > Which I've argued with Don about before. Automation is good, but you > should then double-check what it spits out. > > (Note also that in Gentoo, we abstract away the actual interaction > with Cabal so for simple libraries we just have to specify things like > dependencies, download location, etc.). > > > If there is some issue (like you explained with the --flag=-have-gio > flag) > > archlinux aur would have the same problem. To make things more clear, > here > > is an example of the pkgbuild for gtk (from AUR) > > http://aur.archlinux.org/packages/haskell-gtk/haskell-gtk/PKGBUILD > > As you can see, all the script does is invoke runhaskell > > configure/build/haddock etc etc and then registers it with GHC. Thats the > > exact same with every other AUR package, and it isn't any different from > > doing a cabal install (which invokes configure/build/haddock anyways). > That > > pkgbuild generates the actual package you install through pacman, only > > difference being the library is already built (but it still registers > > through GHC). Likewise the uninstalling is the same story > > Yup: I think Don's approach of "oh, if we want to change something > we'll just re-generate them all" rather short-minded (then again, that > seems to be the whole point of Arch, one reason why if I give up > Gentoo I'm more likely to go to Fedora than Arch). > > > So the issues you stated would also be the case with AUR, which means I > am > > not worse off using cabal-install > > Except if you help out with AUR, you can try to make these things better... > ;-) > > And that uninstallation with AUR should be easier/better than what > cabal-install can do, and the ability to specify non-Haskell deps. > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic(a)gmail.com > IvanMiljenovic.wordpress.com >

4 4