Re: [Haskell-cafe] Category Theory Questions
On 4/9/12 12:37 AM, Sergiu Ivanov wrote: I am currently studying category theory by the book Joy of Cats. Are there any people whom I could ask some questions related to category theory from time to time? Or could I just post my questions here directly? In addition to the math venues others've mentioned, if you're into IRC then you can also try #haskell-in-depth and ##categorytheory for a more real-time interaction. For quick/beginner questions that's probably better than either mailing lists or stackoverflow (unless the latter are specifically dedicated to the topic). That said, there are a number of us here who're familiar with CT and willing to provide pointers, insights, and discussions. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory Questions
On Mon, Apr 9, 2012 at 9:47 AM, wren ng thornton w...@freegeek.org wrote: On 4/9/12 12:37 AM, Sergiu Ivanov wrote: I am currently studying category theory by the book Joy of Cats. Are there any people whom I could ask some questions related to category theory from time to time? Or could I just post my questions here directly? In addition to the math venues others've mentioned, if you're into IRC then you can also try #haskell-in-depth and ##categorytheory for a more real-time interaction. For quick/beginner questions that's probably better than either mailing lists or stackoverflow (unless the latter are specifically dedicated to the topic). Ah, that's great, thank you! I couldn't even imagine that there was an IRC channel on CT! That said, there are a number of us here who're familiar with CT and willing to provide pointers, insights, and discussions. I think I could notice that, this is why I asked this question here :-) Thank you everyone for your feedback! Sergiu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] building ghc on arch linux ARM?
On 09/04/2012 00:45, Joey Hess wrote: Thomas DuBuisson wrote: On Sun, Apr 8, 2012 at 4:03 PM, Francesco Mazzolif...@mazzo.li wrote: No, it is not possible to build GHC without GHC. Building GHC on ARM is going to be extremely tricky (I'm not sure anyone has ever done it). I used to use an unregistered build of GHC built by someone in the Debian community - it worked well enough. It ships with Debian, along with the full Haskell Platform built for ARM and lots of other libraries. Other than speed, it's fine. Hmmm... I wonder if it will squeeze onto a Raspberry Pi :) #g -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Guide for converting existing code to Conduit 0.4?
Hi all, Is there some sort of a guide for converting existing code Conduit 0.4? What happened to Control.Monad.Trans.Resource.with? What happens to stuff that used to to have a type C.Source m a which now seems to need type C.Pipe Void a (ResourceT m) a? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
I transfered my code from 0.3 to 0.4 without any changes. There are type synonyms in Conduit for that. Changes were from 0.2 to 0.3. Michael discribed it here http://www.yesodweb.com/blog/2012/03/announcing-conduit-0-3 Actually, in 0.4 no changes with Control.Monad.Trans.Resource. type Source m a = Pipe Void a m () old Conduit-API use type synonyms and not changed 2012/4/9 Erik de Castro Lopo mle...@mega-nerd.com Hi all, Is there some sort of a guide for converting existing code Conduit 0.4? What happened to Control.Monad.Trans.Resource.with? What happens to stuff that used to to have a type C.Source m a which now seems to need type C.Pipe Void a (ResourceT m) a? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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] Guide for converting existing code to Conduit 0.4?
Dmitry Olshansky wrote: I transfered my code from 0.3 to 0.4 without any changes. There are type synonyms in Conduit for that. Changes were from 0.2 to 0.3. Michael discribed it here http://www.yesodweb.com/blog/2012/03/announcing-conduit-0-3 Ok, so Control.Monad.Trans.Resource.with gets replaced with Control.Monad.Trans.Resource.allocate. Actually, in 0.4 no changes with Control.Monad.Trans.Resource. type Source m a = Pipe Void a m () old Conduit-API use type synonyms and not changed My code has a lot of low level Conduit stuff and hence I run into a bunch of the lower level issues. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On Mon, Apr 9, 2012 at 12:58 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Hi all, Is there some sort of a guide for converting existing code Conduit 0.4? What happened to Control.Monad.Trans.Resource.with? What happens to stuff that used to to have a type C.Source m a which now seems to need type C.Pipe Void a (ResourceT m) a? Hmm... I'd be surprised if you really need the Pipe signature that you're providing. That would mean that you are providing an output stream of `a`, PLUS a final result of `a`. Most likely, what you want is: Pipe Void a (ResourceT m) () which would be identical to: Source (ResourceT m) a The recommended approach though would be more like: MonadResource m = Source m a Since that gives more flexibility about where in your monad stack you place the ResourceT. Michael Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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] Guide for converting existing code to Conduit 0.4?
Michael Snoyman wrote: Hmm... I'd be surprised if you really need the Pipe signature that you're providing. I'm not providing it, the compiler is suggesting it: Network/HTTP/Proxy.hs:835:47: Couldn't match expected type `ByteString' with actual type `()' Expected type: C.Pipe Void ByteString (ResourceT IO) ByteString Actual type: C.Source (ResourceT IO) ByteString In the return type of a call of `requestBody' In the second argument of `($)', namely `requestBody req' For the code: HC.requestBody = HC.RequestBodySource contentLength $ fmap copyByteString $ Wai.requestBody req but the type of the RequestBodySource constructor and Wai.requestBody hasn't changed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On Mon, Apr 9, 2012 at 2:27 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Michael Snoyman wrote: Hmm... I'd be surprised if you really need the Pipe signature that you're providing. I'm not providing it, the compiler is suggesting it: Network/HTTP/Proxy.hs:835:47: Couldn't match expected type `ByteString' with actual type `()' Expected type: C.Pipe Void ByteString (ResourceT IO) ByteString Actual type: C.Source (ResourceT IO) ByteString In the return type of a call of `requestBody' In the second argument of `($)', namely `requestBody req' For the code: HC.requestBody = HC.RequestBodySource contentLength $ fmap copyByteString $ Wai.requestBody req but the type of the RequestBodySource constructor and Wai.requestBody hasn't changed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe It's caused by fmap. This is one of the downsides with the move to a single type: some of the instances don't make sense anymore. In particular, Functor will allow you to map the *result* type, not the *output* type. I think I'll add a helper function- mapOutput- to the next version of conduit. Meanwhile, you can use: Wai.requestBody req $= Data.Conduit.List.map copyByteString Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On 9 April 2012 21:34, Michael Snoyman mich...@snoyman.com wrote: It's caused by fmap. This is one of the downsides with the move to a single type: I've been reading the various posts you've been making about Conduit, and this is something I still don't get: wasn't one of the original strengths you touted for Conduit that usage of different types made for better error messages, etc.? As such, why have you now switched to a single type and thus causing these kinds of problems again? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Guide for converting existing code to Conduit 0.4?
On Mon, Apr 9, 2012 at 2:37 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 9 April 2012 21:34, Michael Snoyman mich...@snoyman.com wrote: It's caused by fmap. This is one of the downsides with the move to a single type: I've been reading the various posts you've been making about Conduit, and this is something I still don't get: wasn't one of the original strengths you touted for Conduit that usage of different types made for better error messages, etc.? As such, why have you now switched to a single type and thus causing these kinds of problems again? Honestly, I'm still torn on this. If you read through the arguments in Reddit, you'll see a lot of: Everyone else: Well, obviously this is more elegant because it's a single type Me: Err I'm not convinced. There *are* definitely advantages to this new approach, but there are also costs. The fact that such a huge part of the codebase simply disappeared, and that it's easier to step through the remaining code and convince myself that it's doing the right thing, is what put me over the edge on this one. To clarify just a bit: the *main* advantage of conduit's multiple types approach (versus enumerator where everything is an Iteratee) is that (1) it's easier to understand, and (2) it makes it possible to do things like resumable sources. Both of those advantages still hold: writing a Conduit retains its relative simplicity versus an Enumeratee in this new system, for example. The downside is really the error messages and the instances. It might be that we decide to introduces newtype wrappers for Source, Conduit, and Sink in the future to solve these problems, I'm not sure. For now, it seems like an acceptable trade-off. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: plugins-1.5.2.1
Hello! I am pleased to announce the release of plugins-1.5.2.1: http://hackage.haskell.org/package/plugins The plugins library provides facilities to compile and dynamically load/link Haskell code into a running Haskell application. (The related, plugins-auto package adds support for file watching via inontify and automatic recompilation and reloading, http://hackage.haskell.org/package/plugins). There are three important changes in this release: 1. Support for GHC 7.0, 7.2. and 7.4. We have not *knowingly* dropped support for GHC 6.12. So, if you still use an older compiler and we broke it.. we might be willing to fix it still :) 2. New maintainer: Don Stewart has graciously allowed me to take over the project. I do not have any immediate plans for big changes. But I do plan to: keep it compiling, apply patches in a timely manner, and deal with other minor bug fixes. I would certainly love to see some major improvements. I believe plugins predates the GHC API and, accordingly, does not use it as well as it could. If someone wanted to give plugins some major love, that would be awesome. While plugins has not much recent development, there are still a lot of people that are using it, or would like to. 3. the source has moved to patch-tag and darcs 2, http://patch-tag.com/r/stepcut/plugins patch-tag only supports darcs 2 format repositories, so this forced me to run darcs convert to switch from darcs 1 to darcs 2 format. In the end that is a good thing. The only downside is that I can not directly apply any darcs 1 patches to the repo now. But I doubt there are many floating around anyway. And I can still apply them the hard way. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
On Thu, Apr 5, 2012 at 7:14 AM, Grigory Sarnitskiy sargrig...@ya.ru wrote: Hello! I've just realized that Haskell is no good for working with functions! First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. The usual set theoretic definition is constructive -- it is the extension of the definition which is non-constructive. We can restrict the extension to constructive domains. Note that we do not need the law of the excluded middle or double negation to define a function. We can easily define: newtype Function a b = Function (Set (a,b)) apply :: (Function a b) - a - b apply f a = findMin . filter (\(a',_) - a == a') $ f and enforce the function definition/axioms with a smart constructor. (A Map is probably a better data structure for this purpose) Obviously, that's not all of the imaginable possibilities. One also can rewrite programs. And write programs that rewrite programs. And write programs that rewrite programs that rewrite the first programs and so on. But there is no such possibility in Haskell, except for introducing a DSL. You will always need a DSL of some kind. Otherwise, what will you quantify over? This is an important point. In order to give a function semantics, it /must/ be interpreted. This will either happen by the compiler, which interprets a function definition in terms of machine code (or Haskell code, if you use Template Haskell), or at run-time, as in the Function a b type above. With some appropriate constraints, you can even rewrite a (-)-function in terms of a Function-function, and vice-versa. toFunction :: (Enum a, Bounded a) = (a - b) - (Function a b) toFunction f = Set.fromList . fmap f $ [minBound..maxBound] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: plugins-1.5.2.1
Hello, I will update the description. The documentation is not on hackage yet because the haddock builder only runs a few times a day. That should correct itself in a few hours -- unless the build fails for some reason. However, the API has not changed from the previous version, so these docs are still valid: http://hackage.haskell.org/package/plugins-1.5.1.4 - jeremy On Mon, Apr 9, 2012 at 1:21 PM, Jeremy Shaw jer...@n-heptane.com wrote: Hello! I am pleased to announce the release of plugins-1.5.2.1: http://hackage.haskell.org/package/plugins The plugins library provides facilities to compile and dynamically load/link Haskell code into a running Haskell application. (The related, plugins-auto package adds support for file watching via inontify and automatic recompilation and reloading, http://hackage.haskell.org/package/plugins). There are three important changes in this release: 1. Support for GHC 7.0, 7.2. and 7.4. We have not *knowingly* dropped support for GHC 6.12. So, if you still use an older compiler and we broke it.. we might be willing to fix it still :) 2. New maintainer: Don Stewart has graciously allowed me to take over the project. I do not have any immediate plans for big changes. But I do plan to: keep it compiling, apply patches in a timely manner, and deal with other minor bug fixes. I would certainly love to see some major improvements. I believe plugins predates the GHC API and, accordingly, does not use it as well as it could. If someone wanted to give plugins some major love, that would be awesome. While plugins has not much recent development, there are still a lot of people that are using it, or would like to. 3. the source has moved to patch-tag and darcs 2, http://patch-tag.com/r/stepcut/plugins patch-tag only supports darcs 2 format repositories, so this forced me to run darcs convert to switch from darcs 1 to darcs 2 format. In the end that is a good thing. The only downside is that I can not directly apply any darcs 1 patches to the repo now. But I doubt there are many floating around anyway. And I can still apply them the hard way. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: pipes-core 0.1.0
I'm pleased to announce the release of version 0.1.0 of pipes-core, a library for efficient, safe and compositional IO, similar in scope to iteratee and conduits. http://hackage.haskell.org/package/pipes-core This release fixes a mistake in the previous version which violated the category laws in certain cases. I have now written a fairly explicit proof of the category laws for the current implementation, which I'll try to keep updated as the library evolves: https://github.com/pcapriotti/pipes-core/wiki/Category-laws-for-pipes --- # CHANGELOG for pipes-core: ## Version 0.1.0 - Significant simplification of the internals. - Removed `ensure` primitive. # CHANGELOG for pipes-extra: ## Version 0.1.0 - Improved naming in Control.Pipe.Coroutine. - Replaced ChunkPipe with PutbackPipe. --- BR, Paolo Capriotti ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I Need a Better Functional Language!
A concurring opinion here, and an example. iff :: Bol - a - a - a iff True x _ = x iff False _ x = x f, g :: Bool - Bool f x = x g x = iff x True False Are these two functions equal? I would say yes, they are. Yet once you can pattern match on functions, you can easily tell these functions apart, and create a function h :: (Bool - Bool) - Bool such that h f = True but h g = False. -- ryan On Thu, Apr 5, 2012 at 8:52 AM, Dan Doel dan.d...@gmail.com wrote: On Thu, Apr 5, 2012 at 10:14 AM, Grigory Sarnitskiy sargrig...@ya.ru wrote: First, what are 'functions' we are interested at? It can't be the usual set-theoretic definition, since it is not constructive. The constructive definition should imply functions that can be constructed, computed. Thus these are computable functions that should be of our concern. But computable functions in essence are just a synonym for programs. This is a flawed premise. The point of working with functions is abstraction, and that abstraction is given by extensional equality of functions: f = g iff forall x. f x = g x So functions are not synonymous with programs or algorithms, they correspond to an equivalence class of algorithms that produce the same results from the same starting points. If you can access the source of functions within the language, this abstraction has been broken. And this abstraction is useful, because it allows you to switch freely between programs that do the same thing without having to worry that someone somewhere is relying on the particular algorithm or source. This is the heart of optimization and refactoring and the like. There are places for metaprogramming, or perhaps even a type of algorithms that can be distinguished by means other than the functions they compute. But to say that functions are that type is false, and that functions should mean that is, I think, wrong headed. -- Dan ___ 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] GHCi runtime linker: fatal error (was Installing REPA)
On 08/04/2012, at 2:41 AM, Dominic Steinitz wrote: Hi Ben, Chris and Others, Thanks for your replies and suggestions. All I want to do is invert (well solve actually) a tridiagonal matrix so upgrading ghc from the version that comes with the platform seems a bit overkill. I think I will go with Chris' suggestion for now and maybe upgrade ghc (and REPA) when I am feeling braver. Dominic. Sadly I now get this when trying to mulitply two matrices. Is this because I have two copies of Primitive? I thought Cabal was supposed to protect me from this sort of occurrence. Does anyone have any suggestions on how to solve this? You'll need to upgrade. Trying to support old versions of software is a lost cause. I pushed Repa 3.1 to Hackage on the weekend. It has a *much* cleaner API. I can't recommend continuing to use Repa 2. You will just run into all the problems that are now fixed in Repa 3. Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
