November 2003 - Haskell

a type question
by rui yang 27 Nov '03

27 Nov '03

Suppose I have a function: funcmap :: a->b->c can I use type synonyms to describe a new type like this: Type Funcmap = a->b>c ? it will give a syntax error message: syntax error in input (unexpected '->'), does anyone know how to define this Funcmap type? rui ---------------------------------------- This mail sent through www.mywaterloo.ca

3 3

How to best add logging/debugging code?
by Ben Escoto 26 Nov '03

26 Nov '03

Hi all, does anyone have any tips on how to insert debugging or logging statements through a program? Here are two possibilities: 1. Use some kind of logging monad. But then all your types become more complicated and it seems you have to use lots of ->'s and >>='s instead of ordinary function application. It seems this can make the code much less elegant. Also it seems that every time you want to add logging to a function, you have to change its type, and then change the type of all the functions that call it, etc. Should it really be this complicated? 2. Use unsafePerformIO or similar. But then your code is regularly defeating the type system, which presumably isn't good. Also the ghc manual has special instructions for compiling code that uses unsafePerformIO, intimating that it isn't used very often. It seems this must come up a lot when writing Haskell programs. What do most pople do? -- Ben Escoto

7 8

[JFPLC'04]First Call for Papers
by jfplc2004 25 Nov '03

25 Nov '03

--------------------------------------------------------------- Call for Papers -- JFPLC'2004 Thirteenth French Conference on Logic and Constraint Programming http://www.info.univ-angers.fr/jfplc2004/ Angers, France, June 21-23, 2004 --------------------------------------------------------------- The thirteenth French Conference on Logic and Constraint Programming of the AFPLC (http://www.afplc.org) JFPLC'2004 is co-localized with JNPC'04 (http://www.info.univ-angers.fr/jnpc2004/appelJNPC.html) JFPLC'2004 follows the series of previous meetings which took place in Amiens (2003), Nice (2002), Paris (2001), Marseille (2000), Lyon (1999), Nantes (1998), Orleans (1997), Clermont-Ferrand (1996), Dijon (1995), Bordeaux (1994), Nimes (1993) and Lille (1992). The aim of the meeting is to review recent research works on logic and constraint programming including theoretical aspects, applications, and teaching issues. --------------------------------------------------------------- Important dates (hard deadlines): Abstract February 22, 2004 Submission February 29, 2004 Acceptation April 5, 2004 Final Version April 18, 2004 The proceedings will be published by Hermes. Official conference languages are French and English. Papers may be submitted in English, but should be published in French if one of the authors speaks French fluently. Simultaneous submissions to JFPLC and JNPC is not allowed. Scope : Papers are welcome on all theoretical, experimental and pedagogical aspects of logic programming and/or constraint programming. Submissions : Authors are invited to send papers in PDF or Postscript format not exceeding 15 pages, formatted according to the Hermes style (see http://www.editions-hermes.fr/fr/cons_actes.html) Papers should contain original, previously unpublished results (neither in a conference nor in a journal). Accepted papers should be presented at the conference. Electronic submissions should be made before: - February 22, 2004 as a standard text email including the title, the authors, an abstract, its category (theory, application, pedagogy) - February 29, 2004 as a standard postscript or PDF file, together with the possibly updated data described above and send to Frederic.Mesnard(a)univ-reunion.fr. Please ensure that the subject of your email is [jfplc04]. ------------------------------------------------------------------- Program Chair: Fred Mesnard, IREMIA, universite de La Reunion Program Committee: Abder Aggoun, COSYTEC Roberto Bagnara, Universita degli Studi di Parma Pascal Brisset, ENAC Veronica Dahl, université Simon Fraser Pierre Deransart, INRIA Rocquencourt Yves Deville, université catholique de Louvain François Fages, INRIA Rocquencourt Carmen Gervet, IC Parc Isabelle Gnaedig, LORIA Arnaud Gotlieb, IRISA Jin-Kao Hao, université d'Angers Narendra Jussien, École des mines de Nantes François Laburthe, Bouygues Arnaud Lallouet, université d'Orléans Juliette Mattioli, Thales Eric Monfroy, université de Nantes Catuscia Palamidessi, INRIA Futurs Laurent Perron, ILOG Andreas Podelski, Max-Planck-Institut für Informatik Alexander Serebrenik, Katholieke Universiteit Leuven Christine Solnon, université de Lyon ---------------------------------------------------------------

1 0

ghc, FFI and autotools
by Lloyd Allison 25 Nov '03

25 Nov '03

We are trying to build and call some Haskell code in and from from the open-src spreadsheet "gn'meric". It seems that it could be a good basis for experiments in FP + SSs. We have worked through the simple FFI examples and can create small C+Haskell stand-alone programs. However, gnu'eric is quite a large program and autoconf|automake|...|libtools are used to build it. Consequently one does not have an entirely free hand to just compile and link the pieces in any old way. It has to fit in with the general build scheme. There is a general pattern to 'eric's "plugins": add a directory, e.g. ...../plugins/haskell/Makefile.am --->Mafilefile.in--->Makefile /functions.c -- the plugin's code /.... and we can make C-only plugins. The next step, or "impasse" to give it the technical name, is to add /functionsH.hs -- Haskell called from functions.c ? Please has anybody used ghc in this type of environment before, and ? have advice on the exercise in general or on ? creating a *shared library* from C + Haskell code in particular ? We[*] have tried a few things, so far with less than complete success, and often featuring undefined labels,-( e.g. E Unable to open module file "/home/lloyd/gnumeric/install//lib/gnumeric/1.2.1-bonobo/plugins/haskell/plugin.la". E /home/lloyd/gnumeric/install//lib/gnumeric/1.2.1-bonobo/plugins/haskell/plugin.so: undefined symbol: GHCziInt_I8zh_con_info Lloyd -- Lloyd ALLISON, CSSE, Monash University, Victoria, Australia 3800. web: http://www.csse.monash.edu.au/~lloyd/ tel: +61 3 9905 5205 use: http://www.linux.org/ OpenOffice: http://www.openoffice.org/ PS. [*] Not a royal we.

3 3

ANN: CMI 1.0.0 - a cross-module inliner for C - written in Haskell
by Alastair Reid 24 Nov '03

24 Nov '03

[The following GPLed program may be of interest to you if: - You want examples of programs written in Haskell that do something useful. - You sometimes hack C code as well as Haskell and want to make your code smaller, faster or better structured. - You want a library of code for parsing and manipulating C programs. -- Alastair Reid www.haskell-consulting.com ] The University of Utah's Flux Research Group announces the first release of CMI, our cross-module inliner for C. CMI is an optimizing frontend for gcc which allows gcc to inline across module (i.e., function) boundaries without requiring you to put inline functions in header files or even mark inline functions for inlining. Get CMI's open source code and docs at: http://www.cs.utah.edu/flux/knit/cmi.html CMI: o makes your code go faster; o is a preprocessor for gcc; o supports most gcc extensions and is able to deal with such notoriosly tricky code as the glibc header files; o works by merging multiple C files into one file, topologically sorting the definitions so that definitions come before uses, and marks functions as inline; o controls code-bloat by deleting dead code and inlining up until a user-specified budget is reached; o can use user-specified heuristics to select which functions to inline (we include a tool which uses gprof output to choose inlinings to illustrate this); CMI is part of an ongoing R&D effort. We seek feedback, external users, and collaborators whose experiences and insight will help evolve CMI. CMI is a small part of Knit, our C Components project. To join the knit-users or knit-announce mailing lists, send email to majordomo(a)flux.cs.utah.edu with, e.g., "subscribe knit-users" in the body. Thanks go to DARPA for their support, and thanks go to the entire Knit crew, but especially Alastair Reid, for the fine research, development, and hard work that led to this release. and Alastair says... Enjoy! Jay Lepreau, lepreau(a)cs.utah.edu Flux Research Group, School of Computing University of Utah

1 0

RE: ANNOUNCE: Haddock version 0.6
by Simon Marlow 24 Nov '03

24 Nov '03

> In article <SMARTHOSTmGviaeSdaQ0009caeb(a)SMARTHOST.microsoft.com>, > "Simon Marlow" <simonmar(a)microsoft.com> wrote: > > > There is a new release of Haddock, version 0.6. This > version has several > > improvements over the previous release; the full list is below. > > Excellent! I was stuck on implicit parameters for awhile. > > I found one issue in 0.6 though, it seems to choke on explicit kind > declarations, for instance: > > newtype Constant (m :: * -> *) a = MkConstant a deriving (Eq); Yup, I'm afraid that's another extension not supported by Haddock at the moment. Cheers, Simon

1 0

ICALP'04 - Call for Papers
by Petri Salmela 24 Nov '03

24 Nov '03

Printable pdf-version at: http://www.math.utu.fi/icalp04/icalp-call.pdf ___________________________________________________________________ CALL FOR PAPERS - ICALP'04 31st International Colloquium on Automata, Languages and Programming July 12-16, 2004, Turku, Finland http://www.math.utu.fi/icalp04/ ___________________________________________________________________ The 31st International Colloquium on Automata, Languages and Programming sponsored by the European Association of Theoretical Computer Science will take place in Turku, on July 12-16, 2004. It is organised at Turku University by the Department of Mathematics and Turku Centre for Computer Science. ICALP04 is colocated with the 19th International Conference on Logic in Computer Science (LICS04). Papers presenting original research on all aspects of theoretical computer science are sought. Typical but not exclusive topics of interest are: Track A: * Algorithmic aspects of parallel and distributed computing * Algorithms and data structures * Algorithms and models for large networks * Algorithms for computationally hard problems * Automata theory and formal languages * Bioinformatics * Computational complexity * Combinatorics and structures in Computer Science * Cryptography * Machine learning * Molecular computing, neural and evolutionary algorithms * Proof complexity * Quantum computing Track B: * Algebraic and categorical models * Applications of automata in logic * Concurrency, mobility and distributed systems * Databases, semi-structured data and finite model theory * Logics and their applications * Principles of programming languages * Program logics, formal methods and model checking * Security analysis and verification * Semantics of programming languages * Specification, refinement and verification * Type systems and typed calculi SUBMISSIONS: ************ Authors are invited to submit a paper of no more than 12 pages in LNCS-style, presenting original research on the theory of computer science. Submissions should indicate which track the paper is submitted to. No simultaneous submission to other conferences with published proceedings is allowed. Accepted papers will be published in the Lecture Notes in Computer Science by Springer. IMPORTANT DATES: **************** Workshop proposals: November 30, 2003 Submissions: February 8, 2004 Notification: March 31, 2004 Final version: April 27, 2004 CONFERENCE CHAIR: ***************** Juhani Karhumäki Department of Mathematics and Turku Centre for Computer Science University of Turku FIN-20014 Turku, Finland email: karhumak(a)cs.utu.fi INVITED SPEAKERS: ***************** Joint ICALP-LICS: R. Harper (Carnegie Mellon) A. Razborov (Princeton & Moscow) M. Yannakakis (Stanford) ICALP: P. Flajolet (INRIA) M. Henzinger (Google) M. Hofmann (Munich) W. Rytter (Warsaw & NJIT) PROGRAM COMMITTEE: ****************** Track A A. Atserias, Barcelona (ES) G. Brodal, Aarhus (DK) J. Cassaigne, Marseille (FR) J. Díaz, Barcelona (ES), chair R. Fleischer, Hong Kong (HK) H. Gabow, Boulder (US) L. Goldberg, Warwick (UK) J. Hromkovic, Aachen (DE) G. Italiano, Roma (IT) T. Jiang, Riverside (US) C. Kaklamanis, Patras (GR) J. Kari, Turku (FI) C. Moore, Santa Fe (US) P. Pudlak, Prague (CZ) P. Raghavan, Verity, Stanford (US) M. Santha, Paris (FR) B. Voecking, Dortmund (DE) G. Woeginger, Twente (NL) M. Yung, Columbia U. (US) Track B R.-J. Back, Turku (FI) P.-L. Curien, Paris (FR) A. Gordon, Microsoft, Cambridge (UK) S. Hayashi, Kobe (JP) T. Henzinger, Berkeley (US) M. Hofmann, Munich (DE) B. Jacobs, Nijmegen (NL) E. Moggi, Genova (IT) J. Parrow, Uppsala (SE) C. Palamidessi, University Park, Penn. (US) B. Pierce, Philadelphia (US) A. Rabinovich, Tel Aviv (IL) D. Sannella, Edinburg (UK), chair W. Thomas, Aachen (DE) I. Walukiewicz, Bordeaux (FR) ORGANIZING COMMITTEE: ********************* J. Karhumäki, Conference Chair T. Järvi, Co-chair (ICALP) L. Hella, Co-chair (LICS) V. Halava M. Hirvensalo I. Petre P. Sibelius T. Knuutila CONTACT ADDRESSES: **************** For further information see: http://www.math.utu.fi/icalp04/ or contact: icalp04(a)cs.utu.fi or karhumak(a)cs.utu.fi

1 0

ANNOUNCE: Chameleon version (03-11)
by Martin Sulzmann 24 Nov '03

24 Nov '03

We are pleased to announce Chameleon version 03-11. Latest version can be downloaded via http://www.comp.nus.edu.sg/~sulzmann/chameleon/ The current version is a substantial improvement over previous versions. New/Improved features include: * Compilation of Chameleon to (plain) Haskell. * Mixing Haskell and Chameleon overloading. * Updated Chameleon manual. The manual (http://www.comp.nus.edu.sg/~sulzmann/chameleon/download/haskell.html) contains lots more information and an extensive collection of examples. Martin Sulzmann (sulzmann(a)comp.nus.edu.sg) Jeremy Wazny (jeremyrw(a)students.cs.mu.OZ.AU)

1 0

ANNOUNCE: Haddock version 0.6
by Simon Marlow 23 Nov '03

23 Nov '03

There is a new release of Haddock, version 0.6. This version has several improvements over the previous release; the full list is below. Source and binary distributions can be obtained from Haddock's homepage: http://www.haskell.org/haddock/ Enjoy! Simon Changes in version 0.6: * Implicit parameters, zip comprehensions and 'mdo' are now supported by the parser. * Some lexical bugs were fixed, mainly concerning literal paragraphs next to non-literal paragraphs. * New options: --gen-index, --use-index, --gen-contents and --use-contents, for generting a combined index and contents for several libraries from the appropriate .haddock files. * There is now one index rather than separate Function/Constructor and Type/Class indices. Where a name refers to several entities, these are listed separately in the index. * New option: -v, elicits more verbose warnings. Some warnings are now turned off by default; Haddock should be a little less noisy in general. * Markup for definition lists has been added. See the documentation for details. * New option: --package for setting the package name. The package is listed alongside each module name in the combined contents. * Entities which are re-exported from another package now at least leave a hyperlink in the generated HTML, rather than nothing at all. * Some fixes for bugs which caused incorrect hyperlinks in the generated HTML. In particular, instances should now be linked correctly. * Some aesthetic improvements to the generated HTML.

4 4

lifting functions to tuples?
by Abraham Egnor 21 Nov '03

21 Nov '03

The classic way to write a lift function for tuples is, of course: liftTup f (a, b) = (f a, f b) which has a type of (a -> b) -> (a, a) -> (b, b). I've been wondering if it would be possible to write a function that doesn't require the types in the tuple to be the same, just that the types in the second tuple are the result of applying the type transformation implied in the function to be lifted to the types in the first tuple. Now, in Haskell98, this isn't possible because of the monomorphism restriction; however, ghc conveniently has a way to disable that. However, I'm still having problems figuring out if it's even doable within the current constraints of the glasgow-extended type system. One possibility I tried is: liftTup (f :: forall a b. a -> b) (p, q) = (f p, f q) which does, in fact, compile. A very odd type is inferred: liftTup :: forall b1 b a1 a. (forall a2 b2. a2 -> b2) -> (a, a1) -> (b, b1) I call this odd because there's no mention of the type dependencies inherent in the actual function. However, any attempt to apply it to a polymorphic function results in the following errors: random.hs:17: Could not deduce (Num b) from the context () arising from use of `inc' at random.hs:17 Probable fix: Add (Num b) to the expected type of an expression In the first argument of `liftTup', namely `inc' In the definition of `tupInc': tupInc = liftTup inc random.hs:17: Inferred type is less polymorphic than expected Quantified type variable `b' is unified with another quantified type variable `a' In the first argument of `liftTup', namely `inc' In the definition of `tupInc': tupInc = liftTup inc which seems to be a direct consequence of the odd derived type. However, I can't think of a way to write a better one. The problem, as far as I can tell, is that there's no way in the type system to deal in type transformations, i.e. apply the conversion implied by (a -> b) to a given type a' to produce the appropriate b'. Thoughts? Abe

6 9