- Glasgow-haskell-users

Choosing implementation depending on class instances using rewriting rules
by Milan Straka 04 Jun '09

04 Jun '09

Hi, I am interesting in writing a method nub in such a way, that it will use O(N^2) trivial algorithm for types with equality only, and O(N log N) algorithm for comparable types. I would like to say class Nub where nub :: [a] -> [a] instance Ord a => Nub a where nub = nubOrd instance Eq a => Nub a where nub = nubEq which is of course not valid Haskell. I tried using GHC rewriting rules to achieve this. My first try was {-# NOINLINE nub #-} nub :: Eq a => [a] -> [a] nub xs = ... nubOrd :: Ord a => [a] -> [a] nubOrd xs = ... {-# RULES "nub/nubOrd" nub = nubOrd #-} which does not work either, because of missing an Ord a context. I was not able to write the rule which would fire. Is there a way to write such a rewriting rule or there is no way of acquiring the Ord dictionary in rewrite rule? Or does anyone know any other way of implementing such a nub without explicitly listing all Ord instances? I wish you a nice day, Milan Straka PS: Listing {-# RULES "nub/nubOrd Int" nub = nubOrd :: [Int]->[Int] #-} for all Ord instances would work, but ...

4 3

Problem with profiling
by Marco Túlio Gontijo e Silva 03 Jun '09

03 Jun '09

Hello, recently there was a thread about a problem in profiling in gtk2hs-users, and it was menitoned that this could be a GHC6 bug. The problem is described in http://sourceforge.net/mailarchive/forum.php?thread_name=1242762143.18742.2… . Do you think this is a gtk2hs specific problem, or is it something about GHC? Greetings. -- marcot http://marcot.iaaeee.org/

3 3

ghc - force library search order
by John Lask 02 Jun '09

02 Jun '09

----- Original Message ----- From: "Duncan Coutts" <duncan.coutts(a)worc.ox.ac.uk> To: "John Lask" <jvlask(a)hotmail.com> Sent: Friday, May 29, 2009 8:09 PM Subject: Re: [Haskell-cafe] ghc - force library search order > On Fri, 2009-05-29 at 18:08 +1000, John Lask wrote: >> I need to force a library to be searched for unresolved symbols after all >> other libraries have been searched, and I would rather not resort to >> constructing the linker command line directly. Is there a way to do this? >> >> i.e. I want for example -lfoo to appear after all other haskell libraries >> and before system libraries (for example -lmsvcrt) once ghc has >> constructed >> the link command. i.e. how is it possible to coerce ghc into respecting >> dependencies between the libraries. GHC does a good job in general with >> native libraries, but there are allways corner cases. >> >> I have a feeling this is not possible, but it dosn't hurt to ask. > > If you don't get a reply then ask on the ghc users mailing list. > > Duncan > >

2 3

IFL 2009 - 2nd Call for papers
by Jost Berthold 01 Jun '09

01 Jun '09

Apologies for multiple copies. Jost Berthold Call for Papers IFL 2009 Seton Hall University SOUTH ORANGE, NJ, USA http://tltc.shu.edu/blogs/projects/IFL2009/ ** NEW ** Accomodations information available: http://tltc.shu.edu/blogs/projects/IFL2009/accommodations.html Jane Street Capital has joined IFL 2009 as a sponsor ********* The 21st International Symposium on Implementation and Application of Functional Languages, IFL 2009, will be held for the first time in the USA. The hosting institution is Seton Hall University in South Orange, NJ, USA and the symposium dates are September 23-25, 2009. It is our goal to make IFL a regular event held in the USA and in Europe. The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2009 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2009 will use a post-symposium review process to produce a formal proceedings which will be published by Springer in the Lecture Notes in Computer Science series. All participants in IFL 2009 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. These submissions will be screened by the program committee chair to make sure they are within the scope of IFL and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full arcticle for the formal review process. These revised submissions will be reviewed by the program committee using prevailing academic standards to select the best articles that will appear in the formal proceedings. TOPICS IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools. If you are not sure if your work is appropriate for IFL 2009, please contact the PC chair at ifl2009(a)shu.edu. Topics of interest include, but are not limited to: language concepts type checking contracts compilation techniques staged compilation runtime function specialization runtime code generation partial evaluation (abstract) interpretation generic programming techniques automatic program generation array processing concurrent/parallel programming concurrent/parallel program execution functional programming and embedded systems functional programming and web applications functional programming and security novel memory management techniques runtime profiling and performance measurements debugging and tracing virtual/abstract machine architectures validation and verification of functional programs tools and programming techniques FP in Education PAPER SUBMISSIONS Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series format and not exceed 16 pages. The draft proceedings will appear as a technical report of the Department of Mathematics and Computer Science of Seton Hall University. IMPORTANT DATES Registration deadline August 15, 2009 Presentation submission deadline August 15, 2009 IFL 2009 Symposium September 23-25, 2009 Submission for review process deadline November 1, 2009 Notification Accept/Reject December 22, 2009 Camera ready version February 1, 2010 PROGRAM COMMITTEE Peter Achten University of Nijmegen, The Netherlands Jost Berthold Philipps-Universität Marburg, Germany Andrew Butterfield University of Dublin, Ireland Robby Findler Northwestern University, USA Kathleen Fisher AT&T Research, USA Cormac Flanagan University of California at Santa Cruz, USA Matthew Flatt University of Utah, USA Matthew Fluet Toyota Technological Institute at Chicago, USA Daniel Friedman Indiana University, USA Andy Gill University of Kansas, USA Clemens Grelck University of Amsterdam/Hertfordshire, The Netherlands/UK Jurriaan Hage Utrecht University, The Netherlands Ralf Hinze Oxford University, UK Paul Hudak Yale University, USA John Hughes Chalmers University of Technology, Sweden Patricia Johann University of Strathclyde, UK Yukiyoshi Kameyama University of Tsukuba, Japan Marco T. Morazán (Chair) Seton Hall University, USA Rex Page University of Oklahoma, USA Fernando Rubio Universidad Complutense de Madrid, Spain Sven-Bodo Scholz University of Hertfordshire, UK Manuel Serrano INRIA Sophia-Antipolis, France Chung-chieh Shan Rutgers University, USA David Walker Princeton University, USA Viktória Zsók Eötvös Loránd University, Hungary PETER LANDIN PRIZE The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 euros.

1 0

mtl and network packages in GHC 6.10.3.*
by Neil Mitchell 30 May '09

30 May '09

Hi, I just downloaded the Windows snapshot of 6.10.3.20090526, and found that mtl and network don't seem to be included. $ ghc-pkg list c:/ghc/ghc-6.10.3.20090526\package.conf: Cabal-1.6.0.1, Cabal-1.6.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.3, extensible-exceptions-0.1.1.0, filepath-1.1.0.2, (ghc-6.10.3.20090526), ghc-prim-0.1.0.0, haddock-2.4.2, haskell98-1.0.1.0, hpc-0.5.0.3, integer-0.1.0.1, old-locale-1.0.0.1, old-time-1.0.0.2, packedstring-0.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4 In addition, I can't install network under Cygwin, Mingw, or the Windows command line. Here are the errors from Cygwin: Preprocessing library network-2.2.1.2... In file included from Network\BSD.hsc:17: include/HsNet.h:78:22: sys/uio.h: No such file or directory include/HsNet.h:81:25: sys/socket.h: No such file or directory include/HsNet.h:84:26: netinet/tcp.h: No such file or directory include/HsNet.h:87:25: netinet/in.h: No such file or directory include/HsNet.h:90:21: sys/un.h: No such file or directory include/HsNet.h:93:24: arpa/inet.h: No such file or directory include/HsNet.h:96:19: netdb.h: No such file or directory In file included from Network\BSD.hsc:17: include/HsNet.h:138: error: syntax error before "addr" include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:146: error: storage size of 'a' isn't known include/HsNet.h:147: error: `addr' undeclared (first use in this function) include/HsNet.h:147: error: (Each undeclared identifier is reported only once include/HsNet.h:147: error: for each function it appears in.) include/HsNet.h:148: warning: return makes pointer from integer without a cast Network\BSD.hsc: In function `main': Network\BSD.hsc:145: error: invalid application of `sizeof' to incomplete type ` servent' And Mingw: * Missing header file: HsNet.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 And Windows command line: Resolving dependencies... Configuring network-2.2.1.2... cabal: Error: some packages failed to install: network-2.2.1.2 failed during the configure step. The exception was: sh: runProcess: does not exist (No such file or directory) Was removal of these packages on the stable branch was an oversight? Could network at the very least be reinstated soon? I'd love to report back whether the GHC 6.10.4 fixes work or not in practice. Thanks Neil

6 7

draft proposal for relative paths in installed package descriptions
by Duncan Coutts 29 May '09

29 May '09

All, This is a draft proposal for a common mechanism for implementing relative paths in installed package descriptions. Comments and feedback are welcome. I'm cc'ing this to the cabal and ghc-users lists but let's keep the discussion on the libraries list. There has been some discussion of this issue on the cabal and ghc-users list, but it's a relatively long thread and the idea has evolved somewhat so this is an attempt to present the proposal clearly. Proposal ======== This proposal is an extension to the Cabal spec section 3 http://haskell.org/cabal/proposal/x272.html Motivation ---------- Being able to have relative paths in the installed package description is useful as it makes it possible to construct relocatable (prefix-independent) package installations. This is useful when distributing compilers along with packages and there may be other uses. This proposal does not require that all paths are relative. It is still perfectly ok to use absolute paths where appropriate. It just adds an option to use relative paths. The aim is for a single simple specification that any compiler can implement and have the tools work uniformly, rather than ad-hoc implementations for each compiler. Details ------- In the installed package description, we will allow paths that begin with the variables ${pkgroot} or ${pkgrooturl}. For example: library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 They may only appear at the beginning of the paths and must be followed by a directory separator (platform-dependent '/' or '\'). This is because the vars refer to a directory so it does not make sense to construct extensions like ${pkgroot}blah. The use of '{}' is required and is to avoid any ambiguity (especially since the string "$pkgrooturl" is otherwise an extension of "$pkgroot"). Directly relative file paths like "blah" or "./blah" are not allowed. Fields containing paths must be absolute or begin with ${pkgroot}. Field containing urls must be absolute or begin with ${pkgrooturl}. The var ${pkgroot} is to be interpreted as the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is the usual system-dependent filepath syntax, e.g. windows: c:\ghc\ghc-6.12.1 unix: /opt/ghc-6.12.1 The var ${pkgrooturl} is to be interpreted as a url representation of the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is as a valid file url including the file:// prefix e.g. windows: file:///c:/ghc/ghc-6.12.1 unix: file:///opt/ghc-6.12.1 This is similar to how relative paths in .cabal files are interpreted relative to the directory containing the .cabal file, however in this case we mark relative paths more explicitly using a variable. So in the original example library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 If we assume this installed package description is at c:\ghc\ghc-6.12.1 \package.conf on windows or /opt/ghc-6.12.1/package.conf on unix then the compiler and other tools would interpret these as library-dirs: c:\ghc\ghc-6.12.1/foo-1.0 haddock-html: file:///c:/ghc/ghc-6.12.1/doc/foo-1.0 or on unix: library-dirs: /opt/ghc-6.12.1/foo-1.0 haddock-html: file:///opt/ghc-6.12.1/doc/foo-1.0 Tools ----- Tools which process the installed package description format will be expected to interpret these relative paths. This requires that they can discover the path for the ${pkgroot}. How they discover this is dependent on the Haskell implementation. Some implementations use separate files for each installed package description, some embed them in library package files, some use databases of installed package descriptions. Haskell implementations should provide a mechanism to discover the path for an installed package description. Duncan

1 0

Re: haddock-2.3.0 literate comments discarded from .lhs input
by Duncan Coutts 29 May '09

29 May '09

On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote: > Andrea, > > 2009/3/19 Andrea Vezzosi <sanzhiyan(a)gmail.com>: > > It turns out that those variables are there to allow relocation, in > > fact $topdir is expanded by > > Distribution.Simple.GHC.getInstalledPackages, it seems that > > $httptopdir has been overlooked. > > I'd be tempted to say that it's ghc-pkg dump/describe responsibility > > to expand those vars instead, like it does for ghc-pkg field. > > Do you (or anyone else) intend to work on this? If not, I'd like to > fix it, but I'll need some guidance. Like, is > Distribution.Simple.GHC.getInstalledPackages where the variable > expansion code should go, or should it be somewhere else? I don't think we should be hacking around this in Cabal without any discussion with the ghc folks on what is supposed to be there, what variables are allowed. We need a clear spec on what variables tools are expected to handle and how they are to be interpreted. The output of ghc-pkg describe/dump is not just for ghc to define and play around with. It's supposed to be defined by the Cabal spec. Supporting relocatable sets of packages is a good idea. We should aim to have something that is usable by each compiler, not just ghc, so interpreting paths relative to ghc's libdir doesn't seem ideal. How about this: a way to specify paths in the package registration info that are relative to the location of the package db they are in. That makes sense beyond just ghc and even with would allow other sets of relocatable packages, not just those installed with ghc. Then perhaps as a compat hack we should get Cabal to handle older ghc versions that do use these funny vars. Duncan

2 9

Unqualified names for -ddump-splices?
by Daniel Schüssler 29 May '09

29 May '09

Hi! is it possible to look at spliced code without fully qualified names? (And maybe with simple integer indices for newNames). Currently it can be pretty hard to decipher sometimes :) Greetings, Daniel

2 1

Re: can't run Grapefruit
by Peter Gavin 28 May '09

28 May '09

On Sat, May 23, 2009 at 3:58 PM, Dean Herington <heringtonlacey(a)mindspring.com> wrote: > GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m + Graphics.UI.Grapefruit.Circuit > Prelude Graphics.UI.Grapefruit.Circuit> :m + Graphics.UI.Grapefruit.GTK > Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK> :m + > Examples.Grapefruit.Simple > Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK > Examples.Grapefruit.Simple> run GTK mainCircuit > Loading package syb ... linking ... done. > Loading package base-3.0.3.0 ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package containers-0.2.0.0 ... linking ... done. > Loading package bytestring-0.9.1.4 ... linking ... done. > Loading package old-locale-1.0.0.1 ... linking ... done. > Loading package old-time-1.0.0.1 ... linking ... done. > Loading package random-1.0.0.1 ... linking ... done. > Loading package Win32-2.2.0.0 ... linking ... done. > Loading package filepath-1.1.0.1 ... linking ... done. > Loading package directory-1.0.0.2 ... linking ... done. > Loading package process-1.0.1.0 ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package glib-0.10.0 ... can't load .so/.DLL for: intl (addDLL: could > not load DLL) Hi Dean, First, you should try using the newest version of the installer (0.10.1, it requires GHC 6.10.3). Second, you should check whether intl.dll exists in c:\gtk2hs\0.10.x\bin, and that c:\gtk2hs\0.10.x\bin is also in your PATH. If you're still having problems, please paste the contents of c:\gtk2hs\0.10.x\lib\gtk2hs\{gtk,glib}.package.conf. Please also make sure the libraries listed in the extra-libraries field and extra-ghci-libraries field exist in c:\gtk2hs\0.10.x\lib and c:\gtk2hs\0.10.x\bin respectively. Pete

1 0

Lazy computation being repeated?
by Tyson Whitehead 28 May '09

28 May '09

I have a program that seems to me to be exhibiting strange behaviour. Basically, it looks like something somewhere is not being updated, and this is resulting in (very expensive) computation being repeated. The program in question goes like so. The results from the expensive calculation are stored in this structure data Cache = Cache { cacheBits0 :: UArr Float, cacheBits1 :: UArr Float } and computed by this function (which takes several gigs of RAM) cacheIndex :: ... -> Cache cacheIndex ... = ... The main program is main = catch prog error where prog = do ... let !cache = cacheIndex ... ... run cache ... ... The run function reads an input line from stdin and calls effectChange to performs the indicated calculation run cache ... = loop where loop = do ... case effectChange ... cache of ... ... loop The effectChange function is calculates the change in an auto correlation. It is made much cheaper (order too fast to notice) through the use of a the one time computations stored in cacheBits0 and cacheBits1 (order several seconds). Whether cacheBits1 is used or not depends on the input, while cacheBits0 is always used because I used lengthU cacheBits0 [the fast one from UArr] to get the length of both of them. The first line of input causes a several second delay and lots of memory to be allocated (the cacheBits are being computed). Repeated lines of input respond very quickly and the memory stays mostly constant, unless cacheBits1 is used, in which case there is always a delay of several seconds and big jumps in memory allocation. The only thing I can think of that each time effectsChange is being run and it is uses cacheBits1, it causes it value to be recomputed. Indeed, the delay and big memory jumps go away if I change all references of cacheBits1 to cacheBits0 in effectsChange or make the data fields strict like so data Cache = Cache { cacheBits0 :: !(UArr Float), cacheBits1 :: !(UArr Float) } Does this make sense? Am I missing some reason why this should be the expected behaviour for this program? Thanks! -Tyson

3 2