Re: [Haskell-cafe] Mersenne-random and standard random API
Yves Parès yves.pa...@gmail.com wrote: I've been in the past told that mersenne-random was much better than the standard random package. This is relative. The Mersenne Twister algorithm has a large memory footprint, but in relation to the size of the average Haskell program, this is probably not much of an issue. So is it possible to use the fast and efficient mersenne generator with the convenient and general random API? No, because mersenne-random provides an impure generator with a global state, as is also pointed out by the Haddock documentation. As an alternative consider the mersenne-random-pure64 and the cprng-aes packages. Both provide the interface you want. Personally I prefer the cprng-aes package, because it is reasonably fast and convenient for non-cryptographic applications, but also provides a strong Crypto-API interface, if you need cryptographically strong random numbers. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is ListT a valid MonadPlus?
First of all, ListT is not a monad transformer, since it breaks the law of associativity of bind: *Control.Monad.List let one = (lift $ putStrLn 1) :: ListT IO () *Control.Monad.List let two = (lift $ putStrLn 2) :: ListT IO () *Control.Monad.List let choice = return 1 `mplus` return 2 :: ListT IO Int *Extensible Control.Monad.List runListT $ choice (one two) 1 2 1 2 [(),()] *Extensible Control.Monad.List runListT $ (choice one) two 1 1 2 2 [(),()] It appears to me that the MonadPlus instance for ListT breaks the following MonadPlus law m mzero = mzero The precise set of MonadPlus laws isn't actually agreed upon. The above law is the least agreed upon. Incidentally, this law is certainly violated for _any_ back-tracking monad transformer. Consider (lift any action in base monad) mzero for example (lift (putStrLn printed)) mzero Is it reasonable to expect that printing should be undone? That the paper should be fed back into the printer and the toner lifted? There are back-tracking monad transformers; for example, LogicT. ___ 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
Although it's a bit off topic, I must say I agree with Malcolm on that. Record-fields-selection-as-functions might be sometime unconvenient, but it is simple and easy to reason about and deal with, with usual Haskell strategies (prefixed names, modules, qualified imports ... business as usual). However, records updating is often painful. A lot of thoughts have been put in lenses, and they quiet improve the state of things. But, franckly, having to pragma template haskell, then prefix all the fields with an underscore, then call a TH splice straight in my code in not a pleasure. Nor is a pleasure to hand-craft lenses. An improvement on this front is probably easier to achieve, would make syntax more consistent, and be immediatly applicable at large scale. Malcolm I very much fail to see the point of replacing prefix function Malcolm application with postfix dots, merely for field selection. Malcolm There are already some imperfect, but adequate, solutions to Malcolm the problem of global uniqueness of field names. But you now Malcolm have mentioned what is really bothering me about this Malcolm discussion: record updates are simply the most painful and Malcolm least beautiful part of the Haskell syntax. Their verbosity is Malcolm astonishing compared to the careful tenseness of every other Malcolm language construct. If we could spend some effort on designing Malcolm a decent notation for field updates, I think it would be Malcolm altogether more likely to garner support than fiddling with Malcolm dots. -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mersenne-random and standard random API
On 09.02.2012 01:56, Yves Parès wrote: Hi, I've been in the past told that mersenne-random was much better than the standard random package. ... So is it possible to use the fast and efficient mersenne generator with the convenient and general random API? I think design of Random type class basically precludes efficient generators with large periods and consequently large state. Look at next function: next :: g - (Int, g) It means that state has to be copied but for efficiency we want to mutate it in place. I consider Random type class a failure and ignore it. P.S. For monte-carlo and thing like that I'd recommend mwc-random it more featureful than mersenne-random and don't rely on global state ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mersenne-random and standard random API
Aleksey Khudyakov : I think design of Random type class basically precludes efficient generators with large periods and consequently large state. Look at next function: next :: g - (Int, g) It means that state has to be copied but for efficiency we want to mutate it in place. I consider Random type class a failure and ignore it. P.S. For monte-carlo and thing like that I'd recommend mwc-random it more featureful than mersenne-random and don't rely on global state I am afraid that Aleksey Khudakov confuses a few things. 1. Mersenne Twister, AND congruential generators AND the Marsaglia stuff, all use some kind of seed, all are stateful. There are no miracles. Just look the agressive monadization, the form of defaultSeed, etc. within MWC.hs, before saying that this generator doesn't rely on some global state. 2. In the standard generator stuff the state is stored in IoRefs and is not copied. Did Aleksey ever look inside the sources of these generators? In any case, the seed changes after each generation, and must be stored somewhere. 3. The API question is a conventional one. People who are really unhappy, may make their own interfaces, or give such a mini-project as a students' assignment, instead of weeping that the library is lousy and should be ignored. E. g., I wanted random numers in some purely functional, lazy context, and I didn't want the existing interface ; I manufactured a lazy stream interface, and that was all. Look Ma!: no global state... 4. L'Ecuyer signalled some 15 years ago that MWC generators introduce some bias on the most significant bits (complementary MWC are safer). This is less annoying that the last bits periodicity of simple congruential generators, but for SOME Monte-Carlo it may be harmful. === In general, I believe that saying publicly that some part of the available library is a failure, should be avoided, unless accompanied by some SERIOUS analysis, and - if possible - some constructive suggestions. With my thanks to all people who made those generators however imperfect they are. Only Mister Nobody is perfect. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Yesod] Re: Yesod and dependencies hell
As somebody who has very recently started working with Yesod -- I feel your pain! In truth Yesod is a huge bundle of packages, many of which aren't managed by the Yesod developers. I get the impression that they work very hard to keep everything coherent while Yesod continues its very active development. I think it is quite a miracle that it fits together so well under the circumstances and I am quite in awe of the whole development. You seem to have been unlucky (3 days!) but I have found it to be worth it -- you eventually get an amazing platform. (I do think that we could be delivering the tools with a little more packaging that could significantly help with these situations. I have found them to be highly useful in any case.) Chris -Original Message- From: yesod...@googlegroups.com [mailto:yesod...@googlegroups.com] On Behalf Of Michael Snoyman Sent: 09 February 2012 06:44 To: Никита Тимофеев Cc: haskell-cafe@haskell.org; yesod...@googlegroups.com Subject: [Yesod] Re: [Haskell-cafe] Yesod and dependencies hell Are you talking about starting a new site, or running an existing site? For a new site, it's probably a good idea to wait until 0.10 comes out, as it includes a lot of nice enhancements, and we'll be releasing it this week. If an existing site, you probably need to have more strict upper bounds on your package dependencies. Without seeing your cabal file, I can't really comment further. It also might be a good idea to move this discussion to the Yesod mailing list (CCed). On Wed, Feb 8, 2012 at 5:09 PM, Никита Тимофеев ndtimof...@gmail.com wrote: For three days I can't compile dependencies for my project using yesod, yesod-auth, yesod-persistent, persistent-template, persistent-sqlite, persistent. When I varied version I received a variety of broken dependencies: persistent (0.6.* vs 0.7.*), conduit (0.1.* vs 0.2.*), conduit-pool, path-pieces, attoparsec and something else. In this regard, I have a few questions. How to build these packages together? And, Michael, why so bad? -- Тимофеев Н.Д. ___ 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] Mersenne-random and standard random API
On 09.02.2012 15:32, Jerzy Karczmarczuk wrote: Aleksey Khudyakov : 1. Mersenne Twister, AND congruential generators AND the Marsaglia stuff, all use some kind of seed, all are stateful. There are no miracles. Just look the agressive monadization, the form of defaultSeed, etc. within MWC.hs, before saying that this generator doesn't rely on some global state. I think you are missing the point here. Surely all PRNG carry some state around. But both StdGen and mwc-random (and likely many others) allow to have many generators at once (for use in different threads) mersenne-random is just wrapper around vastly impure library (as documentation says) and allows only one genrator per program. This is why I said it uses *global* state 2. In the standard generator stuff the state is stored in IoRefs and is not copied. Did Aleksey ever look inside the sources of these generators? In any case, the seed changes after each generation, and must be stored somewhere. No. It doesn't and cannot data StdGen = StdGen Int32 Int32 If generator state is stored in IORef it's not possible to implement `next :: g → (Int,g)'. To do something useful with it one have to go to IO monad but we can't. So state have to be copied. 3. The API question is a conventional one. People who are really unhappy, may make their own interfaces, or give such a mini-project as a students' assignment, instead of weeping that the library is lousy and should be ignored. E. g., I wanted random numers in some purely functional, lazy context, and I didn't want the existing interface ; I manufactured a lazy stream interface, and that was all. Look Ma!: no global state... Usually. But sometimes it's not possible to implement some algorithms for particular API. For example if PRNG rely on in-place array updates it cannot implement Random type class. 4. L'Ecuyer signalled some 15 years ago that MWC generators introduce some bias on the most significant bits (complementary MWC are safer). This is less annoying that the last bits periodicity of simple congruential generators, but for SOME Monte-Carlo it may be harmful. Thank you for reminder. I wanted to read their paper for some time. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Wed, Feb 8, 2012 at 10:56 AM, Ian Lynagh ig...@earth.li wrote: That sounds right. It basically means you don't have to write the C stubs yourself, which is nice because (a) doing so is a pain, and (b) when the foreign import is inside 2 or 3 CPP conditionals it's even more of a pain to replicate them correctly in the C stub. Unfortunately, there are cases where C doesn't get all the type information it needs, e.g.: http://hackage.haskell.org/trac/ghc/ticket/2979#comment:14 but I'm not sure what the best fix is. I believe jhc's algorithm works in this case. Certain type constructors have C types associated with them, in particular, many newtypes have c types that are different than their contents. So my routine that finds out whether an argument is suitable for FFIing returns both a c type, and the underlying raw type (Int# etc..) that the type maps to. So the algorithm checks if the current type constructor has an associated C type, if it doesn't then it expands the newtype one layer and trys again, however if it does have a c type, it still recurses to get at the underlying raw type, but then replaces the c type with whatever was attached to the newtype. In the case of 'Ptr a' it recursively runs the algorithm on the argument to 'Ptr', then takes that c type and appends a '*' to it. If the argument to 'Ptr' is not an FFIable type, then it just returns HsPtr as the C type. Since CSigSet has sigset_t associated with it, 'Ptr CSigSet' ends up turning into 'sigset_t *' in the generated code. (Ptr (Ptr CChar)) turns into char** and so forth. An interesting quirk of this scheme is that it faithfully translates the perhaps unfortunate idiom of newtype Foo_t = Foo_t (Ptr Foo_t) into foo_t (an infinite chain of pointers) which is actually what the user specified. :) I added a check for recursive newtypes that chops the recursion to catch this as people seem to utilize it. I ask because jhc needs such a feature (very hacky method used now, the rts knows some problematic functions and includes hacky wrappers and #defines.) and I'll make it behave just like the ghc one when possible. Great! It has now been implemented, shall be in jhc 0.8.1. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mersenne-random and standard random API
Aleksey Khudyakov: On 09.02.2012 15:32, Jerzy Karczmarczuk wrote: 1. Mersenne Twister, AND congruential generators AND the Marsaglia stuff, all use some kind of seed, all are stateful. There are no miracles. Just look the agressive monadization, the form of defaultSeed, etc. within MWC.hs, before saying that this generator doesn't rely on some global state. I think you are missing the point here. Surely all PRNG carry some state around. But both StdGen and mwc-random (and likely many others) allow to have many generators at once (for use in different threads) This is irrelevant. I believe that there is a misunderstanding in terminology. When I say global state it means not a local variable in some function. You seem to say one object per programme. This is confirmed by: mersenne-random is just wrapper around vastly impure library (as documentation says) and allows only one genrator per program. This is why I said it uses *global* state In any case, the seed changes after each generation, and must be stored somewhere. No. It doesn't and cannot data StdGen = StdGen Int32 Int32 If generator state is stored in IORef it's not possible to implement `next :: g → (Int,g)'. To do something useful with it one have to go to IO monad but we can't. So state have to be copied. We can't WHAT? Look, all data that change or are created MUST be stored somewhere, don't say dubious things. Your next function is a threading generator, which makes another StdGen, OK, but this is not a copy. This is a creation of a new seed. When I spoke about IORefs, I thought about the global generator, which USES the l'Ecuyer stuff, newStdGen and its friends. The threading becomes implicit. Try, say r=newStdGen r = return . next and you will see, it works, and you don't keep explicitly your seed. From the efficiency point of view all this is comparable. With IOrefs you do not pollute the memory which has to be garbage-collected, but its administration is heavier than the standard heap operations. StdGen with l'Ecuyer two-number seed, or some 600 of the Mersenne, I don't see a conceptual difference. The Marsaglia generator has a global seed quite voluminous as well. ...sometimes it's not possible to implement some algorithms for particular API. For example if PRNG rely on in-place array updates it cannot implement Random type class. No idea what do you mean. In the Random library you will find the generators using IORefs, AND the class Random, with the member random (or randomR, etc.) and you may write getStdRandom random getStdRandom random ... as you wish, getting different results. What's wrong with that? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Yesod] Re: Yesod and dependencies hell
Hi, Am Donnerstag, den 09.02.2012, 11:39 + schrieb Chris Dornan: (I do think that we could be delivering the tools with a little more packaging that could significantly help with these situations. I have found them to be highly useful in any case.) if you are content with not always having the very latest versions, you can use your distribution’s packages. Distributions tend to provide exactly one (well, at most one :-)) version of each hackage library, and they all go well together. But then, for a few more days, Debian sid is broken due to the GHC 7.4.1 transition... Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata 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] Mersenne-random and standard random API
On 9 February 2012 10:59, Aleksey Khudyakov alexey.sklad...@gmail.com wrote: So is it possible to use the fast and efficient mersenne generator with the convenient and general random API? I think design of Random type class basically precludes efficient generators with large periods and consequently large state. Look at next function: next :: g - (Int, g) It means that state has to be copied but for efficiency we want to mutate it in place. I consider Random type class a failure and ignore it. Actually it is not true that the state has to be copied. Using the lazy ST monad we can implement this interface and internally use mutable ST arrays. See for example http://web.archive.org/web/20090108050217/http://www.augustsson.net/Darcs/MT/MersenneTwister.hs It ends up with this function that generates the infinite lazy sequence of words from a seed word. This can be then made to fit the next :: g - (Int, g) interface, with g = [W]. mersenneTwister :: W - [W] mersenneTwister s = L.runST (mersenneTwisterST s) For reference: import Control.Monad.ST.Lazy as L type W = Word32 mersenneTwisterST :: W - L.ST s [W] So yes this looses a small constant factor because of the extra lazy list (which could be reduced somewhat), so it's not suitable for the absolutely max performance interface, but it certainly allows the use of traditional mutable PRNGs with the nice interface with decent performance. Certainly none of these PRNGs support split, but that's a separate issue. Overall, I think the Random type class is salvageable given a few changes. In the end, the Random module probably needs both an ST-monadic interface and a pure one. People can use the ST one if it happens to be more convenient or if they need to squeeze the last drop of performance out. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mersenne-random and standard random API
On 09.02.2012 18:27, Duncan Coutts wrote: Actually it is not true that the state has to be copied. Using the lazy ST monad we can implement this interface and internally use mutable ST arrays. See for example http://web.archive.org/web/20090108050217/http://www.augustsson.net/Darcs/MT/MersenneTwister.hs It ends up with this function that generates the infinite lazy sequence of words from a seed word. This can be then made to fit the next :: g - (Int, g) interface, with g = [W]. This is very elegant trick! Ability to snapshot and restore generator is lost. So yes this looses a small constant factor because of the extra lazy list (which could be reduced somewhat), so it's not suitable for the absolutely max performance interface, but it certainly allows the use of traditional mutable PRNGs with the nice interface with decent performance. Certainly none of these PRNGs support split, but that's a separate issue. Overall, I think the Random type class is salvageable given a few changes. In the end, the Random module probably needs both an ST-monadic interface and a pure one. People can use the ST one if it happens to be more convenient or if they need to squeeze the last drop of performance out. There is another problem. Functions like `next' aren't meant to be used by humans. One have to thread state manually and this is tedious and error-prone. So PRNG should be wrapped into monad. Are `next'-like function needed at all? I'd expect that creation of generic and useful type class would be very nontrivial. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mersenne-random and standard random API
On 09.02.2012 17:28, Jerzy Karczmarczuk wrote: Aleksey Khudyakov: On 09.02.2012 15:32, Jerzy Karczmarczuk wrote: 1. Mersenne Twister, AND congruential generators AND the Marsaglia stuff, all use some kind of seed, all are stateful. There are no miracles. Just look the agressive monadization, the form of defaultSeed, etc. within MWC.hs, before saying that this generator doesn't rely on some global state. I think you are missing the point here. Surely all PRNG carry some state around. But both StdGen and mwc-random (and likely many others) allow to have many generators at once (for use in different threads) This is irrelevant. I believe that there is a misunderstanding in terminology. When I say global state it means not a local variable in some function. You seem to say one object per programme. This is confirmed by: mersenne-random is just wrapper around vastly impure library (as documentation says) and allows only one genrator per program. This is why I said it uses *global* state In any case, the seed changes after each generation, and must be stored somewhere. No. It doesn't and cannot data StdGen = StdGen Int32 Int32 If generator state is stored in IORef it's not possible to implement `next :: g → (Int,g)'. To do something useful with it one have to go to IO monad but we can't. So state have to be copied. We can't WHAT? Look, all data that change or are created MUST be stored somewhere, don't say dubious things. Your next function is a threading generator, which makes another StdGen, OK, but this is not a copy. This is a creation of a new seed. When I spoke about IORefs, I thought about the global generator, which USES the l'Ecuyer stuff, newStdGen and its friends. The threading becomes implicit. Try, say r=newStdGen r = return . next and you will see, it works, and you don't keep explicitly your seed. From the efficiency point of view all this is comparable. With IOrefs you do not pollute the memory which has to be garbage-collected, but its administration is heavier than the standard heap operations. StdGen with l'Ecuyer two-number seed, or some 600 of the Mersenne, I don't see a conceptual difference. The Marsaglia generator has a global seed quite voluminous as well. I didn't quite understand you In order to implement RandomGen one have to implement `next' function next :: g → (Int,g) Lets assume that g stores internal generator state (In case of NWC256 it's 258 Word32s). We cannot modify it in place. Someone may hold this g and changing it behind the scenes will violate referential transparence. We have to create new array and this is expensive. There still way out as Duncan Coutts pointed out. We may generate stream of random numbers in lazy ST monad and use them as random generator. No idea what do you mean. In the Random library you will find the generators using IORefs, AND the class Random, with the member random (or randomR, etc.) and you may write getStdRandom random getStdRandom random ... as you wish, getting different results. What's wrong with that? Nothing. I was talking about problems with `next' function. One always can use IORefs to create global generator but that's irrelevant ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cannot understand liftM2
Nice explanation. However, at http://stackoverflow.com/questions/4119730/cartesian-product it was pointed out that this cartProd :: [a] - [b] - [(a, b)] cartProd = liftM2 (,) is equivalent to the cartesian product produced using a list comprehension: cartProd xs ys = [(x,y) | x - xs, y - ys] I do not see how your method of explanation can be used to explain this equivalence? Nevertheless, can you help me to understand how liftM2 (,) achieves the cartesian product? For example, Prelude Control.Monad.Reader liftM2 (,) [1,2] [3,4,5] [(1,3),(1,4),(1,5),(2,3),(2,4),(2,5)] Thank you! -- View this message in context: http://haskell.1045720.n5.nabble.com/Cannot-understand-liftM2-tp3085649p5470185.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The State of Testing?
On Wed, Feb 8, 2012 at 4:42 AM, Christoph Breitkopf chbreitk...@googlemail.com wrote: Hello Thomas, On Wed, Feb 8, 2012 at 4:03 AM, Thomas Tuegel ttue...@gmail.com wrote: First, as author of the test suite code, let me apologize for the terrible documentation. This is absolutely NOT how coverage reports are supposed to work. If you configure with '--enable-tests --enable-library-coverage', Cabal will take care of _everything_ else for you, including excluding the test module from the coverage report. You should not have to put any flag gymnastics in your .cabal file. I get only cabal: unrecognized option `--enable-library-coverage' when doing that. Which cabal version do I need? Can you point me to any docs about this? I'm still using test type exitcode-stdio-1.0, because I could not get detailed-1.0 to work. You need Cabal 1.12 for '--enable-library-coverage'. The only place it's documented is in 'cabal configure --help' (a major oversight on my part). The online docs for Cabal are only from version 1.10 anyway, so that wouldn't have helped. I'm sorry for your struggles getting the detailed type to work. It's a known issue: the detailed test interface is intentionally disabled in all the released versions because it's going to change. That's why none of the test libraries support it yet and why you weren't able to get it to work. -- Thomas Tuegel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: stm-conduit-0.2.1
Hi all, I've just released stm-conduit [1] on Hackage. This package introduces conduits to the wonderful world of concurrency. My package solves the common problem of constant bottleneck switching loaders have. This is when, for example, we stream XML from the disk and then parse the XML in one conduit pipeline. While it streams a file from the disk, the process is clearly IO bound, and while it parses the XML, the process is CPU bound. By putting each task on its own thread, the disk IO doesn't need to wait for the CPU to parse a document before loading the next file. By using stm-based conduits, we have full resource utilization. The way it does this is by creating a source and sink for TChans, letting us stream data between conduits and channels. There are more examples in the docs. Check it out! Regards, - clark [1] http://hackage.haskell.org/package/stm-conduit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Transactional memory going mainstream with Intel Haswell
http://arstechnica.com/business/news/2012/02/transactional-memory-going-mainstream-with-intel-haswell.ars would any haskell STM expert care to comment on the possibilities of hardware acceleration? best, ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Transactional memory going mainstream with Intel Haswell
Duncan Coutts talked a bit about this on Reddit here: http://www.reddit.com/r/programming/comments/pfnkx/intel_details_hardware_transactional_memory/c3p4oq7 On Thu, Feb 9, 2012 at 12:43 PM, Ben midfi...@gmail.com wrote: http://arstechnica.com/business/news/2012/02/transactional-memory-going-mainstream-with-intel-haswell.ars would any haskell STM expert care to comment on the possibilities of hardware acceleration? best, ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Error in installing dph-examples on Mac OS X 10.7.3
Hello all I am trying to install dph-examples on Mac OS X version 10.7.3 but getting this error http://hpaste.org/57699. I am using ghc-7.4.1. Error running clang! you need clang installed to use the LLVM backend cabal: Error: some packages failed to install: dph-examples-0.6.1.3 failed during the building phase. The exception was: ExitFailure 1 I have already installed Xcode 4.2 and it shows Macintosh-0026bb610428:tmp mukesh$ clang clang clang++ Macintosh-0026bb610428:tmp mukesh$ clang -v Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.3.0 Thread model: posix Macintosh-0026bb610428:tmp mukesh$ clang++ -v Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.3.0 Thread model: posix Macintosh-0026bb610428:tmp mukesh$ l Display all 113 possibilities? (y or n) Macintosh-0026bb610428:tmp mukesh$ llvm- llvm-ar llvm-config llvm-diff llvm-extract llvm-gcc llvm-link llvm-objdump llvm-rtdyld llvm-tblgen llvm-as llvm-cov llvm-dis llvm-g++ llvm-gcc-4.2 llvm-mc llvm-prof llvm-size llvm-bcanalyzer llvm-cpp-4.2 llvm-dwarfdump llvm-g++-4.2 llvm-ld llvm-nm llvm-ranlib llvm-stub Macintosh-0026bb610428:tmp mukesh$ llvm-g++ -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~1/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~1/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Regards Mukesh Tiwari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fancy REPL
Dear list, the Show class is extremely useful for exploring Haskell in a terminal, but sometimes, I just want something fancier. For instance, I'm currently dabbling with sound generation and it is only natural that I want to hear the sound instead of seeing a textual representation. Another example would be graphics, that are simply drawn on screen whenever you evaluate their value. Of course, this is simple to implement with a class class Demonstrable a where demo :: a - IO () instance Demonstrable Sound where demo = play instance Demonstrable Sound where demo = draw instance Demonstrable GUI where demo = run etc. However, I don't want to reinvent the wheel, small as it may be, hence my question: is there a package on hackage that already defines a class similar to Demonstrable ? Or any other projects in this direction, like, say, a fancy REPL built on wxHaskell? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: stm-conduit-0.2.1
Hello. Thu, Feb 09, 2012 at 01:32:41PM -0500, Clark Gaebel wrote Hi all, I've just released stm-conduit [1] on Hackage. This package introduces conduits to the wonderful world of concurrency. My package solves the common problem of constant bottleneck switching loaders have. This is when, for example, we stream XML from the disk and then parse the XML in one conduit pipeline. While it streams a file from the disk, the process is clearly IO bound, and while it parses the XML, the process is CPU bound. By putting each task on its own thread, the disk IO doesn't need to wait for the CPU to parse a document before loading the next file. By using stm-based conduits, we have full resource utilization. The way it does this is by creating a source and sink for TChans, letting us stream data between conduits and channels. There are more examples in the docs. Check it out! Regards, - clark [1] http://hackage.haskell.org/package/stm-conduit A day ago I've make analogical library in utils for my project, code was 90% same. Thanks for putting such a library on hackage -- Best regards, Alexander. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: stm-conduit-0.2.1
Happy to help! I'm new to this whole package on hackage thing, so any feedback would be great. - clark On Thu, Feb 9, 2012 at 2:19 PM, Alexander V Vershilov alexander.vershi...@gmail.com wrote: Hello. Thu, Feb 09, 2012 at 01:32:41PM -0500, Clark Gaebel wrote Hi all, I've just released stm-conduit [1] on Hackage. This package introduces conduits to the wonderful world of concurrency. My package solves the common problem of constant bottleneck switching loaders have. This is when, for example, we stream XML from the disk and then parse the XML in one conduit pipeline. While it streams a file from the disk, the process is clearly IO bound, and while it parses the XML, the process is CPU bound. By putting each task on its own thread, the disk IO doesn't need to wait for the CPU to parse a document before loading the next file. By using stm-based conduits, we have full resource utilization. The way it does this is by creating a source and sink for TChans, letting us stream data between conduits and channels. There are more examples in the docs. Check it out! Regards, - clark [1] http://hackage.haskell.org/package/stm-conduit A day ago I've make analogical library in utils for my project, code was 90% same. Thanks for putting such a library on hackage -- Best regards, Alexander. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Thu, Feb 09, 2012 at 04:52:16AM -0800, John Meacham wrote: Since CSigSet has sigset_t associated with it, 'Ptr CSigSet' ends up turning into 'sigset_t *' in the generated code. (Ptr (Ptr CChar)) turns into char** and so forth. What does the syntax for associating sigset_t with CSigSet look like? Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cannot understand liftM2
A good first step would be understanding how the other entry works: cartProd :: [a] - [b] - [(a,b)] cartProd xs ys = do x - xs y - ys return (x,y) It is about halfway between the two choices. John On Thu, Feb 9, 2012 at 9:37 AM, readams richard.ad...@lvvwd.com wrote: Nice explanation. However, at http://stackoverflow.com/questions/4119730/cartesian-product it was pointed out that this cartProd :: [a] - [b] - [(a, b)] cartProd = liftM2 (,) is equivalent to the cartesian product produced using a list comprehension: cartProd xs ys = [(x,y) | x - xs, y - ys] I do not see how your method of explanation can be used to explain this equivalence? Nevertheless, can you help me to understand how liftM2 (,) achieves the cartesian product? For example, Prelude Control.Monad.Reader liftM2 (,) [1,2] [3,4,5] [(1,3),(1,4),(1,5),(2,3),(2,4),(2,5)] Thank you! -- View this message in context: http://haskell.1045720.n5.nabble.com/Cannot-understand-liftM2-tp3085649p5470185.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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] ANN: stm-conduit-0.2.1
Your package uses TMChans which AFAIK are unbounded. That means that if the writer is faster than the reader, then everything will be kept into memory. This means that using TMChans you may no longer say that your program uses a constant amount of memory. Actually, you lose a lot of your space reasoning since, being concurrent processes, you can't guarantee almost anything wrt. progress of the reader. This doesn't mean that your package is broken, this means that it has a caveat that should be stated on the docs. Congrats on your Hackage debut! Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fancy REPL
Does this mean we're going to see music FRP examples soon?! amindfv / Tom On Feb 9, 2012 2:17 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Dear list, the Show class is extremely useful for exploring Haskell in a terminal, but sometimes, I just want something fancier. For instance, I'm currently dabbling with sound generation and it is only natural that I want to hear the sound instead of seeing a textual representation. Another example would be graphics, that are simply drawn on screen whenever you evaluate their value. Of course, this is simple to implement with a class class Demonstrable a where demo :: a - IO () instance Demonstrable Sound where demo = play instance Demonstrable Sound where demo = draw instance Demonstrable GUI where demo = run etc. However, I don't want to reinvent the wheel, small as it may be, hence my question: is there a package on hackage that already defines a class similar to Demonstrable ? Or any other projects in this direction, like, say, a fancy REPL built on wxHaskell? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Thu, Feb 9, 2012 at 11:23 AM, Ian Lynagh ig...@earth.li wrote:
On Thu, Feb 09, 2012 at 04:52:16AM -0800, John Meacham wrote:
Since CSigSet has sigset_t associated with it, 'Ptr CSigSet' ends up
turning
into 'sigset_t *' in the generated code. (Ptr (Ptr CChar)) turns into char**
and so forth.
What does the syntax for associating sigset_t with CSigSet look like?
There currently isn't a user accessable once, but CSigSet is included in the
FFI spec so having the complier know about it isn't that bad. In fact, it is
how I interpreted the standard. Otherwise, why would CFile be specified if it
didn't expand 'Ptr CFile' properly. I just have a single list of associations
that is easy to update at the moment, but a user defineable way is something i
want in the future. My current syntax idea is.
data CFile = foreign stdio.h FILE
but it doesn't extend easily to 'newtype's
or maybe a {-# CTYPE FILE #-} pragma...
The 'Ptr' trick is useful for more than just pointers, I use the same thing to
support native complex numbers. I have
data Complex_ :: # - # -- type function of unboxed types to unboxed types.
then can do things like 'Complex_ Float64_' to get hardware supported complex
doubles. The expansion happens just like 'Ptr' except instead of postpending
'*' when it encounters _Complex, it prepends '_Complex ' (a C99 standard
keyword).
You can then import primitives like normal (for jhc)
foreign import primitive Add complexPlus ::
Complex_ Float64_ - Complex_ Float64_ - Complex_ Float64_
and lift it into a data type and add instances for the standard numeric classes
if you wish. (I have macros that automate the somewhat repetitive instance
creation in lib/jhc/Jhc/Num.m4)
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fancy REPL
Tom Murphy wrote: Heinrich Apfelmus wrote: For instance, I'm currently dabbling with sound generation and it is only natural that I want to hear the sound instead of seeing a textual representation. Does this mean we're going to see music FRP examples soon?! I'm not so sure about the soon part, but yes, using FRP to make music is part of the plan. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: hs-json-rpc 0.0.0.1
[Redirecting to haskell-cafe] Congrats on your first release! While I haven't looked into your package in more depth, I'd suggest taking a look at http-conduit [1]. While I don't know of any benchmarks, it should be faster or at least as fast the HTTP package. It's also used by many people everyday (myself included), which means that it has no major bugs and that bugs are promptly solved. It also has some features that HTTP doesn't. Cheers! [1] http://hackage.haskell.org/package/http-conduit -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: stm-conduit-0.2.1
Actually, that is a moderately fatal flaw. I just uploaded 0.2.2 which addresses this by highly recommending using bounded channels, as well as adding sources/sinks for them. Thanks for catching that! - clark On Thu, Feb 9, 2012 at 2:29 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: Your package uses TMChans which AFAIK are unbounded. That means that if the writer is faster than the reader, then everything will be kept into memory. This means that using TMChans you may no longer say that your program uses a constant amount of memory. Actually, you lose a lot of your space reasoning since, being concurrent processes, you can't guarantee almost anything wrt. progress of the reader. This doesn't mean that your package is broken, this means that it has a caveat that should be stated on the docs. Congrats on your Hackage debut! Cheers! =) -- Felipe. ___ 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
Quoth Evan Laforge qdun...@gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at the risk of stating the obvious, is it fair to say the root
of this problem is at least the lack of `first class' update syntax?
For example, in a better world you could write stuff like
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a) }
upTempo config = modifyConfig tempo (+ 20) config
... but today you get `fr' is not a (visible) constructor field name
So you need a modifyConfigTempo, etc. - when even the above is
inconveniently specific, as we'd rather have
modifyRecord :: RecordType r = (r - a) - (a - a) - r - r
I'm not saying modifyRecord (+ 20) tempo config would be the ideal
syntax for everyone who's been dreaming of records improvement, just
trying to get at the underlying problem with minimal syntactic
distractions. Nested structure doesn't look like a special problem -
modifyRecord innerRecord (modifyRecord inInField (+ 20)) outRecord
An operator with some infixing doesn't seem to buy a lot -
(innerRecord \{} (inInField \{} (+ 20))) outRecord
... but better might be possible without sacrificing composability.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Yesod] Re: Yesod and dependencies hell
On Thu, Feb 9, 2012 at 3:45 PM, Joachim Breitner nome...@debian.org wrote: Hi, Am Donnerstag, den 09.02.2012, 11:39 + schrieb Chris Dornan: (I do think that we could be delivering the tools with a little more packaging that could significantly help with these situations. I have found them to be highly useful in any case.) if you are content with not always having the very latest versions, you can use your distribution’s packages. Distributions tend to provide exactly one (well, at most one :-)) version of each hackage library, and they all go well together. But then, for a few more days, Debian sid is broken due to the GHC 7.4.1 transition... Greetings, Joachim Firstly, Yesod 0.10 is out, so if you upgrade, there shouldn't be any more dependency hell. I'm highly optimistic that there won't be much more of this kind of pain in the future. As far as using distribution packages: I've recommended against it in the past, due to the combination of Yesod's speed of development and the lack of package coverage. However, we're getting to a point now where Yesod development is stabilizing on solid APIs, and the distribution packages are beginning to cover many more dependencies. Perhaps by Yesod 1.0 (hopefully available next month), it will be a real possibility to depend entirely on distribution packages. I might start to experiment with that myself soon, don't be surprised if you hear some questions from me. Michael ___ 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
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a)
I like this Idea. The only problem I see is this: if I'm trying to write
code that is very generic and abstract, how does the compiler know if the
update
a { fr = 5 }
is targeting a field fr of the record a, or a variable fr, which is in
scope and points to a first-class field. The difference depends on the
record in question, so the code would work differently depending on the
context. I would think it would have to be something like
a { :fr = 5 }
or something else syntactically distinct from current record update syntax.
With this and a few more conveniences on record syntax, lenses could go
away. For example, I'd love to see a lambda update syntax. For example
instead of:
setName n r = r {name = n}
we'd write
setName n = \{name = n}
I'd also like to see an Update field by syntax. Instead of
addMr r = r { name = Mr. ++ (name r) }
we'd write
addMr r = r { name = (Mr. ++) }
or combining the previous 2:
addMr = \{name=(Mr. ++)}
feels very terse and Haskelly to me.
Regards,
--J Arthur
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: hs-json-rpc 0.0.0.1
Felipe Almeida Lessa wrote: [Redirecting to haskell-cafe] Congrats on your first release! While I haven't looked into your package in more depth, I'd suggest taking a look at http-conduit [1]. While I don't know of any benchmarks, it should be faster or at least as fast the HTTP package. It's also used by many people everyday (myself included), which means that it has no major bugs and that bugs are promptly solved. It also has some features that HTTP doesn't. +1 on http-conduit. I think the main feature that http-conduit has which HTTP lacks is support for secure HTTPS operations. With http-conduit being part of the Wai/Warp/Yesod stack I believe this is a high tested and rigorously maintained piece of code. 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] Error in installing dph-examples on Mac OS X 10.7.3
On 10/02/2012, at 6:12 AM, mukesh tiwari wrote: Hello all I am trying to install dph-examples on Mac OS X version 10.7.3 but getting this error. I am using ghc-7.4.1. This probably isn't DPH specific. Can you compile a hello world program with -fllvm? Ben.___ 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 - record update
Donn Cave donn at avvanta.com writes:
Quoth Evan Laforge qdunkan at gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at the risk of stating the obvious, is it fair to say the root
of this problem is at least the lack of `first class' update syntax?
No, Donn, it's not the lack of syntax, it's the lack of semantics for first-
class (polymorphic) record update. And there's very little that's obvious. SPJ
was not very happy with any of this.
SPJ in the SORF proposal asks:
what does e { x = True } mean if there are lots of x fields in scope?
(which is precisely what we want to allow)
So he's supposing some syntax -- where `e' is some expression that evaluates
to a record. (There's a shorter discussion in the TDNR proposal.)
If Haskell supported polymorphic update semantics (as well as polymorphic
field selection), you could build for yourself all those update idioms you
talk about.
More abstractly, can Haskell offer a polymorphic `set' (and `get') method for
the `Has' class?
set :: (Has r fld t) = fld - t - _r - r
get :: (Has r fld t) = r - fld - t -- fld in record r at type t
-- where fld is a type/Kind that identifies the field
The SORF proposal discusses lots of awkward cases which make polymorphic
update difficult.
I've built a prototype that hacks round some of those cases. SPJ's view (on a
quick inspect) is that it's workable in some cases, limited in others, and not
scalable in general.
Are you/everybody here prepared to give away some of the current record
features so that you can go poly?
- Do you want to change the type of a record?
(that's why I've put `_r' in `set's type
`_r' is the as-was type that we're throwing away.)
Haskell currently supports changing the type of the record.
(SPJ doubts whether type-changing has ever been a valuable feature.
So do I.)
- Do you want to update Higher-rank fields?
(typically used in records representing OO-style objects)
Or is it enough to initialise the HR field when you create the record,
then never change it?
How many forall'd variables might you like in the HR field?
- Do you want to put constraints on the HR's forall'd types?
This is where the issue is stuck. Very possibly if we agree workable
constraints, we're going to just run into further difficulties (like type
inference becoming unmanageable without lots of type annotations to help
resolve instances).
AntC
___
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 -record update
Quoth AntC anthony_clay...@clear.net.nz,
...
No, Donn, it's not the lack of syntax, it's the lack of semantics for first-
class (polymorphic) record update. And there's very little that's obvious.
Ah, you're right, I certainly shouldn't have used the word syntax there.
But just to be clear on the point, I wonder if you could expand on what
you mean by polymorphic above.
I mean, when I wrote
modifyRecord :: RecordType r = (a - a) - (r - a) - r - r
... while this does obviously represent a polymorphic function,
if I write
data Config { tempo :: Int, ...}
f = modifyRecord tempo (+20)
... then f has type Config - Config, it isn't polymorphic.
I am however vaguely aware that some parties to the Record
Question would like to make record fields themselves polymorphic, so
that 'tempo' could be defined for multiple record types and 'f'
would, I suppose, have a type like RecordThatHasTempo r = r - r
Maybe that's semantically more like overloading, but in any case,
it isn't strictly necessary in order to support first class updates,
true?
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fancy REPL
On Thu, Feb 9, 2012 at 3:04 PM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: I'm not so sure about the soon part, but yes, using FRP to make music is part of the plan. you know, i've been thinking about this recently, and while i need more haskell skillz if i want to do some sound synthesis, i think it would be really spiffy to work on something like that! are you working on this privately or do you have a public repo one can clone? a fully-haskell sound synth program would be really spiffy!! (esp if one could code new synths in real-time in haskell) hex -- * my blog is cooler than yours: http://serialhex.github.com * The wise man said: Never argue with an idiot. They bring you down to their level and beat you with experience. * As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow. ~Doug McIlroy No snowflake in an avalanche ever feels responsible. --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?” ___ 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
On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave d...@avvanta.com wrote:
Quoth Evan Laforge qdun...@gmail.com,
...
The non-composing non-abstract updates are what bug me, and
make me scatter about tons of 'modifyThis' functions, both for
composability and to protect from field renames.
So ... at the risk of stating the obvious, is it fair to say the root
of this problem is at least the lack of `first class' update syntax?
I think there are two problems, or at least the way I'm thinking about
it I'm decomposing it into two parts. One is the lack of first class
and composable update, but that is solved satisfactorily by lenses.
The second is how to write those composable first class names without
getting RSI. So at least the way I'm thinking currently, only the
second needs to be solved.
Module qualified names work, but are wordy. Importing unqualified
leads to clashes. Typeclasses can solve that, but are global so
they're kind of too unqualified---no export control. So by that
logic, we need either export control for typeclasses or some other
kind of automatic resolution which is not global, like my #suggestion.
Both would be orthogonal and interesting features in their own right,
but now that I think of it maybe export control for typeclasses or
closed typeclasses might fit in better. I know a lot of people have
wanted those though, so maybe there are serious snags.
For example, in a better world you could write stuff like
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a) }
upTempo config = modifyConfig tempo (+ 20) config
I think lenses already do better than this, since not only are they
more concise than the above (once you've resigned yourself to a few TH
splices), they aren't restricted to being only record fields.
I've done this before:
data Event = Event { event_string :: String, ... }
-- oops, strings are inefficient, but Event is already used in many places
-- most of which enjoy the convenience of Strings and are not in hotspots:
data Event = Event { event_text :: Text, ...}
event_string = Text.unpack . event_text
With lenses you can do this for update as well:
event_string = lens (Text.unpack . event_text) (\s e - e { event_text
= Text.pack s })
You can also enforce invariants, etc. It would be a shame to have a
nice record update syntax only to be discouraged from using it because
it would tie you too tightly to the current shape of the data
structure. There would always be a tension and every time I wrote
down a new type I'd waste some time thinking: is the record big enough
to want to define functions, or can I get away with direct access? Of
course it may *get* bigger later so...
It's the same tension as direct access vs. accessors in the OO world, I guess.
___
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 -record update
Donn Cave donn at avvanta.com writes:
-- modifyRecord :: RecordType r = (a - a) - (r - a) - r - r
modifyRecord :: RecordType r = (r - a) - (a - a) - r - r
... while this does obviously represent a polymorphic function,
Exactly!
if I write
-- data Config { tempo :: Int, ...}
data Config = Config { tempo :: Int, ...}
f = modifyRecord tempo (+20)
...
But f defined like that is exactly what you can't write now (even with the
args round the same way as the signature ;-), because:
* `tempo' is a function to select a field out of a record, *and only that*.
So there's no way in the body of modifyRecord to use its (r - a)
argument to put the updated `a' back into `r'.
* You can't (in current Haskell) put in place of `tempo' any type/species
of a term that could achieve that update, except by either:
making modifyRecord in effect monomorphic to Config/tempo,
or building a polymorphic update system wot we 'ave no' go' (yet).
... then f has type Config - Config, it isn't polymorphic.
You can do:
f Config{ tempo, .. } = Config {tempo = tempo + 20, ..}
And that does yield f :: Config - Config
(But I'm sure you knew that.)
OK, we could implement lenses, make `tempo' a lens instead of a selector,
desugar the update syntax to call the update 'method' out of the lens, ...
And of course somehow arrange the sugar that when `tempo' appears in other
contexts we take the select 'method'.
You write up the proposal, and think through all the changes it would involve
over Haskell/GHC as is, and then we can compare it to all those other
proposals.
I think you'll still find you run into exactly the same difficulties I
mentioned around update for record changing, Higher-ranked, etc.
I am however vaguely aware that some parties to the Record
Question would like to make record fields themselves polymorphic,
Yes, for example Jonathan Geddes' post:
setName n r = r {name = n}
addMr r = r { name = Mr. ++ (name r) }
(Jonathan's post is asking for alternative syntax: that's rather ambitious
when we can't yet write anything like that currently, indeed we don't even
know how we could implement it in general.)
His context is, presumably, having lots of different record types all with a
field `name'. (Arguably he should adopt long_and_meaningful_names for his
various fields.)
Maybe that's semantically more like overloading,
Yes, I've implemented it as overloading.
but in any case,
it isn't strictly necessary in order to support first class updates,
true?
Donn
Well, I think we might be getting stuck here with what does 'first class
update' mean?
The narrow issue we're trying to address is namespacing, and specifically name
clashes: two different records with the same named field.
I can't do better than quote SPJ again, sorry (not very) to repeat myself:
SPJ in the SORF proposal asks:
what does e { x = True } mean if there are lots of x fields in scope?
(which is precisely what we want to allow)
It's true that each x is monomorphic (in the sense of being tied to a
specific record and field type), but at the time the compiler encounters that
expression, it doesn't know the type of `e'. (In general, `e' is some
arbitrary expression -- perhaps selecting a record out of a keyed array?)
So the compiler relies on the name x being monomorphic to tell it. In
contrast, -XDisambiguateRecordFields copes with different xs by insisting
you put the Record's data constructor in place of the expression `e'.
If we want to turn this into a syntax question, we perhaps need a way of
putting both an expression and a data constructor in with the field and the
value to update. But note that the x in { x = True } is sort of hard-coded,
there's currently no way to put an expression in its place.
So you still can't define a modifyConfig: you couldn't put anything in place
of its (r - a) parameter that could represent x.
Now in return for me answering that, please answer the questions in my earlier
post about what limitations on update you'd like:
* record-type changing?
* Higher-ranked fields?
* How many forall'd variables?
* Constrained forall'd variables?
Thank you
AntC
___
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
Quoth Evan Laforge qdun...@gmail.com,
On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave d...@avvanta.com wrote:
...
For example, in a better world you could write stuff like
modifyConfig :: (Config - a) - (a - a) - Config - Config
modifyConfig fr fv a = a { fr = fv (fr a) }
upTempo config = modifyConfig tempo (+ 20) config
I think lenses already do better than this, since not only are they
more concise than the above (once you've resigned yourself to a few TH
splices), they aren't restricted to being only record fields.
How more concise? Because =# is more concise than `modifyRecord', etc.,
or is there some real economy of expression I missed out on? Asking
because, honestly I didn't get your earlier example -
setTempo :: Config - Config
setTempo y = Config.deflt#Config.tempo =# y
... something's missing, I thought - but maybe it's conciser than
I can reckon with!
The rest - the functions that look like fields, the enforcing invariants,
etc. - are cool as lens features, but for Haskell records in general it
seems like something that would call for a lot of discussion. Compared
to first class record update, where it's easy to see how close to broken
the current situation is.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The State of Testing?
On Thu, Feb 9, 2012 at 6:57 PM, Thomas Tuegel ttue...@gmail.com wrote: You need Cabal 1.12 for '--enable-library-coverage'. The only place it's documented is in 'cabal configure --help' (a major oversight on my part). The online docs for Cabal are only from version 1.10 anyway, so that wouldn't have helped. I'm sorry for your struggles getting the detailed type to work. It's a known issue: the detailed test interface is intentionally disabled in all the released versions because it's going to change. That's why none of the test libraries support it yet and why you weren't able to get it to work. No problem - I was just wondering where my error lay. The stdio tests do the trick for the time being. - Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error in installing dph-examples on Mac OS X 10.7.3
It may be a problem with the gloss / opengl dependencies? do you have those packages installed? I had similar trouble earlier this week wrt dph-examples, and that was the root of the matter in my case -Carter On Thu, Feb 9, 2012 at 7:04 PM, Ben Lippmeier b...@ouroborus.net wrote: On 10/02/2012, at 6:12 AM, mukesh tiwari wrote: Hello all I am trying to install dph-examples on Mac OS X version 10.7.3 but getting this error http://hpaste.org/57699. I am using ghc-7.4.1. This probably isn't DPH specific. Can you compile a hello world program with -fllvm? Ben. ___ 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] Some thoughts on Type-Directed Name Resolution -record update
Quoth AntC anthony_clay...@clear.net.nz, Donn Cave donn at avvanta.com writes: ... The narrow issue we're trying to address is namespacing, and specifically name clashes: two different records with the same named field. ... Now in return for me answering that, please answer the questions in my earlier post about what limitations on update you'd like: * record-type changing? * Higher-ranked fields? * How many forall'd variables? * Constrained forall'd variables? All right, but it won't be a very interesting answer; partly because I personally do not find the name clash issue per se as compelling as some - I mean, it can be a nuisance for sure, but it isn't broken the way update per se is broken - and partly because, as best as I can make out, I have never dreamed of using any of those four features. So I hope someone with more invested in the problem will chime in! Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
