January 2011 - Haskell-Cafe

getting fulling qualified names of types from hint/ghc api
by Pasqualino "Titto" Assini 19 Jan '11

19 Jan '11

Hi, I am using hint's Language.Haskell.Interpreter.typeOf function to dynamically get the type of a haskell expression but, unfortunately for my purposes, I see that it returns unqualified names (I see in Hint.Conversions that it uses the GHC function GHC.getPrintUnqual). Is there any function in the GHC api or any other simple way of getting the fully qualified types? Surprisingly, I could not find any. Thanks, titto -- Dr. Pasqualino "Titto" Assini http://quid2.org/

1 0

Building Haskell Platform on PowerPC?
by Tim Chevalier 18 Jan '11

18 Jan '11

Hello, For reference, I'm wondering whether there's an easier way to build the current version of the Haskell Platform on a PowerPC Mac running Mac OS 10.5.8 than the way in which I documented at: http://tim.dreamwidth.org/1715938.html I was installing the platform from scratch as a favor for a colleague who didn't have any version of GHC installed on his machine, and I just couldn't find a simpler way than installing two other versions of GHC first. Just curious if anyone has done it. I realize PPC is unsupported. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings

1 0

Merging SMT solving and programming languages: two EDSLs for SMT in Haskell
by Don Stewart 18 Jan '11

18 Jan '11

Hey all, For a while now, Galois has been interested in connecting automated solvers to our programming language of choice, Haskell, to make it possible to prove automatically some properties of our functions (rather than just testing, e.g. with QuickCheck). We've pushed two efforts out this week, as previews of what we're thinking in this space: * SBV; and http://hackage.haskell.org/package/sbv * yices-painless. http://hackage.haskell.org/package/yices-painless Both are embedded DSLs for representing propositions to an SMT solver via Haskell functions and values. They take different approaches (a compiler from Haskell to the SMT-LIB format, versus an interpreter for the Yices SMT solver). SBV is the more mature package, while yices-painless emphasizes a type-preserving translation from a minimal core language. SBV was built by Levent Erkok, yices-painless by Don Stewart. Documentation for the design of yices-painless is available, as is documentation on SBV. Both are ready for experimentation and feedback, and we welcome your comments. More information is on the blog: http://corp.galois.com/blog/2011/1/18/merging-smt-solvers-and-programming-l… -- Don

1 0

H98, OOHaskell - getting started with objects in Haskell
by gutti 18 Jan '11

18 Jan '11

Hi, I wanted to check whether Haskell offers reasonably easy object oriented programming -- I already had a look into "Haskell's overlooked object system" und "A Gentle Introduction to Haskell 98" [H98] There are a few things where I could use advice with: 1. OOHaskell doesn't seem to be available in the HackageDB (cabal) -- so how do I install it especially on Debian ? 2. is OOHaskell the right way to go - is it standardised (H98) or is it extension and is it widely used and recommended ? 3. Haskell 98 offers datatypes and some sort of monadic classes -- is it possible to build simple objects without OOHaskell ? 4. When I want object properties to change, when should I use IORef when STRef ? Thanks in advance, Phil -- View this message in context: http://haskell.1045720.n5.nabble.com/H98-OOHaskell-getting-started-with-obj… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

10 15

ANN: extcore 1.0
by Tim Chevalier 18 Jan '11

18 Jan '11

Hello, I've recently released version 1.0 of extcore, a library for processing code in GHC's text-based External Core format. extcore includes a parser, prettyprinter, typechecker, and interpreter for External Core, as well as modules for computing module dependencies and combining multiple Core modules into a single module. The library was originally written by Andrew Tolmach and was part of the GHC distribution. After becoming its maintainer, about a year ago I moved the library to Hackage. Since in the past year, the library has acquired some users but has received no fatal bug reports, I thought it was time for a 1.0 release. You might be interested in using this library if you're a compiler or tool writer who wants to write a tool that processes the output of GHC's front-end and simplifier -- that is, code in the Core intermediate language, a typed functional language in which many of Haskell's features have been desugared into a polymorphically typed lambda-calculus (extended with type coercions, as are necessary to support type system features such as GADTs). Such tools might include alternative back-ends or new program transformations. Using the extcore library allows tool writers to experiment with implementing new compiler features without modifying GHC itself. While the GHC API is also a route to adding new stages to the GHC pipeline, using extcore has the advantage that External Core is well-specified (read on) and less subject to change than GHC's internal Core format. The library has been tested on External Core produced by GHC 6.10.* and GHC 6.12.*. It has not yet been tested on External Core produced by GHC 7.*. Documentation for the External Core format itself lives at http://www.haskell.org/ghc/docs/latest/html/ext-core/core.pdf - but documentation for the library is limited, and I would welcome documentation or other patches. Currently the best source of documentation for the library is the README file, found in the distribution. To get the distribution, please visit http://hackage.haskell.org/package/extcore or cabal install extcore. Please direct replies to glasgow-haskell-users(a)haskell.org, with me CCed. Please make sure not to reply to haskell(a)haskell.org. Cheers, Tim Chevalier -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -- E.E. Cummings

2 3

Re: [Haskell-cafe] HDBC, postgresql, bytestrings and embedded NULLs
by John Lato 18 Jan '11

18 Jan '11

> > From: Michael Snoyman <michael(a)snoyman.com> > > > I took a quick look at the enumerators library, but it doesn't seem to > have > > the necessary support for handling data that comes from arbitrary C API > > function calls rather than handles or sockets. > > It does support this, for prior art see yaml[1] or yajl-enumerator[2]. > I'd be happy to help you with this, as having some enumerator > experience is a big help here. > This is one of the things that iteratee supports rather better than enumerator, IMHO. See "enumFromCallback"[1]. But if you want this style of code with database access, why not try Takusen? John L. [1] http://hackage.haskell.org/packages/archive/iteratee/0.6.0.1/doc/html/Data-…

2 1

Re: [Haskell-cafe] Mailing lists on projects.haskell.org
by John Lato 18 Jan '11

18 Jan '11

> > Message: 10 > Date: Tue, 18 Jan 2011 09:53:42 +1100 > From: Erik de Castro Lopo <mle+hs(a)mega-nerd.com <mle%2Bhs(a)mega-nerd.com>> > Subject: Re: [Haskell-cafe] Mailing lists on projects.haskell.org? > To: haskell-cafe(a)haskell.org > Cc: haskell(a)haskell.org > Message-ID: <20110118095342.89b92b21.mle+hs(a)mega-nerd.com<20110118095342.89b92b21.mle%2Bhs(a)mega-nerd.com> > > > Content-Type: text/plain; charset=US-ASCII > > Erik de Castro Lopo wrote: > > > Hi all, > > > > I tried sending mail to the haskell-llvm mailing list (xxxx AT > > projects.haskell.org) several days ago and today I received a bounce > > message. > > > > Looking into the issue a little further, I find that DNS has no MX > > record for projects.haskell.org and projects.haskell.org doesn't > > seem to be listening on port 25. > > > > I would email the administrator, but that is also an @projects.h.o > > address and I doubt it would get through. > > > > Posting here in the hope that someone who sees this can fix it. > > > Anyone? > > There is still no mx record and still nothing listening on port 25. > In case anyone was replying off-list, could you please cc me as well? I believe this is the cause of problems with the iteratee list (which Maciej just mentioned) as well. Although the problem does seem intermittent. John

4 3

Template Haskell a Permanent solution?
by Jonathan Geddes 18 Jan '11

18 Jan '11

Cafe, First let me say that Template Haskell is very powerful and a lot of great work has been done in this area. It fills in a number of holes in Haskell's feature set. But TH gives me the same feeling as other language features that have been described as "bolted on." Also, TH is both library and built-in syntax (via an extension) which feels strange to me. Finally, It's very complicated to do some simple things. I see TH used most for the following tasks: #1 Parse a string at compile-time so that a custom syntax for representing data can be used. At the extreme, this "data" might even be an EDSL. #2 Provide instances automatically. I would propose that more specialized features be implemented to accomplish these tasks. To start, I'll throw out some ideas that provide these capabilities. For TH use #1, compile-time parsing of arbitrary strings, I think it would be nice for quasiquote semantics to be modified so that code like > json :: String -> JsonObject > json = ... > > data = [ json | > { "name" : "Jonathan" > , "favorite language": "Haskell" > } >|] causes the function json to be called at compile time with a string argument of " {\"name\" : \"Jonathan\"\n , \"favorite language\": \"Haskell\"\n }". The whole expression being then replaced with the result of the function application. What I like about this is that defining "quasiquoters" is trivial. They're just functions of the form String -> a. Many such quasiquoters already exist and would be ready for use! I imagine certain rules would apply, ie a quasiquoter must be defined prior to use and in a separate module, etc. For TH use #2, automatic instances, I would propose a way of declaring that a class can be automatically derived, and therefore added to the set [Eq, Ord, Show, Read, ... , etc]. This is the set of classes that can be put in the "deriving" clause of a type declaration. I don't know exactly what the syntax for this would look like, but I imagine it would look a bit like the various current implementations of automatic instances in TH. Again, TH is very powerful, and fills in a number of holes in Haskell's feature set. But it leaves me wondering if these holes should not be filled in by other, more specialized features, leaving TH to continue to find other holes to fill. I'm wondering if others see TH as a permanent solution, or if you agree with me that some of TH's most common usages should have more specialized features dedicated to them. It may very well be that I am simply not experienced enough with TH to fully appreciate and embrace it. By the way, did I miss any uses of TH as common as the ones I mentioned? --Jonathan

9 16

multiple instances or contexts?
by John Lato 18 Jan '11

18 Jan '11

Hello, This post is (hopefully) literate Haskell. I recently noticed that there are two ways to specify instances in a common situation. Suppose I have something like this: > {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, NoMonomorphismRestriction, OverlappingInstances #-} > > data A = A > data B = B > data C = C > > newtype Repr a = Repr { unRepr :: State MyState a } > > class SomeClass a b where > If I want to make instances of SomeClass for Repr, A and Repr, B, I have two choices: > instance SomeClass Repr A where > instance SomeClass Repr B where > or I can introduce a new class and make an instance with a context, > class RClass c where > > instance RClass A where > instance RClass B where > -- no C instance for RClass > > instance RClass x => SomeClass Repr x is there any reason to prefer one form over the other? Of course the first requires more instance declarations, but they're auto-generated so that doesn't bother me. Thanks, John L.

1 0

HDBC, postgresql, bytestrings and embedded NULLs
by Iustin Pop 17 Jan '11

17 Jan '11

Hi all, It seems that (at least) the postgresql bindings do not allow pure binary data. I have a simple table: debug=# create table test (name bytea); byteas seems to be the backing type on the DB side for bytestrings. and then I run this: import Database.HDBC.PostgreSQL import Database.HDBC import Data.ByteString main = do db <- connectPostgreSQL "dbname=debug" stmt <- prepare db "INSERT INTO test (name) VALUES($1)" execute stmt [toSql $ pack [0]] execute stmt [toSql $ pack [65, 0, 66]] commit db What happens is that the inserted string is cut-off at the first NULL value: the first row is empty, and the second row contains just "A". http://www.postgresql.org/docs/8.4/static/datatype-binary.html says: “When entering bytea values, octets of certain values must be escaped (but all octet values can be escaped) when used as part of a string literal in an SQL statement. In general, to escape an octet, convert it into its three-digit octal value and precede it by two backslashes”, and continues to list that NULL should be quoted as E'\\000'. However, I find no such quoting in the HDCB.Postgresql sources. Anyone else stumbled on this? thanks, iustin

4 11