September 2015 - Haskell-Cafe

the library of beautiful instruments implemented in haskell / csound
by Anton Kholomiov 14 Sep '15

14 Sep '15

Status update for my haskell synth csound-expression. The main point is presence of many cool instruments. They are implemented in the package csound-catalog. All packages are compiled with GHC-7.10 So the hackage fails to build them and unfortunately docs a broken too. But you can look at the source code of the module Csound.Patch to now the names of the instruments. The usage is pretty straightforward. It's described here: https://github.com/spell-music/csound-expression/blob/master/tutorial/chapt… There is an mp3 file to listen to the instruments. http://ge.tt/1jNETqN2/v/0 *The 4.8.3 is out! New features:* This is a very important release to me. It tries to solve the problem present in the most open source music-production libraries. It's often the pack of beautiful sounds/timbres is missing. User is presented with many audio primitives but no timbres are present to show the real power of the framework. This release solves this problem. See the friend package csound-catalog on Hackage. It defines 200+ beautiful instruments ready to be used. The csound-expression defines a new type called Patch for description of an instrument with a chain of effects. It's good place to start the journey to the world of music production. There are new functions for synchronized reaction on events. The triggering of events can be synchronized with given BPM. The library is updated for GHC-7.10! github repo: https://github.com/spell-music/csound-expression hackage: http://hackage.haskell.org/package/csound-expression Cheers!

3 5

The semiring of Scott reals (Thoughts about redesigning "Num" type class)
by Olaf Klinke 13 Sep '15

13 Sep '15

This departs somewhat from the thread's topic. Below I detail a semiring R that is not a ring because negation is not definable in Haskell. I further sketch integration in Haskell which I ripped off papers by Gordon Plotkin, Steve Vickers, Anders Kock and others. Infinity comes in as a limit, of course. Approximate a real number by an ascending stream of rational numbers. (The ascending can not be enforced by Haskell's type system, of course.). What you have is a so-called lower real or Scott real. Still addition and multiplication is continuous on such reals and there is a unique way of extending these operations to infinity, represented by any strictly ascending stream. Neither subtraction not division are computable for the Scott reals. Indeed, to know a lower bound of x-y one needs to know upper bounds of y. Denote this type by R: type R = Stream Rational Further consider ascending streams of Booleans, where any two streams containing True are considered semantically equivalent. type S = Stream Bool Consider the following types: type ScottOpen x = x -> S type V x = (ScottOpen x) -> R Certain elements of the type V x are called valuations, assigning to any Scott open subset[*] of x a lower real number. The type constructor V has a monad instance. If there was a one-element type in Haskell (say 1), then V 1 is isomorphic to R. Hence a lower semicontinuous real-valued function f :: x -> R is the same as a function f :: x -> V 1. Now observe that (=<<) :: (x -> V 1) -> V x -> V 1 :: (x -> R ) -> V x -> R has the type of an integral operator. In other words, the bind of the monad V implements integration. I have an implementation that lets you do integration over any Haskell type, but it is very slow. An analogue of this is the monad []. Indeed, total elements of type N = [()] are natural numbers. Disregarding permutations, an element of [x] assigns to finitely many elements of x a weight from the natural numbers. Then (=<<) :: (x -> [()]) -> [x] -> [()] :: (x -> N ) -> [x] -> N is the integral operator integrating natural-number-valued functions against a finite natural-number-valued measure. Further observe that liftM2 (flip const) :: Monad m => m () -> m x -> m x is a monoid action that implements multiplication on N. It distributes over (++) for categorical reasons: (++) arises from the isomorphism (up to permutation) ([a],[b]) -> [Either a b]. As an exercise, define a monad instance for type FinDist x = [(x,Rational)] Hint: FinDist x = WriterT (Product Rational) [] x and observe that FinDist () is isomorphic to Rational (up to some equivalence relation). Voila: You have integration of Rational-valued functions against finitely supported distributions. For many combinatorial applications, this is sufficient. [*] For u :: x -> S, consider the set of elements of x for which u produces a stream containing True. This is the Scott open subset. Valuations are required to send the empty open to the constant zero stream and further obey the modular law you know from measures: v(u) + v(u') = v(union u u') + v(intersection u u') where union = liftA2 max and intersection = liftA2 min. -- Olaf

2 1

ANNOUNCE: ioctl 0.0.1
by Maciej Piechotka 13 Sep '15

13 Sep '15

A package for type-safe I/O control. Currently only ioctl is supported. Currently simply a extract from my tuntap fork TODO: - Return the integer as well as structure (will break the API) - Port for Windows Network.Socket.IOCtl (as soon as I manage to setup some sane environment on this platform) - Wrapping around DeviceIoControl Example (in hsc): data NotRead = NotRead instance NotRead Int where ioctlReq _ = #const FIONREAD notRead s = ioctlsocket' s NotRead Regards

2 1

Re: [Haskell-cafe] haskell est il compatible avec mon projet graphique ?
by Daniel Díaz 13 Sep '15

13 Sep '15

Pardonnez mon mauvais français. Il existe des liaisons pour SDL2: http://hackage.haskell.org/package/sdl2 Aussi jeter un oeil à "diagrams" http://projects.haskell.org/diagrams/gallery.html On Saturday, September 12, 2015 at 6:17:04 AM UTC+2, Vincent Douce LR wrote: > > salut à tous > je dois réaliser des créations graphiques, avec deux destinations : des > animations sur l'écran, et des images fixes destinées à être publiées sur > papier > ces créations reposent sur des algorithmes de mon crû > je souhaite me créer une bibliothèque de séquences de code que je pourrai > étoffer au fur et à mesure et utiliser dans mes programmes > je cherche quel langage adopter, et quel pendant graphique lui adjoindre > j'envisage des pistes comme C+sdl ou python +? > utiliser haskell serait un défi parce que c'est moins intuitif pour moi un > langage fonctionnel et aussi tout simplemetn parce que je n'y connais rien > en haskell, je sais juste un peu de Scheme > mais peut être qu'il y a dans l'univers haskell un moyen de générer des > graphiques de qualité ? je susi ouvert > qu'en pensez-vous ? >

2 1

Re: [Haskell-cafe] Thoughts about redesigning "Num" type class
by Olaf Klinke 12 Sep '15

12 Sep '15

I sencond the statement that semirings might be a useful typeclass to have. Another example: Non-negative reals with infinity, the values that a measure can take. Nevertheless the biggest issue is what _symbol_ to use for the operations. We know that a ring is a semigroup in two ways, and no matter what semigroup structure we think the ring to "originate" from, we're going to annoy the other half of users who thought it the other way around. Some semigroups are thought of as (+), others as (*). Picking one of these symbols for all semigroups will be counter-intuitive for some structures. As to affine structures, Martin Escardo and Alex Simpson have a paper showing that the unit interval is the free cancellative midpoint algebra over two generators. They have Haskell code for this [1]. And yes, a typeclass is not a mathematical category, but Haskell is a language that lets you formalise quite a bit of category theory, and this is a cool thing to have. You can read a paper based on category theory and obtain executable code with very little effort. There are now entire Ph.D. theses written in Agda. To me it seems that the solution to the Num typeclass problem would be to have sub-typeclass statements that let you introduce aliases for the operations, as so: class Semigroup a where (<>) :: a -> a -> a class Group a where (*) :: a -> a -> a unit :: a inverse :: a -> a superclass Semigroup Group where (<>) = (*) But wait, we do have a mechanism for aliases: It's called newtype! Conclusion: If you want to express that any Num instance is a Group, do so with a newtype. Data.Monoid is a good example for this. -- Olaf [1] http://www.cs.bham.ac.uk/~mhe/.talks/map2011/martin_map.pdf

4 3

Re: [Haskell-cafe] lazily updating dependencies, git submodules and cabal
by timmy tofu 10 Sep '15

10 Sep '15

> > Using the 'cabal sandbox add-source' solution now requires that I > "add-source" the MarketModel package too. Otherwise, any change I make > to this package will not be tracked. > then… > Cabal sets the paths for "import"ed > modules in the "hs-source-dirs:" and that is global to the whole > package. > I can't tell if you do or do not want ProfitCalculator and Persistence to track changes made in MarketModel. If you do, and both should be in lock-step with it (unlike your situation with Tax), then you don't have a problem. If not, then the problem is Trader would depend on ProfitCalculator which might depend on a different version of MarketModel than Persistence (upon which Trader also depends). That is a classic dependency problem and not a function of submodules or add-sourcing, per se. The Trader module seems to be at the top of this heap - why would you want the Trader to (indirectly) use one version of MarketModel through ProfitCalculator, and another through Persistence?

3 2

Best deployment method for Hakyll websites (with Stack)?
by Nicola Gigante 10 Sep '15

10 Sep '15

Hello, Note, this is not a Hakyll question, after all. I’m trying to host a hakyll website on a CentOS 7 server. I want to replicate the setup I had with the previous site, made with Jekyll: at each push on the git repository (hosted on the same server), the branch is recompiled and deployed to the web server. I already have the git hooks in place etc… The problem is how to manage the installation of ghc, hakyll, and their dependencies. I really really wish to have a clean solution. I really like stack, but its “per-user” directories make me wonder. The site compilation has to be performed by the git user account, which does not have an home directory. Can I setup a stack installation of a set of packages and then point stack to use that and only that? Also, how about the integration with docker? Is it really so painless as it is advertised? If I’ve understood correctly, I could install the docker image with stackage packages already installed, and tell stack to use that image with docker, having the site compilation sandboxed. Is it feasible? Thank you for any advice, Nicola

5 4

Senior Haskell developer roles at Standard Chartered, Singapore
by Don Stewart 10 Sep '15

10 Sep '15

The Strats team at SCB has two more open roles for Haskell developers in Singapore. These are exciting "director level" development roles in a large team. Location is Singapore. Details here: https://donsbot.wordpress.com/2015/09/10/senior-haskell-developer-roles-at-… Please contact me for more details.

1 0

lazily updating dependencies, git submodules and cabal
by Dimitri DeFigueiredo 09 Sep '15

09 Sep '15

Hello all, I am facing a problem that I assume others have seen before, but am stumped for a solution. It's not about Haskell per se, but about how to organize my haskell code to play nicely with the build tools. #The Setup I am currently developing a bitcoin trading agent. I produce 2 executables: the "Trader" and the "Tax" calculator. These 2 executables share a common dependency to talk to a SQLite3 database in their "Persistence" layer. (I actually have 3 levels of dependency, but we'll get to that later) I spend most of my time working on the Trader and the Persistence layer. These are just different source code files: Trader.hs and Persistence.hs. The problem is that as I update the Persistence.hs file I break Tax.hs. Because I am "lazy" and only really have to calculate taxes once I year. I do *not* want to have to continuously modify the Tax.hs file to keep up with the development in the Persistence layer. I just want it to use an old version, so that I only have to bring it up to speed later. In other words, I want to: 1. always be able to compile both executables, 2. delay updating an executable because of changes in a common dependency as much as possible. I want to be lazy and delay updating my Tax.hs code to work with latest version of the Persistence layer a much as possible. At the same time, the Trader and Persistence layer are worked on simultaneously. #My Current Solution The immediate solution that comes to mind is to put these files in 3 different packages. That way, I can use version 1.5 of the Persistence layer for the Tax calculator, but still develop version 2.0 at the same time as working on the Trader. I can use 'cabal sandbox add-source' to immediately get changes made to the Persistence layer as I develop the Trader. There is one minor problem with this approach: I have to manually track the version numbers. I need to put the proper version number in the "build-depends" section in the .cabal file. For example, for Tax.cabal I would have: "build-depends: persistence == 1.5". There is a different approach that is completely orthogonal to using Cabal packages. I can put each of the 3 files (Trader.hs, Tax.hs and Persistence.hs) in 3 different repositories and use git submodules. The Persistence layer would be a submodule of both the Trader and the Tax repos. As each submodule just points to a specific commit in the Persistence repo, I don't have to manually track version numbers and the Trader and Tax calculator can point to different commits and use different versions of the Persistence layer. The git solution is really convenient because when you clone a repo (with --recursive), it comes with the correct versions of the dependencies you need. This is what I did. #The Problem The problem I am facing is that I now have 3 (or more) levels and multiple dependencies. There are 2 changes to the original setup: 1. Persistence.hs now imports MarketModel.hs and that also changes pretty quickly as I develop the Trader. 2. The Trader now also depends on ProfitCalculator.hs that also imports MarketModel.hs Using the 'cabal sandbox add-source' solution now requires that I "add-source" the MarketModel package too. Otherwise, any change I make to this package will not be tracked. In fact, I have to "add-source" two different versions of MarketModel (in general, there's an exponential blow up as the number of levels increases). The manual tracking of version numbers in the cabal file also becomes critical. If I forget to update a version number, the package will be reinstalled over an existing one that's being used. This quickly becomes a mess. The git submodule solutions doesn't work either. Although GHC does the right thing and only complains about two modules with the same name if I use a symbol that is ambiguous. Cabal sets the paths for "import"ed modules in the "hs-source-dirs:" and that is global to the whole package. I can't say: 1. first, compile the Persistence.hs file by "import"ing files in the path /trader/persistence/marketmodel, 2. now, compile the ProfitCalculator.hs by "import"ing files in the path /trader/profitcalculator/marketmodel. That path is the same for the whole project and I can't use different versions of MarketModel.hs In short, it seems no solution works anymore. Is there a way to make this work? Is there another way for me to be lazy about updating my dependencies when building multiple targets? Any pointers on this would be much appreciated! Thanks, Dimitri

1 0

emacs haskell-mode with cabal exec, test suite sections
by Stuart Popejoy 09 Sep '15

09 Sep '15

I'm having trouble coding test-suite and executable sections with the emacs REPL and flycheck. 1. cabal-repl can compile against the library code, but fails to see any modules within the non-library section. 2. flycheck has the opposite problem: it fails on library module imports but recognizes imports local to the section. Note I don't always have these issues, but they seem to crop up whenever I upgrade GHC, or emacs, or haskell-mode, flycheck-haskell etc. I'm not sure #1 ever works, but #2 is happening to me on my mac, but not at work on Linux. For #1, in the past I've tried a big .dir-locals.el to use `ghci` for the repl and just import everything -- of course losing the nice cabal integration, plus it being slow as molasses to load source files. I also briefly investigated modifying haskell-mode to support separate sessions for a given section. For #2, flycheck is just a pain to debug, my only recourse is to stick debug output into `flycheck-start-command-checker` to see what commands are going out, and try to troubleshoot. Any thoughts or suggestions? Commiseration is OK too :) Thanks, Stuart

3 5