From dix at in.tu-clausthal.de Thu Sep 1 06:48:52 2005 From: dix at in.tu-clausthal.de (Juergen Dix) Date: Thu Sep 1 12:25:06 2005 Subject: [Haskell] [CfP] Special Issue on Answer Set Programming (ASP) in Annals of Mathematics and Artificial Intelligence Message-ID: <20050901104852.GF17908@in.tu-clausthal.de> [we apologize for multiple copies of this e-mail] ---------------------------------------------------------------------- Call for Papers: Special Issue on Answer Set Programming (ASP) in Annals of Mathematics and Artificial Intelligence http://cig.in.tu-clausthal.de/ASP06/ * Special Issue Editors: Gerhard Brewka (University of Leipzig, Germany) Juergen Dix (Clausthal University of Technology, Germany) * About the Special Issue: Answer set programming (ASP) is a promising declarative programming paradigm which has proven to be successful in a variety of areas such as planning, diagnosis, configuration and space shuttle control. It emerged from deductive databases as wellas from non-monotonic reasoning. Answer sets are sets of literals representing intended models of generalized logic programs with two types of negation. They were introduced by Gelfond and Lifschitz and generalize stable models to more expressive logic programs. The basic idea underlying ASP is to represent a problem in a way such that answer sets correspond to solutions of the problem. A Working Group on ASP funded by the EC (http://wasp.unime.it/) coordinates and represents most of the work on ASP done in Europe. We invite papers describing original research advancing the state of the art in ASP. Contributions may range from theoretical foundations (e.g. language extensions, first order programs) to implementation methods (e.g. new answer set generation methods, intelligent grounding or related heuristics) and innovative applications (e.g. information extraction, agent technology,dynamic systems). In particular applications showing that ASP scales up or is competing with special-purpose techniques are welcome. * Relevant topics include the following (but are not limited to): - Foundations of ASP - Systems of ASP - Algorithms and heuristics - Language extensions (aggregates, preferences , etc.) - Integrated approaches (description logic, constraints, etc.) - ASP methodology (modularization, debugging etc.) - Planning in ASP - Knowledge representation in ASP - Innovative applications (bioinformatics, linguistics, etc.) * Submission Details: We are expecting full papers to describe original, previously unpublished research, be written in English, and not be simultaneously submitted for publication elsewhere (previous publication of partial results at workshops with informal proceedings is allowed). Papers should be formatted according to the Instructions for AMAI submissions and should be between 20 and 40 pages long. (www.springeronline.com/journal/10472/submission) Please submit a PDF file of your paper by the 1st of December2005 at http://cig.in.tu-clausthal.de/ASP06/ (click on Submissions: you can enter your paper into the easychair system provided by Andrei Voronkov). * Important Dates: Submission Deadline: December 1, 2005 Author Notification: February 1, 2006 Final Paper Deadline: April 1, 2006 Special Issue: Fall 2006 * About the special issue editors: Gerhard Brewka is Professor for Intelligent Systems at Leipzig University (Germany) since 1996. Before that he was Professor for Knowledge-Based Systems at Technical University of Vienna. He is director of the Leipzig doctoral programme in Knowledge Representation. His research interests include knowledge representation, nonmonotonic reasoning, inconsistency handling, preference models and logic programming. Juergen Dix is Professor for Computational Intelligence at Clausthal University of Technology (Germany) (http://cig.in.tu-clausthal.de/). He is also member of the CS Department at the Technical University of Vienna, and honorary member at The University of Manchester, where he lived from 2000-2003. Since 1989 he is working in several areas of Computational Logic (nonmonotonic reasoning, logic programming, deductive databases, knowledge representation) and, in the past 7 years, also in Multi-Agent Reasoning. * About the journal: Annals of Mathematics and Artificial Intelligence (AMAI) is devoted to reporting significant contributions on the interaction of mathematical and computational techniques reflecting the evolving disciplines of artificial intelligence: http://www.informatik.uni-trier.de/~ley/db/journals/amai/. Annals of Mathematics and Artificial Intelligence publishes edited volumes of original manuscripts, survey articles, monographs and well refereed conference proceedings of the highest caliber within this increasingly important field. All papers will be subject to the peer reviewing process with at least two referees per paper. ------------------------------------------------------------------------ This e-mail was delivered to you by event@in.tu-clausthal.de, what is a moderated list runned by Computational Intelligence Group of Technical University of Clausthal, Germany. All event announcements sent through this list are also listed in our conference planner at http://cig.in.tu-clausthal.de/index.php?id=planner. In the case of any requests, questions, or comments, do not hesitate and contact event-owner@in.tu-clausthal.de ASAP. ****************************************************** * CIG does not take any responsibility for validity * * of content of messages sent through this list. * ****************************************************** Computational Intelligence Group Institute of Informatics Technical University Clausthal Germany http://cig.in.tu-clausthal.de/ From Horatiu.Cirstea at loria.fr Thu Sep 1 11:44:29 2005 From: Horatiu.Cirstea at loria.fr (Horatiu Cirstea) Date: Thu Sep 1 12:25:06 2005 Subject: [Haskell] Rewriting Calculi and Higher-Order Reductions - special issue of MSCS Message-ID: <74214E28-1954-4F20-9F55-E85713061548@loria.fr> CALL FOR PAPERS Mathematical Structures in Computer Science, Special Issue on Rewriting Calculi and Higher-Order Reductions Following from the success of the workshops on rewriting calculus, there will be a special issue of the journal Mathematical Structures in Computer Science (MSCS, Cambridge University Press) on Rewriting Calculi and Higher-Order Reductions. Submissions for this special issue are hereby solicited. The integration of first-order and higher-order paradigms has been one of the main problems raised since the beginning of the study of programming language semantics and of proof environments. This has been handled either by enriching first-order rewriting with higher-order capabilities or by adding to lambda-calculus algebraic features. The rewriting calculus has been introduced as a general means to uniformly integrate rewriting and lambda calculus. This calculus makes explicit and first-class all of its components: matching (possibly modulo given theories), abstraction, application and substitutions. The rewriting calculus is designed and used for logical and semantical purposes. It could be used with powerful type systems and for expressing the semantics of rule based as well as object oriented paradigms. It allows one to naturally express exceptions and imperative features as well as expressing elaborated rewriting strategies. This special issue of the MSCS will be devoted to the foundations of the rewriting calculus and of related systems combining matching and higher-order features. Topics for the special issue include, but are not limited to, the following aspects of these calculi: - operational semantics, - type systems, - models, - associated logics, - implementation issues, - applications. Submissions should be sent electronically to rho-editors@loria.fr by 15th January 2006 (all submissions will be acknowledged). Information about the journal, including style files, can be found at: http://www.cambridge.org/uk/journals/journal_ifc.asp?mnemonic=MSC Submissions will be refereed according to the usual very high standards of MSCS. Horatiu Cirstea and Maribel Fernandez will serve as guest editors for this special issue. Final decisions on editorial matters rest with the editor-in-chief of MSCS. From ijones at syntaxpolice.org Thu Sep 1 20:24:20 2005 From: ijones at syntaxpolice.org (Isaac Jones) Date: Thu Sep 1 21:21:26 2005 Subject: [Haskell] Re: cannot compile ghc on Debian unstable In-Reply-To: (Aaron Denney's message of "Wed, 31 Aug 2005 22:48:06 +0000 (UTC)") References: <20050828050640.C3FC6103BE3@orchestra.cs.caltech.edu> <87vf1ni3o1.fsf@syntaxpolice.org> Message-ID: <87hdd4fhaj.fsf@syntaxpolice.org> Aaron Denney writes: > On 2005-08-30, Isaac Jones wrote: >> Michael Vanier writes: >> >>> Right now, the Debian unstable package for GHC 6.4 won't install due to >>> some conflict with libgmp3 (the package maintainer has been notified). >> >> The trick to getting this to work is to install the libgmp3 from >> stable. >> >> apt-get install libgmp3/stable #or grab it and install it with dpkg >> apt-get install ghc6 >> >> That might work? > > It should, but I have other packages that depend on a newer > version of libgmp3. Well, I've held off on upgrading them, > because of this. I believe that this is fixed now at least for i386. Try apt-get update and apt-get install ghc6. peace, isaac From l2lu at oakland.edu Fri Sep 2 10:43:09 2005 From: l2lu at oakland.edu (Lunjin Lu) Date: Fri Sep 2 11:39:32 2005 Subject: [Haskell] Extended Deadline - ACM SAC'06: Software Verification Message-ID: <20050902144309.7FF8D642B0@grant.sys.oakland.edu> ---------------------------------------------------------------- CALL FOR PAPERS Software Verification Track ACM Symposium on Applied Computing April 23-27, 2006, Dijon, France http://www.cs.wmich.edu/~zijiang/sac2006 ***PAPER SUBMISSION DEADLINE: September 15, 2005**** ----------------------------------------------------------------- 1. SAC 2006 For the last twenty years, the ACM Symposium on Applied Computing has been a primary gathering forum for applied computer scientists, computer engineers, software engineers, and application developers from around the world. SAC 2006 is sponsored by the ACM Special Interest Group on Applied Computing, and is hosted this year by Bourgogne University, Dijon, France. 2. Technical track on software verification In the next decade the software industry will have to face its responsibility imposed by a computer-dependent society. Since software is increasing deployed in safety critical applications, correctness and reliability are becoming issues of utmost importance. Consequently, software verification will be a grand challenge for both academic world and computer industry. The track will focus on theoretical foundations, practical methods as well as case studies for verification of conventional and embedded software. We welcome papers that describe work on combinations of formal verification and program analysis techniques. Tool papers and case studies which report on advances in verifying large software systems are particularly sought. The list of topics includes but not limited to . Tools, and case studies for large scale software verification . Static analysis/Abstract interpretation for verification . Model checking and deductive techniques for software verification . Role of declarative programming languages (such as Prolog) for infinite state software verification. . Proof techniques for verifying specific classes of software . Integration of testing and run-time monitoring with formal techniques . Validation of UML diagrams, and/or requirement specifications . Software certification and proof carrying code . Integration of formal verification into software development projects 3. Guidelines for paper submission Each paper must not exceed 4,000 words and should not be more than 15 pages long using 11 point font and 1 inch margins on all four sides on letter size paper. Papers that fail to comply with length limitations risk rejection. Each submitted paper will be fully referenced and undergo a blind review process. Author(s) must not be identified in the submissions, either explicitly or by implication. Before submitting paper, author(s) should submit a separate cover page that includes title, abstract, list of keywords, and list of authors with full names and postal addresses, telephone numbers, fax numbers, and e-mail addresses. One of the authors must be designated as the primary contact person. Please upload the cover page via http://milo.cs.iupui.edu/sac2006/SubmitAbstract.aspx?TrackID=62. A confirmation email with further instructions on paper submission will be sent to the contact author. Please contact track chairs or Jeff Allen (jallen@cs.iupui.edu) for any problems with submission. Authors of accepted papers must submit an editorial revision of their papers that must fit within five two-column pages following the ACM proceedings format (an extra three extra pages may be available at additional cost to the authors). At least one of the authors of an accepted paper must register for the conference and present the paper. Accepted papers will be published in the ACM SAC 2006 proceedings. 4. Important dates . Electronic submission of full papers: September 15, 2005 . Notification of paper acceptance: October 15, 2005 . Camera-ready copy of accepted paper due: November 5, 2005 5. Program Committee . Franjo Ivancic, NEC Labs America, Inc, U.S.A. . Radu Grosu, SUNY-Stony Brook, U.S.A. . Francesco Logozzo, Ecole Polytechnique, France . Lunjin Lu(Co-Chair), Oakland University, U.S.A. . Madhusudan Parthasarathy, UIUC, U.S.A. . Robby, Kansas State University, U.S.A. . Abhik Roychoudhury, National Univ. Singapore . Fausto Spoto, Univ. di Verona, Italy . Frank Stomp, Wayne State University ,U.S.A. . Zijiang Yang(Co-Chair), Western Michigan University, U.S.A. . Tian Zhao, University of Wisconsin-Milwaukee, U.S.A From dons at cse.unsw.edu.au Sun Sep 4 00:46:46 2005 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sun Sep 4 00:26:25 2005 Subject: [Haskell] mini-announce: h4sh 0.2 In-Reply-To: <20050814062218.GA12441@cse.unsw.EDU.AU> References: <20050814062218.GA12441@cse.unsw.EDU.AU> Message-ID: <20050904044646.GA15271@cse.unsw.EDU.AU> h4sh 0.2 has been released. h4sh has stablised, and this is intended to be the last release for some time. Changes since h4sh 0.1 include: * New functions available in the shell: foldl, foldr, unfoldr, iterate, ($), transpose, group, show, concatMap * Compilation strategies added for a wider range of types. * Removed argument flags. Instead arguments are provided in their Haskell type order. * Renamed some functions to avoid clashes with existing shell commands * Added HOWTO of one-liners. * Cabalised. * Simplified build dependencies. * Added support library of regex operators * Use mmapped FastPackedStrings for IO. Good space and time improvements * Functions expecting a single argument will read from stdin if no argument is provided. * Lift group from a -> [a], to [a] -> [[a]] Get it: darcs get --partial http://www.cse.unsw.edu.au/~dons/code/h4sh Cheers, Don Stewart From frederik at a5.repetae.net Mon Sep 5 02:31:53 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Sep 5 02:11:30 2005 Subject: [Haskell] emacs haskell mode Message-ID: <20050905063153.GC24198@a5.repetae.net> Hi Stefan, Sorry if I've asked this before, but is version 2.0 of haskell-mode on your website really the newest version? I ask because the file haskell-mode.el says "Version: 1.43" in the header, and I thought I remembered certain bugs being fixed which are present in your version. For instance, I thought that "\(x)->x" parsed correctly in the latest version, but in the version 2.0 which you distribute, the backslash is still interpreted incorrectly as escaping the parenthesis. Frederik -- http://ofb.net/~frederik/ From gale at sefer.org Mon Sep 5 05:12:56 2005 From: gale at sefer.org (Yitzchak Gale) Date: Mon Sep 5 04:52:32 2005 Subject: [Haskell] Missing docs on Debian? Message-ID: <20050905091256.GA3136@mail.actcom.co.il> Using Debian testing with the ghc6-doc package installed (version 6.4-3), I just noticed that I only seem to have the "Hierarchical Libraries" manual, but not the "User's Guide" nor the "Cabal" docs (nor hslibs docs). Those links are broken on the "index.html" page that was installed. Did I do something wrong, or is there a reason that those were omitted? Thanks, Yitz From monnier at iro.umontreal.ca Mon Sep 5 11:48:12 2005 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon Sep 5 11:27:43 2005 Subject: [Haskell] Re: emacs haskell mode In-Reply-To: <20050905063153.GC24198@a5.repetae.net> (Frederik Eaton's message of "Sun, 4 Sep 2005 23:31:53 -0700") References: <20050905063153.GC24198@a5.repetae.net> Message-ID: <87oe77qzyd.fsf-monnier+emacs@gnu.org> > Sorry if I've asked this before, but is version 2.0 of haskell-mode on > your website really the newest version? It's the latest released version. There's newer code in the CVS, of course. > I ask because the file haskell-mode.el says "Version: 1.43" in the header, > and I thought I remembered certain bugs being fixed which are present in > your version. For instance, I thought that "\(x)->x" parsed correctly in > the latest version, but in the version 2.0 which you distribute, the > backslash is still interpreted incorrectly as escaping the parenthesis. The backslash problem is only fixed if you use font-lock. Do you use font-lock? Also it may not work in all versions of Emacs. Which version do you use? Stefan From Chad.Scherrer at pnl.gov Mon Sep 5 14:31:00 2005 From: Chad.Scherrer at pnl.gov (Scherrer, Chad) Date: Mon Sep 5 14:12:20 2005 Subject: [Haskell] FunDeps and MArray Message-ID: Hi, I'm trying to use functionally dependent typeclasses to create an overloaded (+=) function. A simplified example of a first bit of code is... class PlusEq a b c | a b -> c where (+=) :: a -> b -> c instance (MArray a e m, Num e, Ix i) => PlusEq (a i e) (a i e) (m ()) where (+=) x y = let updateX i = do xi <- readArray x i yi <- readArray y i writeArray x i (xi + yi) in sequence_ . map updateX $ indices x I keep getting this error in GHCi: Illegal instance declaration for `PlusEq (a i e) (a i e) (m ())' (the instance types do not agree with the functional dependencies of the class) In the instance declaration for `PlusEq (a i e) (a i e) (m ())' Failed, modules loaded: none. Looking at GHC's documentation for MArray, the definition starts out class (HasBounds a, Monad m) => MArray a e m where ... It seems to me if MArray were written using fundeps (something like MArray a e m | a e -> m) things may work out. Is there a reason it's not written this way? If so, is there another way to do what I'm trying to do? Thanks. Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx From ijones at syntaxpolice.org Mon Sep 5 15:38:57 2005 From: ijones at syntaxpolice.org (Isaac Jones) Date: Mon Sep 5 15:20:13 2005 Subject: [Haskell] Missing docs on Debian? In-Reply-To: <20050905091256.GA3136@mail.actcom.co.il> (Yitzchak Gale's message of "Mon, 5 Sep 2005 12:12:56 +0300") References: <20050905091256.GA3136@mail.actcom.co.il> Message-ID: <87wtlve23y.fsf@syntaxpolice.org> Yitzchak Gale writes: > Using Debian testing with the ghc6-doc package > installed (version 6.4-3), It looks to me like this isn't the version from "testing" fwiw, but the version from "unstable". You might want to make sure that your versions of ghc and ghc-doc are consistent. > I just noticed that I only seem to have the "Hierarchical Libraries" > manual, but not the "User's Guide" nor the "Cabal" docs (nor hslibs > docs). Those links are broken on the "index.html" page that was > installed. I'm using unstable w/ ghc6-doc version 6.4-4, and this link: file:///usr/share/doc/ghc6-doc/html/index.html Seems to give me access to each of the user's guide, hierarchical libraries, old hierarchical libraries, and cabal docs. > Did I do something wrong, or is there a reason > that those were omitted? First I would just check to see if this file exists: file:///usr/share/doc/ghc6-doc/html/users_guide/index.html If not, try upgrading to the new version (maybe Ian can say whether there's any fix between -3 and -4). If that doesn't fix it, then you might start to wonder why you have ghc 6.4 with testing; did you get this -doc package from the Haskell Unsafe repository, or from the unstable repository? Finally, file a bug report against the package with "reportbug" if none of the above works. peace, isaac From frederik at a5.repetae.net Mon Sep 5 17:09:01 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Sep 5 16:50:21 2005 Subject: [Haskell] Re: emacs haskell mode In-Reply-To: <87oe77qzyd.fsf-monnier+emacs@gnu.org> References: <20050905063153.GC24198@a5.repetae.net> <87oe77qzyd.fsf-monnier+emacs@gnu.org> Message-ID: <20050905210901.GE24198@a5.repetae.net> On Mon, Sep 05, 2005 at 11:48:12AM -0400, Stefan Monnier wrote: > > Sorry if I've asked this before, but is version 2.0 of haskell-mode on > > your website really the newest version? > > It's the latest released version. There's newer code in the CVS, of course. > > > I ask because the file haskell-mode.el says "Version: 1.43" in the header, > > and I thought I remembered certain bugs being fixed which are present in > > your version. For instance, I thought that "\(x)->x" parsed correctly in > > the latest version, but in the version 2.0 which you distribute, the > > backslash is still interpreted incorrectly as escaping the parenthesis. > > The backslash problem is only fixed if you use font-lock. Do you use > font-lock? Also it may not work in all versions of Emacs. Which version do > you use? Hmm. I use font-lock, but I use xemacs (21.4). Maybe that's the cause of the difference. Frederik -- http://ofb.net/~frederik/ From rturk at science.uva.nl Mon Sep 5 17:24:50 2005 From: rturk at science.uva.nl (Remi Turk) Date: Mon Sep 5 17:06:21 2005 Subject: [Haskell] FunDeps and MArray In-Reply-To: References: Message-ID: <20050905212450.GA850@localhost.lan> On Mon, Sep 05, 2005 at 11:31:00AM -0700, Scherrer, Chad wrote: > I keep getting this error in GHCi: > > Illegal instance declaration for `PlusEq (a i e) (a i e) (m ())' > (the instance types do not agree with the functional dependencies of the class) > In the instance declaration for `PlusEq (a i e) (a i e) (m ())' > Failed, modules loaded: none. > > Looking at GHC's documentation for MArray, the definition starts out > > class (HasBounds a, Monad m) => MArray a e m where > ... > > It seems to me if MArray were written using fundeps (something like > MArray a e m | a e -> m) things may work out. Is there a reason it's not > written this way? If so, is there another way to do what I'm trying to > do? Thanks. I don't know the actual reason, but if it were MArray a e m | a e -> m it would be impossible to define an MArray instance of STArray for both the strict and the lazy ST monad. (There isn't currently an instance for the lazy ST monad, but right now it can easily be defined: http://www.mail-archive.com/haskell-cafe@haskell.org/msg09404.html) Groetjes, Remi -- Nobody can be exactly like me. Even I have trouble doing it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org//pipermail/haskell/attachments/20050905/3146041d/attachment.bin From monnier at iro.umontreal.ca Mon Sep 5 18:53:21 2005 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon Sep 5 18:34:38 2005 Subject: [Haskell] Re: emacs haskell mode In-Reply-To: <20050905210901.GE24198@a5.repetae.net> (Frederik Eaton's message of "Mon, 5 Sep 2005 14:09:01 -0700") References: <20050905063153.GC24198@a5.repetae.net> <87oe77qzyd.fsf-monnier+emacs@gnu.org> <20050905210901.GE24198@a5.repetae.net> Message-ID: <87ek83m8le.fsf-monnier+emacs@gnu.org> > Hmm. I use font-lock, but I use xemacs (21.4). Maybe that's the cause > of the difference. IIRC XEmacs's support for syntax-table text-properties (and more specifically for font-lock-syntactic-keywords) has been generally fairly late. I'd expect it to be fully working by now, but maybe only in 21.5. Try Emacs ;-) Stefan From frederik at a5.repetae.net Mon Sep 5 19:48:37 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Sep 5 19:29:59 2005 Subject: [Haskell] [OT] xemacs (was: Re: emacs haskell mode) In-Reply-To: <87ek83m8le.fsf-monnier+emacs@gnu.org> References: <20050905063153.GC24198@a5.repetae.net> <87oe77qzyd.fsf-monnier+emacs@gnu.org> <20050905210901.GE24198@a5.repetae.net> <87ek83m8le.fsf-monnier+emacs@gnu.org> Message-ID: <20050905234837.GH24198@a5.repetae.net> On Mon, Sep 05, 2005 at 06:53:21PM -0400, Stefan Monnier wrote: > > Hmm. I use font-lock, but I use xemacs (21.4). Maybe that's the cause > > of the difference. > > IIRC XEmacs's support for syntax-table text-properties (and more > specifically for font-lock-syntactic-keywords) has been generally fairly > late. I'd expect it to be fully working by now, but maybe only in 21.5. > > Try Emacs ;-) I switched from emacs to xemacs because of gnuserv/gnuclient. As I understand it, please correct me, but with xemacs "gnuclient" one can attach a "frame" of a server xemacs process to the current terminal. Emacs only supports "emacsclient" which allows you to open a file in a remote server process, but not on the terminal which you run "emacsclient" from, so it's not as useful. The difference means that xemacs can simulate a fast-loading terminal editor, whereas emacs cannot. There are other problems with xemacs - the default syntax-coloring colors are all mapped to "white" on the terminal, for instance, and one has to manually reassign them to standard terminal colors in order to get syntax-coloring to work. I would switch back to emacs if it were not for the above difference. Frederik -- http://ofb.net/~frederik/ From zijiang.yang at wmich.edu Mon Sep 5 14:18:07 2005 From: zijiang.yang at wmich.edu (Zijiang (James) Yang) Date: Tue Sep 6 01:10:57 2005 Subject: [Haskell] SVV'05 CFP: INTERNATIONAL WORKSHOP ON SOFTWARE VERIFICATION AND VALIDATION Message-ID: <431C8BDF.7050501@wmich.edu> -------------------------------------------------------------------------------- CALL FOR PAPERS SVV'05: 3RD INTERNATIONAL WORKSHOP ON SOFTWARE VERIFICATION AND VALIDATION October 31, 2005 Manchester, UK http://www.cs.wmich.edu/~zijiang/svv2005/ In Conjunction with International Conference on Formal Engineering Methods (ICFEM'05) -------------------------------------------------------------------------------- Goal of the Workshop Software is playing an important role in economy, government, and military. Since software is often deployed in safety critical applications, correctness and reliability have become issues of utmost importance. Techniques for verification and validation traditionally fall into three main categories. The first category involves informal methods such as software testing and monitoring. The second involves formal verification, i.e., model checking and theorem proving. The third is abstract interpretation and static program analysis techniques. The goal of this workshop is to promote discussion on novel combinations of these methodologies, as well as study the individual contribution of each of these methodologies in verifying software. An example of a combined verification methodology is the recent research direction that combines abstraction (of infinite-state programs into finite-state ones) with model checking (of finite-state systems). There is a growing conviction in the research community that such hybrid methodologies are imperative for the process of analyzing full-fledged software systems. This workshop will study combination of analysis methodologies for verification of software. This research is very important and timely since . Software is being increasingly used to control embedded systems which are often safety critical (such as automobile parts). . There is renewed promise in program verification in the recent years due to (a) progress in generating models from code, and (b) combination of model checking with other analysis techniques such as abstract interpretation. Topics Covered The workshop will focus on theoretical techniques, practical methods as well as case studies for verification of conventional and embedded software systems. In particular, we welcome papers which describe combinations of formal and informal reasoning, as well as formal verification and program analysis techniques. Tool papers and case studies, which report on advances in verifying large scale programs in standard languages are particularly sought. The list of topics include, but are not restricted to: . Tools, environments and case studies for large scale software verification . Static analysis/Abstract interpretation/Program transformations for verification . Use of model checking and deductive techniques for software verification . Role of declarative programming languages (such as Prolog) for infinite state software verification. . Techniques to validate system software (such as compilers) as well as assembly code/Java bytecode . Proof techniques for verifying specific classes of software (such as object-oriented programs) . Integrating testing and run-time monitoring with formal techniques . Validation of UML diagrams, and/or requirement specifications . Software certification and proof carrying code . Integration of formal verification into software development projects Submissions Information . Regular submissions should be no more than 15 pages. Short papers (upto 5 pages) describing initial ideas are also welcome. All submitted papers should be in PS or PDF. Please avoid using zip, gzip, compress, tar etc. Papers should be submitted via e-mail to zijiang.yang@wmich.edu . The workshop proceeding will be published as Electronic Notes in Theoretical Computer Science (ENTCS). Note that ENTCS papers should be at least 10 pages in ENTCS format. . The deadlines are as follows. . Submission deadline: September 30, 2005 . Notification of Acceptance: October 14, 2005 . Final Version submission: October 21, 2005 Program Committee . Rajeev Alur (University of Pennsylvania, USA) . Tevfik Bultan (University of California, Santa Barbara, USA) . Sandro Etalle (University of Twente, Netherlands) . Daniel Kroning (ETH Zurich, Switzerland) . Lunjin Lu (Oakland University, USA) . C. R. Ramakrishnan (SUNY Stony Brook, USA) . Chao Wang (NEC Laboratories, USA) . Farn Wang (National Taiwan University, Taiwan) . Yi Wang (Uppsala University, Sweden) . Lintao Zhang (Micosoft Research, USA) Invited Speakers . TBA Organizers . Supratik Mukhopadhyay, West Virginia University, USA. . Abhik Roychoudhury, National University of Singapore, Singapore. . Zijiang Yang, Western Michigan University, USA (Workshop Co-ordinator). If you have any queries about the workshop, please send e-mail to zijiang.yang@wmich.edu From hagiya at is.s.u-tokyo.ac.jp Mon Sep 5 22:35:24 2005 From: hagiya at is.s.u-tokyo.ac.jp (Masami Hagiya) Date: Tue Sep 6 01:10:58 2005 Subject: [Haskell] FLOPS 2006 Call for Papers Message-ID: <20050906.113524.72624509.hagiya@is.s.u-tokyo.ac.jp> Dear Moderator, Could you consider distributing the following call for papers? -- Masami Hagiya === First Call For Papers Eighth International Symposium on Functional and Logic Programming FLOPS 2006 April 24--26 Fuji Susono, JAPAN Submission deadline: November 11 http://hagi.is.s.u-tokyo.ac.jp/FLOPS2006 FLOPS is a forum for research on all issues concerning declarative programming, including functional programming and logic programming, and aims to promote cross-fertilization between the two paradigms. Previous FLOPS meetings were held in Fuji Susono (1995), Shonan Village (1996), Kyoto (1998), Tsukuba (1999), Tokyo (2001), Aizu (2002), and Nara (2004). 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. For 2006, we wish to particularly encourage papers on new application areas, including security, bioinformatics, and quantum computation. The proceedings will be published as a LNCS volume. The proceedings of the previous meeting (FLOPS2004) were published as LNCS2998. 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 and under preparation. Please visit http://hagi.is.s.u-tokyo.ac.jp/FLOPS2006/ INVITED SPEAKERS Peter Van Roy (Louvain, Belgium) other speakers to be decided CO-CHAIRS Philip Wadler (Edinburgh, UK) Masami Hagiya (Tokyo, Japan) PC MEMBERS Peter Selinger (Dalhousie, Canada) Manuel Hermenegildo (New Mexico & Madrid, US & Spain) Eijiro Sumii (Tohoku, Japan) Konstantinos Sagonas (Uppsala, Sweden) Jacques Garrigue (Nagoya, Japan) Peter Thiemann (Freiburg, Germany) David Warren (Stony Brook, US) Gabrielle Keller (UNSW, Sydney, Australia) Alain Frisch (INRIA Roquencourt, France) Veronica Dahl (Simon Fraser, Canada) Ken Satoh (NII, Tokyo, Japan) Naoyuki Tamura (Kobe, Japan) Michael Rusinowitch (INRIA Lorraine, France) Vincent Danos (Paris, France) IMPORTANT DATES Submission deadline: November 11 Author notification: January 6 Camera-ready copy: January 20 PLACE The meeting will be held at Fuji Institute of Education and Training (http://www.fujiken.gr.jp/) located in Fuji Susono, JAPAN, where the first FLOPS was held. It is famous of its view to Mt. Fuji. Previous FLOPS: FLOPS 2004, Nara: http://logic.is.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 University of Tokyo IN COOPERATION (pending) ACM SIGPLAN Japan Society for Software Science and Technology (JSSST) Association for Logic Programming (ALP) Asian Association for Foundation of Software (AAFS) INQUIRIES to Masami Hagiya hagiya@is.s.u-tokyo.ac.jp From gale at sefer.org Tue Sep 6 09:19:30 2005 From: gale at sefer.org (Yitzchak Gale) Date: Tue Sep 6 09:00:51 2005 Subject: [Haskell] Missing docs on Debian? In-Reply-To: <87wtlve23y.fsf@syntaxpolice.org> References: <20050905091256.GA3136@mail.actcom.co.il> <87wtlve23y.fsf@syntaxpolice.org> Message-ID: <20050906131903.GA3133@mail.actcom.co.il> Isaac Jones wrote: > Yitzchak Gale writes: > > Using Debian testing with the ghc6-doc package > > installed (version 6.4-3)... (I was missing > > docs) > It looks to me like this isn't the version from > "testing" fwiw, but the version from > "unstable"... try upgrading to the new version > (maybe Ian can say whether there's any fix > between -3 and -4). Thanks, you are right. Since I had to get 6.4 manually (testing is still stuck way back at 6.2), I forgot that I do not get upgrades automatically. > ...did you get this -doc package from the > Haskell Unsafe repository... ? Oooh, nice! I didn't know about this. So now I can indeed get automatic updates. It looks like there is nothing interesting there in testing, though. So I guess I want unstable. For the benefit of other Debian users, Google took me here: http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html where I found the following lines to add to my /etc/apt/sources.list file: deb http://haskell-unsafe.alioth.debian.org/archive/i386 . unstable deb-src http://haskell-unsafe.alioth.debian.org/archive/i386 . unstable If you are using Debian stable, and you want the not-quite-as-old Haskell packages from testing, change "unstable" to "stable" in the above lines. Regards, Yitz From ilya+haskell at iponweb.net Tue Sep 6 10:00:09 2005 From: ilya+haskell at iponweb.net (Ilya Martynov) Date: Tue Sep 6 09:41:27 2005 Subject: [Haskell] [OT] xemacs In-Reply-To: <20050905234837.GH24198@a5.repetae.net> (Frederik Eaton's message of "Mon, 5 Sep 2005 16:48:37 -0700") References: <20050905063153.GC24198@a5.repetae.net> <87oe77qzyd.fsf-monnier+emacs@gnu.org> <20050905210901.GE24198@a5.repetae.net> <87ek83m8le.fsf-monnier+emacs@gnu.org> <20050905234837.GH24198@a5.repetae.net> Message-ID: <87ek82s3di.fsf@iponweb.net> >>>>> "FE" == Frederik Eaton writes: FE> I switched from emacs to xemacs because of gnuserv/gnuclient. No need to switch. Just use a port of gnuserv for gnu emacs: http://meltin.net/hacks/emacs/ -- Ilya Martynov, ilya@iponweb.net CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org From ijones at syntaxpolice.org Tue Sep 6 11:01:46 2005 From: ijones at syntaxpolice.org (Isaac Jones) Date: Tue Sep 6 10:46:02 2005 Subject: [Haskell] Missing docs on Debian? In-Reply-To: <20050906131903.GA3133@mail.actcom.co.il> (Yitzchak Gale's message of "Tue, 6 Sep 2005 16:19:30 +0300") References: <20050905091256.GA3136@mail.actcom.co.il> <87wtlve23y.fsf@syntaxpolice.org> <20050906131903.GA3133@mail.actcom.co.il> Message-ID: <878xyadyud.fsf@syntaxpolice.org> Yitzchak Gale writes: (on the Haskell Unsafe debian repository) > For the benefit of other Debian users, Google took > me here: > > http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html > > where I found the following lines to add to my > /etc/apt/sources.list file: > > deb http://haskell-unsafe.alioth.debian.org/archive/i386 . unstable > deb-src http://haskell-unsafe.alioth.debian.org/archive/i386 . unstable > > If you are using Debian stable, and you want the > not-quite-as-old Haskell packages from testing, > change "unstable" to "stable" in the above lines. You can do the same thing with Unstable; just add "unstable" entries to your /etc/apt/souces.list and add a "preferences" file that says you prefer to get everything from "testing" or "stable" or whatever. Then if you want something from Unstable, just say "apt-get install ghc6/unstable". Unstable is more stable than unsafe, btw ;) peace, isaac From gale at sefer.org Tue Sep 6 16:51:32 2005 From: gale at sefer.org (Yitzchak Gale) Date: Tue Sep 6 16:32:54 2005 Subject: [Haskell] Re: cannot compile ghc on Debian unstable In-Reply-To: <87hdd4fhaj.fsf@syntaxpolice.org> References: <20050828050640.C3FC6103BE3@orchestra.cs.caltech.edu> <87vf1ni3o1.fsf@syntaxpolice.org> <87hdd4fhaj.fsf@syntaxpolice.org> Message-ID: <20050906205132.GA3134@mail.actcom.co.il> Isaac Jones wrote: > Aaron Denney writes: > > Isaac Jones wrote: > >> Michael Vanier writes: > >>> Right now, the Debian unstable package for > >>> GHC 6.4 won't install due to some conflict > >>> with libgmp3... > >> ...install the libgmp3 from stable... That > >> might work? > > It should, but I have other packages that depend on a newer > > version of libgmp3... > I believe that this is fixed now... ghc6 in unstable now depends on libgmp3c2 which conflicts with libgmp3. So, for example, ghc6 now conflicts with darcs. -Yitz From ijones at syntaxpolice.org Tue Sep 6 18:29:06 2005 From: ijones at syntaxpolice.org (Isaac Jones) Date: Tue Sep 6 18:17:10 2005 Subject: [Haskell] Re: cannot compile ghc on Debian unstable In-Reply-To: <20050906205132.GA3134@mail.actcom.co.il> (Yitzchak Gale's message of "Tue, 6 Sep 2005 23:51:32 +0300") References: <20050828050640.C3FC6103BE3@orchestra.cs.caltech.edu> <87vf1ni3o1.fsf@syntaxpolice.org> <87hdd4fhaj.fsf@syntaxpolice.org> <20050906205132.GA3134@mail.actcom.co.il> Message-ID: <878xy9de4t.fsf@syntaxpolice.org> Yitzchak Gale writes: > Isaac Jones wrote: >> Aaron Denney writes: >> > Isaac Jones wrote: >> >> Michael Vanier writes: > >> >>> Right now, the Debian unstable package for >> >>> GHC 6.4 won't install due to some conflict >> >>> with libgmp3... > >> >> ...install the libgmp3 from stable... That >> >> might work? > >> > It should, but I have other packages that depend on a newer >> > version of libgmp3... > >> I believe that this is fixed now... > > ghc6 in unstable now depends on libgmp3c2 which > conflicts with libgmp3. So, for example, ghc6 now > conflicts with darcs. Believe me... I know. People are working on this problem. From jgoerzen at complete.org Tue Sep 6 12:08:42 2005 From: jgoerzen at complete.org (John Goerzen) Date: Tue Sep 6 20:13:22 2005 Subject: [Haskell] Haskell Weekly News: September 6, 2005 Message-ID: <20050906160842.GA10547@katherina.lan.complete.org> Haskell Weekly News: September 6, 2005 Greetings, and thanks for reading the sixth issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * h4sh 0.2. Donald Bruce Stewart [3]announced version 0.2 of h4sh, a tool to expose Haskell functions to shell scripters. This release adds more functions, removed argument flags, cabalized the package, added regex operators, and had some other changes as well. * cabal-get/put beta. Isaac Jones [4]announced the beta of cabal-get, which will download and install Haskell packages and their dependencies. It is designed to work for any cabal-compatible package. The cabal-get team is looking for beta testers to try out both cabal-get and cabal-put. 3. http://article.gmane.org/gmane.comp.lang.haskell.general/12043 4. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8188 Discussion Emacs haskell-mode. Frederik Eaton began a [5]thread on the Emacs haskell-mode, asking where the latest version is available from. 5. http://thread.gmane.org/gmane.comp.lang.haskell.general/12044 Time limits on computations. Dmitry Vyal [6]asked how to set a time limit on computations. Several different suggestions were presented over the course of the discussion. 6. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8185 Haskell Toolchain The Haskell CVS server, previously hosted at OGI, is now being [7]hosted by [8]Galois. There is a new machine and updated software, but it should be a drop-in replacement overall. 7. http://article.gmane.org/gmane.comp.lang.haskell.general/12036 8. http://www.galois.com/ Darcs Corner Darcs 1.0.4pre3 and pre4. Two new Darcs prerelease versions happened this week. First, 1.0.4pre3 was [9]announced this week. 1.0.4pre4 quickly [10]followed, correcting an error in a Makefile. This is expected to be the last prerelease prior to 1.0.4 itself. 9. http://article.gmane.org/gmane.comp.version-control.darcs.user/8192 10. http://article.gmane.org/gmane.comp.version-control.darcs.user/8198 Quote of the Week "When I read through a Haskell program, it's more like reading a novel than solving a calculus problem." -- [11]post on the Haskell Sequence 11. http://sequence.complete.org/node/93 About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [12]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 12. http://sequence.complete.org/hwn-contrib From frederik at a5.repetae.net Wed Sep 7 15:46:42 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Wed Sep 7 15:27:59 2005 Subject: [Haskell] mailing list headaches Message-ID: <20050907194642.GA23229@a5.repetae.net> Hi all, I've been trying for some time to get threading to work properly on this mailing list. The problem is that I don't want to thread by subject in all of my folders, because then messages with short subjects like "hi", "hey", etc., in my personal folders will end up together. However, threading by "References", which RFC 2822 says SHOULD be possible, and which works on my other folders, doesn't work well on Haskell mailing lists. Presumably the issue is that there are a large number of Windows users with strange mail clients which don't insert "References" headers. After some weeks of squinting, I've ended up settling with the following partial solution in my configuration files (I use Mutt): set strict_threads=yes folder-hook folders/haskell set strict_threads=no folder-hook folders/libraries set strict_threads=no folder-hook folders/glasgow-haskell set strict_threads=no folder-hook folders/glasgow-haskell-bugs set strict_threads=no I thought I'd share this feature because a lot of people use Mutt and it makes the Haskell mailing lists a bit easier to follow. It isn't perfect, because threads organized by subject are only one layer deep - you end up getting a list instead of a tree, except that since Mutt uses References where possible it ends up being a list of trees, where at the root of each tree is either a reply to the first message of the thread, or someone with a non-conforming mail client. Of course, another problem is the mailing list archives, which also try to organize threads by "References" but fail on these lists: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-June/thread.html Thus it seems the list archive software also requires fixing or reconfiguration... Frederik -- http://ofb.net/~frederik/ From frederik at a5.repetae.net Thu Sep 8 00:43:23 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Sep 8 00:24:37 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <200403231255.59233.haskell@ser.fdns.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> Message-ID: <20050908044323.GA6037@a5.repetae.net> Hi, Sean's comment (yeah, it was like a billion years ago, just catching up) is something that I've often thought myself. I want the type system to be able to do "automatic lifting" of monads, i.e., since [] is a monad, I should be able to write the following: [1,2]+[3,4] and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". Also, I would have Reader (+1) + Reader (+4) == Reader (\x -> 2*x+5) The point I want to make is that this is much more general than IO or monads! I think we all understand intuitively what mathematicians mean when they add two sets {1,2}+{3,4} (i.e. { x+y | x\in {1,2}, y\in {3,4}}) or when they add functions (f+g)(x) where f(x)=x+1 and g(x)=x+4 So "automatic lifting" is a feature which is very simple to describe, but which gives both of these notations their intuitive mathematical meaning - not to mention making monadic code much tidier (who wants to spend their time naming variables which are only used once?). I think it deserves more attention. I agree that in its simplest incarnation, there is some ugliness: the order in which the values in the arguments are extracted from their monads could be said to be arbitrary. Personally, I do not think that this in itself is a reason to reject the concept. Because of currying, the order of function arguments is already important in Haskell. If you think of the proposed operation not as lifting, but as inserting `ap`s: return f `ap` x1 `ap` ... `ap` xn then the ordering problem doesn't seem like such a big deal. I mean, what other order does one expect, than one in which the arguments are read in the same order that 'f' is applied to them? Although it is true that in most of the instances where this feature would be used, the order in which arguments are read from their monads will not matter; yet that does not change the fact that in cases where order *does* matter it's pretty damn easy to figure out what it will be. For instance, in print ("a: " ++ readLn ++ "\nb: " ++ readLn) two lines are read and then printed. Does anybody for a moment question what order the lines should be read in? Frederik On Tue, Mar 23, 2004 at 12:55:56PM -0500, Sean E. Russell wrote: > On Tuesday 23 March 2004 11:36, Graham Klyne wrote: > > I think you're a rather stuck with the "temporary variables" (which they're > > not really), but it might be possible to hide some of the untidiness in an > > auxiliary monadic function. > > That seems to be the common suggestion: write my own visitors. > > I'm just surprised that there isn't a more elegant mechanism for getting > interoperability between monadic and non-monadic functions. The current > state of affairs just seems awkward. > > [Warning: quasi-rant] > > Caveat: I'm not smart enough, and I don't know enough, to criticize Haskell, > so please don't misconstrue my comments. To quote Einstein: "When I'm asking > simple questions and I'm getting simple answers, I'm talking to God." I > simply mistrust, and therefore question, systems where simple things are > overly involved. > > The standard explaination about why monads are so troublesome always sounds > like an excuse to me. We have monads, because they allow side-effects. Ok. > If programs that used side effects were uncommon, I'd be fine with them being > troublesome -- but they aren't. Maybe it is just me, but my Haskell programs > invariably develop a need for side effects within a few tens of lines of > code, whether IO, Maybe, or whatnot. And I can't help but think that > language support to make dealing with monads easier -- that is, to integrate > monads with the rest of the language, so as to alleviate the need for > constant lifting -- would be a Good Thing. > > Hmmm. Could I say that Haskell requires "heavy lifting"? > > -- > ### SER > ### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido > ### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 > ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell -- http://ofb.net/~frederik/ From Ben.Lippmeier at anu.edu.au Thu Sep 8 01:26:48 2005 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Sep 8 01:08:05 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908044323.GA6037@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> Message-ID: <431FCB98.70709@anu.edu.au> Frederik Eaton wrote: > I want the type system to be able to do "automatic lifting" of monads, > i.e., since [] is a monad, I should be able to write the following: > > [1,2]+[3,4] > > and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". > print ("a: " ++ readLn ++ "\nb: " ++ readLn) > > two lines are read and then printed. Does anybody for a moment > question what order the lines should be read in? > Frederik, To do "automatic lifting" you need to do a (higher-order) effect analysis, then make sure the compiler doesn't rearrange applications which have conflicting effects. One way of preventing the compiler from rearranging effects is to thread though a dummy variable - like a "World token", ala the IO monad - which makes the order of operations explicit as an extra data dependency, then compile the resulting code. Another way is to use the effect information to lift the applications into a hierarchy of monads which represent how effectful the application is, then compile the monadic code directly. There's a paper by Andrew Tolmach called "Optimizing ML using a hierarchy of monadic types", which does exactly this. Tolmach's approach worked ok, but there were some problems with higher order functions.. ie with map :: (a -E> b) -> [a] -E> [b] where E is some effect, you have to assume a worst case effect for the first argument - so any expression using map can't be moved around by the compiler - eg for the full laziniess transform. Another way would be just to annotate every application with the effects it has, then have the compiler check these before it tries to rearrange anything - and have an extra rule that you can't suspend an application which has visible effects. I am working on a compiler for my PhD project which takes this third option. I've got the effect analysis working, but I had to resort to a graph based type inference method - which is something that wouldn't be easilly added to something like GHC. Onward! Ben. From tomasz.zielonka at gmail.com Thu Sep 8 02:39:29 2005 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Thu Sep 8 02:20:43 2005 Subject: [Haskell] mailing list headaches In-Reply-To: <20050907194642.GA23229@a5.repetae.net> References: <20050907194642.GA23229@a5.repetae.net> Message-ID: <20050908063929.GA1359@students.mimuw.edu.pl> On Wed, Sep 07, 2005 at 12:46:42PM -0700, Frederik Eaton wrote: > Hi all, Hi! > After some weeks of squinting, I've ended up settling with the > following partial solution in my configuration files (I use Mutt): > > set strict_threads=yes > folder-hook folders/haskell set strict_threads=no > folder-hook folders/libraries set strict_threads=no > folder-hook folders/glasgow-haskell set strict_threads=no > folder-hook folders/glasgow-haskell-bugs set strict_threads=no Nice, thanks! BTW, could you also share the configuration you use to split e-mails into folders? Do you use procmail for this? Best regards Tomasz From frederik at a5.repetae.net Thu Sep 8 02:41:41 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Sep 8 02:22:59 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <431FCB98.70709@anu.edu.au> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <431FCB98.70709@anu.edu.au> Message-ID: <20050908064141.GB6037@a5.repetae.net> > Frederik, > To do "automatic lifting" you need to do a (higher-order) effect analysis, then make sure the > compiler doesn't rearrange applications which have conflicting effects. Hrm, I disagree. I don't think this is what I was advocating in my message. What I'm advocating is a reasonably simple modification of the type checker to allow a more concise syntax. Unless I'm misunderstanding you, there is no special "effect analysis" needed. I haven't worked it out exactly, but what you'd do is the following: 1. keep track of when you are unifying types within a "monadic context"; for instance when you unify "Monad m => x -> m b" with "Monad m => y -> m b", you have to unify "x" and "y". this second unification of "x" and "y" will be done within a "context" to which the monad "m" has been added, to make a note of the fact that computations in "m" within "x" or "y" can be lifted. 2. if two types don't unify, but you can get them to unify by inserting a lift operation from one of the current context monads, then do that. e.g. when you find an application where a function expects an argument of type "a" and the user is passing something of type "m a", and "m" is in the context (so we know that we can eventually get rid of it), then do the application with `ap` instead of "$". I don't pretend that this is rigorous, but I do hope it gives a better idea of what I'm talking about doing. The point of the last few paragraphs of my message was to argue that even with this syntax change, users will still be able to easily reason about the side-effects of monadic parts of their code. Do you disagree with that assertion? Or are you just saying that the syntax change as I propose it is called "effect analysis"? Frederik -- http://ofb.net/~frederik/ From list at atmarama.org Thu Sep 8 02:58:03 2005 From: list at atmarama.org (Gour) Date: Thu Sep 8 02:39:30 2005 Subject: [Haskell] mailing list headaches In-Reply-To: <20050908063929.GA1359@students.mimuw.edu.pl> References: <20050907194642.GA23229@a5.repetae.net> <20050908063929.GA1359@students.mimuw.edu.pl> Message-ID: <20050908065803.GA15674@mail.inet.hr> Tomasz Zielonka (tomasz.zielonka@gmail.com) wrote: > Nice, thanks! BTW, could you also share the configuration you use to > split e-mails into folders? Do you use procmail for this? I use maildrop, here is part of my .mailfilter: if ( /^X-BeenThere: .*@haskell\.org/ || /^X-BeenThere: gtk2hs.*@lists\.sourcefor ge\.net/ ) { log "------------------- haskell-related mailing list -------------------" to "|maildir ${MAIL}/IN-L-haskell/" } logging part is, of course, optional and I put all the haskell-related email in the same folder. I fetch mail with getmail - http://pyropus.ca/software/getmail/ - which invokes different filters, e.g. virus-scanning, spam-assassin and uses maildrop as MDA. Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD From frederik at a5.repetae.net Thu Sep 8 03:29:19 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Sep 8 03:10:34 2005 Subject: [Haskell] mailing list headaches In-Reply-To: <20050908063929.GA1359@students.mimuw.edu.pl> References: <20050907194642.GA23229@a5.repetae.net> <20050908063929.GA1359@students.mimuw.edu.pl> Message-ID: <20050908072919.GC6037@a5.repetae.net> On Thu, Sep 08, 2005 at 08:39:29AM +0200, Tomasz Zielonka wrote: > On Wed, Sep 07, 2005 at 12:46:42PM -0700, Frederik Eaton wrote: > > Hi all, > > Hi! > > > After some weeks of squinting, I've ended up settling with the > > following partial solution in my configuration files (I use Mutt): > > > > set strict_threads=yes > > folder-hook folders/haskell set strict_threads=no > > folder-hook folders/libraries set strict_threads=no > > folder-hook folders/glasgow-haskell set strict_threads=no > > folder-hook folders/glasgow-haskell-bugs set strict_threads=no > > Nice, thanks! BTW, could you also share the configuration you use to > split e-mails into folders? Do you use procmail for this? Ooh, no, I don't use procmail. I don't like procmail at all. I wrote my own set of scripts in perl. I run 'w3m' with a local cgi script which shows all the folders along with their new/total counts, and when I select one of the links it opens mutt with that folder. Then I defined mutt macros to do things like respool messages (if I change the filter script) or move them to other folders. I don't expect that this hackery will be very useful to you, but I've posted it here so you can see: http://ofb.net/~frederik/mailproc.tar.gz One thing it has is perl code to automatically recognize mailing list messages and put them into appropriately-named folders. Apparently I'm subscribed to over 100 mailing lists. I'd wanted to do something more elegant, something like John Meacham's Ginsu but backed by an SQL database, but never got around to it. Frederik -- http://ofb.net/~frederik/ From frederik at a5.repetae.net Thu Sep 8 03:38:13 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Sep 8 03:19:40 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908064141.GB6037@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <431FCB98.70709@anu.edu.au> <20050908064141.GB6037@a5.repetae.net> Message-ID: <20050908073813.GD6037@a5.repetae.net> I guess what I don't understand is what's wrong with the first alternative you mention: > One way of preventing the compiler from rearranging effects is to > thread though a dummy variable - like a "World token", ala the IO > monad - which makes the order of operations explicit as an extra > data dependency, then compile the resulting code. which sounds sort of the same as the semantics I'm envisioning. Frederik On Wed, Sep 07, 2005 at 11:41:41PM -0700, Frederik Eaton wrote: > > Frederik, > > To do "automatic lifting" you need to do a (higher-order) effect analysis, then make sure the > > compiler doesn't rearrange applications which have conflicting effects. > > Hrm, I disagree. I don't think this is what I was advocating in my > message. > > What I'm advocating is a reasonably simple modification of the type > checker to allow a more concise syntax. Unless I'm misunderstanding > you, there is no special "effect analysis" needed. > > I haven't worked it out exactly, but what you'd do is the following: > > 1. keep track of when you are unifying types within a "monadic > context"; for instance when you unify "Monad m => x -> m b" with > "Monad m => y -> m b", you have to unify "x" and "y". this second > unification of "x" and "y" will be done within a "context" to which > the monad "m" has been added, to make a note of the fact that > computations in "m" within "x" or "y" can be lifted. > > 2. if two types don't unify, but you can get them to unify by > inserting a lift operation from one of the current context monads, > then do that. e.g. when you find an application where a function > expects an argument of type "a" and the user is passing something > of type "m a", and "m" is in the context (so we know that we can > eventually get rid of it), then do the application with `ap` > instead of "$". > > I don't pretend that this is rigorous, but I do hope it gives a better > idea of what I'm talking about doing. The point of the last few > paragraphs of my message was to argue that even with this syntax > change, users will still be able to easily reason about the > side-effects of monadic parts of their code. Do you disagree with that > assertion? Or are you just saying that the syntax change as I propose > it is called "effect analysis"? > > Frederik > > -- > http://ofb.net/~frederik/ > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- http://ofb.net/~frederik/ From Jeremy.Gibbons at comlab.ox.ac.uk Thu Sep 8 04:09:28 2005 From: Jeremy.Gibbons at comlab.ox.ac.uk (Jeremy Gibbons) Date: Thu Sep 8 03:50:39 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908044323.GA6037@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> Message-ID: On Wed, 7 Sep 2005, Frederik Eaton wrote: > I want the type system to be able to do "automatic lifting" of monads, > i.e., since [] is a monad, I should be able to write the following: > > [1,2]+[3,4] > > and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". You might want to take a look at "Monadification of Functional Programs" by Erwig and Ren (Science of Computer Programming, 52:101-129, 2004): http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html which describes the transformation that introduces such a monadic structure. Jeremy Jeremy.Gibbons@comlab.ox.ac.uk Oxford University Computing Laboratory, TEL: +44 1865 283508 Wolfson Building, Parks Road, FAX: +44 1865 273839 Oxford OX1 3QD, UK. URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html From k.schupke at imperial.ac.uk Thu Sep 8 04:34:33 2005 From: k.schupke at imperial.ac.uk (Keean Schupke) Date: Thu Sep 8 04:15:45 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908044323.GA6037@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> Message-ID: <431FF799.3060209@imperial.ac.uk> Can't you do automatic lifting with a "Runnable" class: class Runnable x y where run :: x -> y instance Runnable (m a) (m a) where run = id instance Runnable (s -> m a) (s -> m a) where run = id instance (Monad m,Monad n,MonadT t m,Runnable (m a) (n a)) => Runnable (t m a) (n a) where run = run . down instance (Monad m,MonadT t m,Monad (t m)) => Runnable (t m a) (m a) where run = down Where: class (Monad m,Monad (t m)) => MonadT t m where up :: m a -> t m a down :: t m a -> m a For example for StateT: downST :: Monad m => StateT st m a -> (st -> m a) downST m = \st -> do (_,a) <- runST m st return a downST' :: Monad m => (b -> StateT st m a) -> (st -> b -> m a) downST' m = \st b -> do (_,a) <- runST (m b) st return a instance (MonadState st (StateT st m),Monad m,Monad n,Runnable (st -> m s) (st -> n s)) => Runnable (StateT st m s) (st -> n s) where run = run . downST instance (MonadState st (StateT st m),Monad m) => Runnable (StateT st m s) (st -> m s) where run = downST Keean. Frederik Eaton wrote: >Hi, > >Sean's comment (yeah, it was like a billion years ago, just catching >up) is something that I've often thought myself. > >I want the type system to be able to do "automatic lifting" of monads, >i.e., since [] is a monad, I should be able to write the following: > >[1,2]+[3,4] > >and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". > >Also, I would have > >Reader (+1) + Reader (+4) == Reader (\x -> 2*x+5) > >The point I want to make is that this is much more general than IO or >monads! I think we all understand intuitively what mathematicians mean >when they add two sets > >{1,2}+{3,4} (i.e. { x+y | x\in {1,2}, y\in {3,4}}) > >or when they add functions > >(f+g)(x) where f(x)=x+1 and g(x)=x+4 > >So "automatic lifting" is a feature which is very simple to describe, >but which gives both of these notations their intuitive mathematical >meaning - not to mention making monadic code much tidier (who wants to >spend their time naming variables which are only used once?). I think >it deserves more attention. > >I agree that in its simplest incarnation, there is some ugliness: the >order in which the values in the arguments are extracted from their >monads could be said to be arbitrary. Personally, I do not think that >this in itself is a reason to reject the concept. Because of currying, >the order of function arguments is already important in Haskell. If >you think of the proposed operation not as lifting, but as inserting >`ap`s: > >return f `ap` x1 `ap` ... `ap` xn > >then the ordering problem doesn't seem like such a big deal. I mean, >what other order does one expect, than one in which the arguments are >read in the same order that 'f' is applied to them? > >Although it is true that in most of the instances where this feature >would be used, the order in which arguments are read from their monads >will not matter; yet that does not change the fact that in cases where >order *does* matter it's pretty damn easy to figure out what it will >be. For instance, in > >print ("a: " ++ readLn ++ "\nb: " ++ readLn) > >two lines are read and then printed. Does anybody for a moment >question what order the lines should be read in? > >Frederik > > > >On Tue, Mar 23, 2004 at 12:55:56PM -0500, Sean E. Russell wrote: > > >>On Tuesday 23 March 2004 11:36, Graham Klyne wrote: >> >> >>>I think you're a rather stuck with the "temporary variables" (which they're >>>not really), but it might be possible to hide some of the untidiness in an >>>auxiliary monadic function. >>> >>> >>That seems to be the common suggestion: write my own visitors. >> >>I'm just surprised that there isn't a more elegant mechanism for getting >>interoperability between monadic and non-monadic functions. The current >>state of affairs just seems awkward. >> >>[Warning: quasi-rant] >> >>Caveat: I'm not smart enough, and I don't know enough, to criticize Haskell, >>so please don't misconstrue my comments. To quote Einstein: "When I'm asking >>simple questions and I'm getting simple answers, I'm talking to God." I >>simply mistrust, and therefore question, systems where simple things are >>overly involved. >> >>The standard explaination about why monads are so troublesome always sounds >>like an excuse to me. We have monads, because they allow side-effects. Ok. >>If programs that used side effects were uncommon, I'd be fine with them being >>troublesome -- but they aren't. Maybe it is just me, but my Haskell programs >>invariably develop a need for side effects within a few tens of lines of >>code, whether IO, Maybe, or whatnot. And I can't help but think that >>language support to make dealing with monads easier -- that is, to integrate >>monads with the rest of the language, so as to alleviate the need for >>constant lifting -- would be a Good Thing. >> >>Hmmm. Could I say that Haskell requires "heavy lifting"? >> >>-- >>### SER >>### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido >>### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 >>### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg >> >> > > > > > >>_______________________________________________ >>Haskell mailing list >>Haskell@haskell.org >>http://www.haskell.org/mailman/listinfo/haskell >> >> > > > > From wlux at uni-muenster.de Thu Sep 8 04:35:49 2005 From: wlux at uni-muenster.de (Wolfgang Lux) Date: Thu Sep 8 04:17:13 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908044323.GA6037@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> Message-ID: Frederik Eaton wrote: > I want the type system to be able to do "automatic lifting" of monads, > i.e., since [] is a monad, I should be able to write the following: > > > > and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". Are you sure that this is the interpretation you have in mind? The expression do {a<-[1,2]; b<-[3,4]; return (a+b)} does *not* compute the element-wise sum of the two lists, but returns the list [4,5,5,6]. To me, this would be a very counter intuitive result for an expression [1,2]+[3,4]. Wolfgang From frederik at a5.repetae.net Thu Sep 8 05:21:25 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Sep 8 05:02:38 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> Message-ID: <20050908092125.GB11509@a5.repetae.net> On Thu, Sep 08, 2005 at 10:35:49AM +0200, Wolfgang Lux wrote: > Frederik Eaton wrote: > > >I want the type system to be able to do "automatic lifting" of monads, > >i.e., since [] is a monad, I should be able to write the following: > >and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". > > Are you sure that this is the interpretation you have in mind? The > expression do {a<-[1,2]; b<-[3,4]; return (a+b)} does *not* compute the > element-wise sum of the two lists, but returns the list [4,5,5,6]. To > me, this would be a very counter intuitive result for an expression > [1,2]+[3,4]. Thanks for bringing up a good point. Yes, this is what I have in mind. As I see it, the monadic interface for lists gives them the semantics of (multi)sets. Adding two sets could only be interpreted as I have said. If you were adding, say, arrays, elementwise, the monad would be more like a reader monad, which I also gave an example of, with the parameter being the array index. Furthermore, it's hard to see how one would elegantly flesh out the semantics you propose for lists. What if the two lists have different lengths? Thus I think set semantics is more appropriate for a list monad. Frederik -- http://ofb.net/~frederik/ From tomasz.zielonka at gmail.com Thu Sep 8 05:35:49 2005 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Thu Sep 8 05:17:01 2005 Subject: [Haskell] mailing list headaches In-Reply-To: <20050908072919.GC6037@a5.repetae.net> References: <20050907194642.GA23229@a5.repetae.net> <20050908063929.GA1359@students.mimuw.edu.pl> <20050908072919.GC6037@a5.repetae.net> Message-ID: <20050908093549.GA1487@students.mimuw.edu.pl> On Thu, Sep 08, 2005 at 12:29:19AM -0700, Frederik Eaton wrote: > I don't expect that this hackery will be very useful to you, but I've > posted it here so you can see: > > http://ofb.net/~frederik/mailproc.tar.gz Thanks! Hopefully it will be at least an inspiration to improve my mail config :-) Best regards Tomasz From sestoft at dina.kvl.dk Wed Sep 7 04:08:59 2005 From: sestoft at dina.kvl.dk (Peter Sestoft) Date: Thu Sep 8 12:11:15 2005 Subject: [Haskell] ESOP 2006 Call for papers Message-ID: Call for Papers ESOP 2006: The European Symposium on Programming http://www.itu.dk/research/esop06/ Affiliated with ETAPS'06 Vienna, Austria, 25 March to 2 April 2006 CONFERENCE DESCRIPTION ESOP is an annual conference devoted to fundamental issues in the specification, analysis, and implementation of programming languages and systems. This includes: * design of programming languages and calculi and their formal properties * techniques, methods, and tools for their implementation * exploitation of programming styles within different programming paradigms * automatic and manual methods for generating and reasoning about programs * the design and invention of systems and tools to assist in exploitation of the languages Contributions bridging the gap between theory and practice are particularly welcome. Topics traditionally covered by ESOP include programming paradigms and their integration, semantics, calculi of computation, security and privacy, advanced type systems, program analysis, program transformation, and practical algorithms based on theoretical developments. More information about ESOP can be found at ESOP's home page: http://www.imm.dtu.dk/~riis/esop.html ESOP'06 is one of the main conferences of ETAPS'06 with sister events CC, FASE, FOSSACS, TACAS, see: http://www.complang.tuwien.ac.at/etaps06/ IMPORTANT DATES Friday 7 October 2005 Submission deadline for abstracts Friday 14 October 2005 Submission deadline for full papers (strict) Friday 9 December 2005 Notification of acceptance/rejection Friday 6 January 2006 Camera-ready version due Saturday 25 March to Sunday 2 April 2006 ETAPS 2006 SUBMISSION INFORMATION ETAPS conferences accept two types of contributions: research papers and tool demonstration papers. Both types will appear in the proceedings and have presentations during the conference. A condition of submission is that, if the submission is accepted, one of the authors attends the conference to give the presentation. All submitted papers must be unpublished and not submitted for publication elsewhere. In particular, simultaneous submission of the same contribution to multiple ETAPS conferences is forbidden. Papers should be submitted electronically in PDF (preferably) or PS (using Type 1 fonts). The proceedings will be published in the Springer-Verlag Lecture Notes in Computer Science series. Final papers will be in the format specified by Springer-Verlag at the URL: http://www.springer.de/comp/lncs/authors.html It is recommended that submissions adhere to the specified format and length. Submissions that are clearly too long may be rejected immediately. A link to the electronic submission system will available shortly on the ESOP 2006 home page (http://www.itu.dk/research/esop06/). RESEARCH PAPERS: Final papers will be not more than 15 pages long, and should present original research. Additional material intended for the referee but not for publication in the final version - for example details of proofs - may be placed in a clearly marked appendix that is not included in the page limit. TOOL DEMONSTRATION PAPERS: Submissions should consist of two parts: The first part, at most four pages, should describe the tool presented. Please include the URL of the tool (if available) and provide information which illustrates the maturity and robustness of the tool. (This part will be included in the proceedings.) The second part, at most six pages, should explain how the demonstration will be carried out and what it will show, including screen dumps and examples. (This part will be not be included in the proceedings, but will be evaluated.) ESOP 2006 INVITED SPEAKER Sophia Drossopoulou, Imperial College London, UK ETAPS 2006 JOINT INVITED SPEAKERS Carlo Ghezzi, Politecnico di Milano, Italy Benjamin Pierce, University of Pennsylvania, USA ESOP 2006 PROGRAM COMMITTEE Anindya Banerjee, Kansas State University, USA Anton Ertl, Technische Universit?t Wien, Austria David Warren, Stony Brook University, USA Didier R?my, INRIA Rocquencourt, France Erik Meijer, Microsoft Corporation, USA Eugenio Moggi, University of Genova, Italy German Vidal, Technical University of Valencia, Spain Giuseppe Castagna, ?cole Normale Sup?rieure, France Joe Wells, Heriot-Watt University, UK Kostis Sagonas, Uppsala University, Sweden Michele Bugliesi, University of Venezia, Italy Mooly Sagiv, Tel-Aviv University, Israel Nick Benton, Microsoft Research, UK Peter O'Hearn, Queen Mary, University of London, UK Peter Sestoft, KVL and IT University Copenhagen, Denmark Peter Stuckey, Melbourne University, Australia Peter Thiemann, Freiburg University, Germany Pieter Hartel, Twente University, Netherlands Reinhard Wilhelm, Saarland University, Germany Stephanie Weirich, University of Pennsylvania, USA Susan Eisenbach, Imperial College London, UK Todd Veldhuizen, Indiana University, USA Ulrik Pagh Schultz, University of Southern Denmark Chair: Peter Sestoft, KVL and IT University Copenhagen, Denmark From Chad.Scherrer at pnl.gov Thu Sep 8 12:30:34 2005 From: Chad.Scherrer at pnl.gov (Scherrer, Chad) Date: Thu Sep 8 12:12:01 2005 Subject: [Haskell] Mixing monadic and non-monadic functions Message-ID: One of Mark Jones's articles suggests something like class Plus a b c | a b -> c where (+) :: a -> b -> c Would instance (Plus a b c, Monad m) => Plus (m a) (m b) (m c) where mx + my = do x <- mx y <- my return (x + y) do what you're looking for? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx ------------------------------------------------------------------ Original message: Hi, Sean's comment (yeah, it was like a billion years ago, just catching up) is something that I've often thought myself. I want the type system to be able to do "automatic lifting" of monads, i.e., since [] is a monad, I should be able to write the following: [1,2]+[3,4] and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". Also, I would have Reader (+1) + Reader (+4) == Reader (\x -> 2*x+5) The point I want to make is that this is much more general than IO or monads! I think we all understand intuitively what mathematicians mean when they add two sets {1,2}+{3,4} (i.e. { x+y | x\in {1,2}, y\in {3,4}}) or when they add functions (f+g)(x) where f(x)=x+1 and g(x)=x+4 So "automatic lifting" is a feature which is very simple to describe, but which gives both of these notations their intuitive mathematical meaning - not to mention making monadic code much tidier (who wants to spend their time naming variables which are only used once?). I think it deserves more attention. I agree that in its simplest incarnation, there is some ugliness: the order in which the values in the arguments are extracted from their monads could be said to be arbitrary. Personally, I do not think that this in itself is a reason to reject the concept. Because of currying, the order of function arguments is already important in Haskell. If you think of the proposed operation not as lifting, but as inserting `ap`s: return f `ap` x1 `ap` ... `ap` xn then the ordering problem doesn't seem like such a big deal. I mean, what other order does one expect, than one in which the arguments are read in the same order that 'f' is applied to them? Although it is true that in most of the instances where this feature would be used, the order in which arguments are read from their monads will not matter; yet that does not change the fact that in cases where order *does* matter it's pretty damn easy to figure out what it will be. For instance, in print ("a: " ++ readLn ++ "\nb: " ++ readLn) two lines are read and then printed. Does anybody for a moment question what order the lines should be read in? Frederik From glynn at gclements.plus.com Thu Sep 8 12:53:17 2005 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Sep 8 12:34:26 2005 Subject: [Haskell] mailing list headaches In-Reply-To: <20050907194642.GA23229@a5.repetae.net> References: <20050907194642.GA23229@a5.repetae.net> Message-ID: <17184.27773.769491.686852@cerise.gclements.plus.com> Frederik Eaton wrote: > However, threading by "References", which RFC 2822 says > SHOULD be possible, and which works on my other folders, doesn't work > well on Haskell mailing lists. Presumably the issue is that there are > a large number of Windows users with strange mail clients which don't > insert "References" headers. It isn't so much that there are a large number of such users, but that two of the core developers are among them (and are both employed by Microsoft, so RFC-conformance probably isn't an option). -- Glynn Clements From frederik at a5.repetae.net Thu Sep 8 16:30:51 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Sep 8 16:12:15 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: References: Message-ID: <20050908203051.GE11509@a5.repetae.net> On Thu, Sep 08, 2005 at 09:30:34AM -0700, Scherrer, Chad wrote: > One of Mark Jones's articles suggests something like > > class Plus a b c | a b -> c where > (+) :: a -> b -> c > > Would > > instance (Plus a b c, Monad m) => Plus (m a) (m b) (m c) where > mx + my = do x <- mx > y <- my > return (x + y) > > do what you're looking for? Hi Chad, I'm not sure exactly what you have in mind. Obviously I want something that applies to all functions, with any number of arguments, and not just (+). Furthermore, it should handle cases like 1+[2,3] where only one value is monadic. Keean Schupke's suggestion sounds more likely to be useful, but I'm still reading it. In any case, a minimum of syntactic overhead is desired. Frederik > ------------------------------------------------------------------ > Original message: > > Hi, > > Sean's comment (yeah, it was like a billion years ago, just catching > up) is something that I've often thought myself. > > I want the type system to be able to do "automatic lifting" of monads, > i.e., since [] is a monad, I should be able to write the following: > > [1,2]+[3,4] > > and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". > > Also, I would have > > Reader (+1) + Reader (+4) == Reader (\x -> 2*x+5) > > The point I want to make is that this is much more general than IO or > monads! I think we all understand intuitively what mathematicians mean > when they add two sets > > {1,2}+{3,4} (i.e. { x+y | x\in {1,2}, y\in {3,4}}) > > or when they add functions > > (f+g)(x) where f(x)=x+1 and g(x)=x+4 > > So "automatic lifting" is a feature which is very simple to describe, > but which gives both of these notations their intuitive mathematical > meaning - not to mention making monadic code much tidier (who wants to > spend their time naming variables which are only used once?). I think > it deserves more attention. > > I agree that in its simplest incarnation, there is some ugliness: the > order in which the values in the arguments are extracted from their > monads could be said to be arbitrary. Personally, I do not think that > this in itself is a reason to reject the concept. Because of currying, > the order of function arguments is already important in Haskell. If > you think of the proposed operation not as lifting, but as inserting > `ap`s: > > return f `ap` x1 `ap` ... `ap` xn > > then the ordering problem doesn't seem like such a big deal. I mean, > what other order does one expect, than one in which the arguments are > read in the same order that 'f' is applied to them? > > Although it is true that in most of the instances where this feature > would be used, the order in which arguments are read from their monads > will not matter; yet that does not change the fact that in cases where > order *does* matter it's pretty damn easy to figure out what it will > be. For instance, in > > print ("a: " ++ readLn ++ "\nb: " ++ readLn) > > two lines are read and then printed. Does anybody for a moment > question what order the lines should be read in? > > Frederik > > -- http://ofb.net/~frederik/ From john at repetae.net Thu Sep 8 19:42:22 2005 From: john at repetae.net (John Meacham) Date: Thu Sep 8 19:23:40 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908203051.GE11509@a5.repetae.net> References: <20050908203051.GE11509@a5.repetae.net> Message-ID: <20050908234222.GA30737@momenergy.repetae.net> On Thu, Sep 08, 2005 at 01:30:51PM -0700, Frederik Eaton wrote: > On Thu, Sep 08, 2005 at 09:30:34AM -0700, Scherrer, Chad wrote: > > One of Mark Jones's articles suggests something like > > > > class Plus a b c | a b -> c where > > (+) :: a -> b -> c > > > > Would > > > > instance (Plus a b c, Monad m) => Plus (m a) (m b) (m c) where > > mx + my = do x <- mx > > y <- my > > return (x + y) > > > > do what you're looking for? > > Hi Chad, > > I'm not sure exactly what you have in mind. Obviously I want something > that applies to all functions, with any number of arguments, and not > just (+). Furthermore, it should handle cases like 1+[2,3] where only > one value is monadic. Keean Schupke's suggestion sounds more likely to > be useful, but I'm still reading it. In any case, a minimum of > syntactic overhead is desired. I think what he means is that if we had a somewhat better design of the prelude type classes, we would be able to do this in haskell now for most interesting operations. as we could write an instance like instance (Monad m,Num a) => Num (m a) where .. .. of course, we can't do this because Num has Ord and Show as superclasses when it really doesn't need to. (we would have to create a separate class for 'pattern matchable nums' if we got rid of those, but that is no problem other than being non-haskell-98 compatable). Solving this 'class inflexibility' problem in general is something I have given some thought too. I will let everyone know if I figure something out... John -- John Meacham - ?repetae.net?john? From wnoise at ofb.net Fri Sep 9 04:37:00 2005 From: wnoise at ofb.net (Aaron Denney) Date: Fri Sep 9 04:20:57 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions References: <20050908203051.GE11509@a5.repetae.net> <20050908234222.GA30737@momenergy.repetae.net> Message-ID: On 2005-09-08, John Meacham wrote: > of course, we can't do this because Num has Ord and Show as superclasses > when it really doesn't need to. (we would have to create a separate > class for 'pattern matchable nums' if we got rid of those, but that is > no problem other than being non-haskell-98 compatable). Solving this > 'class inflexibility' problem in general is something I have given some > thought too. I will let everyone know if I figure something out... Has anyone found any problem with your "superclasses" proposal? http://repetae.net/john/recent/out/supertyping.html -- Aaron Denney -><- From wolfgang at jeltsch.net Fri Sep 9 06:22:20 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Sep 9 06:03:28 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908203051.GE11509@a5.repetae.net> References: <20050908203051.GE11509@a5.repetae.net> Message-ID: <200509091222.20966.wolfgang@jeltsch.net> Am Donnerstag, 8. September 2005 22:30 schrieb Frederik Eaton: > Hi Chad, > > I'm not sure exactly what you have in mind. Obviously I want something > that applies to all functions, with any number of arguments, and not > just (+). Furthermore, it should handle cases like 1+[2,3] where only > one value is monadic. Keean Schupke's suggestion sounds more likely to > be useful, but I'm still reading it. In any case, a minimum of > syntactic overhead is desired. > > Frederik Hello, I doubt that it is a good thing to extend the language in a way that such far reaching declarations are automatically generated. I would like to have more control about which things are declared and which are not and also in which way the are declared. In addition, I'm against giving a specific class (Monad) a very special position among all classes. One of the advantages of functional programming languages is that the language directly supports very little features but is so powerful that you can define new features by using the language. Maybe, it would be good that those people who want this automatic lifting of functions implement it using Template Haskell. Best regards, Wolfgang From Malcolm.Wallace at cs.york.ac.uk Fri Sep 9 06:37:44 2005 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Sep 9 06:25:06 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <200509091222.20966.wolfgang@jeltsch.net> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> Message-ID: <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> Wolfgang Jeltsch writes: > > I'm not sure exactly what you have in mind. Obviously I want something > > that applies to all functions, with any number of arguments, and not > > just (+). Furthermore, it should handle cases like 1+[2,3] where only > > one value is monadic. > > I doubt that it is a good thing to extend the language in a way that such > far reaching declarations are automatically generated. I agree. The original request was for something like [1,2] + [3,4] to be automatically lifted into a monad. But surely it is not too difficult to define the required behaviour precisely (and only) where needed, e.g. (+.) = liftM2 (+) [1,2] +. [3,4] Where the functions in question are not infix, you don't even need to define a new name, just use (liftM fn) directly inline! Regards, Malcolm From duncan.coutts at worcester.oxford.ac.uk Fri Sep 9 07:27:34 2005 From: duncan.coutts at worcester.oxford.ac.uk (Duncan Coutts) Date: Fri Sep 9 07:07:05 2005 Subject: [Haskell] ANNOUNCE: Gtk2Hs special release with cairo support Message-ID: <1126265254.11126.31.camel@localhost> To mark the end of Paolo Martini?s project to add support for the cairo vector graphics library (cairographics.org) we are pleased to announce a special ?tech preview? release of Gtk2Hs including Paolo?s contributions. Here?s a screenshot from a demo program Paolo and others wrote to show off the combination of Haskell, cairo and Gtk+. http://haskell.org/gtk2hs/gallery/Cairo-demo/Cairo_demo_13 You can see more of his latest screenshots in his blog. http://haskell.org/gtk2hs/archives/category/cairo/ As of version 2.8, Gtk+ now depends on cairo and uses it for much of it?s drawing. It is a great advance over Gtk?s previous drawing API. The cairo website describes it thusly: Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System, win32, and image buffers. Experimental backends include OpenGL (through glitz), Quartz, XCB, PostScript and PDF file output. Cairo is designed to produce consistent output on all output media while taking advantage of display hardware acceleration when available (for example, through the X Render Extension). The cairo API provides operations similar to the drawing operators of PostScript and PDF. Operations in cairo including stroking and filling cubic B?zier splines, transforming and compositing translucent images, and antialiased text rendering. All drawing operations can be transformed by any affine transformation (scale, rotation, shear, etc.). We encourage anyone who has Gtk+ 2.8 installed to give this Gtk2Hs release a try and to experiment with using the cairo drawing API. Bug reports and cool screenshots will be gratefully accepted. Download: http://haskell.org/gtk2hs/gtk2hs-0.9.9.5.tar.gz The release includes some demos showing how to use cairo in a stand alone fashion to produce PNG image files and also demos showing how to use the cairo API for drawing in a Gtk+ GUI (both real-time and non-real-time). There is also some preliminary reference documentation available: http://haskell.org/gtk2hs/docs/gtk2hs-docs-0.9.9.5/ This release is not intended for packaging for distros. The next ordinary release will of course retain the cairo support. It is intended that the cairo package will eventually be distributed separately since it is useful in non-GUI programs too. This project was undertaken by Paolo as part of Google?s Summer of Code programme. In our opinion his project has been a success and so we would like to recommend to Paolo?s official mentor at Google and the judges that he be counted amongst the successful SoC programme participants and awarded the full project grant. Duncan (on behalf of the Gtk2Hs team) From k.schupke at imperial.ac.uk Fri Sep 9 07:39:29 2005 From: k.schupke at imperial.ac.uk (Keean Schupke) Date: Fri Sep 9 07:21:07 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <43217471.20406@imperial.ac.uk> Malcolm Wallace wrote: >Wolfgang Jeltsch writes: > > > >>>I'm not sure exactly what you have in mind. Obviously I want something >>>that applies to all functions, with any number of arguments, and not >>>just (+). Furthermore, it should handle cases like 1+[2,3] where only >>>one value is monadic. >>> >>> >>I doubt that it is a good thing to extend the language in a way that such >>far reaching declarations are automatically generated. >> >> > >I agree. The original request was for something like > [1,2] + [3,4] >to be automatically lifted into a monad. But surely it is not too >difficult to define the required behaviour precisely (and only) >where needed, e.g. > > (+.) = liftM2 (+) > > [1,2] +. [3,4] > > > Why not make the monad an instance of Num, then you do not proliferate meaningless similar symbols... besides which I am sure all the good ones are used in libraries already (like +. <+> etc) ;) instance (Monad m, Show a) => Show (m a) ... instance (Monad m, Ord a) => Ord (m a) ... instance (Monad m, Num a,Show (m a),Ord (m a)) -> Num (m a) where (+) = liftM2 (+) The instances for Show and Ord can be empty if you don't need the functionality... Regards, Keean. From k.schupke at imperial.ac.uk Fri Sep 9 07:54:58 2005 From: k.schupke at imperial.ac.uk (Keean Schupke) Date: Fri Sep 9 07:36:36 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <43217471.20406@imperial.ac.uk> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> Message-ID: <43217812.7060407@imperial.ac.uk> Keean Schupke wrote: >>>> I'm not sure exactly what you have in mind. Obviously I want something >>>> that applies to all functions, with any number of arguments, and not >>>> just (+). Furthermore, it should handle cases like 1+[2,3] where only >>>> one value is monadic. >>> Just noticed the 1+[1,2] case... I am not certain whether this is possible - it is outside the scope of the formal definiton of Haskell and may rely on implementation details of the compiler/interpreter. Effectivly we need to redefine list as a class, then (Num a) can be made an instance of the class... See my implementation of Joy in the HList library. (this lifts numbers into an AST rather than a list) - this however uses type level programming and has problems with non static types (IE you need to use existentials for lists who's values is not known at compile time)... The easy answer is to define a type that contains both singletons and lists... although the type constructors may not look as neat. Regards, Keean. From trevion at gmail.com Fri Sep 9 08:05:02 2005 From: trevion at gmail.com (J. Garrett Morris) Date: Fri Sep 9 07:46:09 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <43217812.7060407@imperial.ac.uk> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> Message-ID: <6cf91caa050909050523271929@mail.gmail.com> On 9/9/05, Keean Schupke wrote: > Just noticed the 1+[1,2] case... I am not certain whether this is > possible - it is outside the > scope of the formal definiton of Haskell and may rely on implementation > details of the compiler/interpreter. While this is outside the scope of the current Num class, if we adopt the suggestion to redefine the standard classes using functional dependencies (which is, I think, a useful addition to the standard prelude anyway), we have, for example: class Plus a b c | a b -> c where (+) :: a -> b -> c instance (Plus a b c, Functor f) => a -> f b -> f c where a + fb = fmap (a +) fb and so forth. However, this doesn't generalize obviously (in any way that I see) to generic two argument functions, which seemed to be what Frederik wanted. /g From wnoise at ofb.net Fri Sep 9 14:17:48 2005 From: wnoise at ofb.net (Aaron Denney) Date: Fri Sep 9 14:03:33 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> Message-ID: On 2005-09-09, Keean Schupke wrote: > Keean Schupke wrote: > >>>>> I'm not sure exactly what you have in mind. Obviously I want something >>>>> that applies to all functions, with any number of arguments, and not >>>>> just (+). Furthermore, it should handle cases like 1+[2,3] where only >>>>> one value is monadic. >>>> > Just noticed the 1+[1,2] case... I am not certain whether this is > possible - it is outside the > scope of the formal definiton of Haskell and may rely on implementation > details of the compiler/interpreter. > > Effectivly we need to redefine list as a class, then (Num a) can be made > an instance of the class... See my implementation of Joy in the HList > library. (this lifts numbers into an AST rather than a list) - this > however uses type level programming and has problems with non static > types (IE you need to use existentials for lists who's values is not > known at compile time)... > > The easy answer is to define a type that contains both singletons and > lists... although the type constructors may not look as neat. I thought the easy answer would be to inject non-monadic values into the monad (assuming one already rejiggered things to do automatic lifting). -- Aaron Denney -><- From dpw at CS.Princeton.EDU Fri Sep 9 14:46:03 2005 From: dpw at CS.Princeton.EDU (David Walker) Date: Fri Sep 9 15:16:11 2005 Subject: [Haskell] SPACE 2006: Call for Papers Message-ID: <200509091846.j89Ik83E006801@bluebox.CS.Princeton.EDU> SPACE 2006 Third workshop on SEMANTICS, PROGRAM ANALYSIS, AND COMPUTING ENVIRONMENTS FOR MEMORY MANAGEMENT January 14, 2006 Charleston, South Carolina Sponsored by ACM/SIGPLAN http://www.itu.dk/research/plt/space2006/ ------------------------------------------------------------------------ Memory management is a difficult engineering task. We desperately need new tools and analyses that can identify memory management errors in low-level C/C++ code, such as dereferencing a pointer to an object that has been recycled or failing to reclaim an object. We also need new data structures and algorithms to avoid overheads such as fragmentation and synchronization. High-level languages such as Java or ML insulate the programmer from many of these problems through automatic memory management techniques (e.g., garbage collection). But standard GC techniques are not always suitable for all domains. For instance, programmers for embedded and real-time systems need static guarantees about resource requirements that are difficult to meet with standard collection algorithms. New languages, logics, analyses, and type systems are needed that let us reason about the management of memory, time, and other critical resources, whether using manual or automatic methods. The aim of this workshop is to bring together researchers for a fruitful exchange of ideas on semantics, program analysis and computing environments for memory management. SCOPE: Topics of interest include but are not limited to: * alternative memory management strategies (.e.g, region- or reap-based) * memory management for constrained (embedded, real-time, etc.) systems * analyses for optimization of memory management * analyses for faults in manual memory management * types, semantics, logics, and calculi for memory management * applications of statically controlled memory management * empirical results for new or existing memory management strategies TIME AND PLACE: The workshop takes place in Charleston, South Carolina on January 14, 2006. It is co-located with POPL 2006, which takes place January 11-13, 2006. IMPORTANT DATES: * Submission deadline: midnight EST, Thursday, November 10, 2005 * Electronic PC meeting: Monday/Tuesday, November 28/29, 2005 * Notification: Tuesday, December 2, 2005 * Final copy: midnight, Friday, December 16, 2005 * Workshop: Saturday, January 14, 2006 FORMAT: The workshop will consist of: * 25-minute presentations by authors of selected, peer-reviewed papers * 10-minute short presentations (non-peer reviewed) * two 45-minute invited talks (to be determined) * a series of "5-minute madness" talks as time permits The long papers will be selected by a program committee and only "lightly" reviewed. Our goal in selecting papers is to meet our time requirements and present a balanced program. We hope to include all of the short presentations, but may be forced to select a subset depending on the number of submissions. Again, our goal is to have a productive, interactive workshop. At lunch-time, participants will be able to sign up for a "5-minute madness" talk slot (as time permits). These talks will be limited to at most 2 viewgraphs and are meant to give a brief, perhaps provocative, viewpoint on the research issues in memory management and to spark conversation. A moderator will limit time according to the excitement generated by the presentation. INFORMAL PROCEEDINGS: We will distribute an informal proceedings at the workshop only. We do not consider the proceedings to be a formal (citable) publication so that any works in progress presented here may be submitted later for formal publication. The informal proceedings for the workshop will consist of the accepted papers, and titles and abstracts for the short presentations. LONG PAPERS: Authors should submit a 12 page extended abstract formatted using the ACM LaTeX sig-alternate format (http://www.acm.org/sigs/pubs/proceed/template.html). Accepted final papers will be allowed to be longer (up to 20 pages). SHORT PRESENTATIONS: Authors should submit a 2-3 page abstract formatted using the ACM LaTeX sig-alternate format (http://www.acm.org/sigs/pubs/proceed/template.html). The title should start with "Short Presentation: ". INFORMATION: Please refer to the workshop home page at http://www.itu.dk/research/plt/space2006 for up-to-date information on location, invited talks, participation, and so on. REGISTRATION: For information on registration, accommodation etc, please refer to the POPL 2006 conference web pages. STEERING COMMITTEE: * Fritz Henglein, Dept. of Computer Science, University of Copenhagen * Richard Jones, Computing Laboratory, University of Kent * Greg Morrisett, Division of Engineering and Applied Science, Harvard University * Peter O'Hearn, Dept. of Computer Science, Queen Mary, University of London PROGRAM CHAIRS: * Martin Elsman, IT University of Copenhagen * David Walker, Princeton University PROGRAM COMMITTEE: * Amal Ahmed, Harvard University * Perry Cheng, IBM (T.J. Watson Research Center) * Martin Elsman, IT University of Copenhagen * Philippa Gardner, Imperial College * Michael Hicks, University of Maryland * Martin Hofmann, Ludwig-Maximilians-Universit?t M?nchen * Atsushi Igarashi, Kyoto University * Mooly Sagiv, Tel-Aviv University * David Walker, Princeton University PREVIOUS SPACE WORKSHOPS: The first SPACE workshop was held in connection with POPL 2001 at Imperial College, London, January 15-16, 2001. The second SPACE workshop was held in connection with POPL 2004 in Venice, Italy, January 12, 2004. From frederik at a5.repetae.net Fri Sep 9 16:17:57 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri Sep 9 15:59:16 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <431FF799.3060209@imperial.ac.uk> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <431FF799.3060209@imperial.ac.uk> Message-ID: <20050909201757.GC2080@a5.repetae.net> On Thu, Sep 08, 2005 at 09:34:33AM +0100, Keean Schupke wrote: > Can't you do automatic lifting with a "Runnable" class: > > class Runnable x y where > run :: x -> y > > instance Runnable (m a) (m a) where > run = id > > instance Runnable (s -> m a) (s -> m a) where > run = id > instance (Monad m,Monad n,MonadT t m,Runnable (m a) (n a)) => Runnable (t m a) (n a) where > run = run . down Interesting... > instance (Monad m,MonadT t m,Monad (t m)) => Runnable (t m a) (m a) where > run = down The above is redundant, right? > Where: > > class (Monad m,Monad (t m)) => MonadT t m where > up :: m a -> t m a > down :: t m a -> m a > > For example for StateT: > ... So, 'run' is more like a form of casting than running, right? How do I use it to add two lists? Where do the 'run' applications go? Do you have an explicit example? I was trying to test things out, and I'm running into problems with the type system, for instance when I declare: class Cast x y where cast :: x -> y instance Monad m => Cast x (m x) where cast = return p1 :: (Monad m, Num a) => m (a -> a -> a) p1 = cast (+) it says: Could not deduce (Cast (a1 -> a1 -> a1) (m (a -> a -> a))) from the context (Monad m, Num a) arising from use of `cast' at runnable1.hs:14:5-8 But this should match the instance I declared, I don't understand what the problem is. Frederik -- http://ofb.net/~frederik/ From frederik at a5.repetae.net Fri Sep 9 16:42:41 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri Sep 9 16:24:01 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050909201757.GC2080@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <431FF799.3060209@imperial.ac.uk> <20050909201757.GC2080@a5.repetae.net> Message-ID: <20050909204241.GD2080@a5.repetae.net> Anyway, if the idea is to ultimately wrap every value in an expression like ([1,2]+[3,4]) in a 'run' application, that doesn't sound very useful. Program structure might be improved, but it would be bloated out by these calls. Also, I don't know what would happen to the readability of type checker errors. I think it would be more useful if the compiler took care of this automatically. I think it would be worthwhile just for making imperative code more readable. Frederik P.S. By the way, did you misunderstand what I meant by 'automatic lifting'? Note that I'm talking about "lift" as in 'liftM', not 'lift' from MonadTrans. On Fri, Sep 09, 2005 at 01:17:57PM -0700, Frederik Eaton wrote: > On Thu, Sep 08, 2005 at 09:34:33AM +0100, Keean Schupke wrote: > > Can't you do automatic lifting with a "Runnable" class: > > > > class Runnable x y where > > run :: x -> y > > > > instance Runnable (m a) (m a) where > > run = id > > > > instance Runnable (s -> m a) (s -> m a) where > > run = id > > instance (Monad m,Monad n,MonadT t m,Runnable (m a) (n a)) => Runnable (t m a) (n a) where > > run = run . down > > Interesting... > > > instance (Monad m,MonadT t m,Monad (t m)) => Runnable (t m a) (m a) where > > run = down > > The above is redundant, right? > > > Where: > > > > class (Monad m,Monad (t m)) => MonadT t m where > > up :: m a -> t m a > > down :: t m a -> m a > > > > For example for StateT: > > ... > > So, 'run' is more like a form of casting than running, right? > > How do I use it to add two lists? Where do the 'run' applications go? > Do you have an explicit example? > > I was trying to test things out, and I'm running into problems with > the type system, for instance when I declare: > > class Cast x y where > cast :: x -> y > > instance Monad m => Cast x (m x) where > cast = return > > p1 :: (Monad m, Num a) => m (a -> a -> a) > p1 = cast (+) > > it says: > > Could not deduce (Cast (a1 -> a1 -> a1) (m (a -> a -> a))) > from the context (Monad m, Num a) > arising from use of `cast' at runnable1.hs:14:5-8 > > But this should match the instance I declared, I don't understand what > the problem is. > > Frederik > > -- > http://ofb.net/~frederik/ > -- http://ofb.net/~frederik/ From frederik at a5.repetae.net Fri Sep 9 17:56:06 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri Sep 9 17:37:24 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> Message-ID: <20050909215606.GA26645@a5.repetae.net> By the way, I thought it would be obvious, but a lot of people seem to be missing the fact that I'm not (as Sean, I believe, isn't) requesting limited support for 1 or 2 or 3 argument functions or certain type classes to be applied to monads, or for certain operations to defined on certain types. I know at least how to define type classes and functions. If this is what I wanted I would probably do it myself. > I thought the easy answer would be to inject non-monadic values into the > monad (assuming one already rejiggered things to do automatic lifting). I don't know if this is the right way of looking at it. Do you have an example? My idea is that you should be able to have code like this: -- (a) m3 :: a -> m b m6 = do m1 m2 m3 (p1 (p2 p3 (p4 m4 p5)) p6) m5 - where the m* values are functions returning monads and the p* values are so-called "pure" functions, i.e. functions which don't take monad values or return monad results (so currently the above code won't type-check beacuse of m4) - but have it be interpreted as: -- (b) m3 :: a -> m b m6 = do m1 m2 v <- m4 m3 (p1 (p2 p3 (p4 v p5) p6) m5 Note that in (a), "pure" values are never used where monads are asked for, only the other way around. I think that supporting syntax (a) for semantics (b) should be a feature because: (1) it is (usually) obvious what (a) means; (2) it eliminates the single-use variable 'v' - single-use variables like this occur a lot in monadic Haskell code, and I think they make it harder to read and write; (3) it would support the math-like syntax that I presented in my original message. It might be hard to modify the type checker to get it to work, but I think it is possible, and I see no reason not to be as general as possible. Would it mean treating the 'Monad' class specially? Perhaps, but I don't think this is a reason to avoid it. Further, it is likely that whatever is done to extend the type checker could be given a general interface, which Monad would simply take advantage of, using a meta-declaration in the same spirit as "infixr" etc. Also, I do not think that template haskell is powerful enough to support this, but I'm willing to be proven wrong. Frederik -- http://ofb.net/~frederik/ From cgibbard at gmail.com Fri Sep 9 19:12:00 2005 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri Sep 9 18:53:04 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: <20050909215606.GA26645@a5.repetae.net> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> <20050909215606.GA26645@a5.repetae.net> Message-ID: <89ca3d1f050909161212dddc2b@mail.gmail.com> Despite having a fairly mathematical background, I don't really care for the proposed syntax. myList :: [[Integer]] myList = return [1,2,3,4] Is myList equal to [[1,2,3,4]] or [[1],[2],[3],[4]]? Either interpretation is possible if there is automatic lifting about. If the lifting only occurs when a type error would otherwise have happened, then there will be cases where genuine type errors are happening and being obscured by automatic lifting. This basically takes a type error reported at compile time, which, in the case where it would have been solved by lifting, is easily resolved by simply adding a line to a do-block or by using liftM, and turns it into a potential behavioural error which may only be detected at runtime, and whose source in the code may not be so obvious (since the lifting was unintentional in the first place). Also, a class instance, say of Num for lists (treating them as polynomials/power series) would suddenly turn one valid piece of code, like [1,2,3] + [4,5,6] defined by automatic lifting, into a completely different one, and suddenly silently introduce bugs into previously written code in the module (perhaps written by another author who had intended to use the automatic lifting). I think that's reason enough to make people say what they mean in each case. Automatic lifting is performed in mathematics because it is assumed that the reader is an intelligent human who will be able to infer quite reasonably what is meant in each (often somewhat ambiguous) case. Haskell programs are not written only for humans, but also for the Haskell compiler, which can't be expected to (and quite possibly shouldn't try to) judge the intent of a piece of code. - Cale On 09/09/05, Frederik Eaton wrote: > By the way, I thought it would be obvious, but a lot of people seem to > be missing the fact that I'm not (as Sean, I believe, isn't) > requesting limited support for 1 or 2 or 3 argument functions or > certain type classes to be applied to monads, or for certain > operations to defined on certain types. I know at least how to define > type classes and functions. If this is what I wanted I would probably > do it myself. > > > I thought the easy answer would be to inject non-monadic values into the > > monad (assuming one already rejiggered things to do automatic lifting). > > I don't know if this is the right way of looking at it. Do you have an > example? > > My idea is that you should be able to have code like this: > > -- (a) > > m3 :: a -> m b > > m6 = do > m1 > m2 > m3 (p1 (p2 p3 (p4 m4 p5)) p6) > m5 > > - where the m* values are functions returning monads and the p* values > are so-called "pure" functions, i.e. functions which don't take monad > values or return monad results (so currently the above code won't > type-check beacuse of m4) - but have it be interpreted as: > > -- (b) > > m3 :: a -> m b > > m6 = do > m1 > m2 > v <- m4 > m3 (p1 (p2 p3 (p4 v p5) p6) > m5 > > Note that in (a), "pure" values are never used where monads are asked > for, only the other way around. > > I think that supporting syntax (a) for semantics (b) should be a > feature because: (1) it is (usually) obvious what (a) means; (2) it > eliminates the single-use variable 'v' - single-use variables like > this occur a lot in monadic Haskell code, and I think they make it > harder to read and write; (3) it would support the math-like syntax > that I presented in my original message. > > It might be hard to modify the type checker to get it to work, but I > think it is possible, and I see no reason not to be as general as > possible. > > Would it mean treating the 'Monad' class specially? Perhaps, but I > don't think this is a reason to avoid it. Further, it is likely that > whatever is done to extend the type checker could be given a general > interface, which Monad would simply take advantage of, using a > meta-declaration in the same spirit as "infixr" etc. > > Also, I do not think that template haskell is powerful enough to > support this, but I'm willing to be proven wrong. > > Frederik > > -- > http://ofb.net/~frederik/ > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From claus.reinke at talk21.com Fri Sep 9 19:55:15 2005 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Sep 9 19:34:57 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions References: <20050908203051.GE11509@a5.repetae.net><200509091222.20966.wolfgang@jeltsch.net><20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk><43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> <20050909215606.GA26645@a5.repetae.net> Message-ID: <010e01c5b599$ee7fbde0$ae1ffea9@vaio> life is funny, isn't it? so many people so eagerly discussing conversion between non-monadic and monadic code, yet when we asked for your opinions and suggestions on this very topic only a short while ago, we got a total of 4 (four) replies - all quite useful, mind you, so we were grateful, but still one wonders.. we might have assumed that not many people cared after all: http://www.haskell.org//pipermail/haskell/2005-March/015557.html shall I assume that all participants in this discussion have joined the Haskell parade since then, and have proceeded rapidly to the problems of monadic lifting?-) in which case I'd invite you to have a look at that survey and the papers mentioned. > > I thought the easy answer would be to inject non-monadic values into the > > monad (assuming one already rejiggered things to do automatic lifting). I'd phrase it slightly differently: what (I think) one wants are implicit coercions between monadic and non-monadic types of expressions, where the coercions lift non-monadic values into the monad in question, while embedding monadic computations in the current monad to get a non-monadic result if only that is needed (although one might think of the latter as partially lifting the operation that needs the non-monadic result). only I wouldn't want those implicit coercions to be introduced unless programmers explicitly ask for that (one usually only converts code from non-monadic to monadic once, and while the details of that step might be tiresome and in need of tool-support, the step itself should be explicit - see my comment on (2) below). > Note that in (a), "pure" values are never used where monads are asked > for, only the other way around. that is probably where some would beg to differ - if you lift operations, why not lift values as well? > I think that supporting syntax (a) for semantics (b) should be a > feature because: (1) it is (usually) obvious what (a) means; (2) it > eliminates the single-use variable 'v' - single-use variables like > this occur a lot in monadic Haskell code, and I think they make it > harder to read and write; (3) it would support the math-like syntax > that I presented in my original message. (1) "(usually) obvious" is tech-speak for "(perhaps) possible to figure out, though probably not uniquely determined"?-) when mathematicians abuse notation in the "obvious" way, there is usually an assumed context in which the intended abuses are clearly defined (if not, there is another context in which the "obvious" things will go unexpectedly awry). (2) the nice thing about Haskell is that it *distinguishes* between monadic and non-monadic computations, and between evaluation and execution of monadic computations. if you want everything mixed into one soup, ML might be your language of choice (http://portal.acm.org/citation.cfm?id=178047 , if I recall correctly? see the paper discussed in http://lambda-the-ultimate.org/node/view/552 for one application that demonstrates the power/danger of such implicit monads). (3) using math-like syntax for lifted expressions is common practice in some families of Haskell-DSELs, eg. Conal Elliot's Fran. As John pointed out, the predefined class-hierarchy is not really helpful for such endeavours, but if one isn't picky, one may ignore classes not used.. the "trick" is to lift even constants, so when you get to applications, all components are already lifted, and lifting most arithmetic works out fine (Boolean operations are another matter). note, however, that the resulting language, while looking mathematically pure and permitting concise expression of complex circumstances, may not have the reasoning properties you expect.. > It might be hard to modify the type checker to get it to work, but I > think it is possible, and I see no reason not to be as general as > possible. here I'd agree, although in contrast to you, I'd be talking about a complex refactoring under programmer control, not about an implicitly invoked collection of coercions. I played with that idea after Martin Erwig visited our refactoring project in March, and got to a prototype type-coercion inference system for a very simple functional language, because I found the situation with various existing and, as Erwig/Ren pointed out, apparently unrelated monadification algorithms confusing. apart from the various styles of monadification, which we'd like to permit, and have the programmer select, e.g., by type annotations, there is the slight problem that there are an unbounded number of different monadifications (more if one wants to keep annotations to a minimum), so one needs a sensible bound (one that does not exclude any of the alternatives one might want). one also might want to be able to choose between the alternatives (or tune the system so that taking the first choice works out ok most of the time). oh, and it shouldn't be too inefficient, and it is really a pain to re-implement a type-system just to add a few coercion rules to it (which is why I haven't extended my mini fpl to Haskell yet..). in light of this, perhaps some more participants in this discussion might want to look into contributing their suggestions to our old survey? cheers, claus From wnoise at ofb.net Fri Sep 9 23:12:05 2005 From: wnoise at ofb.net (Aaron Denney) Date: Fri Sep 9 22:55:12 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> <20050909215606.GA26645@a5.repetae.net> Message-ID: On 2005-09-09, Frederik Eaton wrote: > >> I thought the easy answer would be to inject non-monadic values into the >> monad (assuming one already rejiggered things to do automatic lifting). > > I don't know if this is the right way of looking at it. Do you have an > example? In a do block, 1 + [2,3,4] would get turned into liftM2 (+) (return 1) [2, 3, 4] (I actually think this whole thing is a horrible idea, much for the reasons Cale Gibbard puts forward.) > Would it mean treating the 'Monad' class specially? Perhaps, but I > don't think this is a reason to avoid it. Further, it is likely that > whatever is done to extend the type checker could be given a general > interface, which Monad would simply take advantage of, using a > meta-declaration in the same spirit as "infixr" etc. Well, monads are already treated specially -- the whole do syntax. -- Aaron Denney -><- From frederik at a5.repetae.net Sat Sep 10 03:09:49 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sat Sep 10 02:51:04 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: <89ca3d1f050909161212dddc2b@mail.gmail.com> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> <20050909215606.GA26645@a5.repetae.net> <89ca3d1f050909161212dddc2b@mail.gmail.com> Message-ID: <20050910070949.GA936@a5.repetae.net> These are good arguments, and I think this is a good direction for the discussion, should it continue. > Despite having a fairly mathematical background, I don't really care > for the proposed syntax. > > myList :: [[Integer]] > myList = return [1,2,3,4] I'm assuming you mean myList :: [[Integer]] myList = [1,2,3,4] > Is myList equal to [[1,2,3,4]] or [[1],[2],[3],[4]]? Either > interpretation is possible if there is automatic lifting about. If the > lifting only occurs when a type error would otherwise have happened, > then there will be cases where genuine type errors are happening and > being obscured by automatic lifting. Perhaps. The question is whether enough type errors will be left over to keep type checking useful. I'm willing to explore the possibility that there are. This is not the same as an all-purpose, C++-style "cast" operator. It only applies to Monads, and it never makes them disappear, it only introduces and propagates them. The effect on the type system is thus circumscribed. You can only introduce a Monad in "monadic context". I think there may be better examples than the one you gave. To me it it seems intuitive that myList should be [[1,2,3,4]]. It also seems intuitive that this can be turned into a general rule, although I'm not accustomed to this sort of reasoning. By the way, I'm not entirely confident in the definition of "monadic context" that I gave in a message dated "Wed, 7 Sep 2005 23:41:41 -0700". > This basically takes a type error reported at compile time, which, in > the case where it would have been solved by lifting, is easily > resolved by simply adding a line to a do-block or by using liftM, and > turns it into a potential behavioural error which may only be detected > at runtime, and whose source in the code may not be so obvious (since > the lifting was unintentional in the first place). This is true, if you see the two values as essentialy different. But if you intended to write [[1,2],[3,4]], and you're complaining that the type system would no longer save you from omitting the outer and middle brackets by accident, then I would say: but even now it doesn't save you from omitting just the middle brackets by accident. You still have to watch what you type. And I would say, furthermore, that many of the errors that the type system currently catches are a result of programs being too far from their specifications, in the present syntax, and that if my proposal succeeds in bringing them closer, then it isn't clear that there won't be a net decrease in errors as a result. Many of the technologies which Haskell researchers are inventing to make programming easier already have this effect - of making errors harder to detect, but compensating by making programs more concise. Strong typing is a great language feature, but it isn't the only one. > Also, a class instance, say of Num for lists (treating them as > polynomials/power series) would suddenly turn one valid piece of code, > like [1,2,3] + [4,5,6] defined by automatic lifting, into a completely > different one, and suddenly silently introduce bugs into previously > written code in the module (perhaps written by another author who had > intended to use the automatic lifting). Again, I'm trying to imagine a better example. In this case, personally: even if I weren't forced to, and even if it just wrapped a list, I would create my own polynomial datatype with 'newtype'. Just for the sake of clarity. So it would not be a problem. Am I being obtuse? > ... Automatic lifting is performed in mathematics because it is > assumed that the reader is an intelligent human who will be able to > infer quite reasonably what is meant in each (often somewhat > ambiguous) case. Haskell programs are not written only for humans, > but also for the Haskell compiler, which can't be expected to (and > quite possibly shouldn't try to) judge the intent of a piece of > code. This is a most persuasive observation. And it is often true that these authors we invoke for mathematicians will explicitly "declare" what they mean before adding functions or sets, as I am being asked to do. However, they'll also define explicitly what a homomorphism is, over and over again, separately; for groups, rings, fields, etc. But the fact is that we don't really use separate concepts for homomorphisms on different categories, when we think about them. And if we look closely we can even discover a simple and unambiguous rule uniting them, and we can apply this rule to programming language design. The fact that the general rule was also given to us in the form of different specialized versions, by mathematicians, let alone by programmers, doesn't mean that we shouldn't try to do better. I think the same is true for a large class of mathematical shorthand (and I think that the importance of notation is underrated). I think most such shorthand can be understood simply in terms of lifting, and I hypothesize that we can find an automatic lifting rule along the lines I've described which will not be as ambiguous as you suggest. Frederik > On 09/09/05, Frederik Eaton wrote: > > By the way, I thought it would be obvious, but a lot of people seem to > > be missing the fact that I'm not (as Sean, I believe, isn't) > > requesting limited support for 1 or 2 or 3 argument functions or > > certain type classes to be applied to monads, or for certain > > operations to defined on certain types. I know at least how to define > > type classes and functions. If this is what I wanted I would probably > > do it myself. > > > > > I thought the easy answer would be to inject non-monadic values into the > > > monad (assuming one already rejiggered things to do automatic lifting). > > > > I don't know if this is the right way of looking at it. Do you have an > > example? > > > > My idea is that you should be able to have code like this: > > > > -- (a) > > > > m3 :: a -> m b > > > > m6 = do > > m1 > > m2 > > m3 (p1 (p2 p3 (p4 m4 p5)) p6) > > m5 > > > > - where the m* values are functions returning monads and the p* values > > are so-called "pure" functions, i.e. functions which don't take monad > > values or return monad results (so currently the above code won't > > type-check beacuse of m4) - but have it be interpreted as: > > > > -- (b) > > > > m3 :: a -> m b > > > > m6 = do > > m1 > > m2 > > v <- m4 > > m3 (p1 (p2 p3 (p4 v p5) p6) > > m5 > > > > Note that in (a), "pure" values are never used where monads are asked > > for, only the other way around. > > > > I think that supporting syntax (a) for semantics (b) should be a > > feature because: (1) it is (usually) obvious what (a) means; (2) it > > eliminates the single-use variable 'v' - single-use variables like > > this occur a lot in monadic Haskell code, and I think they make it > > harder to read and write; (3) it would support the math-like syntax > > that I presented in my original message. > > > > It might be hard to modify the type checker to get it to work, but I > > think it is possible, and I see no reason not to be as general as > > possible. > > > > Would it mean treating the 'Monad' class specially? Perhaps, but I > > don't think this is a reason to avoid it. Further, it is likely that > > whatever is done to extend the type checker could be given a general > > interface, which Monad would simply take advantage of, using a > > meta-declaration in the same spirit as "infixr" etc. > > > > Also, I do not think that template haskell is powerful enough to > > support this, but I'm willing to be proven wrong. > > > > Frederik > > > > -- > > http://ofb.net/~frederik/ > > _______________________________________________ > > Haskell mailing list > > Haskell@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > -- http://ofb.net/~frederik/ From cs-haskell at nil.ics.uci.edu Sat Sep 10 09:03:27 2005 From: cs-haskell at nil.ics.uci.edu (Christian Stork) Date: Sat Sep 10 08:44:51 2005 Subject: [Haskell] Uniqueness types for Haskell? Message-ID: <20050910130327.GA11907@anthony.ics.uci.edu> After looking at the language Clean (http://www.cs.ru.nl/~clean/) I wonder why there does not seem to be the desire to integrate uniquness typing into Haskell. Any ideas, pointers, comments? -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F From ndmitchell at gmail.com Sat Sep 10 09:17:28 2005 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Sep 10 08:58:30 2005 Subject: [Haskell] Uniqueness types for Haskell? In-Reply-To: <20050910130327.GA11907@anthony.ics.uci.edu> References: <20050910130327.GA11907@anthony.ics.uci.edu> Message-ID: <404396ef050910061718d71e24@mail.gmail.com> > Any ideas, pointers, comments? Hacle: http://www-users.cs.york.ac.uk/~mfn/hacle/ It transforms from Haskell to Clean, so I would have thought it has a transformation to convert certainly the IO Monad to uniqueness types. Neil From gale at sefer.org Sat Sep 10 14:34:23 2005 From: gale at sefer.org (Yitzchak Gale) Date: Sat Sep 10 14:15:22 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: <89ca3d1f050909161212dddc2b@mail.gmail.com> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> <20050909215606.GA26645@a5.repetae.net> <89ca3d1f050909161212dddc2b@mail.gmail.com> Message-ID: <20050910183423.GA3172@mail.actcom.co.il> I heartily agree with everything Cale wrote on this topic. In addition, I hereby apologize to Claus for being too lazy to participate in the survey. Regards, Yitz Cale Gibbard wrote: > Despite having a fairly mathematical background, I don't really care > for the proposed syntax. > > myList :: [[Integer]] > myList = return [1,2,3,4] > > Is myList equal to [[1,2,3,4]] or [[1],[2],[3],[4]]? Either > interpretation is possible if there is automatic lifting about. If the > lifting only occurs when a type error would otherwise have happened, > then there will be cases where genuine type errors are happening and > being obscured by automatic lifting. > > This basically takes a type error reported at compile time, which, in > the case where it would have been solved by lifting, is easily > resolved by simply adding a line to a do-block or by using liftM, and > turns it into a potential behavioural error which may only be detected > at runtime, and whose source in the code may not be so obvious (since > the lifting was unintentional in the first place). > > Also, a class instance, say of Num for lists (treating them as > polynomials/power series) would suddenly turn one valid piece of code, > like [1,2,3] + [4,5,6] defined by automatic lifting, into a completely > different one, and suddenly silently introduce bugs into previously > written code in the module (perhaps written by another author who had > intended to use the automatic lifting). > > I think that's reason enough to make people say what they mean in each > case. Automatic lifting is performed in mathematics because it is > assumed that the reader is an intelligent human who will be able to > infer quite reasonably what is meant in each (often somewhat > ambiguous) case. Haskell programs are not written only for humans, but > also for the Haskell compiler, which can't be expected to (and quite > possibly shouldn't try to) judge the intent of a piece of code. > > - Cale > > On 09/09/05, Frederik Eaton wrote: > > By the way, I thought it would be obvious, but a lot of people seem to > > be missing the fact that I'm not (as Sean, I believe, isn't) > > requesting limited support for 1 or 2 or 3 argument functions or > > certain type classes to be applied to monads, or for certain > > operations to defined on certain types. I know at least how to define > > type classes and functions. If this is what I wanted I would probably > > do it myself. > > > > > I thought the easy answer would be to inject non-monadic values into the > > > monad (assuming one already rejiggered things to do automatic lifting). > > > > I don't know if this is the right way of looking at it. Do you have an > > example? > > > > My idea is that you should be able to have code like this: > > > > -- (a) > > > > m3 :: a -> m b > > > > m6 = do > > m1 > > m2 > > m3 (p1 (p2 p3 (p4 m4 p5)) p6) > > m5 > > > > - where the m* values are functions returning monads and the p* values > > are so-called "pure" functions, i.e. functions which don't take monad > > values or return monad results (so currently the above code won't > > type-check beacuse of m4) - but have it be interpreted as: > > > > -- (b) > > > > m3 :: a -> m b > > > > m6 = do > > m1 > > m2 > > v <- m4 > > m3 (p1 (p2 p3 (p4 v p5) p6) > > m5 > > > > Note that in (a), "pure" values are never used where monads are asked > > for, only the other way around. > > > > I think that supporting syntax (a) for semantics (b) should be a > > feature because: (1) it is (usually) obvious what (a) means; (2) it > > eliminates the single-use variable 'v' - single-use variables like > > this occur a lot in monadic Haskell code, and I think they make it > > harder to read and write; (3) it would support the math-like syntax > > that I presented in my original message. > > > > It might be hard to modify the type checker to get it to work, but I > > think it is possible, and I see no reason not to be as general as > > possible. > > > > Would it mean treating the 'Monad' class specially? Perhaps, but I > > don't think this is a reason to avoid it. Further, it is likely that > > whatever is done to extend the type checker could be given a general > > interface, which Monad would simply take advantage of, using a > > meta-declaration in the same spirit as "infixr" etc. > > > > Also, I do not think that template haskell is powerful enough to > > support this, but I'm willing to be proven wrong. > > > > Frederik > > > > -- > > http://ofb.net/~frederik/ > > _______________________________________________ > > Haskell mailing list > > Haskell@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > From wolfgang at jeltsch.net Sat Sep 10 18:03:58 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Sat Sep 10 17:45:02 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: <20050909215606.GA26645@a5.repetae.net> References: <20050909215606.GA26645@a5.repetae.net> Message-ID: <200509110003.58368.wolfgang@jeltsch.net> Am Freitag, 9. September 2005 23:56 schrieb Frederik Eaton: > [...] > Would it mean treating the 'Monad' class specially? Perhaps, but I > don't think this is a reason to avoid it. As far as I can see, your approach would make Haskell a kind of imperative programming language. Side-effects would be hidden in expressions which is a thing I want to see strictly avoided. > [...] > Also, I do not think that template haskell is powerful enough to > support this, but I'm willing to be proven wrong. I suppose that Template Haskell is powerful enough to automatically declare instances of classes like Num for monadic types, based on instances for non-monadic types. > Frederik Best wishes, Wolfgang From wolfgang at jeltsch.net Sat Sep 10 18:17:57 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Sat Sep 10 17:59:00 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: References: <20050909215606.GA26645@a5.repetae.net> Message-ID: <200509110017.58215.wolfgang@jeltsch.net> Am Samstag, 10. September 2005 05:12 schrieb Aaron Denney: > [...] > Well, monads are already treated specially -- the whole do syntax. But the do syntax isn't a very drastic special treatment of monads. There is a relatively simple syntax-based transformation into code without do expressions. Best wishes, Wolfgang From frederik at a5.repetae.net Sat Sep 10 19:25:23 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sat Sep 10 19:06:40 2005 Subject: [Haskell] Monadification as a refactoring [was: Mixing monadic and non-monadic functions] In-Reply-To: <010e01c5b599$ee7fbde0$ae1ffea9@vaio> References: <20050909215606.GA26645@a5.repetae.net> <010e01c5b599$ee7fbde0$ae1ffea9@vaio> Message-ID: <20050910232523.GA22894@a5.repetae.net> On Sat, Sep 10, 2005 at 12:55:15AM +0100, Claus Reinke wrote: > life is funny, isn't it? so many people so eagerly lazily, in my case > discussing conversion between non-monadic and monadic code, I'm trying to discuss a new syntax, not code transformations. I agree that the two are related. I'm interested in the latter, but I don't understand it very well. I think of refactoring as an operation that takes source code to source code, i.e. unlike most operations done on source code, refactoring produces output which is meant to be edited by humans. Is this correct? But if it is, doesn't it mean that one would like refactorizations to have some ill-defined "reversibility" property: a refactorization should have an inverse which commutes with simple edits For instance, if I (a) rename a variable, and then (b) introduce a new reference to the renamed variable somewhere, I can later decide to change the name back, reverting (a), without losing the work I did in the meantime in (b). I can do this by applying another rename operation, which will also affect the new reference. Or, if I (a) take a bit of code and remove it to a separate function, and then (b) modify the body of that function, I can later decide to inline the function back into the one place which calls it, thus reverting (a), without losing the modification done in (b). Yet, I don't see how the "monadification" operations you propose could have this property. They are certainly code transformations! But they seem irreversible - once I (a) apply your transformations and (b) edit the output, I can't revert (a) without losing the work done in (b). Changes to the code become tightly coupled, design becomes less tractable. > yet when we asked for your opinions and suggestions on this very > topic only a short while ago, we got a total of 4 (four) replies - > all quite useful, mind you, so we were grateful, but still one > wonders.. we might have assumed that not many people cared after > all: > > http://www.haskell.org//pipermail/haskell/2005-March/015557.html It might have been more useful to ask for survey replies to be sent to the list. Often the various opinions of a large number of people can be compressed to a few representative positions. But if respondents can't see what opinions have been expressed so far, then this time-saving compression becomes impossible. That is just my opinion. > shall I assume that all participants in this discussion have joined > the Haskell parade since then, and have proceeded rapidly to the > problems of monadic lifting?-) in which case I'd invite you to have > a look at that survey and the papers mentioned. I should do that, yes! It's just that I was a bit late, having misplaced my trumpet. > > > I thought the easy answer would be to inject non-monadic values into the > > > monad (assuming one already rejiggered things to do automatic lifting). > > I'd phrase it slightly differently: what (I think) one wants are implicit coercions > between monadic and non-monadic types of expressions, where the coercions > lift non-monadic values into the monad in question, while embedding monadic > computations in the current monad to get a non-monadic result if only that is > needed (although one might think of the latter as partially lifting the operation > that needs the non-monadic result). > > only I wouldn't want those implicit coercions to be introduced unless > programmers explicitly ask for that (one usually only converts code from > non-monadic to monadic once, and while the details of that step might > be tiresome and in need of tool-support, the step itself should be explicit > - see my comment on (2) below). > > > Note that in (a), "pure" values are never used where monads are asked > > for, only the other way around. > > that is probably where some would beg to differ - if you lift operations, > why not lift values as well? Oh, one should do both, I was just giving a case where value-lifting didn't happen, as a counterexample to Aaron's viewpoint. > > I think that supporting syntax (a) for semantics (b) should be a > > feature because: (1) it is (usually) obvious what (a) means; (2) it > > eliminates the single-use variable 'v' - single-use variables like > > this occur a lot in monadic Haskell code, and I think they make it > > harder to read and write; (3) it would support the math-like syntax > > that I presented in my original message. > > (1) "(usually) obvious" is tech-speak for "(perhaps) possible to > figure out, though probably not uniquely determined"?-) > > when mathematicians abuse notation in the "obvious" way, > there is usually an assumed context in which the intended > abuses are clearly defined (if not, there is another context > in which the "obvious" things will go unexpectedly awry). > > (2) the nice thing about Haskell is that it *distinguishes* between > monadic and non-monadic computations, and between evaluation > and execution of monadic computations. if you want everything > mixed into one soup, ML might be your language of choice > (http://portal.acm.org/citation.cfm?id=178047 , if I recall correctly? > see the paper discussed in > http://lambda-the-ultimate.org/node/view/552 > for one application that demonstrates the power/danger of such > implicit monads). > > (3) using math-like syntax for lifted expressions is common practice > in some families of Haskell-DSELs, eg. Conal Elliot's Fran. As John > pointed out, the predefined class-hierarchy is not really helpful > for such endeavours, but if one isn't picky, one may ignore classes > not used.. the "trick" is to lift even constants, so when you get > to applications, all components are already lifted, and lifting most > arithmetic works out fine (Boolean operations are another matter). > > note, however, that the resulting language, while looking > mathematically pure and permitting concise expression of complex > circumstances, may not have the reasoning properties you expect.. At this point I think we have to look at more examples. I'm not convinced that my position is right, but I'm not convinced that that it is wrong either. I just think it's promising, based on my experience. If I were a better person, and had more free time, I would work on producing examples and working things out myself, and perhaps write a paper or something. Of course, experienced people are disagreeing with me, so maybe I should just accept their good judgment! In any case, I'm afraid I don't have much more to contribute, beyond the idea itself. > > It might be hard to modify the type checker to get it to work, but I > > think it is possible, and I see no reason not to be as general as > > possible. > > here I'd agree, although in contrast to you, I'd be talking about a > complex refactoring under programmer control, not about an implicitly > invoked collection of coercions. I played with that idea after Martin > Erwig visited our refactoring project in March, and got to a prototype > type-coercion inference system for a very simple functional language, > because I found the situation with various existing and, as Erwig/Ren > pointed out, apparently unrelated monadification algorithms confusing. > > apart from the various styles of monadification, which we'd like > to permit, and have the programmer select, e.g., by type annotations, > there is the slight problem that there are an unbounded number of > different monadifications (more if one wants to keep annotations to > a minimum), so one needs a sensible bound (one that does not > exclude any of the alternatives one might want). one also might > want to be able to choose between the alternatives (or tune the > system so that taking the first choice works out ok most of the > time). oh, and it shouldn't be too inefficient, and it is really a pain > to re-implement a type-system just to add a few coercion rules to > it (which is why I haven't extended my mini fpl to Haskell yet..). Well, I've said a little about why I don't like irreversible refactoring. I've been reading "Notes on the Synthesis of Form" by Christopher Alexander, I think this has helped me understand the process of design in more abstract terms, if you want a reference. I think the source code of a program should be as close to its initial specification as possible. The goal should be to make it as easy to read and modify as it was to write. However, if the design is spread out over write/test/debug cycles, as is often the case in interpreted languages such as perl; or refactor cycles, as you seem to be proposing; then a lot of the decisions and rationales which determine that design will not be visible in the final version of the code - rather, they will be stored in the succession of modifications which have been applied to create this final version. But these modifications are, as it were, difficult to go back and modify. The more a program is produced through a process of accretion or evolution, the more tightly coupled various aspects of its design will be, and the more difficult it will be to change any one of them. Even if most of the design decisions are good ones, eventually the number of unfixable bad decisions will grow until continued development of a particular component becomes untenable. This might happen at a function level or a module level or a program level - but in any case I think the development style in question should be avoided where possible, and made avoidable where feasible. Frederik From cgibbard at gmail.com Sun Sep 11 01:48:16 2005 From: cgibbard at gmail.com (Cale Gibbard) Date: Sun Sep 11 01:29:15 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: <20050910070949.GA936@a5.repetae.net> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> <20050909215606.GA26645@a5.repetae.net> <89ca3d1f050909161212dddc2b@mail.gmail.com> <20050910070949.GA936@a5.repetae.net> Message-ID: <89ca3d1f050910224813bd2335@mail.gmail.com> On 10/09/05, Frederik Eaton wrote: > These are good arguments, and I think this is a good direction for the > discussion, should it continue. > > > Despite having a fairly mathematical background, I don't really care > > for the proposed syntax. > > > > myList :: [[Integer]] > > myList = return [1,2,3,4] > > I'm assuming you mean > > myList :: [[Integer]] > myList = [1,2,3,4] No, the confusion is over whether to lift the return, because the inner and outer monads are the same. It's either return [1,2,3,4] == [[1,2,3,4]], or it's liftM return [1,2,3,4] == [[1],[2],[3],[4]] > > > Is myList equal to [[1,2,3,4]] or [[1],[2],[3],[4]]? Either > > interpretation is possible if there is automatic lifting about. If the > > lifting only occurs when a type error would otherwise have happened, > > then there will be cases where genuine type errors are happening and > > being obscured by automatic lifting. > > Perhaps. The question is whether enough type errors will be left over > to keep type checking useful. I'm willing to explore the possibility > that there are. This is not the same as an all-purpose, C++-style > "cast" operator. It only applies to Monads, and it never makes them > disappear, it only introduces and propagates them. The effect on the > type system is thus circumscribed. You can only introduce a Monad in > "monadic context". > > I think there may be better examples than the one you gave. To me it > it seems intuitive that myList should be [[1,2,3,4]]. It also seems > intuitive that this can be turned into a general rule, although I'm > not accustomed to this sort of reasoning. > > By the way, I'm not entirely confident in the definition of "monadic > context" that I gave in a message dated "Wed, 7 Sep 2005 23:41:41 > -0700". > > > This basically takes a type error reported at compile time, which, in > > the case where it would have been solved by lifting, is easily > > resolved by simply adding a line to a do-block or by using liftM, and > > turns it into a potential behavioural error which may only be detected > > at runtime, and whose source in the code may not be so obvious (since > > the lifting was unintentional in the first place). > > This is true, if you see the two values as essentialy different. > > But if you intended to write [[1,2],[3,4]], and you're complaining > that the type system would no longer save you from omitting the outer > and middle brackets by accident, then I would say: but even now it > doesn't save you from omitting just the middle brackets by accident. > You still have to watch what you type. Well, the concern isn't so much for explicit lists as such (as errors there are quite visible), but when the lists involved are abstract anyway, perhaps hidden in some chain of compositions. > > And I would say, furthermore, that many of the errors that the type > system currently catches are a result of programs being too far from > their specifications, in the present syntax, and that if my proposal > succeeds in bringing them closer, then it isn't clear that there won't > be a net decrease in errors as a result. Many of the technologies > which Haskell researchers are inventing to make programming easier > already have this effect - of making errors harder to detect, but > compensating by making programs more concise. Strong typing is a great > language feature, but it isn't the only one. > > > Also, a class instance, say of Num for lists (treating them as > > polynomials/power series) would suddenly turn one valid piece of code, > > like [1,2,3] + [4,5,6] defined by automatic lifting, into a completely > > different one, and suddenly silently introduce bugs into previously > > written code in the module (perhaps written by another author who had > > intended to use the automatic lifting). > > Again, I'm trying to imagine a better example. In this case, > personally: even if I weren't forced to, and even if it just wrapped a > list, I would create my own polynomial datatype with 'newtype'. Just > for the sake of clarity. So it would not be a problem. Am I being > obtuse? > Well, that's true, but many types are instances of Monad and instances of another class, and often not in a way which is compatible with your form of lifting. That's the generic version of the point which I'd hoped would be extracted from the example. > > ... Automatic lifting is performed in mathematics because it is > > assumed that the reader is an intelligent human who will be able to > > infer quite reasonably what is meant in each (often somewhat > > ambiguous) case. Haskell programs are not written only for humans, > > but also for the Haskell compiler, which can't be expected to (and > > quite possibly shouldn't try to) judge the intent of a piece of > > code. > > This is a most persuasive observation. > > And it is often true that these authors we invoke for mathematicians > will explicitly "declare" what they mean before adding functions or > sets, as I am being asked to do. However, they'll also define > explicitly what a homomorphism is, over and over again, separately; > for groups, rings, fields, etc. > > But the fact is that we don't really use separate concepts for > homomorphisms on different categories, when we think about them. And > if we look closely we can even discover a simple and unambiguous rule > uniting them, and we can apply this rule to programming language > design. The fact that the general rule was also given to us in the > form of different specialized versions, by mathematicians, let alone > by programmers, doesn't mean that we shouldn't try to do better. > > I think the same is true for a large class of mathematical shorthand > (and I think that the importance of notation is underrated). I think > most such shorthand can be understood simply in terms of lifting, and > I hypothesize that we can find an automatic lifting rule along the > lines I've described which will not be as ambiguous as you suggest. > Why not look for a way to do the lifting which is explicit, yet not inconvenient? Monads often do a great job of this on their own. One can already write code with a fair amount of convenience which works across monads and which determines its effects based on its inputs. It may be possible to use template haskell to derive an automatic monad lifter which could be applied in a controlled fashion, and if people really like it, it could be given some special syntax perhaps. Another point which is perhaps important to mention is that the monadification of some code is not really something which is unique. The right level of abstraction is sometimes not to just apply liftMn to everything, but to use something stronger, like MonadPlus, and to be careful about how everything happens. This can come up when producing a nondeterministic abstraction of an initially deterministic algorithm. Full nondeterminism without any optimisation is often not what you want. You might want to work with a subset of the combinations of the inputs that may not at first be obvious, and there are various optimisations which may be necessary to curb combinatorial explosion (even though laziness often does help a lot here). To do this sort of optimisation, you need an instance of MonadPlus (or at least MonadZero, but that's not around anymore). Also, if the whole thing is autolifted, you can't inject these controls into the middle, and end up lifting the code by hand anyway. Careful application of the generic lifting could be very useful, but unrestrained, in many cases could completely fail to be helpful. Also, with multiparameter functions, liftMn isn't always the right thing to apply. Maybe some parameters should be lifted to one monad and others to another, and the results collected in a suitable combination. This sort of thing is hard to do automatically, and it can be difficult to tell. What we probably want is an explicit, but generic, lifting mechanism, which takes care of the boilerplate parts of the lifting, but which we can control with some precision. Doing it automatically everywhere seems like it could often be inconvenient. - Cale From dons at cse.unsw.edu.au Mon Sep 12 00:13:24 2005 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sun Sep 11 23:54:24 2005 Subject: [Haskell] mini-announce: fast packed strings v0.1 In-Reply-To: <20050825041044.GA14151@cse.unsw.EDU.AU> References: <20050825041044.GA14151@cse.unsw.EDU.AU> Message-ID: <20050912041324.GA30364@cse.unsw.EDU.AU> After some weeks of hacking, and after taking into consideration the suggestions on this list, from darcs-devel and on #haskell, I've tagged and released v0.1 of the FastPackedString library, FPS. FPS provides mmapped and malloc'd packed strings, along with a list interface to these strings. It lets you do extremely fast IO in Haskell; in some cases, even faster than typical C implementations. Some of the changes since the port from darcs include: * Added a full List interface * Full haddocks * QuickCheck and HUnit tests * Improved performance for many functions, after extensive profiling * Now uses qualified names, e.g. P.length instead of lengthPS * Type is now 'FastString', so as not to clash with the old 'PackedString' * Some new constructors, particularly for Addr# and CStrings Home: http://www.cse.unsw.edu.au/~dons/fps.html Docs: http://www.cse.unsw.edu.au/~dons/fps/Data.FastPackedString.html Src: ftp://ftp.cse.unsw.edu.au/pub/users/dons/fps/fps-0.1.tar.gz Darcs: darcs get --partial http://www.cse.unsw.edu.au/~dons/code/fps Feedback is very welcome, and encouraged. -- Don Stewart From ralfla at microsoft.com Tue Sep 13 02:18:40 2005 From: ralfla at microsoft.com (Ralf Lammel) Date: Tue Sep 13 01:59:36 2005 Subject: [Haskell] OOHaskell -- major release of report and library Message-ID: <1152E22EE8996742A7E36BBBA7768FEE07026D4E@RED-MSG-50.redmond.corp.microsoft.com> An extended technical report has been released at: TR & software: http://homepages.cwi.nl/~ralf/OOHaskell/ TR: http://arxiv.org/abs/cs.PL/0509027 "Haskell's overlooked object system" 10 September 2005, 79 pages by O. Kiselyov (FNMOC, Monterey, CA, USA) and R. Laemmel (Microsoft Corp., WA, USA) Some recently added topics: - Many Haskell 98 encodings - Safe value recursion - Safe downcasts - Safe co-variant method arguments - Nominal subtyping - Iso-recursive object types - With and depth subtyping The report describes and classifies all principled, to our best knowledge, object encodings in Haskell98, with and without common extensions. On the one hand, this report covers many advanced topics, as to make it interesting for programming language researchers. On the other hand, the report is detailed and lightweight enough to be useful as an OO-FP tutorial. Regards, Oleg and Ralf From ahey at iee.org Tue Sep 13 02:51:47 2005 From: ahey at iee.org (Adrian Hey) Date: Tue Sep 13 02:25:38 2005 Subject: [Haskell] StringMaps available Message-ID: <200509130751.47061.ahey@iee.org> Hello, I've put the first release of Data.StringMap here.. http://homepages.nildram.co.uk/~ahey/HLibs/Data.StringMap/ The implementation is a bit different than what was discussed earlier as I decided the first version would burn heap unecessarily. It's still based on Tries though. I'm afraid I won't be able to do much Haskelling for a few months so not much will be added in the near future. But if anybody would like to use this but finds the absence of some function or other a show stopping issue then let me know and I'll add it. Regards -- Adrian Hey From simonmar at microsoft.com Tue Sep 13 08:29:10 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Sep 13 08:10:04 2005 Subject: [Haskell] reading call graphs Message-ID: <3429668D0E777A499EE74A7952C382D10470AE4B@EUR-MSG-01.europe.corp.microsoft.com> On 24 August 2005 11:10, Malcolm Wallace wrote: > "Scherrer, Chad" writes: > >> individual inherited >> COST CENTRE MODULE no. entries %time %alloc %time %alloc >> >> >> MAIN MAIN 1 0 0.0 0.0 100.0 100.0 >> main Main 228 92329 0.2 0.9 99.8 99.8 >> step Main 259 679 38.4 26.6 56.6 39.2 >> >> I'm trying to understand the "entries" column. I thought this was the >> number of times a given function is called. But "main" is >> nonrecursive, and only calls "step" (also nonrecursive) once. Where >> are the 92329 and 679 coming from? > > Perhaps these functions are split into smaller chunks by the > compiler/optimiser? Then the profiler would aggregate the data for > the individual chunks back up into the original cost centre. That's a plausible hypothesis. Each time an expression of the form ({-# SCC "foo" #-} e) is evaluated, the entries count for "foo" is incremented. The effect of -auto-all is to wrap each top-level function in an {-# SCC #-} expression, so you would normally get one entry per call of the function. However, the optimiser can change the structure of the code. Optimisations are supposed to retain the cost attribution model, but they don't necessarily retain the same entry counts. Basically I find the entries figure is a useful sanity check (i.e. "is this function called at all?"), but not much more than that. Cheers, Simon From wolfgang at jeltsch.net Wed Sep 14 05:17:42 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Sep 14 04:58:42 2005 Subject: [Haskell] A Gentle Introduction to Haskell Version 98 Message-ID: <200509141117.43007.wolfgang@jeltsch.net> Hello, the web page under http://haskell.org/tutorial/ says: This is the master HTML version of the Gentle Introduction To Haskell, version 98. Revised June, 2000 by Reuben Thomas. However, the Postscript, gezipped PDF, PDF and DVI versions don't mention Reuben Thomas as co-author and have October 1999 as their date. The downloadable HTML version doesn't mention Reuben Thomas too and has September 28, 1999 as its date. So what is true? Ist the online version different from the download versions and is the downloadable HTML version different from the other download versions? Did Reuben Thomas modify the tutorial? Which versions do contain his modifications, which not? Best wishes, Wolfgang From wolfgang at jeltsch.net Wed Sep 14 05:25:24 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Sep 14 05:06:15 2005 Subject: [Haskell] how to cite the (revised) Haskell Report Message-ID: <200509141125.24429.wolfgang@jeltsch.net> Hello, how should one cite the revised Haskell Report? As "Journal of Functional Programming 13(1)" or "Haskell 98 Language and Libraries, The Revised Report"? Who should be mentioned as the editor? According to http://www.cambridge.org/uk/journals/JFP/, Paul Hudak is the editor of the Journal of Functional Programming but Simon Peyton Jones is the editor of the revised Haskell Report. Would someone be able to post a sample BibTeX entry? That would be nice. Best wishes, Wolfgang From ben.horsfall at gmail.com Wed Sep 14 05:53:24 2005 From: ben.horsfall at gmail.com (Ben Horsfall) Date: Wed Sep 14 05:34:16 2005 Subject: [Haskell] how to cite the (revised) Haskell Report In-Reply-To: <200509141125.24429.wolfgang@jeltsch.net> References: <200509141125.24429.wolfgang@jeltsch.net> Message-ID: On 14/09/05, Wolfgang Jeltsch wrote: > Would someone be able to post a sample BibTeX entry? That would be nice. I cite it like this: @article{haskell98, author = {Simon {Peyton Jones} and others}, title = {The {Haskell} 98 Language and Libraries: The Revised Report}, journal = {Journal of Functional Programming}, volume = 13, number = 1, pages = {0--255}, month = {Jan}, year = 2003, note = {\url{http://www.haskell.org/definition/}}, } From paul.hudak at yale.edu Wed Sep 14 08:38:28 2005 From: paul.hudak at yale.edu (Paul Hudak) Date: Wed Sep 14 08:19:18 2005 Subject: [Haskell] A Gentle Introduction to Haskell Version 98 References: <200509141117.43007.wolfgang@jeltsch.net> Message-ID: <432819C4.3060609@yale.edu> Reuben Thomas is not a co-author of the Gentle Introduction, although it looks like he's had something to do with the HTML rendering of it. John Peterson would know more about that but I think that he's off-line for awhile. In any case, the non-HTML versions should all be consistent, with Hudak/Fasel/Peterson as authors. I really don't know much about the HTML version, except that it's handy to have on-line :-) -Paul Hudak Wolfgang Jeltsch wrote: > Hello, > > the web page under http://haskell.org/tutorial/ says: > > This is the master HTML version of the Gentle Introduction To Haskell, > version 98. Revised June, 2000 by Reuben Thomas. > > However, the Postscript, gezipped PDF, PDF and DVI versions don't mention > Reuben Thomas as co-author and have October 1999 as their date. The > downloadable HTML version doesn't mention Reuben Thomas too and has September > 28, 1999 as its date. > > So what is true? Ist the online version different from the download versions > and is the downloadable HTML version different from the other download > versions? Did Reuben Thomas modify the tutorial? Which versions do contain > his modifications, which not? > > Best wishes, > Wolfgang From paul.hudak at yale.edu Wed Sep 14 09:08:29 2005 From: paul.hudak at yale.edu (Paul Hudak) Date: Wed Sep 14 08:49:19 2005 Subject: [Haskell] how to cite the (revised) Haskell Report References: <200509141125.24429.wolfgang@jeltsch.net> Message-ID: <432820CD.3080701@yale.edu> Alternatively, you could cite the book version: @book{Haskell98Book ,editor={Simon Peyton Jones} ,title={Haskell 98 Language and Libraries -- The Revised Report} ,publisher={Cambridge University Press} ,address={Cambridge, England} ,year=2003 } Ben Horsfall wrote: > On 14/09/05, Wolfgang Jeltsch wrote: > >>Would someone be able to post a sample BibTeX entry? That would be nice. > > > I cite it like this: > > @article{haskell98, > author = {Simon {Peyton Jones} and others}, > title = {The {Haskell} 98 Language and Libraries: The Revised Report}, > journal = {Journal of Functional Programming}, > volume = 13, > number = 1, > pages = {0--255}, > month = {Jan}, > year = 2003, > note = {\url{http://www.haskell.org/definition/}}, > } > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Professor Paul Hudak Department of Computer Science Office: (203) 432-1235 Yale University FAX: (203) 432-0593 P.O. Box 208285 email: paul.hudak@yale.edu New Haven, CT 06520-8285 WWW: www.cs.yale.edu/~hudak From wolfgang at jeltsch.net Wed Sep 14 10:23:08 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Sep 14 10:04:03 2005 Subject: [Haskell] how to cite the (revised) Haskell Report In-Reply-To: <432820CD.3080701@yale.edu> References: <200509141125.24429.wolfgang@jeltsch.net> <432820CD.3080701@yale.edu> Message-ID: <200509141623.09179.wolfgang@jeltsch.net> Am Mittwoch, 14. September 2005 15:08 schrieb Paul Hudak: > @book{Haskell98Book > ? ? ?,editor={Simon Peyton Jones} > ? ? ?,title={Haskell 98 Language and Libraries -- The Revised Report} > ? ? ?,publisher={Cambridge University Press} > ? ? ?,address={Cambridge, England} > ? ? ?,year=2003 > ? ? ?} Thank you (and the others too). Well, I think you should use "Peyton Jones, Simon" instead of "Simon Peyton Jones" because in the latter case, Peyton would be considered a middle name. Best wishes, Wolfgang From Benjamin.Rudiak-Gould at cl.cam.ac.uk Wed Sep 14 10:32:27 2005 From: Benjamin.Rudiak-Gould at cl.cam.ac.uk (Ben Rudiak-Gould) Date: Wed Sep 14 10:13:22 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050908044323.GA6037@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> Message-ID: <4328347B.1040708@cl.cam.ac.uk> Frederik Eaton wrote: > I want the type system to be able to do "automatic lifting" of monads, > i.e., since [] is a monad, I should be able to write the following: > > [1,2]+[3,4] > > and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". The main problem is ambiguity: [[1]]++[[2]] could be [[1],[2]] or [[1,2]], for example. If your proposal resolves this ambiguity in favor of one result or the other, then I'm opposed to it -- it's far too easy in practice to write code like this, expecting it to be lifted, and failing to notice that it also has an interpretation without lifting (or the other way around). This is the Perl FWIM disease[1] -- not that I dislike Perl, but people are quite rightly leery about bringing this sort of thing into Haskell. I have another proposal, though. Introduce a new keyword, which I'll call "borrow" (the opposite of "return"), that behaves like a function of type (Monad m) => m a -> a inside of do statements. More precisely, a do expression of the form do { ... ; ... borrow E ... ; ... } is transformed into do { ... ; x <- E ; ... x ... ; ... } where x is a fresh variable. If more than one borrow form appears in the same do statement, they are pulled out from left to right, which matches the convention already used in liftM2, ap, mapM, etc. Pros: + Pure sugar; no tricky interactions with the type system. + Nice symmetry between putting a value in a monad and taking it out. + Potentially helpful for beginners who ask "how do I get a String from an IO String?" Cons: - Needs a new keyword. - Pretends to be an expression but really isn't; perhaps distinctive syntax would be better. (Inline "<-"?) - Depends on enclosing do keyword: in particular, do { stmt } would no longer be equivalent to stmt, if stmt contains "borrow". Potential confusion. - Potentially misleading for beginners (but then so is do notation, and the keyword "class", and n+k patterns, and so on...) -- Ben [1] http://www.dcs.gla.ac.uk/~partain/haskerl/partain-1.html From wolfgang at jeltsch.net Wed Sep 14 11:07:37 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Sep 14 10:48:29 2005 Subject: [Haskell] how to cite the (revised) Haskell Report In-Reply-To: References: <200509141125.24429.wolfgang@jeltsch.net> Message-ID: <200509141707.37965.wolfgang@jeltsch.net> Am Mittwoch, 14. September 2005 11:53 schrieb Ben Horsfall: > @article{haskell98, > ? author = {Simon {Peyton Jones} and others}, > ? title = {The {Haskell} 98 Language and Libraries: The Revised Report}, > ? journal = {Journal of Functional Programming}, > ? volume = 13, > ? number = 1, > ? pages = {0--255}, > ? month = {Jan}, > ? year = 2003, > ? note = {\url{http://www.haskell.org/definition/}}, > } Hello, could you please give a more specific page range? There is a situation similar to the Haskell Report with the current Scheme report. The Scheme report was published as volume 11, issue 1 of Higher-Order and Symbolic Computation. The corresponding entry on http://www.informatik.uni-trier.de/~ley/db/journals/lisp/lisp11.html exactly specifies the page range as 7-105 although the Scheme report is said to cover the whole issue. Alas, I couldn't find a page similar to the one above for the Journal of Functional Programming. The content information which should be available from http://www.cambridge.org/uk/journals/JFP/ is broken. Clicking on "Contents (1997 onwards)" gives me an empty text file with the title "bladerunner". :-o Best wishes, Wolfgang From jgoerzen at complete.org Wed Sep 14 11:35:10 2005 From: jgoerzen at complete.org (John Goerzen) Date: Wed Sep 14 12:23:51 2005 Subject: [Haskell] Haskell Weekly News: September 13, 2005 Message-ID: <20050914153510.GA15150@katherina.lan.complete.org> Haskell Weekly News: September 13, 2005 Greetings, and thanks for reading the seventh issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * CabalFind 0.1. Dimitry Golubovsky [3]announced CabalFind 0.1, an interface to search engines such as Google and Yahoo designed to help find Cabalized packages out on the Internet. 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8214 * gtk2hs with Cairo. Duncan Coutts [4]announced a special release of gtk2hs as a "tech preview" of the included Cairo bindings. Some impressive screenshots are in there as well. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12082 * OOHaskell. Ralf Laemmel and Olaf Kiselyov [5]announced a new version of their paper, "Haskell's overlooked object system" and its accompanying library. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/12077 * StringMap. Adrian Hey [6]announced his new module, Data.StringMap, which provides mapes from String keys to arbitrary values. 6. http://article.gmane.org/gmane.comp.lang.haskell.general/12104 * AVL 2.3. Adrian Hey [7]announced version 2.3 of his Data.Tree.AVL library, adding a few new features and a bit of renaming. 7. http://article.gmane.org/gmane.comp.lang.haskell.libraries/3714 Discussion Why is HWN a day late this week? Your HWN editor was stuck in some large airports that had a [8]surprising lack of Wifi. Sigh. 8. http://changelog.complete.org/node/388 Binary parser combinators. Einar Karttunen [9]asked about a binary parser combinator interface for network protocol parsing. Malcolm Wallac pointed out that nhc98 has a Binary library with a "<<" operator that could be useful. 9. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8256 Windows programming in Haskell. Brian McQueen [10]asked about Windows programming in Haskell, including access to the Windows registry, APIs, and communicating with other Windows apps. Several suggestions relating to Hugs were offered, including .NET support and some libraries. 10. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8221 Functional vs. Imperative. Dhaemon began an [11]interesting discussion by asking for some help understanding functional vs. imperative approaches. Several people commented on the IO monad, and how it is still a functional interface even though it may appear imperative at first glance. 11. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8254 Mixing monadic and non-monadic functions. A long [12]thread on this subject appeared in the Haskell list this week. Rather too long to summarize here -- take a look at the link. 12. http://thread.gmane.org/gmane.comp.lang.haskell.general/12077 Language workbenches. Yoel Jacobsen [13]wrote about an article on language workbenches, in which configuration files are actually valid code in a general-purpose language. Yoel went on to ask about doing this in Haskell. Some suggestions, such as hs-plugins, were offered. 13. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8227 Types in Template Haskell. Gracjan Polak [14]posted about some trouble with typing in Template Haskell. Several responses regarding quoting types were posted, including a reference to Simon Marlow's "update" [15]paper. 14. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8235 15. http://research.microsoft.com/~simonpj/tmp/notes2.ps Web applications. Gary began a large [16]discussion by asking about writing Web applications. Several options were mentioned, including Wash and HAppS. S. Alexander Jacobsen [17]mentioned that he will be launching a commercial chat service using Haskell and AJAX with HAppS as the underlying core. 16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8215 17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8242 Calling Haskell from C++. Felix Breuer [18]wrote about some trouble calling into Haskell from C++ programs. Several suggestions were provided, mostly relating to C++ name mangling. 18. http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/8652 What gets profiled? Niels began a [19]discussion on the use of profiling features by commenting that profiling didn't seem to show the problem in his own code. Several suggestions regarding memory use and possible reasons that profilers might miss things were provided. 19. http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/8622 Haskell Toolchain GHC 6.4.1. Simon Marlow posted an [20]update on GHC 6.4.1. Though more bug reports have been rolling in while he was away, only a few are blockers for 6.4.1. The tentative release date is September 19. 20. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/8649 Data.Monoid. Ross Paterson [21]proposed replacing an instance of Data.Monoid. There was some discussion about whether the old or new instance was better. 21. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3719 Quotes of the Week "Oh, a monad...that's just a funny name for a particular sort of arrow" Chocolate Frosted Monads, new from Cadbury ... "All the sugar, twice the arrows" Mr. Tweedsmuir, we're going to have to bypass your left ventrical monad. You'll probably never play Chopin again Readers of the ABC Warriors strip in 2000AD may remember The Monad as the concentrated essence of human evil Monadocet. Because category theory should be understood by everyone. About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [22]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 22. http://sequence.complete.org/hwn-contrib From lisper at it.kth.se Wed Sep 14 16:10:39 2005 From: lisper at it.kth.se (Bjorn Lisper) Date: Wed Sep 14 15:51:36 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <4328347B.1040708@cl.cam.ac.uk> (message from Ben Rudiak-Gould on Wed, 14 Sep 2005 15:32:27 +0100) References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> Message-ID: <200509142010.j8EKAd10006079@ripper.it.kth.se> Ben Rudiak-Gould: >Frederik Eaton wrote: >> I want the type system to be able to do "automatic lifting" of monads, >> i.e., since [] is a monad, I should be able to write the following: >> >> [1,2]+[3,4] >> >> and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}". > >The main problem is ambiguity: [[1]]++[[2]] could be [[1],[2]] or [[1,2]], >for example. If your proposal resolves this ambiguity in favor of one result >or the other, then I'm opposed to it -- it's far too easy in practice to >write code like this, expecting it to be lifted, and failing to notice that >it also has an interpretation without lifting (or the other way around). >This is the Perl FWIM disease[1] -- not that I dislike Perl, but people are >quite rightly leery about bringing this sort of thing into Haskell. However, there is a way to resolve the ambiguity that can be claimed to be the most natural one, and that is to always choose the "least possible" lifting. In the example above, this would mean to interpret [[1]]++[[2]] precisely as [[1]]++[[2]] (lift 0 levels) rather than [[1]++[2]] (lift 1 level). This is akin to choosing the most general type in the pure Hindley-Milner type system, and it has the advantage that expressions that are typable in the original type system, without lifting, retain their semantics in the type system with lifting added. Lifting (mainly of arithmetic operators) has been around for a long time in array- and data parallel languages such as Fortran 90 and *lisp. The kind of ambiguity mentioned here was first observed for nested data-parallel languages like NESL, which use nested sequences as parallel data structures. Now, whether to include this kind of lifting in Haskell or not is an entirely different story. One complication would be to handle possible clashes between lifting and overloading through the class system. IMHO, I think it would be interesting to be able to define application-specific Haskell dialects, which can have this kind of lifting for a restricted set of types and/or functions, whereas having it as a general feature of the language would be quite problematic. Björn Lisper From ben.horsfall at gmail.com Wed Sep 14 19:20:09 2005 From: ben.horsfall at gmail.com (Ben Horsfall) Date: Wed Sep 14 19:00:56 2005 Subject: [Haskell] how to cite the (revised) Haskell Report In-Reply-To: <200509141707.37965.wolfgang@jeltsch.net> References: <200509141125.24429.wolfgang@jeltsch.net> <200509141707.37965.wolfgang@jeltsch.net> Message-ID: On 15/09/05, Wolfgang Jeltsch wrote: > Am Mittwoch, 14. September 2005 11:53 schrieb Ben Horsfall: > > @article{haskell98, > > author = {Simon {Peyton Jones} and others}, > > title = {The {Haskell} 98 Language and Libraries: The Revised Report}, > > journal = {Journal of Functional Programming}, > > volume = 13, > > number = 1, > > pages = {0--255}, > > month = {Jan}, > > year = 2003, > > note = {\url{http://www.haskell.org/definition/}}, > > } > could you please give a more specific page range? These are the pages of the journal occupied by the report. Ben From wolfgang at jeltsch.net Wed Sep 14 19:37:37 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Sep 14 19:18:27 2005 Subject: [Haskell] how to cite the (revised) Haskell Report In-Reply-To: References: <200509141125.24429.wolfgang@jeltsch.net> <200509141707.37965.wolfgang@jeltsch.net> Message-ID: <200509150137.37645.wolfgang@jeltsch.net> Am Donnerstag, 15. September 2005 01:20 schrieb Ben Horsfall: > On 15/09/05, Wolfgang Jeltsch wrote: > > Am Mittwoch, 14. September 2005 11:53 schrieb Ben Horsfall: > > > @article{haskell98, > > > author = {Simon {Peyton Jones} and others}, > > > title = {The {Haskell} 98 Language and Libraries: The Revised Report}, > > > journal = {Journal of Functional Programming}, > > > volume = 13, > > > number = 1, > > > pages = {0--255}, > > > month = {Jan}, > > > year = 2003, > > > note = {\url{http://www.haskell.org/definition/}}, > > > } > > > > could you please give a more specific page range? > > These are the pages of the journal occupied by the report. > > Ben Page 0? What is that? Is the whole Journal issue equivalent to the Haskell Report? At least in the Scheme report case there seemed to be some pages of the Journal which don't actually belong to the report. Best wishes, Wolfgang From kgrapone at gmail.com Wed Sep 14 20:03:53 2005 From: kgrapone at gmail.com (Karl Grapone) Date: Wed Sep 14 19:44:41 2005 Subject: [Haskell] Realistic max size of GHC heap Message-ID: <1e082fb205091417033c347c2@mail.gmail.com> Hello, I'm considering using haskell for a system that could, potentially, need 5GB-10GB of live data. My intention is to use GHC on Opteron boxes which will give me a max of 16GB-32GB of real ram. I gather that GHC is close to being ported to amd64. Is it a realistic goal to operate with a heap size this large in GHC? The great majority of this data will be very long tenured, so I'm hoping that it'll be possible to configure the GC to not need to much peak memory during the collection phase. Thanks Karl From lists at qseep.net Wed Sep 14 23:36:08 2005 From: lists at qseep.net (Lyle Kopnicky) Date: Wed Sep 14 23:34:42 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions Message-ID: <4328EC28.8080100@qseep.net> It appears to me that: * Many people don't like having to "extract values" from a monad on a separate line, but would like to be able to mix monadic return values into pure expressions, on the way to calculating a monadic result. * Some people want to fix this by doing an implicit lifting operation on functions, when their parameters are monadic * It is not really clear what values are "monadic" and which aren't, so the implicit lifting is a guessing game, and likely to produce confounding errors. * If you aren't going to be precise about what's in the monad and what's not, you might as well use ML. I propose instead an explicit, lightweight notation, with a simple rewrite rule. Instead of: do putStr "What is your name? " s <- getLine putStrLn ("Hello " ++ s) I would like to write something like: do putStr "What is your name? " putStrLn ("Hello " ++ {* getLine *}) In other words, we use some kind of special brackets (I don't care what) to indicate that this value needs to be extracted from the monad on a previous line, and inserted back here as a "pure" value. If these occur multiply nested, they can be flattened out according to a dependency rule. E.g., do m1 {* m2 {* m3 *} v4 *} {* m5 *} ...would be rewritten as... do v3 <- m3 v2 <- m2 v3 v4 v5 <- m5 m1 v2 v5 ...and... do m1 {* {* m2 *} *} ...would become... do m2a <- m2 v2 <- m2a m1 v2 I'm sure this has been suggested before... but what do folks think? - Lyle From ben.horsfall at gmail.com Thu Sep 15 02:33:20 2005 From: ben.horsfall at gmail.com (Ben Horsfall) Date: Thu Sep 15 02:14:07 2005 Subject: [Haskell] how to cite the (revised) Haskell Report In-Reply-To: <200509150137.37645.wolfgang@jeltsch.net> References: <200509141125.24429.wolfgang@jeltsch.net> <200509141707.37965.wolfgang@jeltsch.net> <200509150137.37645.wolfgang@jeltsch.net> Message-ID: On 15/09/05, Wolfgang Jeltsch wrote: > Page 0? What is that? OK, I admit there is no page zero (although the JFP contents page gives pages 0--255, which is where the information in my bibtex file must have come from); you've forced me to look at the journal version again - I usually use the HTML. In place of page zero there should be pages i--xii, which contain the report's table of contents and preface. Thus pages = {i--xii,1--255}. Also, I give author = {... and others} rather than editor only because bibtex will not display an editor in an @article citation. Ben From simonmar at microsoft.com Thu Sep 15 06:42:44 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Thu Sep 15 06:23:33 2005 Subject: [Haskell] Realistic max size of GHC heap Message-ID: <3429668D0E777A499EE74A7952C382D10478D98E@EUR-MSG-01.europe.corp.microsoft.com> On 15 September 2005 01:04, Karl Grapone wrote: > I'm considering using haskell for a system that could, potentially, > need 5GB-10GB of live data. > My intention is to use GHC on Opteron boxes which will give me a max > of 16GB-32GB of real ram. I gather that GHC is close to being ported > to amd64. > > Is it a realistic goal to operate with a heap size this large in GHC? > The great majority of this data will be very long tenured, so I'm > hoping that it'll be possible to configure the GC to not need to much > peak memory during the collection phase. It'll be a good stress test for the GC, at least. There are no reasons in principle why you can't have a heap this big, but major collections are going to take a long time. It sounds like in your case most of this data is effectively static, so in fact a major collection will be of little use. Generational collection tries to deal with this in an adaptive way: long-lived data gets traversed less and less often as the program runs, as long as you have enough generations. But if the programmer really knows that a large chunk of data is going to be live for a long time, it would be interesting to see whether this information could be fed back in a way that the GC can take advantage of it. I'm sure there must be existing techniques for this sort of thing. Cheers, Simon From wolfgang at jeltsch.net Thu Sep 15 06:49:11 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Thu Sep 15 06:30:01 2005 Subject: [Haskell] how to cite the (revised) Haskell Report In-Reply-To: References: <200509141125.24429.wolfgang@jeltsch.net> <200509150137.37645.wolfgang@jeltsch.net> Message-ID: <200509151249.11986.wolfgang@jeltsch.net> Am Donnerstag, 15. September 2005 08:33 schrieb Ben Horsfall: > On 15/09/05, Wolfgang Jeltsch wrote: > > Page 0? What is that? > > OK, I admit there is no page zero (although the JFP contents page > gives pages 0--255, which is where the information in my bibtex file > must have come from); you've forced me to look at the journal version > again - I usually use the HTML. In place of page zero there should be > pages i--xii, which contain the report's table of contents and > preface. Thus pages = {i--xii,1--255}. Also, I give author = {... and > others} rather than editor only because bibtex will not display an > editor in an @article citation. > > Ben Thank you very much. Best wishes, Wolfgang From alex at alexjacobson.com Thu Sep 15 09:48:03 2005 From: alex at alexjacobson.com (S. Alexander Jacobson) Date: Thu Sep 15 09:28:48 2005 Subject: [Haskell] Realistic max size of GHC heap In-Reply-To: <3429668D0E777A499EE74A7952C382D10478D98E@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D10478D98E@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: Should one interpret this as GHC now targets 64-bit systems or does one need to employ some sort of clevernesss to use this much memory? (I posted this question a while ago and was told that GHC did not at that time support 64-bit so could not use that much memory) On a related note, does GHC now distribute IO threads over multiple CPUs or is it still a 1 CPU system? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Thu, 15 Sep 2005, Simon Marlow wrote: > On 15 September 2005 01:04, Karl Grapone wrote: > >> I'm considering using haskell for a system that could, potentially, >> need 5GB-10GB of live data. >> My intention is to use GHC on Opteron boxes which will give me a max >> of 16GB-32GB of real ram. I gather that GHC is close to being ported >> to amd64. >> >> Is it a realistic goal to operate with a heap size this large in GHC? >> The great majority of this data will be very long tenured, so I'm >> hoping that it'll be possible to configure the GC to not need to much >> peak memory during the collection phase. > > It'll be a good stress test for the GC, at least. There are no reasons > in principle why you can't have a heap this big, but major collections > are going to take a long time. It sounds like in your case most of this > data is effectively static, so in fact a major collection will be of > little use. > > Generational collection tries to deal with this in an adaptive way: > long-lived data gets traversed less and less often as the program runs, > as long as you have enough generations. But if the programmer really > knows that a large chunk of data is going to be live for a long time, it > would be interesting to see whether this information could be fed back > in a way that the GC can take advantage of it. I'm sure there must be > existing techniques for this sort of thing. > > Cheers, > Simon > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From simonmar at microsoft.com Thu Sep 15 11:09:52 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Thu Sep 15 10:50:40 2005 Subject: [Haskell] Realistic max size of GHC heap Message-ID: <3429668D0E777A499EE74A7952C382D10478DE54@EUR-MSG-01.europe.corp.microsoft.com> On 15 September 2005 14:48, S. Alexander Jacobson wrote: > Should one interpret this as GHC now targets 64-bit systems or does > one need to employ some sort of clevernesss to use this much memory? > (I posted this question a while ago and was told that GHC did not at > that time support 64-bit so could not use that much memory) GHC has supported 64 bit systems for quite some time, eg. we have had Alpha support for many years. Recently we've added amd64 support, which will be fully supported in the upcoming 6.4.1 release. Perhaps you're thinking of nhc98 - if I recall correctly it isn't ported to 64 bit yet. > On a related note, does GHC now distribute IO threads over multiple > CPUs or is it still a 1 CPU system? GHC has distributed IO threads over multiple CPUs for quite some time :-) You need to use the -threaded option when compiling your program. Cheers, Simon From bulatz at HotPOP.com Thu Sep 15 13:25:53 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Thu Sep 15 14:18:03 2005 Subject: [Haskell] Realistic max size of GHC heap In-Reply-To: <3429668D0E777A499EE74A7952C382D10478D98E@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D10478D98E@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <7317846371.20050915212553@HotPOP.com> Hello Simon, Thursday, September 15, 2005, 2:42:44 PM, you wrote: >> of 16GB-32GB of real ram. I gather that GHC is close to being ported SM> It'll be a good stress test for the GC, at least. There are no reasons SM> in principle why you can't have a heap this big, but major collections SM> are going to take a long time. It sounds like in your case most of this SM> data is effectively static, so in fact a major collection will be of SM> little use. may be he must use more than 2 generations? -- Best regards, Bulat mailto:bulatz@HotPOP.com From bulatz at HotPOP.com Thu Sep 15 13:19:41 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Thu Sep 15 14:18:12 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <4328347B.1040708@cl.cam.ac.uk> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> Message-ID: <3517473846.20050915211941@HotPOP.com> Hello Ben, Wednesday, September 14, 2005, 6:32:27 PM, you wrote: BRG> do { ... ; ... borrow E ... ; ... } BRG> is transformed into BRG> do { ... ; x <- E ; ... x ... ; ... } i strongly support this suggestion. actually, i suggest the same for dealing with references (IORef/MVar/...), for example: do x <- newIORef 0 y <- newIORef 0 z <- newIORef 0 z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } -- Best regards, Bulat mailto:bulatz@HotPOP.com From lists at qseep.net Thu Sep 15 14:50:30 2005 From: lists at qseep.net (Lyle Kopnicky) Date: Thu Sep 15 14:33:31 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <3517473846.20050915211941@HotPOP.com> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> Message-ID: <4329C276.4050208@qseep.net> Bulat Ziganshin wrote: >Hello Ben, > >Wednesday, September 14, 2005, 6:32:27 PM, you wrote: > >BRG> do { ... ; ... borrow E ... ; ... } > >BRG> is transformed into > >BRG> do { ... ; x <- E ; ... x ... ; ... } > >i strongly support this suggestion. actually, i suggest the same for >dealing with references (IORef/MVar/...), for example: > >do x <- newIORef 0 > y <- newIORef 0 > z <- newIORef 0 > z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } > > > Right, I realize my suggestion is the same as Ben's. I just prefer a more succinct notation, like special brackets instead of a keyword. I like your idea about IORefs. I think it should work as well for STRefs... perhaps it needs to belong to a type class, in a way? - Lyle From bulatz at HotPOP.com Thu Sep 15 15:40:23 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Thu Sep 15 15:25:49 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <4329C276.4050208@qseep.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> <4329C276.4050208@qseep.net> Message-ID: <14525916455.20050915234023@HotPOP.com> Hello Lyle, Thursday, September 15, 2005, 10:50:30 PM, you wrote: >> z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } >> LK> Right, I realize my suggestion is the same as Ben's. I just prefer a LK> more succinct notation, like special brackets instead of a keyword. I LK> like your idea about IORefs. I think it should work as well for LK> STRefs... perhaps it needs to belong to a type class, in a way? of course class Ref c a where new :: a -> IO (c a) get :: c a -> IO a set :: c a -> a -> IO () -- Best regards, Bulat mailto:bulatz@HotPOP.com From robdockins at fastmail.fm Thu Sep 15 16:25:37 2005 From: robdockins at fastmail.fm (robert dockins) Date: Thu Sep 15 16:06:23 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <14525916455.20050915234023@HotPOP.com> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> <4329C276.4050208@qseep.net> <14525916455.20050915234023@HotPOP.com> Message-ID: <4329D8C1.2090608@fastmail.fm> I raise you: class (Monad m) => Ref m c | c -> m where new :: a -> m (c a) get :: c a -> m a peek :: c a -> m a set :: c a -> a -> m () modify :: c a -> (a -> a) -> m a modify_ :: c a -> (a -> a) -> m () modifyM :: c a -> (a -> m a) -> m a modifyM_ :: c a -> (a -> m a) -> m () Bulat Ziganshin wrote: > Hello Lyle, > > Thursday, September 15, 2005, 10:50:30 PM, you wrote: > > >>> z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } >>> > > LK> Right, I realize my suggestion is the same as Ben's. I just prefer a > LK> more succinct notation, like special brackets instead of a keyword. I > LK> like your idea about IORefs. I think it should work as well for > LK> STRefs... perhaps it needs to belong to a type class, in a way? > > of course > > class Ref c a where > new :: a -> IO (c a) > get :: c a -> IO a > set :: c a -> a -> IO () > > > From ekarttun at cs.helsinki.fi Thu Sep 15 16:28:55 2005 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Thu Sep 15 16:07:47 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <14525916455.20050915234023@HotPOP.com> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> <4329C276.4050208@qseep.net> <14525916455.20050915234023@HotPOP.com> Message-ID: <20050915202855.GB27576@yui.aoinet> On 15.09 23:40, Bulat Ziganshin wrote: > of course > > class Ref c a where > new :: a -> IO (c a) > get :: c a -> IO a > set :: c a -> a -> IO () Maybe even: class Ref m t where new :: a -> m (t a) get :: t a -> m a set :: t a -> a -> m () Or if you want to support things like FastMutInts class Ref m t v where new :: v -> m t get :: t -> v -> m a set :: t -> v -> m () That would even support an evil IOArray instance: instance Ref IO (IOArray Int v, Int) v where new iv = newArray_ (0,iv) get (arr,idx) = readArray arr idx set (arr,idx) val = writeArray arr idx val - Einar Karttunen From frederik at a5.repetae.net Thu Sep 15 16:43:20 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Sep 15 16:24:10 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <4328347B.1040708@cl.cam.ac.uk> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> Message-ID: <20050915204320.GB22894@a5.repetae.net> > I have another proposal, though. Introduce a new keyword, which I'll > call "borrow" (the opposite of "return"), that behaves like a > function of type (Monad m) => m a -> a inside of do statements. More > precisely, a do expression of the form > > do { ... ; ... borrow E ... ; ... } > > is transformed into > > do { ... ; x <- E ; ... x ... ; ... } > > where x is a fresh variable. If more than one borrow form appears in > the same do statement, they are pulled out from left to right, which > matches the convention already used in liftM2, ap, mapM, etc. I think this is a good idea. I like the inline "<-", or maybe something like "@". I'm not sure what you intend to do about nested "do" statements, though. If they correspond to different monads, I might want to have a 'borrow' in the inner "do" statement create a lifted expression in the outer "do" statement. Furthermore, I might want to have a lifted expression in the outer "do" create something which needs to be evaluated again in the monad of the inner "do" to produce the final value. In any case, it would certainly be good to have better support for lifting; and something which doesn't weaken the type system is likely to be implemented before something that does is, so I am in favor of investigation along the lines of your proposal. Frederik -- http://ofb.net/~frederik/ From kgrapone at gmail.com Thu Sep 15 18:36:13 2005 From: kgrapone at gmail.com (Karl Grapone) Date: Thu Sep 15 18:16:58 2005 Subject: [Haskell] Realistic max size of GHC heap In-Reply-To: <3429668D0E777A499EE74A7952C382D10478D98E@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D10478D98E@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <1e082fb2050915153635a3d85d@mail.gmail.com> On 9/15/05, Simon Marlow wrote: > > On 15 September 2005 01:04, Karl Grapone wrote: > > > I'm considering using haskell for a system that could, potentially, > > need 5GB-10GB of live data. > > My intention is to use GHC on Opteron boxes which will give me a max > > of 16GB-32GB of real ram. I gather that GHC is close to being ported > > to amd64. > > > > Is it a realistic goal to operate with a heap size this large in GHC? > > The great majority of this data will be very long tenured, so I'm > > hoping that it'll be possible to configure the GC to not need to much > > peak memory during the collection phase. > > It'll be a good stress test for the GC, at least. Ouch! It scares me when people say that something will be a good stress test! :) There are no reasons > in principle why you can't have a heap this big, but major collections > are going to take a long time. It sounds like in your case most of this > data is effectively static, so in fact a major collection will be of > little use. You're correct, the system will gradually accrue permanent data. I forsee there being two distinct generations, a fairly constant sized short-lived one, and a gradually increasing set of immortal allocations. Response times will be critical, but hopefully the GC can be tweaked to a sweet spot. Generational collection tries to deal with this in an adaptive way: > long-lived data gets traversed less and less often as the program runs, > as long as you have enough generations. But if the programmer really > knows that a large chunk of data is going to be live for a long time, it > would be interesting to see whether this information could be fed back > in a way that the GC can take advantage of it. I'm sure there must be > existing techniques for this sort of thing. Well, I would naively say I only need two, maybe three, generations, as any memory that has been around for more than a matter of a couple of hours is definitely going to be around until system shutdown. But I'm completely new to haskell and I don't know if that holds for a lazy language. My hope was that laziness would allow for better response times but it certainly seems to muddy the GC waters. I'd like to recommend haskell, but I just don't know enough to be comfortable yet... more research methinks. Thanks for your responses. Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/haskell/attachments/20050916/91e5b899/attachment.htm From tomasz.zielonka at gmail.com Fri Sep 16 06:19:28 2005 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Fri Sep 16 06:00:17 2005 Subject: [Haskell] Re: Mixing monadic and non-monadic functions In-Reply-To: <89ca3d1f050910224813bd2335@mail.gmail.com> References: <20050908203051.GE11509@a5.repetae.net> <200509091222.20966.wolfgang@jeltsch.net> <20050909113744.47424532.Malcolm.Wallace@cs.york.ac.uk> <43217471.20406@imperial.ac.uk> <43217812.7060407@imperial.ac.uk> <20050909215606.GA26645@a5.repetae.net> <89ca3d1f050909161212dddc2b@mail.gmail.com> <20050910070949.GA936@a5.repetae.net> <89ca3d1f050910224813bd2335@mail.gmail.com> Message-ID: <20050916101928.GA1429@students.mimuw.edu.pl> On Sun, Sep 11, 2005 at 01:48:16AM -0400, Cale Gibbard wrote: > On 10/09/05, Frederik Eaton wrote: > > These are good arguments, and I think this is a good direction for the > > discussion, should it continue. > > > > > Despite having a fairly mathematical background, I don't really care > > > for the proposed syntax. > > > > > > myList :: [[Integer]] > > > myList = return [1,2,3,4] > > > > I'm assuming you mean > > > > myList :: [[Integer]] > > myList = [1,2,3,4] > > No, the confusion is over whether to lift the return, because the > inner and outer monads are the same. It's either return [1,2,3,4] == > [[1,2,3,4]], or it's liftM return [1,2,3,4] == [[1],[2],[3],[4]] I think that Frederik's example is even better. Here you either lift the entire list or each individual number: return [1,2,3,4] or [return 1,return 2,return 3,return 4] After all, return is only a fancy name for liftM0 ;-) Best regards Tomasz From kwang at ropas.snu.ac.kr Thu Sep 15 02:29:57 2005 From: kwang at ropas.snu.ac.kr (Kwangkeun Yi) Date: Fri Sep 16 07:19:54 2005 Subject: [Haskell] Call For Participation APLAS'05 Message-ID: <20050915062957.GD19096@ropas.snu.ac.kr> Apologies for multiple copies. -- CALL FOR PARTICIPATION The 3rd Asian Symposium on Programming Languages and Systems (APLAS 2005) November 3-5, 2005 Tsukuba, Japan http://ropas.snu.ac.kr/aplas05 Early Registration Ends on October 14, 2005 ------------------------------------------- VENUE -- Building: Advanced Research Laboratory B Room number 110 (Main Lecture Hall) University of Tsukuba, Japan REGISTRATION FEE -- Early Online registration (Until Oct.14) 18000 JPY (students) 25000 JPY (others) Normal online registration (Until Oct. 27) & on-site registration (Nov.2-4) 20000 JPY (students) 30000 JPY (others) HIGHLIGHTS -- . 2.5-day Technical Program . Three invited talks by . Patrick Cousot . Haruo Hosoya . Thomas Reps . 24 Contributed Papers . .5-day Tutorial . One Poster Session . Proceedings as LNCS 3780 of Springer . Excursion at Kagami Crystal (Japanese beaux-arts) and Asahi Beer brewery (cutting-edge research on beer) . Banquet Dinner at Sansui Tei (traditional Japanese cuisine) . Early Registration: Oct. 14 Please visit the conference Web site for details: http://ropas.snu.ac.kr/aplas05 POSTERS -- For poster submission, please visit: ropas.snu.ac.kr/aplas05/openconf PROGRAM -- DAY 0: November 2, 2005 13:00-17:30 Tutorials * 13:00-15:00 Type Classes with Associated Types Manuel M.T. Chakravarty * 15:30-17:30 Type Systems for Object-Oriented Languages Atsushi Igarashi 18:00-20:00 Reception in Advanced Research Laboratory B building DAY I: November 3, 2005 09:00-10:00 Invited Talk * Type Systems for XML Haruo Hosoya 10:30-12:30 Session 1 * The Essence of Dataflow Programing Tarmo Uustalu, Varmo Vene * Data Refinement with Low-level Pointer Operations Ivana Mijajlovic, Hongseok Yang * A Simple Semantics for Polymorphic Recursion William Harrison * Symbolic Execution with Separation Logic Josh Berdine, Cristiano Calcagno, Peter O'Hearn 14:00-16:00 Session 2 * An Abstract Interpretation Perspective on Linear vs. Branching Time Francesco Ranzato, Francesco Tapparo * The Parallel Implementation of the Astree Static Analyzer David Monniaux * Using Datalog with Binary Decision Diagrams for Program Analysis John Whaley, Dzintars Avots, Michael Carbin, Monica Lam * Loop invariants on demand K. Rustan M. Leino, Francesco Logozzo 16:00-17:30 Poster Session DAY II: November 4, 2005 09:00-10:00 Invited Talk Integrating Physical Systems in the Static Analysis of Embedded Control Software Patrick Cousot 10:30-12:30 Session 3 * Reflection Analysis for Java Benjamin Livshits, John Whaley, Monica Lam * Lightweight Family Polymorphism Atsushi Igarashi, Chieri Saito, Mirko Viroli * A Portable and Customizable Profiling Framework for Java Based on Bytecode Instruction Counting Walter Binder * Race Conditions in Message Sequence Charts Chien-An CHEN, Sara Kalvala, Jane Sinclair 13:00-18:00 Excursion 18:00-20:00 Banquet DAY III: November 5, 2005 09:00-10:00 Invited Talk A Next-Generation Platform for Analyzing Executables Thomas Reps, G. Balakrishnan, J. Lim, T. Teitelbaum 10:30-12:30 Session 4 * Calculating Polynomial Runtime Properties Hugh Anderson, Saiu-Cheng Khoo, Stefan Andrei, Beatrice Luca * Resource Bound Certification for a Tail-Recursive Virtual Machine Silvano Dal Zilio, Regis Gascon * A Path Sensitive Type System for Resource Usage Verification of C-like Language Hyun-Goo Kang, Youil Kim, Taisook Han, Hwansoo Han * Temrination Analysis of Higher-Order Functional Programs Damien Sereni, Neil D. Jones 14:00-16:00 Session 5 * Heterogeneous Fixed Points with Application to Points-to Analysis Aditya Kanade, Uday Khedker, Amitabha Sanyal * Register Allocation via Coloring of Chordal Graphs Fernando Magno Quintao Pereira, Jens Palsberg * Transformation to Dynamic Single Assignment Using a Simple Data Flow Analysis Peter Vanbroekhoven, Gerda Janssens, Maurice Bruynooghe, Francky Catthoor * Abstract Dependences for Alarm Diagnosis Xavier Rival 16:30-18:30 Session 6 * A Typed, Compositional Logic for a Stack-Based Abstract Machine Nick Benton * A New Occurrence Counting Analysis for BioAmbients Roberta Gori, Francesca Levi * Parametric Model Checking for Mobile Ambients Dino Distefano * On the Role of Abstract Non-Interference in Language-based Security Isabella Mastroeni 18:30-18:40 Closing -- From doublef-ctm at yandex.ru Fri Sep 16 08:02:49 2005 From: doublef-ctm at yandex.ru (Sergey Zaharchenko) Date: Fri Sep 16 07:43:42 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <3517473846.20050915211941@HotPOP.com> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> Message-ID: <20050916120249.GA6250@shark.localdomain> Hello Bulat! Thu, Sep 15, 2005 at 09:19:41PM +0400 you wrote: > Hello Ben, > > Wednesday, September 14, 2005, 6:32:27 PM, you wrote: > > BRG> do { ... ; ... borrow E ... ; ... } > > BRG> is transformed into > > BRG> do { ... ; x <- E ; ... x ... ; ... } > > i strongly support this suggestion. actually, i suggest the same for > dealing with references (IORef/MVar/...), for example: > > do x <- newIORef 0 > y <- newIORef 0 > z <- newIORef 0 > z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } I might be misunderstanding, but aren't we going to introduce evaluation order for `+' in this case? -- DoubleF No virus detected in this message. Ehrm, wait a minute... /kernel: pid 56921 (antivirus), uid 32000: exited on signal 9 Oh yes, no virus:) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.haskell.org//pipermail/haskell/attachments/20050916/c6bd2073/attachment-0001.bin From wolfgang at jeltsch.net Fri Sep 16 09:55:52 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Sep 16 09:36:36 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050916120249.GA6250@shark.localdomain> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <3517473846.20050915211941@HotPOP.com> <20050916120249.GA6250@shark.localdomain> Message-ID: <200509161555.52568.wolfgang@jeltsch.net> Am Freitag, 16. September 2005 14:02 schrieb Sergey Zaharchenko: > [...] > > do x <- newIORef 0 > > y <- newIORef 0 > > z <- newIORef 0 > > z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef > > y; writeIORef z (x'+y') } > > I might be misunderstanding, but aren't we going to introduce evaluation > order for `+' in this case? I think so and I think this is the case also for the approaches of including monadic expressions into "ordinary" expressions. That is, in my opinion, a strong argument against these proposals. One thing I like about Haskell is that side-effects are strictly separated from evaluation so that there is no such thing like an implicit evaluation order. Best wishes, Wolfgang From wolfgang at jeltsch.net Fri Sep 16 10:04:40 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Sep 16 09:45:24 2005 Subject: [Haskell] Re: [Haskell-cafe] Basic Haskell Types Question In-Reply-To: <432AB846.8090307@wyner.info> References: <432AB846.8090307@wyner.info> Message-ID: <200509161604.40658.wolfgang@jeltsch.net> Am Freitag, 16. September 2005 14:19 schrieb Adam Wyner: > [...] > But, what I don't understand or like is that the type of the whole > is given as [[Char]], not what I thought it would be, namely PropList. > Nor is it [String]. These three are essentially the same type. So a Haskell system may use whatever representation the developer of it thought is the best one. > [...] > Am I supposed to be using newtype or data declarations here? How would > I do this? I looked around for information in the usual sources, > but haven't found an answer. You should use newtype declarations since they introduce a truely new type. Apart from solving your problem, this has further advantages. A list of complex numbers may, for example, denote a polynomial or a digital filter. If you use type synonyms, as you did so far, you could use a digital filter where a polynomial is needed or vica versa. With newtype declarations you couldn't confuse these two different things. In addition, you could restrict instance declarations to just polynomials or digital filters and implement the methods so that they are meaningful for just this particular kind of thing. > Thanks, > Adam Wyner Best wishes, Wolfgang From wolfgang at jeltsch.net Fri Sep 16 10:24:08 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Sep 16 10:04:52 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <17194.51389.90269.546470@cerise.gclements.plus.com> References: <432AADE1.1000103@yahoo.co.uk> <20050916124618.GC5539@abridgegame.org> <17194.51389.90269.546470@cerise.gclements.plus.com> Message-ID: <200509161624.08812.wolfgang@jeltsch.net> Am Freitag, 16. September 2005 15:29 schrieb Glynn Clements: > David Roundy wrote: > > > Bearing this in mind, and hoping you can see where I'm coming from, I > > > think my question is: shouldn't you guys be using Lisp? > > > > Lisp is impure, weakly typed and has way too many parentheses. Why would > > we use lisp? It seems to be lacking almost all the advantages of Haskell, > > and have an ugly, inflexible syntax to boot. > > The ability to dynamically generate, manipulate and analyse code in a > structured manner provides a flexibility which is unmatched by any > other language I know of. > > A good example is Emacs; lisp is entirely the right language for that, > IMHO. Could you explain this a bit more, please? To the moment, I cannot imagine cases where you need LISP's way of code analysis and manipulation because Haskell's capabilities are not sufficient. In Haskell, code is data too because code in the sense of imperative actions is described by IO values. You cannot analyse them. But you can use your do expressions etc. to construct action descriptions with a more general type like MonadIO m => m a. Then you can instantiate m with a monad whose values store part of the action's structure so that this information can be used later. Or you use a monad which doesn't keep structural information to use it for later processing but which does the processing upon construction. Best wishes, Wolfgang From cisse at cisse2005.org Thu Sep 15 21:56:56 2005 From: cisse at cisse2005.org (cisse@cisse2005.org) Date: Fri Sep 16 10:37:06 2005 Subject: [Haskell] Call for Papers: The International Joint Conferences on Computer, Information and Systems Sciences and Engineering (CISSE 05) Message-ID: <200509160156.j8G1utSM027945@mailblast.bridgeport.edu> Dear Colleagues, You are invited to submit your work to the following international e-conference. Looking forward to receiving your submissions. Please note: (1) If you wish to unsubscribe from this e-mail list, please visit: http://cisse2005.org/unsubscribe.aspx (2) If you need more information about CISSE 2005, please visit: http://www.cisse2005.org and/or e-mail - info@cisse2005.org (3) If this is Call for Papers is outside the scope of work of your department, we would appreciate it if you can forward the Call for Papers to the appropriate department in your institution. Best Regards, ---------------------------------- Tarek M. Sobh, Ph.D., P.E., CMfgE Dean, School of Engineering University of Bridgeport 221 University Avenue Bridgeport, CT 06604, U.S.A. ---------------------------------- ====================================== International Joint Conferences on Computer, Information, and Systems Sciences, and Engineering (CISSE 05) http://www.cisse2005.org December 10-20, 2005 Sponsored by: Institute of Electrical & Electronics Engineers (IEEE) University of Bridgeport --------------------------------------------------------------------- CONFERENCE OVERVIEW --------------------------------------------------------------------- CISSE 05 provides a virtual forum for presentation and discussion of the state-of the-art research on computers, information and systems sciences and engineering. The virtual conference will be conducted through the Internet using web-conferencing tools, made available by the conference. Authors will be presenting their PowerPoint, audio or video presentations using web-conferencing tools without the need for travel. Conference sessions will be broadcast to all the conference participants, where session participants can interact with the presenter during the presentation and (or) during the Q&A slot that follows the presentation. This international conference will be held entirely on-line. The accepted and presented papers will be made available after the conference both on a CD and as a book publication. Conference participants - authors, presenters and attendees - only need an internet connection and sound available on their computers in order to be able to contribute and participate in this international ground-breaking conference. The on-line structure of this high-quality event will allow academic professionals and industry participants to contribute work and attend world-class technical presentations based on rigorously refereed submissions, live, without the need for investing significant travel funds or time out of the office. Potential non-author conference attendees who cannot make the on-line conference dates are encouraged to register, as the entire joint conferences will be archived for future viewing. CISSE 05 is composed of the following four conferences: (1) International Conference on Industrial Electronics, Technology & Automation (IETA 05) Topics: Advanced and Distributed Control Systems, Intelligent Control Systems (NN, FL, GA, .etc), Expert Systems, Man Machine Interaction, Data Fusion, Factory Automation, Robotics, Motion Control, Machine Vision, MEMS Sensors and Actuators, Sensors Fusion, Power Electronics, High Frequency Converters, Motors and Drives, Power Converters, Power Devices and Components, Electric Vehicles and Intelligent Transportation, Process Automation, Factory Communication, Manufacturing Information System Advances in Manufacturing Systems, Industrial Applications of MultiMedia, Intelligent Systems Instrumentation, Industrial Instrumentation, Modeling and Simulation, Signal Processing, Image and Data Processing, VR and Parallel systems. Conference Page: http://www.cisse2005.org/ieta.aspx (2) International Conference on Telecommunications and Networking (TeNe05) Topics: Optical Networks and Switching, Computer Networks, Network architectures and Equipment, Access Technologies, Telecommunication Technology, Coding and Modulation technique, Modeling and Simulation, Spread Spectrum and CDMA Systems, OFDM technology, Space-time Coding, Ultra Wideband Communications, Medium Access Control, Spread Spectrum, Wireless LAN: IEEE 802.11, HIPERLAN, Bluetooth, Cellular Wireless Networks, Cordless Systems and Wireless Local Loop, Mobile Network Layer, Mobile Transport Layer, Support for Mobility, Conventional Encryption and Message Confidentiality, Block Ciphers Design Principles, Block Ciphers Modes of Operation, Public-Key Cryptography and Message Authentication, Authentication Application, Stenography, Electronic Mail Security, Web Security, IP Security, Firewalls, Computer Forensics. Conference Page: http://www.cisse2005.org/tene.aspx (3) International Conference on Systems, Computing Sciences and Software Engineering (SCSS 05) Topics: Grid Computing, Internet-based Computing Models, Resource Discovery, Programming Models and tools, e-Science and Virtual Instrumentation, Biometric Authentication, Computers for People of Special Needs, Human Computer Interaction, Information and Knowledge Engineering, Algorithms, Parallel and Distributed processing, Modeling and Simulation, Services and Applications, Embedded Systems and Applications, Databases, Programming Languages, Signal Processing Theory and Methods, Signal Processing for Communication, Signal Processing Architectures and Implementation, Information Processing, Geographical Information Systems, Object Based Software Engineering, Parallel and Distributed Computing, Real Time Systems Multiprocessing, File Systems and I/O, Kernel and OS Structures. Conference Page: http://www.cisse2005.org/scss.aspx (4) International Conference on Engineering Education, Instructional Technology, Assessment, and E-learning (EIAE 05) Topics: Instructional Design, Accreditation, Curriculum Design, Educational Tools, 2-2-2 Platforms, Teaching Capstone Design, Teaching Design at the Lower Levels, Design and Development of e-Learning tools, Assessment Methods in Engineering, Development and Implementation of E-learning tools, Economical and Social Impacts of E-learning, Platforms and Systems for K-12 / Industry and Higher Education Cooperation. Conference Page: http://www.cisse2005.org/eiae.aspx --------------------------------------------------------------------- PAPER SUBMISSION --------------------------------------------------------------------- Prospective authors are invited to submit full papers electronically in Microsoft Word or PDF format through the website of each conference at http://www.cisse2005.org Accepted papers must be presented in the virtual conference by one of the authors. To submit your paper, visit http://www.cisse2005.org/author/submit.aspx or visit the individual conference pages. --------------------------------------------------------------------- IMPORTANT DATES --------------------------------------------------------------------- Paper submission: September 30, 2005 Notification of Acceptance: October 28, 2005 Final Manuscript and Registration: November 18, 2005 -------------- next part -------------- A non-text attachment was scrubbed... Name: cfpcisse05.pdf Type: application/octet-stream Size: 152088 bytes Desc: not available Url : http://www.haskell.org//pipermail/haskell/attachments/20050915/7ef57d8e/cfpcisse05-0001.obj From bulatz at HotPOP.com Fri Sep 16 09:08:18 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Fri Sep 16 10:54:14 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050916120249.GA6250@shark.localdomain> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> <20050916120249.GA6250@shark.localdomain> Message-ID: <10988790784.20050916170818@HotPOP.com> Hello Sergey, Friday, September 16, 2005, 4:02:49 PM, you wrote: >> z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } SZ> I might be misunderstanding, but aren't we going to introduce evaluation SZ> order for `+' in this case? of course. really, in many situations evaluation order is just not matter, including all IORef usage i could imagine btw, if someone interested, explicit operation for dereferencing variables used in ML (afair, it called just "."), and in some old system programming language, may be BLISS of course, automatic dereferncing could be much better, but it rises some potential double-readings just like auto-lifting (f.e., "z:=x" - is z must have type "IORef a" or "IORef (IORef a)", if x have type "IORef a" ? ) -- Best regards, Bulat mailto:bulatz@HotPOP.com From bulatz at HotPOP.com Fri Sep 16 11:12:22 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Fri Sep 16 10:54:48 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <200509161555.52568.wolfgang@jeltsch.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <3517473846.20050915211941@HotPOP.com> <20050916120249.GA6250@shark.localdomain> <200509161555.52568.wolfgang@jeltsch.net> Message-ID: <5396234918.20050916191222@HotPOP.com> Hello Wolfgang, Friday, September 16, 2005, 5:55:52 PM, you wrote: WJ> strong argument against these proposals. One thing I like about Haskell is WJ> that side-effects are strictly separated from evaluation so that there is no WJ> such thing like an implicit evaluation order. like in assembler? ;) -- Best regards, Bulat mailto:bulatz@HotPOP.com From u.stenzel at web.de Fri Sep 16 11:19:49 2005 From: u.stenzel at web.de (Udo Stenzel) Date: Fri Sep 16 11:03:43 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <3517473846.20050915211941@HotPOP.com> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> Message-ID: <20050916151949.GE1579@web.de> Bulat Ziganshin wrote: > i strongly support this suggestion. actually, i suggest the same for > dealing with references (IORef/MVar/...), for example: > > do x <- newIORef 0 > y <- newIORef 0 > z <- newIORef 0 > z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } May I humbly suggest you explain what problem you are actually trying to solve here? I've never felt the need to hide monadic binding behind fancy syntax, defining some combinator was always sufficient. I mean... if you want C, you know where to find it. If possible I'd rather not see the same programming "style" in Haskell. Udo. -- There's too much blood in my caffeine system. -------------- 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/20050916/156f36c9/attachment.bin From glynn at gclements.plus.com Fri Sep 16 12:40:04 2005 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 16 12:21:00 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <200509161624.08812.wolfgang@jeltsch.net> References: <432AADE1.1000103@yahoo.co.uk> <20050916124618.GC5539@abridgegame.org> <17194.51389.90269.546470@cerise.gclements.plus.com> <200509161624.08812.wolfgang@jeltsch.net> Message-ID: <17194.62820.581985.149725@cerise.gclements.plus.com> Wolfgang Jeltsch wrote: > > > > Bearing this in mind, and hoping you can see where I'm coming from, I > > > > think my question is: shouldn't you guys be using Lisp? > > > > > > Lisp is impure, weakly typed and has way too many parentheses. Why would > > > we use lisp? It seems to be lacking almost all the advantages of Haskell, > > > and have an ugly, inflexible syntax to boot. > > > > The ability to dynamically generate, manipulate and analyse code in a > > structured manner provides a flexibility which is unmatched by any > > other language I know of. > > > > A good example is Emacs; lisp is entirely the right language for that, > > IMHO. > > Could you explain this a bit more, please? To the moment, I cannot imagine > cases where you need LISP's way of code analysis and manipulation because > Haskell's capabilities are not sufficient. > > In Haskell, code is data too because code in the sense of imperative actions > is described by IO values. You cannot analyse them. And thus they are not data. > But you can use your do > expressions etc. to construct action descriptions with a more general type > like MonadIO m => m a. Then you can instantiate m with a monad whose values > store part of the action's structure so that this information can be used > later. Or you use a monad which doesn't keep structural information to use > it for later processing but which does the processing upon construction. Yeah, but this is heading in the direction of Greenspun's Tenth Rule of Programming: Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." You could easily end up doing the same thing in Haskell. The main thing about Lisp is that it tends to make it fairly easy to write something close to the ideal language for the task in hand without starting from the ground floor. You get stuck with Lisp's token syntax, and the semantics of its core primitives, but you can replace anything else. Every other language (including Haskell) tends to have the problem that eventually you will encounter a situation where the language's own worldview gets in the way. Or, to put it another way: if Haskell is so flexible, why do we need Template Haskell? I can't imagine a "Template Lisp"; it would just be Lisp. -- Glynn Clements From bulatz at HotPOP.com Fri Sep 16 14:40:17 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Fri Sep 16 14:25:38 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050916151949.GE1579@web.de> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <3517473846.20050915211941@HotPOP.com> <20050916151949.GE1579@web.de> Message-ID: <626473017.20050916224017@HotPOP.com> Hello Udo, Friday, September 16, 2005, 7:19:49 PM, you wrote: >> do x <- newIORef 0 >> y <- newIORef 0 >> z <- newIORef 0 >> z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y; writeIORef z (x'+y') } US> May I humbly suggest you explain what problem you are actually trying to US> solve here? I've never felt the need to hide monadic binding behind US> fancy syntax, defining some combinator was always sufficient. I mean... US> if you want C, you know where to find it. If possible I'd rather not US> see the same programming "style" in Haskell. you absolutely true - i need sometimes C and don't think to use it just to write several lines, such as when i need to compute CRC of data stream -- Best regards, Bulat mailto:bulatz@HotPOP.com From alex at alexjacobson.com Fri Sep 16 15:41:56 2005 From: alex at alexjacobson.com (S. Alexander Jacobson) Date: Fri Sep 16 15:22:34 2005 Subject: [Haskell] implicit responses/values Message-ID: I am now using implicit parameters quite happily. But I also feel the need for the reverse. There are occasions where I want to pass a value back through the set of calling functions e.g. produce HTTP cache header info through functions that are not really about that. I am not sure how this would work, but it strikes me as useful. Anything like that in the offing? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com From tomasz.zielonka at gmail.com Fri Sep 16 17:33:46 2005 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Fri Sep 16 17:14:33 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <17194.62820.581985.149725@cerise.gclements.plus.com> References: <432AADE1.1000103@yahoo.co.uk> <20050916124618.GC5539@abridgegame.org> <17194.51389.90269.546470@cerise.gclements.plus.com> <200509161624.08812.wolfgang@jeltsch.net> <17194.62820.581985.149725@cerise.gclements.plus.com> Message-ID: <20050916213346.GB2206@students.mimuw.edu.pl> On Fri, Sep 16, 2005 at 05:40:04PM +0100, Glynn Clements wrote: > > Every other language (including Haskell) tends to have the problem > that eventually you will encounter a situation where the language's > own worldview gets in the way. Are you sure that lisp's worldview never gets in the way? > Or, to put it another way: if Haskell is so flexible, why do we need > Template Haskell? It's nice to have Template Haskell, but saying that we need it is a bit of an overstatement. In the GHC Survey 2005 only 9% of people said it's essential. Well, OK, I was one of them, but I think you know what I mean. > I can't imagine a "Template Lisp"; it would just be Lisp. The power of lisp macros is often overrated. I remember a long discussion crossposted on comp.lang.lisp an comp.lang.functional. The lisp advocates gave examples for how macros allow to do things supposedly unavailable in other languages. Surprisingly, most of these things were equally easy to do with higher-order functions and closures in Haskell. I am sure that lisp gurus can achieve great things with macros, but I'm not sure they are the best tool for software engineering problems. I think they can make the code more difficult to understand, make the semantics less uniform (despite the uniform syntax), and can become an abused ugly hack. Don't get me wrong - I still think that lisp is one of the best programming languages around and from time to time I am trying to learn a bit of it. One of the things that puts me off is the attitude of its community - it seems to be very close minded. Best regards Tomasz From mvanier at cs.caltech.edu Fri Sep 16 17:37:14 2005 From: mvanier at cs.caltech.edu (Michael Vanier) Date: Fri Sep 16 17:17:59 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <20050916213346.GB2206@students.mimuw.edu.pl> (message from Tomasz Zielonka on Fri, 16 Sep 2005 23:33:46 +0200) References: <432AADE1.1000103@yahoo.co.uk> <20050916124618.GC5539@abridgegame.org> <17194.51389.90269.546470@cerise.gclements.plus.com> <200509161624.08812.wolfgang@jeltsch.net> <17194.62820.581985.149725@cerise.gclements.plus.com> <20050916213346.GB2206@students.mimuw.edu.pl> Message-ID: <20050916213714.D474D103C1C@orchestra.cs.caltech.edu> > Date: Fri, 16 Sep 2005 23:33:46 +0200 > From: Tomasz Zielonka > > On Fri, Sep 16, 2005 at 05:40:04PM +0100, Glynn Clements wrote: > > > > Every other language (including Haskell) tends to have the problem > > that eventually you will encounter a situation where the language's > > own worldview gets in the way. > > Are you sure that lisp's worldview never gets in the way? > > > Or, to put it another way: if Haskell is so flexible, why do we need > > Template Haskell? > > It's nice to have Template Haskell, but saying that we need it is a bit > of an overstatement. In the GHC Survey 2005 only 9% of people said it's > essential. Well, OK, I was one of them, but I think you know what I > mean. > > > I can't imagine a "Template Lisp"; it would just be Lisp. > > The power of lisp macros is often overrated. I remember a long > discussion crossposted on comp.lang.lisp an comp.lang.functional. The > lisp advocates gave examples for how macros allow to do things > supposedly unavailable in other languages. Surprisingly, most of these > things were equally easy to do with higher-order functions and closures > in Haskell. > But were they as efficient? The beauty of macros is that a lot of things can be done with no run-time overhead at all. Not that I'm taking a stand on the Haskell-vs-Lisp argument; I think everyone should learn both languages. Mike From tomasz.zielonka at gmail.com Fri Sep 16 17:47:56 2005 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Fri Sep 16 17:28:42 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <20050916213714.D474D103C1C@orchestra.cs.caltech.edu> References: <432AADE1.1000103@yahoo.co.uk> <20050916124618.GC5539@abridgegame.org> <17194.51389.90269.546470@cerise.gclements.plus.com> <200509161624.08812.wolfgang@jeltsch.net> <17194.62820.581985.149725@cerise.gclements.plus.com> <20050916213346.GB2206@students.mimuw.edu.pl> <20050916213714.D474D103C1C@orchestra.cs.caltech.edu> Message-ID: <20050916214756.GC2206@students.mimuw.edu.pl> On Fri, Sep 16, 2005 at 02:37:14PM -0700, Michael Vanier wrote: > But were they as efficient? If some code is equivalent to macro expansion then the compiler should be able to optimize it to the same extent as a macro. > The beauty of macros is that a lot of things can be done with no > run-time overhead at all. Macros can lead to bigger generated code size, which can affect performance. Best regards Tomasz From glynn at gclements.plus.com Fri Sep 16 18:26:01 2005 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Sep 16 18:07:01 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <20050916213346.GB2206@students.mimuw.edu.pl> References: <432AADE1.1000103@yahoo.co.uk> <20050916124618.GC5539@abridgegame.org> <17194.51389.90269.546470@cerise.gclements.plus.com> <200509161624.08812.wolfgang@jeltsch.net> <17194.62820.581985.149725@cerise.gclements.plus.com> <20050916213346.GB2206@students.mimuw.edu.pl> Message-ID: <17195.18041.244826.540653@cerise.gclements.plus.com> Tomasz Zielonka wrote: > > Every other language (including Haskell) tends to have the problem > > that eventually you will encounter a situation where the language's > > own worldview gets in the way. > > Are you sure that lisp's worldview never gets in the way? I wouldn't say never. But it's main advantage is that it doesn't really have much of a worldview. Its primary composite data type is the heterogeneous linked list, which is isomorphic to both binary trees and n-ary trees. This provides a reasonable fit for most common data structures, and also for most languages (anything defined by a recursive grammar can be represented as a parse tree). The complete absence of keywords is another useful feature (I've lost track of the various C packages which had to have identifiers named "class" renamed to allow for C++). Even "quote" is just another symbol. Ultimately, all languages are limited by their choice of primitives. > > Or, to put it another way: if Haskell is so flexible, why do we need > > Template Haskell? > > It's nice to have Template Haskell, but saying that we need it is a bit > of an overstatement. In the GHC Survey 2005 only 9% of people said it's > essential. Well, OK, I was one of them, but I think you know what I > mean. > > > I can't imagine a "Template Lisp"; it would just be Lisp. > > The power of lisp macros is often overrated. I remember a long > discussion crossposted on comp.lang.lisp an comp.lang.functional. The > lisp advocates gave examples for how macros allow to do things > supposedly unavailable in other languages. Surprisingly, most of these > things were equally easy to do with higher-order functions and closures > in Haskell. > > I am sure that lisp gurus can achieve great things with macros, but I'm > not sure they are the best tool for software engineering problems. > I think they can make the code more difficult to understand, make the > semantics less uniform (despite the uniform syntax), and can become an > abused ugly hack. Well, this is heading towards the inevitable paradox (G?del's theorem, halting problem, etc). If you allow the programmer to escape from your chosen semantic model, you no longer have the luxury of being able to assume those semantics. Ultimately, the issue isn't whether shooting oneself in the foot is a good idea, it's whether you leave it up to the language or to the programmer to prevent it. Both have their pros and cons. In that regard, Lisp and Haskell are almost opposite extremes, with more conventional languages inbetween. Haskell's safety and consistency can get in the way, while Lisp's freedom can be quite unsafe and inconsistent. > Don't get me wrong - I still think that lisp is one of the best > programming languages around and from time to time I am trying to learn > a bit of it. One of the things that puts me off is the attitude of its > community - it seems to be very close minded. Hmm. That depends upon which faction of the community you're dealing with. If you get into discussions about the merits of Lisp on public fora, you'll likely be dealing with the evangelists. Language evangelists are often closed-minded whatever the language. -- Glynn Clements From wnoise at ofb.net Fri Sep 16 19:16:44 2005 From: wnoise at ofb.net (Aaron Denney) Date: Fri Sep 16 18:59:52 2005 Subject: [Haskell] Re: implicit responses/values References: Message-ID: On 2005-09-16, S. Alexander Jacobson wrote: > I am now using implicit parameters quite happily. But I also feel the > need for the reverse. There are occasions where I want to pass a > value back through the set of calling functions e.g. produce HTTP > cache header info through functions that are not really about that. > > I am not sure how this would work, but it strikes me as useful. > Anything like that in the offing? Monads. Implicit parameters can be thought of as co-monad. -- Aaron Denney -><- From cdutchyn at cs.ubc.ca Fri Sep 16 20:21:30 2005 From: cdutchyn at cs.ubc.ca (Christopher Dutchyn) Date: Fri Sep 16 20:02:17 2005 Subject: [Haskell] Haskell versus Lisp In-Reply-To: <17195.18041.244826.540653@cerise.gclements.plus.com> Message-ID: <200509170021.j8H0LZo2011897@mail-relay1.cs.ubc.ca> > From: Glynn Clements [mailto:glynn@gclements.plus.com] > In that regard, Lisp and Haskell are almost opposite > extremes, with more conventional languages inbetween. > Haskell's safety and consistency can get in the way, while > Lisp's freedom can be quite unsafe and inconsistent. I disagree with your safety distinction. Haskell and Scheme are both extremely (and I believe, equally) safe ... (Common lisp does seem to offer lots of type holes). The key difference between Haskell and Scheme is that Haskell supplies more guidance earlier -- you can supply a (simple/limited) proof that your program doesn't go wrong, and have it checked in advance. Scheme offers no way to provide an advance proof, but it still checks at execution time. Chris Dutchyn Software Practices Lab cdutchyn@cs.ubc.ca From bulatz at HotPOP.com Sat Sep 17 03:40:25 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Sat Sep 17 04:25:51 2005 Subject: [Haskell] Haskell versus Lisp In-Reply-To: <200509170021.j8H0LZo2011897@mail-relay1.cs.ubc.ca> References: <200509170021.j8H0LZo2011897@mail-relay1.cs.ubc.ca> Message-ID: <4853280933.20050917114025@HotPOP.com> Hello Christopher, Saturday, September 17, 2005, 4:21:30 AM, you wrote: CD> Scheme offers no way to provide an advance proof, but it still checks at CD> execution time. ALL modern laguages check at least at execution time. but compile-time checking is much better, otherwise you need to check every execution path of program after each modification -- Best regards, Bulat mailto:bulatz@HotPOP.com From Benjamin.Rudiak-Gould at cl.cam.ac.uk Sat Sep 17 07:19:28 2005 From: Benjamin.Rudiak-Gould at cl.cam.ac.uk (Ben Rudiak-Gould) Date: Sat Sep 17 07:00:19 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <200509142010.j8EKAd10006079@ripper.it.kth.se> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <200509142010.j8EKAd10006079@ripper.it.kth.se> Message-ID: <432BFBC0.1040803@cl.cam.ac.uk> Bjorn Lisper wrote: > However, there is a way to resolve the ambiguity that can be claimed to be > the most natural one, and that is to always choose the "least possible" > lifting. In the example above, this would mean to interpret [[1]]++[[2]] > precisely as [[1]]++[[2]] (lift 0 levels) rather than [[1]++[2]] (lift 1 > level). It's not the mathematics I'm worried about, it's the people. Consider the "time flies like an arrow; fruit flies like a banana" example. What's interesting about it is not just the existence of more than one parse, but the fact that it's hard to even notice the other parses exist unless you're looking for them, because people are so good at unconsciously resolving this kind of ambiguity from context. I'm afraid that once people get used to the idea that they can write xs `op` ys and get implicit lifting, they will write xs ++ ys and never notice that it has an unlifted interpretation which will take precedence. This isn't the nastiest class of bug, but it's pretty nasty. -- Ben From Benjamin.Rudiak-Gould at cl.cam.ac.uk Sat Sep 17 13:56:36 2005 From: Benjamin.Rudiak-Gould at cl.cam.ac.uk (Ben Rudiak-Gould) Date: Sat Sep 17 13:37:15 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <20050915204320.GB22894@a5.repetae.net> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <20050915204320.GB22894@a5.repetae.net> Message-ID: <432C58D4.1010608@cl.cam.ac.uk> Frederik Eaton wrote: > I think this is a good idea. I like the inline "<-", or maybe > something like "@". The operator-section notation (<- expr) has the big advantage of being unlikely to collide with any other syntax proposals. > I'm not sure what you intend to do about nested "do" statements, > though. If they correspond to different monads, I might want to have a > 'borrow' in the inner "do" statement create a lifted expression in the > outer "do" statement. In such cases you almost certainly wouldn't want to use this notation anyway. It's confusing enough with a single monad. As an experiment I tried rewriting some monadic code from one of my projects (Reform) using the (<- expr) syntax. It was interesting. Some points: * Most of my uses of <- could be replaced with the inline form. In some cases it seemed like a bad idea, because the intermediate variable name was useful as documentation. In the other cases I'd obviously chosen a meaningless intermediate variable name just to get around the lack of a feature like this one. * I found myself writing "do return" a lot, which isn't a combination you usually see in Haskell code. It felt odd, but perhaps you'd get used to it. * The new syntax is really nice as a replacement for the annoyingly common "x <- foo ; case x of..." idiom that I've always disliked. * The increased similarity to programming in an eager language was startling at times. I'm just not used to thinking eagerly when I write Haskell, even though I do it all the time in other languages. * There are tricky corner cases. For example, x <- getByte if x < 128 then return x else return (x - 128) * 256 + (<- getByte) doesn't do what it's probably intended to do: the second byte will be read even if x < 128. You have to write "else do return" instead of "else return". I'm afraid this would be easy to get wrong. It wouldn't be hard to make the translation assume an implicit do at the branches of if and case statements, but this wouldn't always be what you'd want. Even worse is that short- circuiting && and || don't work as they do in eager languages. So on reflection I'm not sure I think this proposal is a good idea. I probably wouldn't be able to write or read code in this style without doing manual desugaring in my head, which takes away much of the appeal. But it might be worth adding if people can be trusted to use it judiciously. -- Ben From thjaeger at gmail.com Sat Sep 17 19:08:18 2005 From: thjaeger at gmail.com (Thomas =?ISO-8859-1?Q?J=E4ger?=) Date: Sat Sep 17 18:49:04 2005 Subject: [Haskell] Mixing monadic and non-monadic functions In-Reply-To: <432C58D4.1010608@cl.cam.ac.uk> References: <5.1.0.14.2.20040323160135.02e168d8@127.0.0.1> <200403231255.59233.haskell@ser.fdns.net> <20050908044323.GA6037@a5.repetae.net> <4328347B.1040708@cl.cam.ac.uk> <20050915204320.GB22894@a5.repetae.net> <432C58D4.1010608@cl.cam.ac.uk> Message-ID: <1126998499.1169.38.camel@mthomas> Hello, I haven't followed this discussion very closely, but in case you want to play with this sort of thing, you can check out the code from my TMR-Article http://www.haskell.org/tmrwiki/FunWithLinearImplicitParameters Despite the wacky implementation it is actually surprisingly reliable, modulo some (linear) implicit parameter quirks. The [[1,2,3,4]] vs. [[1],[2],[3],[4]] ambiguity is resolved using the same method as the borrow/<- proposal (by a function called `reflect'); and the function `reify' is corresponding to the enclosing do. A notable difference is that my implementation always shows the information whether a specific expression is a `monadic' one in the type. E.g. *Reflection> reify [1,2,3,4] :: [[Int]] [[1,2,3,4]] *Reflection> [reify 1, reify 2,reify 3,reify 4] :: [[Int]] [[1],[2],[3],[4]] *Reflection> reify [reflect [1,2], reflect [3,4]] :: [[Int]] [[1,3],[1,4],[2,3],[2,4]] Here [reflect [1,2], reflect [3,4]] has the type Monadic [] [Int] (where Monadic is a type synonym involving linear implicit parameters...). However, when doing such a thing, one must decide for an evaluation order. Because of the way it is implemented, my code uses Haskell's lazy strategy but that makes reasoning about the resulting programs very hard (though I believe it can be made precise): *Reflection> reify (tail $ [reflect [1,2],3,4]) :: [[Int]] [[3,4]] *Reflection> reify (tail $!! [reflect [1,2],3,4]) :: [[Int]] [[3,4],[3,4]] (here, $!! is deepSeq'ed application) An eager strategy might be less obscure, but suffers from the problems described by Ben. It should also be noted that a Call-By-Name-like strategy can be emulated with appropriate types, as in: *Reflection> reify (let x :: Monadic [] Int; x = reflect [1,2] in [x,x]) [[1,1],[1,2],[2,1],[2,2]] *Reflection> reify (let x :: Int; x = reflect [1,2] in [x,x]) [[1,1],[2,2]] Of course, in case of no explicit type signature, the monomorphism restriction plays an infamous role and the behavior depends on the flag -fno-monomorphism-restriction. Thomas From john at repetae.net Sun Sep 18 20:53:17 2005 From: john at repetae.net (John Meacham) Date: Sun Sep 18 20:34:01 2005 Subject: [Haskell] monadic where Message-ID: <20050919005317.GP4005@momenergy.repetae.net> All the talk of automatic monad lifting has reminded me of an extension I have wanted on several occasions. f x y = z where a = ... b <- ... c <- ... translates too f x y = do let a = .. b <- ... c <- ... z now, this doesn't seem that worth it until you consider guards in which case it becomes _very_ nice compared to the alternative. f x y | b > c = ... | c <= 0 && a > b = ... where a = ... b <- ... c <- ... f x y = ... there is really no clean (IMHO) way to express this idiom otherwise, and the benefits are even greater when you consider pattern guards. Manually you end up with a lot of strange nested cases or spurious subfunctions and generally hard to read and write code. Ideally, it would translate to an 'mdo' rather than a 'do', but not every monad is an instance of MonadFix and although that would be nice to have, it is not really vital since 'mdo', although indispensable sometimes, is not generally needed except in a few special cases so I'd stick to the standard 'do' translation. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Mon Sep 19 03:43:40 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 19 03:24:16 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp Message-ID: <036EAC76E7F5EC4996A3B3C3657D411603350C15@EUR-MSG-21.europe.corp.microsoft.com> This would be a great discussion for the haskell-caf? list, but perhaps it's less appropriate on the low-bandwidth Haskell list. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Michael Vanier | Sent: 16 September 2005 22:37 | To: tomasz.zielonka@gmail.com | Cc: haskell@haskell.org; glynn@gclements.plus.com | Subject: Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp | | | > Date: Fri, 16 Sep 2005 23:33:46 +0200 | > From: Tomasz Zielonka | > | > On Fri, Sep 16, 2005 at 05:40:04PM +0100, Glynn Clements wrote: | > > | > > Every other language (including Haskell) tends to have the problem | > > that eventually you will encounter a situation where the language's | > > own worldview gets in the way. | > | > Are you sure that lisp's worldview never gets in the way? | > | > > Or, to put it another way: if Haskell is so flexible, why do we need | > > Template Haskell? | > | > It's nice to have Template Haskell, but saying that we need it is a bit | > of an overstatement. In the GHC Survey 2005 only 9% of people said it's | > essential. Well, OK, I was one of them, but I think you know what I | > mean. | > | > > I can't imagine a "Template Lisp"; it would just be Lisp. | > | > The power of lisp macros is often overrated. I remember a long | > discussion crossposted on comp.lang.lisp an comp.lang.functional. The | > lisp advocates gave examples for how macros allow to do things | > supposedly unavailable in other languages. Surprisingly, most of these | > things were equally easy to do with higher-order functions and closures | > in Haskell. | > | | But were they as efficient? The beauty of macros is that a lot of things | can be done with no run-time overhead at all. Not that I'm taking a stand | on the Haskell-vs-Lisp argument; I think everyone should learn both | languages. | | Mike | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From simonmar at microsoft.com Mon Sep 19 09:51:47 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Mon Sep 19 09:32:24 2005 Subject: [Haskell] ANNOUNCE: GHC version 6.4.1 Message-ID: <3429668D0E777A499EE74A7952C382D1047CDBCD@EUR-MSG-01.europe.corp.microsoft.com> ============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.4.1 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a significant number of bugfixes relative to 6.4, so we recommend upgrading. No library APIs have changed, so code that was working with 6.4 should continue to work with 6.4.1. Release notes are here: http://haskell.org/ghc/docs/6.4.1/html/users_guide/release-6-4-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in Windows Installer (MSI) form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html Supported Platforms ~~~~~~~~~~~~~~~~~~~ GHC supports the following platforms in this release: * x86 machines running Windows, common flavours of Linux, FreeBSD, OpenBSD, and NetBSD * x86_64 (aka amd64) machines running Linux * Macs running MacOS X * PowerPC machines running AIX or Linux * Sparc machines running Solaris. Ports to other platforms are possible with varying degrees of difficulty. The Building Guide gives a complete run-down of what ports work and how to go about porting to a new platform: http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs@haskell.org. GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding edge CVS users party on cvs-ghc@haskell.org. From gale at sefer.org Tue Sep 20 03:29:14 2005 From: gale at sefer.org (Yitzchak Gale) Date: Tue Sep 20 03:09:43 2005 Subject: [Haskell] monadic where In-Reply-To: <20050919005317.GP4005@momenergy.repetae.net> References: <20050919005317.GP4005@momenergy.repetae.net> Message-ID: <20050920072914.GA3179@sefer.org> John Meacham wrote: > f x y > | b > c = ... > | c <= 0 && a > b = ... > where > a = ... > b <- ... > c <- ... > f x y = ... > > there is really no clean (IMHO) way to express this idiom otherwise, What does this translate to (even if not clean)? I am not sure I understand what this is supposed to do. It looks like the guards depend on things computed inside the monad, so I guess you want the guard code put at the end of the monadic code. But then, by the time you get to the guards, you may have already created side effects in the monad. So running the second version of f after failing the first version is not equivalent to running the second version by itself. Or am I missing something? Thanks, Yitz From benjamin.franksen at bessy.de Tue Sep 20 06:25:00 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Tue Sep 20 06:05:32 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <17194.62820.581985.149725@cerise.gclements.plus.com> References: <432AADE1.1000103@yahoo.co.uk> <200509161624.08812.wolfgang@jeltsch.net> <17194.62820.581985.149725@cerise.gclements.plus.com> Message-ID: <200509201225.01012.benjamin.franksen@bessy.de> On Friday 16 September 2005 18:40, Glynn Clements wrote: > Wolfgang Jeltsch wrote: > > In Haskell, code is data too because code in the sense of > > imperative actions is described by IO values. You cannot analyse > > them. > > And thus they are not data. Huh? I'd say they are not /concrete/ data, but (abstract) data they surely are(?) Ben From simonmar at microsoft.com Tue Sep 20 08:29:19 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Sep 20 08:09:52 2005 Subject: [Haskell] ANNOUNCE: Visual Haskell version 0.0 Message-ID: <3429668D0E777A499EE74A7952C382D1048127E7@EUR-MSG-01.europe.corp.microsoft.com> The Visual Haskell team are proud to announce the first preview release of Visual Haskell, version 0.0. Visual Haskell is a complete development environment for Haskell software, based on Microsoft's Visual Studio platform. Visual Haskell integrates with the Visual Studio editor to provide interactive features to aid Haskell development, and it enables the construction of projects consisting of multiple Haskell modules, using the Cabal building/packaging infrastructure. Visual Haskell is a complete system in one download: it includes a full GHC installation with libraries, and various tools including Haddock, Happy, and Alex. In order to use Visual Haskell, you need an x86 machine running Windows, and Visual Studio .NET 2003. Downloads, screenshots and documentation here: http://www.haskell.org/visualhaskell/ Please note that this is a preview release - please download and try it out, but don't expect a production quality experience. We'll be grateful for any feedback you have. A quick note about the license: this is a binary release with a BSD license. We changed the license at the last minute, and didn't have time to re-roll the installer. You have the option of using Visual Haskell either under the click-through license in the installer (a Microsoft shared source license for non-commercial use) or the more liberal BSD license in the documentation. Enjoy! Simon Marlow Krasimir Angelov (with thanks to the others who have contributed to Visual Haskell in the past and to the huge amount of external software on which it relies). From jgoerzen at complete.org Tue Sep 20 09:27:10 2005 From: jgoerzen at complete.org (John Goerzen) Date: Tue Sep 20 09:08:04 2005 Subject: [Haskell] Haskell Weekly News: September 20, 2005 Message-ID: <20050920132710.GA15851@katherina.lan.complete.org> Haskell Weekly News: September 20, 2005 Greetings, and thanks for reading the eighth issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * GHC 6.4.1. According to Simon Marlow's [3]announcement, GHC 6.4.1 is out and is mainly a bugfix release. No library APIs have changed, so code working with GHC 6.4 should continue to work. 3. http://article.gmane.org/gmane.comp.lang.haskell.general/12158 * Visual Haskell 0.0. Simon Marlow [4]announced Visual Haskell 0.0, a Haskell development environment for the Microsoft Visual Studio platform. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12161 Discussion Autrijus Tang interviewed at perl.com. Autrijus Tang is a Perl hacker and developer of the first working Perl 6 [5]interpreter, which is written in Haskell. On Page 2 of an [6]interview on perl.com, he explained Haskell in glowing terms to the Perl audience. Favorite quote: "Haskell . . . is faster than C++, more concise than Perl, more regular than Python, more flexible than Ruby, more typeful than C#, more robust than Java, and has absolutely nothing in common with PHP." Thanks to metaperl for [7]mentioning this on the Haskell Sequence. There was als a small [8]thread about this. 5. http://www.pugscode.com/ 6. http://www.perl.com/pub/a/2005/09/08/autrijus-tang.html?page=2 7. http://sequence.complete.org/node/98 8. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8288 Overloading (==). In an interesting [9]thread, Tom Hawkins asked if it was possible to overload (==) to return something other than a Bool. The answer was no, but the discussion led to comments about using typeclasses instead of a simple Bool type in certain situations. 9. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8346 Haskell vs. Lisp. This [10]discussion began with a post from Mark Carter, who is considering Haskell and wondering what advantages it might have over Lisp. Many perspectives were discussed, especially relating to metaprogramming (Lisp macros and Template Haskell). David F. Place had an interesting [11]post. As someone with experience with both Haskell and Lisp, he commented that Haskell's "lazy evaluation eliminates 99% of the need for macros in Lisp." There were also posts by [12]Tomasz Zielonka, [13]Cale Gibbard were also insightful. 10. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8309 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8342 12. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8356 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8316 Network Parsing and Parsec. John Goerzen posed a [14]question about using Parsec to parse network streams such as IMAP, where the results of the parsing itself determine how much data should be read, and reading too much data results in deadlock. Some solutions offered included a separate tokenizer phase and the use of the Parsec state to help. 14. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8293 Haskell Toolchain The Big News this week is, of course, the new release of GHC. A big thanks to everyone on the GHC team for this. Cabal du jour. Cabal keeps coming up on the libraries list. This week's [15]discussion revolves around whether or not a --package-db option is wise. 15. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3729 Quotes of the Week "Learning Haskell requires some brain rewiring, so the best way to learn it is by coding something in it for real. Yuval, a fellow "lambdacamel," learned Haskell from scratch by coding up a Forth parser, interpreter, and runtime all within a few days." -- Autrijus Tang Corrections Two typos in last week's HWN. In the web applications story, "S. Alexander Jacobsen" should have been "S. Alexander Jacobson". In the binary pasrser combinators story, "Malcolm Wallac" should have been "Malcolm Wallace". Sorry about that. About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [16]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 16. http://sequence.complete.org/hwn-contrib From john at repetae.net Tue Sep 20 14:55:33 2005 From: john at repetae.net (John Meacham) Date: Tue Sep 20 14:36:15 2005 Subject: [Haskell] monadic where In-Reply-To: <20050920072914.GA3179@sefer.org> References: <20050919005317.GP4005@momenergy.repetae.net> <20050920072914.GA3179@sefer.org> Message-ID: <20050920185533.GS13885@momenergy.repetae.net> On Tue, Sep 20, 2005 at 10:29:14AM +0300, Yitzchak Gale wrote: > John Meacham wrote: > > f x y > > | b > c = ... > > | c <= 0 && a > b = ... > > where > > a = ... > > b <- ... > > c <- ... > > f x y = ... > > > > there is really no clean (IMHO) way to express this idiom otherwise, > > What does this translate to (even if not clean)? > I am not sure I understand what this is supposed > to do. f x y = do let a = ... b <- ... c <- ... case b > c of True -> ... False -> case c <= 0 && a > b of True -> ... False -> (next fn) > > It looks like the guards depend on things computed > inside the monad, so I guess you want the guard > code put at the end of the monadic code. yeah. exactly. > > But then, by the time you get to the guards, you may > have already created side effects in the monad. So > running the second version of f after failing the > first version is not equivalent to running the second > version by itself. Or am I missing something? this is true. all the actions in a where clause will be executed before pattern matching starts. to limit confusion, we could enforce only a single choice, with pattern guards it is not even that onerous. but I don't know if that is necessary. John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Sep 20 15:27:49 2005 From: john at repetae.net (John Meacham) Date: Tue Sep 20 15:08:38 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <200509201225.01012.benjamin.franksen@bessy.de> References: <432AADE1.1000103@yahoo.co.uk> <200509161624.08812.wolfgang@jeltsch.net> <17194.62820.581985.149725@cerise.gclements.plus.com> <200509201225.01012.benjamin.franksen@bessy.de> Message-ID: <20050920192749.GW13885@momenergy.repetae.net> On Tue, Sep 20, 2005 at 12:25:00PM +0200, Benjamin Franksen wrote: > On Friday 16 September 2005 18:40, Glynn Clements wrote: > > Wolfgang Jeltsch wrote: > > > In Haskell, code is data too because code in the sense of > > > imperative actions is described by IO values. You cannot analyse > > > them. > > > > And thus they are not data. > > Huh? I'd say they are not /concrete/ data, but (abstract) data they > surely are(?) and you are certainly free to turn them into concrete data by creating your own data type which you then can inspect and modify and then "interpret". John -- John Meacham - ?repetae.net?john? From glynn at gclements.plus.com Tue Sep 20 15:43:00 2005 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Sep 20 15:23:30 2005 Subject: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp In-Reply-To: <20050920192749.GW13885@momenergy.repetae.net> References: <432AADE1.1000103@yahoo.co.uk> <200509161624.08812.wolfgang@jeltsch.net> <17194.62820.581985.149725@cerise.gclements.plus.com> <200509201225.01012.benjamin.franksen@bessy.de> <20050920192749.GW13885@momenergy.repetae.net> Message-ID: <17200.26180.435653.148146@cerise.gclements.plus.com> John Meacham wrote: > > > > In Haskell, code is data too because code in the sense of > > > > imperative actions is described by IO values. You cannot analyse > > > > them. > > > > > > And thus they are not data. > > > > Huh? I'd say they are not /concrete/ data, but (abstract) data they > > surely are(?) > > and you are certainly free to turn them into concrete data by creating > your own data type which you then can inspect and modify and then > "interpret". IOW, you are free to write a Lisp interpreter in Haskell. But it's a lot easier to do it in Lisp. That, in a nutshell, is Lisp's key strength. It uses the same structure for code as for data, which makes it very easy to add new language features. -- Glynn Clements From lemmih at gmail.com Tue Sep 20 17:43:27 2005 From: lemmih at gmail.com (Lemmih) Date: Tue Sep 20 17:23:56 2005 Subject: [Haskell] ANNOUNCE: ghc-api 0.1.0 Message-ID: I'm pleased to announce ghc-api 0.1.0, a cabalization of the ghc api, plucked from ghc 6.5, making the api available for stable versions of ghc. The ghc-api 0.1.0 has been developed as a part of the running hIDE project, and has so far been succesfully built with ghc 6.4 and 6.4.1. [1] ghc-api: http://scannedinavian.org/~lemmih/ghc-api [2] hIDE: http://haskell.org/hawiki/hIDE -- Friendly, Lemmih From waldmann at imn.htwk-leipzig.de Wed Sep 21 05:22:10 2005 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed Sep 21 05:02:38 2005 Subject: [Haskell] cabal/haddock Message-ID: <43312642.6040508@imn.htwk-leipzig.de> What's the current story on cabal and haddock? I need to run my sources through ghc -cpp before giving them to haddock. Does cabal support this (e. g. by directing the ghc -cpp output to dist/src )? Thanks, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- From nedunuri at cs.utexas.edu Wed Sep 21 12:43:14 2005 From: nedunuri at cs.utexas.edu (Srinivas Nedunuri) Date: Wed Sep 21 12:35:59 2005 Subject: [Haskell] reflection/metadata in Haskell? Message-ID: I'm sure this question has been asked before, (but unf. the Haskell archives aren't searchable without downloading each month seperately), so I hope nobody minds me asking again. Is there any way to get metadata or reflection capabilities in Haskell? cheers From mads_lindstroem at yahoo.dk Wed Sep 21 14:39:34 2005 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Wed Sep 21 14:17:41 2005 Subject: [Haskell] reflection/metadata in Haskell? In-Reply-To: References: Message-ID: <1127327974.4307.9.camel@localhost.localdomain> Hi Srinivas Nedunuri > I'm sure this question has been asked before, (but unf. the Haskell archives > aren't searchable without downloading each month seperately), so I hope You can search here: http://www.mail-archive.com/haskell@haskell.org/ > nobody minds me asking again. Is there any way to get metadata or reflection > capabilities in Haskell? I do not know of any Java-like reflection capabilities in Haskell. However, "Scrap Your Boilerplate" (search google) and Generic Haskell can do a lot of the same stuff reflection can do in Java. Think of it as compile-time reflection. /Mads > > cheers > > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From slucas at dsic.upv.es Wed Sep 21 15:15:33 2005 From: slucas at dsic.upv.es (slucas@dsic.upv.es) Date: Wed Sep 21 14:56:11 2005 Subject: [Haskell] reflection/metadata in Haskell? In-Reply-To: References: Message-ID: <1127330133.4331b155c9df0@webmail.dsic.upv.es> Dear Srinivas Nedunuri, Mensaje citado por Srinivas Nedunuri : > I'm sure this question has been asked before, (but unf. the Haskell archives > aren't searchable without downloading each month seperately), so I hope > nobody minds me asking again. Is there any way to get metadata or reflection > capabilities in Haskell? Being a (somehow) related language, I would like to point out that Maude has full reflection capabilities, see http://maude.cs.uiuc.edu/ Best regards, Salvador. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From tarmo at cs.ioc.ee Wed Sep 21 16:29:21 2005 From: tarmo at cs.ioc.ee (Tarmo Uustalu) Date: Wed Sep 21 16:00:21 2005 Subject: [Haskell] Paper: The essence of dataflow programming Message-ID: <20050921201954.A45A141FBD@suhkur.cc.ioc.ee> Dear Haskell subscribers, We would like to announce our new paper The essence of dataflow programming http://cs.ioc.ee/~tarmo/papers/essence.pdf which describes a novel comonadic foundation of dataflow computing, incl. semantics of dataflow languages a la Lucid or Lustre. The central point is that comonads structure the context-dependence in dataflow paradigms in much the same way as monads organize effects. The paper was specifically written for functional programmers (as opposed to semanticists). The paper will not be presented at TFP/ICFP/GPCE in Tallinn. A trimmed-down version will appear in Proc. of APLAS 2005. The full text has been submitted. Best wishes, Tarmo Uustalu, Varmo Vene From ralfla at microsoft.com Wed Sep 21 19:52:20 2005 From: ralfla at microsoft.com (Ralf Lammel) Date: Wed Sep 21 19:32:46 2005 Subject: [Haskell] reflection/metadata in Haskell? Message-ID: <1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.microsoft.com> I would rather argue that: - Template Haskell approx. *compile-time* reflection - Scrap your boilerplate II (ICFP 2004) approx. *run-time* reflection - Generic Haskell is effectively a Haskell generator Ralf P.S.: Another way to get *compile-time* reflection in Haskell is of course type-level programming as pioneered by McBride and Hallgreen ... > -----Original Message----- > From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Mads Lindstr?m > Sent: Wednesday, September 21, 2005 11:40 AM > To: haskell@haskell.org > Subject: Re: [Haskell] reflection/metadata in Haskell? > ... > I do not know of any Java-like reflection capabilities in Haskell. > However, "Scrap Your Boilerplate" (search google) and Generic Haskell > can do a lot of the same stuff reflection can do in Java. Think of it as > compile-time reflection. From stefan at cs.uu.nl Thu Sep 22 03:52:00 2005 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Sep 22 03:32:24 2005 Subject: [Haskell] reflection/metadata in Haskell? In-Reply-To: <1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.microsoft.com> References: <1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.microsoft.com> Message-ID: <77C06026-0452-4FDE-859D-D025B0B626E7@cs.uu.nl> Ralf, On Sep 22, 2005, at 1:52 AM, Ralf Lammel wrote: > I would rather argue that: > - Template Haskell approx. *compile-time* reflection > - Scrap your boilerplate II (ICFP 2004) approx. *run-time* reflection > - Generic Haskell is effectively a Haskell generator I think, Generic Haskell is a Haskell generator in the sense that it's currently implemented like that, i.e., as a preprocessing compiler. I assume that's what you mean by 'effectively'. Conceptually, it's a Haskell extension: indeed, one that gives you a certain form of reflection capabilities. Regards, Stefan From simonmar at microsoft.com Thu Sep 22 04:56:17 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Thu Sep 22 04:36:43 2005 Subject: [Haskell] cabal/haddock Message-ID: <3429668D0E777A499EE74A7952C382D10484F0DE@EUR-MSG-01.europe.corp.microsoft.com> On 21 September 2005 10:22, Johannes Waldmann wrote: > What's the current story on cabal and haddock? > I need to run my sources through ghc -cpp > before giving them to haddock. Does cabal support this > (e. g. by directing the ghc -cpp output to dist/src )? Yes, it does. "runhaskell Setup.lhs haddock" will preprocess the Haskell code before running Haddock over it, which is quite convenient since Haddock doesn't know how to do any preprocessing itself. Cheers, Simon From tomasz.zielonka at gmail.com Thu Sep 22 08:06:01 2005 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Thu Sep 22 07:46:26 2005 Subject: [Haskell] Re: ANNOUNCE: GHC version 6.4.1 In-Reply-To: <3429668D0E777A499EE74A7952C382D1047CDBCD@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D1047CDBCD@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <2bb2bdb4050922050670efbc60@mail.gmail.com> On 9/19/05, Simon Marlow wrote: > > > The GHC Team is pleased to announce a new patchlevel release of GHC. > This release contains a significant number of bugfixes relative to > 6.4, so we recommend upgrading. No library APIs have changed, so code > that was working with 6.4 should continue to work with 6.4.1. Good job! The program I was working on today runs 24% faster with 6.4.1compared to 6.4 :-) Best regards Tomasz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/haskell/attachments/20050922/3ae42582/attachment.htm From nedunuri at cs.utexas.edu Thu Sep 22 11:23:22 2005 From: nedunuri at cs.utexas.edu (Srinivas Nedunuri) Date: Thu Sep 22 12:11:24 2005 Subject: [Haskell] Re: reflection/metadata in Haskell? References: <1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.microsoft.com> Message-ID: hello Ralf, thanks for your reply. I took a look at the Scrap Your Biolerplate paper and plan to try it out. Meanwhile there's one little piece in that paper I didn't quite follow, and thats the definition of mkT mkT :: (Typeable a, Typeable b) => (b -> b) -> a -> a mkT f = case cast f of Just g -> g Nothing -> id From the definition of cast and the examples given earlier it looks like cast needs to be told what the target type (a here) is in order to know what its trying to cast to - hence the example was "(cast 'a')::Maybe Char" - which makes sense. So I dont quite understand the usage of cast presented here inside mkT. How does the case proceed without knowing what its trying to cast f to? thanks "Ralf Lammel" wrote in message news:1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.micros oft.com... I would rather argue that: - Template Haskell approx. *compile-time* reflection - Scrap your boilerplate II (ICFP 2004) approx. *run-time* reflection - Generic Haskell is effectively a Haskell generator Ralf P.S.: Another way to get *compile-time* reflection in Haskell is of course type-level programming as pioneered by McBride and Hallgreen ... > -----Original Message----- > From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Mads Lindstrøm > Sent: Wednesday, September 21, 2005 11:40 AM > To: haskell@haskell.org > Subject: Re: [Haskell] reflection/metadata in Haskell? > ... > I do not know of any Java-like reflection capabilities in Haskell. > However, "Scrap Your Boilerplate" (search google) and Generic Haskell > can do a lot of the same stuff reflection can do in Java. Think of it as > compile-time reflection. From mads_lindstroem at yahoo.dk Thu Sep 22 14:00:48 2005 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Thu Sep 22 13:38:51 2005 Subject: [Haskell] reflection/metadata in Haskell? In-Reply-To: <1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.microsoft.com> References: <1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.microsoft.com> Message-ID: <1127412048.4316.14.camel@localhost.localdomain> Hi > I would rather argue that: > - Template Haskell approx. *compile-time* reflection > - Scrap your boilerplate II (ICFP 2004) approx. *run-time* reflection After given the Scrap Your Boilerplate (SYB) issue further thought, I am afraid I must say that you are right. What I should have said was that SYB, opposed to Java-type reflection, has compile-time type checking. Well, most of its constructs are checked at compile-time. /Mads Lindstr?m > - Generic Haskell is effectively a Haskell generator > Ralf > P.S.: Another way to get *compile-time* reflection in Haskell is of course type-level programming as pioneered by McBride and Hallgreen ... > > > -----Original Message----- > > From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On > > Behalf Of Mads Lindstr?m > > Sent: Wednesday, September 21, 2005 11:40 AM > > To: haskell@haskell.org > > Subject: Re: [Haskell] reflection/metadata in Haskell? > > ... > > I do not know of any Java-like reflection capabilities in Haskell. > > However, "Scrap Your Boilerplate" (search google) and Generic Haskell > > can do a lot of the same stuff reflection can do in Java. Think of it as > > compile-time reflection. > > From petersen at haskell.org Thu Sep 22 22:23:01 2005 From: petersen at haskell.org (Jens Petersen) Date: Thu Sep 22 22:03:30 2005 Subject: [Haskell] Annouce: ghc-6.4.1 now in Fedora Extras In-Reply-To: <3429668D0E777A499EE74A7952C382D1047CDBCD@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D1047CDBCD@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <43336705.4000907@haskell.org> I am very happy to announce that ghc-6.4.1 packages have been released already in Fedora Extras[1]. (There are builds for FC4 ppc/i386/x86_64 and for FC3 i386/x86_64 as usual.) 6.4.1 feels like quite a milestone specially for us Linux amd64/x86-64 users. :-) Thank you for the release! Jens [1] http://fedoraproject.org/wiki/Extras/UsingExtras From stefan at cs.uu.nl Fri Sep 23 03:55:00 2005 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Fri Sep 23 03:35:22 2005 Subject: [Haskell] Re: reflection/metadata in Haskell? In-Reply-To: References: <1152E22EE8996742A7E36BBBA7768FEE07203433@RED-MSG-50.redmond.corp.microsoft.com> Message-ID: <8D257B53-64E9-405F-9755-B79580B75F66@cs.uu.nl> Srinivas, > mkT :: (Typeable a, Typeable b) => (b -> b) -> a -> a > mkT f = case cast f of > Just g -> g > Nothing -> id > > From the definition of cast and the examples given earlier it looks > like cast needs to be told what the target type (a here) is in > order to > know what its trying to cast to - hence the example was "(cast > 'a')::Maybe Char" - which makes sense. So I dont quite understand the > usage of cast presented here inside mkT. How does the case proceed > without knowing what its trying to cast f to? Well, it can proceed because all type information it really needs is available. Just consider: The explicit signature reveals that mkT has type (b -> b) -> a -> a (for any a and b that are instances of Typeable). Using this information we derive that f in mkT f = ... is a function of type b -> b, right? Then the right-hand side: that one should give us a function of type a -> a. Just skip the first part of the case statement for a while and proceed to its body: mkT f = case ... of Just g -> g ... Since, g has to have type a -> a and Just has type t -> Maybe t for all t, it follows that Just g has type Maybe (a -> a). Therefore the case statement should perform pattern matching on a value of type Maybe (a -> a). So, from mkT f = case cast f of Just g -> g ... it can be inferred that cast f has type Maybe (a -> a) and, hence, that cast should try to case f to a function of type a -> a. HTH, Stefan From yunwen at l3d.cs.colorado.edu Thu Sep 22 19:14:07 2005 From: yunwen at l3d.cs.colorado.edu (Yunwen Ye) Date: Fri Sep 23 07:41:24 2005 Subject: [Haskell] Call for Participation (correction): International Conference on Automated Software Engineering 2005 Message-ID: <20050922231407.2B7B790B675@l3d.cs.colorado.edu> In the previous CfP(ASE05) I sent, I mixed the titles of keynotes by Dr. Swartout and Dr. Kemmerer. My deep apology to Dr. Swartout and Dr. Kemmerer, as well as to all of you who have to receive and (hopefully not) to delete this email twice. The correct CfP is as follows. --Yunwen Ye, publicity chair of ASE05 ----------------------------------------------------------- Call for Participation 20th IEEE/ACM International Conference on AUTOMATED SOFTWARE ENGINEERING (ASE 2005) November 7-11, 2005 Long Beach, California, USA http://www.ase-conference.org/ ========================================================== Early Registration Deadline: October 7, 2005 Regsitration website: http://www.isr.uci.edu/ase2005/ConferenceRegistration.html ========================================================== The IEEE/ACM International Conference on Automated Software Engineering brings together researchers and practitioners to share ideas on the foundations, techniques, tools, and applications of automated software engineering technology. ASE 2005 features three keynotes, a technical program, four half-day tutorials, four workshops, and a doctoral sympoisum. -------- Keynotes -------- The Power of Software Alfonso Fuggetta CEFRIEL - Politecnico di Milano Virtual Humans: Lessons Learned in Integrating a Large-Scale AI Project William Swartout Institute for Creative Technologies, Univ. of Southern California Designing and Implementing a Family of Intrusion Detection Systems Richard A. Kemmerer University of California, Santa Barbara ----------------- Technical Program ----------------- The technical program includes 28 long papers, 34 short papers, and 4 tool demonstrations on topics such as Validation and Verification, Maintenance and Evolution, Program Understanding, Testing, Code Generation, Configuration Management & Security, Aspect-Oriented Programming, and Software Visualization. --------- Tutorials --------- All four tutorilas are half-day. Bogor: An Extensible Software Model Checking Framework for Domain-Specific Model Checking Robby, Kansas State University, USA Matthew B. Dwyer, University of Nebraska-Lincoln, USA Matthew Hoosier, Kansas State University, USA Learning from Executions: Dynamic Analysis for Program Understanding and Software Engineering Michael Ernst, MIT, USA New Computational Methods for Complex System Construction Christopher Landauer, The Aerospace Corporation, USA Kirstie L. Bellman, The Aerospace Corporation, USA Software Component Models Kung-Kiu Lau, The University of Manchester, UK --------- Workshops --------- Workshop on Specification and Automated Processing of Security Requirements (SAPS '05) http://www.lcc.uma.es/SAPS/ Workshop on Software Security Assurance Tools, Techniques, and Metrics (SSATTM) http://samate.nist.gov/index.php/SSATTM 3rd International Workshop on Traceability in Emerging Forms of Software Engineering (TEFSE 05) http://re.cs.depaul.edu/TEFSE05/ Workshop on Software Certificate Management (SoftCeMent '05) http://ti.arc.nasa.gov/sc05/ ------------------ Doctoral Symposium ------------------ The symposium is closed to public. Only invited students and sympoisum committee will attend. ----------------------- Conference Organization ----------------------- General Chair David Redmiles, University of California, Irvine, USA Program Co-Chairs Tom Ellman, Vassar College, USA Andrea Zisman, City University London, UK Sponsored by IEEE CS, ACM SIGSOFT, ACM SIGART Supported by Institute for Software Research, University of California, Irvine, USA School of Informatics, City University London, UK Donald Bren School of ICS, University of California, Irvine, USA From wolfgang.thaller at gmx.net Fri Sep 23 15:52:33 2005 From: wolfgang.thaller at gmx.net (Wolfgang Thaller) Date: Fri Sep 23 15:32:53 2005 Subject: [Haskell] ANNOUNCE: GHC 6.4.1 binary package for Mac OS X Message-ID: My GHC 6.4.1 packages for Mac OS X are finally ready. Mac OS X 10.3.9 (Panther) and 10.4.x (Tiger) ==== http://www.uni-graz.at/imawww/haskell/GHC-6.4.1.pkg.zip This is an installer package that will install a full version of GHC with GHCi, profiling, dynamic linking, double-clickable icons and HTML documentation on Mac OS X 10.3.9 or later. Darwin/PPC 8.x and Mac OS X 10.4 (Tiger) ==== http://www.uni-graz.at/imawww/haskell/ghc-6.4.1dyn-powerpc-apple- darwin.tar.bz2 This is a standard unix-style binary package with GHCi, profiling, dynamic linking and HTML docs. It requires Mac OS X 10.4 (Tiger) and libreadline.5.0.dylib. The readline library is expected to be installed in /usr/local/lib, but you can change those expectations using the following command: install_name_tool -change /usr/local/lib/libreadline.5.0.dylib /some/ new/path/libreadline.5.0.dylib ghc-6.4.1/lib/powerpc-apple-darwin/ ghc-6.4.1 Enjoy, Wolfgang From ashley at semantic.org Sat Sep 24 04:12:18 2005 From: ashley at semantic.org (Ashley Yakeley) Date: Sat Sep 24 03:53:43 2005 Subject: [Haskell] Object-Orientation and Haskell Message-ID: Here's a simple test for object orientation (for some reasonable definition): Define a type A such that for any type B you can define up :: B -> A down :: A -> Maybe B such that down . up = Just You can do this quite easily in Java or C++, mutatis mutandis. You can't do this in Haskell, I don't think. You can't actually do this in O'Haskell either, it seems the O' essentially amounts to syntactic sugar. You can do a weaker form of this with Haskell's Dynamic, where you only have to deal with Bs that are instances of Typeable. But even with that, note that Dynamic/Typeable/TypeRep are a bit messy, with instances for Typeable defined for a wide range of known types. An alternative approach would be to identify your "B" within "A" not per-B but per-(up,down). This would allow for instance separate (up,down) for the same B such that down1 . up2 = Nothing down2 . up1 = Nothing Of course this can be done with Dynamic too, by defining dummy types. But it's ugly. A better extension is something like extensible data-types. This allows a type to be defined as "open", which can later be extended by disjoint union. Here's a sample syntax that achieves my OO test: module P where data A = .. module Q where import P A |= MkB B up = MkB down (MkB b) = Just b down _ = Nothing Actually, it is possible to define Dynamic in this way. Here's a naive attempt: data Dynamic = .. class Typeable' a where toDyn :: a -> Dynamic fromDynamic :: Dynamic -> Maybe a -- for each type... Dynamic |= MkBool Bool instance Typeable' Bool where toDyn = MkBool fromDynamic (MkBool b) = Just b fromDynamic _ = Nothing This attempt however doesn't allow easy creation of Typeable1, Typeable2 etc. A better way is to use type-constructor parameters: data Dynamic0 (f :: * -> *) = .. data Dynamic1 (g :: (* -> *) -> *) = .. type Dynamic = Dynamic0 Identity data Type a = MkType type TypeRep = Dynamic0 Type class Typeable0 a where toDyn0 :: f a -> Dynamic0 f fromDynamic0 :: Dynamic0 f -> Maybe (f a) class Typeable1 p where toDyn1 :: g p -> Dynamic1 g fromDynamic1 :: Dynamic1 g -> Maybe (g p) data Compose p q a = MkCompose (p (q a)) data Compose1 d0 f p = MkCompose1 (d0 (Compose f p)) Dynamic0 f |= MkDynamic1 (Dynamic1 (Compose1 Dynamic0 f)) unDynamic1 :: Dynamic0 f -> Maybe (Dynamic1 (Compose1 Dynamic0 f)) unDynamic1 (MkDynamic1 xx) = Just xx unDynamic1 _ = Nothing instance (Typeable1 p,Typeable0 a) => Typeable0 (p a) -- toDyn0 :: f (p a) -> Dynamic0 f toDyn0 = MkDynamic1 . toDyn1 . MkCompose1 . toDyn0 . MkCompose -- fromDynamic0 :: Dynamic0 f -> Maybe (f (p a)) fromDynamic0 dyn = do dcdf <- unDynamic1 dyn (MkCompose1 dcfp) <- fromDynamic1 dcdf (MkCompose fpa) <- fromDynamic0 dcfp return fpa -- for each type Dynamic0 f |= MkInt (f Int) instance Typeable0 Int where toDyn0 = MkInt fromDynamic0 (MkInt fi) = Just fi fromDynamic0 _ = Nothing Dynamic1 g |= MkMaybe (g Maybe) instance Typeable1 Maybe where toDyn1 = MkMaybe fromDynamic1 (MkMaybe gm) = Just gm fromDynamic1 _ = Nothing I submit that this is "hairy" rather than "ugly", but I suspect the Type-Constructors Of Unusual Kind (TCOUKs) get even hairier for Typeable2, Typeable3 etc... -- Ashley Yakeley, Seattle WA From ralfla at microsoft.com Sat Sep 24 04:29:41 2005 From: ralfla at microsoft.com (Ralf Lammel) Date: Sat Sep 24 04:10:01 2005 Subject: [Haskell] Object-Orientation and Haskell Message-ID: <1152E22EE8996742A7E36BBBA7768FEE07242C1A@RED-MSG-50.redmond.corp.microsoft.com> > Define a type A such that for any type B you can define > > up :: B -> A > down :: A -> Maybe B > > such that > > down . up = Just > > You can do this quite easily in Java or C++, mutatis mutandis. You can't > do this in Haskell, I don't think. You can't actually do this in > O'Haskell either, it seems the O' essentially amounts to syntactic sugar. You can't even do this in OCaml. However, in OOHaskell you can. >From the TOC of the OOHaskell paper http://homepages.cwi.nl/~ralf/OOHaskell/ 5.4 Casts based on dynamics 50 5.5 Casts based on unions 51 The second technique may add something to this discussion here. We use a sort of intersection-type encoding (also reminiscent of TICs). Thanks, Ralf From blume at tti-c.org Fri Sep 23 10:42:11 2005 From: blume at tti-c.org (Matthias Blume) Date: Sun Sep 25 00:54:12 2005 Subject: [Haskell] *** ICFP '06 CALL FOR WORKSHOP PROPOSALS *** Message-ID: <56AE4829-DF3B-4D04-A6FA-CD62E3A47897@tti-c.org> ICFP '06 CALL FOR WORKSHOP PROPOSALS The ICFP 2006 ACM SIGPLAN International Conference on Functional Programming will be held in Portland, Oregon from September 18 to September 20, 2006. Proposals for workshops are invited for consideration of ACM SIGPLAN sponsorship and affiliation with ICFP 2006. Affiliated workshops will be held on September 16 and 17 (as well as on September 21, if necessary). The purpose of these workshops is to provide a forum for presenting novel ideas in a less formal and possibly more focused way than at ICFP itself. They may also provide good opportunities for young researchers to present their work to, and to obtain feedback from, a specialized community. The format of each workshop is to be determined by its organizers, but it is expected that each workshop allows ample time for general discussion. The preference is for workshops which span only one day, but other schedules will also be considered. Researchers and practitioners are invited to submit workshop proposals to the ICFP 2006 Workshop Chairs, Matthias Blume and Patricia Johann, via e-mail (icfp06-workshops@cs.uchicago.edu), NO LATER THAN NOVEMBER 11, 2005. Submission may be made by e-mail (Postscript, PDF, or ASCII) with "ICFP06 Workshop Submission" in the subject header. Following ACM SIGPLAN's sponsorship procedures, proposals must include: 1. The name of the workshop. 2. A statement of goals for the workshop. 3. The names and addresses of the organizers. 4. The names of potential participants, such as program committee members. (It would be wise to inform your potential comittee members that they have been selected pending SIGPLAN approval.) 5. A description of plans for calls for participation (e.g., calls for papers). 6. The expected number of attendees and planned length of the workshop. 7. A description of plans for publicity. 8. An explanation of any plans for a published proceedings. 9. A description of past versions of the workshop, including dates, organizers, submission and acceptance counts, attendance, sites, registration fees and summary budget information. 10. The URL of the workshop web site. Note that should a proposal be accepted, a final report about the workshop, suitable for publication in SIGPLAN Notices, will be required. Notification of acceptance will be made by DECEMBER 15, 2005. Accepted workshops will be sponsored by SIGPLAN (see http://www.acm.org/sigplan/sigplan_workshop_proposal.htm for more information). A committee chaired by the ICFP 2006 Workshop Chairs and consisting of the ICFP Program and General Chairs and the SIGPLAN Executive Committee will evaluate all proposals. The workshop selection committee members are: * Matthias Blume, TTI-Chicago, Workshop co-Chair for ICFP 2006 * Patricia Johann, Rutgers University, Workshop co-Chair for ICFP 2006 * Julia Lawall, DIKU, Program Chair for ICFP 2006 * John Reppy, University of Chicago, General Chair for ICFP 2006 The maximum number of workshop proposals to be accepted is 6. Any further information needed for preparing a workshop proposal can be obtained by sending email to the workshop chairs (icfp06-workshops@cs.uchicago.edu) or consulting the ICFP 2006 web site at http://icfp06.cs.uchicago.edu/. From vivian.mcphail at paradise.net.nz Sun Sep 25 09:01:29 2005 From: vivian.mcphail at paradise.net.nz (Vivian McPhail) Date: Sun Sep 25 08:47:45 2005 Subject: [Haskell] sweet bananas, lenses, and other miscellaneous brackets Message-ID: <02ec01c5c1d1$3f245b00$0301a8c0@intranet> Hi, Just as we can define infix operators as syntactic sugar, could we not also have a similar mechanism for programmable fancy brackets? There could be a keyword for the bracket declaration and a function definition, in this way ana- and catamorphisms, Template Haskell-like syntax, and set notation could become a regular feature of the language. I am more interested in the general idea than the syntax of this specific example: \begin{code} bracket (( _ )) :: a -> Ana a bracket (| _ |) :: a -> Cata a bracket [ _ | _ |] :: Char -> b -> Splice -- or whatever bracket {[ _ , .. ]} :: [a] -> SList a ((( _ ))) :: a -> Ana a (( x )) = Ana x ((| _ |)) :: a -> Cata a (| x |) = Cata x ([ _ | _ |]) :: Char -> b -> Splice [ c | t |] = case c of b -> doC t d -> doD t -- or whatever -- the idea of this bracket is to create a user-defined list-type structure -- {[ "the" , "lambda" , "calculus" ]} -- would have the value -- (SCons "the" (SCons "lambda" (SCons "calculus" SEmpty))) ({[ _ , .. ]} :: [a] -> SList a {[ [] ]} = sempty {[ x:xs ]} = scons x {[ xs ]} \end{code} Any thoughts? Vivian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/haskell/attachments/20050926/06b32025/attachment.htm From zednenem at psualum.com Mon Sep 26 01:01:56 2005 From: zednenem at psualum.com (David Menendez) Date: Mon Sep 26 00:42:13 2005 Subject: [Haskell] Paper: The essence of dataflow programming In-Reply-To: <20050921201954.A45A141FBD@suhkur.cc.ioc.ee> Message-ID: Tarmo Uustalu writes: | We would like to announce our new paper | | The essence of dataflow programming | | http://cs.ioc.ee/~tarmo/papers/essence.pdf | | which describes a novel comonadic foundation of dataflow computing, | incl. semantics of dataflow languages a la Lucid or Lustre. The | central point is that comonads structure the context-dependence in | dataflow paradigms in much the same way as monads organize | effects. The paper was specifically written for functional | programmers (as opposed to semanticists). This is really cool! For those who haven't read the above paper yet, it describes how to structure an interpreter for a dataflow language using comonads, similar to the way you can structure an interpreter for an impure language using monads. Inspired, I've tried my hand at implementing some of the example dataflow functions directly in Haskell. This message is literate Haskell code. It uses the arrow syntax in a few places; these are just examples, so you may comment them out if you do not have a recent-enough GHCi or an arrow syntax preprocessor. > {-# OPTIONS -farrows #-} > module Dataflow where > import Prelude hiding (sum) > import Control.Arrow FIrst, a class for comonads: > class Functor d => Comonad d where > extract :: d a -> a > coextend :: (d a -> b) -> d a -> d b (In the paper, these are "counit" and "cobind".) We'll also define the injection combinator from Kieburtz's paper[1]: > (.>>) :: Functor d => d a -> b -> d b > d .>> a = fmap (const a) d As a simple example, the environment comonad: > instance Functor ((,) e) where > fmap f (e,a) = (e, f a) > > instance Comonad ((,) e) where > extract (e,a) = a > coextend f d@(e,a) = (e, f d) This is closely related to the reader monad (in fact they are adjoint). Given a comonad d, we can also create an arrow Cokleisli d: > newtype Cokleisli d a b = Cokleisli { runCokleisli :: d a -> b } > > instance Comonad d => Arrow (Cokleisli d) where > arr f = Cokleisli (f . extract) > > Cokleisli f >>> Cokleisli g = Cokleisli (g . coextend f) > > first (Cokleisli f) = Cokleisli $ > \d -> (f (fmap fst d), snd (extract d)) Here is something I did not expect to find: you can *apply* cokleisli arrows. > instance Comonad d => ArrowApply (Cokleisli d) where > app = Cokleisli $ > \d -> runCokleisli (fst (extract d)) (fmap snd d) > > instance Comonad d => ArrowChoice (Cokleisli d) where > left = leftApp Now, I haven't proven that this implementation of app satisfies the relevant laws, but assuming it does, it raises some questions. Most of the papers dealing with arrows state that instances of ArrowApply are equivalent to monads, but cokleisli arrows allow you to do dataflow programming, which cannot be done with monads. That may or may not be a contradiction. One point to consider is that the type "Cokleisli d a b" (or "d a -> b") is isomorphic to "Reader (d a) b" (or "d a -> b"), and "Reader (d a)" is a monad. Thus: > instance Functor (Cokleisli d a) where > fmap f (Cokleisli k) = Cokleisli (f . k) > > instance Monad (Cokleisli d a) where > return a = Cokleisli (const a) > > Cokleisli k >>= f = Cokleisli $ \d -> runCokleisli (f (k d)) d I don't know whether this is significant or useful. To describe synchronous dataflow languages (where values can depend on the past, but not the future), Uustalu and Vene employ the non-empty list comonad, which I will call History. > data History a = First a | History a :> a > infixl 4 :> > > runHistory :: (History a -> b) -> [a] -> [b] > runHistory f [] = [] > runHistory f (a:as) = run (First a) as > where > run az [] = [f az] > run az (a:as) = f az : run (az :> a) as > > instance Functor History where > fmap f (First a) = First (f a) > fmap f (as :> a) = fmap f as :> f a > > instance Comonad History where > extract (First a) = a > extract (as :> a) = a > > coextend f d@(First a) = First (f d) > coextend f d@(as :> a) = coextend f as :> f d We'll also need a combinator "fby", which is short for "followed by". In a dataflow language, you might write: pos = 0 fby (pos + 1) Which means that pos is initially zero, and its next value is always the current value plus one. The fby combinator is easy to define, > fby :: a -> History a -> a > a0 `fby` First a = a0 > a0 `fby` (az :> a) = extract az but defining pos requires recursion. Thanks to Yampa[2], we know how this sort of thing looks when written in arrow notation: > type Hist = Cokleisli History > > posA :: Hist a Integer > posA = proc _ -> do > rec > x <- delay 0 -< x + 1 > returnA -< x We can define 'delay' using 'fby'. > delay :: a -> Hist a a > delay a0 = Cokleisli $ \d -> a0 `fby` d Now we just need a instance for ArrowLoop. This was tricky, but I eventually managed to reverse-engineer the ArrowLoop instance for Kleisli arrows and come up with a counterpart. I rely on two combinators. The first, czip, is from the paper and expresses the ability to merge two comonadic values. > class Comonad d => ComonadZip d where > czip :: d a -> d b -> d (a,b) > > instance ComonadZip History where > czip (First a) (First b) = First (a,b) > czip (as :> a) (First b) = First (a,b) > czip (First a) (bs :> b) = First (a,b) > czip (as :> a) (bs :> b) = czip as bs :> (a,b) The second, cfix, corresponds to mfix. > cfix :: Comonad d => d (d a -> a) -> a > cfix d = extract d (coextend cfix d) Interestingly enough, cfix, unlike mfix, is defined for all comonads. Finally, ArrowLoop: > instance ComonadZip d => ArrowLoop (Cokleisli d) where > loop (Cokleisli f) = Cokleisli (fst . cfix . coextend f') > where > f' da db = f (czip da (fmap snd db)) Assuming, again, that this satisfies the appropriate laws, it suggests that ComonadZip is in some way dual to MonadFix. Now, a quick function for running History arrows: > runHist :: Hist a b -> [a] -> [b] > runHist = runHistory . runCokleisli and presto: *Dataflow> runHist posA [(),(),()] [0,1,2] Having defined pos as an arrow, can we define it using the comonad combinators directly? Yes, but it doesn't look as pretty: > pos :: History a -> Int > pos d = cfix $ d .>> \dpos -> 0 `fby` fmap (+1) dpos Using (.>>), we inject a function into the comonad, giving us a value of the necessary type for cfix. This is noisy, but you can see the similiarities to the original code, pos = 0 fby (pos + 1) Fortunately, the arrow notation lets us work in a more intuitive fashion without having to define a comonadic counterpart to the mdo syntax. Here are some other examples from the paper. > -- sum x = x + (0 fby sum x) > > sumA :: Num a => Hist a a > sumA = proc x -> do > rec > prev_sum <- delay 0 -< sum > let sum = x + prev_sum > returnA -< sum > > sum :: Num a => History a -> a > sum dx = extract dx + 0 `fby` coextend sum dx > > -- diff x = x - 0 fby x > > diffA :: Num a => Hist a a > diffA = proc x -> do > prev_x <- delay 0 -< x > returnA -< x - prev_x > > diff :: Num a => History a -> a > diff dx = extract dx - 0 `fby` dx > > -- ini x = x fby ini x > > ini :: History a -> a > ini x = extract x `fby` coextend ini x > > iniA :: Hist a a > iniA = proc x -> do > rec i <- delay x -<< i > returnA -< i > > -- fibo = 0 fby (fibo + (1 fby fibo)) > > fibo :: Num b => History a -> b > fibo d = cfix $ d .>> \dfibo -> > 0 `fby` coextend (\dfibo -> extract dfibo + 1 `fby` dfibo) dfibo > > fiboA :: Num b => Hist a b > fiboA = proc _ -> do > rec > fib <- delay 0 -< next_fib > next_fib <- delay 1 -< fib + next_fib > returnA -< fib Note that the versions written with straight comonads are sometimes simpler than those written using arrow syntax. In particular, iniA involves arrow recursion and arrow application, while ini gets by with regular recursion and application. While the Fibonacci series examples work, they are extremely inefficient. As it happens, it is possible to write O(n) versions: > fibo' :: Num b => History a -> b > fibo' d = fst $ cfix $ > d .>> \dfibo -> (0,1) `fby` fmap (\(x,x') -> (x',x+x')) dfibo > > fiboA' :: Num b => Hist a b > fiboA' = proc _ -> do > rec (fib, next_fib) <- delay (0,1) -< (next_fib, fib + next_fib) > returnA -< fib I initially thought the problem with fiboA was the double use of delay, but this code--essentially a hand translation of fiboA into raw arrow combinators--is also O(n). > fiboA'' :: Num b => Hist a b > fiboA'' = loop $ > second ((arr snd >>> delay 0) &&& (arr (uncurry (+)) >>> delay 1)) > >>> arr (\(_,d) -> (fst d,d)) I'm not sure why fiboA'' works so much better than fiboA. To clarify, fibo' and its relatives are O(n) for calculating the nth Fibonacci number *only*. If you want to find the first n Fibonacci numbers, then they are O(n^2). This is because each calculation occurs separately. Consider the signature of sum: sum :: Num a => History a -> a The use of fby makes it seem like sum is using past calculations, but in fact there can be no communication from one invocation of sum to the next. Thus, sum is O(n), but "coextend sum" is O(n^2). There are other arrows with better performance. Consider the automaton arrow[3]: newtype Auto a b = Auto (a -> (b, Auto a b)) This is an instance of Arrow, ArrowChoice, and ArrowLoop. It supports a delay operation, just like the History comonad and its relatives. Its versions of posA, sumA, and fiboA are O(n). To gain that performance, it gives up power: Auto is not an instance of ArrowApply, meaning iniA has to be defined as a primitive. I don't have any conclusion, except to say that it's great to see some examples of comonads in action. I had heard comonads described as encapsulating context-dependence, much as monads encapsulate effects, but I never had a good sense of what that meant before now. Actually, the context-dependence angle also suggests a connection to zippers[4]. I guess that's my next project. [1] [2] [3] [4] -- David Menendez From ekarttun at cs.helsinki.fi Mon Sep 26 03:45:25 2005 From: ekarttun at cs.helsinki.fi (Einar Karttunen) Date: Mon Sep 26 03:22:11 2005 Subject: [Haskell] Paper: The essence of dataflow programming In-Reply-To: References: <20050921201954.A45A141FBD@suhkur.cc.ioc.ee> Message-ID: <20050926074525.GA10893@yui.aoinet> On 26.09 01:01, David Menendez wrote: > We'll also define the injection combinator from Kieburtz's paper[1]: > > > (.>>) :: Functor d => d a -> b -> d b > > d .>> a = fmap (const a) d We add some nice combinators: (>>-) :: Comonad co => (co a -> co b) -> (co b -> co c) -> co a -> co c a >>- b = b . a infixr >>- (>>--) :: Comonad co => (co a -> co b) -> (b -> co b -> co c) -> co a -> co c a >>-- b = \co -> let x = a co in b (counit x) x infixr >>-- coreturn v = cobind (const v) And define the simple state comonad: data StateC st a = StateC (st -> a) st instance Comonad (StateC st) where counit (StateC f v) = f v cobind fun (StateC f v) = StateC (\v -> fun (StateC f v)) v get :: StateC st a -> StateC st st get (StateC _ st) = StateC id st set :: st -> StateC st a -> StateC st a set new (StateC fun _) = StateC fun new modify :: (c -> c) -> StateC c a -> StateC c a modify mutator (StateC fun st) = StateC fun $ mutator st runStateC fun v0 = let StateC a b = fun (StateC id v0) in (a b,b) Now we can write comonadic code like monadic code: foobar = get >>-- \x -> coreturn (3*x) test3 = get >>-- \x -> set 15 >>- foobar >>-- \y -> set x >>- coreturn (show y) This looks very much like monadic code written with >> and >>=. A general Functor instance is easy (but non-haskell98): instance Comonad w => Functor w where fmap f = cobind (f . counit) - Einar Karttunen From joelr1 at gmail.com Mon Sep 26 03:56:54 2005 From: joelr1 at gmail.com (Joel Reymont) Date: Mon Sep 26 03:37:08 2005 Subject: [Haskell] Making shared libraries with Haskell Message-ID: <0C76622A-7484-43ED-8D50-9A98AFFAA1CA@gmail.com> Folks, Is the procedure of creating shared libraries with Haskell and loading them from C described somewhere? Is this even possible? Thanks, Joel -- http://wagerlabs.com/ From tarmo at cs.ioc.ee Mon Sep 26 08:44:57 2005 From: tarmo at cs.ioc.ee (Tarmo Uustalu) Date: Mon Sep 26 08:27:15 2005 Subject: [Haskell] Paper: The essence of dataflow programming In-Reply-To: Message from David Menendez of "Mon, 26 Sep 2005 01:01:56 EDT." References: Message-ID: <20050926123850.80AA941FB7@suhkur.cc.ioc.ee> Dear Dave, Thanks for the nice propaganda! A few comments regarding the points you made in your message. Ineffeciency of fibo-like programs: Your observations are true. But this is a comonadic interpreter analogous to the cbv monadic interpreter. One can also define an analogue to the cbn monadic interpreter. This is better than the "cbv" version on the n first Fibonacci numbers but worse on the nth number alone... Zippers: Yes, of course! Streams are an infinite linear datastructure, but you can also do trees (eg decorated parse trees of a CFG). Such trees with a distinguished position are of course the zipper datatype and this is a comonad as well. And similarly to the comonadic approach to the semantics of dataflow languages one can give a comonadic structure eg to attribute grammar specifications (either purely synthesized attribute grammars or general attribute grammars). We've developed these ideas in a paper that was presented at TFP, see http://www.cs.ioc.ee/~tarmo/papers/tfp05.pdf (this is the symposium version, the full version is in preparation.) To present the comonadic semantics of attribute grammar specifications neatly, one needs either GADTs or dependent types. Best wishes, Tarmo U From yogibear at cmiddlemast.fsnet.co.uk Sun Sep 25 15:44:37 2005 From: yogibear at cmiddlemast.fsnet.co.uk (Craig Middlemast) Date: Mon Sep 26 10:06:46 2005 Subject: [Haskell] Haskell Interfacing With VB Message-ID: <20050925194441.0279F1C00083@mwinf3012.me.freeserve.com> Hello, I computing student entering my final year at Northumbria University, Newcastle upon Tyne. I am doing some research for my final year project which is to design and build a Syntax Directed Editor for a high level computing language. The problem which I have is that I would like to use VB as a user interface and Haskell as the parser, however I am not sure if this is possible. Therefore I was hoping that you could answer the question regarding Haskell and VB interfacing, is it possible to interface the two languages, and if so could you give me some insight how this can be achieved. Regards Craig Middlemast -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/haskell/attachments/20050925/ead9e76f/attachment.htm From pinna at unisi.it Mon Sep 26 04:47:33 2005 From: pinna at unisi.it (g. michele pinna) Date: Mon Sep 26 10:06:47 2005 Subject: [Haskell] ICTCS 2005: Call for participation Message-ID: Ninth Italian Conference on Theoretical Computer Science (ICTCS'05) Certosa di Pontignano (Siena), Italy October 12 - 14, 2005 http://ictcs05.dsmi.unisi.it Call for Partecipation The Ninth Italian Conference on Theoretical Computer Science will take place at the Certosa di Pontignano (Siena), Italy. There will be three invited speakers: Luca Cardelli (Microsoft Research, Cambridge, United Kingdom) Giuseppe Castagna (LIENS - ?cole Normale Sup?rieure, Paris, France) Nicola Santoro (School of Computer Science, Carleton University, Ottawa, Canada) Program Committee: Michele Bugliesi (Venezia), Mario Coppo (Torino, Co-Chair), Pierluigi Crescenzi (Firenze), Giulia Galbiati (Pavia) Luisa Gargano (Salerno), Giorgio Ghelli (Pisa), Roberto Grossi (Pisa), Benedetto Intrigila (L'Aquila), Nicola Leone (Cosenza), Elena Lodi (Siena, Co-Chair), Flaminia Luccio (Trieste), Andrea Masini (Verona), Giancarlo Mauri (Milano), Corrado Priami (Trento), Geppino Pucci (Padova), Davide Sangiorgi (Bologna). Preliminary program: Wednesday, October 12: 08,45 - 09,00 Welcome 09,00 - 10,00 L. Cardelli: Biological System as Reactive Systems 10,00 - 11,00 B. DasGupta, S. Ferrarini, U. Gopalakrishnan, N. Paryani: Inapproximability Results for the Lateral Gene Transfer Problem S. Mantaci, A. Restivo, G. Rosone, M. Sciortino: A new combinatorial approach to sequence comparison 11,00 - 11,20 coffee break 11,20 - 13,20 M. Bartoletti, P. Degano, G. L. Ferrari: Checking Risky Events is Enough for Local Policy B. Aziz, D. Gray, G. Hamilton: A Static Analsis of PKI-Based Systems R. Medel, A. Compagnoni, E. Bonelli: A Typed Assembly Language for Non-interference L. Bettini, V. Bono, S. Likavec: Safe Object Composition in the Presence of Subtyping 13,20 - 15,00 Lunch 15,00 - 17,00 L. A. Hemaspaandra, J. Rothe, A. Saxena: Enforcing and Defying Associativity, Commutativity, Totality, and Strong Noninvertibility for One-Way Functions in Complexity Theory J. Fiala, J. Kratochvil: On the computational complexity of the L(2,1)-labeling problem for regular graphs B. Escoffier, J. Monnot, V. T. Paschos: Weighted coloring: further complexity and approximability results V. Raman, S. Saurabh, S. Sikdar: Improved Exact Exponential Algorithms for Vertex Bipartization and Other Problems 17,00 - 17,20 coffee break 17,20 - 19,20 S. van Bakel, U. de' Liguoro: Subtyping Object and Recursive Types Logically J. Schwinghammer: A Typed Semantics of Higher Order Store and Subtyping W. Jamroga, J. Dix: Model Checking Strategic Abilities of Agents under Incomplete Information S. Heymans, D. Van Nieuwenborgh, D. Vermeir: Synthesis from Temporal Specifications using Preferred Answer Set Programming 20,00 - Dinner Thursday, October 13: 09,00 - 10,00 N. Santoro: Mobile Agents Computing: Security Issues and Algorithmic Solutions 10,00 - 11,00 T. Kuboyama, K. Shin, T. Miyahara, H. Yasuda: A Theoretical Analysis of Alignment and Edit Problems for Trees L. Anderegg, M. Cieliebak, G. Prencipe: Efficient Algorithms for Detecting Regular Point Configurations 11,00 - 11,20 coffee break 11,20 - 13,20 R. Statman: Two Variables are Not Enough S. van Bakel, S. Lengrand, P. Lescanne: The language X: Circuits, Computations and Classical Logic C. Bertolissi: The Graph Rewriting Calculus: confluence and Expressiveness N. Busi, G. Zavattaro: Reachability Analysis in Boxed Ambients 13,20 - 15,00 Lunch 15,15 - 17,15 G. De Marco, M. Pellegrini, G. Sburlati: Faster Deterministic Wakeup in Multiple Access Channels M-C. Costa, F. Jarray, C. Picoleau: Reconstructing an alternate periodical binary matrix from its orthogonal projections S. Fung, F. Chin, C. K. Poon: Laxity helps in broadcast scheduling Y. Asahiro, E. Miyano, S. Shimoirisa: Pickup and Delivery for Moving Objects on Broken Lines 17,30 - Excursion to Siena 18,00 - 20,00 EATCS Italian Chapter Annual Meeting (at the Dipartimento di Scienze Matematiche e Informatiche "R. Magari" 20,30 - Social dinner Friday, October 14: 09,00 - 10,00 G. Castagna: Semantic Subtyping: challenges, perspectives and open problems 10,00 - 11,00 G. Castagna, D. Colazzo, A. Frish: Error Mining for Regular Expressions Patterns M. Macchetti, M. Caironi, L. Breveglieri, A. Cherubini: A Complete Formulation of Generalized Affine Equivalence 11,00 - 11,30 coffee break 11,30 - 13,00 T. Kopelowitz, E. Porat: Improved Algorithms for Polynomial Time-Decay and Time-Decay with Additive error S. Fenner, Y. Zhan: Quantum Algorithms for a Set of Group Theoretic Problems G. Franco: A polymerase based algorithm for SAT 13,00 - 13,20 End of the Conference 13,20 Lunch Registration The registration form is available at http://ictcs05.dsmi.unisi.it/registration.html or at the web page http://conference.unisi.it/gest-congressi/web/online_ing.asp?id_cong=670 Here is a list of hotels with web sites Hotel Athena (4 stars): http://www.hotelathena.com Hotel Garden (4 stars): http://www.garden-hotels.it/it/garden/garden.html Hotel Italia (3 stars): http://www.garden-hotels.it/it/italia/italia.html Hotel Palazzo Ravizza (3 stars): http://www.palazzoravizza.it/ Hotel Minerva (3 stars): http://www.emmeti.it/Welcome/Toscana/Senese/Siena/Alberghi/Minerva/ Hotel Duomo (3 stars): http://www.hotelduomo.it/ Hotel Etruria (2 stars): http://www.hoteletruria.com Piccolo Hotel il Palio (2 stars): http://www.minotel.com/minotelPublic/main/basicHotelInfo.asp?hotelCode=IT107 Hotel Cannon D'Oro (2 stars): http://www.cannondoro.com Booking can also be made via the Siena Hotels Promotion - Congress & Meeting Dept. email: congressi@hotelsiena.com http://www.hotelsiena.com Piazza M.T. di Calcutta, 5 - 53100 Siena - Italy Tel. 0039+0577+288084 - Fax. 0039+0577+280290 Please quote ICTCS conference in the request. Further informations are available at the conference web pages. From cgibbard at gmail.com Mon Sep 26 11:06:46 2005 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon Sep 26 10:48:16 2005 Subject: [Haskell] Haskell Interfacing With VB In-Reply-To: <20050925194441.0279F1C00083@mwinf3012.me.freeserve.com> References: <20050925194441.0279F1C00083@mwinf3012.me.freeserve.com> Message-ID: <89ca3d1f050926080685a1670@mail.gmail.com> On 25/09/05, Craig Middlemast wrote: > Hello, > > I computing student entering my final year at Northumbria University, > Newcastle upon Tyne. I am doing some research for my final year project > which is to design and build a Syntax Directed Editor for a high level > computing language. > > The problem which I have is that I would like to use VB as a user interface > and Haskell as the parser, however I am not sure if this is possible. > Therefore I was hoping that you could answer the question regarding Haskell > and VB interfacing, is it possible to interface the two languages, and if so > could you give me some insight how this can be achieved. > > Regards > > Craig Middlemast Well, I don't know about VB, but if you're after a library with a nice GUI editor, you might try using Glade (http://glade.gnome.org/) with Gtk2Hs (http://haskell.org/gtk2hs/) which I've been finding to be quite a nice combination of tools. You can use Glade to produce XML templates of user interfaces which you can load in your Haskell program by using the functions in Graphics.UI.Gtk.Glade from Gtk2Hs. I've never tried doing this on win32, but apparently there is a win32 port of Glade (http://gladewin32.sourceforge.net/), so I think it should be possible to get things to work. Someone else might be able to tell you about using VB... I seem to recall some people working on .net integration for Haskell, though I'm not sure how that's going. I'm not really a windows user myself. anyway, hope this is useful - Cale From wchogg at lotus.hep.wisc.edu Mon Sep 26 11:19:09 2005 From: wchogg at lotus.hep.wisc.edu (Creighton Hogg) Date: Mon Sep 26 11:00:43 2005 Subject: [Haskell] IO functions reference? Message-ID: Hi, I've been trying to write some code in Haskell and have been running into trouble not knowing the already built-in IO functions. For example, is there a function that will take a line and turn it into a list? Is there a reference where one can lookup all these things? Thanks, Creighton Hogg From bortzmeyer at nic.fr Mon Sep 26 11:28:33 2005 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon Sep 26 11:10:08 2005 Subject: [Haskell] Re: IO functions reference? In-Reply-To: References: Message-ID: <20050926152833.GA10469@nic.fr> On Mon, Sep 26, 2005 at 10:19:09AM -0500, Creighton Hogg wrote a message of 13 lines which said: > Is there a reference where one can lookup all these things? I use: http://www.zvon.org/other/haskell/Outputglobal/index.html From cgibbard at gmail.com Mon Sep 26 13:23:17 2005 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon Sep 26 13:04:51 2005 Subject: [Haskell] IO functions reference? In-Reply-To: References: Message-ID: <89ca3d1f0509261023b7acd4a@mail.gmail.com> On 26/09/05, Creighton Hogg wrote: > Hi, > I've been trying to write some code in Haskell and have been > running into trouble not knowing the already built-in IO > functions. For example, is there a function that will take > a line and turn it into a list? > Is there a reference where one can lookup all these things? > > Thanks, > Creighton Hogg Well, the standard prelude is the first thing to read: http://www.haskell.org/onlinereport/standard-prelude.html Then refer to the standard libraries: http://www.haskell.org/ghc/docs/latest/html/libraries/index.html for lots more. Also in Part II of the report, there's further documentation for some of the libraries (though they have been moved into the hierarchy). http://www.haskell.org/onlinereport/ From shelarcy at capella.freemail.ne.jp Mon Sep 26 13:28:52 2005 From: shelarcy at capella.freemail.ne.jp (shelarcy) Date: Mon Sep 26 13:10:37 2005 Subject: [Haskell] Haskell Interfacing With VB In-Reply-To: <20050925194441.0279F1C00083@mwinf3012.me.freeserve.com> References: <20050925194441.0279F1C00083@mwinf3012.me.freeserve.com> Message-ID: On Mon, 26 Sep 2005 04:44:37 +0900, Craig Middlemast wrote: > I computing student entering my final year at Northumbria University, > Newcastle upon Tyne. I am doing some research for my final year project > which is to design and build a Syntax Directed Editor for a high level > computing language. Do you see Proxima (http://www.cs.uu.nl/research/projects/proxima/) and its thesis? Proxima isn't Syntax-directed editor, but it tries to integrate Syntax-directed editors and Syntax-recognizing editor's idea, and Proxima thesis shows its Architechture. If you intereseted in that, you can get source code by cvs. I don't know that CVS HEAD works well. but it is helpful for you. > The problem which I have is that I would like to use VB as a user > interface > and Haskell as the parser, however I am not sure if this is possible. > Therefore I was hoping that you could answer the question regarding > Haskell > and VB interfacing, is it possible to interface the two languages, and > if so > could you give me some insight how this can be achieved. Proxima depend on wxHaskell (http://wxhaskell.sourceforge.net/). wxHaskell is one of the option to implement GUI program. If you think wxHaskell's editor program support is very poor, you can use Haste (http://haste.dyndns.org:8080/)'s website patch. -- shelarcy http://page.freett.com/shelarcy/ From wchogg at lotus.hep.wisc.edu Mon Sep 26 20:26:45 2005 From: wchogg at lotus.hep.wisc.edu (Creighton Hogg) Date: Tue Sep 27 08:30:14 2005 Subject: [Haskell] Re: IO functions reference? In-Reply-To: <20050926152833.GA10469@nic.fr> References: <20050926152833.GA10469@nic.fr> Message-ID: On Mon, 26 Sep 2005, Stephane Bortzmeyer wrote: > On Mon, Sep 26, 2005 at 10:19:09AM -0500, > Creighton Hogg wrote > a message of 13 lines which said: > > > Is there a reference where one can lookup all these things? > > I use: > > http://www.zvon.org/other/haskell/Outputglobal/index.html > I appreciate all the references people gave. So I looked to see if there were any standard functions for taking an input line and turning it into a list, and I couldn't find any. How would one do this in Haskell? I just want to parse the line into a list of strings, and from there recover the numbers from the strings. Basically, my goal is to take a table of floats, read it in line by line and store it into a list of lists, then run the whole thing through a function and print the output. That doesn't seem easy though, unelss there's something I'm missing. From ketil+haskell at ii.uib.no Tue Sep 27 08:55:28 2005 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Tue Sep 27 08:37:00 2005 Subject: [Haskell] Re: IO functions reference? In-Reply-To: (Creighton Hogg's message of "Mon, 26 Sep 2005 19:26:45 -0500 (CDT)") References: <20050926152833.GA10469@nic.fr> Message-ID: Creighton Hogg writes: > So I looked to see if there were any standard functions for > taking an input line and turning it into a list, and I > couldn't find any. How would one do this in Haskell? I > just want to parse the line into a list of strings, and > from there recover the numbers from the strings. In other words, you want to split "lines" into "words" and "read" numbers from the result? Perhaps you should check the Prelude again. > That doesn't seem easy though, unelss there's something I'm > missing. Reading from and writing to the outside world must take place in the IO monad. The parsing and other manipulation can be done by functions, use e.g. "let" in the IO code to construct intermediate values. E.g., main can look like: main = do f <- readFile "table.txt" let x = my_parse_function f putStrLn x my_parse_function :: String -> String ... -k -- If I haven't seen further, it is by standing in the footprints of giants From wchogg at lotus.hep.wisc.edu Tue Sep 27 10:48:14 2005 From: wchogg at lotus.hep.wisc.edu (Creighton Hogg) Date: Tue Sep 27 10:29:45 2005 Subject: [Haskell] Re: IO functions reference? In-Reply-To: References: <20050926152833.GA10469@nic.fr> Message-ID: On Tue, 27 Sep 2005, Ketil Malde wrote: > Creighton Hogg writes: > > > So I looked to see if there were any standard functions for > > taking an input line and turning it into a list, and I > > couldn't find any. How would one do this in Haskell? I > > just want to parse the line into a list of strings, and > > from there recover the numbers from the strings. > > In other words, you want to split "lines" into "words" and "read" > numbers from the result? Perhaps you should check the Prelude again. Well don't I feel silly. I'll RTFM next time instead of just skimming the type signatures. > > That doesn't seem easy though, unelss there's something I'm > > missing. > > Reading from and writing to the outside world must take place in the > IO monad. The parsing and other manipulation can be done by > functions, use e.g. "let" in the IO code to construct intermediate > values. > > E.g., main can look like: > > main = do > f <- readFile "table.txt" > let x = my_parse_function f > putStrLn x > > my_parse_function :: String -> String > ... Okay this is a bit more clear to me now, thanks. From ashley at semantic.org Tue Sep 27 16:44:28 2005 From: ashley at semantic.org (Ashley Yakeley) Date: Tue Sep 27 16:34:52 2005 Subject: [Haskell] Re: ANNOUNCE: Visual Haskell version 0.0 References: <3429668D0E777A499EE74A7952C382D1048127E7@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: In article <3429668D0E777A499EE74A7952C382D1048127E7@EUR-MSG-01.europe.corp.microso ft.com>, "Simon Marlow" wrote: > A quick note about the license: this is a binary release with a BSD > license. We changed the license at the last minute, and didn't have > time to re-roll the installer. You have the option of using Visual > Haskell either under the click-through license in the installer (a > Microsoft shared source license for non-commercial use) or the more > liberal BSD license in the documentation. Will you be coming out with another installer? I'm not comfortable clicking "accept" on the MSR license... -- Ashley Yakeley, Seattle WA From smith at itee.uq.edu.au Tue Sep 27 01:59:28 2005 From: smith at itee.uq.edu.au (Graeme Smith) Date: Wed Sep 28 04:18:18 2005 Subject: [Haskell] 2nd Call for Participation: IFM 2005 Message-ID: 2nd CALL FOR PARTICIPATION Fifth International Conference on Integrated Formal Methods (IFM) November 30 - December 2, 2005 Eindhoven, The Netherlands http://www.win.tue.nl/ifm/ INVITED SPEAKERS Patrice Godefroid - Software Model Checking: Searching for Computations in the Abstract or the Concrete David Parnas - A Family of Mathematical Methods for Professional Software Documentation Doron Peled - Generating Path Conditions for Timed Systems INVITED TUTORIAL Holger Hermanns - QoS Modelling and Analysis for Embedded Systems PROGRAM The program is now available on the IFM2005 web site. DOCTORAL SYMPOSIUM PhD students are invited to submit a contribution on their current research in integrated formal methods. The symposium will take place in Eindhoven on November 29, right after the tutorial by Holger Hermanns, and one day before the main conference (Nov 30 - Dec 2). For details please check the IFM2005 web site: http://www.win.tue.nl/ifm/. VENUE IFM2005 is hosted by the Technische Universiteit Eindhoven (TU/e). Eindhoven is the largest city of the southern Netherlands and the fifth largest in the Netherlands as a whole. It is a diverse city offering innovation and technology, as well as cultural activities (museums, theatre and music), and leading in sports such as swimming (Olympic champion Pieter van den Hoogenband) and soccer (PSV). In the region of Eindhoven, well-known companies such as Philips, ASML and DAF, and dozens of other engineering companies are situated. Eindhoven and the TU/e campus are easily reachable by plane (Eindhoven Airport) and train (also from Schiphol Airport). REGISTRATION At the IFM web site, the registration page can be found. The early registration deadline is October 16th, 2005. The registration fee includes a copy of the proceedings, attendance of the tutorial and the main conference, lunches, refreshments in the coffee breaks, a welcome reception, an excursion and dinner banquet. PROGRAM COMMITTEE CO-CHAIRS Jaco van de Pol, CWI, The Netherlands Judi Romijn, Eindhoven University of Technology, The Netherlands Graeme Smith, University of Queensland, Australia SPONSORS IFM2005 is sponsored by FME and BCS-FACS. From marcello at liacs.nl Tue Sep 27 06:20:57 2005 From: marcello at liacs.nl (M.M. Bonsangue) Date: Wed Sep 28 04:18:21 2005 Subject: [Haskell] FMCO 2005: first call for participation Message-ID: <200509271020.j8RAKvE13304@tin.liacs.nl> Our apologies if you receive multiple copies of this e-mail. ****************** FIRST CALL FOR PARTICIPATION ******************** Fourth International Symposium on Formal Methods for Components and Objects (FMCO 2005) DATES 1 - 4 November 2005 PLACE CWI, Amsterdam, The Netherlands Registration form and more information at the FMCO site http://fmco.liacs.nl/fmco05.html PRELIMINARY PROGRAM Tuesday November 1st -------------------- SESSION: ALGEBRAIC METHODS 9:00 - 10:00 Keynote: Davide Sangiorgi (University of Bologna, IT) The Bisimulation Proof Method: Enhancements and Challenges Break 10:20 - 11:10 Expressiveness via Leader Election Problems C. Palamidessi (INRIA Futurs Saclay and LIX , FR) Break 11:30 - 12:30 Keynote: Wan Fokkink (Free University, NL) Divide and Congruence Lunch break SESSION: COMPONENT AND SERVICE ORIENTED PROGRAMMING 14:30 - 15:00 Keynote: Kung-Kiu Lau (University of Manchester, UK) Towards a Theory of Software Components Break 15:20 - 16:10 Keynote: Luís Caires (New University of Lisbon, PT) t.b.a. 16:10 - 17:00 Synchronized Hyperedge Replacement as a Model for Service Oriented Computing D. Hirsch (Pisa University, IT) Welcome reception Wednesday November 2nd ---------------------- SESSION: HEAP VERIFICATION 9:30 - 10:30 Keynote: Peter O' Hearn (Queen Mary University of London, UK) Smallfoot: A Tool for Checking Separation Logic Footprint Specifications Break 11:10 - 12:00 Keynote: Joost-Pieter Katoen (RWTH Aachen, DE) Verifying Liveness and Safety of Concurrent Heap-Manipulating Programs Lunch break SESSION: TOOLS 13:30 - 14:30 Keynote: Dennis Dams (Bell Labs, USA) Orion: Building Blocks for Program Analyzers Break 14:50 - 16:00 mCRL2: a language and toolset for behavioural modelling and analysis J.-F. Groote (Technical University Eindhoven, NL) Social event and dinner Thursday Nov 3rd ---------------- SESSION: MODEL CHECKING 9:00 - 10:00 Keynote: Orna Grumberg (Technion, ISR) Abstraction and Refinement in Model Checking Break 10:20 - 11:10 Verification of Evolving Software via Component Substitutability Analysis N. Sinha (Carnegie Mellon University, USA) 11:10 - 12:00 Distributed Analysis of Large Systems L. Brim (University Brno, CZ) Lunch break SPECIAL SESSION 13:30 - 14:30 Keynote: John Reynolds (Carnegie Mellon University, USA) t.b.a. Break SESSION: QUANTITATIVE ANALYSIS 14:50 – 15:40 Quantitative Aspects of Coordination H. Wiklicky (Imperial College London, UK) 15:40 - 16:30 Partial Order Reduction for Markov Decision Processes C. Baier (Bonn University, DE) Friday Nov 4th -------------- SESSION: ASSERTIONAL METHODS 9:00 - 10:00 Keynote: Arnd Poetzsch-Heffter (University of Kaiserslautern, DE) t.b.a. Break 10:20 - 11:10 Beyond Hoare Logic Assertions: Advanced Specification and Verification with JML and ESC/Java2 J. Kiniry (UCD Dublin, IE) Break 11:30 - 12:30 Keynote: Michael Barnett (Microsoft, USA) t.b.a. Lunch break SESSION: SYSTEM DESIGN 14:00 - 15:00 Keynote: Jan van Schuppen (CWI, NL) Decentralized and Modular Control of Discrete-Event Systems Break 15:20 - 16:10 Formal Development of Critical Systems with UML: Methods and Tools J. Jürjens (Technical University Munich, DE) 16:10 - 17:00 UpSTAIRS with Sequence Diagrams K. Stølen (SINTEF ICT, NO) Farewell drink ORGANIZING COMMITTEE F.S. de Boer (CWI and LIACS-Leiden University) M.M. Bonsangue (LIACS-Leiden University) S. Graf (Verimag) W.P. de Roever (CAU) From jgoerzen at complete.org Wed Sep 28 09:54:35 2005 From: jgoerzen at complete.org (John Goerzen) Date: Wed Sep 28 10:44:46 2005 Subject: [Haskell] Haskell Weekly News: September 27, 2005 Message-ID: <20050928135435.GA23705@katherina.lan.complete.org> Haskell Weekly News: September 27, 2005 Greetings, and thanks for reading the ninth issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * GHC 6.4.1 for MacOS X. Wolfgang Thaller [3]announced the availability of a binary GHC 6.4.1 package for MacOS X. 3. http://article.gmane.org/gmane.comp.lang.haskell.general/12182 * ghc-api 0.1.0. Lemmih [4]announced ghc-api, a cabalization of the GHC 6.5 API. It is currently used by hIDE. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12166 Discussion Haskell Team Winns ICFP! Congratulations to Wolfgang Thaller's team for winning the ICFP 2005 programming contest! According to the [5]ICFP homepage, "First prize goes to KiebererAndXiaoTou. The judges are happy to proclaim that Haskell is the programming tool of choice for discriminating hackers." This is the second year in a row in which a team using Haskell has taken first place in this contest. 5. http://icfpc.plt-scheme.org/ The Combat-Tanteidan team (Takayuki Muranushi and Hideyuki Tanaka), also using Haskell, took third place in this year's ICFP. In addition, on page 68 of the [6]presentation slides, you can see that Haskell was the top-performing language at the contest overall. The author wrote, "The clear fact that stands out here is that Haskell is the language of choice for the programming contest. Haskell stands out a little bit in the first round, but it clearly stands out in the twist. So, kudos to the Haskell community for both producing a language that lets people build re-usable code and instilling this as a value in their community!" 6. http://icfpc.plt-scheme.org/icfpc2005-talk.pdf Unfortunately, the names of all team members were not documented, so I was not able to list the real names for this story. Thanks to Don Stewart for sending me information about this. Haskell-style proof tools. Robin Green asked about proof tools, and the resulting [7]thread contained several suggestions. 7. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8451 Trapped by Monads. In this [8]thread, the infamous IO monad was discussed, along with a number of comparisons to Forth. 8. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8427 Quote of the Week Haskell is the programming tool of choice for discriminating hackers. -- ICFP 2005 judges About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [9]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 9. http://sequence.complete.org/hwn-contrib From gale at sefer.org Thu Sep 29 07:49:14 2005 From: gale at sefer.org (Yitzchak Gale) Date: Thu Sep 29 07:30:47 2005 Subject: [Haskell] Literal for Infinity Message-ID: <20050929114914.GB3179@sefer.org> While checking for floating-point overflow and underflow conditions, I tried to create a somewhat reliable cross-platform Infinity with the literal "1e100000". When GHC 6.4.1 reads this literal, it goes into a deep trance and consumes huge amounts of memory. Shouldn't it immediately recognize such a thing as Infinity? Is there a better way to check for Infinity? I have not yet figured out how to check for NaN at all - because it is not equal to itself. Any suggestions? BTW, I notice that Simon PJ proposed literals for Infinity and Nan several years ago: http://www.haskell.org/pipermail/haskell/2001-August/007753.html Did anything ever come out of this? Regards, Yitzchak From tomasz.zielonka at gmail.com Thu Sep 29 08:08:35 2005 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Thu Sep 29 07:49:59 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <20050929114914.GB3179@sefer.org> References: <20050929114914.GB3179@sefer.org> Message-ID: <2bb2bdb40509290508d1ed260@mail.gmail.com> On 9/29/05, Yitzchak Gale wrote: > > While checking for floating-point overflow and > underflow conditions, I tried to create a somewhat > reliable cross-platform Infinity with the literal > "1e100000". > > When GHC 6.4.1 reads this literal, it goes into a > deep trance and consumes huge amounts of > memory. Shouldn't it immediately recognize such a > thing as Infinity? I think it is equivalent to (fromRational 1e100000), and (1e100000 :: Rational) can take a substantial amount of space. Is there a better way to check for Infinity? I > have not yet figured out how to check for NaN at > all - because it is not equal to itself. Any > suggestions? Did you try isNaN and isInfinite? I don't have much experience with these functions myself. Best regards Tomasz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/haskell/attachments/20050929/6e7bbe08/attachment.htm From carette at mcmaster.ca Thu Sep 29 08:13:27 2005 From: carette at mcmaster.ca (Jacques Carette) Date: Thu Sep 29 07:55:01 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <20050929114914.GB3179@sefer.org> References: <20050929114914.GB3179@sefer.org> Message-ID: <433BDA67.6060107@mcmaster.ca> The IEEE 754 standard says (fairly clearly) that +1.0 / +0.0 is one of the most 'stable' definitions of Infinity (in Float at least). Throwing an exception is also regarded as a possibility in IEEE 754, but it is expected that that is not the default, as experience shows that that is a sub-optimal default. Mathematical software (Maple, Mathematica, Matlab) have generally moved in that direction. Almost all hardware implementations of float arithmetic now default to IEEE 754 arithmetic. Having the arithmetic do 'something else' involves more CPU cycles, so users should generally complain if their system's arithmetic differs from IEEE 754 arithmetic without some deep reason to do so [there are some; read and understand William Kahan's papers for these]. Jacques Yitzchak Gale wrote: >While checking for floating-point overflow and >underflow conditions, I tried to create a somewhat >reliable cross-platform Infinity with the literal >"1e100000". > >When GHC 6.4.1 reads this literal, it goes into a >deep trance and consumes huge amounts of >memory. Shouldn't it immediately recognize such a >thing as Infinity? > >Is there a better way to check for Infinity? I >have not yet figured out how to check for NaN at >all - because it is not equal to itself. Any >suggestions? > >BTW, I notice that Simon PJ proposed literals >for Infinity and Nan several years ago: > >http://www.haskell.org/pipermail/haskell/2001-August/007753.html > >Did anything ever come out of this? > >Regards, >Yitzchak >_______________________________________________ >Haskell mailing list >Haskell@haskell.org >http://www.haskell.org/mailman/listinfo/haskell > > From lennart at augustsson.net Thu Sep 29 08:57:05 2005 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Sep 29 08:39:32 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <20050929114914.GB3179@sefer.org> References: <20050929114914.GB3179@sefer.org> Message-ID: <433BE4A1.2050005@augustsson.net> The RealFloat class has a number of methods for testing various properties of a FP number: isNaN :: a -> Bool isInfinite :: a -> Bool isDenormalized :: a -> Bool isNegativeZero :: a -> Bool isIEEE :: a -> Bool If you really want to create an Infinity, I suggest 1/0, but not all FP formats support it (IEEE754 does). -- Lennart Yitzchak Gale wrote: > While checking for floating-point overflow and > underflow conditions, I tried to create a somewhat > reliable cross-platform Infinity with the literal > "1e100000". > > When GHC 6.4.1 reads this literal, it goes into a > deep trance and consumes huge amounts of > memory. Shouldn't it immediately recognize such a > thing as Infinity? > > Is there a better way to check for Infinity? I > have not yet figured out how to check for NaN at > all - because it is not equal to itself. Any > suggestions? > > BTW, I notice that Simon PJ proposed literals > for Infinity and Nan several years ago: > > http://www.haskell.org/pipermail/haskell/2001-August/007753.html > > Did anything ever come out of this? > > Regards, > Yitzchak > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From gale at sefer.org Thu Sep 29 09:41:19 2005 From: gale at sefer.org (Yitzchak Gale) Date: Thu Sep 29 09:22:56 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <2bb2bdb40509290508d1ed260@mail.gmail.com> References: <20050929114914.GB3179@sefer.org> <2bb2bdb40509290508d1ed260@mail.gmail.com> Message-ID: <20050929134119.GD3179@sefer.org> I wrote: > > While checking for floating-point overflow and > > underflow conditions, I tried to create... > > Infinity with the literal "1e100000"... Is > > there a better way to check for Infinity? Tomasz Zielonka wrote: > Did you try isNaN and isInfinite? Oops. Thanks! Thanks also to Lennart Augustsson. I wrote: > > ...I tried to create... Infinity with the > > literal "1e100000"... GHC... goes into a deep > > trance... Tomasz Zielonka wrote: > ...it is equivalent to (fromRational 1e100000), > and (1e100000 :: Rational) can take a > substantial amount of space. I see. That explains it. Thanks! Regards, Yitz From gale at sefer.org Thu Sep 29 14:11:25 2005 From: gale at sefer.org (Yitzchak Gale) Date: Thu Sep 29 13:52:55 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <433BDA67.6060107@mcmaster.ca> References: <20050929114914.GB3179@sefer.org> <433BDA67.6060107@mcmaster.ca> Message-ID: <20050929181125.GA3176@sefer.org> Hi Jacques, Thanks also to you for a most interesting reply. This same discussion has taken place on the discussion list of every modern general-purpose programming language. The same points are always raised and argued, and the conclusion is always the same: floating point exceptions should raise exceptions. Programs that are so sensitive that the tiny overhead makes a difference should use numeric libraries, unboxed types, FFI, and the like. In Haskell also, it looks like the infrastructure was already laid in the Control.Exception module. I hope we will soon be using it. I personally would like also to see alternative functions that return values in the Error monad. Regards, Yitz On Thu, Sep 29, 2005 at 03:13:27PM +0300, Jacques Carette wrote: > The IEEE 754 standard says (fairly clearly) that +1.0 / +0.0 is one of > the most 'stable' definitions of Infinity (in Float at least). > Throwing an exception is also regarded as a possibility in IEEE 754, but > it is expected that that is not the default, as experience shows that > that is a sub-optimal default. Mathematical software (Maple, > Mathematica, Matlab) have generally moved in that direction. > > Almost all hardware implementations of float arithmetic now default to > IEEE 754 arithmetic. Having the arithmetic do 'something else' involves > more CPU cycles, so users should generally complain if their system's > arithmetic differs from IEEE 754 arithmetic without some deep reason to > do so [there are some; read and understand William Kahan's papers for > these]. > > Jacques