From mads_lindstroem at yahoo.dk Mon Oct 1 13:21:24 2007 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Mon Oct 1 13:23:29 2007 Subject: [Haskell] Announce: AutoForms release 0.3 Message-ID: <1191259284.3945.5.camel@localhost.localdomain> Hi all I am happy to release version 0.3 of AutoForms. AutoForms is a library to ease the creation of Graphical User Interfaces. It does this by using generic programming to construct GUI components. The AutoForms user creates an ordinary algebraic data type (ADT), which should reflect the data model of an application. From this ADT AutoForms automatically constructs a GUI component, by using the structure and identifiers of the ADT. To facilitate this construction, AutoForms uses the "Scrap your boilerplate" approach to generic programming. What happened since release 0.2? * Moved website to http://www.haskell.org/haskellwiki/AutoForms * Closer integration with WxHaskell * Bug-fixes * Cabalized AutoForms * Handles sum-types. E.g. data Foo = Foo Int | Bar Int [Char] * Added a custom monadic interface to AutoForms * More examples * Layout managers * Plus many other changes See http://www.haskell.org/haskellwiki/AutoForms for more information. Greetings, Mads Lindstr?m From coreyoconnor at gmail.com Mon Oct 1 19:23:56 2007 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Mon Oct 1 19:22:56 2007 Subject: [Haskell] ANN: MacOSX - A library some Haskell users on OS X might find useful. Message-ID: I've been working on integrating haskell code with some Objective-C/C++ Cocoa Mac OS X applications. Nothing fancy like a Haskell/Cocoa bridge. Just trying to get the build process smooth. The default cabal build system was incomplete to do this effectively;* Extending XCode was no good either. With some effort I created some Cabal build hooks to fix up the behavior of build on OS X and add support for packaging an executable into a ".app" package. That's not much, but I packaged it up, plus some extras, into a library in case other projects would like to use it: http://tothepowerofdisco.com/repo/HaskellLibraries/ Of course, this is all hackish and very incomplete. EG: * No fat binary support. I only have a PPC Mac and the only fat-binary process usable with GHC I know of requires executing the x86 GHC. * The build hook in MacOSX.Build will only work on the Cabal distributed with GHC 6.6.1 and *completely* replaces the standard GHC build hook. * GHC compiled to use the framework version of GMP installed to /Library/Frameworks is required. * The name is vague... Still, I've used it to add haskell support and replace XCode for building for 3 exisitng Cocoa applications. Maybe somebody else will find it useful as well. -- -Corey O'Connor * I neglected to make a good list of why the default Cabal build hook doesn't work. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20071001/27244d0f/attachment.htm From garrigue at math.nagoya-u.ac.jp Mon Oct 1 21:08:53 2007 From: garrigue at math.nagoya-u.ac.jp (Jacques Garrigue) Date: Mon Oct 1 21:08:05 2007 Subject: [Haskell] [Last CFP] FLOPS 2008 Message-ID: <20071002.100853.39664899.garrigue@math.nagoya-u.ac.jp> [We apologize for the multiple postings of this announce] LAST CALL FOR PAPERS Ninth International Symposium on Functional and Logic Programming (FLOPS 2008) April 14-16, 2008 Ise, Japan Submission deadline: October 10, 2007 Keynotes: Peter Dybjer, Naoki Kobayashi, and Torsten Schaub http://www.math.nagoya-u.ac.jp/~garrigue/FLOPS2008/ FLOPS is a forum for research on all issues concerning declarative programming, including functional programming and logic programming, and aims to promote cross-fertilization and integration between the two paradigms. Previous FLOPS meetings were held in Fuji Susono (1995), Shonan Village (1996), Kyoto (1998), Tsukuba (1999), Tokyo (2001), Aizu (2002), Nara (2004), and Fuji Susono (2006). TOPICS FLOPS solicits original papers in all areas of functional and logic programming, including (but not limited to): Declarative Pearls: new and excellent declarative programs with illustrative applications; Language issues: language design and constructs, programming methodology, integration of paradigms, interfacing with other languages, type systems, constraints, concurrency and distributed computing; Foundations: logic and semantics, rewrite systems and narrowing, type theory, proof systems; Implementation issues: compilation techniques, memory management, program analysis and transformation, partial evaluation, parallelism; Applications: case studies, real-world applications, graphical user interfaces, Internet applications, XML, databases, formal methods and model checking. The proceedings are expected to be published as an LNCS volume. The proceedings of the previous meeting (FLOPS2006) were published as LNCS 3945. INVITED SPEAKERS Peter Dybjer (Chalmers, Sweden) Naoki Kobayashi (Tohoku, Japan) Torsten Schaub (Potsdam, Germany) PC CO-CHAIRS Jacques Garrigue (Nagoya, Japan) Manuel Hermenegildo (Madrid, Spain and New Mexico, USA) PC MEMBERS Maria Alpuente (Valencia, Spain) Sergio Antoy (Portland, OR, USA) Matthias Blume (TTI, Chicago, USA) Tyng-Ruey Chuang (Academia Sinica, Taiwan) Zhenjiang Hu (Tokyo, Japan) Oleg Kiselyov (FNMOC, Monterey, USA) Herbert Kuchen (Muenster, Germany) Dale Miller (INRIA, Palaiseau, France) Atsushi Ohori (Tohoku, Japan) Enrico Pontelli (New Mexico, USA) Kristoffer Rose (IBM Watson, USA) Kazunori Ueda (Waseda, Japan) Peter Van Roy (Louvain-la-Neuve, Belgium) Benjamin Werner (INRIA, Palaiseau, France) LOCAL CHAIR Shoji Yuen (Nagoya, Japan) SUBMISSION Submissions must be unpublished and not submitted for publication elsewhere. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. Submissions should fall into one of the following categories: Regular research papers: they should describe new results and will be judged on originality, correctness, and significance. System descriptions: they should contain a link to a working system and will be judged on originality, usefulness, and design. All submissions must be written in English and can be up to 15 proceedings pages long. Authors are strongly encouraged to use LaTeX2e and the Springer llncs class file, available at http://www.springer.de/comp/lncs/authors.html Regular research papers should be supported by proofs and/or experimental results. In case of lack of space, this supporting information should be made accessible otherwise (e.g., a link to a web page, or an appendix). Submission is Web-based. Please visit the conference site. IMPORTANT DATES Submission deadline: October 10, 2007 Author notification: December 21, 2007 Camera-ready copy: January 21, 2008 Conference: April 14-16, 2008 PLACE Ise, Japan Previous FLOPS: FLOPS 2006, Fuji Susono: http://hagi.is.s.u-tokyo.ac.jp/FLOPS2006/ FLOPS 2004, Nara: http://logic.cs.tsukuba.ac.jp/FLOPS2004/ FLOPS 2002, Aizu: http://www.ipl.t.u-tokyo.ac.jp/FLOPS2002/ FLOPS 2001, Tokyo: http://www.ueda.info.waseda.ac.jp/flops2001/ SPONSOR Japan Society for Software Science and Technology (JSSST) SIG-PPL IN COOPERATION with Asian Association for Foundation of Software (AAFS) Association for Logic Programming (ALP) ACM SIGPLAN (pending) INQUIRIES to From gvidal at dsic.upv.es Tue Oct 2 07:39:12 2007 From: gvidal at dsic.upv.es (German Vidal) Date: Tue Oct 2 07:38:11 2007 Subject: [Haskell] SAS 2008 Preliminary Call for Papers Message-ID: PLEASE POST --> SAS 2008 at the Technical University of Valencia We are happy to announce that SAS 2008, the Static Analysis Symposium, will take place at the Technical University of Valencia: Submission of abstract: January 12, 2008 Submission of full paper: January 19, 2008 Notification: March 7, 2008 Camera-ready version: April 5, 2008 Conference: July 16-18, 2008 Please see: http://www.dsic.upv.es/~sas2008/ Maria Alpuente, German Vidal (PC co-chairs) --------------------------------------------------------------------------- Call for papers Static Analysis Symposium - SAS 2008 16-18 July 2008, Valencia, Spain (co-located with LOPSTR 2008) url http://www.dsic.upv.es/~sas2008 email sas2008@dsic.upv.es Static Analysis is increasingly recognized as a fundamental tool for high performance implementations and verification of programming languages and systems. The series of Static Analysis Symposia has served as the primary venue for presentation of theoretical, practical, and application advances in the area. The technical programme for SAS 2008 will consist of invited lectures and presentations of refereed papers. Contributions are welcome on all aspects of static analysis, including, but not limited to: abstract domains abstract interpretation abstract testing compiler optimizations control flow analysis data flow analysis model checking program specialization security analysis theoretical analysis frameworks type based analysis verification systems Submissions can address any programming paradigm, including concurrent, constraint, functional, imperative, logic, and object-oriented programming. Survey papers, that present some aspect of the above topics from a new perspective, and application papers, that describe experience with industrial applications, are also welcome. Papers must describe original work, be written and presented in English, and must not substantially overlap with papers that have been published, or that are simultaneously submitted to a journal or a conference with refereed proceedings. Submitted papers should be at most 15 pages formatted in LNCS style (excluding bibliography and well-marked appendices not intended for publication). PC members are not required to read the appendices, and thus papers should be intelligible without them. The conference proceedings is planned to be published by Springer-Verlag in the Lecture Notes in Computer Science series. Invited Speakers Roberto Giacobazzi (Universita' degli Studi di Verona, Italy) Ben Liblit (University of Wisconsin-Madison, USA) PC co-chairs Maria Alpuente (Technical University of Valencia, Spain) German Vidal (Technical University of Valencia, Spain) PC members Elvira Albert (Complutense University of Madrid, Spain) Roberto Bagnara (University of Parma, Italy) Maurice Bruynooghe (Katholieke Universiteit Leuven, Belgium) Radhia Cousot (CNRS & Ecole Polytechnique, France) Javier Esparza (Technical University of Munchen, Germany) Sandro Etalle (University of Twente, The Netherlands) Moreno Falaschi (University of Siena, Italy) Stephen Fink (IBM T.J. Watson Research Center, USA) John Gallagher (Roskilde University, Denmark) Maria del Mar Gallardo (University of Malaga, Spain) Chris Hankin (Imperial College, UK) Manuel Hermenegildo (Technical University of Madrid, Spain) Julia Lawall (University of Copenhagen, Denmark) Alexey Loginov (IBM T.J. Watson Research Center, USA) Hanne Riis Nielson (Technical University of Denmark, Denmark) David Schmidt (Kansas State University, USA) Harald Sondergaard (University of Melbourne, Australia) Tachio Terauchi (Tohoku University, Japan) Ji Wang (National Laboratory for Parallel and Distributed Processing, China) Local chair Alicia Villanueva (Technical University of Valencia, Spain) Important dates Submission of abstract: January 12, 2008 Submission of full paper: January 19, 2008 Notification: March 7, 2008 Camera-ready version: April 5, 2008 Conference: July 16-18, 2008 --------------------------------------------------------------------------- From ganesh.narayan at gmail.com Wed Oct 3 20:02:31 2007 From: ganesh.narayan at gmail.com (Ganesh Narayan) Date: Wed Oct 3 20:08:40 2007 Subject: [Haskell] Haskell Applications - reg Message-ID: <4816a32d0710031702h68296a38icd4b51bffdd89ad2@mail.gmail.com> Hi List, I am planning a study on statistical properties of (static) call graphs for programs written in different languages; the idea is to compute a handful of "relevant" graph structural metrics and see what they have to say about the software/language. In this lieu, I am studying following languages - C, C++, Haskell, OCaml and hopefully Scheme and Java. I picked up a handful of Haskell applications from Haskell Apps repository [0] and computed the call graph for them [1]. But am not quite sure if the applications are representative; for one, the graphs are quantitatively distinct! In addition, this difference appears consistent across the Haskell applications I tried. Am not sure if its GHC compiler/runtime effect or Haskell effect though. Should the effects are artifact of disassembly, likely that OCaml graphs would have exhibited them too. Is there any particular application(s) that is quintessentially Haskell'sh that I could convince myself that my samples are representative?! I am fledging new to Haskell and would appreciate some pointers in picking up the "few, but ripe" ones. Hope it's fine. In case any list member is curious, I have got some preliminary plots hosted at http://agni.csa.iisc.ernet.in/nganesh/plots ; horizontal dividers represent language boundaries [top, bottom) and in/out/total stand for degrees. I have five Haskell applications enlisted: Yarrow, Frown, DrIFT, HaXml.{Validate/Extract}. Thanks -ganesh [0] http://www.haskell.org/haskellwiki/Applications_and_libraries; I picked up whatever I could compile. I am yet to get cabal running. [1] Am presently constructing the call graphs from disassembled application binaries; resultant graph includes ghc runtime library calls. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20071004/142ced67/attachment.htm From stefanor at cox.net Wed Oct 3 20:15:17 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Oct 3 20:14:39 2007 Subject: [Haskell] Haskell Applications - reg In-Reply-To: <4816a32d0710031702h68296a38icd4b51bffdd89ad2@mail.gmail.com> References: <4816a32d0710031702h68296a38icd4b51bffdd89ad2@mail.gmail.com> Message-ID: <20071004001517.GB3558@localhost.localdomain> On Thu, Oct 04, 2007 at 05:32:31AM +0530, Ganesh Narayan wrote: > [1] Am presently constructing the call graphs from disassembled application > binaries; resultant graph includes ghc runtime library calls. Not necessary a good idea - Haskell's purity gives the compilers great license to reorder and rearrange code, and the laziness causes the dynamic call graph to differ wildly from the static call graph even without without optimizations. GHC's use of a private stack with very weird return conventions probably isn't helping either! Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20071003/78057e0f/attachment-0001.bin From ninegua at gmail.com Thu Oct 4 11:00:08 2007 From: ninegua at gmail.com (Paul L) Date: Thu Oct 4 10:59:05 2007 Subject: [Haskell] new SOE release with performance improvement Message-ID: <856033f20710040800h735ca461l7e0a96c76d60c4db@mail.gmail.com> Thanks to the help from Peter Verswyvelen, a new SOE version is available at http://www.haskell.org/soe, under the name SOE-20071003.zip. This update makes better handling of events and buffer swap, and results in less CPU usage and smoother animation. The performance improvement may be quite apparent on some systems, in particular, those with software GL emulation rather than accelerated hardware. So if you are having performance issues running current SOE, I suggest you it a try. It has been tested on Windows, Linux, and OS X. PS: there's no change to GLFW since previous release, so if you have already installed GLFW, you don't need to re-install it. Regards, Paul Liu -- Yale Haskell Group http://www.haskell.org/yale From A.Simon at kent.ac.uk Thu Oct 4 12:46:09 2007 From: A.Simon at kent.ac.uk (Axel Simon) Date: Thu Oct 4 12:45:37 2007 Subject: [Haskell] reading from stdin Message-ID: <1191516369.22482.58.camel@localhost> Hi, I'm trying to continuously output data to a file handle while reading single characters from the user to adjust the speed at which things are output. I'm interested to get this to work in Hugs on Windows. I successfully used the following function ghci under Mac OS: {{{ getUserInput :: IO (Maybe Char) getUserInput = do hasInput <- hReady stdin if hasInput then liftM Just (hGetChar stdin) else return Nothing }}} This function returns a character to me if there's one available. If anybody could give me a hint how to get this working in Hugs under Windows, please tell me. For the entertainment value, here's what's happening currently: a) ghci under Unix A character is returned if it is available, otherwise the function returns immediately. b) Hugs under Unix Characters are not recognised when typed. The characters are returned as soon as return is hit. The function does not block. c) ghci under Windows The function does not block until a character is entered. Once a character is entered, the function blocks until return is hit. d) Hugs under Windows The function aborts immediately somewhere in IO.hWaitForInput with an 'invalid operation (unsupported opperation)' error. I don't know what the right behaviour is, and I don't really care. But: a) is the behaviour I want, but unfortunately for platform d) b) must be due to ghci and Hugs having different opinions on whether stdin should be line buffered or unbuffered c) this is weird d) this is broken How can I get platform d) working with the behaviour of a)? Thanks a lot, Axel. P.S.: Sorry to post to haskell@..., but nothing else seemed to match. From ganesh.narayan at gmail.com Thu Oct 4 13:03:36 2007 From: ganesh.narayan at gmail.com (Ganesh Narayan) Date: Thu Oct 4 13:02:32 2007 Subject: [Haskell] Haskell Applications - reg In-Reply-To: <20071004001517.GB3558@localhost.localdomain> References: <4816a32d0710031702h68296a38icd4b51bffdd89ad2@mail.gmail.com> <20071004001517.GB3558@localhost.localdomain> Message-ID: <4816a32d0710041003k6177497crce62984cfcf25fa7@mail.gmail.com> True, but I was of the opinion that -O0, -fno-state-hack and -fno-full-laziness would preserve the calling structure with minimal perturbance. Wouldn't it? Besides, I am hardly aware of any utility that generates source level call graph/expression dependence graph; suppose one can generate a module dependency graph, but guess its little too coarse! -ganesh On 10/4/07, Stefan O'Rear wrote: > > On Thu, Oct 04, 2007 at 05:32:31AM +0530, Ganesh Narayan wrote: > > [1] Am presently constructing the call graphs from disassembled > application > > binaries; resultant graph includes ghc runtime library calls. > > Not necessary a good idea - Haskell's purity gives the compilers great > license to reorder and rearrange code, and the laziness causes the > dynamic call graph to differ wildly from the static call graph even > without without optimizations. GHC's use of a private stack with very > weird return conventions probably isn't helping either! > > Stefan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHBDCVFBz7OZ2P+dIRAnogAJ9m8Vv/NjUg50bJYdAGl2lzJQZMIwCgsXdq > mwdCgw1AO7KMBVkKTXjymAM= > =+aCh > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20071004/3686e3f4/attachment.htm From simonpj at microsoft.com Thu Oct 4 18:43:42 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 4 18:42:34 2007 Subject: [Haskell] Haskell Applications - reg In-Reply-To: <20071004001517.GB3558@localhost.localdomain> References: <4816a32d0710031702h68296a38icd4b51bffdd89ad2@mail.gmail.com> <20071004001517.GB3558@localhost.localdomain> Message-ID: Stefan's last point is the key one. GHC compiles into code that doesn't use call/return instructions. Instead, it pushes explicit return addresses, and returns by doing an indirect jump. I bet this isn't what your tool expects. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On | Behalf Of Stefan O'Rear | Sent: 04 October 2007 01:15 | To: Ganesh Narayan | Cc: haskell@haskell.org | Subject: Re: [Haskell] Haskell Applications - reg | | On Thu, Oct 04, 2007 at 05:32:31AM +0530, Ganesh Narayan wrote: | > [1] Am presently constructing the call graphs from disassembled application | > binaries; resultant graph includes ghc runtime library calls. | | Not necessary a good idea - Haskell's purity gives the compilers great | license to reorder and rearrange code, and the laziness causes the | dynamic call graph to differ wildly from the static call graph even | without without optimizations. GHC's use of a private stack with very | weird return conventions probably isn't helping either! | | Stefan From dave at zednenem.com Thu Oct 4 21:52:02 2007 From: dave at zednenem.com (David Menendez) Date: Thu Oct 4 21:50:53 2007 Subject: [Haskell] Haskell Applications - reg In-Reply-To: <4816a32d0710041003k6177497crce62984cfcf25fa7@mail.gmail.com> References: <4816a32d0710031702h68296a38icd4b51bffdd89ad2@mail.gmail.com> <20071004001517.GB3558@localhost.localdomain> <4816a32d0710041003k6177497crce62984cfcf25fa7@mail.gmail.com> Message-ID: <49a77b7a0710041852m6f134aax5a1e15a612a792b9@mail.gmail.com> On 10/4/07, Ganesh Narayan wrote: > True, but I was of the opinion that -O0, -fno-state-hack and > -fno-full-laziness would preserve the calling structure with minimal > perturbance. Wouldn't it? Besides, I am hardly aware of any utility that > generates source level call graph/expression dependence graph; suppose one > can generate a module dependency graph, but guess its little too coarse! You might have more luck with JHC, which (if I understand correctly) creates intermediate C code that somewhat resembles the Haskell source in structure. -- Dave Menendez From Oege.de.Moor at comlab.ox.ac.uk Fri Oct 5 09:18:55 2007 From: Oege.de.Moor at comlab.ox.ac.uk (Oege.de.Moor@comlab.ox.ac.uk) Date: Fri Oct 5 09:17:46 2007 Subject: [Haskell] PEPM 2008: abstracts due Oct 12 Message-ID: <200710051318.l95DIta5003254@mercury.comlab.ox.ac.uk> >>> LAST CALL <<< >>> abstracts - Oct 12, full papers - Oct 17 <<< PEPM 2008 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation January 7-8, 2008, San Francisco Keynotes by Ras Bodik (Berkeley) and Monica Lam (Stanford) Co-located with POPL http://www.program-transformation.org/PEPM08/WebHome PEPM is a leading venue for the presentation of cutting-edge research in program analysis, program generation and program transformation. Its proceedings are published by ACM Press; full details of the scope, submission process, and program committee can be found at the above URL. The program committee would particularly welcome submissions from researchers in functional programming on any topic relating to analysis, optimisation and synthesis of Haskell programs Abstracts are due on October 12, and the deadline for full paper submission is October 17. Prospective authors are welcome to contact the program chairs, Robert Glueck (glueck@acm.org) and Oege de Moor (oege@comlab.ox.ac.uk) with any queries they might have. From demis at dimi.uniud.it Fri Oct 5 11:45:28 2007 From: demis at dimi.uniud.it (demis@dimi.uniud.it) Date: Fri Oct 5 11:44:30 2007 Subject: [Haskell] 2nd CFP: 3rd Int'l Workshop on Automated Specification and Verification of Web Systems (WWV'07) Message-ID: <20071005154532.5E04047C2DC@smtp.uniud.it> Skipped content of type multipart/alternative From dons at galois.com Sat Oct 6 11:21:55 2007 From: dons at galois.com (Don Stewart) Date: Sat Oct 6 11:20:48 2007 Subject: [Haskell] ANNOUNCE: binary 0.4: high performance, pure binary parsing and serialisation Message-ID: <20071006152155.GA26150@scytale.galois.com> Binary: high performance, pure binary encoding, decoding and serialisation for Haskell ---------------------------------------------------------------------- The Binary Strike Team is pleased to announce release 0.4 of Data.Binary, the pure, efficient binary serialisation library for Haskell, now available from Hackage: tarball: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary/0.4 darcs: darcs get http://darcs.haskell.org/binary The 'binary' package provides efficient serialisation of Haskell values to and from lazy ByteStrings, and a low level layer for high performance decoding and decoding binary data. ByteStrings constructed this way may then be written to disk, written to the network, or further processed (e.g. stored in memory directly, or compressed in memory with zlib or bzlib). *Very* high performance can be expected, with throughput over 1G/sec observed in practice (good enough for most networking scenarios, we suspect). Encoding and decoding are achieved by the functions: encode :: Binary a => a -> ByteString decode :: Binary a => ByteString -> a which mirror the read/show functions. Convenience functions for serialising to disk are also provided: encodeFile :: Binary a => FilePath -> a -> IO () decodeFile :: Binary a => FilePath -> IO a To serialise your Haskell data, all you need do is write an instance of Binary for your type. For example, suppose in an interpreter we had the data type: import Data.Binary import Control.Monad data Exp = IntE Int | OpE String Exp Exp We can serialise this to bytestring form with the following instance: instance Binary Exp where put (IntE i) = putWord8 0 >> put i put (OpE s e1 e2) = putWord8 1 >> put s >> put e1 >> put e2 get = do tag <- getWord8 case tag of 0 -> liftM IntE get 1 -> liftM3 OpE get get get The binary library has been heavily tuned for performance, particularly for writing speed. On average, Data.Binary is 10x faster than NewBinary, and has the advantage of a pure interface, and bytestring return values. Binary was developed by a team of 8 during the Haskell Hackathon, Hac 07, in January 2007, and this maintainence release has taken place during the second hackathon. Binary is portable, using the foreign function interface and cpp, and has been tested with Hugs and GHC. Happy hacking! -- Don From johan.tibell at gmail.com Sun Oct 7 05:20:28 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun Oct 7 05:19:12 2007 Subject: [Haskell] ANNOUNCE: network-bytestring 0.1.1: Fast and memory efficient low-level networking Message-ID: <90889fe70710070220p317935d0p8fe1874d775fb804@mail.gmail.com> network-bytestring: Fast and memory efficient low-level networking ---------------------------------------------------------------------- Strict ByteString versions of the recv/send family of functions, now available from Hackage: tarball: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-bytestring-0.1.1 darcs: darcs get http://code.haskell.org/network-bytestring The 'network-bytestring' package provides more efficient networking by using strict ByteStrings instead of Strings for sending and receiving data. -- Johan From ganesh.narayan at gmail.com Sun Oct 7 16:06:49 2007 From: ganesh.narayan at gmail.com (Ganesh Narayan) Date: Sun Oct 7 16:05:30 2007 Subject: [Haskell] Haskell Applications - reg In-Reply-To: <49a77b7a0710041852m6f134aax5a1e15a612a792b9@mail.gmail.com> References: <4816a32d0710031702h68296a38icd4b51bffdd89ad2@mail.gmail.com> <20071004001517.GB3558@localhost.localdomain> <4816a32d0710041003k6177497crce62984cfcf25fa7@mail.gmail.com> <49a77b7a0710041852m6f134aax5a1e15a612a792b9@mail.gmail.com> Message-ID: <4816a32d0710071306xe68d2a3g29682a874f3d666d@mail.gmail.com> Yup, my call graph constructor jst tracks statically resolved call instructions and splices them to get the whole program graph; no indirections. I could rewrite the tool, but tracking jmp *%eax would be tad too complicated! I'd try JHC meanwhile. Stefen, Simon and David, thanks again for the inputs. -ganesh On 10/5/07, David Menendez wrote: > > On 10/4/07, Ganesh Narayan wrote: > > True, but I was of the opinion that -O0, -fno-state-hack and > > -fno-full-laziness would preserve the calling structure with minimal > > perturbance. Wouldn't it? Besides, I am hardly aware of any utility that > > generates source level call graph/expression dependence graph; suppose > one > > can generate a module dependency graph, but guess its little too coarse! > > You might have more luck with JHC, which (if I understand correctly) > creates intermediate C code that somewhat resembles the Haskell source > in structure. > > -- > Dave Menendez > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20071008/20e7e5cd/attachment.htm From bjorn.wikstrom at gmail.com Mon Oct 8 05:28:30 2007 From: bjorn.wikstrom at gmail.com (bjornie) Date: Mon Oct 8 05:27:08 2007 Subject: [Haskell] Converting Double from String Message-ID: <13092415.post@talk.nabble.com> Hi! I'm kind of new to functional programming with Haskell, I'm reading a university course you see. Now I'm having some problems with one of our lab assignments, we're supposed to write a program handling numeric operations (addition, multiplication, and some functionality like sin and cos). I've made a data type; data Expr = Num Double | Add Expr Expr | Mul Expr Expr... I.e for representing the expression: 2.4 * (4.0 + 1.5) The Haskell representation is: Mul (Num 2.4) (Add (Num 4.0) (Num 1.5)) My problem is to convert a String to an expression like the one above. I.e the String: "2.4*(4.0+1.5)" If we would use plain Integers there would not be a problem, since the Prelude function 'digitToInt' :: Char -> Int does nearly what I would like to do. But I'm stuck on the Doubles! How can I solve this in a smooth way? -- View this message in context: http://www.nabble.com/Converting-Double-from-String-tf4586633.html#a13092415 Sent from the Haskell - Haskell mailing list archive at Nabble.com. From johan.tibell at gmail.com Mon Oct 8 06:01:19 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Oct 8 05:59:57 2007 Subject: [Haskell] Converting Double from String In-Reply-To: <13092415.post@talk.nabble.com> References: <13092415.post@talk.nabble.com> Message-ID: <90889fe70710080301p21b1cc8eq7f15977960189be8@mail.gmail.com> On 10/8/07, bjornie wrote: > > Hi! I'm kind of new to functional programming with Haskell, I'm reading a > university course you see. Now I'm having some problems with one of our lab > assignments, we're supposed to write a program handling numeric operations > (addition, multiplication, and some functionality like sin and cos). > > I've made a data type; > data Expr = Num Double | Add Expr Expr | Mul Expr Expr... > > I.e for representing the expression: > 2.4 * (4.0 + 1.5) > The Haskell representation is: > Mul (Num 2.4) (Add (Num 4.0) (Num 1.5)) > > My problem is to convert a String to an expression like the one above. > I.e the String: "2.4*(4.0+1.5)" > > If we would use plain Integers there would not be a problem, since the > Prelude function 'digitToInt' :: Char -> Int does nearly what I would like > to do. But I'm stuck on the Doubles! How can I solve this in a smooth way? You can use read. Here's a session from GHC's interpreter: $ ghci Prelude> read "1.0" :: Double 1.0 Since read is polymorphic (i.e. works for different types) you need to specify the type of the result you want using ":: Double". From asloane at ics.mq.edu.au Wed Oct 10 02:07:32 2007 From: asloane at ics.mq.edu.au (Tony Sloane) Date: Wed Oct 10 02:06:18 2007 Subject: [Haskell] CFP: Intl Conf on Eval'n of Novel Approaches to Soft Eng Message-ID: [Apologies for multiple copies of this announcement that you may receive.] ENASE 2008 CALL FOR PAPERS 3rd International Conference on Evaluation of Novel Approaches to Software Engineering http://www.enase.org Funchal, Madeira, 4 - 7 May, 2008 organized by the Institute for Systems and Technologies of Information, Control and Communication (INSTICC) IMPORTANT DATES: Full Paper Submission: November 9, 2007 Authors Notification: January 4, 2008 Final Paper Submission and Registration: January 25, 2008 ENASE 2008 will be held in conjunction with WEBIST 2008 (http://www.webist.org) Mission The mission of the ENASE (Evaluation of Novel Approaches to Software Engineering) series of working conferences is to be a prime international forum to discuss and publish research findings and IT industry experiences with relation to evaluation of novel approaches to software engineering. By comparing novel approaches with established traditional practices and by evaluating them against software quality criteria, ENASE conferences advance knowledge and research in software engineering, identify most hopeful trends and propose new directions for consideration by researchers and practitioners involved in large-scale software development and integration. Goals and Topics of Interest ENASE provides a yearly forum for researchers and practitioners to review and evaluate relatively new and original in conception SE methods, practices, architectures, technologies and tools. An important underpinning and assumption of ENASE is that in software engineering "novel" turns out frequently to be just new hype. An objective of ENASE is to reveal any such hype as soon as feasible. This means that ENASE does not exclude more traditional approaches to software development and integration. On the contrary, ENASE endeavors to compare novel with traditional, also to discover if novel is not just traditional in disguise. Consequently, ENASE accepts also papers concentrating on a critique of more established and popular SE approaches. Against that background, ENASE undertakes to provide fast but careful scientific and empirical evaluation of new as well as more established approaches to software engineering. Of particular interest are experience reports and evaluations (qualitative and quantitative) of existing approaches as well as new ideas and proposals for improvements. The conference solicits experiments, case studies, surveys, meta-analyses, empirical studies, systematic reviews, conceptual explorations, innovative ideas, critical appraisals, etc. related to: * agile software development, * aspect-oriented software development, * agent-oriented software engineering, * multi-agent systems, * model-driven engineering, * component-based software engineering, * evolutionary design, * intentional software, * example centric programming, * meta programming systems, * knowledge management and engineering, * architectural design and meta architectures, * business process management, engineering and reengineering, * process-centric paradigms, * service-oriented architectures, * application integration technologies, * enterprise integration strategies and patterns, * e-business technologies, * requirements engineering frameworks and models, * collaborative requirements management systems, * business and software modeling languages, * software quality management, * software change and configuration management, * geographically distributed software development environments, * cross-feeding between data engineering and software engineering, * design thinking as a paradigm for software development, * formal methods, * software process improvement, * metamodelling, * software development methodologies Conference Format There will be full papers presented to the conference by the authors, poster papers available for viewing and discussions, and demo papers available for viewing and related to the demonstrations of software tools and products. Conference Publications All accepted papers will be published in the conference proceedings, under an ISBN reference, in paper and in CD-ROM support. A book including a selection of the best full papers will be edited and published by Springer-Verlag. Conference Chairs Joaquim Filipe (Polytechnic Institute of Set?bal / INSTICC, Portugal) Leszek A. Maciaszek (Macquarie University ~ Sydney, Australia) Program Chairs Cesar Gonzalez-Perez (Neco, Spain) Stefan Jablonski (University of Bayreuth, Germany) From simonpj at microsoft.com Thu Oct 11 05:42:31 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 11 05:41:02 2007 Subject: [Haskell] Fingerprints and hashing Message-ID: Dear Haskellers Here's a challenge. We are all familiar with the idea of an MD5 checksum, which provides a reliable "fingerprint" for a file, usually 128 bits or so. If the file changes, the fingerprint is (almost) certain to do so too. There are lots of techniques: CRC, shar?, MD5, etc. For various applications (including identifying common sub-expressions, and version tracking in GHC), I'd like a Haskell library that supports simple fingerprint operations. Below I give an informal specification of such a library. I can think of any number of implementations, but I'd like one that is (a) robust and (b) efficient. By "robust" I meant that with, say, a 128-bit fingerprint the chance of accidental collision is truly low; a non-robust implementation uses the 128-bit space in a non-uniform way [trivial example: gets stuck on zero]. Any takers? I bet some of you have this already, in some form. Simon The module signature would be something like this: data Fingerprint instance Eq Fingerprint instance Ord Fingerprint initialPrint :: Fingerprint class Fingerprintable t where fingerPrint :: t -> Fingerprint -> FingerPrint instance Fingerprintable Char instance Fingerprintable Int instance Fingerprintable Word32 -- etc The fingerPrint operation here is expressed in the traditional way: an accumulator (say 128 bits) into which one stuffs successive values (e.g. a byte stream). However, very important, I also want a more compositional form: instance Fingerprintable Fingerprint so that I can do something like fp :: Expr -> Fingerprint fp (App e1 e2) = fp e1 `fingerPrint` fp e2 Yes, I could thread the accumulator, thus: fp' :: Expr -> Fingerprint -> Fingerprint fp' (App e1 e2) p = fp' e1 (fp' e2 p) but I can't *always* do that; or even if I can, I may already *have* a fingerprint for e1 in my hand, and it's painful to re-traverse e1. Think of hash-consing. An obvious implementation of "instance Fingerprintable Fingerprint" is to divide one fingerprint into words, and feed it into the other via the Word32 instance. But it's not clear to me whether or not that is robust. (Incidentally, one could define the class thus: class Fingerprintable t where fingerPrint :: t -> FingerPrint plus plusFP :: Fingerprint -> Fingerprint -> Fingerprint But I think it'd be less efficient if that was the only way, because of all those now-compulsory plusFP operations.) I'd like one other thing: to be able to trade cost for accuracy. I'd like a 128-bit fingerprint with essentially zero chance of having two distinct values that map to the same fingerprint; and a one-word fingerprint that was a lot more efficient, but where collisions would be entirely possible (again hash-consing is an example). From ndmitchell at gmail.com Thu Oct 11 06:18:52 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Oct 11 06:17:21 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: References: Message-ID: <404396ef0710110318u45b29fc9i7afe5eb8e75c601a@mail.gmail.com> Hi Simon, > We are all familiar with the idea of an MD5 checksum, which provides a reliable "fingerprint" for a file, usually 128 bits or so. If the file changes, the fingerprint is (almost) certain to do so too. There are lots of techniques: CRC, shar?, MD5, etc. I believe the basic operations are all in the Crypto library: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Crypto-3.0.3 - see Data.Digest.SHA1 and Data.Digest.MD5 - digest is simply another word for fingerprint in this sense. However, your fingerprint stuff sounds a lot more like a request for a Hash function - rather than something that operates over streams of bytes. To get both, I'd recommend something like taking the digest of the data after calling show, or after serialising it to a ByteString with the binary library. Doing it this way means you have no additional need for a FingerPrint class but can reuse the existing Show/Binary class. Thanks Neil From la at iki.fi Thu Oct 11 06:27:16 2007 From: la at iki.fi (Lauri Alanko) Date: Thu Oct 11 06:25:47 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: References: Message-ID: <20071011102716.GA32281@cs.helsinki.fi> If compositionality is important, at least Rabin's fingerprints are worth considering: http://citeseer.ist.psu.edu/broder93some.html They have the neat property that the fingerprint of a concatenation of strings can be cheaply computed from the fingerprints of the constituents. I think this effectively means that the plusFP operation can be made associative, which might offer optimization opportunities. I remember implementing it some seven years ago when prototyping for a C implementation. The code is lost, though. I can give it a shot again, if this is considered a reasonable algorithm. Lauri From simonpj at microsoft.com Thu Oct 11 07:28:30 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 11 07:27:01 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: <20071011102716.GA32281@cs.helsinki.fi> References: <20071011102716.GA32281@cs.helsinki.fi> Message-ID: Interesting! The associativity property is the kind of thing I was after. Except that I don't really care if FP(as ++ bs) = FP(as) `plusFP` FP(bs). I only care that the latter is robust in the sense of having low probabilty of collision. So the Rabin scheme does more than I really need (which is probably fine). On page 1 he draws a distinction between fingerprinting and hashing, which relates to my last wish. Does one need a different technique for the two, or is it enough to reduce the number of bits in the Rabin scheme, and thereby get a hashing scheme? Strangely the paper gives no comparison with other fingerprinting schemes. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Lauri Alanko | Sent: 11 October 2007 11:27 | To: haskell | Subject: Re: [Haskell] Fingerprints and hashing | | If compositionality is important, at least Rabin's fingerprints are | worth considering: http://citeseer.ist.psu.edu/broder93some.html | | They have the neat property that the fingerprint of a concatenation of | strings can be cheaply computed from the fingerprints of the | constituents. I think this effectively means that the plusFP operation | can be made associative, which might offer optimization opportunities. | | I remember implementing it some seven years ago when prototyping for a | C implementation. The code is lost, though. I can give it a shot | again, if this is considered a reasonable algorithm. | | | Lauri | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From paolot at informatik.uni-bremen.de Thu Oct 11 08:55:50 2007 From: paolot at informatik.uni-bremen.de (paolot@informatik.uni-bremen.de) Date: Thu Oct 11 10:00:04 2007 Subject: [Haskell] Abstract syntax representation Message-ID: <20071011145550.xgy2lpicow4ogg8o@webmail.informatik.uni-bremen.de> Hi, I am writing translations of Haskell to specification languages. I was wondering whether there already exist a representation of Haskell syntax that, in contrast with standard abstract syntax, is "light" on structure (few data-types, few constructors) and has no dictionary parameters. Thanks, -paolo From cwitty at newtonlabs.com Thu Oct 11 12:58:27 2007 From: cwitty at newtonlabs.com (Carl Witty) Date: Thu Oct 11 12:55:15 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: References: <20071011102716.GA32281@cs.helsinki.fi> Message-ID: <1192121907.28535.186.camel@localhost> On Thu, 2007-10-11 at 12:28 +0100, Simon Peyton-Jones wrote: > Interesting! The associativity property is the kind of thing I was after. Except that I don't really care if FP(as ++ bs) = FP(as) `plusFP` FP(bs). I only care that the latter is robust in the sense of having low probabilty of collision. So the Rabin scheme does more than I really need (which is probably fine). > > On page 1 he draws a distinction between fingerprinting and hashing, which relates to my last wish. Does one need a different technique for the two, or is it enough to reduce the number of bits in the Rabin scheme, and thereby get a hashing scheme? > > Strangely the paper gives no comparison with other fingerprinting schemes. > > Simon > | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Lauri Alanko > | > | If compositionality is important, at least Rabin's fingerprints are > | worth considering: http://citeseer.ist.psu.edu/broder93some.html Note that Rabin's fingerprint algorithm is the same as CRC (http://en.wikipedia.org/wiki/Cyclic_redundancy_check). I'm not aware of people using CRCs for hashing inside a program, but they should work fine and be fairly fast. I can think of two caveats. 1) With CRC and a fixed polynomial, it is very easy for an "adversary" to pick multiple inputs that give the same fingerprint/hash code. (Rabin avoids this by picking a random polynomial after the adversary has selected the inputs.) Depending on the application, this may be very important, or it may not matter at all. 2) The straightforward approach for "instance Fingerprintable Fingerprint" works very poorly for CRCs. Considering balanced binary trees with four leaves, and the obvious compositional hash function, then for all a,b,c,d we would have fingerprint ((a,b),(c,d)) == fingerprint ((a,c),(b,d)), and fingerprint ((a,b),(b,d)) == fingerprint ((a,c),(c,d)). To avoid this, the fingerprint would have to include not only the remainder, but the number of bits involved in creating the fingerprint. Then fingerprinting a fingerprint would require time logarithmic in this number of bits. Carl Witty From westondan at imageworks.com Thu Oct 11 14:45:35 2007 From: westondan at imageworks.com (Dan Weston) Date: Thu Oct 11 14:44:06 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: References: <20071011102716.GA32281@cs.helsinki.fi> Message-ID: <470E6F4F.7050508@imageworks.com> I am zero training in cryptography, but I would think that if in addition to FP(as ++ bs) = FP(bs) `plusFPFlipped` FP(as) (I think the flipped plusFP def is more intuitive) there also existed a minusFP for all f and x such that FP(bs) = FP(as ++ bs) `minusFP` FP(as) then that might facilitate common subexpression refactorization in the merging of two hashes of memoized expressions. One example of such an minusFP (not recommended) is (foldr xor 0): That xor is its own inverse is no advantage. But xor is associative and (xor 0) is an identity, so FP([] ++ as) = FP(as ++ []) = FP(as) as expected. There must be more robust such monoidal functors out there. Refactorization could be limited to respect substructure boundaries reflected in the serialization. Dan Weston Simon Peyton-Jones wrote: > Interesting! The associativity property is the kind of thing I was after. Except that I don't really care if FP(as ++ bs) = FP(as) `plusFP` FP(bs). I only care that the latter is robust in the sense of having low probabilty of collision. So the Rabin scheme does more than I really need (which is probably fine). > > On page 1 he draws a distinction between fingerprinting and hashing, which relates to my last wish. Does one need a different technique for the two, or is it enough to reduce the number of bits in the Rabin scheme, and thereby get a hashing scheme? > > Strangely the paper gives no comparison with other fingerprinting schemes. > > Simon > > | -----Original Message----- > | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Lauri Alanko > | Sent: 11 October 2007 11:27 > | To: haskell > | Subject: Re: [Haskell] Fingerprints and hashing > | > | If compositionality is important, at least Rabin's fingerprints are > | worth considering: http://citeseer.ist.psu.edu/broder93some.html > | > | They have the neat property that the fingerprint of a concatenation of > | strings can be cheaply computed from the fingerprints of the > | constituents. I think this effectively means that the plusFP operation > | can be made associative, which might offer optimization opportunities. > | > | I remember implementing it some seven years ago when prototyping for a > | C implementation. The code is lost, though. I can give it a shot > | again, if this is considered a reasonable algorithm. > | > | > | Lauri > | _______________________________________________ > | Haskell mailing list > | Haskell@haskell.org > | http://www.haskell.org/mailman/listinfo/haskell > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > From westondan at imageworks.com Thu Oct 11 14:47:57 2007 From: westondan at imageworks.com (Dan Weston) Date: Thu Oct 11 14:46:38 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: <470E6F4F.7050508@imageworks.com> References: <20071011102716.GA32281@cs.helsinki.fi> <470E6F4F.7050508@imageworks.com> Message-ID: <470E6FDD.5020402@imageworks.com> > One example of such an minusFP (not recommended) is (foldr xor 0): Obviously I meant that FP = foldr xor 0. minusFP would be a simple unfolding of this. Dan Weston wrote: > I am zero training in cryptography, but I would think that if in > addition to > > FP(as ++ bs) = FP(bs) `plusFPFlipped` FP(as) > > (I think the flipped plusFP def is more intuitive) > > there also existed a minusFP for all f and x such that > > FP(bs) = FP(as ++ bs) `minusFP` FP(as) > > then that might facilitate common subexpression refactorization in the > merging of two hashes of memoized expressions. > > One example of such an minusFP (not recommended) is (foldr xor 0): > > That xor is its own inverse is no advantage. But xor is associative and > (xor 0) is an identity, so FP([] ++ as) = FP(as ++ []) = FP(as) as > expected. There must be more robust such monoidal functors out there. > > Refactorization could be limited to respect substructure boundaries > reflected in the serialization. > > Dan Weston > > Simon Peyton-Jones wrote: >> Interesting! The associativity property is the kind of thing I was >> after. Except that I don't really care if FP(as ++ bs) = FP(as) >> `plusFP` FP(bs). I only care that the latter is robust in the sense >> of having low probabilty of collision. So the Rabin scheme does more >> than I really need (which is probably fine). >> >> On page 1 he draws a distinction between fingerprinting and hashing, >> which relates to my last wish. Does one need a different technique >> for the two, or is it enough to reduce the number of bits in the Rabin >> scheme, and thereby get a hashing scheme? >> >> Strangely the paper gives no comparison with other fingerprinting >> schemes. >> >> Simon >> >> | -----Original Message----- >> | From: haskell-bounces@haskell.org >> [mailto:haskell-bounces@haskell.org] On Behalf Of Lauri Alanko >> | Sent: 11 October 2007 11:27 >> | To: haskell >> | Subject: Re: [Haskell] Fingerprints and hashing >> | >> | If compositionality is important, at least Rabin's fingerprints are >> | worth considering: http://citeseer.ist.psu.edu/broder93some.html >> | >> | They have the neat property that the fingerprint of a concatenation of >> | strings can be cheaply computed from the fingerprints of the >> | constituents. I think this effectively means that the plusFP operation >> | can be made associative, which might offer optimization opportunities. >> | >> | I remember implementing it some seven years ago when prototyping for a >> | C implementation. The code is lost, though. I can give it a shot >> | again, if this is considered a reasonable algorithm. >> | >> | >> | Lauri >> | _______________________________________________ >> | Haskell mailing list >> | Haskell@haskell.org >> | http://www.haskell.org/mailman/listinfo/haskell >> _______________________________________________ >> Haskell mailing list >> Haskell@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> >> > > From apfelmus at quantentunnel.de Thu Oct 11 16:33:03 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Thu Oct 11 16:41:02 2007 Subject: [Haskell] Re: Fingerprints and hashing In-Reply-To: References: Message-ID: Simon Peyton-Jones wrote: > For various applications (including identifying common sub-expressions, > and version tracking in GHC), I'd like a Haskell library that supports > simple fingerprint operations. Note that for CSE and hash-consing, there is a no-collision yet very efficient way of fingerprinting (with a drawback, of course :). The starting point is the question "why does cryptographic hashing work"? I mean, uniquely serializing (g?del numbering) a tree like newtype Exp = Exp (ExpF Exp) data ExpF a = Zero | One | Add a a | Mult a a deriving (Functor, Foldable, Traversable) takes an amount of bits proportional to its size (number of constructors). So, how can we expect a simple 128-bit number to have only few collisions for a collection of medium-sized trees? The answer is that the collection is much too small, no computer will ever be able to count (or construct said trees) from 1 to 2^128 in eons. So, the idea is to use a "local g?del numbering" and uniquely number the and only the trees that are actually constructed (no collisions, but few in numbers). In other words, every new tree created gets the g?del number size collection + 1 and we can simply use type G?delNumber = Word32 assuming that no more than 4G of trees will ever be constructed. For fast hash-consing, the collection itself is a (generalized) trie type Collection = ExpF G?delNumber ~~> Maybe G?delNumber mapping each new top of a tree (constructor + g?del numbers for already known subtrees) to either Just its g?del number or Nothing when it's not in the collection yet. With this, CSE becomes a catamorphism that allocates new g?del numbers if necessary type StateC a = Collection -> (Collection, a) deriving (Monad) cse :: Exp -> StateC G?delNumber cse = cata hashCons hashCons :: ExpF (StateC G?delNumber) -> StateC G?delNumber hashCons x0 = \c0 -> let (c,x) = sequence x0 c0 in case lookup x c of Maybe g -> (c,g) Nothing -> let g = size c + 1; c' = insert x g c in (c',g) where sequence :: ExpF (StateC G?delNumber) -> StateC (ExpF G?delNumber) sequence = Data.Traversable.sequence CSE in the sense that all common subexpressions now have the same g?del number. Of course, the drawback compared to "free-form" fingerprinting is that the fingerprinting and the collection now depend on each other. But for CSE, we have to carry the collection around anyway. I don't know any references for that method since I came up with it myself and haven't searched around yet. Any pointers? Regards, apfelmus From u.stenzel at web.de Thu Oct 11 19:27:11 2007 From: u.stenzel at web.de (Udo Stenzel) Date: Thu Oct 11 20:30:54 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071010142229.GA30114@scytale.galois.com> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> Message-ID: <20071011232711.GB2972@web.de> Don Stewart wrote: > Since you're not using ghc 6.8, you should use binary 0.3 :) That was PC for "sorry, GHC 6.6 is no longer supported and don't even ask about 6.4" The other day I tried to install the tar library on a GHC 6.4. It's nearly impossible. The old base library gets in the way of installing bytestring, binary 0.4 absolutely needs bytestring 0.9 and tar absolutely needs binary 0.4, but still won't compile because System.Posix is now called System.PosixCompat which actually makes it incompatible. Oh, and everything needs a new cabal, but the setup scripts still picks up the wrong one (apparently, since Distribution.Simple is supposed to be there but GHC doesn't find it). Wanna know the solution? - install exactly one version of cabal, 1.1.6.2, and *remove* all others, - ask ghc-pkg for the description of base, then edit Data.ByteString out of that and re-register it, - install bytestring 0.9, - install binary 0.4, - edit the Setup.lhs of tar (it still won't run, even though it should), - edit the source of tar, changing System.PosixCompat to System.Posix, - install it. Should I mention that this is made even more difficult by not being root on the machine in question? All this happened with libraries that look as if they are supposed to be stable, but absolutely nothing works right out of the box. Oh, and Cabal Configurations will make it worse, not better. Here's what should be done, imho: - Rename 'base' ASAP and especially before GHC 6.8 comes out, call it 'foundation' or something else. If you want to keep the name 'base', make sure Cabal considers 'base-2.x' a different library than 'base-3.x'. - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one is still alive!) that removes the conflict between 'base' and 'bytestring' and pretends to provide bytestring, containers, array, etc. - Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. - Start fixing dependencies. - Refrain from renaming stuff. System.Posix is a fine name. - Refrain from always using the latest interface of everything. While we're at it, the ability to have multiple versions of a library installed under the same name is a recipe for desaster, too. It should be dropped, instead implementing Eternal Compatibility in Theory by encoding version numbers in module names. Sorry for the rant, but the situation was actually better before Cabal tried to fix everything and in the process broke both versions of GHC that are in widespread use right now. -Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20071012/b11d04f8/attachment-0001.bin From jmaessen at alum.mit.edu Thu Oct 11 21:07:25 2007 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Thu Oct 11 21:05:47 2007 Subject: [Haskell] Re: Fingerprints and hashing In-Reply-To: References: Message-ID: <9667FEBB-0391-4E65-A272-83D7FF8766CE@alum.mit.edu> On Oct 11, 2007, at 4:33 PM, apfelmus wrote: ... > > So, the idea is to use a "local g?del numbering" and uniquely > number the and only the trees that are actually constructed (no > collisions, but few in numbers). In other words, every new tree > created gets the g?del number size collection + 1 and we can > simply use > > type G?delNumber = Word32 > > assuming that no more than 4G of trees will ever be constructed. > For fast hash-consing, the collection itself is a (generalized) trie > > type Collection = ExpF G?delNumber ~~> Maybe G?delNumber > > mapping each new top of a tree (constructor + g?del numbers for > already known subtrees) to either Just its g?del number or Nothing > when it's not in the collection yet. > > With this, CSE becomes a catamorphism that allocates new g?del > numbers if necessary > ... > CSE in the sense that all common subexpressions now have the same > g?del number. > > Of course, the drawback compared to "free-form" fingerprinting is > that the fingerprinting and the collection now depend on each > other. But for CSE, we have to carry the collection around anyway. > > > I don't know any references for that method since I came up with it > myself and haven't searched around yet. Any pointers? Actually, the paper that Lauri cited in his message mentions essentially this technique; this is equivalent to the permutation T() that they impose when fingerprinting a DAG. That citation again: http://citeseer.ist.psu.edu/broder93some.html But it's generally pretty well known. -Jan From stefanor at cox.net Thu Oct 11 23:05:22 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Oct 11 23:03:50 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071011232711.GB2972@web.de> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> Message-ID: <20071012030522.GA4138@localhost.localdomain> On Fri, Oct 12, 2007 at 01:27:11AM +0200, Udo Stenzel wrote: > - Rename 'base' ASAP and especially before GHC 6.8 comes out, call it > 'foundation' or something else. If you want to keep the name 'base', > make sure Cabal considers 'base-2.x' a different library than > 'base-3.x'. > - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one > is still alive!) that removes the conflict between 'base' and > 'bytestring' and pretends to provide bytestring, containers, array, > etc. +10 Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20071011/5d42cc4c/attachment.bin From simonmarhaskell at gmail.com Fri Oct 12 04:11:19 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Oct 12 04:09:52 2007 Subject: [Haskell] [Fwd: Re: CFP - DAMP 2008 - Declarative Aspects of Multicore Programming] Message-ID: <470F2C27.6010605@gmail.com> [ posting on behalf of Manuel Hermenegildo ] Subject: CFP - DAMP 2008 - Declarative Aspects of Multicore Programming DAMP 2008: Workshop on Declarative Aspects of Multicore Programming San Francisco, CA, USA (colocated with POPL 2008) January 9, 2008 SUBMISSION DEADLINE: OCTOBER 26 Parallelism is going mainstream. Many chip manufactures are turning to multicore processor designs rather than scalar-oriented frequency increases as a way to get performance in their desktop, enterprise, and mobile processors. This endeavor is not likely to succeed long term if mainstream applications cannot be parallelized to take advantage of tens and eventually hundreds of hardware threads. Multicore architectures will differ in significant ways from their multisocket predecessors. For example, the communication to compute bandwidth ratio is likely to be higher, which will positively impact performance. More generally, multicore architectures introduce several new dimensions of variability in both performance guarantees and architectural contracts, such as the memory model, that may not stabilize for several generations of product. Programs written in functional or (constraint-)logic programming languages, or even in other languages with a controlled use of side effects, can greatly simplify parallel programming. Such declarative programming allows for a deterministic semantics even when the underlying implementation might be highly non-deterministic. In addition to simplifying programming this can simplify debugging and analyzing correctness. DAMP is a one-day workshop seeking to explore ideas in programming language design that will greatly simplify programming for multicore architectures, and more generally for tightly coupled parallel architectures. The emphasis will be on functional and (constraint-)logic programming, but any programming language ideas that aim to raise the level of abstraction are welcome. DAMP seeks to gather together researchers in declarative approaches to parallel programming and to foster cross fertilization across different approaches. Specific topics include, but are not limited to: * suitability of functional and (constraint-)logic programming languages to multicore applications; * run-time issues such as garbage collection or thread scheduling; * architectural features that may enhance the parallel performance of declarative languages; * type systems and analysis for accurately knowing or limiting dependencies, aliasing, effects, and nonpure features; * ways of specifying or hinting at parallelism; * ways of specifying or hinting at data placement which abstract away from any details of the machine; * compiler techniques, automatic parallelization, automatic granularity control; * experiences of and challenges arising from making declarative programming practical; * technology for debugging parallel programs; * design and implementation of domain-specific declarative languages for multi-core; Submission: Submitted papers papers should not exceed 15 pages in LLNCS format. Submission is electronic via: http://www.easychair.org/DAMP2008/ Important dates: Paper submission: Oct 26 Notification to authors: Nov 30 Camera ready: Dec 14 Program Chair: Manuel Hermenegildo Technical University of Madrid / IMDEA-Software -- herme@fi.upm.es University of New Mexico -- herme@unm.edu Program Committee: Koen De Bosschere (U. of Gent, Belgium) Manuel Carro (Tech. U. of Madrid, Spain) Manuel Chakravarty (U. of New S. Wales, Australia) Clemens Grelck (U. of Luebeck, Germany) Dan Grossman (U. of Washington, USA) Suresh Jagannathan (Purdue U., USA) Pedro Lopez-Garcia (Tech. U. of Madrid, Spain) Lee Naish (Melbourne University, Australia) Leaf Petersen (Intel Corporation, USA) Enrico Pontelli (New Mexico State U., USA) John Reppy (U. of Chicago, USA) Vitor Santos-Costa (U. of Porto, Portugal) General Chairs: Leaf Petersen Neal Glew Intel Corporation Santa Clara, CA, USA leaf.petersen@intel.com neal.glew@intel.com URL: http://www.cliplab.org/Conferences/DAMP08 Past DAMPs: http://glew.org/damp2006 http://www.cs.cmu.edu/~damp -- -- ------------------------------------------------------------------------------- Manuel Hermenegildo | Prof., C.S. Department Director, IMDEA-Software and CLIP Group | T.U. of Madrid (UPM) http://www.cliplab.org/herme | +34-91-336-7435 (W) -352-4819 (Fax) ------------------------------------------------------------------------------- From ketil+haskell at ii.uib.no Fri Oct 12 04:52:54 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Oct 12 04:51:17 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071011232711.GB2972@web.de> (Udo Stenzel's message of "Fri\, 12 Oct 2007 01\:27\:11 +0200") References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> Message-ID: <87myuo3eah.fsf@nmd9999.imr.no> Udo Stenzel writes: [incompatibilities between recent libraries/cabal/ghc] I'm installing a GHC-6.8 snapshot, and compiling a bunch of libraries I need in the process (HTTP, HXT, and binary). No show-stoppers, but a lot of rewriting of the dependencies. At least ghc will tell me which package to add, and after a bunch of iterations of this, things work nicely. +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc, with compatible interfaces. (Versioning isn't as good, I think, because it's too common to specify just 'base' without any version. At least, I know I do.) -k -- If I haven't seen further, it is by standing in the footprints of giants From simonmarhaskell at gmail.com Fri Oct 12 05:13:19 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Oct 12 05:11:50 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <87myuo3eah.fsf@nmd9999.imr.no> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <87myuo3eah.fsf@nmd9999.imr.no> Message-ID: <470F3AAF.5020102@gmail.com> Ketil Malde wrote: > +1 to renaming the new base, and have 'base' be a compatibility > package incorporating 'containers', 'array', etc, with compatible > interfaces. (Versioning isn't as good, I think, because it's too > common to specify just 'base' without any version. At least, I know I > do.) There's currently no (easy) way to make a package that just re-exports the contents of other packages. I've been thinking about ways to do this recently, but I'm now convinced that adding direct support to Cabal and the rest of the packaging infrastructure to do this is the wrong way. I'll try to write down my thoughts and post it sometime. Cheers, Simon From simonmarhaskell at gmail.com Fri Oct 12 05:26:40 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Oct 12 05:25:09 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071011232711.GB2972@web.de> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> Message-ID: <470F3DD0.3030502@gmail.com> Udo Stenzel wrote: > - Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. Cabal 1.2 works all the way back to GHC 6.2. The recommended way to build new packages with an old GHC will be to upgrade Cabal first. > - Start fixing dependencies. In progress for the GHC 6.8.1 release, I believe (dcoutts is on the case). > - Refrain from renaming stuff. System.Posix is a fine name. Who renamed it? It's still called System.Posix AFAIK. > - Refrain from always using the latest interface of everything. > > While we're at it, the ability to have multiple versions of a library > installed under the same name is a recipe for desaster, too. It should > be dropped, instead implementing Eternal Compatibility in Theory by > encoding version numbers in module names. Personally I object to ECT, it's too heavy. I believe versioning belongs in the package system where it currently is. > Sorry for the rant, but the situation was actually better before Cabal > tried to fix everything and in the process broke both versions of GHC > that are in widespread use right now. The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right? In that case, I think a reasonable hack is to modify the package configuration for base to move Data.ByteString from exposed-modules to hidden-modules (I'd be wary about removing it altogether). Perhaps the bytestring Setup.lhs should do this automatically when registering? Cheers, Simon From ketil+haskell at ii.uib.no Fri Oct 12 06:26:05 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Oct 12 06:24:28 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <470F3AAF.5020102@gmail.com> (Simon Marlow's message of "Fri\, 12 Oct 2007 10\:13\:19 +0100") References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <87myuo3eah.fsf@nmd9999.imr.no> <470F3AAF.5020102@gmail.com> Message-ID: <87641c39z6.fsf@nmd9999.imr.no> Simon Marlow writes: >> +1 to renaming the new base, and have 'base' be a compatibility >> package incorporating 'containers', 'array', etc > There's currently no (easy) way to make a package that just re-exports > the contents of other packages. Presumably the hard way would be to simply compile a 'base' consisting of all the modules from those packages? Would that be an option? -k -- If I haven't seen further, it is by standing in the footprints of giants From u.stenzel at web.de Fri Oct 12 04:45:28 2007 From: u.stenzel at web.de (Udo Stenzel) Date: Fri Oct 12 06:31:32 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071011232711.GB2972@web.de> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> Message-ID: <20071012084528.GA5625@web.de> Udo Stenzel wrote: > - install exactly one version of cabal, 1.1.6.2, and *remove* all > others, > - ask ghc-pkg for the description of base, then edit Data.ByteString out > of that and re-register it, I forgot, I also tried tar-1.0 on GHC 6.6, and had the same problem there. Even after updating Cabal, there was no way to install 'bytestring' due to the conflict with 'base'. A modified package description for 'base' helped. The reason that tar absolutely wants new stuff is 'instance MonadFix Get', which is not in binary-0.3. If you absolutely want users of GHC 6.6 to stick with binary-0.3, then you should provide a maintenance release binary-0.3.1. And we're back to Eternal Compatibility in Theory... -Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20071012/87153243/attachment-0001.bin From bos at serpentine.com Fri Oct 12 10:01:37 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Oct 12 10:01:41 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: <404396ef0710110318u45b29fc9i7afe5eb8e75c601a@mail.gmail.com> References: <404396ef0710110318u45b29fc9i7afe5eb8e75c601a@mail.gmail.com> Message-ID: <470F7E41.7060105@serpentine.com> Neil Mitchell wrote: > Hi Simon, > >> We are all familiar with the idea of an MD5 checksum, which provides a reliable "fingerprint" for a file, usually 128 bits or so. If the file changes, the fingerprint is (almost) certain to do so too. There are lots of techniques: CRC, shar?, MD5, etc. > > I believe the basic operations are all in the Crypto library: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Crypto-3.0.3 > - see Data.Digest.SHA1 and Data.Digest.MD5 - digest is simply another > word for fingerprint in this sense. The Crypto library does indeed provide those operations, but the implementations are naive and hence extremely slow. Fine for hashing an individual password, but not appropriate for ten thousand identifiers in a compiler. Hello, what are good approaches for creating Haskell bindings to C++ libraries? The most promising so far seems to create C wrappers around the C++ libraries and then bind to them. Is it feasible to bind directly to C++ using ccall by relying on some standardized C++ ABI? What about H/Direct? Are there any other good ways? Thank you for any hints. Best wishes, Wolfgang From A.Simon at kent.ac.uk Fri Oct 12 10:46:51 2007 From: A.Simon at kent.ac.uk (Axel Simon) Date: Fri Oct 12 10:46:07 2007 Subject: [Haskell] C++ bindings In-Reply-To: <200710121622.36348.g9ks157k@acme.softbase.org> References: <200710121622.36348.g9ks157k@acme.softbase.org> Message-ID: <19D0E5EA-B83F-475E-94AC-5683F6381EFE@kent.ac.uk> Hi Wolfgang, On Oct 12, 2007, at 15:22, Wolfgang Jeltsch wrote: > Hello, > > what are good approaches for creating Haskell bindings to C++ > libraries? The > most promising so far seems to create C wrappers around the C++ > libraries and > then bind to them. Is it feasible to bind directly to C++ using > ccall by > relying on some standardized C++ ABI? What about H/Direct? Are > there any > other good ways? Since the name mangling of C++ members, classes and functions are compiler specific, I don't think there is a good way of directly calling the C++ functions and methods. I wrapped all C++ methods of my classes in C functions. I use the following structure: C++ header file tvpi.hh: #ifndef __TVPI_H #define __TVPI_H namespace Tvpi { class Domain { public: Domain(); void joinWiden(Domain& prev, mpz_class extrapolate); }; #endif // __TVPI_H ========================== C header file tvpi_c.h #ifndef TVPI_C_H_ #define TVPI_C_H_ #ifdef __cplusplus extern "C" { #endif // __cplusplus #undef TVPI_TYPE_DECLARATION #define TVPI_TYPE_DECLARATION(Type) \ typedef struct Type ## _tag Type ## _t; \ typedef Type ## _t * Type ## _p; \ typedef Type ## _t const* const_ ## Type ## _p TVPI_TYPE_DECLARATION(Domain); Domain_p tvpiNew(void); void tvpiFree(Domain_p d); void tvpiJoin(Domain_p d1, Domain_p d2); #ifdef __cplusplus } #endif // __cplusplus #endif // TVPI_C_H_ ========================== C wrapper file, tvpi_c.cpp: #include "tvpi_c.h" #include "tvpi.hh" using namespace Tvpi; template const ToType* to_const(const FromType* x) { return reinterpret_cast(x); } template ToType* to_nonconst(FromType* x) { return reinterpret_cast(x); } Domain_p tvpiNew() { return to_nonconst(new Domain()); } void tvpiFree(Domain_p d) { delete to_nonconst(d); } Domain_p tvpiCopy(Domain_p d) { return to_nonconst (new Domain(*to_const(d))); } void tvpiJoin(Domain_p d1, Domain_p d2) { mpz_class w(-1); to_nonconst(d2)->joinWiden(*to_nonconst(d1 ), w); } ========================== I'm not claiming it's pretty, but it works on several g++ versions. You also need to pass something like -pgml g++ -optl -pg to ghc so it know that it should link using g++ (and thereby linking against the C++ runtime). Hope this helps, Axel. From u.stenzel at web.de Sat Oct 13 14:35:53 2007 From: u.stenzel at web.de (Udo Stenzel) Date: Sat Oct 13 16:29:23 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <470F3DD0.3030502@gmail.com> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <470F3DD0.3030502@gmail.com> Message-ID: <20071013183553.GA3117@web.de> Simon Marlow wrote: > >- Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. > > Cabal 1.2 works all the way back to GHC 6.2. The recommended way to build > new packages with an old GHC will be to upgrade Cabal first. Can it be installed by a user? Because I think my GHC 6.4 always picks up Cabal-1.0, which is installed globally. tar-1.0 then fails through not finding Distribution.Simple. > >- Refrain from renaming stuff. System.Posix is a fine name. > > Who renamed it? It's still called System.Posix AFAIK. tar references System.PosixCompat, which apparently comes from a library called unix-compat. I have no idea why the lib isn't just called unix and the modules not System.Posix.*, for tar works fine with System.Posix.*. > Personally I object to ECT, it's too heavy. I believe versioning belongs > in the package system where it currently is. Well, versioning of shared libraries belongs into the dynamic linker, where it currently is. My gut says, Cabal is more like ld than apt-get. Of course I don't care for the solution ultimately implemented, as long as it works. However, without guidelines for what can be changed between versions of packages, nothing will. > The main problem you seem to be running into is that base previously > contained bytestring, but you need to upgrade bytestring in order to use > binary, right? Actually I'm more annoyed by the many small and unneccessary stumbling blocks right now. I mean, you could easily put an instruction into the INSTALL file that says "if you're on GHC 6.4 or 6.6, register this replacement configuration for base to sanitize it". You cannot write "if you're on 6.4, edit all references to System.PosixCompat, unless you already installed unix-compat, and you absolutely need binary 0.4, unless you're on 6.4, where you want binary 0.3 but need to patch it so it has instance MonadFix Get, etc. pp." there, since something like that just pisses off your users. But yes, base and bytestring not liking each other is the showstopper, since base can neither be hidden nor upgraded. > In that case, I think a reasonable hack is to modify the package > configuration for base to move Data.ByteString from exposed-modules to > hidden-modules (I'd be wary about removing it altogether). Perhaps the > bytestring Setup.lhs should do this automatically when registering? First off, this should be documented. Having bytestring's Setup do the messy registering would be a good solution, I think. A better one than a gazillion Cabal configurations, I might add. -Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20071013/d5d1048d/attachment.bin From bringert at cs.chalmers.se Sat Oct 13 17:28:09 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Sat Oct 13 17:25:48 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071013183553.GA3117@web.de> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <470F3DD0.3030502@gmail.com> <20071013183553.GA3117@web.de> Message-ID: <4F6ABE1C-A5D1-4914-B669-3DFA98BCC91B@cs.chalmers.se> On Oct 13, 2007, at 20:35 , Udo Stenzel wrote: > Simon Marlow wrote: >>> - Refrain from renaming stuff. System.Posix is a fine name. >> >> Who renamed it? It's still called System.Posix AFAIK. > > tar references System.PosixCompat, which apparently comes from a > library > called unix-compat. I have no idea why the lib isn't just called unix > and the modules not System.Posix.*, for tar works fine with > System.Posix.*. The tar package uses System.PosixCompat from the unix-compat package to also work under non-posix systems (read Windows). This dependency is listed in the tar.cabal file (see http://hackage.haskell.org/ packages/archive/tar/0.1/tar.cabal). System.Posix was never renamed. >> The main problem you seem to be running into is that base previously >> contained bytestring, but you need to upgrade bytestring in order >> to use >> binary, right? > > Actually I'm more annoyed by the many small and unneccessary stumbling > blocks right now. I mean, you could easily put an instruction into > the > INSTALL file that says "if you're on GHC 6.4 or 6.6, register this > replacement configuration for base to sanitize it". You cannot write > "if you're on 6.4, edit all references to System.PosixCompat, > unless you > already installed unix-compat, and you absolutely need binary 0.4, > unless you're on 6.4, where you want binary 0.3 but need to patch > it so > it has instance MonadFix Get, etc. pp." there, since something like > that > just pisses off your users. Why not just install unix-compat? It is listed as a dependency after all. I seem to be able to build the tar package against binary-0.3. What exactly is the error that you are getting? By the way, I don't think that users of open source software have a right to be pissed off, or at least authors don't have an obligation to care about them being pissed off. What users do have is a right to submit patches. That said, I agree that the constantly changing packages make it hard to keep dependencies up to date. I guess that this is price we pay for moving quickly. At some point, however, we will have to stop breaking things. /Bj?rn From u.stenzel at web.de Sun Oct 14 08:06:09 2007 From: u.stenzel at web.de (Udo Stenzel) Date: Sun Oct 14 08:31:14 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4F6ABE1C-A5D1-4914-B669-3DFA98BCC91B@cs.chalmers.se> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <470F3DD0.3030502@gmail.com> <20071013183553.GA3117@web.de> <4F6ABE1C-A5D1-4914-B669-3DFA98BCC91B@cs.chalmers.se> Message-ID: <20071014120608.GA4256@web.de> Bjorn Bringert wrote: > The tar package uses System.PosixCompat from the unix-compat package > to also work under non-posix systems (read Windows). This dependency > is listed in the tar.cabal file (see http://hackage.haskell.org/ > packages/archive/tar/0.1/tar.cabal). System.Posix was never renamed. > [...] > Why not just install unix-compat? It is listed as a dependency after > all. Actually Windows claims to be a Posix system, too (not that I really believe it or care much). Iirc, unix-compat blew up on GHC 6.4, too, again by picking up the wrong Cabal. I'll check this again tomorrow (don't have access to that machine right now). Anyway, I don't see why something that provides the same functionality as something else needs a different name. With the mechanism of something like apt (Provides, Conflicts, Replaces, ...) I'd have no problem, but Cabal doesn't do that stuff. Maybe it should, though. > I seem to be able to build the tar package against binary-0.3. What > exactly is the error that you are getting? No "instance MonadFix Get" (from memory, I can check this again once I calm down...) > By the way, I don't think that users of open source software have a > right to be pissed off, or at least authors don't have an obligation > to care about them being pissed off. What users do have is a right to > submit patches. No sir, I always have a right to be pissed off. What I don't have is a right to demand anything from you. The problem with patches is how do you patch something as thoroughly messed up as 'base-2.0' vs. 'base-2.1' vs. 'base-2.1.1'? If I saw a way to fix it, you'd already have a patch, but all I have right now is a GHC with an afroengineered package configuration and a mutilated tar package... > That said, I agree that the constantly changing packages make it hard > to keep dependencies up to date. Moreover, the conical place to find packages is Hackage, right? Tar is there, unix-compat is and binary is, too. But bytestring is missing. Which means you have to hunt down bytestring separately, and cabal-get will fail, too. It also means that some of these packages cannot work on any released version of GHC. > I guess that this is price we pay for moving quickly. Is it impossible to move quickly on GHC 6.4? -Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20071014/4b227bc0/attachment.bin From igloo at earth.li Sun Oct 14 10:09:22 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Oct 14 10:07:42 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071011232711.GB2972@web.de> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> Message-ID: <20071014140922.GA25871@matrix.chaos.earth.li> Hi Udo, On Fri, Oct 12, 2007 at 01:27:11AM +0200, Udo Stenzel wrote: > > - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one > is still alive!) that removes the conflict between 'base' and > 'bytestring' and pretends to provide bytestring, containers, array, > etc. People interested in making it easy to use new versions of packages with old compiler releases can make a small script that installs empty Cabal packages called bytestring, containers, array, etc. Then link to it from appropriate places on the wikis, and everyone can benefit from it. Thanks Ian From u.stenzel at web.de Sun Oct 14 11:19:31 2007 From: u.stenzel at web.de (Udo Stenzel) Date: Sun Oct 14 12:29:20 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071014140922.GA25871@matrix.chaos.earth.li> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <20071014140922.GA25871@matrix.chaos.earth.li> Message-ID: <20071014151930.GB4256@web.de> Ian Lynagh wrote: > People interested in making it easy to use new versions of packages with > old compiler releases can make a small script that installs empty Cabal > packages called bytestring, containers, array, etc. That completely misses the fact that bytestring cannot be upgraded, no matter how many fake packages are available. -Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20071014/3f5b14c7/attachment.bin From igloo at earth.li Sun Oct 14 12:48:40 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Oct 14 12:46:58 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071014151930.GB4256@web.de> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <20071014140922.GA25871@matrix.chaos.earth.li> <20071014151930.GB4256@web.de> Message-ID: <20071014164840.GA19265@matrix.chaos.earth.li> On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote: > Ian Lynagh wrote: > > People interested in making it easy to use new versions of packages with > > old compiler releases can make a small script that installs empty Cabal > > packages called bytestring, containers, array, etc. > > That completely misses the fact that bytestring cannot be upgraded, no > matter how many fake packages are available. Ah, you mean the problem is that it really does depend on some change in bytestring (the internal API?), rather than just having a dependency on the bytestring package? Then yes, things are not so easy. Part of the motivation for splitting up base is so that this sort of thing is easier in the future. Thanks Ian From allbery at ece.cmu.edu Sun Oct 14 13:28:51 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Oct 14 13:27:10 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071014164840.GA19265@matrix.chaos.earth.li> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <20071014140922.GA25871@matrix.chaos.earth.li> <20071014151930.GB4256@web.de> <20071014164840.GA19265@matrix.chaos.earth.li> Message-ID: <2C4170E7-B111-4D20-BAE8-7A841AD8C67D@ece.cmu.edu> On Oct 14, 2007, at 12:48 , Ian Lynagh wrote: > On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote: >> Ian Lynagh wrote: >>> People interested in making it easy to use new versions of >>> packages with >>> old compiler releases can make a small script that installs empty >>> Cabal >>> packages called bytestring, containers, array, etc. >> >> That completely misses the fact that bytestring cannot be >> upgraded, no >> matter how many fake packages are available. > > Ah, you mean the problem is that it really does depend on some > change in > bytestring (the internal API?), rather than just having a > dependency on > the bytestring package? I think dons has said that the latest bytestring depends on some GHC 6.8 internals that can't reasonably be backported, so if you need the new bytestring API, you're kinda stuck. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From claus.reinke at talk21.com Sun Oct 14 13:47:30 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Oct 14 13:45:55 2007 Subject: [Haskell] Re: Trying to install binary-0.4 References: <470CCAED.4010702@cogito.org.uk><20071010142229.GA30114@scytale.galois.com><20071011232711.GB2972@web.de> <20071014140922.GA25871@matrix.chaos.earth.li> Message-ID: <00fd01c80e8a$4c34e5f0$21358351@cr3lt> >> - Provide a replacement configuration for GHC 6.6 and 6.4 (yes, that one >> is still alive!) that removes the conflict between 'base' and >> 'bytestring' and pretends to provide bytestring, containers, array, >> etc. > > People interested in making it easy to use new versions of packages with > old compiler releases can make a small script that installs empty Cabal > packages called bytestring, containers, array, etc. there are implicit assumptions in most package managers: - unless you ask for a specific package version, any version will do - if you need a minimum feature set, giving a *lower* bound for the package version will do unless you want to keep updating your package spec every time a new version of a dependency comes out, you really do not want to give *upper* bounds on package versions. haskell software frequently violates both assumptions, deprecating features for one or two a minor versions, then abandoning them in the next. but calling "split-base" "base" goes directly against all basic assumptions of all packages depending on "base". i don't know whether the first intel ai should really still be expected to run the original excel code without change, but suggesting that people keep going back to make old software compatible with continuosly changing new assumptions does not sound right at all. claus From conal at conal.net Mon Oct 15 01:32:58 2007 From: conal at conal.net (Conal Elliott) Date: Mon Oct 15 01:31:15 2007 Subject: [Haskell] pretty-printing Haskell with automatic parens? Message-ID: The haskell-src package contains a pretty-printer for Haskell syntax that requires parentheses to be explicitly placed in the (abstract) syntax representation. I have some code for automatically inserting parentheses where necessary (for use before pretty-printing), but I'm guessing someone else has done so better than I. Does anyone have pointers? I'm glad to share my version as well. Cheers, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20071014/2fb3f341/attachment.htm From thiemann at informatik.uni-freiburg.de Mon Oct 15 02:03:34 2007 From: thiemann at informatik.uni-freiburg.de (Peter Thiemann) Date: Mon Oct 15 02:01:53 2007 Subject: [Haskell] PLAN-X 2008 Deadline approaching Message-ID: <471302B6.6060902@informatik.uni-freiburg.de> Call for Papers and Demos ========================= ****** Abstract deadline: Oct. 17, 2007 ****** Paper deadline: Oct. 22, 2007 PLAN-X 2008 --- Programming Language Techniques for XML ACM SIGPLAN Workshop colocated with POPL 2008 San Francisco, California, USA - 9 January 2008 http://gemo.futurs.inria.fr/events/PLANX2008/ The PLAN-X 2008 workshop is the forum to present and discuss bleeding-edge research at the intersection of programming language and data base technology with an emphasis on tree-shaped data structures and their XML representation. Topics of interest are all aspects of XML processing and querying: theories, methodologies, paradigms, language designs, types, analyses, runtime aspects, implementations, tools, applications. This edition of PLAN-X is particularly interested in blending the XML processing approaches developed by the programming languages and data management communities. Expressive power and high performance are among the common goals that these communities pursue. We encourage the submission of crosscutting contributions that apply techniques from one community to problems from the other. The primary criteria for paper selection are originality, relevance, and timeliness to ensure that we can enjoy reports on ongoing and unfinished work with high potential in the workshop. Submissions =========== We seek submissions in two categories * regular papers (10 pages, 30 minutes presentation) * demo papers (4 pages, 10 minutes plenary presentation + 30 minutes slot for individual discussions shared with other demos) For details see the submission instructions on http://gemo.futurs.inria.fr/events/PLANX2008/?page=subm Important Dates =============== Abstract deadline *** 17 October 2007 Submission deadline *** 22 October 2007 Notification 30 November 2007 Final papers due 14 December 2007 Program Committee ================= Veronique Benzaken Universit? de Paris-Sud 11, France Alin Deutsch University of California, San Diego, USA Wenfei Fan University of Edinburgh, UK Mary Fernandez ATT Research, USA Haruo Hosoya University of Tokyo, Japan Ralf L?mmel Universit?t Koblenz, Germany Sebastian Maneth National ICT and UNSW, Sydney, Australia Jim Melton Oracle Corporation, USA Michael Schwartzbach University of Aarhus, Denmark J?r?me Vouillon CNRS, France Ioana Manolescu (general chair) Gemo group, INRIA Futurs, France Peter Thiemann (program chair) University of Freiburg, Germany From nr at eecs.harvard.edu Mon Oct 15 13:32:09 2007 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Mon Oct 15 13:30:28 2007 Subject: [Haskell] Fingerprints and hashing In-Reply-To: (sfid-H20071011-054253-+038.97-1@spamfilter.osbf.lua) References: (sfid-H20071011-054253-+038.97-1@spamfilter.osbf.lua) Message-ID: <20071015173210.655921EB166@labrador.eecs.harvard.edu> Simon Peyton Jones writes: > We are all familiar with the idea of an MD5 checksum, which provides a > reliable "fingerprint" for a file, usually 128 bits or so... > For various applications (including identifying common sub-expressions, and > version tracking in GHC), I'd like a Haskell library that supports simple > fingerprint operations... > > Below I give an informal specification of such a library. I can think of > any number of implementations, but I'd like one that is (a) robust and (b) > efficient. By "robust" I meant that with, say, a 128-bit fingerprint the > chance of accidental collision is truly low; a non-robust implementation > uses the 128-bit space in a non-uniform way [trivial example: gets stuck on > zero]... > The module signature would be something like this: > > data Fingerprint > initialPrint :: Fingerprint > > class Fingerprintable t where > fingerPrint :: t -> Fingerprint -> FingerPrint > > instance Fingerprintable Char > instance Fingerprintable Int > instance Fingerprintable Word32 > -- etc > > The fingerPrint operation here is expressed in the traditional way: an > accumulator (say 128 bits) into which one stuffs successive values (e.g. a > byte stream). > > However, very important, I also want a more compositional form: > > instance Fingerprintable Fingerprint > > so that I can do something like > > fp :: Expr -> Fingerprint > fp (App e1 e2) = fp e1 `fingerPrint` fp e2 [For Salil anad Michael: apply the fingerPrint function to a fingerprint] > An obvious implementation of "instance Fingerprintable Fingerprint" is to > divide one fingerprint into words, and feed it into the other via the > Word32 instance. But it's not clear to me whether or not that is robust... > > I'd like one other thing: to be able to trade cost for accuracy. I'd like > a 128-bit fingerprint with essentially zero chance of having two distinct > values that map to the same fingerprint; and a one-word fingerprint that > was a lot more efficient, but where collisions would be entirely possible > (again hash-consing is an example). Simon, If I wanted this functionality, I'd call in the professionals (like Salil Vadhan, Michael Rabin, and Andrei Broder, whom I have cc'ed on this message). You sent this mail to the Haskell list, but I think the Haskell content of this problem is trivial compared to the algorithmic problems you pose. I remember, for example, a problem in the distant past of SRC Modula-3, where fingerprinting did not behave as expected because the source of the fingerprint module was itself fingerprinted. Here are some algorithmic references: http://tinyurl.com/yoeusg, http://tinyurl.com/2a2yfj - Modula-3 code for compositional 64-bit fingerprints, polynomial chosen by (literally) flipping a coin http://citeseer.ist.psu.edu/broder93some.html - Andrei's paper on applications of fingerprinting How does laziness play into this problem? If you don't mind building up a lot of thunks, you can probably just use several fingerprinting algorithms in parallel and then pull just the one you need... Norman From nr at eecs.harvard.edu Mon Oct 15 13:39:07 2007 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Mon Oct 15 13:37:27 2007 Subject: [Haskell] pretty-printing Haskell with automatic parens? In-Reply-To: (sfid-H20071015-013318-+036.55-1@spamfilter.osbf.lua) References: (sfid-H20071015-013318-+036.55-1@spamfilter.osbf.lua) Message-ID: <20071015173907.390901EB166@labrador.eecs.harvard.edu> > The haskell-src package contains a pretty-printer for Haskell syntax that > requires parentheses to be explicitly placed in the (abstract) syntax > representation. I have some code for automatically inserting parentheses > where necessary (for use before pretty-printing), but I'm guessing someone > else has done so better than I. Does anyone have pointers? I'm glad to > share my version as well. Conal, I don't have code, but I did publish an algorithm for inserting parentheses minimally: http://tinyurl.com/24xbp7 There's code on that page but I'm sorry to say it's ML code :-( Norman From dons at galois.com Mon Oct 15 13:55:20 2007 From: dons at galois.com (Don Stewart) Date: Mon Oct 15 13:53:40 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071014164840.GA19265@matrix.chaos.earth.li> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> <20071014140922.GA25871@matrix.chaos.earth.li> <20071014151930.GB4256@web.de> <20071014164840.GA19265@matrix.chaos.earth.li> Message-ID: <20071015175520.GG2323@scytale.galois.com> igloo: > On Sun, Oct 14, 2007 at 05:19:31PM +0200, Udo Stenzel wrote: > > Ian Lynagh wrote: > > > People interested in making it easy to use new versions of packages with > > > old compiler releases can make a small script that installs empty Cabal > > > packages called bytestring, containers, array, etc. > > > > That completely misses the fact that bytestring cannot be upgraded, no > > matter how many fake packages are available. > > Ah, you mean the problem is that it really does depend on some change in > bytestring (the internal API?), rather than just having a dependency on > the bytestring package? > > Then yes, things are not so easy. Part of the motivation for splitting > up base is so that this sort of thing is easier in the future. Yes, this was exactly the motivation for not back porting the binary library to 6.4 and earlier: it depends on representation details of ByteString that I'm not going to cpp into portability. If I understand correctly, the main issue for Udo is simply that the MonadFix instance is required by his code, and isn't available in binary 0.3 -- the version to be used on earlier GHCs. Is that right Udo? If that's the case, manually inserting that instance when using binary 0.3 seems easy enough. -- Don From iavor.diatchki at gmail.com Mon Oct 15 15:34:37 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon Oct 15 15:32:53 2007 Subject: [Haskell] Module system question Message-ID: <5ab17e790710151234o4684a8bah39dcccb402222cd0@mail.gmail.com> Hello, I have a question concerning Haskell's module system. Consider the following example which defines three modules A,B, and C: > module A where { data X = X } > module B where { class X a } > module C where { import A; import B; data Y = Y X } The question is: "Is there an ambiguity error in module C?". It seems that the answer depends on how we interpret "ambiguous". In the context of module C, the name X may refer to either the class defined in module B, or the datatype defined in module A. Therefore, we could consider X to be ambiguous, and indeed, this is what happens in GHC 6.6. On the other hand, the name X is used in a context where we are expecting a type constructor and not a class name, and therefore the name X could be unambiguously taken to refer to the datatype X, which is what seems to happen in Hugs. I like the Hugs behavior because it accepts more programs. OTOH, GHC's behavior may be a bit simpler to explain and implement(?). Any thoughts? -Iavor From duncan.coutts at worc.ox.ac.uk Mon Oct 15 17:56:11 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 17:51:39 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071011232711.GB2972@web.de> References: <470CCAED.4010702@cogito.org.uk> <20071010142229.GA30114@scytale.galois.com> <20071011232711.GB2972@web.de> Message-ID: <1192485371.9844.152.camel@localhost> On Fri, 2007-10-12 at 01:27 +0200, Udo Stenzel wrote: > Don Stewart wrote: > > Since you're not using ghc 6.8, you should use binary 0.3 :) > > That was PC for "sorry, GHC 6.6 is no longer supported and don't even > ask about 6.4" As far as I can see, there's no good reason why binary, tar, etc cannot work with ghc-6.4, 6.6 and 6.8. I've made it work for my zlib & iconv libs just fine without too much cpp'ery. So I'm going to try and fix binary, tar etc to work with all recent ghc. Stay tuned. Obviously it'll need the newest Cabal, but that works with all versions of ghc back to 6.2, and it can be installed as user. Duncan From simonpj at microsoft.com Tue Oct 16 06:30:34 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Oct 16 06:28:50 2007 Subject: [Haskell] Module system question In-Reply-To: <5ab17e790710151234o4684a8bah39dcccb402222cd0@mail.gmail.com> References: <5ab17e790710151234o4684a8bah39dcccb402222cd0@mail.gmail.com> Message-ID: The H98 report is pretty clear about there being a single name space for type constructors and classes. Yes, in certain circumstances it's unambiguous. In Hugs, can you write module M where class C a data C = MkC f :: C a => C -> C which is also unambiguous. I'm inclined to stick to the H98 story. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Iavor Diatchki | Sent: 15 October 2007 20:35 | To: haskell@haskell.org | Subject: [Haskell] Module system question | | Hello, | | I have a question concerning Haskell's module system. | Consider the following example which defines three modules A,B, and C: | | > module A where { data X = X } | > module B where { class X a } | > module C where { import A; import B; data Y = Y X } | | The question is: "Is there an ambiguity error in module C?". It seems | that the answer depends on how we interpret "ambiguous". In the | context of module C, the name X may refer to either the class defined | in module B, or the datatype defined in module A. Therefore, we could | consider X to be ambiguous, and indeed, this is what happens in GHC | 6.6. On the other hand, the name X is used in a context where we are | expecting a type constructor and not a class name, and therefore the | name X could be unambiguously taken to refer to the datatype X, which | is what seems to happen in Hugs. | | I like the Hugs behavior because it accepts more programs. OTOH, | GHC's behavior may be a bit simpler to explain and implement(?). Any | thoughts? | | -Iavor | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From iavor.diatchki at gmail.com Tue Oct 16 07:14:54 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Oct 16 07:20:58 2007 Subject: [Haskell] Module system question In-Reply-To: References: <5ab17e790710151234o4684a8bah39dcccb402222cd0@mail.gmail.com> Message-ID: <5ab17e790710160414l5c8e6589v73111c79d32d85da@mail.gmail.com> Hello, On 10/16/07, Simon Peyton-Jones wrote: > The H98 report is pretty clear about there being a single name space for type constructors and classes. Yes, in certain circumstances it's unambiguous. In Hugs, can you write > module M where > class C a > data C = MkC > f :: C a => C -> C > which is also unambiguous. My version of Hugs (20050308) rejects this because it does not allow the definition of a class and a datatype with the same name in the same module. If the class and datatype are imported from different modules (as in the example I gave), then a type signature in Hugs gives a rather strange error which to me looks like a bug :-) ERROR "C.hs":1 - Ambiguous class occurrence "X" *** Could refer to: B.X case.case > I'm inclined to stick to the H98 story. Seems reasonable---the situations where the extra cleverness is useful are probably not that many and, in any case, one can always work around by using a qualified name. I recently noticed that the alternative rule would be quite easy to implement in a compiler that I sometimes play around with, and was wondering if that was what Haskell implementations did anyways. -- Iavor From hg.manuel at gmail.com Tue Oct 16 17:50:25 2007 From: hg.manuel at gmail.com (Manuel Hernandez) Date: Tue Oct 16 17:48:37 2007 Subject: [Haskell] IN Doubt... Message-ID: Dear Haskellers, why this program is not accepted by Hugs? equal a a = True equal a b | not(a==b) = False Best, Manher -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20071016/12b22b64/attachment.htm From dons at galois.com Tue Oct 16 17:52:50 2007 From: dons at galois.com (Don Stewart) Date: Tue Oct 16 17:51:08 2007 Subject: [Haskell] IN Doubt... In-Reply-To: References: Message-ID: <20071016215250.GT15214@scytale.galois.com> hg.manuel: > Dear Haskellers, > > why this program is not accepted by Hugs? > > equal a a = True > equal a b | not(a==b) = False You can't pattern match 'a' and 'a' like that -- there's no implicit unification. Instead, I'd write: equal a b | a == b = True | otherwise = False Well actually, maybe I'd write: equal a b = a == b In reality, though: equal = (==) And then I'd just use (==) directly :) Cheers, Don From jpeliz at icmc.usp.br Tue Oct 16 21:32:46 2007 From: jpeliz at icmc.usp.br (Jorge Marques Pelizzoni) Date: Tue Oct 16 21:31:13 2007 Subject: [Haskell] [Fwd: undecidable & overlapping instances: a bug?] Message-ID: <10895.200.158.223.162.1192584766.squirrel@mail2.icmc.usp.br> Hi, all! It's been a while since I sent the message below to the GHC list, which I believe is its rightful forum, but I've had no reply so far. So I am giving the haskell list a try. Thanks in advance. Cheers, Jorge. --------------------------- Mensagem Original ---------------------------- Assunto: undecidable & overlapping instances: a bug? De: "Jorge Marques Pelizzoni" Data: Sab, Outubro 13, 2007 5:59 am Para: "GHC users" -------------------------------------------------------------------------- Hi, all! I am quite intrigued at the behaviour examplified in the attached module. It's true I am a newbie and probably don't quite get the whole consequence spectrum of -fallow-undecidable-instances, but why providing that dummy instance (commented out) get the thing to compile? By the way, I'm using GHC 6.6 on WinXP (actually, latest Visual Haskell with MS Visual Studio 2005) and the error message I get is: FooModule.hs:13:9: Could not deduce (Show a) from the context (Concrete a b) arising from use of `bar' at FooModule.hs:13:9-13 Possible fix: add (Show a) to the class or instance method `foo' In the expression: bar x In the definition of `foo': foo x = bar x In the definition for method `foo' A second question: which kinds of overlapping are covered by -fallow-overlapping-instances? It seems that the following (also in the attached module) is not allowed: instance (Show a, Abstract a b) => Concrete a b where foo x = show x instance (Abstract a b) => Concrete a b which gives me the message: FooModule.hs:17:0: Duplicate instance declarations: instance [overlap ok] (Show a, Abstract a b) => Concrete a b -- Defined at FooModule.hs:17:0 instance [overlap ok] (Abstract a b) => Concrete a b -- Defined at FooModule.hs:30:0 Thanks in advance for any pointers. Cheers, Jorge. -------------- next part -------------- A non-text attachment was scrubbed... Name: FooModule.hs Type: application/octet-stream Size: 685 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell/attachments/20071016/1f6a6fe3/FooModule.obj From john at repetae.net Tue Oct 16 21:59:52 2007 From: john at repetae.net (John Meacham) Date: Tue Oct 16 21:58:01 2007 Subject: [Haskell] Module system question In-Reply-To: <5ab17e790710151234o4684a8bah39dcccb402222cd0@mail.gmail.com> References: <5ab17e790710151234o4684a8bah39dcccb402222cd0@mail.gmail.com> Message-ID: <20071017015952.GC4040@momenergy.repetae.net> On Mon, Oct 15, 2007 at 10:34:37PM +0300, Iavor Diatchki wrote: > I like the Hugs behavior because it accepts more programs. OTOH, > GHC's behavior may be a bit simpler to explain and implement(?). Any > thoughts? Currently, the class and datatype namespaces are considered the same by the standard. There is no particular reason this needs to be the case as they can always be disambiguated syntactically except in the one case of export/import lists. Some of the proposed module system changes for haskell' address this issue, which would allow fully separate namespaces for the two. Although I am not sure exactly what form it will take, I would like some reworking of the module system to allow this change in haskell'. There are some concrete proposals on the wiki, I have been meaning to make a grand unified proposal at some point that incorperates all the proposed changes (and incidentally, more importantly, proves compatibility between them) to the module system so that we may consider it. Not that I think all the proposals should go in or not as a unit, but it will give us a concrete theoretically implementable superset of all the proposals to think about and illuminate any interactions between proposals that might not be obvious when considered separately. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Wed Oct 17 04:14:26 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 17 04:12:46 2007 Subject: [Haskell] [Fwd: undecidable & overlapping instances: a bug?] In-Reply-To: <10895.200.158.223.162.1192584766.squirrel@mail2.icmc.usp.br> References: <10895.200.158.223.162.1192584766.squirrel@mail2.icmc.usp.br> Message-ID: | I am quite intrigued at the behaviour examplified in the attached module. | It's true I am a newbie and probably don't quite get the whole consequence | spectrum of -fallow-undecidable-instances, but why providing that dummy | instance (commented out) get the thing to compile? Sorry I must have missed this. It's a nice example of the trickiness of functional dependencies. Here's what is happening. First a very cut-down version of your example: class Concrete a b | a -> b where bar :: a -> String instance (Show a) => Concrete a b wib :: Concrete a b => a -> String wib x = bar x Now consider type inference for 'wib'. GHC figures out that the call of 'bar' gives rise to the constraint (Concrete p q), where x has type 'p'. Ah, but x must have type 'a', so the constraint is (Concrete a q). Now GHC tries to satisfy (Concrete a q) from (Concrete a b). If it applied improvement right away it'd succeed, but sadly it first looks at instances declarations. Success: we can get (Concrete a q) from (Show a). So it uses the instance decl and now we can't get (Show a) from (Concrete a b). OK, so you found that adding instance Concrete Bool Bool fixed the problem. That's weird isn't it? The reason is this. When GHC looks at the instance decls, it now sees *two* instance decls matching (Concrete a q), and so it declines for now to use either of them (since it's not clear which would be the right one). Once it has finished with instance decls it tries improvement. And, yes, it now sees that q=b, so all is well. You might say that GHC should use improvement more vigorously, and perhaps you'd be right. And indeed the upcoming GHC 6.8 does exactly that. But it's a great example of the delicacy of type inference in the presence of equalities. I'm going to add it to GHC's test suite! Simon From voigt at tcs.inf.tu-dresden.de Wed Oct 17 07:45:15 2007 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed Oct 17 07:43:25 2007 Subject: [Haskell] Announce: generating free theorems, online and offline Message-ID: <4715F5CB.8080006@tcs.inf.tu-dresden.de> A while back I announced a library and tools for generating free theorems from Haskell types: http://www.haskell.org/pipermail/haskell/2006-August/018426.html There is now an improved version with new features. To try it out online, visit: http://linux.tcs.inf.tu-dresden.de/~voigt/ft Highlights are: - support for type classes (e.g., enter "elem" and note the generated respects-restrictions) - three different language subsets to choose from, including one that takes selective strictness into account and thus gives theorems that are valid even in the presence of seq and friends (e.g., enter "filter" and compare the outputs for the three language subsets) - equational as well as inequational free theorems, the latter often coming with less restrictive preconditions, and thus being applicable where equational free theorems are not (e.g., enter "head" and compare the outputs in equational vs. inequational style for the second or third language subset) The source code of the library is available from: http://wwwtcs.inf.tu-dresden.de/~voigt/dist.tar.gz This package additionally contains a shell-like interface to the library, giving more control than the web interface. In particular, using it one can declare one's own algebraic data types, type synonyms, type renamings and type classes, and then generate free theorems for types involving those. Credits for the implementation are due to Sascha Boehme! Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From ajb at spamcop.net Wed Oct 17 08:16:46 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Oct 17 08:15:07 2007 Subject: [Haskell] Announce: generating free theorems, online and offline In-Reply-To: <4715F5CB.8080006@tcs.inf.tu-dresden.de> References: <4715F5CB.8080006@tcs.inf.tu-dresden.de> Message-ID: <20071017081646.vijytz8mdcw48cok@webmail.spamcop.net> [Ccing to haskell-cafe; please direct any replies there instead of haskell] G'day all. First of all, once again well done to Sascha on a great tool. Just a few comments. Quoting Janis Voigtlaender : > - support for type classes > (e.g., enter "elem" and note the generated respects-restrictions) This is a great feature, and it'll be even better when constructor classes are done. Some of these respects-restrictions arent as useful as they might be, because they don't take into account easily-predictable invariants. For example, the type: (Eq a) => [a] -> [a] generates the following restriction: g respects Eq if forall x :: t1. forall y :: t1. (==) x y = (==) (g x) (g y) forall x :: t1. forall y :: t1. (/=) x y = (/=) (g x) (g y) Thats correct, but redundant, because (x == y) = (g x == g y) if and only if (x /= y) = (g x /= g y). Crucially, you can work this out from the definition of Eq, because (/=) has a default implementation defined in terms of (==) alone. The type (Monoid a) => [a] -> a gives: forall t1,t2 in TYPES(Monoid), g :: t1 -> t2, g respects Monoid. forall x :: [t1]. g (f x) = f (map g x) The class restriction occurring therein is defined as follows: g respects Monoid if g mempty = mempty forall x :: t1. forall y :: t1. g (mappend x y) = mappend (g x) (g y) forall (x, y) in lift{[]}(g). g (mconcat x) = mconcat y Again, mconcat is redundant. Even more curiously, though, map appears in the theorem, but lift{[]} appears in the class restriction. Cheers, Andrew Bromage From mpj at cs.pdx.edu Wed Oct 17 13:22:47 2007 From: mpj at cs.pdx.edu (Mark P Jones) Date: Wed Oct 17 13:20:10 2007 Subject: [Haskell] [Fwd: undecidable & overlapping instances: a bug?] In-Reply-To: References: <10895.200.158.223.162.1192584766.squirrel@mail2.icmc.usp.br> Message-ID: <471644E7.5000806@cs.pdx.edu> Simon Peyton-Jones wrote: > | I am quite intrigued at the behaviour examplified in the attached module. > | It's true I am a newbie and probably don't quite get the whole consequence > | spectrum of -fallow-undecidable-instances, but why providing that dummy > | instance (commented out) get the thing to compile? > > Sorry I must have missed this. It's a nice example of the trickiness of > functional dependencies. Here's what is happening. First a very cut-down > version of your example: > > class Concrete a b | a -> b where > bar :: a -> String > > instance (Show a) => Concrete a b > > wib :: Concrete a b => a -> String > wib x = bar x > > Now consider type inference for 'wib'. ... Hold on a second! There's a more serious problem here, before we get to 'wib'. The definition of class Concrete asserts that there is a dependency from a to b. In other words, it promises that, for any a, there must be at most one b such that Concrete a b holds. But then the following instance declaration says that Concrete a b can be instantiated for *any* a and b, the only proviso being that a is an instance of Show. In particular, there is no functional relationship between the parameters. As such, these two declarations are in direct conflict with one another! To quote the error message that Hugs produces, the "Instance is more general than a dependency allows". I thought this must be a typo in your email, but then I discovered that the ghci (6.6.1) installed on my machine accepts this code, at least once the Concrete Bool Bool instance was added. If the instance declarations are not consistent with the functional dependency, then improvement is unsound, and all bets are off! Further experiments suggest that this behavior occurs only when the-fallow-undecidable-instances flag is specified. But the reason you need to check for consistency between instance declarations and dependencies is to ensure soundness, not decidability. I don't know if this was the problem in the original example, but perhaps we should debug this cut down version first :-) All the best, Mark From iavor.diatchki at gmail.com Wed Oct 17 14:18:40 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed Oct 17 14:16:48 2007 Subject: [Haskell] [Fwd: undecidable & overlapping instances: a bug?] In-Reply-To: <471644E7.5000806@cs.pdx.edu> References: <10895.200.158.223.162.1192584766.squirrel@mail2.icmc.usp.br> <471644E7.5000806@cs.pdx.edu> Message-ID: <5ab17e790710171118l396d27f6gc27329bf718c832c@mail.gmail.com> Hi, Mark is quite right, and there is a bug report that documents the problem: http://hackage.haskell.org/trac/ghc/ticket/1241 The trac ticket is targeting GHC 6.8 but the ticket is still open. I have not had a chance to try out any of the 6.8 release candidates yet, so I am not sure if there have been changes in this area. -Iavor On 10/17/07, Mark P Jones wrote: > Simon Peyton-Jones wrote: > > | I am quite intrigued at the behaviour examplified in the attached module. > > | It's true I am a newbie and probably don't quite get the whole consequence > > | spectrum of -fallow-undecidable-instances, but why providing that dummy > > | instance (commented out) get the thing to compile? > > > > Sorry I must have missed this. It's a nice example of the trickiness of > > functional dependencies. Here's what is happening. First a very cut-down > > version of your example: > > > > class Concrete a b | a -> b where > > bar :: a -> String > > > > instance (Show a) => Concrete a b > > > > wib :: Concrete a b => a -> String > > wib x = bar x > > > > Now consider type inference for 'wib'. ... > > Hold on a second! There's a more serious problem here, before we > get to 'wib'. The definition of class Concrete asserts that there > is a dependency from a to b. In other words, it promises that, for > any a, there must be at most one b such that Concrete a b holds. > But then the following instance declaration says that Concrete a b > can be instantiated for *any* a and b, the only proviso being that a > is an instance of Show. In particular, there is no functional > relationship between the parameters. As such, these two > declarations are in direct conflict with one an