January 2009 - Haskell-Cafe

"Standard C" available in cabal package
by Maurício 30 Jan '09

30 Jan '09

Hi, I see that cabal allows me to say: c-sources: (...) and then have a few C files built with my program. I see that I can have lines like #include <some usual C header> in those files, and that makes me think that, even if I add no C files to my .cabal, I still can count on what would be standard C functions available, and that I could use them with Foreign, like, say: foreign import ccall "memcpy" :: Ptr a -> Ptr a -> CSize -> IO Ptr a Am I right to guess that? If so, what would be the available set of functions? I imagined standard C (C99?), but searching around I see that there are a few different stabdard C libraries, like, for instance, glibc, which seems to be used in Linux, and a few others. Supposed I wanted to write a module with all C functions always available, what could I let be there? Thanks, Maurício

3 4

Fwd: [Haskell-cafe] HPC and literate haskell
by Pavel Perikov 30 Jan '09

30 Jan '09

> No I do not process it using lhs2tex. I just compile literate haskell code. The necessity of preprocessing kills the entire idea of having literate source. I just feed lhs files to ghc and everything works fine except code coverage. > > > On 30.01.2009, at 5:35, Robin Green wrote: > >> Have you tried processing the file with lhs2tex first, to unlit it? >> (Or >> is that what you are doing? It's unclear from your email.) >> -- >> Robin

1 0

Re: Haskell on ARM (was Re: ANN: Topkata)
by Jeremy Apthorp 30 Jan '09

30 Jan '09

2008/6/25 Braden Shepherdson <Braden.Shepherdson(a)gmail.com>: > Jeremy Shaw wrote: >> >> If any does attempt to build for the ARM, please, please, please, >> document what you do in the wiki. And, if you do, edit the wiki as you >> go, you definitely won't be able to remember what you did after the >> fact. (Or, at the very least, use some program to capture everything >> you do so that you can refer to it later). >> >> And, finally, I heard vague rumors a while ago that made me think that >> GHC 6.10 might have a pure ANSI-C backend? Is there any truth to this? >> That would make porting much easier if it meant you did not have to do >> steps 1-4. >> >> j. >> ps. I would be happy to try to answer any questions if someone tries a >> port. I would still like to run GHC on my 770, and I hope to own an >> iPhone if they fix a few ommisions (bluetooth keyboard support, and >> similar stuff). >> > > > I recently acquired the ARM-based Nokia N810 (and <3 it), powered by Maemo. > Running a uname -a on it: > > Linux Nokia-N810-42-19 2.6.21-omap1 #2 Fri Nov 16 16:24:58 EET 2007 armv6l > unknown > > I would love a working GHC implementation on it, if for nothing else than > how awesome it would be. Whether that means using a C back-end or native > compilation doesn't matter to me so much. > > I might be one to attempt this, as I know C and ARM-ish asm decently well > and have a powerful desktop to compile on. I have no familiarity > with GHC internals, though. Lastly, I won't have anything like the time to > attempt this seriously until mid-September or so. Oops, forgot to Cc the list. Next year I'll be working on a project for my undergraduate computing course at UNSW that will involve getting GHC to target the Nintendo DS. It'll require cross-compilation, because the DS isn't powerful enough to actually run GHC (4M main ram and a 66MHz processor). It'll also require that I significantly strip down the runtime system, as the current RTS won't fit in 4M and leave any left over for the main application. I'll be documenting the whole process, but I won't be starting until next year... Jeremy

11 15

experience with SmallCheck
by Sebastian Fischer 30 Jan '09

30 Jan '09

Today I played with SmallCheck. Interested in what happened when I tried to find a small unsatisfiable boolean formula that is not easily detected as such? Watch my attempts: <http://www-ps.informatik.uni-kiel.de/~sebf/haskell/unsatisfiable-formula-th… > (strip `.html` suffix for executable Haskell file) Cheers, Sebastian

1 0

The case of the missing Arrow function
by Henk-Jan van Tuyl 30 Jan '09

30 Jan '09

L.S., The function 'liftA2' is mentioned in many documents about Arrows; yet I cannot find it in the Control.Arrow module, as it comes with GHC 6.10.1 and Hugs Sep 2006. Is there a special reason for this? -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ --

3 2

ANNOUNCE: Extensible and Modular Generics for the Masses: emgm-0.2
by Sean Leather 30 Jan '09

30 Jan '09

============================================== Extensible and Modular Generics for the Masses ============================================== Extensible and Modular Generics for the Masses (EMGM) is a library for generic programming in Haskell using type classes and a sum-of-products view. ------------ Introduction ------------ emgm-0.2 is the second major release of the EMGM library. A lot of work has been done since the initial release to build a solid set of functions that will allow you to derive the necessary declarations for using EMGM with your datatype. Thus, you don't have to write much code to get started. A great deal of documentation has also been added. There's a comprehensive new entry page for Generics.EMGM that should help one figure out what to do with this library. We plan to publish articles providing more examples as well. With these two improvements, you have no more excuses for not trying it out. Download EMGM and see what you can do, generically! ------------ New Features ------------ Improvements over emgm-0.1 include: * Derive type representation using Template Haskell [1] * Major improvement in documentation with Haddock * bimap function [2] [1] Here is a snippet from the documentation that shows what you save when using TH over manual implementation. > {-# LANGUAGE TemplateHaskell #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE OverlappingInstances #-} > {-# LANGUAGE UndecidableInstances #-} > module Example where > import Generics.EMGM > data T a = C a Int > $(derive ''T) The $(derive ''T) declaration in the above example generates the following code: 1. Constructor description declarations (1 per constructor) > conC :: ConDescr > conC = ConDescr "C" 2 [] Nonfix 2. Embedding-projection pair declarations (1 per type) > epT :: EP (T a) (a :*: Int) > epT = EP fromT toT > where fromT (C v1 v2) = v1 :*: v2 > toT (v1 :*: v2) = C v1 v2 3. Rep instance (1 per type) > instance (Generic g, Rep g a, Rep g Int) => Rep g (T a) where > rep = rtype epT (rcon conC (rprod rep rep)) 4. Higher arity instances if applicable (either FRep, FRep2, and FRep3 together, or BiFRep2) > instance (Generic g) => FRep g T where > frep ra = rtype epT (rcon conC (rprod ra rint)) In this case, similar instances would be generated for FRep2 and FRep3. 5. Function-specific instances (1 per type) > instance Rep (Collect Char) Char where > rep = Collect (:[]) [2] EMGM has a new function bimap and its related representation type class BiFRep2: > bimap :: (BiFRep2 Map f) => (a -> c) -> (b -> d) -> f a b -> f c d With bimap, you can do the following in GHCi: *Generics.EMGM Data.Char Prelude> bimap ord chr ('a',65) (97,'A') *Generics.EMGM Data.Char Prelude> bimap (++" So Long!") (const 42) (Right "Earth") Right 42 ------------------- General Information ------------------- Visit the home page: http://www.cs.uu.nl/wiki/GenericProgramming/EMGM ---------------- General Features ---------------- The primary features of EMGM include: * Datatype-generic programming using sum-of-product views * Large collection of ready-to-use generic functions * Included support for standard datatypes: lists, Maybe, tuples * Easy to add support for new datatypes * Type classes make writing new functions straightforward in a structurally inductive style * Generic functions are extensible with ad-hoc cases for arbitrary datatypes * Good performance of generic functions The features of this distribution include: * The API is thoroughly documented with Haddock * Fully tested with QuickCheck and HUnit * Program coverage ensures that all useful code has been touched by tests * Tested on both Mac and Windows systems ------------ Requirements ------------ EMGM has the following requirements: * GHC 6.8.1 - It has been tested with versions 6.8.3 and 6.10.1 * Cabal library 1.2.1 - It has been tested with versions 1.2.4.0 and 1.6.0.1. ----------------- Download & Source ----------------- Use caball-install: cabal install emgm Get the package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm Check out the current source with Subversion: svn checkout https://svn.cs.uu.nl:12443/repos/dgp-haskell/EMGM/trunk Or view it online: https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/trunk/ -------- Examples -------- Check out the examples: https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/trunk/examples/ -------------- Bugs & Support -------------- Report issues or request features: http://code.google.com/p/emgm/issues/list Discuss EMGM with the authors, maintainers, and other interested persons: http://www.haskell.org/mailman/listinfo/generics ------- Credits ------- The research for EMGM originated with Ralf Hinze. It was extended with work by Bruno Oliveira and Andres Löh. More details of the library functionality were explored by Alexey Rodriguez. We are very grateful to all of these people for the foundation on which this library was built. The current authors and maintainers of EMGM are: * Sean Leather * José Pedro Magalhães * Alexey Rodriguez * Andres Löh

1 0

Re: [Haskell-cafe] C-like Haskell
by Duncan Coutts 30 Jan '09

30 Jan '09

On Wed, 2009-01-28 at 20:42 -0500, Ross Mellgren wrote: > Very possibly -- I'm on a mac so no prebuilt 64-bit binary. I'm not > good enough at reading core to tell, but I can tell from the core that > it's calling out to external C functions to do the 64-bit math. Right, that'll make it really slow but does not explain the allocations. > It could be that it's crossing over from machine register size to > managed heap object and so without additional help on 32-bit it wants > to allocate thunks. If it's using Int64 then there's no transition, that only happens with Integer (which is always heap allocated anyway). The sum parameter in the inner loop is an accumulating parameter that is not inspected until the final value is returned. In the case of the simple direct Int64 implementation the strictness analyser does notice that it really is strict so can be evaluated as we go along. I bet that's the source of the problem, that for the indirect Int64 impl used on 32bit machines the strictness analyser does not discover the same property. So that would explain the allocations. It's worth investigating the indirect Int64 implementation to see if this could be improved. > Does your core indicate that it's making a bunch of external __ccalls? No, it's all unboxed Int# types and primitive # operations. Lovely. In particular the inner loop is all unboxed types with no allocations. Duncan

3 2

WYSIWYG literate programming
by Massimiliano Gubinelli 30 Jan '09

30 Jan '09

Hi, I would like to "advertise" TeXmacs (http://www.texmacs.org/) to the Haskell comunity as a possible front-end for literate programming in Haskell (and GHCI interaction). TeXmacs is a system which allows the production of documents featuring high quality typesetting (comparable to TeX) and high level of customizability (a la Emacs). It does not rely on TeX for the typesetting (but can export to Latex, HTML, etc..). It is written in C++ (unfortunately not Haskell) and use Scheme as extension language (specifically Guile). It has been in use for at least 10 years and has plugins for many external applications like Pari, Axiom, Maxima, Octave, R, Yacas, etc... >From the webpage: "GNU TeXmacs is a free wysiwyw (what you see is what you want) editing platform with special features for scientists. The software aims to provide a unified and user friendly framework for editing structured documents with different types of content (text, graphics, mathematics, interactive content, etc.). The rendering engine uses high-quality typesetting algorithms so as to produce professionally looking documents, which can either be printed out or presented from a laptop." It would be nice to develop a pluging for GHC/GHCI to allow "direct" literate programming style with high-quality rendering. (If someone want to try before I find the time to do it myself.... ) Massimiliano -- View this message in context: http://www.nabble.com/WYSIWYG-literate-programming-tp21682184p21682184.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

7 12

haddock-2.3.0 error: file name does not match module name
by Alistair Bayley 30 Jan '09

30 Jan '09

I'm getting an error when I run setup haddock-2.3.0 on the Takusen src: haddock.exe: File name does not match module name: Saw: `Main' Expected: `Database.Enumerator' I assume that it's procesing file Database.Enumerator.lhs when it emits this, but I'm puzzled because the module name in Database.Enumerator.lhs is certainly Database.Enumerator, and not Main. Or am I looking in the wrong place? Alistair

3 4

databases in Haskell & type-safety
by Gour 30 Jan '09

30 Jan '09

Hi! I'd like to use sqlite3 as application storage in my haskell project... Browsing the available database options in Haskell it seems that: a) HSQL is dead (hackage reports build-failure with 6.8 & 6.10) b) haskelldb is also not in a good shape - build fails with 6.8 & 6.10 For Haskell-newbie as myself, it looks that haskelldb is the one which provide(ed)s the most secure API (I was reading draft paper about MetaHDBC but, apparently, the type inference support in open-source databases is poor and that's why, according to the author "This is unfortunately as it makes MetaHDBC a lot less valuable." What remains is: c) Takusen which is also not up-to-date (it fails with 6.10) and d) HDBC and sqlite bindings which are the only packages which build with 6.10. However options in d) do not offer, afaik, type-safety which is emblem of Haskell language, so I wonder how much this could be the problem for real-world usage? So, considering that HDBC nicely abstracts API enabling one to easily switch from e.g. Sqlite3 to Postgres, and it is used as in example for database programming, it seems as logical (and the only) choice for Haskell database programming in a real-world? I'm not familiar with Takusen which says: "Takusen's unique selling point is safety and efficiency..." and I would appreciate if someone could shed some more light to its 'safety' and the present status? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

11 29