December 2015 - Haskell-Cafe

RFC: explicit support for GADTs in Template Haskell
by Jan Stolarek 22 Dec '15

22 Dec '15

GHC Users, I am working on adding proper support for GADTs in Template Haskell. By proper I mean that GADTs data constructors will no longer be encoded using H98 data constructors, but will be represented explicity. GADTs allow to declare several constructors with the same signature: data T where MkT1, MkT2 :: T The question is whether to represent such constructors in TH syntax as: (1) GadtC [Name] [StrictType] Name [Type] -- or: (2) GadtC Name [StrictType] Name [Type] Note the difference in first field. (1) is closer to the original syntax, as it stores the list of all names in a single declaration, as was originally written in the source code. (2) requires to have a separate `GadtC` for each constructor even if constructors were declared together, as in the example above. I would like to hear from TH users which of these two representations you prefer. At the moment I have implemented (1) as it directly represents source syntax. The downside of (1) is that information whether several data constructors were declared together is not recoverable during reification, and so reifying T will yield: data T where MkT1 :: T MkT2 :: T Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 2

wondering on Haskell kickstarter project: VST plugin / mobile synthesizer
by Anton Kholomiov 22 Dec '15

22 Dec '15

I'm wondering if it's good idea to make crowd-founding project for a synthesizer written in Haskell. What's your opinion? Would you like to support such a project? I've made a prototype: https://github.com/anton-k/tiny-synth It's a desktop synthesizer, a collection of instruments. About 150 instruments written in Haskell. It works with midi keyboard. You can try it out with USB-midi device. The UI is written with Python and audio engine is written with Haskell. I use my library csound-expression to generate the code for Csound. The Csound is an audio programming language it can be used as C library. There are bindings to many languages and it can work on Android / iOS. Right now I've made a prototype for desktop. The big plan is to create VST/AU/Lv2 plugins and mobile versions for Android and iOS. [1] https://github.com/anton-k/tiny-synth [2] http://hackage.haskell.org/package/csound-expression [3] https://github.com/spell-music/csound-expression Cheers, Anton

2 3

More disciplined alternative to rewrite rules?
by Will Yager 22 Dec '15

22 Dec '15

Has there been any discussion of replacing rewrite rules with a more disciplined and robust system? Some problems I've noticed with rewrite rules are: A) It's highly syntactic. It isn't really capable of encapsulating intent; it just does restrictively simple term manipulation. B) As a result, many performance-oriented modules seem to have an ungainly number of rewrite rules so as to cover every likely case. C) There are many cases where rewrite rules fail to work as intended, either because the module author missed a rewrite case or because the rewrite fails to fire for some reason. Perhaps a good approach would be to implement a rewrite system in a domain more amenable to simplification rules. For example, there has been a great deal of (quite successful) work on circuit simplification in the form of operations on graphs. Haskell is quite amenable to graph representations, so this approach might work for Haskell as well. -Will

1 0

Imported rewrite rules are ignored
by Johannes Waldmann 22 Dec '15

22 Dec '15

Forgot to say: I confirm your observation for ghc-7.* and I checked that the imported rule *does* fire with ghc-6.10.4.

1 0

Imported rewrite rules are ignored
by Johannes Waldmann 22 Dec '15

22 Dec '15

Well, ghc --show-iface RuleModule.hi does show the rule: rewrite_me :: () -> () {- Strictness: b, Inline: NOINLINE -} "rewrite_me" [ALWAYS] forall input :: () rewrite_me input = ()

1 0

New Functional Programming Job Opportunities
by Functional Jobs 22 Dec '15

22 Dec '15

Here are some functional programming job opportunities that were posted recently: Software Engineer (Scala/Play/Scala.js/React) at AdAgility https://functionaljobs.com/jobs/8871-software-engineer-scala-play-scalajs-r… Cheers, Sean Murphy FunctionalJobs.com

1 0

Imported rewrite rules are ignored
by Alexander Vieth 22 Dec '15

22 Dec '15

Hi café, I observe that rewrite rules from imported modules are ignored by GHC. Given these two files, one module and one executable, the problem can be demonstrated by switching between `rewrite_me` and `rewrite_me_local`. If the rule fires, the program should run cleanly, as the `error` term should be rewritten to `()`. The imported function rewrite_me is not rewritten; but the same thing, rewrite_me_local, defined in the same program, will be rewritten. File RuleModule.hs module RuleModule where {-# NOINLINE rewrite_me #-} rewrite_me :: () -> () rewrite_me = error "Should rewrite" {-# RULES "rewrite_me" forall input . rewrite_me input = () #-} File Rule.hs import RuleModule {-# NOINLINE rewrite_me_local #-} rewrite_me_local :: () -> () rewrite_me_local = error "Should rewrite" {-# RULES "rewrite_local" forall input . rewrite_me_local input = () #-} -- Replace with rewrite_me_local and it's all good. main = case rewrite_me () of () -> return () This is GHC 7.10.2. I compile using -O -fenable-rewrite-rules. Using -dverbose-core2core, the "Desugar (after optimization)" section shows no rules when using rewrite_me, but shows the rule rewrite_local when using the local variant. Maybe this is expected, but I thought it important to mention. Thanks for any advice, Alex

1 0

Preventing sharing
by Oleg 21 Dec '15

21 Dec '15

The old article Preventing memoization in (AI) search problems http://okmij.org/ftp/Haskell/index.html#memo-off deals with the problem, explaining the trick to deliberately confuse GHC so that it won't perform memoization (sharing). Yes, I know how bad this confusing of GHC sounds: which is part of my argument that lazy evaluation by default was a mistake.

2 1

Clausula where
by vieira.ufpi＠gmail.com 20 Dec '15

20 Dec '15

I’m using GHCi in a Haskell version 7.10.2 and using this fragmente of coding: data ArvBinA t = Folha t | No Int (ArvBinA t) (ArvBinA t) deriving (Eq, Ord, Show) arvbina = No 4 (No 2 (Folha 14) (Folha 09)) (No 2 (Folha 19) (Folha 51)) tamArvBinA :: ArvBinA t -> Int tamArvBinA (Folha x) = 1 tamArvBinA (No n xt yt) = n rotula :: ArvBinA t -> ArvBinA t -> ArvBinA t rotula ae ad = No n ae ad where n = (tamArvBinA ae) + (tamArvBinA ad) listoArvBinA :: (Eq t) => [t] -> ArvBinA t listoArvBinA xs |m == 0 = Folha (head xs) |otherwise = rotula (listoArvBinA xse) (listoArvBinA xsd) where m = (length xs) `div` 2 (xse, xsd) = (take m xs, drop m xs) After compiling there is this message: parse error on input ‘=’. There is someone that he/she can help me? I think that’is na error by clause where and the offside rule, or so, but I’m not right of this. Thanks in advance for some help Francisco Vieira Enviado do Email do Windows

4 4

Re: [Haskell-cafe] No instance of ... error with Statistics.Sample.Histogram
by Sigrid Keydana 20 Dec '15

20 Dec '15

1 0