November 2007 - Glasgow-haskell-users

First Call for Papers TFP 2008, The Netherlands
by Peter Achten 23 Nov '07

23 Nov '07

CALL FOR PAPERS TRENDS IN FUNCTIONAL PROGRAMMING 2008 RADBOUD UNIVERSITY NIJMEGEN, THE NETHERLANDS MAY 26-28, 2008 INVITED SPEAKER: PROF. HENK BARENDREGT http://www.st.cs.ru.nl/AFP_TFP_2008/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts and full papers. A formal post-symposium refereeing process selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2008 is hosted by the Radboud University Nijmegen, The Netherlands, and will be held in the rural setting of Center Parcs “Het Heijderbos”, Heijen (in the vicinity of Nijmegen), The Netherlands. TFP 2008 is co-located with the 6th Int’l. Summer School on Advanced Functional Programming (AFP’08), which is held immediately before TFP’08. SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research: leading-edge, previously unpublished research. Position: on what new trends should or should not be. Project: descriptions of recently started new projects. Evaluation: what lessons can be drawn from a finished project. Overview: summarizing work with respect to a trendy subject. Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Contributions on the following subject areas are particularly welcomed: * Dependently Typed Functional Programming * Validation and Verification of Functional Programs * Debugging for Functional Languages * Functional Programming and Security * Functional Programming and Mobility * Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications * Functional Languages for Telecommunications Applications * Functional Languages for Embedded Systems * Functional Programming Applied to Global Computing * Functional GRIDs * Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) * Interoperability with Imperative Programming Languages * Novel Memory Management Techniques * Parallel/Concurrent Functional Languages * Program Transformation Techniques * Empirical Performance Studies * Abstract/Virtual Machines and Compilers for Functional Languages * New Implementation Strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2008 program chairs, Peter Achten and Pieter Koopman, at afp_tfp_2008(a)cs.ru.nl. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of full papers (15 pages) and extended abstracts (3 pages) by the program committee. TFP encourages PhD students to submit papers. PhD students may request the program committee to provide extensive feedback on their full papers at the time of submission. Full papers describing work accepted for presentation must be completed before the symposium for publication in the draft proceedings and on-line. Further details can be found at the TFP 2008 website http://www.st.cs.ru.nl/AFP_TFP_2008/. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. IMPORTANT DATES (ALL 2008) Paper Submission: March 3 Notification of Acceptance: March 31 Early Registration Deadline: April 14 Late Registration Deadline: May 5 Camera Ready Symposium: May 5 TFP Symposium: May 26-28 Post Symposium Paper Submission: June 20 Notification of Acceptance: September 7 Camera Ready Revised Paper: September 21 PROGRAMME COMMITTEE Peter Achten (co-chair) Radboud Univ. Nijmegen, NL Andrew Butterfield Trinity College, IE Manuel Chakravarty Univ. of New South Wales, AU John Clements Cal Poly State Univ., USA Matthias Felleisen Northeastern Univ., USA Jurriaan Hage Utrecht Univ., NL Michael Hanus Christian-Albrechts Univ. zu Kiel, DE Ralf Hinze Univ. of Oxford, UK Graham Hutton Univ. of Nottingham, UK Johan Jeuring Utrecht Univ., NL Pieter Koopman (co-chair) Radboud Univ. Nijmegen, NL Shriram Krishnamurthi Brown Univ., USA Hans-Wolfgang Loidl Ludwig-Maximilians Univ.München, DE Rita Loogen Philipps-Univ. Marburg, DE Greg Michaelson Heriot-Watt Univ., UK Marco T. Morazán (symp. chair) Seton Hall Univ., USA Sven-Bodo Scholz Univ. of Hertfordshire, UK Ulrik Schultz Univ. of Southern Denmark, DK Clara Segura Univ. Complutense de Madrid, ES Olin Shivers Northeastern Univ., USA Phil Trinder Heriot-Watt Univ., UK Varmo Vene Univ. of Tartu, EE Viktória Zsók Eötvös Loránd Univ., HU ORGANIZATION Symposium Chair: Marco T. Morazán, Seton Hall University, USA Programme Chair: Peter Achten, Pieter Koopman, Radboud University Nijmegen, NL Treasurer: Greg Michaelson, Heriot-Watt University, UK

1 0

You can now register a trac user for yourself
by Ian Lynagh 22 Nov '07

22 Nov '07

Hi all, It is now possible to register a new user account for yourself on the GHC trac. To do so, make sure you are logged out and then click the "register" link at the top-right, or go to this URL: http://hackage.haskell.org/trac/ghc/register Making your own account preferred over using the guest account, as it means we know who to contact if we have a query about a bug report you make, e.g. if we are unable to reproduce it. Thanks Ian

4 4

Windows overlapped IO
by Felix Martini 22 Nov '07

22 Nov '07

I have made a prototype for overlapped IO that works with a modified version of Takano Akio's SSC library. I have been trying to add it to GHC's IO implementation but there are some issues. Instead of file descriptors windows handles are needed. The GHC handle implementation is currently based around fd's and many functions would need a separate windows API version. In some cases there is no simple conversion of existing functionality like the binary/text modes. An additional complication is that Haskell handles can be a lot of things other than files. Finally, a threaded rts is needed for the worker pool that processes the IO completions, so the current single threaded IO support must also remain. So for now i am focusing on testing and improving the prototype with a separate IO library. Best regards, Felix

2 2

ghci changing 'm' to 'g'
by Greg Fitzgerald 22 Nov '07

22 Nov '07

Running 6.8.1 on Windows XP, typing 'main' while ":r" is still processing causes the 'm' in 'main' to morph to a 'g'. > :r [1 of 2] Compiling Language.QidlTypeLibrary.Parser ( Language/QidlTypeLibrary/Parser.hs, interpreted ) Ok, modules loaded: Main, Language.QidlTypeLibrary.Parser. > main <interactive>:1:0: Not in scope: `gain' Thanks, Greg

6 8

[Fwd: Re: suggestion: add a .ehs file type]
by Richard Giraud 22 Nov '07

22 Nov '07

A pre-processor is a great idea. Template Haskell and Cabal make it possible to extend the language by adding all kinds of funky pre-processing (via Cabal hooks) and compile-time calculations. It wouldn't be too difficult to add a package-specific .ehs file type with the desired behavior. I'm currently using this combo to work around the TH limitation of not being able to generate import statements. A Cabal hook looks in a directory to find what .hs files are present, spits out an intermediate file that imports all of these files, and Cabal compiles the generated file into the final program. I think that the biggest limitation of this setup is managing the files if multiple stages of pre-processing are performed. Richard -------- Original Message -------- Subject: Re: suggestion: add a .ehs file type Date: Thu, 22 Nov 2007 10:19:57 +0000 From: Lennart Augustsson <lennart(a)augustsson.net> To: Simon Marlow <simonmarhaskell(a)gmail.com> CC: Alex Jacobson <alex(a)alexjacobson.com>, glasgow-haskell-users(a)haskell.org References: <47434E64.1070206(a)alexjacobson.com> <200711202239.57672.g9ks157k(a)acme.softbase.org> <474354D4.7010307(a)alexjacobson.com> <4743F6B4.9050505(a)gmail.com> <47447B2B.8090206(a)alexjacobson.com> <47454879.8040003(a)gmail.com> Or use a preprocessor that inserts a LANGUAGE pragma. :) On Nov 22, 2007 9:14 AM, Simon Marlow <simonmarhaskell(a)gmail.com <mailto:simonmarhaskell@gmail.com>> wrote: Alex Jacobson wrote: > In any case, I'm pretty sure the correct answer is not 50 language > pragmas with arbitrary spellings for various language features at the > top of each source file. You probably won't like any of these, but there are many ways to avoid writing out all the pragmas at the top of each file. 1. Use Cabal's extensions field. 2. Use CPP MyExtensions.h : {-# LANGUAGE TemplateHaskell, FlexibleInstances, OverlappingInstances, UndecidableInstances, CPP, ScopedTypeVariables, PatternSignatures, GADTs, PolymorphicComponents, FlexibleContexts, MultiParamTypeClasses, DeriveDataTypeable, PatternGuards #-} MyModule.hs: {-# LANGUAGE CPP #-} #include "MyExtensions.h" 3. Use a shell alias alias ghce='ghc -XTemplateHaskell -XFlexibleInstances ...' 4. use a script wrapper for GHC #!/bin/sh exec ghc -XTemplateHaskell -XFlexibleInstances ... $* I'm sure there are more... Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

if-them_else
by Serge D. Mechveliani 21 Nov '07

21 Nov '07

Dear GHC developers, when compiling the function f x = if x them False else True ghc-8.8.1 reports: " parse error on input `else' ". When there is a large expession after `them', it is sometimes difficult to locate a typo. Why does not it report " parsing if-then-else: cannot find `then' " ? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 3

GHC 6.8.1 and HDirect
by Fernand 21 Nov '07

21 Nov '07

Hi dear fellow ghc users, I simply wanted to let people know that I apparently succeeded in compiling a patched version of HDirect with GHC 6.8.1 (with typelibs support). At least, I could compile some of the examples and had very simple test programs launch/connect to Word and Excel using automation. I lack time to really clean up the library (I did not made any Cabal patch and currently directly link with the « .a » and « .o » of the various modules), but feel free to contact me if you need some help to use hdirect with GHC 6.8.1. Sincerely yours, sL

1 0

ghc 6.8.1 windows link issue ?
by Fernand 21 Nov '07

21 Nov '07

Dear all, Giving a try to GHC 6.8.1 under Windows, I stumble upon the following issue (yes, I'm struggling with HDirect), which did not occur with the 6.6 version : the linking phase of my project fails with $ C:/ghc/ghc-6.8.1/bin/ghc -o ihc.exe -fglasgow-exts -static -fvia-C -Rghc-timing -Wall -recomp AbsHUtils.o AbstractH.o Attribute.o Bag.o [... lots of files, among which we have CoreUtils.o ...] CoreUtils.o(.text+0x15066):ghc2436_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' CoreUtils.o(.text+0x150b0):ghc2436_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' CoreUtils.o(.text+0x1ac23):ghc2436_0.hc: undefined reference to `__stginit_containerszm0zi1zi0zi0_DataziGraph_' IDLUtils.o(.text+0x6026):ghc768_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' IDLUtils.o(.text+0x6070):ghc768_0.hc: undefined reference to `containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure' IDLUtils.o(.text+0xc607):ghc768_0.hc: undefined reference to `__stginit_containerszm0zi1zi0zi0_DataziGraph_' collect2: ld returned 1 exit status Indeed, that symbol is undefined in the CoreUtils file : $ nm CoreUtils.o | grep strongl U _containerszm0zi1zi0zi0_DataziGraph_stronglyConnComp_closure As far as I understand, this is a reference to the Data.Graph function stronglyConnComp (which can be seen in the « containers-0.1.0.0/Data/Graph.hi » interface file ; according to the haddock documentation of GHC, that function is indeed in the Data.Graph module, which is imported by the CoreUtils.lhs file). What is strange to me is that $ nm libHSghc.a | grep strongl gives : 00000598 D _ghczm6zi8zi1_Digraph_stronglyConnComp_closure which could explain why that function is not found. May be I'm looking at the wrong file, I don't know much of the linking and name-mangling process at hand here (Digraph vs. DataziGraph ?). What I do not understand is what causes that issue, which seems to only concern the Data.Graph module so far. Hopes this makes sense to you, Sincerely yours, Samuel

2 3

Re: [Haskell] recursive deriving
by Duncan Coutts 21 Nov '07

21 Nov '07

On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote: > When you want automated deriving of show/read etc., you need all the > components of your type also to be instances of show/read but you won't > want to *require* them to be automatically generated verions. > > Standalone deriving does the wrong thing here. Standalone deriving > should not cause an overlapping instance error if someone derives an > instance manually. Instead, the manually derived instance should be > treated as more specific and win out. > > The other part of this problem is that you can't do automatic recursive > deriving and this results in a ridiculous amount of boilerplate. I know > some people have a theory that they want to avoid accidentally creating > instances for things that shouldn't have them, but the solution to that > is probably to add some declaration for types that prohibits automatic > deriving for those types. The 99% case is that automatic deriving is ok. > > Proposed syntax: > > derive instance Show T recursively > data T = T no-deriving (Ord,Eq) I would expect that if the data constructor for T is not exported then standalone deriving should not work. However this appears not to be the case which breaks module abstraction. Foo.hs: module Foo ( T, t ) where data T = T t = T Bar.hs: import Foo deriving instance Eq T $ ghci Bar.hs -XStandaloneDeriving [1 of 2] Compiling Bar ( Bar.hs, interpreted ) [2 of 2] Compiling Main ( Baz.hs, interpreted ) Ok, modules loaded: Bar, Main. *Main> t == t True You could write that Eq instance by hand since they do not have access to the T constructor, then StandaloneDeriving should not be able to so either. I think it's a design flaw in standalone deriving. Does anyone else agree? Should we file a bug report? Duncan

3 2

Exposed module still hidden, why?
by Greg Fitzgerald 20 Nov '07

20 Nov '07

Using GHC 6.8.1 on Windows XP, after having used ghc-pkg to expose ' directory-1.0.0.0', I am getting an error when I build haddock that says the package is hidden. When I type "ghc-pkg list", the package is not in parenthesis. Typing "ghc -v" says that it is using the file from "C:\ghc\ghc-6.8.1\package.conf". That package.conf file has the 'exposed' set to True for that file. Why does GHC still think the package is hidden? ...\haddock-0.8>runhaskell Setup.lhs configure Configuring haddock-0.8... ...\haddock-0.8>runhaskell Setup.lhs build Preprocessing executables for haddock-0.8... shift/reduce conflicts: 5 Building haddock-0.8... src/Main.hs:49:7: Could not find module `System.Directory': it is a member of package directory-1.0.0.0, which is hidden ...\haddock-0.8>ghc-pkg list C:/ghc/ghc-6.8.1\package.conf: Cabal-1.2.2.0, HUnit-1.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Win32-2.1.0.0, array-0.1.0.0, base-3.0.0.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.0, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.1), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.1, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, xhtml-3000.0.2.1 Thanks, Greg

4 3