April 2013 - Haskell-Cafe

text-icu on Windows
by John MacFarlane 28 Apr '13

28 Apr '13

Hello café: I'd very much like to get text-icu working on Windows, as then I could ship pandoc binaries that do proper unicode collation in bibliographies. But I'm having a devil of a time. This may be due to my very limited Windows knowledge. Any help would be appreciated, especially from someone who actually has text-icu working on Windows. I was able to cabal install text-icu without errors. I used --extra-lib-dirs and --extra-include-dirs to point to the lib and include directories in the 32-bit binary distribution of icu4c. I'm using the latest Haskell Platform, 2012.4.0.0 with ghc 7.4.2. I was also able to build the following simple program that uses text-icu, by doing ghc --make icu.hs: ~~~ -- icu.hs import Data.Text.ICU main = print $ Locale "tr-TR" ~~~ No errors or warnings in either of these steps. But when I try to run the compiled program, icu.exe, I get no output at all. I expected to get a line with 'Locale "tr-TR"', but instead I get nothing -- not even an error or warning. This remains the case if I try ~~~ main = do print "Start" print $ Locale "tr-TR" print "Done" ~~~ 'echo $?' yields False. Any ideas? John (I've posted a similar question to StackOverflow [1], but it hasn't gotten an answer yet there, so I thought I'd try here.) [1]: http://stackoverflow.com/questions/16127710/how-do-i-get-text-icu-working-o…)

3 4

HList with DataKinds [Was: Diving into the records swamp (possible GSoC project)]
by oleg＠okmij.org 28 Apr '13

28 Apr '13

Aleksandar Dimitrov wrote: > I've been kicking around the idea of re-implementing HList on the basis of the > new DataKinds [1] extension. The current HList already uses DataKinds (and GADTs), to the extent possible with GHC 7.4 (GHC 7.6 supports the kind polymorphism better, but it had a critical for me bug, fixed since then.) See, for example http://code.haskell.org/HList/Data/HList/HListPrelude.hs (especially the top of the file). or, better http://code.haskell.org/HList/Data/HList/HList.hs HList now supports both type-level folds and unfolds.

1 0

Markdown extension for Haddock as a GSoC project
by Chris Smith 27 Apr '13

27 Apr '13

Oops, forgot to reply all. ---------- Forwarded message ---------- From: "Chris Smith" <cdsmith(a)gmail.com> Date: Apr 27, 2013 12:04 PM Subject: Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project To: "Bryan O'Sullivan" <bos(a)serpentine.com> Cc: I don't agree with this at all. Far more important than which convention gets chosen is that Haskell code can be read and written without learning many dialects of Haddock syntax. I see an API for pluggable haddock syntax as more of a liability than a benefit. Better to just stick to what we have than fragment into more islands. I do think that changing Haddock syntax to include common core pieces of Markdown could be a positive change... but not if it spawns a battle of fragmented documentation syntax that lasts a decade. On Apr 27, 2013 11:08 AM, "Bryan O'Sullivan" <bos(a)serpentine.com> wrote: > On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley <alistair(a)abayley.org>wrote: > >> How's about Creole? >> http://wikicreole.org/ >> >> Found it via this: >> >> http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-l… >> >> If you go with Markdown, I vote for one of the Pandoc implementations, >> probably Pandoc (strict): >> http://johnmacfarlane.net/babelmark2/ >> >> (at least then we're not creating yet another standard...) >> > > Probably the best way to deal with this is by sidestepping it: make the > support for alternative syntaxes as modular as possible, and choose two to > start out with in order to get a reasonable shot at constructing a suitable > API. > > I think it would be a shame to bikeshed on which specific syntaxes to > support, when a lot of productive energy could more usefully go into > actually getting the work done. Better to say "prefer a different markup > language? code to this API, then submit a patch!" > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

3 2

partially applied data constructor and corresponding type
by TP 27 Apr '13

27 Apr '13

Hello, I ask myself if there is a way to do the following. Imagine that I have a dummy type: data Tensor = TensorVar Int String where the integer is the order, and the string is the name of the tensor. I would like to make with the constructor TensorVar a type "Vector", such that, in "pseudo-language": data Vector = TensorVar 1 String Because a vector is a tensor of order 1. Is this possible? I have tried type synonyms and newtypes without any success. Thanks a lot, TP

2 2

Operations on functional graphs
by Francesco Mazzoli 27 Apr '13

27 Apr '13

Hi list, I’ve been lately thinking about how to implement an algorithm efficiently, and I need a directed graph that can perform the following tasks: 1. Finding the strongly connected components 2. Condensing strongly connected components 3. Contract single edges The condensing shouldn’t prevent successive operations to work with the condensed vertices (treating them all as the same), but should get rid of the edges. Point one is easy, for example as described in [1]. I’m wondering if a nice way to implement the other two with functional structures has been described. I’d guess it would be a mix of a graph and disjoint sets data structure... Thanks, Francesco [1]: Structuring Depth-First Search Algorithms in Haskell, by David King and John Launchbury.

1 1

Request for help: Recompile of ghc producing "...-ghc7.4.2.so"s, which break project builds.
by Captain Freako 27 Apr '13

27 Apr '13

Recently, I had to recompile ghc, in order to get the "-dyn" versions of the standard libraries installed. (The standard Ubuntu 12.10 64-bit Linux distribution doesn't include them in its "haskell-platform" package, and you can't upgrade "base" using the normal "cabal iinstall" approach, from what I understand.) When I did this, the "-dyn" versions of the standard libraries were, in fact, installed. However, they were given names with a "-ghc7.4.2.so" suffix. And this is causing the build of a previously working project to break, thusly: ghc -o libami.so -shared -dynamic -package parsec *-lHSrts* -lm -lffi -lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o /usr/bin/ld: /usr/lib/ghc-7.4.2/*libHSrts.a*(RtsAPI.o): relocation R_X86_64_32S against `ghczmprim_GHCziTypes_Czh_con_info' can not be used when making a shared object; recompile with -fPIC The problem is this: the linker is picking up the "*.a" version of the * HSrts* library, instead of the "*.so" version, which is what it really needs. And the reason it's doing this is the "*.so" version has been given a "-ghc7.4.2" suffix: dbanas@dbanas-lap:~/prj/AMI-Tool$ l /usr/lib/ghc-7.4.2/libHSrts* /usr/lib/ghc-7.4.2/libHSrts.a {snip} /usr/lib/ghc-7.4.2/libHSrts*-ghc7.4.2*.so* {snip} So, it seems to me that I need to either: 1. Tell the linker about the possibility of a "-ghc7.4.2" file name suffix, or 2. rebuild my "*.so"s without that suffix. *Can anyone tell me:* - *How to accomplish either #1 or #2, above?* - *Which one is the preferred solution to the problem?* - *Am I completely off in the weeds?* - *If so, what should I really be doing, in order to fix this issue?* Thanks! -db

3 2

Re: [Haskell-cafe] Why were datatype contexts removed instead of "fixing them"?
by wren ng thornton 26 Apr '13

26 Apr '13

On 4/25/13 9:49 PM, Dan Doel wrote: > I don't really think they're worth saving in general, though. I haven't > missed them, at least. The thing I've missed them for (and what I believe they were originally designed for) is adding constraints to derived instances. That is, if I have: data Bar a => Foo a = ... deriving Baz Then this is equivalent to: data Foo a = ... instance Bar a => Baz (Foo a) where ... where the second ellipsis is filled in by the compiler. Now that these constraints have been removed from the language, I've had to either (a) allow instances of derived classes which do not enforce sanity constraints, or (b) implement the instances by hand even though they're entirely boilerplate. The behavior of these constraints is certainly unintuitive for beginners, but the constraints themselves are very helpful when programming with phantom types and type-level functions for constraints. -- Live well, ~wren

2 1

Instances for continuation-based FRP
by Hans Höglund 25 Apr '13

25 Apr '13

Hi everyone, I am experimenting with various implementation styles for classical FRP. My current thoughts are on a continuation-style push implementation, which can be summarized as follows. > newtype EventT m r a = E { runE :: (a -> m r) -> m r -> m r } > newtype ReactiveT m r a = R { runR :: (m a -> m r) -> m r } > type Event = EventT IO () > type Reactive = ReactiveT IO () The idea is that events allow subscription of handlers, which are automatically unsubscribed after the continuation has finished, while reactives allow observation of a shared state until the continuation has finished. I managed to write the following Applicative instance > instance Applicative (ReactiveT m r) where > pure a = R $ \k -> k (pure a) > R f <*> R a = R $ \k -> f (\f' -> a (\a' -> k $ f' <*> a')) But I am stuck on finding a suitable Monad instance. I notice the similarity between my types and the ContT monad and have a feeling this similarity could be used to clean up my instance code, but am not sure how to proceed. Does anyone have an idea, or a pointer to suitable literature. Best regards, Hans

5 7

pattern matching on data families constructors
by Alexey Egorov 25 Apr '13

25 Apr '13

Hi, suppose that there is following data family: > data family D a > data instance D Int = DInt Int > data instance D Bool = DBool Bool it is not possible to match on constructors from different instances: > -- type error > a :: D a -> a > a (DInt x) = x > a (DBool x) = x however, following works: > data G :: * -> * where > GInt :: G Int > GBool :: G Bool > > b :: G a -> D a -> a > b GInt (DInt x) = x > b GBool (DBool x) = x The reason why second example works is equality constraints (a ~ Int) and (a ~ Bool) introduced by GADT's constructors, I suppose. I'm curious - why data families constructors (such as DInt and DBool) doesn't imply such constraints while typechecking pattern matching? Thanks.

3 6

Munich Haskell Meeting
by Heinrich Hördegen 25 Apr '13

25 Apr '13

Dear all, our next regular meeting will take place in Munich on the 29th of April at 19h30 at Cafe Puck. If you plan to join us, please go to http://www.haskell-munich.de/dates and click the button. Until then, have a nice time, Heinrich

1 0