- Haskell-Cafe - Haskell.org

Why were datatype contexts removed instead of "fixing them"?
by harry 28 Apr '13

28 Apr '13

If I understand correctly, the problem with datatype contexts is that if we have e.g. data Eq a => Foo a = Foo a the constraint Eq a is thrown away after a Foo is constructed, and any method using Foos must repeat Eq a in its type signature. Why were these contexts removed from the language, instead of "fixing" them? PS This is following up on a discussion on haskell-beginners, "How to avoid repeating a type restriction from a data constructor". I'm interested in knowing whether there's a good reason not to allow this, or if it's just a consequence of the way type classes are implemented by compilers.

10 17

Display an inferred type during compilation
by Corentin Dupont 28 Apr '13

28 Apr '13

Hi Cafe, can I ask the compiler to display the type of an inferred value during compile time? It would be great if I can output a string during compilation with the type. A little bit like running :type in GHCi, but without GHCi... Because running GHCi is sometime painful (I have to clean my code first). I'm thinking of something like: main :: IO () main = do a <- someCode displayTypeAtCompileTime a return () $ ghc -c test.hs test.hs:4:3: your type is: Foo Thanks, Corentin

3 3

Diving into the records swamp (possible GSoC project)
by Adam Gundry 28 Apr '13

28 Apr '13

Hi, I am hoping to do a GSoC project this year working on GHC, and have been pointed in the direction of the records issue (in particular, the desire to overload field names). This has been discussed on-and-off for years, and while there are lots of ideas [1], little has been implemented in GHC itself. The plan would be to implement a solution to the "narrow issue" of overloaded field names, along the lines of Simon PJ's SORF proposal (on the wiki). This would provide a basis for experimentation with first-class record types. While there are still design issues to resolve, the broad plan is clear and I'm confident it can be implemented in a summer and without overly restricting future record system designs. Does this sound like a reasonable strategy? I'd appreciate comments and criticism, although arguing about the details of the design should perhaps wait. (A little about me: I'm a PhD student working on type inference for Haskell and dependent types, with about four years' Haskell experience including work on big type-system related projects. I am familiar with the theory behind GHC, but I haven't worked on the code before.) Thanks, Adam Gundry [1] http://hackage.haskell.org/trac/ghc/wiki/Records

6 11

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