Re: [Haskell-cafe] No upgrade of GHC version in Ubuntu repository
Hi, Am Montag, den 14.10.2013, 15:34 +0200 schrieb Vlatko Basic: > Looks like we're missing the point here. I did add the PPAs, and all > is OK for me. :-) > > LTS is a stable release, and yet many other apps get updated regulary, > but GHC does not. GHC is not part of the system itself, it's just an > app, like many others are. So I expected it to be updated regularly, > as other do. > > This way it looks like it is abandoned... the problem is that if you update GHC, you’ll have to update lots of other packages, and rebuild all Haskell libraries. It’s difficult enough to target one release; supporting several would be a considerable amount of work to the maintainers. OTOH, it is not clear if they know that there is demand for it, and I don’t know Ubuntu’s release upgrade policies (Debian, for example, would not allow such an upgrade in a stable release), but maybe you should ask the maintainers of Haskell in Ubuntu? See https://wiki.ubuntu.com/MOTU/Teams/UncommonProgrammingLanguages/Haskell for a possibly up-to-date list of them. 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] Stackage with GHC 7.8 has started
Hi, Am Sonntag, den 13.10.2013, 17:50 +0200 schrieb Michael Snoyman: > I wanted to announce that FP Complete is now running a Jenkins job to > build Stackage with GHC 7.8. You can see the current results in the > relevant Github issue[1]. Essentially, we're still trying to get > version bounds updated so that a build can commence. Great! Is there a way to view the jenkins build results somewhere? For some reason I miss a proper homepage of stackage with links to all the various resources (but maybe I’m blind). Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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
[Haskell-cafe] Any Haskell events in Madrid next week?
Hi, I’ll be visiting Madrid next week (research visit) and I’m wondering if there are any Haskell or FP Group meeting or other events that might be interesting? I could possibly contribute a talk. (Both preferably in English.) Wednesday or Thursday evening might would most convenient. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] Tutorial on JS with Haskell: Fay or GHCJS?
Hi, Am Mittwoch, den 04.09.2013, 14:46 +0200 schrieb Adam Bergmark: > You might be interested in these two comment threads (and maybe the > rest of the comments as well): > http://www.reddit.com/r/haskell/comments/1ldqav/thoughts_on_uhc_vs_haste_vs_fay/cbyrhwz > http://www.reddit.com/r/haskell/comments/1htqi2/announce_haste_the_haskell_to_js_compiler_is_now/cay79g9?context=1 and another data point: http://www.joachim-breitner.de/blog/archives/602-Running-Circle-Packing-in-the-Browser-using-Haste.html Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] inv f g = f . g . f
Hi, Am Samstag, den 17.08.2013, 11:11 +0200 schrieb Christopher Done: > inv reverse (take 10) if you want that fast and lazy, check out http://www.joachim-breitner.de/blog/archives/600-On-taking-the-last-n-elements-of-a-list.html Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] Renumbered mailing list posts
Hi, Am Montag, den 12.08.2013, 14:52 +0200 schrieb Sven Panne: > 2013/8/12 Joachim Breitner : > > happens with mailman/pipermail occasionally. > > o_O That's news to me... Why/how does this happen? This sounds like a > serious bug to me, the URLs should really, really be stable to be of > any use. I only observed it, never debugged it, but I think a common case is if mailing lists posts are removed (e.g. because they are spam) and then the archive is re-created. > > It is more reliable to link to message ids, e.g. via gmame: [...] > > That hint doesn't really help to unbreak the Haskell wiki, the various > trac instances, my mailbox, etc. :-( Unfortunately true. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] Renumbered mailing list posts
Hi, Am Samstag, den 10.08.2013, 10:49 +0200 schrieb Henning Thielemann: > Recently I found that links from Google search results to archive > Haskell-Cafe messages are invalid. The messages are still there, but got > a different number. E.g. the search result says: >http://www.haskell.org/pipermail/haskell-cafe/2011-February/089455.html > > But the message is at >http://www.haskell.org/pipermail/haskell-cafe/2011-February/088146.html > > Also links from Haskell-Wiki articles to the Haskell-Cafe archive are > invalid now. This is very very very bad, since I used tons of such URLs > in Wiki articles and it is very hard to find the message I referred to, > if the URL does not work anymore. happens with mailman/pipermail occasionally. It is more reliable to link to message ids, e.g. via gmame: http://mid.gmane.org/4D779F63.9050506%40irit.fr (random example from my browser history) lists.debian.org also allows links with message ids: http://lists.debian.org/20120408083121.GB9680@flashgordon (another random example) but I don’t know if this is an easy to enable standard mailman feature. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] How can I use ghci more wisely?
Hi, Am Mittwoch, den 24.07.2013, 01:41 -0700 schrieb Michael Sloan: > Another non-answer is to take a look at using vaccum[0] and > vaccum-graphviz[1] together, to get an idea of the heap structure of > unforced values. I've made a gist demonstrating how to use these to > visualize the heap without forcing values[2]. This doesn't show any > concrete values (as that would require some serious voodoo), but does > show how the heap changes due to thunks being forced. if you want to stay in GHCi with it you can use ghc-heapview instead of vacuum: Prelude> :script /home/jojo/.cabal/share/ghc-heap-view-0.5.1/ghci Prelude> let x = [1..] Prelude> take 20 x [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20] Prelude> :printHeap x Prelude> :printHeap x let x1 = S# 20 in S# 1 : S# 2 : S# 3 : S# 4 : S# 5 : S# 6 : S# 7 : S# 8 : S# 9 : S# 10 : S# 11 : S# 12 : S# 13 : S# 14 : S# 15 : S# 16 : S# 17 : S# 18 : S# 19 : x1 : _thunk x1 (S# 1) For this kind of infinite values you don’t see its finite, but for others you do: Prelude> let inf = let x = "ha" ++ x in x Prelude> take 20 inf "hahahahahahahahahaha" Prelude> :printHeap inf let x1 = C# 'h' : C# 'a' : x1 in x1 Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] Generating Haskell Code out of Haskell AST (GHC API)
Hi, Am Freitag, den 19.07.2013, 11:19 +0200 schrieb John Blackbox: > The question about generating the code was only to have a "debugging > tool" - to see if the generated AST is good - I wanted to generate the > Haskell code only to check if its correct, but normally I would not do > it, because it makes no sense to generate AST -> code -> AST (by GHC) > again etc :) it does make sense: ASCII (or today, Unicode text) is a much easier and more stable interface than some ADT of a library. There is a good reason why GHC generates llvm files and calls clang on them, instead of generating the LLVM AST with some libllvm. Same for all the pre-processors (happy, alex) – they all go through the serialized form. It will be easier to plug components together, to inspect the intermediate Haskell code or even modify it. Of course if you need features not available via the command line, using the API might be required. But for your own sake I suggest you avoid it if possible. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] question automatic indentation (and so on)
Hi, Am Montag, den 01.07.2013, 07:59 -0400 schrieb Richard Cobbe: > How does the indentation tool know if (a b c) is supposed to be the next > item in the do block, or merely a continuation of the previous application > of f? I would still expect the developer to write correctly intended Haskell, so the the tool would have to employ a Haskell parser to get an AST (with extra information on where comments were – probably the trickiest part) and then pretty-prints it. If it were not for comments, using haskell-src-exts would already provide a first approximation to the problem, as shown in this script: https://github.com/djv/small/blob/master/tidy.hs Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] question automatic indentation (and so on)
Hi, on a related note: At HaL8 I was wondering how well Haskell would be suited for a workflow similar to what the go programmers do: Do not worry about code layout, but let the computer handle it! For more rationale and examples see http://golang.org/doc/effective_go.html#formatting While everyone has his own style and preferences, as soon as multiple programmers work on the same code, a consistently enforced formatting would probably help here a lot. Also, I would be happy to give up some bikeshedding^Wformatting freedom for not having to worry about this aspect. I found https://github.com/jaspervdj/stylish-haskell/ (found via http://stackoverflow.com/q/6870148/946226) which formats just some very few aspects of Haskell. Does anyone have a more complete solution? Or is interested in creating one? Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Promoting Haskell via Youtube movies
Hi, Daniel Silverstone has a 10-episode video-cast on Haskell at http://www.youtube.com/playlist?list=PL_xuff3BkASMOzBr0hKVKLuSnU4UIinKx and 5 Project Euler solution at http://www.youtube.com/playlist?list=PL_xuff3BkASMwjdTdsqWn5j4VcLGG5jem Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] Testing invasive proposals with Hackager
Hi, Am Donnerstag, den 13.06.2013, 09:59 +0800 schrieb Niklas Hambüchen: > In many discussions we make guesses about how much code proposals like > Functor => Monad would break. > > You can use https://github.com/dterei/Hackager to build all of Hackage > (preferably in a VM). > > Of course many packages have external dependencies, so I'd like to share > the following list of packages to save you some time. Great tool. Does someone have the resources to run it regularly (i.e. daily), dump the results and the diff-to-previous run somewhere and link the status (currently building/not building) on the hackage package? More CI-like data and testing is always good! How much overlap is there between this tool and stackage? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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] ANNOUNCE: new bridge! (prelude-prime)
Hi, Am Donnerstag, den 23.05.2013, 11:52 +0200 schrieb Bas van Dijk: > On 23 May 2013 11:26, Joachim Breitner wrote: > > So you can get what you want by not > > depending on base, but rather have prelude-prime re-export all modules > > from base plus its own Preldue. > > How would you re-export all base's modules from the prelude-prime > package? I didn't know this was already possible. manually... you create a .hs file for every module in base, which imports the module in base (using a package-qualified import), gives it a qualified name and puts that name in the export list. 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] ANNOUNCE: new bridge! (prelude-prime)
HI, Am Donnerstag, den 23.05.2013, 12:38 +0400 schrieb Anton Kholomiov: > I wish it was possible to use an extension > > CustomPrelude = Prelude.Prime > > In the cabal file as far as I know, GHC simply issues an implicit import Prelude without package qualifiers. So you can get what you want by not depending on base, but rather have prelude-prime re-export all modules from base plus its own Preldue. A more modular variant would be to have a package "preludeless-base" which re-exports all modules from base but the prelude. Then you can select which prelude you want simply by depending on preludeless-base (instead of base) plus a package (say prelude-prime) which exports a module named Prelude. If prelude-prime itself wants to use base, it can still use package-qualified imports. Or it could itself be based on preludeless-base. 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] Monad Transformer Space Leak
Hi, Am Montag, den 22.04.2013, 16:44 -0400 schrieb Clark Gaebel: > More interestingly, the problem goes away if I enable profiling. > That's kind of worrisome. this part sounds similar than the recently discussed problem with the ackermann function (http://hackage.haskell.org/trac/ghc/ticket/7850) – maybe your code is only allocating stacks and nothing else? In that case you can try with GHC HEAD and see if the problem is fixed. 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] Prolog-style patterns
Hi, I believe one problem with non-linear patterns would be that the compiler has to figure out what notion of equality you want here. An obvious choice is (==), but the Eq instances might not do what you want. Using pattern guards or view patterns explicates this choice. Also, without an explicit call to == the cost model of such a function definition might be harder to see; an innocent looking change to the patterns of a function could cause a considerable amount of extra work if == is expensive. Greetings, Joachim Am Montag, den 08.04.2013, 07:06 -0700 schrieb Conal Elliott: > Hi Jan, > > What you're suggesting is called "non-linear patterns", and it's a > perfectly sensible, well-defined feature in a language with > pattern-matching. As you point out, non-linearity allows for more > direct & succinct programming. I've often wished for this feature when > writing optimizations on data types, especially for syntactic types > (languages). > > As Ivan mentioned, there is some danger that people may accidentally a > non-linear pattern accidentally, and perhaps the early Haskell > designers chose the linearity restriction out of this worry. The > importance of such dangers is a subjective call, and certainly not one > carried out consistently in Haskell. Consider, for instance, the > choice that let & where bindings are recursive by default in Haskell, > unlike ML and Lisp. I like this choice, but I can understand > objections that it leads to accidental recursions, especially for > non-functions. > > > > -- Conal > > > > > On Mon, Apr 8, 2013 at 6:11 AM, Jan Stolarek > wrote: > > You can achieve something similar with the ViewPatterns > language > > extension. > > > > > member _ [] = False > > member x (((x ==) -> True) : _) = True > > member x (_ : xs) = member x xs > > Hi Tillmann, > > there are a couple of ways to achieve this in Haskell, for > example using guards: > > member :: Eq a => a -> [a] -> Bool > member _ [] = False > > member y (x:_) | x == y = True > member y (_:xs) = member y xs > > The goal of my proposal is to provide a concise syntax, > whereas ViewPatterns are very verbose and > guards are slightly verbose. I want something simple and > something that is very intuitive if > you've programmed in Prolog :) > > Janek > > ___ > 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 -- 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] ANNOUNCE: hydra-print-0.1.0.0
Hi, Am Samstag, den 06.04.2013, 03:09 -0400 schrieb Ryan Newton: > This is an NCurses front end for visualizing a dynamic collection of > text streams (e.g. as produced by "make -j" or "cabal -j"). It just > splits the window when more streams appear. > > >http://hackage.haskell.org/package/hydra-print > >http://parfunk.blogspot.com/2013/04/hydra-print.html > > > Right now I'm using it for the monad-par benchmark script, but I hope > to provide a cabal patch soon. just FYI, there is a related library, http://hackage.haskell.org/package/concurrentoutput, that will not split the view but interleave the lines of each thread as they finish, but append additional data before the newline (e.g. ".") to the right line. 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] duplicate type signatures
Hi, Am Donnerstag, den 28.03.2013, 07:40 +0100 schrieb Heinrich Hördegen: > Is there a deeper sens or is it just a little bit inconsistent? looks like the latter to me. The report states Moreover, it is invalid to give more than one type signature for one variable, even if the signatures are identical. so I guess you can file a bug report. 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] Extracting exposed modules from an installed library
Hi, Am Mittwoch, den 20.03.2013, 00:34 +0100 schrieb Corentin Dupont: > Hi Cafe! > I'm looking for how to extract the exposed modules (as a list of > strings) from an installed library, giving the library name. > I can see some structures in Cabal (InstalledPackageInfo) and some > functions in ghc-pkg.hs in GHC, but nothing readily useable... $ ghc-pkg field base exposed-modules exposed-modules: Foreign.Concurrent GHC.Arr GHC.Base GHC.Char GHC.Conc GHC.Conc.IO GHC.Conc.Signal GHC.Conc.Sync GHC.ConsoleHandler GHC.Constants GHC.Desugar GHC.Enum GHC.Environment GHC.Err GHC.Exception GHC.Exts GHC.Fingerprint GHC.Fingerprint.Type GHC.Float GHC.Float.ConversionUtils GHC.Float.RealFracMethods GHC.Foreign GHC.ForeignPtr GHC.Generics GHC.GHCi GHC.Handle GHC.IO GHC.IO.Buffer GHC.IO.BufferedIO GHC.IO.Device GHC.IO.Encoding GHC.IO.Encoding.CodePage GHC.IO.Encoding.Failure GHC.IO.Encoding.Iconv GHC.IO.Encoding.Latin1 GHC.IO.Encoding.Types GHC.IO.Encoding.UTF16 GHC.IO.Encoding.UTF32 GHC.IO.Encoding.UTF8 GHC.IO.Exception GHC.IO.FD GHC.IO.Handle GHC.IO.Handle.FD GHC.IO.Handle.Internals GHC.IO.Handle.Text GHC.IO.Handle.Types GHC.IO.IOMode GHC.IOArray GHC.IOBase GHC.IORef GHC.IP GHC.Int GHC.List GHC.MVar GHC.Num GHC.PArr GHC.Pack GHC.Ptr GHC.Read GHC.Real GHC.ST GHC.Stack GHC.Stats GHC.Show GHC.Stable GHC.Storable GHC.STRef GHC.TypeLits GHC.TopHandler GHC.Unicode GHC.Weak GHC.Word System.Timeout GHC.Event Control.Applicative Control.Arrow Control.Category Control.Concurrent Control.Concurrent.Chan Control.Concurrent.MVar Control.Concurrent.QSem Control.Concurrent.QSemN Control.Concurrent.SampleVar Control.Exception Control.Exception.Base Control.Monad Control.Monad.Fix Control.Monad.Instances Control.Monad.ST Control.Monad.ST.Safe Control.Monad.ST.Unsafe Control.Monad.ST.Lazy Control.Monad.ST.Lazy.Safe Control.Monad.ST.Lazy.Unsafe Control.Monad.ST.Strict Control.Monad.Zip Data.Bits Data.Bool Data.Char Data.Complex Data.Dynamic Data.Either Data.Eq Data.Data Data.Fixed Data.Foldable Data.Function Data.Functor Data.HashTable Data.IORef Data.Int Data.Ix Data.List Data.Maybe Data.Monoid Data.Ord Data.Ratio Data.STRef Data.STRef.Lazy Data.STRef.Strict Data.String Data.Traversable Data.Tuple Data.Typeable Data.Typeable.Internal Data.Unique Data.Version Data.Word Debug.Trace Foreign Foreign.C Foreign.C.Error Foreign.C.String Foreign.C.Types Foreign.ForeignPtr Foreign.ForeignPtr.Safe Foreign.ForeignPtr.Unsafe Foreign.Marshal Foreign.Marshal.Alloc Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool Foreign.Marshal.Safe Foreign.Marshal.Utils Foreign.Marshal.Unsafe Foreign.Ptr Foreign.Safe Foreign.StablePtr Foreign.Storable Numeric Prelude System.Console.GetOpt System.CPUTime System.Environment System.Exit System.IO System.IO.Error System.IO.Unsafe System.Info System.Mem System.Mem.StableName System.Mem.Weak System.Posix.Internals System.Posix.Types Text.ParserCombinators.ReadP Text.ParserCombinators.ReadPrec Text.Printf Text.Read Text.Read.Lex Text.Show Text.Show.Functions Unsafe.Coerce 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] [jhc] ANNOUNCE: Ajhc 0.8.0.2 Release
Hi, Am Samstag, den 16.03.2013, 05:53 -0700 schrieb John Meacham: > On Sat, Mar 16, 2013 at 5:28 AM, Kiwamu Okabe wrote: > > We are happy to announce Ajhc 0.8.0.2. > >I have merged your changes back into the main jhc tree. Thanks! > John Great. Would it be possible for you two to agree on a mode that allows Kiwamu to develop in his pace, but still avoid having a proper fork of jhc pushed to distros and users? Something like: Kiwamu hacks away happily on the ajhc repo and people interested in the very latest state can pull from there, but ajhc releases get (if there are no technical issues) merged into jhc, and jhc is the version that regular users should use (and distributions should package). Your part-time fork-avoider, 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] Open-source projects for beginning Haskell students?
Hi, Am Montag, den 11.03.2013, 11:48 -0400 schrieb Brent Yorgey: > If you have any such projects, I'd love to hear about it! Just send > me a paragraph or so describing your project and explaining what > task(s) you could use help with --- something that I could put on the > course website for students to look at. arbtt, the Automatic Rule-Based Time-Tracker could possibly be an sufficiently interesting application with lots of corners for improvement. Someone could for example try to generate graphs from it, or add other statistical analyses... but I guess you are interested in a better defined task? Some pointers: http://hackage.haskell.org/package/arbtt http://darcs.nomeata.de/arbtt/doc/users_guide/ https://www.joachim-breitner.de/blog/archives/336-The-Automatic-Rule-Based-Time-Tracker.html https://lists.nomeata.de/mailman/listinfo/arbtt 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] Conflicting bindings legal?!
Hi, Am Dienstag, den 26.02.2013, 10:25 +0100 schrieb Andreas Abel: > To your amusement, I found the following in the Agda source: > > abstractToConcreteCtx :: ToConcrete a c => Precedence -> a -> TCM c > abstractToConcreteCtx ctx x = do >scope <- getScope >let scope' = scope { scopePrecedence = ctx } >return $ abstractToConcrete (makeEnv scope') x >where > scope = (currentScope defaultEnv) { scopePrecedence = ctx } > > I am surprised this is a legal form of shadowing. To understand which > definition of 'scope' shadows the other, I have to consult the formal > definition of Haskell. in more imperative looking Haskell code, I find it useful to shadow a previous binding by a new "foo <-" binding... People who do not like that should use -Wall (or a more specific flag like -fwarn-name-shadowing). 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] RFC: rewrite-with-location proposal
Hi, Am Montag, den 25.02.2013, 10:13 +0100 schrieb Simon Hengel: > On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote: > > Hi, > > > > Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman: > > > Quite a while back, Simon Hengel and I put together a proposal[1] for > > > a new feature in GHC. The basic idea is pretty simple: provide a new > > > pragma that could be used like so: > > > > > > error :: String -> a > > > errorLoc :: IO Location -> String -> a > > > {-# REWRITE_WITH_LOCATION error errorLoc #-} > > > > in light of attempts to split base into a pure part (without IO) and > > another part, I wonder if the IO wrapping is really necessary. > > > > Can you elaborate the reason why a simple "Location ->" is not enough? > > The IO helps with reasoning. Without it you could write code that does > something different depending on the call site. Here is an example: > > > someBogusThingy :: Int > someBogusThingy = .. > > someBogusThingyLoc :: Location -> Int > someBogusThingyLoc loc > | (even . getLine) loc = 23 > | otherwise= someBogusThingyLoc > > {-# REWRITE_WITH_LOCATION someBogusThingy someBogusThingyLoc #-} > > Now someBogusThingy behaves different depending on whether the call site > is on an even or uneven line number. Admittedly, the example is > contrived, but I hope it illustrates the issue. ok, I mentally applied REWRITE_WITH_LOCATION before wondering about reasoning about the code. But you are right that it would be nice if the rewrite rule would be valid as well. I’m not firmly commited either way. 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] RFC: rewrite-with-location proposal
Hi, Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman: > Quite a while back, Simon Hengel and I put together a proposal[1] for > a new feature in GHC. The basic idea is pretty simple: provide a new > pragma that could be used like so: > > error :: String -> a > errorLoc :: IO Location -> String -> a > {-# REWRITE_WITH_LOCATION error errorLoc #-} in light of attempts to split base into a pure part (without IO) and another part, I wonder if the IO wrapping is really necessary. Can you elaborate the reason why a simple "Location ->" is not enough? Thanks, 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] Thunks and GHC pessimisation
Hi, Am Sonntag, den 24.02.2013, 18:41 + schrieb Tom Ellis: > On Sun, Feb 24, 2013 at 07:12:24PM +0100, Joachim Breitner wrote: > > You should try: > > > > > million :: () -> Int > > > million _ = 10 ^ (6 :: Int) > > > > > > many :: () -> [Int] > > > many x = [1..million x] > > Thanks Joachim, but that doesn't work either. oh, strange, I though I had added Maybe you will need {-# NOINLINE million #-} as well. to the mailing. Must have skipped or accidentally removed it... anyways, with that pragma it works. 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] Thunks and GHC pessimisation
Hi, I believe, without checking, that Am Sonntag, den 24.02.2013, 17:49 + schrieb Tom Ellis: > many :: () -> [Int] > many () = [1..million] is indeed called many times. The problem is that [1..million] is not dependent on the parameter, so GHC will float it out to a top level declaration, and hence share it between the multiple calls to many. You should try: > million :: () -> Int > million _ = 10 ^ (6 :: Int) > > many :: () -> [Int] > many x = [1..million x] Greetings, Joachim (Maybe I should continue to work on http://arxiv.org/abs/1106.3478 and related ideas, like annotating thunks in the code as unshareable... or does this mostly occur in small example programs like this?) -- 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] Why isn't "Program Derivation" a first class citizen?
Hi, Am Dienstag, den 12.02.2013, 17:47 -0500 schrieb Nehal Patel: > To me, it seems that something like this should be possible -- am i > being naive? does it already exist? have people tried and given up? > is it just around the corner? can you help me make sense of all of > this? a related project is HOLCF-Prelude, by Christian Sternagel and others. What they do is to reimplement the Haskell prelude as HOLCF data types and functions in the theorem prover Isabelle. This allows you to write functional code as HOLCF functions, prove properties of them (using functions from the prelude and a library of lemmas about them) and, as long as the definitions are the same as in your Haskell code, be happy about it. It is not a silver bullet, and not exactly what you need. For example, you still have to manually translate between the HOLCF definition and the Haskell code. Also, Haskell is not covered completely. Exceptions, for example, are completely ignored. But nevertheless it is useful: For example, we have started to verify some of the transformations suggested by hlint, proved quite a few of them and even found (very few) wrong ones. And what wren said about the complexity of machine verified proofs is very true. Especially when you also cover non-termination and lazyness (as we do) and want to prove properties involving type classes with a few assumptions about them as possible, and suddenly have the problem that (==) can do arbitrary stuff. You can find the code at https://sourceforge.net/p/holcf-prelude/ Comments and contributions are welcome! 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] GHCi (7.4.2) is working on ARM
Hi, that’s no surprise: “ARM support in the RTS linker (#5839) has been implemented.” (http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/release-7-4-2.html) Greetings, Joachim Am Mittwoch, den 06.02.2013, 18:21 -0500 schrieb dude: > I have also validated ghc 7.4.1 on the Ubuntu Precise distro booted on > a BeagleXM. > > There's no ghci included. > > --dude > > On 02/06/2013 08:15 AM, kenny lu wrote: > > > I've got a Cubieboard a few weeks back. I started it off with Linaro > > (Ubuntu) 12.06. > > Today I started to upgrade the OS to 12.11, which surprisingly came > > with ghc 7.4.2. > > > > > > And ghci magically works too. > > > > > > Here are the links > > > > > > http://www.cubieboard.org > > > > > > sudo apt-get install update-manager-core > > sudo apt-get update > > sudo apt-get upgrade > > sudo do-release-upgrade > > > > > > Regards, > > Kenny > > > > > > > > > > > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- > dude > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- 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] Ticking time bomb
Hi, Am Donnerstag, den 31.01.2013, 09:42 +0100 schrieb Ertugrul Söylemez: > And that may even be more harmful, because an insecure system with a > false sense of security is worse than an insecure system alone. > > Let's do it properly. but don’t overengineer it either. Simply adding to hackage the possibility to store a .asc file next to the tar.gz file that contains the cryptographic signature would be a great start, and allow us to develop a WoT model later on. (I try to resist from wondering whether this could go into hackage1 or only hackage2, and in the latter case, whether that means that we actually have the time to overengineer the system.) In fact, a lot would already be gained by a simple „warn if foo-2.0 is signed with a different key than the version of foo already installed“ on cabal-install and people having a closer look at uploads from different people. Not much infrastructure needed there. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Hi, Am Mittwoch, den 30.01.2013, 15:07 -0800 schrieb Edward Z. Yang: > Nevertheless, I believe we are in violent agreement that > cryptographically signed Hackage packages should happen as soon as > possible! I don’t think we need hackage support here. Just add a "MD5-Sum:" field to the .cabal file specifying the checksum of the resulting tarball, and everyone can just check it after downloading. At least with MD5 and modern computers, this should be possible by now or soon. (SCNR) 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] Ticking time bomb
Hi, Am Mittwoch, den 30.01.2013, 14:43 -0800 schrieb Edward Z. Yang: > Excerpts from Joachim Breitner's message of Wed Jan 30 12:59:48 -0800 2013: > > another reason why Cabal is no package manager¹. > > Based on the linked post, it seems that you are arguing that cabal-install is > not a package manager, and thus it is not necessary for it to duplicate > the work that real package managers e.g. Debian or Ubuntu put into > vetting, signing and releasing software. (Though I am not sure, so please > correct me if I am wrong.) I’m not against cryptographically signed packages on hackage. In fact, I would whole-heatedly appreciate it, as it would make my work as a package maintainer easier. I was taking the opportunity to point out an advantage of established package management systems, to shamelessly advertise my work there, as not everyone sees distro-packaged libraries as a useful thing. 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] Ticking time bomb
Hi, Am Mittwoch, den 30.01.2013, 11:27 -0800 schrieb Edward Z. Yang: > https://status.heroku.com/incidents/489 > > Unsigned Hackage packages are a ticking time bomb. another reason why Cabal is no package manager¹. (Ok, I admit that I don’t review every line of diff between the Haskell packages I uploads. But thanks to http://hdiff.luite.com/ I at least glance over them most of the time – a hurdle that malicious code would have to take. And once a package has entered a distribution like Debian (which it only can with a valid cryptographic signatures), checksums and signatures are used in many places to (mostly) guarantee that the package reaches the user unmodified.) Greetings, Joachim ¹ http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ -- 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] [ANN] tls-extra 0.6.1 - security update, please upgrade.
Hi, Am Sonntag, den 20.01.2013, 17:21 +0100 schrieb Vincent Hanquez: > On Sun, Jan 20, 2013 at 11:01:22AM +0100, Joachim Breitner wrote: > > Debian ships tls-extras 0.4.6 in what will become wheezy, and due to the > > freeze upgrading to a new major upstream release is not acceptable. > > > Would it be possible for you to create a 0.4.6.1 with this bugfix > > included? > > (wow, the tls packages stack are quite obsolete) > > Apart from the fact that it took me a while to rebase to this version, > I just uploaded 0.4.6.1. it compiles but got minimal testing. thanks, uploaded to Debian and on its way into the wheezy suite. 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] [ANN] tls-extra 0.6.1 - security update, please upgrade.
Hi, Am Sonntag, den 20.01.2013, 06:50 +0100 schrieb Vincent Hanquez: > this is a security advisory for tls-extra < 0.6.1 which are all vulnerable to > bad > certificate validation. > > Some part of the certificate validation procedure were missing (relying on the > work-in-progress x509 v3 extensions), and because of this anyone with a > correct > end-entity certificate can issue certificate for any arbitrary domain, i.e. > acting as a CA. > > This problem has been fixed in tls-extra 0.6.1, and I advise everyone to > upgrade as > soon as possible. > > Despite a very serious flaw in the certificate validation, I'm happy that the > code is seeing some audits, and would want to thanks Ertugrul Söylemez for the > findings [1]. Debian ships tls-extras 0.4.6 in what will become wheezy, and due to the freeze upgrading to a new major upstream release is not acceptable. Would it be possible for you to create a 0.4.6.1 with this bugfix included? Thanks a lot, 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
[Haskell-cafe] Inferring rewrite rules for higher order functions
Dear list, with rewrite rules I can tell the compiler to replace "map id" by "id", but I still have to write that rule by hand. Does anyone of you know about research into inferring such a rewrite rule automatically? I could imagine that for a function of type "f :: some -> args -> T a -> T b" and not-too-bad type constructors T it might be possible under what conditions on "some" and "args" infer when "f arg1 arg2 = id" holds, and if the conditions are fulfilled by functions like "id", generate a rewrite rule "f id id = id" automatically. Thanks, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generating random arguments for a function
Hi, Am Sonntag, den 13.01.2013, 07:34 -0800 schrieb Bob Ippolito: > I think it's more complicated because he doesn't know what the return > type or arity of the function is. In QuickCheck they know the return > type of a property is Bool. In this case, we only know that the return > type is an instance of Show. I don't think that's enough to simply > implement this. I posted on SE an answer that tries to do it with OverlappingInstances: http://stackoverflow.com/questions/14294802/evaluating-function-at-random-arguments-using-quickcheck/14295179#14295179 Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
Hi, Am Freitag, den 11.01.2013, 23:55 +0100 schrieb Vincent Hanquez: > I've recently released crypto-pubkey [1][2], which provide a comprehensive > solution for public key cryptography. > > Most known RSA modes (PKCS15, OAEP, PSS) are supported, and there's also DSA > and ElGamal signature support. Most of the code originally lived in > cryptocipher, > but have now been made better and safer, and support more modes. > > I've spend some good chunk of time adding KATs and tests, documentation, and > making sure the performance was ahead of other haskell implementations. nice. But in the interest of possible users: Is there a reason why this code could not live in cryptocipher? Do we need multiple implementations of the cyphers, and expect our users to find out for themselves why to use one or the other? Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
Hi, Am Mittwoch, den 09.01.2013, 15:11 +0100 schrieb Erik Hesselink: > We finally solved the problems by completely moving > to strict map operations, strict MVar/TVar operations, and strict data > types. do you mean strict by policy (i.e. before storing something in a [MT]Var, you ensure it is evaluated) or by construction (by `seq` or `deepseq`’ing everything before it is stored)? In the latter case: Seq or deeqseq? Again in the latter case: Do you worry about the performance of repeatedly deepseq’ing an already deepseq’ed and possibly large value? You are not the first user of Haskell who ends up with that approach to lazy evaluation. I’m not sure what that means for Haskell, though. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
Hi Erik, Am Mittwoch, den 09.01.2013, 14:23 +0100 schrieb Erik Hesselink: > We've also used this approach to debug space-leaks, and would have > loved such a tool. We used deepseq, and compared the heap profiles. We > finally found the leaks this way, and fixed them using strictness > annotations. Finally, we verified by running deepseq again at top > level and observing that it didn't change anything anymore. same question to you: Would you have a suitable test case that can be used to test and demonstrate the usefulness of such tools? Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
Hi, Am Dienstag, den 08.01.2013, 13:01 -0800 schrieb Evan Laforge: > > surprisingly, deepseq is not used as much as I thought. > > http://packdeps.haskellers.com/reverse/deepseq lists a lot of packages, > > but (after grepping through some of the code) most just define NFData > > instances and/or use it in tests, but rarely in the „real“ code. For > > some reason I expected it to be in more widespread use. > > I've been using deepseq quite a bit lately, but for the purpose of > debugging space leaks. If, when I deepseq a big structure, the space > leak goes away, I can then apply it to some subset. After much > trial-and-error I can find something which is insufficiently strict. > Ideally I can then strictify that one thing and stop using the > deepseq. I wish there was a more efficient way to do this. this is also a possible application of my approach, by providing a „I want this data structure to be fully evaluated now, please tell me how it currently looks, i.e. where in the data structure still thunks lie hidden.“ Do you have a nice, striking example where using your approach (using deepseq and comparing efficiency) you could make a difference, and where a tool as described above would make the analysis much easier? Thanks, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example programs with ample use of deepseq?
Hi, Am Montag, den 07.01.2013, 13:06 +0100 schrieb Joachim Breitner: > I’m wondering if the use of deepseq to avoid unwanted lazyness might be > a too large hammer in some use cases. Therefore, I’m looking for real > world programs with ample use of deepseq, and ideally easy ways to test > performance (so preferably no GUI applications). surprisingly, deepseq is not used as much as I thought. http://packdeps.haskellers.com/reverse/deepseq lists a lot of packages, but (after grepping through some of the code) most just define NFData instances and/or use it in tests, but rarely in the „real“ code. For some reason I expected it to be in more widespread use. But therefore I am even more interested in non-hackaged applications that I can be allowed to stud – in return I might be able to tell you way to speed up your application. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Example programs with ample use of deepseq?
Dear Haskellers, I’m wondering if the use of deepseq to avoid unwanted lazyness might be a too large hammer in some use cases. Therefore, I’m looking for real world programs with ample use of deepseq, and ideally easy ways to test performance (so preferably no GUI applications). I’ll try to find out, by runtime observerations, which of the calls ot deepseq could be replaced by id, seq, or „shallow seqs“ that, for example, calls seq on the elements of a tuple. Thanks, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-heap-view now with recursive pretty-printing
Hi, Am Dienstag, den 25.12.2012, 16:58 +0100 schrieb Thomas Schilling: > On 21 December 2012 11:16, Joachim Breitner wrote: > > Prelude> :script /home/jojo/.cabal/share/ghc-heap-view-0.4.0.0/ghci > > Prelude> let x = [1..10] > > Prelude> x > > [1,2,3,4,5,6,7,8,9,10] > > Prelude> :printHeap x > > _bh [S# 1,S# 2,S# 3,S# 4,S# 5,S# 6,S# 7,S# 8,S# 9,S# 10] > > > > Note that the tools shows us that the list is a list of S# constructors, > > and also that it is still hidden behind a blackhole. After running > > System.Mem.performGC, this would disappear. > > Why do you call it a "blackhole"? I assume you mean a thunk that has > been evaluated and updated with its value. The commonly used term for > this is "indirection". A blackhole is used to detect when a thunk's > value depends on itself (e.g., in "let x = id x in ..." the thunk for > x may get turned into a black hole). I don’t call it a blackhole, GHC does :-). At least it is a closure of type BLACKHOLE http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/ClosureTypes.h#L61 I assume this is due to lazy blackholing or something, although it still occurs with "ghci -fno-eager-blackholing"... strange. > It's a minor thing, but I think it's a good idea to stick to existing > terminology. Otherwise, it looks like a useful tool. Thanks! > Eventually, we > probably want an interactive graph where we can click a node to > evaluate it (or to show/hide children nodes). Looks like I am not as good at advertising my (or my student’s) projects as much as I thought I am: http://felsin9.de/nnis/ghc-vis/ Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Stackage mailing list
Dear Michael, I’m wondering if I missed something, but is there a mailing list for stackage? Or has one of the standard lists (-cafe, libraries) been designated for questions about stackage? What I want to know is if you plan to provide a website for stackage soon where the list of included packages and their dependencies, including the tested and approved version numbers can be seen. I’d like to take that and integrate it on http://people.debian.org/~nomeata/platform.html and http://people.debian.org/~nomeata/hackagevsdebian.html Also, once you do that, it should be possible to add Stackage to the list of Distributions listed on hackage, so that on hackage one already sees the package’s stackage status and whether it lags behind there. The integrations is rather simple, just provide a file with that format: http://people.debian.org/~nomeata/cabalDebianMap.txt and bug the hackage maintainers to add it. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ghc-heap-view now with recursive pretty-printing
Hi, I get the impression that blogs and planet.haskell.org are the best way to disseminate information about new tools any more. Maybe a part of the earlier importance has been taken over by GooglePlus, but not all, leaving both blogs and GooglePlus less useful individually? Anyways, I’d like to tell you about a feature of ghc-heap-view that I have blogged about¹, namely the possibility to inspect heap values recursively in GHCi or in your programs, including thunks, the references between them and sharing: Prelude> :script /home/jojo/.cabal/share/ghc-heap-view-0.4.0.0/ghci Prelude> let x = [1..10] Prelude> x [1,2,3,4,5,6,7,8,9,10] Prelude> :printHeap x _bh [S# 1,S# 2,S# 3,S# 4,S# 5,S# 6,S# 7,S# 8,S# 9,S# 10] Note that the tools shows us that the list is a list of S# constructors, and also that it is still hidden behind a blackhole. After running System.Mem.performGC, this would disappear. Prelude> let x = Just (1 + 1) Prelude> :printHeap x Just _bco Prelude> x Just 2 Prelude> System.Mem.performGC Prelude> :printHeap x Just (S# 2) Here, we see how the calculation was deferred until forced by showing the value of x. The name _bco stands for a bytecode object as used by the interpreter. Getting useful information from them is a bit harder than for compiled thunks, so for more accurate results put the code in a Haskell source file, compile it and use the GHC.HeapView API to print the interesting parts. Prelude> let a = "hi" Prelude> let partial = (a ++) Prelude> partial "" "hi" Prelude> System.Mem.performGC Prelude> let x = (a, partial) Prelude> :printHeap x let x1 = "hi" in (x1,_fun x1) This demonstrates a partial application. The information which function is called there (++ in this case) is lost at runtime, but we still see that the second element of the tuple is a partial application of some value to the first element. Prelude> let s = "ho" Prelude> let x = cycle s Prelude> length (take 100 (show x)) 100 Prelude> System.Mem.performGC Prelude> :printHeap x let x0 = C# 'h' : C# 'o' : x0 in x0 Prelude> let y = map Data.Char.toUpper x Prelude> length (take 100 (show y)) 100 Prelude> :printHeap y C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : _bh (C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : ... : ...) The cyclic, tying-the-knot structure of cycle is very visible. But can also see how easily it is broken, in this case by mapping a function over the list. Prelude> let {x = 'H' : y ; y = 'o' : x } Prelude> length (show (take 10 x, take 10 y)) `seq` return () Prelude> System.Mem.performGC Prelude> :printHeap (x,y) let x1 = C# 'H' : x3 x3 = C# 'o' : x1 in (x1,x3) If you want to look at multiple variables at once, just pass a tuple to printHeap I hope you’ll find it useful, and I am happy to hear about other features that you might be interested in. Also, if you don’t know about it, a graphical and interactive variant of this is available as ghc-vis². Greetings, Joachim ¹ http://www.joachim-breitner.de/blog/archives/580-GHCi-integration-for-GHC.HeapView.html ² http://felsin9.de/nnis/ghc-vis/ -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle index completeness
Hi, Am Mittwoch, den 19.12.2012, 12:28 -0500 schrieb Radical: > I see that the comments are from years ago. Are there any ongoing > efforts to expand the default search set? if Michael Snoyman’s stackage will fly, I’d that would be a good candidate for a default set. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (L)GPL libraries & Haskell/GHC
Hi, Am Mittwoch, den 12.12.2012, 02:50 +0100 schrieb Jonathan Fischer Friberg: > On Wed, Dec 12, 2012 at 2:26 AM, Ramana Kumar > wrote: > Using the GPL (or a strong copyleft free license) strengthens > the free software community of which I thought the Haskell > community is a part (or at least intersects substantially). > > I don't think it strengthens the community. If someone wants to make a > change a library, > but not release the source, they cannot do that with GPL. this is not fully correct. Correct would be to say: „If someone wants to make a change a library and distribute the resulting programs without also sharing the source with the recipient, they cannot do that with GPL.” So it is fully acceptable under the GPL to change the library for your own use, without sharing your code with anyone else. If you create a web service based on the modified library, you do not have to share the code (unless it is AGPL, but that is a different license). Also, if you want to sell the resulting program, you do not have to publish the source publicly, as long as you offer the source to your customers. For LGPL, we can assume that all this holds; whether the additional relaxation that LGPL provides over GPL apply to Haskell libraries seems to be doubtful. I hope that clarifies the situation a bit, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Profiling slow multiplication of elements read from vector
Hi, Am Dienstag, den 11.12.2012, 15:25 +0100 schrieb Richard Janis Beckert: > I would be very happy for some input on this, because I am pretty new to > Haskell and I don't really know how to do proper profiling. by looking at the core (-ddump-simpl) I found a few issues. neighProd vs l i = foldl' (\acc x -> acc * (lukUp vs l i) ) 1 [i-2 ,i-1 ,i ,i+1 ,i+2] will, for every call to neighProd, create a list of boxed integers and fold over it. I expected this boxing and unboxing to matter, so I switched to: neighProd vs l i = lukUp vs l (i-2) * lukUp vs l (i-1) * lukUp vs l (i) * lukUp vs l (i+1) * lukUp vs l (i+2) This will just allocate five machine integers, fills them and then multiplies them. Surprisingly, I did not notice a speed up. Reading more code I noticed that GHC did not figure out that the parameter i to neighProd is always required, and hence it is passed in as a boxed Integer. Again, boxing and unboxing costs time. Here neighProd vs l !i = lukUp vs l (i-2) * lukUp vs l (i-1) * lukUp vs l (i) * lukUp vs l (i+1) * lukUp vs l (i+2) fares better. There are more problems which I am not sure how to get rid of. For example, every call to div in lukUp makes a check if l is zero _and_ the indexing does bounds checking – the compiler cannot infer that just because you div’ed by l the bounds are guaranteed to be good. Using V.unsafeIndex there gives another noticable speedup. But not every Bang Pattern that avoids boxing gives a noticable speedup. E.g. the Bang Pattern in lukUp :: V.Vector Int -> Int -> Int -> Int lukUp vs l i = let !i' = i `mod` l in V.unsafeIndex vs i' did, according to core, prevent some boxing, but did not speed up the program. Allocating Ints that are unused before the next GC are very cheap. You can save more time by not passing l around, the size of the vector is already present in vs and can cheaply be accessed by "V.length vs". You can prevent the five checks if the lenghts is zero by making that check yourself first – GHC detects that it is in the branch where there length is not 0 (and not -1) and optimize that out: neighProd vs (!i) = case V.length vs of 0 -> undefined -1 -> undefined _ -> lukUp vs (i-2) * lukUp vs (i-1) * lukUp vs (i) * lukUp vs (i+1) * lukUp vs (i+2) The speedup is low; maybe later phases of the compiler did that already. Oh, and you are creating a new byte array in every invocation of randVec. That is of course expensive. Using mutable arrays seems to be a more natural choice. Or is that really what you want to do? Judging from your code I would expect that you want to create a new array consisting only of values returned by neighProd; with the current code, when updating the second value you are including the _updated_ first entry in your product. Disclaimer: I am compiling GHC 7.6.1-rc1 while testing this, so my measurements might be unreliable. Best try it out yourself. Also, this blind-stab-optimization is /not/ best practice, I just enjoyed fiddling around. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers: Why do we need a core language?
Hi, Am Dienstag, den 20.11.2012, 06:54 -0500 schrieb c...@lavabit.com: > I know nothing about compilers and interpreters. I checked several > books, but none of them explained why we have to translate a > high-level language into a small (core) language. Is it impossible > (very hard) to directly translate high-level language into machine > code? I would expect that even if you were to implement a compiler for full Haskell itself, you would end up generating a core language. E.g, where clauses can be implemented using let. So after you have implemented let you are likely to not copy the code but rather transform your where clause into a let clause. And alas, you suddenly have introduced a core language (Haskell without where clauses). This way you will end up with a very reduced subset of Haskell. Then you might also notice that some features are similar to implement and you can merge the code if you add some feature to your language, making it a bit more expressive. Then your core language will be more than just a subset of Haskell. As you can see, you will have a hard time preventing yourself from introducing a core language. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Not exporting a class
Hi, dear package authors. If you define a useful class, please think twice before you do not export the methods, otherwise something like this will happen: Am Samstag, den 10.11.2012, 21:39 -0800 schrieb David Fox: > It looks like there is an export copy of the whole prettyprint system > in template-haskell. I could switch over to that. Oh, and another > one in uulib. And also in ansi-wl-pprint. I think I will switch to > this last one. > > On Sat, Nov 10, 2012 at 6:17 PM, David Fox wrote: > It may belong in Text.PrettyPrint. > > On Sat, Nov 10, 2012 at 6:16 PM, David Fox > wrote: > About as small as a package can get! Yeah, the Pretty > class is in haskell-src, but they don't export the > pretty method. I will drop them a line, but I sort of > assumed they had a reason for doing it that way > > > On Thu, Nov 8, 2012 at 2:02 PM, Joachim Breitner > wrote: > Hi David, > > your pretty-class package is pretty small. In > the interest of preventing > package proliferation: Have you talked to the > maintainers of pretty or > haskell-src-exts whether they’d include the > class in their code? Thanks, 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] more sharing in generated code
Hi, Am Montag, den 05.11.2012, 23:34 +0100 schrieb Peter Divianszky: > Good remark, this can be solved with weak pointers, although I don't > know how efficient they are. > > -- > The next version of the proposal > > Replace every record update > > r' = r { x = y } > > with > > r' = r { x = update (weak r) r' (x r) y) } > > in generated code if some sharing aware optimization flag is enabled. > > Auxilary functions: > > weak :: a -> Weak a > -- make a weak pointer which is not followed by GC > > update :: Weak r -> r -> x -> x > update r_old r_new x_old x_new = unsafePerformIO $ do > eval x_new > b <- x_old === x_new > when b (replace r_new r_old) > return x_new > > (===) :: a -> a -> IO Bool > -- pointer-equality for boxed values, equality for unboxed values > > replace :: a -> Weak a -> IO () > -- replace thunks in the heap > -- do nothing if the weak pointer was gone better, but still keeping too much stuff in memory: Namely x_old cannot be freed. For most uses it will be retained by the thunk x_new anyways, as you intend them to be updates of some kind, but it would probably still make sense to use a weak pointer for (x r). You can probably implement this using System.Mem.Weak, reallyUnsafePtrEquality and unsafePerformIO. Not sure how well it would perform, given the overhead of managing the Weak pointers. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more sharing in generated code
Hi, Am Samstag, den 03.11.2012, 11:26 +0100 schrieb Peter Divianszky: > > This can be implemented by replacing every record update > > > > r' = r { x = y } > > > > with > > > > r' = r { x = unsafePerformIO (cond-update r r' (x r) y) } > > > > where we keep the current record update mechanism and implement > > cond-update like > > > > cond-update :: r -> r -> x -> IO x > cond-update r_old r_new x_old x_new = do > eval x_new > b <- x_old === x_new > when b (replace r_new r_old) > return x_new > > > where (===) is pointer-equality and replace is a low-level function > > which replaces thunks in the heap. I think one problem with this approach is that now, until "x r'" is evaluated, you keep both r and r' alive. If r was _not_ retained by anything else, then you are now preventing the GC from freeing it and hence increasing the memory footprint. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] total Data.Map.! function
Hi Henning, Am Mittwoch, den 03.10.2012, 19:52 +0200 schrieb Henning Thielemann: > I wondered whether there is a brilliant typing technique that makes > Data.Map.! a total function. That is, is it possible to give (!) a type, > such that m!k expects a proof that the key k is actually present in the > dictionary m? How can I provide the proof that k is in m? I think it is possible to do this using the same trick that ST is using, i.e. rank 2 types. The problem is that this code is likely to be unwieldy to use, as the variable needs to change with every change to the map – but I guess if you create your map once and then use it in various places without modification, this can actually work. So we need to tag values (maps and keys) with variables. We could use Edward Kmett’s tagged library, but for now lets just roll our own (full code in the right order attached): newtype Tagged a x = Tag { unTag :: x } retag :: Tagged t1 x -> Tagged t2 x retag (Tag x) = (Tag x) The idea is that if you have a "Tagged a (Map k v)" and a "Tagged a k", where the a’s are the same variable, then you have a guarantee that the key is in the map. In the code we are writing now we can easily break that, e.g. using retag, but hopefully not via the functions that we are going to export in the end. The lookup function just ensures that the tags agree, if all goes well the "fromJust" will never fail: lookup :: Ord k => Tagged t k -> Tagged t (Map k v) -> v lookup (Tag k) (Tag m) = fromJust $ M.lookup k m We want a function that takes an existing map and tags it. As with most of the functions that follow, we use continuation passing style with a rank-2-function to ensure that no assumptions can be made about the tag variable at all. fromMap :: Map k v -> (forall t. Tagged t (Map k v) -> c) -> c fromMap m f = (f (Tag m)) The user of this code has no tagged keys of this type yet, so he cannot use lookup yet. Let’s allow him to add an entry: insert :: Ord k => k -> v -> Tagged t1 (Map k v) -> (forall t2. Tagged t2 (Map k v) -> Tagged t2 k -> (Tagged t1 k -> Tagged t2 k) -> c) -> c insert k v (Tag m) f = f (Tag (M.insert k v m)) (Tag k) retag Besides the usual arguments (key, value, map), it takes a continuation. This receives the updated map with a /new/ tag – after all, our knowledge about it has changed. We also return the tagged key; this is the proof (or the certificate) that the key is in the map that can be passed to lookup. And finally we pass a function that takes a proof „k is in the original map“ and turns it into a proof „k is in the update map“. We can also allow the programmer to check if a key is present, and obtain a proof if that is the case: check :: Ord k => k -> Tagged t1 (Map k v) -> (forall t2. Tagged t2 (Map k v) -> Maybe (Tagged t2 k) -> (Tagged t1 k -> Tagged t2 k) -> c) -> c check k (Tag m) f = f (Tag m) (if M.member k m then Just (Tag k) else Nothing) retag This would be useful when a non-empty map is converted with fromMap. The type of this function could be varied, e.g. by not creating a new tag at all if the type is not present. Finally we need to select the functions that are safe to use for the export list: module SafeMap (Tagged, unTag, fromMap, insert, lookup, check) More functions need to be added, e.g. an adjust (which luckily would not require a continuation-style type). Here is some code that uses the library to implement fromList (it is nice to see that this is possible given the primitives above): {-# LANGUAGE Rank2Types #-} import Data.Map (Map, empty) import SafeMap fromList :: Ord k => [(k,v)] -> (forall t. Tagged t (Map k v) -> [Tagged t k] -> c) -> c fromList [] f = fromMap empty $ \m -> f m [] fromList ((k,v):l) f = fromList l $ \m tks -> insert k v m $ \m' tk rt -> f m' (tk : map rt tks) And here is it in use: *Main> fromList [(1,1),(2,2)] (curry show) "(Tag {unTag = fromList [(1,1),(2,2)]},[Tag {unTag = 1},Tag {unTag = 2}])" The "map rt" will make this quadratic, as GHC does not detect if you map an (operationally speaking) identity over a list. Hopefully that will be fixed eventually: http://hackage.haskell.org/trac/ghc/ticket/2110 Is this anything like what you wanted? Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ {-# LANGUAGE Rank2Types #-} module SafeMap (Tagged, unTag, fromMap, insert, lookup, check) where import qualified Data.Map as M import Data.Map (Map) import Data.Maybe import Prelude hiding (lookup) newtype Tagged a x = Tag { unTag :: x } deriving (Show) retag :: Tagged t1 x -> Tagged t2 x retag (Tag
Re: [Haskell-cafe] Asking for advice on programming style and also performance
Hi, Am Montag, den 03.09.2012, 18:31 +0200 schrieb Harald Bögeholz: > I would greatly appreciate advice from experienced Haskellers why this > has happened. The program is hosted on github; this is the direct link > to the change with unexpected outcome: > > https://github.com/ctbo/slitherlink/commit/b6f58699258ef68ddee21a1346bd184465aaaba2 I’m not sure if you are notified via github, but there are comments there below the commit. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A first glimps on the {-# NOUPDATE #-} pragma
Hi, Am Mittwoch, den 29.08.2012, 17:16 +0100 schrieb Thomas Schilling: > Syntactically, I'd prefer something that looks more like a function. > With a pragma it's difficult to see what expression it actually > affects. For example, we already have the special functions "lazy" > and "inline". Since avoiding updates essentially turns lazy evaluation > into call-by-name you could call it "cbn". Perhaps that suggests a > different use case, though, so "nonstrict", "unshared", or "nonlazy" > might be more self-explanatory. thanks for the feedback. I only made it a pragma because it seemed to be simpler at first, but now the branch also supports GHC.Prim.noupdate (better name to be found before it reaches any official GHC branch, if that ever happens). > I'd also like to point out that avoiding updates can dramatically > improve the kind of speedups my tracing JIT can achieve. In > particular, on some benchmarks, it can optimise idiomatic Haskell code > to the same level as stream fusion. I can simulate that by avoiding > *all* updates (i.e., use call-by-name), but that would break some > programs badly. (Technically, that's all legal, but I'm pretty sure it > breaks any "tying-the-knot" tricks.) If you can make use of my code in Lambdachine I’d be very happy to help fixing bus and to hear about your results (but from a first glance it seems that you are not using that part of GHC in your project, right?). Greetings, Joachim -- Dipl.-Math. Dipl.-Inform. Joachim Breitner Wissenschaftlicher Mitarbeiter http://pp.info.uni-karlsruhe.de/~breitner 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] A first glimps on the {-# NOUPDATE #-} pragma
Hi Facundo, Am Mittwoch, den 29.08.2012, 10:26 -0300 schrieb Facundo Domínguez: > > upd_noupd n = > > let l = myenum' 0 n > > in last l + length l > > This could be rewritten as > > > upd_noupd n = > > let l n = myenum' 0 n > > in last (l n) + length (l n) > > Or a special form of let could be introduced to define locally-scoped macros: > > > upd_noupd n = > > let# l = myenum' 0 n > > in last l + length l > > What's the strength of the {-# NOUPDATE #-} approach? it does not require refactoring of the code. There is not always a parameter handy that you can use to prevent sharing, and using () for that sometimes fails due to the full-lazyness-transformation. And a locally-scoped macros would not help in this case: test g n = g (myenum' 0 n) Now you still might want to prevent the long list to be stored, but here it cannot be done just by inlining or macro expansion. Greetings, Joachim -- Dipl.-Math. Dipl.-Inform. Joachim Breitner Wissenschaftlicher Mitarbeiter http://pp.info.uni-karlsruhe.de/~breitner 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] A first glimps on the {-# NOUPDATE #-} pragma
Hi, Am Dienstag, den 28.08.2012, 18:16 -0400 schrieb Carter Schonwald: > On Tuesday, August 28, 2012, Yves Parès wrote: > Monad? Simple strictness anotation is enough in that case: > > upd_noupd n = > let l = myenum' 0 n > h = head l > in h `seq` last l + h darn, I though I changed my examples before posting to: upd_noupd n = let l = myenum' 0 n in last l + length l ("head" was a bad example because actually due to strictness analysis and worker/wrapper transformation, GHC would yield good code even without "`seq`"). In this case (which is actually the benchmarked case), reordering or strictness annotations do not help. Greetings and sorry for the confusion, Joachim -- Dipl.-Math. Dipl.-Inform. Joachim Breitner Wissenschaftlicher Mitarbeiter http://pp.info.uni-karlsruhe.de/~breitner 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
[Haskell-cafe] A first glimps on the {-# NOUPDATE #-} pragma
Dear GHC users, I am experimenting with ways to /prevent/ sharing in Haskell, e.g. to avoid space leaks or to speed up evaluation. A first attempt was to duplicate closures on the heap to preserve the original one, see http://arxiv.org/abs/1207.2017 for a detailed description and information on the prototype implementation; no GHC patching required for that. Currently I am trying a different angle: Simply avoid generating the code that will update a closure after its evaluation; hence the closure stays a thunk and will happily re-evaluate the next time it is used. Here is a classical example. Take this function (it is basically [f..t] but with a fixed type and no risk of existing rules firing): myenum :: Int -> Int -> [Int] myenum f t = if f <= t then f : myenum (f + 1) t else [] and this example where sharing hurts performance badly: upd_upd n = let l = myenum 0 n in last l + head l The problem is that during the evaluation of "last l", the list is live and needs to be kept in memory, although in this case, re-evaluating l for "head l" would be cheaper. If n is 5000, then this takes 3845ms on my machine, measured with criterion, and a considerable amount of memory (3000MB). So here is what you can do now: You can mark the value as non-updateable. We change myenum to myenum' :: Int -> Int -> [Int] myenum' f t = if f <= t then f : ({-# NOUPDATE #-} myenum' (f + 1) t) else [] and use that: upd_noupd n = let l = myenum' 0 n in last l + head l The improvement is considerable: 531ms and not much memory used (18MB) Actually, it should suffice to put the pragma in the definition of l without touching myenum: noupd_noupd n = let l = {-# NOUPDATE #-} myenum 0 n in last l + head l but this does not work with -O due to other optimizations in GHC. (It does work without optimization.) The next step would be to think of conditions under which the compiler could automatically add the pragma, e.g. when it sees that evaluation a thunk is very cheap but will increase memory consumption considerable. Also this does not have to be a pragma; it could just as well be a function "noupdate :: a -> a" that is treated specially by the compiler, similar to the "inline" function. If you want to play around this, feel free to fetch it from the unshare branch of my ghc repository at http://git.nomeata.de/?p=ghc.git or https://github.com/nomeata/ghc for the GitHub-lovers. Note that the branch is repeatedly rebased against ghc master. Greetings, Joachim -- Dipl.-Math. Dipl.-Inform. Joachim Breitner Wissenschaftlicher Mitarbeiter http://pp.info.uni-karlsruhe.de/~breitner 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] OS-independent auto-monitoring of a program to do things depending on resource usage at runtime
Hi, Am Montag, den 27.08.2012, 18:20 +0200 schrieb Alberto G. Corona : > For a caching library, I need to know the runtime usage of memory of > the program and the total amount of memory, the total memory used by > all the programs etc. > > > I need not do profiling or monitoring but to do different things > inside my program depending on memory usage. > > The search is difficult because all searches go to profiling utilities > which I don´t need. > > > Are there some portable way to to this? . The various monitoring > libraries indicates that there are ways to do it, but they seem not to > allow runtime "internal automonitoring" you can use the GHC.Stats module, see http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Stats.html, and remember to pass +RTS -T to the program, or -with-rtsopts=-T to the compiler. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
Hi, Am Mittwoch, den 15.08.2012, 12:38 -0700 schrieb Bryan O'Sullivan: > I propose that the sense of the recommendation around upper bounds in > the PVP be reversed: upper bounds should be specified only when there > is a known problem with a new version of a depended-upon package. as a Debian packager, I kinda like the tight upper bounds, as it allows me to predict what packages will break when I upgrade package X. It is only an approximation, but a safe one. If we would not have this, then I would either * upgrade X, upload to Debian, start rebuilding other stuff (this is automated and happens on Debians build servers), notice a break in package Y and then have to wait for Y’s upstream author to fix it. All the while, Y and all its reverse dependencies would not be installable. If this collides with a freeze, we’d be in big trouble. * upgrade X locally, rebuild everything manually and locally and only if thinks work out nicely, upload the whole bunch. Would work, but would be a huge amount of extra work. (note that in Debian we have at most one version of each Haskell package). I think what we’d need is a more relaxed policy with modifying a package’s meta data on hackage. What if hackage would allow uploading a new package with the same version number, as long as it is identical up to an extended version range? Then the first person who stumbles over an upper bound that turned out to be too tight can just fix it and upload the fixed package directly, without waiting for the author to react. If modifying packages with the same version number is not nice (it does break certain other invariants), we could make it acceptable behavior to upload someone else’s package without asking provided * one bumps the last (forth) component of the version * one extends the version range to encompass a set of versions that the uploader has just tested to work _without changes_ * no other change to the tarball is done. This way, the common user of hackage (including us distro packagers) will likely get a successful build if the build dependencies are adhered, but new version will much quicker work everywhere, even when original authors are temporarily slow to react. More power to everyone! Be bold! :-) Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talk about Haskell at Ubucon in Berlin
Hi, Am Samstag, den 04.08.2012, 23:56 +0200 schrieb Robert Clausecker: > I'm going to give a talk on Haskell at Ubucon 2012 in Berlin (In > German). I want to give an introduction about the concept of functional > programming and the special language concepts of Haskell. > > Any ideas what to focus on? maybe you get some ideas from my talk at GNUnify ’11, which is roughly the same that I blogged about at http://www.joachim-breitner.de/blog/archives/461-Haskell-Demonstration-at-IIT-Bombay.html But it is less an introduction and more a demonstration. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is (==) commutative?
[Re-sent as my first post did not make it through.] Hi Christian, Am Mittwoch, den 25.07.2012, 10:19 +0900 schrieb Christian Sternagel: > Btw: Isabelle/HOLCF unifies all error values and nontermination in a > single bottom element _|_. Currently we are using the following axioms > for our formal Eq class (where I'm using Haskell syntax although the > real sources [2] use Isabelle/HOLCF syntax which is slightly different; > (=) is meta-equality). > >(x == y) = True ==> x = y >(x == y) = False ==> not (x = y) >(x == _|_) = _|_ >(_|_ == y) = _|_ I am slightly worried about the latter two; after all one might find it reasonable to specify instance Eq () where _ == _ = True or, maybe slightly more sensible instance Eq Void where _ == _ = True But I checked and both the instances of (), the instance of Data.Void (in the void package) and the derived instance for empty data types are strict: Prelude> data V Prelude> :set -XStandaloneDeriving Prelude> deriving instance Eq V Prelude> (error "1" :: V) == (error "2" :: V) *** Exception: Void == Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Inferring Safety
Hi, Am Mittwoch, den 04.07.2012, 21:10 +1000 schrieb Ivan Lazar Miljenovic: > So what's going on here? you are likely hit by http://hackage.haskell.org/trac/ghc/ticket/5989 Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to check thunk
Hi, another related package seems to be my ghc-heap-view package, which is a bit lower level than vaccuum, as it does not try to build a consistent graph image but rather be more verbose about the heap objects, in particular about closures referenced by thunks: http://www.joachim-breitner.de/blog/archives/548-ghc-heap-view-Complete-referential-opacity.html http://hackage.haskell.org/package/ghc-heap-view Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs patch dependencies in dot format
Hi, Am Montag, den 14.05.2012, 07:21 -0700 schrieb Simon Michael: > I wonder how to simplify the graph further. Perhaps just the dependencies of > tags would be interesting in some repos ? I think you’d want to collapse [a]→[b] to [a,b], if no other edges leave a or reach b. This way you only get arrows at branching and merging points. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing call site for partial functions
Hi, Am Mittwoch, den 25.04.2012, 18:36 +0300 schrieb Michael Snoyman: > I'm sure there are many better ways to approach the problem, and I > can't speak to the complexity of implementation within GHC. I *can* > say, however, that this would have saved me a lot of time in the > example I gave above, and I'd bet many Haskellers have similar > stories. This could be a huge debugging win across the board. using TH (which I only reluctantly advocate for general usage) you can get good location information behaviour, see http://hackage.haskell.org/packages/archive/stm-stats/0.2.0.0/doc/html/Control-Concurrent-STM-Stats.html#v:trackThisSTM (and its source) for one example. One would use this approach maybe with http://hackage.haskell.org/packages/archive/safe/0.3.3/doc/html/Safe.html#v:headNote Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewrite rules for enumFromTo
Hi Michael, Am Mittwoch, den 18.04.2012, 19:21 +0300 schrieb Michael Snoyman: > I'm quite a novice at rewrite rules; can anyone recommend an approach > to get my rule to fire first? I’m not an expert of rewrite rules either, but from some experimentation and reading -dverbose-core2core (which is not a very nice presentation, unfortunately), I think that one reason why your rules won’t fire is that yieldMany is inlined too early. diff --git a/conduit/Data/Conduit/Internal.hs b/conduit/Data/Conduit/Internal.hs index bf2de63..8050c2c 100644 --- a/conduit/Data/Conduit/Internal.hs +++ b/conduit/Data/Conduit/Internal.hs @@ -353,7 +353,7 @@ yieldMany = where go [] = Done Nothing () go (o:os) = HaveOutput (go os) (return ()) o -{-# INLINE yieldMany #-} +{-# INLINE [1] yieldMany #-} {-# RULES "yield/bind" forall o (p :: Pipe i o m r). yield o >> p = yieldBind o p changes that. It might be hard to actually match on [1...1000], as that is very early replaced by the specific instance method which then takes part in the foldr/build-rewrite-reign. But maybe instead of specializing enumFromTo, you already get good and more general results in hooking into that? Juding from the code, you are already trying to do so, as you have a yieldMany/build rule that fires with above change: $ cat Test.hs module Test where import Data.Conduit import qualified Data.Conduit.List as CL x :: Pipe i Integer IO () x = mapM_ yield [1..1000] $ ghc -O -fforce-recomp -ddump-rule-firings Test.hs [1 of 1] Compiling Test ( Test.hs, Test.o ) Rule fired: Class op enumFromTo Rule fired: mapM_ yield Rule fired: yieldMany/build Oh, and as you can see, you don’t have to export the functions ocurring in the rules, as you did with yieldMany and yieldBuild. I don’t know conduits well, but you should check whether this also affects you: http://www.haskell.org/pipermail/haskell-cafe/2011-October/095985.html If conduits are constructed like in steam fusion, the build rule might not be of any use. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] building ghc on arch linux ARM?
Hi, Am Dienstag, den 10.04.2012, 13:04 +0200 schrieb Yves Parès: > > All these are not cross-compiled, but natively > > compiled on the repective architecture, and I don’t think it is > easily > > possible to cross-compile GHC itself even today. > > So how did they get compiled the first time? How do you get a GHC > working on or for an ARM platform if you don't use Debian? > And why was Joey Hess talking about performance issues? > (I'll be eventually interested, as Graham Klyne suggested earlier, in > compiling for Raspberry Pi, if the hardware suits). well, GHC was more portable in version 6.8 and before (this is not cross-compiling, at least not really: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting When I ported GHC to s390x half a year ago, I think I started with porting 6.8 and then kept building the next released version with the previous. It would be great, though, if porting current versions directly would become possible again. Most of these architectures do not have a native code generator (so they are compiled via C) and are unregisterized, i.e. GHC knows nothing about their registers. Both cause a performance penalty; I don’t know numbers. I assume this is what Joey refers to. But maybe also that ARM machines tend to be slower :-) I’m happily running git-annex on a NSLU2 (266MHz/23MB RAM ARM NAS device) and have done so before it was registerized, so it is definitely a useful target for Haskell. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] building ghc on arch linux ARM?
Hi, Am Dienstag, den 10.04.2012, 12:36 +0200 schrieb Yves Parès: > For instance, yes. > I think I had seen some times on this mailing list or on blog posts > (http://ghcarm.wordpress.com/) people having used GHC on ARM platform. > I distinctly remember having seen on the mailing list that > cross-compiling wasn't working but that we now can compile with GHC on > ARM, which means GHC can be compiled for ARM. I’m not sure what the news are here: Debian has provided ghc6 on arm at least since Debian etch in 2006 (GHC 6.6), and the first Debian release with ghc6 (Debian sarge) ships it on alpha hppa i386 ia64 m68k powerpc s390 and sparc (GHC 6.2). All these are not cross-compiled, but natively compiled on the repective architecture, and I don’t think it is easily possible to cross-compile GHC itself even today. (All data from http://archive.debian.net/) Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] building ghc on arch linux ARM?
Hi, Am Dienstag, den 10.04.2012, 11:00 +0200 schrieb Yves Parès: > Plus, I believed some had used GHC for smartphones? do you refer to http://www.joachim-breitner.de/blog/archives/300-Xmonad-on-my-mobile-phone.html or something more serious? Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Subscriber-only lists as Maintainer contacts of Cabal packges
Dear Cabal authors, if your package is team maintained and you put in a mailing list as the “Maintainer” contact of your package, that is in general a good thing. But if you do so, please make sure the list is not set to subscriber only; it is an unreasonable burden to subscribe for people who just want to send you one question, and possibly have to contact dozends of different package authors, e.g. as a distribution packager. Thanks, Joachim (Who really thinks that using the subscriber-only setting of mailman as an anti-spam-measure is an abuse of the feature, and that mailman should offer a “non-subscribers get a bounce that allows them to approve the message themselves“ feature which would give the same spam protection but much less hassle for the users.) -- 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] ANN: Haskell Platform Versions Comparison Chart
Hi, Am Dienstag, den 20.03.2012, 18:40 +0100 schrieb Simon Hengel: > > Do you see a way that you could incorporate distribution information? > > I thought it would be nice to have a second table that correlates > Platform versions with distro releases, because I think this is relevant > to package authors. > > Regarding information about Debian sid, I'd like to understand the exact > use case. Can you elaborate on that? one use case is developers who use distro packages and want to tell others against what version of the platform they develop their code against. 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] ANN: Haskell Platform Versions Comparison Chart
Hi, Am Sonntag, den 18.03.2012, 10:08 +0100 schrieb Simon Hengel: > I compiled a chart that gives a side-by-side comparison of package > versions in various Haskell Platform releases. > > http://sol.github.com/haskell-platform-versions-comparison-chart/ > > This includes both, packages that come with ghc and platform packages. > Source is on GitHub[1]. nice, and much prettier version than http://people.debian.org/~nomeata/platform.html Do you see a way that you could incorporate distribution information? You could maybe parse and (optionally) present the information that Hackage reads, e.g. http://people.debian.org/~nomeata/cabalDebianMap.txt for Debian? 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] cabal-install problem with alex dependency in bytestring-lexing
Hi, Am Freitag, den 16.03.2012, 21:00 +1100 schrieb Erik de Castro Lopo: > With a base system with just ghc and cabal-install, if I try to install > bytestring-lexing I get: > > $ cabal install bytestring-lexing > Resolving dependencies... > Configuring bytestring-lexing-0.4.0... > cabal: The program alex version >=2.3 is required but it could not be > found. > cabal: Error: some packages failed to install: > bytestring-lexing-0.4.0 failed during the configure step. The exception > was: > ExitFailure 1 > > The cabal file for bytestring-lexing contains > > Build-Tools: alex >= 2.3 > > Is there any way to make the cabal install of bytestring-lexing force > the install of alex first? no, cabal-install does not automatically install build-tools at all, only Cabal checks them for compilation. I guess the reason is that build-tools needs to be put on the PATH, and that is beyond the scope of cabal-install. 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] Understanding GC time
Hi, Am Samstag, den 10.03.2012, 15:50 -0300 schrieb Thiago Negri: > I see. Thanks for the answers. > > Any data structure or source annotation that would prevent that? > > For example, if I try the same program to run on a > [1..] list, I'll get an out of memory error for the > single-threaded version. Any way to prevent it without declaring two > different versions of "list"? I had real-world applications where I wanted a list rather to be generated over and over again, instead of generated once and then shared. One trick is to add a dummy parameter (of type (), for example) to the list, and instead of passing around the "[Int]", you pass around the "() -> [Int]" and apply it to () very late: module Main where import Data.List (foldl1') import Control.Parallel (par, pseq) import Control.Arrow ((&&&)) f `parApp` (a, b) = a `par` (b `pseq` (f a b)) seqApp = uncurry main = print result where result = (+) `parApp` minMax list minMax = minlist &&& maxlist minlist l = foldl1' min (l ()) maxlist l = foldl1' max (l ()) list _ = [1..1999] Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: string-conversions-0.1
Hi, Am Freitag, den 09.03.2012, 13:44 +0200 schrieb Michael Snoyman: > On Fri, Mar 9, 2012 at 1:40 PM, Joachim Breitner > wrote: > > > > I was about to suggest to merge this into the convertible package (to > > fight package proliferation), but found that it seems it is already > > there: > > http://hackage.haskell.org/packages/archive/convertible-text/0.4.0.2/doc/html/src/Data-Convertible-Instances-Text.html > > > I'm the author of convertible-text, and I consider it deprecated (it's > marked as such in the synopsis). sorry, I got confused by the two packages. In convertible itself, there is http://hackage.haskell.org/packages/archive/convertible/1.0.11.1/doc/html/src/Data-Convertible-Instances-Text.html which only converts between String and the two Text types, but not between ByteString because the encoding is not know there. And sorry for the partial mail. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: string-conversions-0.1
Hi, Am Freitag, den 09.03.2012, 13:44 +0200 schrieb Michael Snoyman: > On Fri, Mar 9, 2012 at 1:40 PM, Joachim Breitner > wrote: > > > > I was about to suggest to merge this into the convertible package (to > > fight package proliferation), but found that it seems it is already > > there: > > http://hackage.haskell.org/packages/archive/convertible-text/0.4.0.2/doc/html/src/Data-Convertible-Instances-Text.html > > > I'm the author of convertible-text, and I consider it deprecated (it's > marked as such in the synopsis). sorry, I got confused. In convertible itself, there is -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: string-conversions-0.1
Hi Sönke, Am Freitag, den 09.03.2012, 11:17 +0100 schrieb Sönke Hahn: > Any comments welcome. you could elaborate the documenatation “Assumes UTF-8” – I guess this only applies to the two ByteString variants, as String and Text _should_ contain unicode codepoints and no encoding. Not that someone tries to use a String where each Char corresponds to a byte in a UTF-8 encoded string and thinks he can convert it correctly. I was about to suggest to merge this into the convertible package (to fight package proliferation), but found that it seems it is already there: http://hackage.haskell.org/packages/archive/convertible-text/0.4.0.2/doc/html/src/Data-Convertible-Instances-Text.html Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compile one static Haskell binary for all x86_64 Linux distributions, is it possible?
Hi, Am Freitag, den 10.02.2012, 18:21 +0100 schrieb Morten Olsen lysgaard: > I tried with: > ghc --make -static -rtsopts=all -optl-pthread -optl-static Program.hs > > When I copy the binary created over to my x86_64 Ubuntu 11.10 desktop > and run it I get: > Program: mkTextEncoding: invalid argument (Invalid argument) this is how I deploy some of my Debian related programs on Debian stable machines. After setting export GCONV_PATH=/usr/lib64/gconv this binary will work fine. (Your path might need adjustment, just find the path that contains gconv-modules and a lot of .so files.) Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [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] strict version of Haskell - does it exist?
Hi, Am Montag, den 30.01.2012, 10:52 +0100 schrieb Alexander Bernauer: > On Sun, Jan 29, 2012 at 11:25:09PM +0100, Ertugrul Söylemez wrote: > > First of all, /learning/ to optimize Haskell can be difficult. The > > optimizing itself is actually fairly easy in my experience, once you > > understand how the language works. > > Given the fact that you have obviously mastered the learning part of > this, do you have any recommendations on what to read or on how to > proceed in order to learn how to optimize Haskell code? > > I can imagine, it's not only about understanding the language itself, > but also about understanding how your compiler and its switches work, > being able to find the hot spots in your code, being able to measure the > effects of your changes, developing a good sense for the tradeoffs, etc. > > So far, I have only stumpled upon chapter 25 of Real World Haskell. > Anything else you might recommend? Although I would not claim that I have mastered this, I did recently hold a talk that touched some of these issues, and also exhibits a case where you want something more fine-grained than just strictness or lazyness. From your name I think it is safe to point you to a German document: http://www.joachim-breitner.de/blog/archives/539-Guest-lecture-on-Haskell-performance.html Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: pointless fun
Hi, Am Samstag, den 28.01.2012, 23:34 -0500 schrieb wren ng thornton: > * Perhaps the most useful is that it packages up Matt Helige's classic > multicomposition trick[1]. These combinators allow you to easily modify > the types of a many-argument function with syntax that looks like giving > type signatures. For example, > > > foo:: A -> B -> C > > > > albert :: A -> X > > beth :: B -> Y > > carol :: C -> Z > > > > bar :: X -> Y -> Z > > bar = foo $:: albert ~> beth ~> carol > > I've found this to be especially helpful for defining non-derivable type > class instances for newtypes since it both abstracts away the plumbing > and also makes explicit what you mean. Even without looking at the definition of $:: and ~>, I have doubts about the existence of such a bar function (it calls foo, which needs an A, but it is not given an A and no used function produces one; albert only consumes one). Maybe you mean: foo:: A -> B -> C albert :: X -> A beth :: Y -> B carol :: C -> Z bar :: X -> Y -> Z bar = foo $:: albert ~> beth ~> carol Greetings from POPL, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern-matching & substitution for haskell-src-exts?
Hi, Am Mittwoch, den 18.01.2012, 12:05 -0800 schrieb Conal Elliott: > Has anyone implemented pattern-matching & substitution for > haskell-src-exts? - Conal without checking the code, I believe that hlint does exactly that; it takes rules (given as Haskell code), matches them as patterns against the real code and substitutes the matched parts in the right side of the rule. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hackage trac broken
Hi, a Debian user tried to report a bug against cabal-install (http://bugs.debian.org/655752) but the trac instance linked from the Cabal homepage seems to be down: http://hackage.haskell.org/trac/hackage/ Internal Server Error TracError: IOError: [Errno 13] Permission denied: '/srv/trac/hackage/VERSION' Is this known and will it be fixed? Thanks, 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] guided seq (Was: Interruptible threads with IO loops)
Dear Wren, Am Mittwoch, den 21.12.2011, 13:04 -0500 schrieb wren ng thornton: > On 12/21/11 4:31 AM, Joachim Breitner wrote: > > This would be particularly handy when with, for example > > snd tuple `evaluateUntilItDoesNotNeed` tuple > > where the tuple is unevaluated in the right component (and where we > > don’t want to force this just now), but retains something large in the > > left component (that we want to become GCable). > > Can't you already do that with: > > let (_,x) = tuple in ...x... > > or > > case tuple of (_,x) -> ...x... > > ? > > The tuple will be evaluated far enough that we can access its second > component, and then we're free to discard the tuple itself provided it's > not referenced elsewhere. The above would only be strict in x if the use > sites are strict. > > Or do you mean that you want something with the semantics of the above, > but with a syntactic form that enables us to abstract out the ellipses? Your first example would not work, because the tuple is only evaluated when x is evaluated, which might be later than the point where I want the left component of the tuple to be GCed: Prelude Debug.Trace> let (_,x) = trace "some tuple" (error "a", error "b") in const () x () The second case works in this particular instance: Prelude Debug.Trace> case trace "some tuple" (error "a", error "b") of (_,x) -> const () x some tuple () But assume the function is not snd but rather a library provided function that you have no control over and that you know returns one component of the tuple, but you don’t know which (depending on other parameters, perhaps). The advantage of a `evaluateUntilItDoesNotNeed` would be that it can be combined with code that was written without having such considerations in mind. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] guided seq (Was: Interruptible threads with IO loops)
Hi, Am Mittwoch, den 21.12.2011, 19:15 +1000 schrieb Gregory Crosswhite: > I don't have any tips for cleaning up the code off the top of my head, > but I suspect that the memory leak is coming from the fact that the > expression (v+1) is not being forced, which means that each iteration > of the loop is constructing a new thunk with a reference to the old > thunk resulting in a data structure that is growing in memory usage > over time. this problem comes up in various places; forcing the whole thunk is of course an option, but would it be possible – theoretical, with the GHC runtime, or even with current tools – to have a function evaluateUntilItDoesNotNeed :: a -> b -> a such that f x `evaluateUntilItDoesNotNeed` x will not retain a reference to x, but is otherwise as lazy as possible? If thunks retain references to their free variables, and these can be introspected, then it should be possible to keep seq’ing those thunks that refer to x, until the expression is either fully evaluated or no referenced thunk references x. This would be particularly handy when with, for example snd tuple `evaluateUntilItDoesNotNeed` tuple where the tuple is unevaluated in the right component (and where we don’t want to force this just now), but retains something large in the left component (that we want to become GCable). Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: The Haskell Platform 2011.4
Hi, Am Samstag, den 17.12.2011, 16:04 -0500 schrieb Don Stewart: > We're pleased to announce the release of the Haskell Platform: a > single, standard Haskell distribution for everyone. > > Download the Haskell Platform 2011.4.0.0: we are pleased to announce the release of the Haskell Platform on Debian: Version 2011.4.0.0 has just been uploaded to the unstable suite. In a few hours you will see it also on http://packages.debian.org/sid/haskell-platform (Ok, this is a bit of cheating; we have packaged the required libraries already a few weeks back, based on the unreleased platform cabal file at http://code.haskell.org/haskell-platform/haskell-platform.cabal, and now just bumped the version number of the meta package.) If everything goes well the updated packages will be available in Debian testing (“wheezy”) in two or three days. Note that Debian slightly deviates from the version constraints as specified in the official platform package, due to non-platform libraries and programs requiring newer versions. At the moment, this is: alexversion 3.0.1 instead of 2.3.5 cgi version 3001.1.8.2 instead of 2001.1.7.4 network version 2.3.0.6instead of 2.3.0.5 You can always check the various platform package versions available in Debian stable (“squeeze”), testing (“wheezy”) and unstable (“sid”) on http://people.debian.org/~nomeata/platform.html On behalf of the Debian Haskell Group, Joachim Breitner -- 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] gtk2hs: adding widget during runtime
Hi, Am Samstag, den 17.12.2011, 20:42 +0100 schrieb Gary Klindt: > That compiles fine, but the GUI never shows a "neues label!". blind guess: Do you need to call widgetShow on the newly created widget? Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Sharing a room for the CRA-W/CDC/SIGPLAN Mentoring Workshop at POPL?
Hi, I will attend the CRA-W/CDC/SIGPLAN Mentoring Workshop at POPL next year, and will have to share a room with another attendee. As we can give preferences, I was wondering if another Haskeller might be in the same position and interested in sharing a room. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Weird interaction between literate haskell, ghci and OverloadedStrings
Hi, Am Samstag, den 03.12.2011, 16:18 +1100 schrieb Erik de Castro Lopo: > I'm working on a literate haskell document (actually TeX, but the > example below is just test) and I'm using ByteStrings in the code. > I know I can do: > > ghci -XOverloadedStrings file.lhs > > or, after ghci is running I can do: > > Main> :set -XOverloadedStrings > > but I'd like to embed a directive in the file so that when loaded > in GHCi, I will automatically get OverloadedStrings. This is mainly > so that it JustWorks(tm) when I pass the file on to someone else. > > Is there a way to do this? > > There is a short example file below. I'm using ghc-7.0.4 from Debian > testing. it does not seem to be related to literate haskell, if I copy the code from your file into a .hs without the "> ", ghci still does not activate the OverloadedStrings extension when loading the file. I’d consider this a bug until the developers explain why this should or cannot be different, and suggest you file it as such. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List Fusion of concatMap
Hi, Am Donnerstag, den 01.12.2011, 22:16 +0100 schrieb Joachim Breitner: > This would motivate the following definition for a fusionable concatMap, > going via list comprehensions and their translation to ideal list fusion > consumers/producers: > >concatMap f xs > == [ y | x <- xs, y <- f x ] > == build (\c n -> foldr (\x b -> foldr c b (f x)) n xs) > > And indeed, adding > {-# RULES "myConcatMap" forall f xs . concatMap f xs = build (\c n -> foldr > (\x b -> foldr c b (f x)) n xs) #-} > > to my file finally makes func1 behave the way I want it to, i.e. exactly > the same core as the list comprehension variant, and no lists at all, > only unboxed integers. > > Now I guess there is a reason why concatMap is not defined this way. But > what is it? I further tired to investigate where func2 (using "concat (map ..)") goes wrong, after all, we have this rule for concat: forall xs. concat xs = build (\c n -> foldr (\x y -> foldr c y x) n xs) which is pretty close to what I am proposing for concatMap above. I used "ghc -dverbose-core2core -ddump-rule-firings", but it seems that this output is not complete; e.g. at some point, RULES "eftInt"[~1] forall x y. eftInt x y = build (\ c n -> eftIntFB c n x y) fires, but the output does not mention it. Anyway, I tried to reconstruct what is happening in better readable terms: We begin with func2 as given: func2 k = any (>5) (concat (map (\m -> [1..m]) [1..k])) rule "map" func2 k = any (>5) (concat (build (\c n -> foldr (mapFB c (\m -> [1..m])) n [1..k]))) rule "concat" func2 k = any (>5) (build (\c n -> foldr (\x y -> foldr c y x) n (build (\c n -> foldr (mapFB c (\m -> [1..m])) n [1..k] rule "fold/build" func2 k = any (>5) (build (\c n -> (\c n -> foldr (mapFB c (\m -> [1..m])) n [1..k]) (\x y -> foldr c y x) n)) rule "any/build" func2 k = (\c n -> (\c n -> foldr (mapFB c (\m -> [1..m])) n [1..k]) (\x y -> foldr c y x) n) ((||) . (>5)) False rule "eftInt" func2 k = (\c n -> (\c n -> foldr (mapFB c (\m -> [1..m])) n (build (\c n -> eftIntFB c n 1 k))) (\x y -> foldr c y x) k) ((||) . (>5)) False rule "fold/build" func2 k = (\c n -> (\c n -> (\c n -> eftIntFB c n 1 k) (mapFB c (\m -> [1..m])) n) (\x y -> foldr c y x) n) ((||) . (>5)) False beta-reduction func2 k = eftIntFB (mapFB (\x y -> foldr ((||) . (>5)) y x) (\m -> [1..m])) False 1 k At this point, if the definition of mapFB would be inlined, we could continue successfully as follows. This is not what is happening, but I am not sure why: func2 k = eftIntFB (\x ys -> (\x y -> foldr ((||) . (>5)) y x) ((\m -> [1..m]) x) ys) False 1 k beta-reduction func2 k = eftIntFB (\m ys -> (foldr ((||) . (>5)) ys [1..m])) False 1 k rule "eftInt" func2 k = eftIntFB (\m ys -> (foldr ((||) . (>5)) ys (build (\c n -> eftIntFB c n 1 m False 1 k rule "fold/build" func2 k = eftIntFB (\m ys -> (eftIntFB ((||) . (>5)) ys 1 m)) False 1 k completely deforested code. What do you think? Can the list fusion rules be improved so that they can catch these cases as well? Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List Fusion of concatMap
Hi, Am Donnerstag, den 01.12.2011, 21:44 +0100 schrieb Joachim Breitner: > Does ghc treat list comprehensions differently here? I could answer this by looking at compiler/deSugar/DsListComp.lhs in the GHC source: List comprehensions may be desugared in one of two ways: ``ordinary'' (as you would expect if you read SLPJ's book) and ``with foldr/build turned on'' (if you read Gill {\em et al.}'s paper on the subject). (and indeed the translation depends on the flags) and later on: @dfListComp@ are the rules used with foldr/build turned on: TE[ e | ]c n = c e n TE[ e | b , q ] c n = if b then TE[ e | q ] c n else n TE[ e | p <- l , q ] c n = let f = \ x b -> case x of p -> TE[ e | q ] c b _ -> b in foldr f n l So I could manually rewrite func3 to: func4 :: Int -> Bool func4 k = any (>5) (build (\c n -> foldr (\x b -> case x of m -> foldr (\x' b' -> case x' of i -> c i b' ) b [1..m] ) n [1..k] )) {-# NOINLINE func4 #-} and get identical core output. Having a case expression does not matter in this case, because the code does all calculations completely with unboxed integers anyways, so this can be written as follows, with still identical core: func5 :: Int -> Bool func5 k = any (>5) (build (\c n -> foldr (\x b -> foldr c b [1..x]) n [1..k] )) {-# NOINLINE func5 #-} This would motivate the following definition for a fusionable concatMap, going via list comprehensions and their translation to ideal list fusion consumers/producers: concatMap f xs == [ y | x <- xs, y <- f x ] == build (\c n -> foldr (\x b -> foldr c b (f x)) n xs) And indeed, adding {-# RULES "myConcatMap" forall f xs . concatMap f xs = build (\c n -> foldr (\x b -> foldr c b (f x)) n xs) #-} to my file finally makes func1 behave the way I want it to, i.e. exactly the same core as the list comprehension variant, and no lists at all, only unboxed integers. Now I guess there is a reason why concatMap is not defined this way. But what is it? Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] List Fusion of concatMap
Hi, in further attempts to get a better understanding of list fusion, I am investigating under what conditions, calls to concat and concatMap succesfully fusion away. Here is my test code: import System.Exit func0 :: Int -> Bool func0 n = any (>5) [1..n] {-# NOINLINE func0 #-} func1 :: Int -> Bool func1 n = any (>5) (concatMap (\m -> [1..m]) [1..n]) {-# NOINLINE func1 #-} func2 :: Int -> Bool func2 n = any (>5) (concat (map (\m -> [1..m]) [1..n])) {-# NOINLINE func2 #-} func3 :: Int -> Bool func3 n = any (>5) [ i | m <- [1..n] , i <- [1..m]] {-# NOINLINE func3 #-} func4 :: Int -> Bool func4 n = any (>5) ( let ok m = [ i | i <- [1..m] ] in concatMap ok [1..n] ) {-# NOINLINE func4 #-} main = if func0 10 && func1 10 && func2 10 && func3 10 && func4 10 then exitSuccess else exitFailure I deliberately did not use any putStr statements in main, so that I can easily spot list types in the output of ghc -fext-core. The use of "any" and "[...]" represent any fusion-enabled producers or consumers; these are just very well-behaving and easy to spot in the core output. Here are my obeservations: * The code generated for func0 does not use any lists at all, but rather one recursive (even tail-recursive) function, as expected. This was basically a test whether I am indeed able to observe list fusion. * func1 and func2 are not fused successfully; both core outputs still contain mentions of [] (search for ZMZN; is there a tool that does this unescaping for me? ghc-core does not, it seems.) * Now the surprising fact: func3 does without any lists! The code generated contains two nested recursive functions, the inner one even tail recursive (and the outer one could have been made tail-recursive, it seems, but that would be a different issue). * func4, which is a direct one-step translation of func3 according to the semantic rules of list comprehension in the haskell report, again is not fused completely. Now I wonder: How do I need to phrase the function with concatMap such that fusion works? Does ghc treat list comprehensions differently here? Do the rewrite rules need work so that func1 and func2 do fuse correctly? Thanks for your attention, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List fusion of nested lists
Hi again, Am Donnerstag, den 01.12.2011, 11:38 +0100 schrieb Joachim Breitner: > Am Donnerstag, den 01.12.2011, 11:28 +0100 schrieb Joachim Breitner: > > Now I’d like to implement streaks in terms of build and foldr such that > > it is subject to list fusion. > > one half of the task is quite doable: > > streaks' :: [Integer] -> [[Integer]] > streaks' xs = foldr streaksF [] xs > > streaksF :: Integer -> [[Integer]] -> [[Integer]] > streaksF i [] = [[i]] > streaksF i ([x]:ys) = [i,x]:ys > streaksF i ((x1:x2:xs):ys) = if i `compare` x1 == x1 `compare` > x2 > then (i:x1:x2:xs):ys > else [i]:(x1:x2:xs):ys > > so I can make streaks a somewhat well-behaving consumer. The task to > create the lists using build remains. isn’t it always nice how posting questions help you think differently about the problem? Here is the next step in the construction; ensure that at least the outer list is subject to list fusion: streaks'' :: [Integer] -> [[Integer]] streaks'' xs = build $ \c n -> uncurry c $ foldr (streaksF' c) ([],n) xs streaksF' :: ([Integer] -> b -> b) -> Integer -> ([Integer],b) -> ([Integer],b) streaksF' c i ([],ys) = ([i],ys) streaksF' c i ([x],ys) = ([i,x],ys) streaksF' c i ((x1:x2:xs),ys) = if i `compare` x1 == x1 `compare` x2 then (i:x1:x2:xs, ys) else ([i], (x1:x2:xs) `c` ys) It seems that the next steps are: 1. Add information to the accumulator of the foldr that carries the information that is currently obtained by pattern matching (as we cannot look a fusioned list any more). 2. Somehow replace the : and [] of the inner list by the functions given by build. But have doubts that this is possible, these can only be used inside the argument of build. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List fusion of nested lists
Hi, Am Donnerstag, den 01.12.2011, 11:28 +0100 schrieb Joachim Breitner: > Now I’d like to implement streaks in terms of build and foldr such that > it is subject to list fusion. one half of the task is quite doable: streaks' :: [Integer] -> [[Integer]] streaks' xs = foldr streaksF [] xs streaksF :: Integer -> [[Integer]] -> [[Integer]] streaksF i [] = [[i]] streaksF i ([x]:ys) = [i,x]:ys streaksF i ((x1:x2:xs):ys) = if i `compare` x1 == x1 `compare` x2 then (i:x1:x2:xs):ys else [i]:(x1:x2:xs):ys so I can make streaks a somewhat well-behaving consumer. The task to create the lists using build remains. (The function only works correctly on lists where no two adjacent elements are the same, and it behaves differently than the code in the first mail on [2,1,2]; it builds [[2],[1,2]] instead of [[2,1],2]. That is ok for my purposes.) Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] List fusion of nested lists
Dear Cafe, I’m trying to exploit list fusion as provided by GHC (build/foldr). One function that I want to get fusable is this, it splits a list of integeres into maximal monotonous subsequences: streaks :: [Integer] -> [[Integer]] streaks [] = [] streaks (x:xs) = let (this,rest) = oneStreak (x:xs) in this:streaks rest oneStreak :: [Integer] -> ([Integer], [Integer]) oneStreak [x] = ([x],[]) oneStreak l@(x:y:_) = splitWhile2 (\a b -> a `compare` b == x `compare` y) l splitWhile2 :: (Integer -> Integer -> Bool) -> [Integer] -> ([Integer], [Integer]) splitWhile2 p [x] = ([x],[]) splitWhile2 p (x:y:xs) | p x y = let (s,r) = splitWhile2 p (y:xs) in (x:s,r) | otherwise = ([x],y:xs) Now I’d like to implement streaks in terms of build and foldr such that it is subject to list fusion. Especially, when used in concatMap (streaks . func) :: [X] -> [[Integer]] where func :: X -> [Integer] is implemented with buildr, this should ideally remove all intermediate lists. Can this be done with list fusion at all? How would I go about it? If the above example is too complicated, known how it would work for Data.List.group would help me already a lot. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers-deepseq?
Hi, Am Dienstag, den 29.11.2011, 10:36 +0200 schrieb Michael Snoyman: > On Tue, Nov 29, 2011 at 10:29 AM, Joachim Breitner > wrote: > > Am Dienstag, den 29.11.2011, 07:43 +0200 schrieb Michael Snoyman: > >> Since the release of deepseq 1.2, we've had a bit of a problem: when > >> using the newest versions of packages on Hackage, there is no NFData > >> instance available for the containers types. When GHC 7.4 comes out > >> with its newer version of containers, this will be addressed, but > >> we'll still have problems for users of older GHC releases. > >> > >> I'd like to suggest a solution: a new package called > >> containers-deepseq. Using conditional compilation, it will provide an > >> orphans NFData instance for all containers types when deepseq >= 1.2 > >> and containers < 0.5. Packages (e.g., aeson) would then depend on > >> containers-deepseq and simply import the module whenever they rely on > >> the NFData instances. When GHC 7.4 comes out, the package will > >> essentially be a no-op. > >> > >> Does this make sense? > > > > from a distro point of view: Please void this if possible; every > > additional package causes us work. (Although we’d likely just not > > upgrade containers before 7.4.1 and patch out the dependency in the > > cabal file when we switch to 7.4.1.) > > > > Why can’t you put the instances in containers, guarded by some #ifs? I > > don’t see the point of a separate package for these 15 lines of code. > > Because containers cannot be updated: you're stuck with whatever > version comes with GHC. ah, I remember. Trying the same trick in deepseq is also not nice, because it would require a cabal-conditional dependency on containers, which would surely cause other problems. How about depending on (deepseq < 1.2 && containers < 0.5) || (deepseq >= 1.2 && containers >= 0.5) in a package that uses the NFData instances? Then cabal would figure out the right version of deepseq to use, based on the version of containers available (or at least I hope so). Gruß, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers-deepseq?
Hi, Am Dienstag, den 29.11.2011, 07:43 +0200 schrieb Michael Snoyman: > Since the release of deepseq 1.2, we've had a bit of a problem: when > using the newest versions of packages on Hackage, there is no NFData > instance available for the containers types. When GHC 7.4 comes out > with its newer version of containers, this will be addressed, but > we'll still have problems for users of older GHC releases. > > I'd like to suggest a solution: a new package called > containers-deepseq. Using conditional compilation, it will provide an > orphans NFData instance for all containers types when deepseq >= 1.2 > and containers < 0.5. Packages (e.g., aeson) would then depend on > containers-deepseq and simply import the module whenever they rely on > the NFData instances. When GHC 7.4 comes out, the package will > essentially be a no-op. > > Does this make sense? from a distro point of view: Please void this if possible; every additional package causes us work. (Although we’d likely just not upgrade containers before 7.4.1 and patch out the dependency in the cabal file when we switch to 7.4.1.) Why can’t you put the instances in containers, guarded by some #ifs? I don’t see the point of a separate package for these 15 lines of code. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] "Bounds checking" pragma?
Hi, Am Donnerstag, den 10.11.2011, 01:35 +0200 schrieb Artyom Kazak: > Anyway, I have to say it once again: unsafeAt is ugly and Haskell is > beautiful. Why high-performance code should be ugly? It does not have to be ugly. Just write (!!) = unsafeAt in some common module of yours, and you have a nice fast array access. I don’t think a flag would be very helpful, because you might have some places where you want the safe access, and others where you know that it is safe to skip the check. Greetings, Joachim -- Joachim "nomeata" Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe