Re: [Haskell-cafe] Some thoughts on Type-Directed Name
There is an effort underway to make Haskell's Records better. The discussion is ongoing on the ghc-users mail list, ... in the direction of making the most minimal changes possible to achieve some simple record name-spacing. Thanks, Greg Weber Thank you Greg, Yes I know, and I have been trying to follow along (intermittently). Thank you for your attempts to marshall the discussion. What would really, really help me is for someone to have a look at the 'solution' I posted to the difficulties SPJ saw with the SORF approach. (I ref'd it in my reply to Steve.) It seemed from my testing to address the needs. Since I got it working in GHC 7.2.1, there's a good chance it will need only minimal changes to implement (I'm thinking mostly syntactic sugar) -- providing of course that it is workable and generalisable enough. It could possibly benefit from some of the new Kind-level stuff in 7.4.1 (that SPJ used, but wasn't available to me at the time). I keep trying to make the time to write up the full proposal on the Wiki. I see it as a 'tweak' to SORF. Given that I'm supposed to have a day job, I'm reluctant to make time until/unless someone else double-checks whether I'm barking up the wrong tree. Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
Hello, On 27.01.2012, at 00:47, Alexander V Vershilov wrote: Recently I asked about tcp server libraries [1] and there was only one answer haskell-scallable-server [2], but in that package there was some dependencies and server logic that are not good for my task. A simple search for server on Hackage turned up the following packages for somewhat generic server infrastructure: http://hackage.haskell.org/package/iterio-server http://hackage.haskell.org/package/generic-server http://hackage.haskell.org/package/c10k http://hackage.haskell.org/package/network-server In issue 19 of The Monad Reader is an article discussing the design of the following web server: http://hackage.haskell.org/package/mighttpd2 This links might be relevant to your original question. So I decided to make a library with skeletons for different types of tcp servers and a basic library to make server [3]. Now there is only warp based (simplified) tcp server. Main logic is: * handle new connection and start iteratee green thread * enumerator (library side) reads socket and send data into enumeratee (application side) * enumeratee consumes input and produces server command (now simply output) and push it into iteratee (server side) * iteratee server side reads command and performs action (now simply output command) It gives application possibility to store state in enumerator. My questions to community: 1). can you help to make code better ;) maybe there are some stupid mistakes 2). is there any ideas what thing can be add to the server to make it reusable I think there is still no consensus on which iteratee library is the one to use. There are at least iteratee, enumerator, iterIO, conduit, and pipes. The reusability of your libary depends on the choice of iteratee-style library you select. Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
http://hackage.haskell.org/package/network-server Straightforward to use, but unfortunately uses unix package. I take it it is not portable. However its first version did not use it, so maybe the concerned part could be rewritten. I think there is still no consensus on which iteratee library is the one to use. There are at least iteratee, enumerator, iterIO, conduit, and pipes. The reusability of your libary depends on the choice of iteratee-style library you select. Yes, and IMO this is a growing problem. Since iteratees were designed, a lot of different libraries providing this kind of service have appeared. Of course they all have advantages and inconvenients, but some libraries that could be compatible are not, because they rely on a different iteratee-ish package. For instance pipes (as its documentation states) is really like iteratee... but with more concrete names. Still it's sufficient to break compatibility. Or else, we have to make sure that each one (iteratee, enumerator, conduit, pipes...) has its own set of associated packages and that each provide equivalent functionalities, but then = combinatorial explosion. ^^ It's just I don't want people to start trolling by applying to Haskell the adage I've heard quite a few times about Java, stating that There are 50 ways to achieve something... none of which is good. 2012/1/28 Jean-Marie Gaillourdet j...@gaillourdet.net Hello, On 27.01.2012, at 00:47, Alexander V Vershilov wrote: Recently I asked about tcp server libraries [1] and there was only one answer haskell-scallable-server [2], but in that package there was some dependencies and server logic that are not good for my task. A simple search for server on Hackage turned up the following packages for somewhat generic server infrastructure: http://hackage.haskell.org/package/iterio-server http://hackage.haskell.org/package/generic-server http://hackage.haskell.org/package/c10k http://hackage.haskell.org/package/network-server In issue 19 of The Monad Reader is an article discussing the design of the following web server: http://hackage.haskell.org/package/mighttpd2 This links might be relevant to your original question. So I decided to make a library with skeletons for different types of tcp servers and a basic library to make server [3]. Now there is only warp based (simplified) tcp server. Main logic is: * handle new connection and start iteratee green thread * enumerator (library side) reads socket and send data into enumeratee (application side) * enumeratee consumes input and produces server command (now simply output) and push it into iteratee (server side) * iteratee server side reads command and performs action (now simply output command) It gives application possibility to store state in enumerator. My questions to community: 1). can you help to make code better ;) maybe there are some stupid mistakes 2). is there any ideas what thing can be add to the server to make it reusable I think there is still no consensus on which iteratee library is the one to use. There are at least iteratee, enumerator, iterIO, conduit, and pipes. The reusability of your libary depends on the choice of iteratee-style library you select. Jean ___ 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] TCP Server
Yves Parès wrote: Yes, and IMO this is a growing problem. Since iteratees were designed, a lot of different libraries providing this kind of service have appeared. Thats mainly because the solution space was new and lots of unexplored terrain. Or else, we have to make sure that each one (iteratee, enumerator, conduit, pipes...) has its own set of associated packages and that each provide equivalent functionalities, but then = combinatorial explosion. There really isn't a combinatorial explosion, but rather a small number of families of packages. ^^ It's just I don't want people to start trolling by applying to Haskell the adage I've heard quite a few times about Java, stating that There are 50 ways to achieve something... none of which is good. Java has been around 20 years. The iteratee/enumerator/iterio/conduit/pipes idea has really only been around for a couple of years and I would be surprised it one of them (or a new one combining the best features of the others) doesn't come out the clear winner in the next year or two. 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] TCP Server
On Sat, Jan 28, 2012 at 9:40 AM, Yves Parès yves.pa...@gmail.com wrote: I think there is still no consensus on which iteratee library is the one to use. There are at least iteratee, enumerator, iterIO, conduit, and pipes. The reusability of your libary depends on the choice of iteratee-style library you select. Yes, and IMO this is a growing problem. Since iteratees were designed, a lot of different libraries providing this kind of service have appeared. Of course they all have advantages and inconvenients, but some libraries that could be compatible are not, because they rely on a different iteratee-ish package. For instance pipes (as its documentation states) is really like iteratee... but with more concrete names. Still it's sufficient to break compatibility. Or else, we have to make sure that each one (iteratee, enumerator, conduit, pipes...) has its own set of associated packages and that each provide equivalent functionalities, but then = combinatorial explosion. I find it funny that conduit is said to be an iteratee library since it has no iteratees! We've had more than one iteratee library since at least 1.5 years with the iteratee (Mar 2009) and enumerator (Aug 2010) packages, and AFAIK now we have four iteratee libraries: those two, iterIO (May 2011) and pipes (Jan 2012). However, conduit is not the fifth since it has no iteratees, no enumerators, no enumeratees... it's a different concept, not a different implementation. In principle it's possible to have some code that converts functions between these different iteratee packages -- at least between iteratee, enumerator and iterIO since these seem to have more or less the same implementation ideas. Converting from pipes may be possible, but to pipes seems pretty difficult since pipes sweeps IO under the rug. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
Felipe Almeida Lessa wrote: I find it funny that conduit is said to be an iteratee library since it has no iteratees! We've had more than one iteratee library since at least 1.5 years with the iteratee (Mar 2009) and enumerator (Aug 2010) packages, and AFAIK now we have four iteratee libraries: those two, iterIO (May 2011) and pipes (Jan 2012). However, conduit is not the fifth since it has no iteratees, no enumerators, no enumeratees... it's a different concept, not a different implementation. I mostly agree, but I think the real strength of Conduits is that it removes a lot of the complexity of the other Iteratee libraries. 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] Natural Transformations and fmap
Ryan Ingram wrote: However, the type of natural transformations comes with a free theorem, for example concat :: [[a]] - [a] has the free theorem forall f :: a - b, f strict and total, fmap f . concat = concat . fmap (fmap f) The strictness condition is needed; consider broken_concat :: [[a]] - [a] broken_concat _ = [undefined] f = const () fmap f (broken_concat []) = fmap f [undefined] = [()] broken_concat (fmap (fmap f) []) = broken_concat [] = [undefined] The 'taming selective strictness' version of the free theorem generator[1] allows removing the totality condition on f, but not the strictness condition. But in the case of concat, you can prove a stronger theorem: forall f :: a - b, fmap f . concat = concat . fmap (fmap f) My suspicion is that this stronger theorem holds for all strict and total natural transformations, but I don't know how to go about proving that suspicion. I'm a hobbyist mathematician and a professional programmer, not the other way around:) ... [1]http://www-ps.iai.uni-bonn.de/cgi-bin/polyseq.cgi There is an analogous approach to the taming selective strictness version of the free theorem generator where it is general recursion that is tamed. In that setting, you then get free theorems like that for concat without either strictness or totality side conditions. It is really very similar, indeed the taming selective strictness work takes over and develops further the much earlier taming general recursion ideas. The original source for the latter is: http://dblp.uni-trier.de/rec/bibtex/conf/esop/LaunchburyP96 Just nobody ever bothered to implement it in a tool. (Well, actually, such an implementation is essentially hidden inside the counterexample generator http://www-ps.iai.uni-bonn.de/cgi-bin/exfind.cgi) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
AntC Steve, I think that proposal has been rather superseeded by AntC http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields, which AntC draws on TDNR. But SORF is best seen as an evolving design space, with precise AntC details yet to be clarified/agreed. I've put my own variation into the ring: AntC http://www.haskell.org/pipermail/glasgow-haskell-users/2011- AntC December/021298.html -- which seems to have fallen into a black hole :-( AntC One of the aspects of TDNR that wasn't so popular was that its type-directed AntC resolution was very similar to instance resolution, but subtly and confusingly AntC different. AntC I guess we have to be very careful about the dot. It seems to be in a AntC very 'crowded' syntax space, so if we implement the wrong way, we could end up AntC shutting the door with the keys left inside. AntC (...) All this dot syntax magic frankly frightens me. Haskell, as a pure functionnal language, requires (and allows !) a programming style that just does not mix well with object oriented practices. Stretching the syntax to have the dot feel a-bit-but-not-really like object oriented programming, mainly to have IDE autocompletion on some cases, does not make much sens. If the editor matters - and it probably does -, we could rather take a more ambitious path, and work on a real semantic editor, as opposed to a plain left-to-right text editor, with hacked semantic goodies to alleviate the pain. Indeed, very often in haskell, we just don't think code left to right, or top to bottom. Emacs ability to move point quickly certainly helps, but I'd surely welcome a drastic switch, to something allowing us to work directly on type-checked syntax trees. -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
Hello. -- Resending reply to maillistmail Sat, Jan 28, 2012 at 11:51:32AM +0100, Jean-Marie Gaillourdet wrote Hello, On 27.01.2012, at 00:47, Alexander V Vershilov wrote: Recently I asked about tcp server libraries [1] and there was only one answer haskell-scallable-server [2], but in that package there was some dependencies and server logic that are not good for my task. A simple search for server on Hackage turned up the following packages for somewhat generic server infrastructure: http://hackage.haskell.org/package/iterio-server http://hackage.haskell.org/package/generic-server http://hackage.haskell.org/package/c10k http://hackage.haskell.org/package/network-server In issue 19 of The Monad Reader is an article discussing the design of the following web server: http://hackage.haskell.org/package/mighttpd2 This links might be relevant to your original question. Thanks I've checked code as sow interesting solutions, maybe I'll ask some more questions about desicions. As I see all servers uses accept-forkIO i.e. one green-thread to accept sockets and then runs another thread for each connection, in this thread function from ServerOptions is run, that function read Socket/Handle itself. Also I've seen another way of implemeting server [http://sequence.complete.org/node/258] in this solution author also uses accept-forkIO style to create workers, but main thread is used for all socket IO, i.e. accepting, reading and writing data back, this server uses STM channels to send data between threads, as I see this is orthogonal way of dealing with server. I'm interested if there is some more ways that are more affectfull in some cases that accept-forkIO(socketIO) or accept(socketIO)-forkIO. Jean -- Alexander V Vershilov signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TCP Server
Yes, I was forecasting a little... Concerning conduit, yes it's not another implementation of Oleg's iteratees, yet its API looks a lot like 'enumerators'. Plus it aims at solving the same problem, only the implementation that differs (roughly state variables instead of pure closure-based automata) 2012/1/28 Erik de Castro Lopo mle...@mega-nerd.com Yves Parès wrote: Yes, and IMO this is a growing problem. Since iteratees were designed, a lot of different libraries providing this kind of service have appeared. Thats mainly because the solution space was new and lots of unexplored terrain. Or else, we have to make sure that each one (iteratee, enumerator, conduit, pipes...) has its own set of associated packages and that each provide equivalent functionalities, but then = combinatorial explosion. There really isn't a combinatorial explosion, but rather a small number of families of packages. ^^ It's just I don't want people to start trolling by applying to Haskell the adage I've heard quite a few times about Java, stating that There are 50 ways to achieve something... none of which is good. Java has been around 20 years. The iteratee/enumerator/iterio/conduit/pipes idea has really only been around for a couple of years and I would be surprised it one of them (or a new one combining the best features of the others) doesn't come out the clear winner in the next year or two. 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] Contributing to http-conduit
On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: the fromJust should never fail, beceause of the guard statement: | 300 = code code 400 isJust l'' isJust l' = Just $ req Because of the order of the operators, it will only evaluate fromJust after it makes sure that the argument isJust. That function in particular shouldn't throw any exceptions - it should only return Nothing. Knowing that, I don't quite think I understand what your concern is. Can you elaborate? You're right, but I had to squint really hard to prove to myself that you're right. That's the kind of code that could easily be broken in future updates by an unwitting maintainer (e.g., me). To protect the world from me, I'd prefer if the code didn't have the fromJust. This might be a good place to leverage the Monad instance of Maybe. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Ah, yes, you're completely right. I completely agree that moving the function into the Maybe monad increases readability. This kind of function is what the Maybe monad was designed for. Here is a revised patch. On Sat, Jan 28, 2012 at 8:28 AM, Michael Snoyman mich...@snoyman.comwrote: On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: the fromJust should never fail, beceause of the guard statement: | 300 = code code 400 isJust l'' isJust l' = Just $ req Because of the order of the operators, it will only evaluate fromJust after it makes sure that the argument isJust. That function in particular shouldn't throw any exceptions - it should only return Nothing. Knowing that, I don't quite think I understand what your concern is. Can you elaborate? You're right, but I had to squint really hard to prove to myself that you're right. That's the kind of code that could easily be broken in future updates by an unwitting maintainer (e.g., me). To protect the world from me, I'd prefer if the code didn't have the fromJust. This might be a good place to leverage the Monad instance of Maybe. Michael getRedirectedRequest.2.patch Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Named captures in regex-pcre?
Hi haskell-cafe. Is there a way to get named captures from regex using regex-pcre (or maybe other PCRE-package)? For example, I want to write something like let result = ab 12 cd =~ ab (?Pnumber\d+) cd :: SomeCrypticType and then have namedCaptures result == [(number, 12)]. I do not see somewhat similar in regex-pcre documentation. It parses such regexs fine, and captures work, but i do not see way to get _named_ captures. WBR, Ilya Portnov. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Michael Snoyman wrote: On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: the fromJust should never fail, beceause of the guard statement: | 300 = code code 400 isJust l'' isJust l' = Just $ req Because of the order of the operators, it will only evaluate fromJust after it makes sure that the argument isJust. That function in particular shouldn't throw any exceptions - it should only return Nothing. Knowing that, I don't quite think I understand what your concern is. Can you elaborate? You're right, but I had to squint really hard to prove to myself that you're right. That's the kind of code that could easily be broken in future updates by an unwitting maintainer (e.g., me). To protect the world from me, I'd prefer if the code didn't have the fromJust. This might be a good place to leverage the Monad instance of Maybe. Maybe fromMaybe is a more grokkable function. 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] Named captures in regex-pcre?
On Sat, Jan 28, 2012 at 15:26, Ilya Portnov port...@iportnov.ru wrote: Is there a way to get named captures from regex using regex-pcre (or maybe other PCRE-package)? For example, I want to write something like regex-pcre is constrained by the common Haskell regex API (used by all the regex-* packages), which doesn't support named captures. Unfortunately, it doesn't look like pcre-light will return the kind of capture alist you want either; it uses the basic pcre_exec() function and doesn't appear to provide an API for pcre_get_named_substring() etc. dons doesn't seem to be very active any more (sandbagged by job?), so pcre-light (which looks to be the obvious place for it given that Text.Regex.PCRE.Base already provides a partial raw API) is likely open to adoption; you could add the named capture API to T.R.P.Base and possibly develop a more Haskell-like API later. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Named captures in regex-pcre?
* Ilya Portnov port...@iportnov.ru [2012-01-29 01:26:29+0500]
Hi haskell-cafe.
Is there a way to get named captures from regex using regex-pcre (or
maybe other PCRE-package)? For example, I want to write something
like
let result = ab 12 cd =~ ab (?Pnumber\d+) cd :: SomeCrypticType
and then have namedCaptures result == [(number, 12)].
I do not see somewhat similar in regex-pcre documentation. It parses
such regexs fine, and captures work, but i do not see way to get
_named_ captures.
Try the regex-applicative package.
{-# LANGUAGE OverloadedStrings #-}
import Text.Regex.Applicative
import Data.Char
main = print $
ab 12 cd =~ ab * some (psym isDigit) * cd
You can combine several captures into, say, a record using the
Applicative instance and thus emulate named captures semantics.
--
Roman I. Cheplyaka :: http://ro-che.info/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: bytestring-lexing 0.3.0
-- bytestring-lexing 0.3.0 The bytestring-lexing package offers efficient reading and packing of common types like Double and Integral types. -- Administrative Changes (since 0.2.1) * Change of maintainer. Don Stewart handed maintainership of the package over to myself when I voiced interest. * Change of repo type. The old repo for the package used Darcs-1 style patches. I've converted the repository to Darcs-2 hashed. This means that the new repository cannot exchange patches with the old Darcs-1 repo (or any other Darcs-2 conversions that may be floating around out there). So anyone who's interested in contributing should scrap their local copies and get the new repo. -- Code Changes (since 0.2.1) * Added Data.ByteString.Lex.Integral which provides efficient implementations for reading and packing/showing integral types in ASCII-compatible formats including decimal, hexadecimal, and octal. * The readDecimal function in particular has been highly optimized. The new version is wicked fast[1] and perfectly suitable for hot code locations like parsing headers for HTTP servers like Warp. In addition, attention has been paid to ensuring that parsing is efficient for larger than native types like Int64 on 32-bit systems (including 64-bit OS X), as well as Integer. The optimization of this function was done in collaboration with Erik de Castro Lopo, Vincent Hanquez, and Christoph Breitkopf following a blog post by Erik[2] and ensuing discussion on Reddit[3] [1] A Criterion report is available for 64-bit Intel OS X running 32-bit GHC 6.12.1: http://code.haskell.org/~wren/bytestring-lexing/test/bench/readDecimal.html The benchmark is included in the repo and has also been run on 64-bit GHC 7 systems, which differ primarily in not showing slowdown for Int64 vs Int (naturally). If you're curious about the different implementations: * readIntBS / readIntegerBS --- are the readInt and readInteger functions in Data.ByteString * readDecimalOrig (correct) --- was my original implementation, prior to collaboration with Erik, Vincent, and Christoph. * readIntegralMH (buggy) --- or rather a non-buggy version very much like it, is the implementation currently used in Warp. * readDecimal (current) --- is the current implementation used in this package. [2] http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/read_int.html [3] http://www.reddit.com/r/haskell/comments/otwxe/benchmarking_and_quickchecking_readint/ -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestring-lexing -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: combinatorics
-- combinatorics 0.1.0 The combinatorics package offers efficient *exact* computation of common combinatorial functions like the binomial coefficients and factorial. (For fast *approximations*, see the math-functions package instead.) -- Long Description * Math.Combinatorics.Primes: provides the prime numbers via Runciman's lazy wheel sieve algorithm. Provided here since efficient algorithms for combinatorial functions often require prime numbers. The current version memoizes the primes as an infinite list CAF, which could lead to memory leaks in long-running programs with irregular access to large primes. I'm looking into a GHC patch to allow resetting individual CAFs from within compiled programs so that you can explicitly decide when to un-memoize the primes. (In GHCi when you reload a module all the CAFs are reset. However, there's no way to access this feature from within compiled programs as yet.) * Math.Combinatorics.Binomial: offers a fast computation of the binomial coefficients based on the prime factorization of the result. As it turns out, it's easier to compute the prime factorization of the answer than it is to compute the answer directly! And you don't even need the factorial function to do so. Albeit, with a fast factorial function, the naive definition of binomial coefficients gives this algorithm a run for its money. * Math.Combinatorics.Factorial: offers a fast computation of factorial numbers. As Peter Luschny comments[1], the factorial function is often shown as a classic example of recursive functions, like addition of Peano numbers, however that naive way of computing factorials is extremely inefficient and does a disservice to those learning about recursion. The current implementation uses the split-recursive algorithm which is more than sufficient for casual use. I'm working on implementing the parallel prime-swing algorithm, which should be a bit faster still. [1] http://www.luschny.de/math/factorial/FastFactorialFunctions.htm -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/combinatorics Darcs: http://community.haskell.org/~wren/combinatorics Haddock (Darcs version): http://community.haskell.org/~wren/combinatorics/dist/doc/html/combinatorics -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: data-or
-- data-or 1.0.0 The data-or package offers a data type for non-exclusive disjunction. This is helpful for things like a generic merge function on sets/maps which could be union, mutual difference, etc. based on which 'Or' value a function argument returns. Also useful for non-truncating zips (cf. 'zipOr') and other cases where you sometimes want an 'Either' and sometimes want a pair. -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/data-or Darcs: http://community.haskell.org/~wren/data-or Haddock (Darcs version): http://community.haskell.org/~wren/data-or/dist/doc/html/data-or -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
Thanks, looks great! I've merged it into the Github tree. On Sat, Jan 28, 2012 at 8:36 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Ah, yes, you're completely right. I completely agree that moving the function into the Maybe monad increases readability. This kind of function is what the Maybe monad was designed for. Here is a revised patch. On Sat, Jan 28, 2012 at 8:28 AM, Michael Snoyman mich...@snoyman.com wrote: On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: the fromJust should never fail, beceause of the guard statement: | 300 = code code 400 isJust l'' isJust l' = Just $ req Because of the order of the operators, it will only evaluate fromJust after it makes sure that the argument isJust. That function in particular shouldn't throw any exceptions - it should only return Nothing. Knowing that, I don't quite think I understand what your concern is. Can you elaborate? You're right, but I had to squint really hard to prove to myself that you're right. That's the kind of code that could easily be broken in future updates by an unwitting maintainer (e.g., me). To protect the world from me, I'd prefer if the code didn't have the fromJust. This might be a good place to leverage the Monad instance of Maybe. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: pointless fun
-- pointless-fun 1.1.0 The pointless-fun package offers some common point-free combinators (common for me at least). -- Long Description * Perhaps the most useful is that it packages up Matt Helige's classic multicomposition trick[1]. These combinators allow you to easily modify the types of a many-argument function with syntax that looks like giving type signatures. For example, foo:: A - B - C albert :: A - X beth :: B - Y carol :: C - Z bar :: X - Y - Z bar = foo $:: albert ~ beth ~ carol I've found this to be especially helpful for defining non-derivable type class instances for newtypes since it both abstracts away the plumbing and also makes explicit what you mean. * Other prevalent combinators include, ** (.:) for binary composition: (f .: g) x y = f (g x y) -- or, f .: g = curry (f . uncurry g) This is the same as the common idiom @(f .) . g@ but more easily extended to multiple uses, due to the fixity declaration. ** (.!) for function composition which calls the right-hand function eagerly; i.e., making the left-hand function strict in its first argument. (f .! g) x = f $! g x This defines the composition for the sub-category of strict Haskell functions. If the 'Functor' class were parameterized by the domain and codomain categories (e.g., a regular @Functor f@ would be @CFunctor (-) (-) f@ instead) then this would allow us to define functors @CFunctor (-) (!-) f@ where @fmap f . fmap g = fmap (f .! g)@. [1] http://matt.immute.net/content/pointless-fun -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/pointless-fun Darcs: http://community.haskell.org/~wren/pointless-fun Haddock (Darcs version): http://community.haskell.org/~wren/pointless-fun/dist/doc/html/pointless-fun -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: pointless fun
On 1/28/12 11:34 PM, wren ng thornton wrote: * Perhaps the most useful is that it packages up Matt Helige's classic multicomposition trick[1]. Apologies, that should be Hellige. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: pointless fun
Hi, Am Samstag, den 28.01.2012, 23:34 -0500 schrieb wren ng thornton: * Perhaps the most useful is that it packages up Matt Helige's classic multicomposition trick[1]. These combinators allow you to easily modify the types of a many-argument function with syntax that looks like giving type signatures. For example, foo:: A - B - C albert :: A - X beth :: B - Y carol :: C - Z bar :: X - Y - Z bar = foo $:: albert ~ beth ~ carol I've found this to be especially helpful for defining non-derivable type class instances for newtypes since it both abstracts away the plumbing and also makes explicit what you mean. Even without looking at the definition of $:: and ~, I have doubts about the existence of such a bar function (it calls foo, which needs an A, but it is not given an A and no used function produces one; albert only consumes one). Maybe you mean: foo:: A - B - C albert :: X - A beth :: Y - B carol :: C - Z bar :: X - Y - Z bar = foo $:: albert ~ beth ~ carol Greetings from POPL, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: bytestring-lexing 0.3.0
wren ng thornton wrote: * The readDecimal function in particular has been highly optimized. The new version is wicked fast[1] and perfectly suitable for hot code locations like parsing headers for HTTP servers like Warp. In addition, attention has been paid to ensuring that parsing is efficient for larger than native types like Int64 on 32-bit systems (including 64-bit OS X), as well as Integer. The optimization of this function was done in collaboration with Erik de Castro Lopo, Vincent Hanquez, and Christoph Breitkopf following a blog post by Erik[2] and ensuing discussion on Reddit[3] Thanks Wren. I'm pretty sure that Warp will swap over to use your new readDecimal function. 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
