June 2005 - Haskell-Cafe

matrix computations based on the GSL
by Alberto Ruiz 21 Apr '06

21 Apr '06

Hello all! This is my first message to the list. In my work I often need linear algebra algorithms and other numeric computations. An option is using scientific computing systems like Matlab, Mathematica, Maple, etc. In Haskell there are several modules and bindings to matrix libraries; many of them are excellent. But I think that Haskell would be even more attractive if the basic matrix computations (what we find, for example, in the GNU Octave Quick Reference) were easily available in a standard library. We have all we need: an interactive environment, excellent graphics (HOpenGL), FFI and ForeignPtr with automatic garbage collection, QuickCheck, etc. Computations can be implemented by the GSL (GNU Scientific Library), a well designed numerical library written in C. Well... I know that I am trying to reinvent the wheel: I am working on a user friendly functional interface to matrix computations based on the GSL. I think that many numeric problems that can be solved using Octave or a similar system can be also solved more elegantly using Haskell. The library is very preliminary and incomplete but some simple problems can already be solved. The sources, haddock documentation and the draft of a tutorial can be found at: http://dis.um.es/~alberto/hmatrix/matrix.html I am not a Haskell expert, I only use the most basic programming techniques, so any suggestion will be greatly appreciated... Alberto

22 97

How to debug GHC
by Monique Louise de Barros Monteiro 10 Sep '05

10 Sep '05

Hi, all, I'm developing a back end for GHC and I have the following problem: my program is throwing an "empty list exception" due to head [] and I need to compile GHC with -prof -auto-all in order to see the stack trace when running it with +RTS -xc -RTS. I changed the makefile but the option +RTS -xc -RTS was not recognized as an available RTS option Does anyone have any idea about how I can do that ? Thanks in advance, __________________________________________________ Monique Louise Monteiro Mestranda em Ciencia da Computacao Centro de Informatica - CIn - UFPE

14 21

RE: [Haskell-cafe] Re: [Haskell] ANNOUNCE: GHC survey results
by Simon Peyton-Jones 06 Jul '05

06 Jul '05

| If anything I would like to see the Haskell community produce a Haskell | front end which was compiler neutral. That would facilitate many | interesting projects, and that might even help with the need to support | new extensions as they come along. There are already some candidates | floating around, but it seems they are not widely adopted. Well, "ghc -c -fext-core Foo.hs" is a Haskell front end that produces System F code ("External Core"), in a file Foo.hcr. I'm not sure whether that was what you meant. However, External Core doesn't seem to have really caught on. Only 5% said it was essential, with another 16% saying "nice to have". I'm sure there's room to improve the ExtCore route. Simon

6 5

Cabal with Alex and and Happy
by Brian Smith 06 Jul '05

06 Jul '05

Is there an example of how to build a Cabal package that has a lexer generated with Alex and a parser generated with Happy? As far as I can tell, the way to do this is to add "Other-Modules: Module.Name.Of.Parser.y Module.Name.Of.Lexer.x" to each executable/library stanza. But, when I try this, I get: Could not find module `GHC.Exts': it is a member of package base-1.0, which is hidden The generated parser code contains: #if __GLASGOW_HASKELL__ >= 503 import GHC.Exts #else import GlaExts #endif Also, I don't see any way of passing options to preprocessors using Cabal. In particular, how do you pass options to Happy? I am using GHC and Cabal from the CVS head, built about two weeks ago. Thanks, Brian

4 4

can't build module with ffi 'wrapper' by cabal (or ghc): unknown symbol
by Evgeny Chukreev 06 Jul '05

06 Jul '05

Hello! http://toril.ru/hmhash/hmhash-0.1.tar.bz2 ###### ./Setup.hs clean; ./Setup.hs configure; ./Setup.hs build -v5 Configuring HMhash-0.1... configure: searching for ghc in path. configure: found ghc at /usr/bin/ghc configure: looking for package tool: ghc-pkg near compiler in /usr/bin/ghc configure: found package tool in /usr/bin/ghc-pkg configure: Using install prefix: /usr/local configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4 configure: Using package tool: /usr/bin/ghc-pkg configure: Using haddock: /usr/bin/haddock configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: Using cpphs: /usr/bin/cpphs configure: Reading installed packages... configure: Dependency base-any: using base-1.0 Preprocessing library HMhash-0.1... /usr/bin/hsc2hs -osrc/Codec/Mhash.hs src/Codec/Mhash.hsc Building HMhash-0.1... /usr/bin/ghc -package-name HMhash -odir dist/build/src -hidir dist/build/src --make -isrc -ffi -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fallow-incoherent-instances -Wall -O0 -package base-1.0 Codec.Mhash -v Glasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC version 6.2.2 Using package config file: /usr/lib/ghc-6.4/package.conf Using package config file: /home/akshaal/.ghc/i386-linux-6.4/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Codec.Mhash Stable modules: *** Compiling Codec.Mhash ( src/Codec/Mhash.hs, interpreted ): compile: input file src/Codec/Mhash.hs *** Checking old interface for Codec.Mhash: Compiling Codec.Mhash ( src/Codec/Mhash.hs, dist/build/src/Codec/Mhash.o ) *** Parser: *** Renamer/typechecker: <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' *** Desugar: Result size = 6135 *** Simplify: Result size = 6847 Result size = 5654 Result size = 5564 *** Tidy Core: Result size = 5564 *** CorePrep: Result size = 6911 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** C Compiler gcc src/Codec/Mhash_stub.c -o /tmp/ghc29101.s -DDONT_WANT_WIN32_DLL_SUPPORT -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=604 -ffloat-store -I src/Codec -I /usr/lib/ghc-6.4/include Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-8) /usr/lib/gcc-lib/i486-linux/3.3.5/cc1 -quiet -v -I src/Codec -I /usr/lib/ghc-6.4/include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5 -DDONT_WANT_WIN32_DLL_SUPPORT -D__GLASGOW_HASKELL__=604 src/Codec/Mhash_stub.c -quiet -dumpbase Mhash_stub.c -auxbase-strip /tmp/ghc29101.s -O -Wimplicit -version -ffloat-store -o /tmp/ghc29101.s GNU C version 3.3.5 (Debian 1:3.3.5-8) (i486-linux) compiled by GNU C version 3.3.5 (Debian 1:3.3.5-8). GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95593 ignoring nonexistent directory "/usr/i486-linux/include" #include "..." search starts here: #include <...> search starts here: src/Codec /usr/lib/ghc-6.4/include /usr/local/include /usr/lib/gcc-lib/i486-linux/3.3.5/include /usr/include End of search list. *** Assembler gcc -Isrc/Codec -c /tmp/ghc29101.s -o dist/build/src/Mhash_stub.o *** Assembler gcc -Isrc/Codec -c /tmp/ghc29100.s -o dist/build/src/Codec/Mhash.o *** Deleting temp files Deleting: /tmp/ghc29101.s /tmp/ghc29100.s Upsweep completely successful. *** Deleting temp files Deleting: link(batch): upsweep (partially) failed OR Main.main not exported; not linking. *** Deleting temp files Deleting: /usr/bin/ar qv dist/build/libHSHMhash-0.1.a dist/build/src/Codec/Mhash.o /usr/bin/ar: creating dist/build/libHSHMhash-0.1.a a - dist/build/src/Codec/Mhash.o ###### ./Setup.hs install Installing: /usr/local/lib/HMhash-0.1 & /usr/local/bin HMhash-0.1... Registering HMhash-0.1... Reading package info from ".installed-pkg-config" done. building GHCi library /usr/local/lib/HMhash-0.1/HSHMhash-0.1.o... done. Saving old package config file... done. Writing new package config file... done. ###### ghci -package HMhash ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Loading package HMhash-0.1 ... linking ... ghc-6.4: /usr/local/lib/HMhash-0.1/HSHMhash-0.1.o: unknown symbol `CodecziMhash_d7Ew' ghc-6.4: unable to load package `HMhash-0.1' ------------------ I know how to fix it by hands: rm dist/build/libHSHMhash-0.1.a /usr/bin/ar qv dist/build/libHSHMhash-0.1.a dist/build/src/Codec/Mhash.o dist/build/src/Mhash_stub.o But, how to do it with cabal? -- ... WBR, Evgeny Chukreev ...

3 3

haskell parser for java bytecode?
by Kimberley Burchett 03 Jul '05

03 Jul '05

I'm interested in using haskell to do static analysis of java bytecode. To my surprise, I wasn't able to find any existing haskell libraries for parsing java .class files. Is anyone aware of such a library? I've already started writing my own implementation, which I intend to make available as a reusable library once it's ready, but if someone else has already done the work then I'd love to avoid having to repeat it. Kimberley Burchett http://www.kimbly.com/

4 4

RE: ANNOUNCE: GHC survey results
by Simon Marlow 01 Jul '05

01 Jul '05

On 28 June 2005 14:11, Bulat Ziganshin wrote: > Tuesday, June 28, 2005, 1:58:13 PM, you wrote: > >> http://www.haskell.org/ghc/survey2005-summary.html >> There's a lot to take in, but it's an interesting read. Enjoy! > > thank you all, processing all the 600 answers was not easy work :) > > i have several comments regarding results of this survey: > > 1) GHCi compiles to bytecode several times faster than GHC makes > unoptimized compilation. can unoptimized GHC compilation just create > bytecode (as Ocaml does)? Do you really mean "several times faster"? My impression is that it's a few percent faster, if at all. Some measurements would be good. We've thought about compiling to persistent byte code in the past, but the gains never seemed to be worth the effort: we'd need a byte-code serialiser and loader. > 2) is your plans to support x86-64 platform includes Windows (and all > other sorts of Unix), or it's for Linux only? Definitely Windows too. I hear the cygwin/mingw tools are still unstable on Windows x64, though. > 3) many users complaining about non-compatibility between GHC > versions. if they mean library interfaces changes then how about using > Pesco's library versioning scheme? (see > http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) I've read that article, and I think it's an interesting idea. I can't disagree with the arguments put forward, but somehow, the cure seems a bit painful. Cheers, Simon

4 3

RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
by Ralf Lammel 30 Jun '05

30 Jun '05

> > But note that "same functionality" is one thing, > > having "separate compilation" and "program extensibility" too > > is another one. > > As I said, and as is well-known, "extensibility" is a red herring in > this context - you merely trade one dimension of extensibility for > another one. I am not going to fight for extensibility. It's just that I believe that there is a value in a direct correspondence as opposed to a transcription. I cite from the OOHaskell abstract: "The [...] code [...] demonstrates that OO code translates into OOHaskell in an intuition-preserving way: essentially expression-by-expression, without requiring global transformations." I would like to add a peer-reviewed clear reference to the OOHaskell paper about the red herring that you mention. I don't have such a reference. May I kindly ask you to offer a few for selection? Thanks, Ralf

4 4

Re: haskell parser for java bytecode?
by Kimberley Burchett 30 Jun '05

30 Jun '05

Jerzy Karczmarczuk asked: > > Why for goodness' sake, people interested in Haskell *should* worry > about parsing of Java bytecode chunks? Are you asking why I'm interested in bytecode instead of source code, or are you asking why I'm interested in Java at all? One answer to the first question is: because java bytecode is a simpler problem domain than java source. For example, name resolution is trivial when working with bytecode (there's no ambiguity between package/class/variable names, inherited names are already resolved, overloaded functions are already resolved, etc). Also, many of the newer features of java disappear at the bytecode level: inner classes, generics, the new foreach statement, etc. Another answer to the first question is: because java bytecode can be used as a target for several languages these days, and by working with it directly, I can work with any language that compiles to the jvm, rather than restricting myself just to java. The answer to the second question is: because the rest of the world matters to some people. Kimberley Burchett http://www.kimbly.com/

4 4

Unicode.hs (was: RE: Re[2]: ANNOUNCE: GHC survey results)
by Dimitry Golubovsky 30 Jun '05

30 Jun '05

Hi, Vadim Konovalov wrote: === that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC? === Clarifying on Unicode stuff in GHC I contributed: It is in CVS now, and I believe will be in 6.4.1 At least it shows up at: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/GHC/Unicod… (MAIN branch) But this module is just an interface to another module, WCsubst.c: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/WCsu… which in turn was produced from UnicodeData.txt (? I believe this is correct name of the file from www.unicode.org) by the shell script: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/ubco… This API handles simple case conversions (Char -> Char), and categorization of characters according to what is in the UnicodeData.txt file. Before (i. e. up to and including 6.4), Unicode stuff was handled through wc* locale based functions for wide chars conversion. Since not every installation of Unix (or some other OS) has this set up properly (mine was not: personal itch), this code was proposed for GHC and finally made it there. Hope this explains everything. In fact, Unicode.hs itself is not completely mine ;) PS: Autrijus (the guy who develops Pugs) included those files on his own because 6.4 was just out, and Unicode stuff was not there yet. -- Dimitry Golubovsky Anywhere on the Web

1 0