Re: [Haskell-cafe] Best FRP package for newbie
Netwire by Ertugrul Söylemez would be a good library to start with. If for some reason netwire doesn't quite suit your needs, take a look at Animas, a fork of Yampa. http://hackage.haskell.org/package/netwire-3.1.0 http://www.haskell.org/haskellwiki/Netwire On 17.2.2012 07:50, Arnaud Bailly wrote: Hello, I am interested in exploring more in depth FRP. I had a look at the wiki page and started to explore reactive which looked promising at first glance and backed by quite a few articles and tutorials, but 1) it did not install properly on my haskell platform and 2) from the mailing-list archives it seems to have died a couple of years ago. So my question is : What package would you recommend me to get my hands dirty with FRP? I am mostly interested in things related to music and network programming, if that matters. Thanks in advance for your help, Arnaud ___ 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] Best FRP package for newbie
Arnaud Bailly wrote: Hello, I am interested in exploring more in depth FRP. I had a look at the wiki page and started to explore reactive which looked promising at first glance and backed by quite a few articles and tutorials, but 1) it did not install properly on my haskell platform and 2) from the mailing-list archives it seems to have died a couple of years ago. So my question is : What package would you recommend me to get my hands dirty with FRP? I am mostly interested in things related to music and network programming, if that matters. Of course, I recommend my reactive-banana library. http://haskell.org/haskellwiki/Reactive-banana http://www.haskell.org/haskellwiki/Reactive-banana/Examples 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] Best FRP package for newbie
Gabríel A. Pétursson gabri...@simnet.is wrote: Netwire by Ertugrul Söylemez would be a good library to start with. If for some reason netwire doesn't quite suit your needs, take a look at Animas, a fork of Yampa. http://hackage.haskell.org/package/netwire-3.1.0 http://www.haskell.org/haskellwiki/Netwire Even though Netwire seems to be the library of choice for your purposes, it is not exactly beginner-friendly. Heinrich Apfelmus' reactive-banana library is much easier to get into, so you may want to start with that one before approaching Netwire. In any case, I can't really recommend Animas or Yampa. They are a proof of concept, but in real world applications they proved to be unfortunate choices, which was the original motivation for me to write Netwire in the first place. 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] Good Java book? (not off-topic)
I've always found Bruce Eckel's Thinking in Java the best introductory book to the practice of object oriented programming and Java. There's a sample online http://www.mindviewinc.com/TIJ4/BookSampleDownload.php Whether this is in concordance with FP principles or not is a different thing, but the point is to introduce OO and Java, isn't it? Anyway, I don't think it's damaging if you later get to use Haskell and formal methods (I went myself through that as well). Cheers, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell implementation of a database?
Hi, I'm the author of Siege, see https://github.com/DanielWaterworth/siege . It's not production ready, but it's in active development. Daniel On 17 February 2012 06:56, Vasili I. Galchin vigalc...@gmail.com wrote: Hello, I have been looking through Hackage database for a Haskell implementation of a database(not a binding) but couldn't find anything. Probably it was under my nose?? Vasili ___ 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] Best FRP package for newbie
I got started in FRP with Yampa, and I currently maintain Animas, which is a fork. AFAIK no one is really doing much with either anymore. Yampa and Animas are both messy both in implementation and the exposed interface. I did start with Yampa, but it was incredibly frustrating because the abstraction is very leaky and thus things often don't work as you'd expect. The only real changes to Animas are the addition of some primitives for evaluation when you don't want a tight loop. I'm currently writing a Masters thesis on FRP which will hopefully result in a much nicer signal function library, but of course you don't want to wait that long. What I can offer though is to try to answer any questions you might have as you're exploring FRP. Netwire and reactive-banana both sound like good choices, though I haven't really toyed much with either of them so I can't really make a firm recommendation. On Fri, Feb 17, 2012 at 2:50 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I am interested in exploring more in depth FRP. I had a look at the wiki page and started to explore reactive which looked promising at first glance and backed by quite a few articles and tutorials, but 1) it did not install properly on my haskell platform and 2) from the mailing-list archives it seems to have died a couple of years ago. So my question is : What package would you recommend me to get my hands dirty with FRP? I am mostly interested in things related to music and network programming, if that matters. Thanks in advance for your help, Arnaud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: unification-fd 0.6.0
-- unification-fd 0.6.0 The unification-fd package offers generic functions for single-sorted first-order structural unification (think Prolog programming or Hindley--Milner type inference)[1][2]. I've had this laying around for a few years, so I figured I might as well publish it. An effort has been made to try to make this package as portable as possible. However, because it uses the ST monad and the mtl-2 package it can't be H98 nor H2010. However, it only uses the following common extensions which should be well supported[3]: Rank2Types MultiParamTypeClasses FunctionalDependencies -- Alas, necessary for type inference FlexibleContexts -- Necessary for practical use of MPTCs FlexibleInstances -- Necessary for practical use of MPTCs UndecidableInstances -- For Show instances due to two-level types -- Changes (since 0.5.0) * The kind of variables has been changed from *-* to *. Thus, the definition of MutVar is now exactly the free monad generated by t on v: data MutTerm v t = MutVar !v | MutTerm !(t (MutTerm v t)) This is a major API-breaking change, however it only affects the type level, and should only affect you if you're using the functions class-polymorphically or if you've defined your own variable types. -- Description The unification API is generic in the type of the structures being unified and in the implementation of unification variables, following the two-level types pearl of Sheard (2001). This style mixes well with Swierstra (2008), though an implementation of the latter is not included in this package. That is, all you have to do is define the functor whose fixed-point is the recursive type you're interested in: -- The non-recursive structure of terms data S a = ... -- The recursive term type type PureTerm = Fix S And then provide an instance for Unifiable, where zipMatch performs one level of equality testing for terms and returns the one-level spine filled with pairs of subterms to be recursively checked (or Nothing if this level doesn't match). class (Traversable t) = Unifiable t where zipMatch :: t a - t b - Maybe (t (a,b)) The choice of which variable implementation to use is defined by similarly simple classes Variable and BindingMonad. We store the variable bindings in a monad, for obvious reasons. In case it's not obvious, see Dijkstra et al. (2008) for benchmarks demonstrating the cost of naively applying bindings eagerly. There are currently two implementations of variables provided: one based on STRefs, and another based on a state monad carrying an IntMap. The former has the benefit of O(1) access time, but the latter is plenty fast and has the benefit of supporting backtracking. Backtracking itself is provided by the logict package and is described in Kiselyov et al. (2005). In addition to this modularity, unification-fd implements a number of optimizations over the algorithm presented in Sheard (2001)--- which is also the algorithm presented in Cardelli (1987). * Their implementation uses path compression, which we retain. Though we modify the compression algorithm in order to make sharing observable. * In addition, we perform aggressive opportunistic observable sharing, a potentially novel method of introducing even more sharing than is provided by the monadic bindings. Basically, we make it so that we can use the observable sharing provided by the previous optimization as much as possible (without introducing any new variables). * And we remove the notoriously expensive occurs-check, replacing it with visited-sets (which detect cyclic terms more lazily and without the asymptotic overhead of the occurs-check). A variant of unification which retains the occurs-check is also provided, in case you really need to fail fast for some reason. * Finally, a highly experimental branch of the API performs *weighted* path compression, which is asymptotically optimal. Unfortunately, the current implementation is quite a bit uglier than the unweighted version, and I haven't had a chance to perform benchmarks to see how the constant factors compare. Hence moving it to an experimental branch. These optimizations pass a test suite for detecting obvious errors. If you find any bugs, do be sure to let me know. Also, if you happen to have a test suite or benchmark suite for unification on hand, I'd love to get a copy. -- Notes and limitations [1] At present it does not appear amenable for higher-rank structural unification (a la HMF, MLF, or other System F type
Re: [Haskell-cafe] [haskell-cafe] Some reflections on Haskell
On 2/14/12 11:41 AM, Bardur Arantsson wrote: On 02/14/2012 04:13 PM, Doug McIlroy wrote: Nevertheless, I share Jardine's concern about the central problem. It is hard to find one's way in this ecosystem. It needn't be, as Java illustrates. As a professional Java developer this sounds really strange, but maybe I just haven't found it yet. Do you mean to suggest that it's easy to choose between e.g. Spring, Guice, etc., the umpteen OSGi containers, the several logging frameworks, etc. etc. etc.? I'm not sure I'd call myself a professional Java programmer ---though I've been paid for writing Java on numerous occasions--- but I'm with Bardur. The JavaDocs for the built-in libraries that come with Java are indeed excellent. However, once you move out of the built-in ecosystem and start using other people's projects, the quality of documentation degenerates rapidly. I can't recall how many opensource projects I've used for which the only thing provided by JavaDoc is the type signatures it could scrape off the code. While the documentation of Hackage projects could certainly be improved, on the whole I find it's much better than what you get from non-core packages for Java. The one big thing I think Hackage needs is better top-level organization. Right now it's hard to browse and find new packages for some topic you're interested in, in part because we're blessed with so many packages, and in part because some packages are properly considered as a group (e.g., Yesod, Kmett's replacement for category-extras,...) but this isn't well-captured by the current system. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unification-fd 0.6.0
* wren ng thornton w...@freegeek.org [2012-02-17 13:05:58-0500] An effort has been made to try to make this package as portable as possible. That's a noble goal for libraries! However, because it uses the ST monad and the mtl-2 package it can't be H98 nor H2010. However, it only uses the following common extensions which should be well supported[3]: Rank2Types MultiParamTypeClasses FunctionalDependencies -- Alas, necessary for type inference FlexibleContexts -- Necessary for practical use of MPTCs FlexibleInstances -- Necessary for practical use of MPTCs UndecidableInstances -- For Show instances due to two-level types Out of these FunctionalDependencies seems to be the most exotic (even in GHC-oriented development there has been some shift towards type families, it seems). Is it used only for mtl stuff (and thus can be replaced by 'transformers' + some lifts), or is it necessary for your own API? -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unification-fd 0.6.0
On 2/17/12 2:51 PM, Roman Cheplyaka wrote: Out of these FunctionalDependencies seems to be the most exotic (even in GHC-oriented development there has been some shift towards type families, it seems). Is it used only for mtl stuff (and thus can be replaced by 'transformers' + some lifts), or is it necessary for your own API? It is indeed used for the unification-fd API, mainly to assist type inference and to avoid the need to have type annotations everywhere (due to the use of MPTCs). The use of fundeps was largely because that's what I'd used when first writing it up a number of years ago, before understanding and implementation of type families had solidified and long before type families had gained much traction. However, the type family variant should be straightforward. In particular the classes using MPTCs are: class (Unifiable t, Variable v, Applicative m, Monad m) = BindingMonad v t m | m - v t where... class (BindingMonad v t m) = RankedBindingMonad v t m | m - v t where... AFAICT, those could be easily converted to the following without any loss in expressivity: class ( Unifiable (BMTerm t) , Variable (BMVar m) , Applicative m -- should be implied by (Monad m), but alas! , Monad m ) = BindingMonad m where type BMVar m :: * type BMTerm m :: * - * ... class (BindingMonad m) = RankedBindingMonad m where... The type signatures may get a bit uglier (as they tend to, due to type equality constraints and the calls to associated types being longer than type variable names), but given that they're not especially pretty to begin with, that's not really a concern. If the above does indeed work, then one nice thing is that it also gets rid of the need for MPTCs (except for the use of mtl's MonadError and MonadState), which brings it one step closer to being usable on JHC. I'm not sure what UHC's status is on implementing MPTCs, fundeps, and type families. The hesitation about releasing unification-tf with the above change implemented is just that I wanted to play around with the ranked unification stuff a bit more, to see if I could get it to a place I liked before forking the package. Also the lack of round tuits. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] empty fields are dropped in bytestring csv
the bytestring-csv package appears to have a bug whereby empty fields are dropped completely from the row, which is different to Text.CSV , which will return an empty field in the parse result. I'd argue this is a bug in bytestring-csv, anyone know whether this has been raised before, or know of a workaround? Prelude Data.Maybe Data.List Text.CSV.ByteString Data.ByteString.Char8 parseCSV $ pack a,b,c\n1,2,3\n1,,9\n Just [[a,b,c],[1,2,3],[1,9]] -- the last row has two fields ^ Prelude Text.CSV parseCSV /tmp/err a,b,c\n1,2,3\n1,,9\n Right [[a,b,c],[1,2,3],[1,,9],[]] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] BayHac '12
Please join us for a weekend of Haskell hacking: BayHac '12 April 20th ~ 22nd, 2012 Hacker Dojo Mountain View, CA This year will be concurrent with UHac in Utrecht, and technology willing, we'll be liking up to share the Hac between the continents! Full details on the Haskell Wiki: http://www.haskell.org/haskellwiki/BayHac2012 - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
