From roman.kraehling at unibw-muenchen.de Tue Jul 3 11:30:59 2007 From: roman.kraehling at unibw-muenchen.de (Rome) Date: Tue Jul 3 11:24:54 2007 Subject: [Haskell] Where's the problem ? Message-ID: <11414756.post@talk.nabble.com> Hi everyone, I write a program for fast online multiplication, this means, leading digits are computed first, so this program is able to handle real numbers. My program and Source-Code is available under http://www.romeinf04.de http://www.romeinf04.de but only with german comments, because this is my master thesis. Now the problem: My program computes using the schoenhage-strassen multi?ply-subroutine the output everytime only until the 32777th Digit, but then it holds without an error message. Windows Task manager tells me CPU Usage 100% and Memory Allocation is increasing. Profiling told me, the function Algorithm.resultOfMult is using this memory. To compute the 32777th digit, my program needs several digits of the input-numbers including the 32800th. I'm using GHC 6.6.1 with option -O2 to compile. Output is row-wise by an IO-function, calling itself recursively with updated parameters, hte output looks like: dig11 dig21 --> res1 dig12 dig22 --> res2 dig12 dig23 --> res3 . . . and so on If I use the Naive-Multiply-Subroutine, the problem occurs at the 16392th digit. I don't have any idea, where the problem might be... Greetings Roman Please excuse my english writing, I'm from Germany. -- View this message in context: http://www.nabble.com/Where%27s-the-problem---tf4019116.html#a11414756 Sent from the Haskell - Haskell mailing list archive at Nabble.com. From roman.kraehling at unibw-muenchen.de Tue Jul 3 14:49:53 2007 From: roman.kraehling at unibw-muenchen.de (Rome) Date: Tue Jul 3 14:43:48 2007 Subject: [Haskell] Where's the problem ? In-Reply-To: <11414756.post@talk.nabble.com> References: <11414756.post@talk.nabble.com> Message-ID: <11418408.post@talk.nabble.com> Rome wrote: > > Hi everyone, > > I write a program for fast online multiplication, this means, leading > digits are computed first, so this program is able to handle real numbers. > > My program and Source-Code is available under > http://www.romeinf04.de http://www.romeinf04.de > > but only with german comments, because this is my master thesis. > > Now the problem: > My program computes using the schoenhage-strassen multi?ply-subroutine the > output everytime only until the 32777th Digit, but then it holds without > an error message. Windows Task manager tells me CPU Usage 100% and Memory > Allocation is increasing. > Profiling told me, the function Algorithm.resultOfMult is using this > memory. > To compute the 32777th digit, my program needs several digits of the > input-numbers including the 32800th. > I'm using GHC 6.6.1 with option -O2 to compile. > > Output is row-wise by an IO-function, calling itself recursively with > updated parameters, hte output looks like: > > dig11 dig21 --> res1 > dig12 dig22 --> res2 > dig12 dig23 --> res3 > . > . > . and so on > > If I use the Naive-Multiply-Subroutine, the problem occurs at the 16392th > digit. > I don't have any idea, where the problem might be... > > Greetings > > Roman > > Please excuse my english writing, I'm from Germany. > > So, a friend of mine compiled it under Linux and got this result: . . . 32779 : 1 1 ---32776--> 0 32780 : 1 0 ---32777--> -1 Main: Ix{Integer}.index: Index (32766) out of range ((0,32765)) Now I know, what i've to look for... -- View this message in context: http://www.nabble.com/Where%27s-the-problem---tf4019116.html#a11418408 Sent from the Haskell - Haskell mailing list archive at Nabble.com. From hbzhu at sei.ecnu.edu.cn Wed Jul 4 22:34:35 2007 From: hbzhu at sei.ecnu.edu.cn (Huibiao Zhu) Date: Wed Jul 4 22:28:39 2007 Subject: [Haskell] TTSS 07 CFP Message-ID: <383602464.04626@webmail.ecnu.edu.cn> 1st International Workshop on Harnessing Theories for Tool Support in Software (TTSS?07) 22-23 September 2007, Macau, China http://www.iist.unu.edu/ttss07 Co-located with ICTAC 2007 The aim of the workshop is to bring together practitioners and researchers from academia, industry and government to present and discuss ideas about: a) How to deal with the complexity of software projects by multi-view modeling and separation of concerns about the design of functionality, interaction, concurrency, and extra-functionality, and b) How to ensure correctness and dependability of software using formal methods and tools of modeling, design, verification and validation into design and development processes and environments The workshop will provide enough time for discussion on problems and research. Each presentation will be 25 minutes followed by 10 minutes discussion. Topics of interest include, but are not limited to, the following areas: ? Mathematical frameworks, methods and tools for model-driven development ? Models, calculus and tool support for component-based and object-oriented software ? rCOS and relational mathematical frameworks of object and component systems and their tool support PAPER SUBMISSION TTSS invites authors to submit original and unpublished work. Submissions should include an abstract, key words, the e-mail address of the corresponding author, and must not exceed 15 pages using ENTCS style. The submission website is http://www.easychair.org/TTSS07 PROCEEDINGS We are talking to ENTCS about the publication of the proceedings, and will consider the publication of a special issue of a journal for selected papers. IMPORTANT DATES ? Submission deadline: 15 July, 2007 ? Notification of acceptance: 15 August 2007 ? Final manuscript due: 1 September 2007 Organized and supported by ECNU and UNU-IIST Program Chairs Geguang Pu ECNU, China Volker Stolz, UNU-IIST, Macau, China Local Organization Chair Volker Stolz, UNU-IIST, Macau, China Program Committee Members Farhad Arbab, CWI, The Netherlands Luis Barbosa, Universidade do Minho, Portugal James C. Browne, UT Austin, US Kung-Kiu Lau, Manchester University, UK Jin Liu, ECNU, China Xiaoshan Li, Macau University, China Markus Lumpe, Iowa State University, USA Zongyan Qiu, Peking University, China Anders P. Ravn, Aalborg University, Denmark Abhik Roychoudhury, NUS, Singapore Bernhard Sch?tz, TU Munich, Germany Heinrich Schmidt, RMIT University, Australia Meng Sun, CWI, The Netherlands Petr Tuma, Charles University, Czech Republic R. Venkatesh, TATA, India Xu Wang, UNU-IIST, Macau, China Ji Wang, NLPDP, China Naijun Zhan, CAS, China Jianhua Zhao, Naijin University, China Gianluigi Zavattaro, University of Bologna, Italy Advisors Patrick Cousot, ENS, France Jifeng He, ECNU, China Mathai Joseph, TATA, India Zhiming Liu, UNU-IIST, Macau, China Bertrand Meyer, ETH, Switzerland Jim Woodcock, University of York, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070705/a1587101/attachment-0001.htm From stefanor at cox.net Fri Jul 6 22:01:53 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Jul 6 21:55:43 2007 Subject: [Haskell] ANN: functorm-1.0 Message-ID: <20070707020153.GA8420@localhost.localdomain> This is the Data.FunctorM module from 6.6's base, deleted from HEAD still used by some projects (notably jhc); this package can be used for compatibility. Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/functorm-1.0 Tarball: http://hackage.haskell.org/packages/archive/functorm/1.0/functorm-1.0.tar.gz Stefan From stefanor at cox.net Sat Jul 7 00:43:45 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Jul 7 00:37:33 2007 Subject: [Haskell] ANN: functorm-1.0.1 Message-ID: <20070707044345.GA16964@localhost.localdomain> This is an update to remove a spurious dependency on the unix package (thanks to Andrea Vezzosi for the quick spot). I had used the vty cabal file as a template but forgot to fix the depenencies. Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/functorm-1.0.1 Tarball: http://hackage.haskell.org/packages/archive/functorm/1.0.1/functorm-1.0.1.tar.gz Darcs: http://members.cox.net/stefanor/functorm Stefan From dan.doel at gmail.com Sat Jul 7 20:55:41 2007 From: dan.doel at gmail.com (Dan Doel) Date: Sat Jul 7 20:47:11 2007 Subject: [Haskell] ANNOUNCE: logict-0.2 Message-ID: <200707072055.41898.dan.doel@gmail.com> Hello all, I've just completed a library adapting the logic programming monad from the "Backtracking, Interleaving, and Terminating Monad Transformers" paper[1] into a format typical of the hierarchical libraries (based on MTL). It uses the two-continuation passing implementation described therein. Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logict-0.2 Tarball: http://hackage.haskell.org/packages/archive/logict/0.2/logict-0.2.tar.gz Feel free to let me know if your find any bugs, or have suggestions. Dan Doel [1]: http://okmij.org/ftp/papers/LogicT.pdf From kili at outback.escape.de Sun Jul 8 13:08:29 2007 From: kili at outback.escape.de (Matthias Kilian) Date: Sun Jul 8 13:03:46 2007 Subject: [Haskell] Cabal, Haddock, and the location of documentation Message-ID: <20070708170829.GA20746@petunia.outback.escape.de> Hi, probably a PEBCAK, but working on updating all our Haskell-related OpenBSD ports, I've currently the problem, that, e.g. for Crypto the Haddock-generated documentation doesn't gets installed where I want it installed ;-) The default obviously is something like $prefix/share/Crypto-$VERSION/doc/html, but I want $prefix/share/doc/Crypto-$VERSION, or, even preferrable, just $prefix/share/doc/Crypto. That's: - $prefix/share/doc as base directory for all documentation, since that's the default on OpenBSD. - no html subdirectory if not strictly necessary, because I don't like a doc directory containing nothing but a html directory. - no version number in the directory name, because typically we don't have different versions of the same software installed at the same time -- there are exceptions from this rule, but I really don't plan to start maintaining several versions of one ore more Haskell packages ;-) Is this configurable at Cabal/Haddock runtime? I'd try to play with --datadir, but this appears a little bit dangerous as a general approach, since some packages my actually come with real data, which should *not* go into $prefix/share/doc, of course. Or do I have to patch Cabal? If so, what about adding just another FilePath like docdir to Distribution.SimpleLocalBuildInfo and use it for the documentation? Ciao, Kili From duncan.coutts at worc.ox.ac.uk Sun Jul 8 13:22:43 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jul 8 13:15:57 2007 Subject: [Haskell] Cabal, Haddock, and the location of documentation In-Reply-To: <20070708170829.GA20746@petunia.outback.escape.de> References: <20070708170829.GA20746@petunia.outback.escape.de> Message-ID: <1183915363.9278.22.camel@localhost> Moving discussion to the cabal-devel@haskell.org list... On Sun, 2007-07-08 at 19:08 +0200, Matthias Kilian wrote: > Hi, > > probably a PEBCAK, but working on updating all our Haskell-related > OpenBSD ports, I've currently the problem, that, e.g. for Crypto > the Haddock-generated documentation doesn't gets installed where I > want it installed ;-) [...] > Is this configurable at Cabal/Haddock runtime? I'd try to play > with --datadir, but this appears a little bit dangerous as a general > approach, since some packages my actually come with real data, which > should *not* go into $prefix/share/doc, of course. Currently the docs do just use --datadir= and --datasubdir= . > Or do I have to patch Cabal? If so, what about adding just another > FilePath like docdir to Distribution.SimpleLocalBuildInfo and use > it for the documentation? I think it'd be perfectly reasonable to follow the lead of autoconf here and have slightly finer grained control with respect to the kinds of files we're installing. Autoconf distinguishes docs (and various kinds of docs, html, ps, pdf, man etc) from the generic datadir. So yes, if you want to extend cabal in this direction I'm happy to review patches. Duncan From igloo at earth.li Sun Jul 8 13:46:55 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 8 13:40:36 2007 Subject: [Haskell] Cabal, Haddock, and the location of documentation In-Reply-To: <1183915363.9278.22.camel@localhost> References: <20070708170829.GA20746@petunia.outback.escape.de> <1183915363.9278.22.camel@localhost> Message-ID: <20070708174655.GA15532@matrix.chaos.earth.li> On Sun, Jul 08, 2007 at 06:22:43PM +0100, Duncan Coutts wrote: > > On Sun, 2007-07-08 at 19:08 +0200, Matthias Kilian wrote: > > > > Or do I have to patch Cabal? If so, what about adding just another > > FilePath like docdir to Distribution.SimpleLocalBuildInfo and use > > it for the documentation? > > I think it'd be perfectly reasonable to follow the lead of autoconf here > and have slightly finer grained control with respect to the kinds of > files we're installing. Autoconf distinguishes docs (and various kinds > of docs, html, ps, pdf, man etc) from the generic datadir. See also: http://hackage.haskell.org/trac/hackage/ticket/140 It would be great for this to get fixed, as I currently have to jump through some hoops to get the docs where I want them in the Debian packages. Thanks Ian From jgbailey at gmail.com Mon Jul 9 18:28:57 2007 From: jgbailey at gmail.com (Justin Bailey) Date: Mon Jul 9 18:22:35 2007 Subject: [Haskell] ANNOUNCE: HCL v1.0 -High-level library for building command line interfaces Message-ID: I'm please to announce HCL 1.0 - a library for building command line interfaces. The library exports a mix of low and high-level functions for building programs which gather simple values, ask yes/no questions, or present hierarchical menus. The library is not intended to do complex, full-screen UIs ala ncurses - it is intended for line-oriented interfaces. Included with the library is a hangman game, so if nothing else you can enjoy that. Where do I get it? ============= Download from Hackage at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HCL-1.0 How do I use it it? ============= It's Cabal-ized so, after downloading and unpacking: runghc Setup.hs configure runghc Setup.hs build runghc Setup.hs install Note I had some inconsistent results building with HEAD cabal, but the version distributed with GHC works great (1.1.6.2). To play hangman, execute 'hangman'. Once installed, you can look at it in GHCi by loading the "HCL" module. Tell me more! ========== This library lets you do a lot of cool things. For example, here's a simple guess a number game: guess_num_fun = do target <- reqIO $ getStdRandom (randomR (1::Integer,100)) let guessed val = case compare target val of GT -> do { reqIO $ putStrLn "Too low!"; return False } LT -> do { reqIO $ putStrLn "Too high!"; return False } EQ -> do { reqIO $ putStrLn "You win!"; return True } reqUntil guessed (prompt "Enter a number between 1 and 100: " reqInteger) "reqUntil" takes a predicate and asks for a response until the predicate is true. In the case above, the user is asked to enter an integer. Once they guess the number, the program ends. The library makes it easy to gather structured values. For example, imagine this data structure: data Taxpayer = Taxpayer { name :: String, age :: Int, ssn :: String } deriving (Read, Show) One way to use HCL to get Taxpayer values from the user is to take advantage of its Read instance: reqTaxpayer :: Request Taxpayer reqTaxpayer = prompt "Please enter tax payer information: " (reqRead reqResp) But that is ugly because the user has to type a "Read"-able string: > getTaxpayer reqTaxpayer Please enter tax payer information: Taxpayer {name="John", age = 30, ssn = "" } However, we can build a form of sorts and make life much easier for the user: reqTaxpayerEasy :: Request Taxpayer reqTaxpayerEasy = do name <- prompt "Please enter the tax payer's name: " reqResp age <- prompt "Please enter their age: " reqInt ssn <- prompt "What is their SSN/ASN: " reqResp return (Taxpayer name age ssn) Which looks like this: > getTaxpayer reqTaxpayerEasy Please enter the tax payer's name: Bob Please enter their age: 50 Please enter their SSN/ASN: 111-11-1111 The library also makes simple hierarchical menus easy to build. The below defines the menu structure for a hypothetical PIM: reqMenu $ reqSubMenu topMenu "Manage contacts" manageContactsMenu $ reqSubMenu topMenu "Manage calendar" (reqMenuItem "Add an event" ... $ ... reqMenuExit "Return to previous menu" reqMenuEnd) $ -- End the menu definition reqMenuEnd -- Defines a partial menu manageContactsMenu = reqMenuItem "Add a contact" ... $ ... reqMenuExit "Return to previous menu" reqMenuEnd These and more examples are distributed with the library in the examples directory. Anything else? =========== Feedback, praise and criticism are welcome. Feedback regarding 'idiomatic' usage is especially desired. This is a first for me so any responses are appreciated. The library was developed on Windows using GHC - please let me know of any odd *nix and Hugs bugs. This library was inspired in part by the Ruby HighLine library (http://highline.rubyforge.org/). Many thanks Mark Jones for his input on HCL's design and implementation. From garrigue at math.nagoya-u.ac.jp Tue Jul 10 08:51:02 2007 From: garrigue at math.nagoya-u.ac.jp (Jacques Garrigue) Date: Tue Jul 10 08:44:51 2007 Subject: [Haskell] CFP: International Symposium on Functional and Logic Programming (FLOPS 2008) Message-ID: <20070710.215102.77063676.garrigue@math.nagoya-u.ac.jp> [We apologize for the multiple postings of this announce] FIRST CALL FOR PAPERS Ninth International Symposium on Functional and Logic Programming (FLOPS 2008) April 14-16, 2008 Ise, Japan Submission deadline: October 10, 2007 http://www.math.nagoya-u.ac.jp/~garrigue/FLOPS2008/ FLOPS is a forum for research on all issues concerning declarative programming, including functional programming and logic programming, and aims to promote cross-fertilization and integration between the two paradigms. Previous FLOPS meetings were held in Fuji Susono (1995), Shonan Village (1996), Kyoto (1998), Tsukuba (1999), Tokyo (2001), Aizu (2002), Nara (2004), and Fuji Susono (2006). TOPICS FLOPS solicits original papers in all areas of functional and logic programming, including (but not limited to): Declarative Pearls: new and excellent declarative programs with illustrative applications; Language issues: language design and constructs, programming methodology, integration of paradigms, interfacing with other languages, type systems, constraints, concurrency and distributed computing; Foundations: logic and semantics, rewrite systems and narrowing, type theory, proof systems; Implementation issues: compilation techniques, memory management, program analysis and transformation, partial evaluation, parallelism; Applications: case studies, real-world applications, graphical user interfaces, Internet applications, XML, databases, formal methods and model checking. The proceedings are expected to be published as an LNCS volume. The proceedings of the previous meeting (FLOPS2006) were published as LNCS 3945. INVITED SPEAKERS To be announced PC CO-CHAIRS Jacques Garrigue (Nagoya, Japan) Manuel Hermenegildo (Madrid, Spain and New Mexico, US) PC MEMBERS Maria Alpuente (Valencia, Spain) Sergio Antoy (Portland, OR, USA) Matthias Blume (TTI, Chicago, USA) Tyng-Ruey Chuang (Academia Sinica, Taiwan) Zhenjiang Hu (Tokyo, Japan) Oleg Kiselyov (FNMOC, Monterey, USA) Herbert Kuchen (Muenster, Germany) Dale Miller (INRIA, Palaiseau, France) Atsushi Ohori (Tohoku, Japan) Enrico Pontelli (New Mexico, USA) Kristoffer Rose (IBM Watson, USA) Kazunori Ueda (Waseda, Japan) Peter Van Roy (Louvain-la-Neuve, Belgium) Benjamin Werner (INRIA, Palaiseau, France) LOCAL CHAIR Shoji Yuen, Nagoya University SUBMISSION Submissions must be unpublished and not submitted for publication elsewhere. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. Submissions should fall into one of the following categories: Regular research papers: they should describe new results and will be judged on originality, correctness, and significance. System descriptions: they should contain a link to a working system and will be judged on originality, usefulness, and design. All submissions must be written in English and can be up to 15 proceedings pages long. Authors are strongly encouraged to use LaTeX2e and the Springer llncs class file, available at http://www.springer.de/comp/lncs/authors.html Regular research papers should be supported by proofs and/or experimental results. In case of lack of space, this supporting information should be made accessible otherwise (e.g. a link to a web page, or an appendix). Submission is Web-based. Please visit the conference site. IMPORTANT DATES Submission deadline: October 10, 2007 Author notification: December 21, 2007 Camera-ready copy: January 21, 2008 Conference: April 14-16, 2008 PLACE Ise, Japan Previous FLOPS: FLOPS 2006, Fuji Susono: http://hagi.is.s.u-tokyo.ac.jp/FLOPS2006/ FLOPS 2004, Nara: http://logic.cs.tsukuba.ac.jp/FLOPS2004/ FLOPS 2002, Aizu: http://www.ipl.t.u-tokyo.ac.jp/FLOPS2002/ FLOPS 2001, Tokyo: http://www.ueda.info.waseda.ac.jp/flops2001/ SPONSOR Japan Society for Software Science and Technology (JSSST) SIG-PPL IN COOPERATION with Asian Association for Foundation of Software (AAFS) (pending) Association for Logic Programming (ALP) INQUIRIES to Jacques Garrigue (garrigue at math.nagoya-u.ac.jp) From doug at cs.dartmouth.edu Thu Jul 12 12:49:51 2007 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu Jul 12 12:43:18 2007 Subject: [Haskell] Power series in a nutshell Message-ID: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> For lovers of things small and beautiful, http://www.cs.dartmouth.edu/~doug/powser.html boils down basic operations on power series with numeric coefficients to the bare minimum--each is a one-liner. Included are overloaded arithmetic operators, integration, differentiation, functional composition, functional inverse and coercion from scalars. --A telling demonstration of the power of lazy evaluation and of Haskell's attunement to math. Doug McIlroy From taralx at gmail.com Thu Jul 12 14:18:35 2007 From: taralx at gmail.com (Taral) Date: Thu Jul 12 14:12:02 2007 Subject: [Haskell] Power series in a nutshell In-Reply-To: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> References: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> Message-ID: On 7/12/07, Doug McIlroy wrote: > http://www.cs.dartmouth.edu/~doug/powser.html Very nice. I would only recommend that you include: scale k f = map (k*) f and have (*) use it. Thanks for your contribution! -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From derek.a.elkins at gmail.com Thu Jul 12 18:05:27 2007 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Jul 12 17:58:56 2007 Subject: [Haskell] Power series in a nutshell In-Reply-To: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> References: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> Message-ID: <1184277927.5368.41.camel@derek-laptop> On Thu, 2007-07-12 at 12:49 -0400, Doug McIlroy wrote: > For lovers of things small and beautiful, > http://www.cs.dartmouth.edu/~doug/powser.html > boils down basic operations on power series with numeric > coefficients to the bare minimum--each is a one-liner. > Included are overloaded arithmetic operators, integration, > differentiation, functional composition, functional inverse > and coercion from scalars. --A telling demonstration of the > power of lazy evaluation and of Haskell's attunement to math. and a link to your earlier Functional Pearl, http://citeseer.ist.psu.edu/mcilroy98power.html From jerzy.karczmarczuk at info.unicaen.fr Thu Jul 12 18:14:24 2007 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Thu Jul 12 18:07:46 2007 Subject: [Haskell] Power series in a nutshell In-Reply-To: <1184277927.5368.41.camel@derek-laptop> References: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> <1184277927.5368.41.camel@derek-laptop> Message-ID: Derek Elkins writes: > Doug McIlroy wrote: >> For lovers of things small and beautiful, >> http://www.cs.dartmouth.edu/~doug/powser.html ... > and a link to your earlier Functional Pearl, > http://citeseer.ist.psu.edu/mcilroy98power.html If somebody is interested in similar manipulations, sometimes a bit more involved, there is a paper (sorry for shameless auto-ad) published more that 10 years ago, copy here: http://users.info.unicaen.fr/~karczma/arpap/lazysem.pdf Jerzy Karczmarczuk From ndmitchell at gmail.com Fri Jul 13 07:19:51 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jul 13 07:13:23 2007 Subject: [Haskell] AngloHaskell 2007, dates and venue confirmed Message-ID: <404396ef0707130419t3834e01co8015a26eaabd538@mail.gmail.com> Hi, We are pleased to announce AngloHaskell 2007 http://www.haskell.org/haskellwiki/AngloHaskell Dates: 10th-11th of August (Friday-Saturday) Location: Cambridge, with talks at Microsoft Research on Friday All the details are on the wiki page, along with free registration. Everyone is invited, we will have a day of talks at MSR, then a day of other activities. There will be plenty of chance for general discussions on anything. If anyone in Cambridge is able to accommodate a few people for the Friday or Saturday night, please add your name to the wiki, and accept our thanks in advance. All that is needed is floor space. Thanks Neil and Philippa From flippa at flippac.org Fri Jul 13 19:53:59 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri Jul 13 19:47:34 2007 Subject: [Haskell] AngloHaskell 2007, dates and venue confirmed In-Reply-To: <404396ef0707130419t3834e01co8015a26eaabd538@mail.gmail.com> References: <404396ef0707130419t3834e01co8015a26eaabd538@mail.gmail.com> Message-ID: On Fri, 13 Jul 2007, Neil Mitchell wrote: > Hi, > > We are pleased to announce AngloHaskell 2007 > > http://www.haskell.org/haskellwiki/AngloHaskell > > Dates: 10th-11th of August (Friday-Saturday) > Location: Cambridge, with talks at Microsoft Research on Friday > Just to add, because I've just been asked this in #anglohaskell: that's the Cambridge in the UK. -- flippa@flippac.org The task of the academic is not to scale great intellectual mountains, but to flatten them. From haskell.vivian.mcphail at gmail.com Sat Jul 14 17:04:16 2007 From: haskell.vivian.mcphail at gmail.com (Vivian McPhail) Date: Sat Jul 14 16:57:36 2007 Subject: [Haskell] (Succ Haskell') `and` $ dependent types Message-ID: <7b03b3c60707141404g7ea25b2bq1ddf825b93643b71@mail.gmail.com> Hello, As the authors point out [1], coal-face time needs to be expended before real world adoption of Dependently-Typed functional programming. But let's get the ball rolling. They say that haskell programmers are normally averse to dependent types. Is this true? It seems to me that one of the appeals of Haskell is the ability to program in a "prove perfect, write once" (elegant) style. Is not dependent typing a good move towards this goal?. It addresses a problem [2] with which we, in our everyday common inter-hominem usage, can deal -- with which (ideal) Haskell should deal. While the major Haskell implementations would require a substantial overhaul, the change at the syntactic level appears to be minimal. There also needs to be advance with respect to programmer development (automatic edit-time inference of (some) types). What are peoples' thoughts on adding dependent types to haskell as a non-incremental evolutionary step? Does the haskell community want to stick with conservative additions to Haskell and a static base, or does the haskell community want to stay in step with the best theoretical developments? Vivian [1] http://www.informatik.uni-bonn.de/~loeh/LambdaPi.html [2] http://thread.gmane.org/gmane.comp.lang.haskell.cafe/21314 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070715/8d4d161e/attachment.htm From stefanor at cox.net Sat Jul 14 17:27:58 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Jul 14 17:21:17 2007 Subject: [Haskell] Re: (Succ Haskell') `and` $ dependent types In-Reply-To: <7b03b3c60707141404g7ea25b2bq1ddf825b93643b71@mail.gmail.com> References: <7b03b3c60707141404g7ea25b2bq1ddf825b93643b71@mail.gmail.com> Message-ID: <20070714212758.GA4146@localhost.localdomain> On Sun, Jul 15, 2007 at 09:04:16AM +1200, Vivian McPhail wrote: > Hello, > > As the authors point out [1], coal-face time needs to be expended before > real world adoption of Dependently-Typed functional programming. But let's > get the ball rolling. They say that haskell programmers are normally > averse > to dependent types. Is this true? It seems to me that one of the appeals > of Haskell is the ability to program in a "prove perfect, write once" > (elegant) style. Is not dependent typing a good move towards this goal?. > It addresses a problem [2] with which we, in our everyday common > inter-hominem usage, can deal -- with which (ideal) Haskell should deal. > > While the major Haskell implementations would require a substantial > overhaul, the change at the syntactic level appears to be minimal. There > also needs to be advance with respect to programmer development (automatic > edit-time inference of (some) types). What are peoples' thoughts on adding > dependent types to haskell as a non-incremental evolutionary step? Does > the > haskell community want to stick with conservative additions to Haskell and > a > static base, or does the haskell community want to stay in step with the > best theoretical developments? > > Vivian > > [1] http://www.informatik.uni-bonn.de/~loeh/LambdaPi.html > [2] http://thread.gmane.org/gmane.comp.lang.haskell.cafe/21314 Dependant types aren't new, they're ten times older than Haskell ;) I don't even think that adding dependant types to Haskell would be that hard. Most of the needed infrastructure (notably the binder rule, lexically scoped type variables, and explicit instantiation) already exists in the implementation of rank-N types in GHC. I think much of the work would be in revising Core (currently it uses a variant of Barandregt's ??, which is strictly less powerful (IIUC) than the full dependant ?C) and flattening the typeinfer/kindinfer staging. Of course, since Haskell is not strongly normalizing, we would not be able to use a calculus where applications of CONV are implicit. Interaction with qualified types (type classes, MPTC, fundeps, implicit parameters, extensible records, associated type synonym equality predicates, etc) could be interesting, in both senses of the word. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20070714/948a6e87/attachment.bin From jvlask at hotmail.com Sat Jul 14 19:45:01 2007 From: jvlask at hotmail.com (John Lask) Date: Sat Jul 14 19:38:28 2007 Subject: [Haskell] Cabal, Haddock, and the location of documentation References: <20070708170829.GA20746@petunia.outback.escape.de> Message-ID: It requires a patch to cabal. I have such a patch. the patch provides an aditional config parameter which will allow you to configure the documentation directory but in absence of any setting will default to old behaviour. the patch is very rough JV. ----- Original Message ----- From: "Matthias Kilian" To: Sent: Monday, July 09, 2007 3:08 AM Subject: [Haskell] Cabal, Haddock, and the location of documentation > Hi, > > probably a PEBCAK, but working on updating all our Haskell-related > OpenBSD ports, I've currently the problem, that, e.g. for Crypto > the Haddock-generated documentation doesn't gets installed where I > want it installed ;-) > > The default obviously is something like > $prefix/share/Crypto-$VERSION/doc/html, > but I want $prefix/share/doc/Crypto-$VERSION, or, even preferrable, just > $prefix/share/doc/Crypto. That's: > > - $prefix/share/doc as base directory for all documentation, since > that's the default on OpenBSD. > > - no html subdirectory if not strictly necessary, because I don't like a > doc directory containing nothing but a html directory. > > - no version number in the directory name, because typically we don't > have different versions of the same software installed at the > same time -- there are exceptions from this rule, but I really > don't plan to start maintaining several versions of one ore more > Haskell packages ;-) > > Is this configurable at Cabal/Haddock runtime? I'd try to play > with --datadir, but this appears a little bit dangerous as a general > approach, since some packages my actually come with real data, which > should *not* go into $prefix/share/doc, of course. > > Or do I have to patch Cabal? If so, what about adding just another > FilePath like docdir to Distribution.SimpleLocalBuildInfo and use > it for the documentation? > > Ciao, > Kili > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From dan.doel at gmail.com Sun Jul 15 06:41:56 2007 From: dan.doel at gmail.com (Dan Doel) Date: Sun Jul 15 06:32:34 2007 Subject: [Haskell] ANNOUNCE: CC-delcont-0.1; Delimited continuations for Haskell Message-ID: <200707150641.56327.dan.doel@gmail.com> Hello, After a bit of hacking, and much documenting, I'm pleased to announce a preliminary release of a delimited continuation library for Haskell. The implementation is drawn from "A Monadic Framework for Delimited Continuations"[1] by Dybvig, Petyon Jones and Sabry, although it has some abstraction available over said implementation (there is both a monad and a transformer; control operations will work interchangeably with either. In addition, all four control operators from "Shift to Control"[2] are implemented). In addition, I have done the adaptation necessary to include the Haskell implementation of the dynamic scoping investigated in "Delimited Dynamic Binding"[3] by Kiselyov, Shan and Sabry, and it has been included. One can think of it as embeddings of the reader or state monads into the delimited control monads (only more flexible). In the future, I'd like to also, possibly, include something like Oleg's generic zippers, and possibly other useful abstractions based on delimited continuations, if I find them. But that's work for another day, I suppose. If you wish to try it out, a package is available on hackage: Page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CC-delcont-0.1 Tabrall: http://hackage.haskell.org/packages/archive/CC-delcont/0.1/CC-delcont-0.1.tar.gz However, I should warn that it's fairly dependent on GHC HEAD at the moment: 1) It uses the Unsafe.Coerce module 2) It uses GADTs to store type class evidence 3) It uses GHC-features that haddock will choke on, so haddock.ghc will be required for docs (and I haven't gotten that working yet to check that the haddock is bug-free), which in turn requires GHC HEAD. 1 & 2 could be relaxed if there's interest. Please feel free to let me know if you find any bugs, or have any suggestions for improvements. I'll follow up this message with a message containing an example program and a discussion thereof. Cheers, Dan Doel 1: http://www.cs.indiana.edu/~sabry/papers/monadicDC.pdf 2: http://www.cs.rutgers.edu/~ccshan/recur/recur.pdf 3: http://okmij.org/ftp/papers/DDBinding.pdf From dan.doel at gmail.com Sun Jul 15 06:57:23 2007 From: dan.doel at gmail.com (Dan Doel) Date: Sun Jul 15 06:47:58 2007 Subject: [Haskell] Re: ANNOUNCE: CC-delcont-0.1; Delimited continuations for Haskell In-Reply-To: <200707150641.56327.dan.doel@gmail.com> References: <200707150641.56327.dan.doel@gmail.com> Message-ID: <200707150657.23859.dan.doel@gmail.com> This is intended as an illustration of how one might use the CC-delcont library, and/or what it might be good for at all. For more, a mailing list search for 'oleg' would likely be fruitful, as this library is heavily derived from the delimited continuation implementation he's used in past mails. Essentially, this is a port of Oleg's 'Incremental, undoable parsing' as seen on the OCaml mailing list. It does lack some of the properties of the OCaml implementation, however (which I'll talk more about later). The original mail is available here: http://caml.inria.fr/pub/ml-archives/caml-list/2007/07/7a34650001bf6876b71c7b1060ac501f.en.html This message is (hopefully) literate haskell, and should be able to be run directly, as long as the CC-delcont library is installed. > {-# OPTIONS_GHC -fglasgow-exts #-} > module Parse where > import Text.ParserCombinators.Parsec > import Control.Monad > import Control.Monad.Trans > import Control.Monad.CC > import Control.Monad.CC.Dynvar ------------ The Inverter ------------ First comes a datatype that is, in some sense, a reification of the act of parsing. Done, of course, means that the parsing is over, and it holds the result of parsing. ReqChar means that the parser is paused, waiting for more input. It holds a position, indicating how many characters it's read so far. > data StreamReq m a where > Done :: Monad m => a -> StreamReq m a > ReqChar :: Monad m => Int -> (Maybe Char -> m (StreamReq m a)) -> StreamReq m a > fromDone :: StreamReq m a -> a > fromDone (Done a) = a > instance Show (StreamReq m a) where > show (Done _) = "Done" > show (ReqChar p _) = "Position: " ++ show p And now comes the magic. toList below takes a function that, given a position in a stream (list), returns the element that should be at that position, and builds such a stream. The important part is that this function works in the context of an arbitrary monad. streamInv is such a "position -> element" function, but when asked for a character, it captures 'the rest of the stream production,' and reifies it into a StreamReq using delimited continuations. This is what allows one to, in essence, get a pointer into 'the act of parsing,' and pass such things around, and even have multiple pointers in play at once. > streamInv :: MonadDelimitedCont p s m => > p (StreamReq m a) -> Int -> m (Maybe Char) > streamInv p pos = shift p (\sk -> return $ ReqChar pos (sk . return)) > toList :: Monad m => (Int -> m (Maybe a)) -> m [a] > toList f = toList' 0 > where > toList' n = f n >>= maybe (return []) (\c -> liftM (c:) $ toList' (n+1)) The following three functions operate on the resumable parsers, either providing input, or telling the parser that there is no more input. Hopefully they're fairly straight forward. > provide :: Monad m => Char -> StreamReq m a -> m (StreamReq m a) > provide _ d@(Done _) = return d > provide c (ReqChar _ f) = f $ Just c > finish :: Monad m => StreamReq m a -> m (StreamReq m a) > finish d@(Done _) = return d > finish (ReqChar _ f) = f Nothing > provideSome :: Monad m => String -> StreamReq m a -> m (StreamReq m a) > provideSome [] s = return s > provideSome (x:xs) s = provide x s >>= provideSome xs The following is sort of a wrapper. It turns a parsing function into a resumable parser. As can be seen, the parser function is pure; you can turn any existing parse function into a resumable parser in this manner. In other words, there's no need to worry about having to go through all your code, putting in delimited continuation constraints on all your functions; no "monad pollution" is involved. > invertParse :: (MonadIO m, MonadDelimitedCont p s m) => > (String -> a) -> m (StreamReq m a) > invertParse parser = reset $ \p -> (Done . parser) > `liftM` toList (streamInv p) ---------- The parser ---------- This is the parser that will be inverted in the example. It reads a sum of several numbers; something like: 1 + 23 + 46 + 59 + 102 and returns the list of numbers to be summed (as an [Integer]). As can be seen, this is just an ordinary Parsec parser. > plus = char '+' >> spaces >> return (++) > number = many1 digit >>= \n -> spaces >> return (read n :: Integer) > total p = p >>= \a -> getInput >>= guard . null >> return a > sump = total $ chainl1 (liftM return number) plus ----- Usage ----- This portion finally makes use of the above stream inversion to interesting effect (I hope). It will repeatedly ask for input to parse, gradually feeding that input into the parser, until a blank line is provided, at which point it assumes the user is finished. However, at each user input, the program stops to see if the input up to that point would have been a successful parse. If so, it saves that partial parser. If, when the user signals the end of input, the parse fails, the program will resume taking input from the last successful parse. The saving of the successful parses is achieved through the use of the dynamically scoped variables also included in this library. They can, essentially, be viewed as more flexible versions of the reader or state monads (depending on whether you use the set operations or not) that can be used within the context of delimited continuation monads. > prompt q p = do liftIO $ print p > liftIO $ putStrLn "(Empty line to stop)" > liftIO $ putStr ": " > l <- liftIO getLine > if null l > then finish p > else saveValid q p >> provideSome l p >>= prompt q > saveValid q p = do p' <- finish p > case p' of > Done (Right _) -> dset q p >> return () > _ -> return () > check _ p@(Done (Right _)) = return p > check q p = do liftIO $ putStrLn "Invalid parse." > liftIO $ putStrLn "Restarting from last good parse." > dupp q (prompt q) >>= check q > main :: IO () > main = runCCT $ do q <- dnew > p <- invertParse (parse sump "Equation") > dlet q p (prompt q p >>= check q > >>= liftIO . print . fromDone) And now for the caveats... If one does some experimentation, he will find that things don't work exactly the same as the OCaml version. For instance, if one tries to emulate the OCaml example exactly, by doing something like (unchecked; I think the code is well-formed): reset (\p -> toList (streamInv p) >>= return . lexer >>= printTokens >> return (Done ())) he'll find that tokens are only printed once a given resumable parser is closed (which may, of course, happen multiple times), and that if he closes multiple parsers from the same source, tokens will be printed for each parser, even over the shared portions. I believe these have the following causes: 1) The delay is due to being highly-sequentialized. Before the lexer and printTokens can do anything, toList has to get the entire list to pass along the monadic pipeline. It can't be produced lazily, because the pieces are being pulled out of monadic computations, which have to be sequenced. 2) The duplication is (possibly) a related matter. One way to solve #1 (I think) would be to parse over a list which incorporated monads. So a cons would have a value at head, and as a tail, a monadic action to produce the rest of the list. If this were used, only enough monadic actions as are needed to produce the output would be performed. If the output of the lexer were produced similarly, the printing could execute in a lazy fashion, and, possibly, the branching caused by the continuation monad could be limited to only the portions of the parse that aren't duplicated. For an example of this sort of idea explored, see "ListT done right" on the wiki: http://haskell.org/haskellwiki/ListT_done_right However, such a solution involves a lot of the monad creep that people tend not to like, and which the above code avoids. The duplication of the output of a printTokens function isn't a big deal; after all, in most cases, one would want to get whole results out of alternate parses, *and then* inspect/print them. However, the over-strictness can be a pain. In fact, it has a direct consequence for the above code, in that parse errors are never detected until an inverted parser is closed. With a lazy list input, the following is well defined: parse sump "Sum" ("1 + 2 - 3" ++ undefined) The result will be a parse error, as the '-' is immediately recognized as a problem. However, if one feeds "1 + 2 - 3" into a resumable parser, it will not recognize that the parse cannot complete, and advance to Done. Instead, it waits until the parser is closed, at which point, it can produce the input list, and get to the parse error. This is one reason that the code above periodically closes the parser, checks for a good parse, and saves the unclosed version if it finds one. However, there are parsers where prefixes of correct input will not themselves parse (consider a parser for something like "1 + 2 + 3 + 4 = 10"; without an '=' and right-hand side of the equation, it's not a correct parse, though it may be a prefix to one), and the above method won't be able to restart as closely to an error as one that, say, saved after each input but resumed when legitimately bad input automatically kicked the parser to Done. Whether this is enough motivation to push monads further into one's data structures, or drop Haskell and go with implicitly monadic code everywhere in OCaml is left as an exercise to the reader. :) Anyhow, I hope I've demonstrated something of interest, and given you a taste of what you can do with this library, and how to do it. There is some more explanation and some elementary examples in the haddock, although due to the code's use of some exotic GHC-isms, haddock.ghc, at the least, will be needed to generate the documentation, and I have yet to get that fully working here, so there may still be bugs in the haddock. Cheers, Dan Doel From ryani.spam at gmail.com Mon Jul 16 20:52:38 2007 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Jul 16 20:45:48 2007 Subject: [Haskell] Power series in a nutshell In-Reply-To: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> References: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> Message-ID: <2f9b2d30707161752g7e529bf7ld99e1434d9a60825@mail.gmail.com> This is really interesting. I love how the typechecker can resolve 1:0:1 (representing (1+x^2)) 1 : 0 : 1 => 1 : 0 : (fromInteger 1 :: [Integer]) => 1 : 0 : (series (fromInteger 1 :: Integer)) => 1 : 0 : (series 1) => 1 : 0 : 1 : repeat 0 (I'm going to go on a bit of a soapbox here...) I feel that Haskell could learn from one of C++'s goals here: provide at least as good support for user-defined-types as for built-in types. Automatic conversion to numeric types via fromInteger could be extended to other types; fromList and fromString could be applied automatically to convert other literals: class LiteralString a where fromString :: String -> a class LiteralList a b where fromList :: [a] -> b From dons at cse.unsw.edu.au Tue Jul 17 01:54:01 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue Jul 17 01:47:14 2007 Subject: [Haskell] ANNOUNCE: Haskell Hackathon 07 II: Freiburg: Oct 5-7 Message-ID: <20070717055401.GA12073@cse.unsw.EDU.AU> ------------------------------------------------------------------------ Hac 2007 II Haskell Hackathon 2007 II October 5-7, 2007 Freiburg, Germany http://haskell.org/haskellwiki/Hac_2007_II ------------------------------------------------------------------------ We are pleased to announce the 2nd Haskell Hackathon for 2007! The event will be held over 3 days, October 5-7 2007, at the University of Freiburg, in Germany, after ICFP. The plan is to hack on serious Haskell infrastructure, tools, libraries and compilers. To attend please register, and get ready to hack those lambdas! Code to hack on: * Hackage * Cabal * Porting foreign libraries * Bug squashing * You decide! At the last Hackathon, in January at Oxford, resulted in: * Cabal, Hackage, Haddock improvements * Data.Binary and DeferedBinary libraries * GHCi debugger improvements * ghc-api interface from Emacs * Crypto lirbary improvments * A native Haskell 'tar' implementation * And more And we hope to be similarly productive this time around. Before you attend, do start thinking and familiarising yourself with 1 or 2 projects you wish to work on, to ensure no wasted effort during the Hackathon. A list of possible projects is available on the website == Registration: We ask that you register you interest. Follow the instructions on the registration page: http://haskell.org/haskellwiki/Hac_2007_II/Register Once you've registered, do add your info to the attendees self-organising page, http://haskell.org/haskellwiki/Hac_2007_II/Attendees if you are looking to share costs, or meet up prior to the hackathon, with other attendees. N.B. if you already expressed interest via the wiki, do confirm by registering `officially' anyway. == Important dates: Hackathon: October 5-7, 2007 == Organisers: Duncan Coutts Ian Lynagh Don Stewart With local arrangements courtesy: Stefan Wehr Phillip Heidegger From v.dijk.bas at gmail.com Tue Jul 17 05:47:08 2007 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue Jul 17 05:40:18 2007 Subject: [Haskell] Power series in a nutshell In-Reply-To: <2f9b2d30707161752g7e529bf7ld99e1434d9a60825@mail.gmail.com> References: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> <2f9b2d30707161752g7e529bf7ld99e1434d9a60825@mail.gmail.com> Message-ID: On 7/17/07, Ryan Ingram wrote: > Automatic conversion to numeric types via fromInteger could be > extended to other types; fromList and fromString could be applied > automatically to convert other literals: > > class LiteralString a where fromString :: String -> a > class LiteralList a b where fromList :: [a] -> b GHC HEAD has support for overloaded String literals. See: http://haskell.org/ghc/dist/current/docs/users_guide/other-type-extensions.html#overloaded-strings regards, Bas van Dijk From g9ks157k at acme.softbase.org Tue Jul 17 09:23:27 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Jul 17 11:12:27 2007 Subject: [Haskell] (Succ Haskell') `and` $ dependent types In-Reply-To: <7b03b3c60707141404g7ea25b2bq1ddf825b93643b71@mail.gmail.com> References: <7b03b3c60707141404g7ea25b2bq1ddf825b93643b71@mail.gmail.com> Message-ID: <200707171523.28110.g9ks157k@acme.softbase.org> Am Samstag, 14. Juli 2007 23:04 schrieb Vivian McPhail: > [?] > They say that haskell programmers are normally averse to dependent types. So I?m far away from being normal. > [?] > What are peoples' thoughts on adding dependent types to haskell as a > non-incremental evolutionary step? I think that a functional language with dependent types is a great thing but I doubt that it is good to extend Haskell in this regard since the presence of bottom is problematic in the context of dependent types. And if you want to use the power of dependent types effectively, you?ll often have to use some kind of specialized editor which removes some of the additional work which is introduced by using dependent types. So I think, it?s more reasonable to improve a system like Epigram to get a system which is applicable to real world problems. > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Jul 17 09:35:33 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Jul 17 11:12:28 2007 Subject: [Haskell] Power series in a nutshell In-Reply-To: References: <200707121649.l6CGnpIp027863@tecumseh.cs.dartmouth.edu> <2f9b2d30707161752g7e529bf7ld99e1434d9a60825@mail.gmail.com> Message-ID: <200707171535.33961.g9ks157k@acme.softbase.org> Am Dienstag, 17. Juli 2007 11:47 schrieb Bas van Dijk: > [?] > GHC HEAD has support for overloaded String literals. See: > > http://haskell.org/ghc/dist/current/docs/users_guide/other-type-extensions. > html#overloaded-strings These are really good news! However, the identifier IsString is problematic. We don?t have classes IsEq, IsOrd and IsNum, so why should there be IsString? Is there any chance that this identifier gets changed at some time? As an aside, the identifier State has a similar problem since the corresponding type is about state transformers, not states. It?s problematic if you want to talk about states and state transformers in your program and you name them both ?state?. In my opinion, we should care that all libraries get cleaned up (not only regarding identifiers) before they become part of a standard ? even if this reduces compatibility. What do others think? > [?] Best wishes, Wolfgang From m at tel.netbeisser.de Wed Jul 18 18:01:13 2007 From: m at tel.netbeisser.de (Marcel Manthe) Date: Wed Jul 18 17:54:18 2007 Subject: [Haskell] Progress in StaticDTD Message-ID: <11678520.post@talk.nabble.com> Hello, in StaticDTD we are moving to complete statical validness against a DTD. For a (compile time) function that uses our generic combinators, we can garuantee the following: - The content model for each element is enforced (this is done by checking a type-level determined finite automaton for each content model) - The attributes are validated (not so their values yet). The check function facilitates a type-level mergesort algorithm. We are using a HList like structure and so these garuantees also hold with higher order functions. The implementation can be found at http://m13s07.vlinux.de/darcs/StaticDTD/v2 It is a mess and all of the infrastructure around it is still missing, but it shows that the concept might work. We hope to have a well-working release in very few months. Some words about related work: - WASH/HTML [1] was the original inspiration for us. It checks proper nesting of elements, but not the content model. It is a HTML, not a 'all DTDs of XML' library - HaXml [2] has two modes: one with generic combinators, which are not type-safe in respect to a DTD, and one where validity is enforced by regex-like Haskell abstract data types. With them, pattern matching can be used. - HSXML [3] has generic combinators and checkes for some nesting-properties. - BinaryNumbers.hs [4] is a great type-level implemention of numeric calculation and we are using it in our library for defining complete order and enumerate the states of a DFA. As a side-effect of our work we hope to put the type-level functions in a small seperate 'type-level programming' library, for common use. Comments are very welcome. Marcel Manthe [1] http://www.informatik.uni-freiburg.de/~thiemann/WASH/#washhtml [2] http://www.cs.york.ac.uk/fp/HaXml/ [3] http://okmij.org/ftp/Scheme/xml.html#typed-SXML [4] http://okmij.org/ftp/Haskell/types.html#binary-arithm -- View this message in context: http://www.nabble.com/Progress-in-StaticDTD-tf4106801.html#a11678520 Sent from the Haskell - Haskell mailing list archive at Nabble.com. From imanolescu at gmail.com Fri Jul 20 08:37:21 2007 From: imanolescu at gmail.com (Ioana Manolescu) Date: Fri Jul 20 08:30:20 2007 Subject: [Haskell] PLAN-X 2008 first call for papers and demos Message-ID: <6ecc70ff0707200537k21cc26c3r1732771b87a4bc6d@mail.gmail.com> Call for Papers and Demos ========================= PLAN-X 2008 --- Programming Language Techniques for XML ACM SIGPLAN Workshop colocated with POPL 2008 San Francisco, California, USA - 9 January 2008 http://gemo.futurs.inria.fr/events/PLANX2008/ The PLAN-X 2008 workshop is the forum to present and discuss bleeding-edge research at the intersection of programming language and data base technology with an emphasis on tree-shaped data structures and their XML representation. Topics of interest are all aspects of XML processing and querying: theories, methodologies, paradigms, language designs, types, analyses, runtime aspects, implementations, tools, applications. This edition of PLAN-X is particularly interested in blending the XML processing approaches developed by the programming languages and data management communities. Expressive power and high performance are among the common goals that these communities pursue. We encourage the submission of crosscutting contributions that apply techniques from one community to problems from the other. The primary criteria for paper selection are originality, relevance, and timeliness to ensure that we can enjoy reports on ongoing and unfinished work with high potential in the workshop. Submissions =========== We seek submissions in two categories * regular papers (10 pages, 30 minutes presentation) * demo papers (4 pages, 10 minutes plenary presentation + 30 minutes slot for individual discussions shared with other demos) For details see the submission instructions on http://gemo.futurs.inria.fr/events/PLANX2008/?page=subm Important Dates =============== Submission deadline 15 October 2007 Notification 30 November 2007 Final papers due 14 December 2007 Program Committee ================= Veronique Benzaken Universit? de Paris-Sud 11, France Alin Deutsch University of California, San Diego, USA Wenfei Fan University of Edinburgh, UK Mary Fernandez ATT Research, USA Haruo Hosoya University of Tokyo, Japan Ralf L?mmel Universit?t Koblenz, Germany Sebastian Maneth National ICT and UNSW, Sydney, Australia Jim Melton Oracle Corporation, USA Michael Schwartzbach University of Aarhus, Denmark J?r?me Vouillon CNRS, France Ioana Manolescu (general chair) Gemo group, INRIA Futurs, France Peter Thiemann (program chair) University of Freiburg, Germany From drl at cs.cmu.edu Mon Jul 23 05:09:01 2007 From: drl at cs.cmu.edu (Dan Licata) Date: Mon Jul 23 05:02:32 2007 Subject: [Haskell] View patterns in GHC: Request for feedback Message-ID: <20070723090900.GA25820@cs.cmu.edu> Hi everyone, Simon PJ and I are implementing view patterns, a way of pattern matching against abstract datatypes, in GHC. Our design is described here: http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns If you have any comments or suggestions about this design, we'd love to hear them. You can respond to this list (and we can take it to haskell-cafe if the thread gets long) or, if you prefer, directly to me. Thanks! -Dan From stefanor at cox.net Mon Jul 23 10:37:18 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Jul 23 10:30:08 2007 Subject: [Haskell] View patterns in GHC: Request for feedback In-Reply-To: <20070723090900.GA25820@cs.cmu.edu> References: <20070723090900.GA25820@cs.cmu.edu> Message-ID: <20070723143718.GB3011@localhost.localdomain> On Mon, Jul 23, 2007 at 05:09:01AM -0400, Dan Licata wrote: > Hi everyone, > > Simon PJ and I are implementing view patterns, a way of pattern matching > against abstract datatypes, in GHC. Our design is described here: > > http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns > > If you have any comments or suggestions about this design, we'd love to > hear them. You can respond to this list (and we can take it to > haskell-cafe if the thread gets long) or, if you prefer, directly to me. Great work! Two comments: 1. It might be better if zenary => used Bool rather than Maybe (). This would allow existing Bool functions to be used as views; eg: foo (isUpper =>) = ... foo ((< 3) =>) = ... foo (ioErrors => (isEOFError =>)) = ... 2. This does introduce another point of infinite lookahead into the grammar. Consider (long text... - after seeing the (, we might be seeing a parenthetized patern (back to pat*) or a expression for a view guard (go to exp). Won't affect implementations that already mix the two (Language.Haskell.Parser, thus probably GHC too). Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20070723/fc2c0fac/attachment.bin From ajb at spamcop.net Mon Jul 23 21:48:58 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Mon Jul 23 21:41:47 2007 Subject: [Haskell] View patterns in GHC: Request for feedback In-Reply-To: <20070723143718.GB3011@localhost.localdomain> References: <20070723090900.GA25820@cs.cmu.edu> <20070723143718.GB3011@localhost.localdomain> Message-ID: <20070723214858.v8ys080osksogks4@webmail.spamcop.net> G'day all. On Mon, Jul 23, 2007 at 05:09:01AM -0400, Dan Licata wrote: > Simon PJ and I are implementing view patterns, a way of pattern matching > against abstract datatypes, in GHC. Our design is described here: > > http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns I have to agree. Great work here, though I'm extremely dubious about the utility of the "Maybe" patterns. One important issue. "We should be able to give clear rules for when the avoidance of repeat computation is guaranteed." This, for me, is a show stopper. I really want to see these "clear rules". Cheers, Andrew Bromage From claus.reinke at talk21.com Tue Jul 24 06:54:31 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Jul 24 06:47:21 2007 Subject: [Haskell] View patterns in GHC: Request for feedback References: <20070723090900.GA25820@cs.cmu.edu><20070723143718.GB3011@localhost.localdomain> <20070723214858.v8ys080osksogks4@webmail.spamcop.net> Message-ID: <004a01c7cde1$04b190f0$2e3f8351@cr3lt> > though I'm extremely dubious about the utility of the "Maybe" patterns. actually, they are the main thing that interests me about view patterns!-) it connects them to the existing work on first-class patterns (where combinators over Maybe patterns do the matching work, and view patterns provide the syntax (a) for integrating Maybe patterns into "dumb" patterns and (b) for binding the results of Maybe patterns to pattern variables). but then, i'd not so much use them as pretend views, but as abstract deconstructors/observers in the unfoldr style. instead of constructing real intermediate types, i'd have the implicit Maybe decide the match and the returned subexpressions available in a tuple for further matching or binding. eg, the first example would become: type Typ unit :: Typ -> Maybe () arrow :: Type -> Maybe (Typ,Typ) size :: Typ -> Integer size (unit -> ()) = 1 size (arrow -> (t1,t2)) = size t1 + size t2 closer to ordinary patterns, with the lowercase and the '->' hinting that there is computation before matching (well, '=>', according to the new proposal). claus From hg.manuel at gmail.com Tue Jul 24 13:56:06 2007 From: hg.manuel at gmail.com (Manuel Hernandez) Date: Tue Jul 24 13:48:58 2007 Subject: [Haskell] View patterns in GHC: Request for feedback In-Reply-To: <004a01c7cde1$04b190f0$2e3f8351@cr3lt> References: <20070723090900.GA25820@cs.cmu.edu> <20070723143718.GB3011@localhost.localdomain> <20070723214858.v8ys080osksogks4@webmail.spamcop.net> <004a01c7cde1$04b190f0$2e3f8351@cr3lt> Message-ID: Dear Haskellers, why is so difficult to define a function to compute the average of a list of numbers?? Warm regards!!! Man -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070724/79afa8b5/attachment.htm From Rene_de_Visser at hotmail.com Tue Jul 24 14:05:13 2007 From: Rene_de_Visser at hotmail.com (Rene de Visser) Date: Tue Jul 24 13:58:16 2007 Subject: [Haskell] Re: View patterns in GHC: Request for feedback References: <20070723090900.GA25820@cs.cmu.edu><20070723143718.GB3011@localhost.localdomain><20070723214858.v8ys080osksogks4@webmail.spamcop.net> <004a01c7cde1$04b190f0$2e3f8351@cr3lt> Message-ID: "Claus Reinke" schrieb im Newsbeitrag news:004a01c7cde1$04b190f0$2e3f8351@cr3lt... >> though I'm extremely dubious about the utility of the "Maybe" patterns. > > actually, they are the main thing that interests me about view patterns!-) > type Typ > > unit :: Typ -> Maybe () > arrow :: Type -> Maybe (Typ,Typ) > size :: Typ -> Integer > size (unit -> ()) = 1 > size (arrow -> (t1,t2)) = size t1 + size t2 > > closer to ordinary patterns, with the lowercase and the '->' hinting > that there is computation before matching (well, '=>', according to > the new proposal). > > claus Though I guess you would not object to: size (unit -> Just ()) = 1 size (arrow -> Just (t1,t2)) = size t1 + size t2 ? Rene. From byorgey at gmail.com Tue Jul 24 14:45:31 2007 From: byorgey at gmail.com (Brent Yorgey) Date: Tue Jul 24 14:38:18 2007 Subject: [Haskell] List averaging function [was: View patterns in GHC: Request for feedback] Message-ID: <22fcbd520707241145i650f3ef7o2ad7295641676847@mail.gmail.com> Hi Man, "Difficult" is a relative term -- with study and practice, what one once considered difficult can become easy. With that said, it is true that beginners to Haskell might find it difficult to define an average function correctly since Haskell is (for good reason) picky about numeric types. If you post some specific code you are having trouble with I'm sure someone would be happy to help you. You can also join the #haskell IRC channel on freenode.net; it is populated by lots of helpful, friendly people who can answer your questions about Haskell in real-time. cheers, -Brent On 7/24/07, Manuel Hernandez wrote: > > Dear Haskellers, > why is so difficult to define a function to compute the average of > a list of > numbers?? > > Warm regards!!! > > Man > > > > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070724/2d932dec/attachment.htm From Andreas-Haskell at gmx.net Tue Jul 24 19:20:09 2007 From: Andreas-Haskell at gmx.net (Andreas Marth) Date: Tue Jul 24 19:18:23 2007 Subject: [Haskell] View patterns in GHC: Request for feedback References: <20070723090900.GA25820@cs.cmu.edu> Message-ID: <047501c7ce49$2f09e2e0$6702a8c0@GPO> I find that the suggested view pattern produce quite obfuscated code! I guess it sets the language barrier quite a bit higher. Do you really think a normal progrogrammer understands: insert x s@(has x -> Just _) = s or: fib (np 2 -> Just n) = fib (n + 1) + fib n or even: fib (np 2 => n) = fib (n + 1) + fib n Do you really know what fun f z [] = z fun f z (x : fun f z -> xs) = x `f` xs means? I find it really hides the most important fact that fun is recursive. (If you didn't recognize fun: it is foldr.) I didn't see 1 convincing excample for the "need" of view pattern in that paper and I didn't read the other proposals. Kind regards Andreas ----- Original Message ----- From: "Dan Licata" To: Sent: Monday, July 23, 2007 11:09 AM Subject: [Haskell] View patterns in GHC: Request for feedback > Hi everyone, > > Simon PJ and I are implementing view patterns, a way of pattern matching > against abstract datatypes, in GHC. Our design is described here: > > http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns > > If you have any comments or suggestions about this design, we'd love to > hear them. You can respond to this list (and we can take it to > haskell-cafe if the thread gets long) or, if you prefer, directly to me. > > Thanks! > -Dan > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From ajb at spamcop.net Tue Jul 24 20:16:53 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Jul 24 20:09:38 2007 Subject: [Haskell] Re: View patterns in GHC: Request for feedback In-Reply-To: References: <20070723090900.GA25820@cs.cmu.edu><20070723143718.GB3011@localhost.localdomain><20070723214858.v8ys080osksogks4@webmail.spamcop.net> <004a01c7cde1$04b190f0$2e3f8351@cr3lt> Message-ID: <20070724201653.itudgks88ccg0ssc@webmail.spamcop.net> G'day all. "Claus Reinke" schrieb im Newsbeitrag news:004a01c7cde1$04b190f0$2e3f8351@cr3lt... > > type Typ > > > > unit :: Typ -> Maybe () > > arrow :: Type -> Maybe (Typ,Typ) > > size :: Typ -> Integer > > size (unit -> ()) = 1 > > size (arrow -> (t1,t2)) = size t1 + size t2 The whole point of a view is that you make views that are semantically useful. data UsefulView = Unit | Arrow Type Type usefulView :: Type -> UsefulView size :: Type -> Integer size (usefulView -> Unit) = 1 size (usefulView -> Arrow t1 t2) = size t1 + size t2 Cheers, Andrew Bromage From Lloyd.Allison at infotech.monash.edu.au Wed Jul 25 04:03:04 2007 From: Lloyd.Allison at infotech.monash.edu.au (Lloyd Allison) Date: Wed Jul 25 03:55:50 2007 Subject: [Haskell] math library for Haskell Message-ID: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> Am I looking in the wrong place (http://haskell.org/ghc/docs/latest/html/libraries/ ) or just not seeing it, but I was hoping there would be a math library for Haskell that would include, e.g., a Gamma function and the like. -L -- From stefanor at cox.net Wed Jul 25 04:16:52 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Jul 25 04:09:43 2007 Subject: [Haskell] math library for Haskell In-Reply-To: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> References: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> Message-ID: <20070725081651.GA20563@localhost.localdomain> On Wed, Jul 25, 2007 at 06:03:04PM +1000, Lloyd Allison wrote: > > Am I looking in the wrong place > (http://haskell.org/ghc/docs/latest/html/libraries/ ) or > just not seeing it, but I was hoping there would be a > math library for Haskell that would include, e.g., > a Gamma function and the like. You're looking in the wrong place; libraries are listed at hackage.haskell.org nowadays. (The other link is just for libraries that come with GHC, an ever-shrinking fraction of the total...) The wiki might also help, http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics. Don't see a gamma function there either, unfortunately. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell/attachments/20070725/dac7de76/attachment.bin From haskell at list.mightyreason.com Wed Jul 25 04:45:18 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Jul 25 04:38:09 2007 Subject: [Haskell] math library for Haskell In-Reply-To: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> References: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> Message-ID: <46A70D9E.7090501@list.mightyreason.com> Lloyd Allison wrote: > Am I looking in the wrong place > (http://haskell.org/ghc/docs/latest/html/libraries/ ) or > just not seeing it, but I was hoping there would be a > math library for Haskell that would include, e.g., > a Gamma function and the like. > > > -L I think the best thing would be to wrap the Gamma function form the GSL: http://www.gnu.org/software/gsl Or add the Gamma wrapper to the Haskell wrapping GSLHaskell at http://dis.um.es/~alberto/GSLHaskell/ Note: Get the darcs version of GSLHaskell. From aruiz at um.es Wed Jul 25 04:59:01 2007 From: aruiz at um.es (Alberto Ruiz) Date: Wed Jul 25 04:51:48 2007 Subject: [Haskell] math library for Haskell In-Reply-To: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> References: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> Message-ID: <200707251059.01311.aruiz@um.es> I have included a binding to gsl_sf_gamma in the darcs repo of GSLHaskell: http://dis.um.es/~alberto/GSLHaskell/doc/GSL-Special.html#v%3Agamma I will try to upload to hackage a recent version of the library in a few days. Alberto On Wednesday 25 July 2007 10:03, Lloyd Allison wrote: > Am I looking in the wrong place > (http://haskell.org/ghc/docs/latest/html/libraries/ ) or > just not seeing it, but I was hoping there would be a > math library for Haskell that would include, e.g., > a Gamma function and the like. > > > -L > -- > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From claus.reinke at talk21.com Wed Jul 25 05:48:42 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jul 25 05:41:30 2007 Subject: [Haskell] Re: View patterns in GHC: Request for feedback References: <20070723090900.GA25820@cs.cmu.edu><20070723143718.GB3011@localhost.localdomain><20070723214858.v8ys080osksogks4@webmail.spamcop.net><004a01c7cde1$04b190f0$2e3f8351@cr3lt> <20070724201653.itudgks88ccg0ssc@webmail.spamcop.net> Message-ID: <004d01c7cea0$fd58e860$49427ad5@cr3lt> > The whole point of a view is that you make views that are semantically > useful. > > data UsefulView = Unit | Arrow Type Type > > usefulView :: Type -> UsefulView > > size :: Type -> Integer > size (usefulView -> Unit) = 1 > size (usefulView -> Arrow t1 t2) = size t1 + size t2 yes, but my point (of view;) was that i was more interested in abstracting over patterns than in creating concrete view types. so, you're interested in views, i'm interested in abstract patterns, and view patterns help with both (each exhaustive set of abstract patterns correspondes to a virtual view), even though they're possibly not the last word on either. claus From drl at cs.cmu.edu Wed Jul 25 06:01:28 2007 From: drl at cs.cmu.edu (Dan Licata) Date: Wed Jul 25 05:54:19 2007 Subject: [Haskell] View patterns in GHC: Request for feedback In-Reply-To: <004a01c7cde1$04b190f0$2e3f8351@cr3lt> References: <20070723214858.v8ys080osksogks4@webmail.spamcop.net> <004a01c7cde1$04b190f0$2e3f8351@cr3lt> Message-ID: <20070725100128.GA30880@cs.cmu.edu> Hi everyone, Thanks for all the helpful feedback! It's great to see what people think. Let me just respond to one point at the moment: I think that the signature > type Typ > > unit :: Typ -> Maybe () > arrow :: Type -> Maybe (Typ,Typ) is *wrong* if what you really mean is > type Typ > > data TypView = Unit | Arrow Typ Typ > view :: Typ -> TypView That is, if what you mean is that every Typ is either Unit or an Arrow *and nothing else* then the latter signature should be preferred, as it makes this fact explicit in the type system. In former signature, it's implicit: you have to say externally that a group of destructors, taken together, define a total view. When programming with the former signature, you always have an extra case to consider, in which all of the destructors fail. The whole point of sum types is that they tell you exactly what cases you have to consider. There's a big difference between the type A and the type A+1, and you should use the type system to track this difference (or else you end up wiht things like null pointer exceptions in Java). To my mind, the syntactic considerations of which way you prefer to write your view patterns should not outweigh this important semantic distinction. -Dan From claus.reinke at talk21.com Wed Jul 25 06:34:39 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jul 25 06:27:27 2007 Subject: [Haskell] View patterns in GHC: Request for feedback References: <20070723214858.v8ys080osksogks4@webmail.spamcop.net><004a01c7cde1$04b190f0$2e3f8351@cr3lt> <20070725100128.GA30880@cs.cmu.edu> Message-ID: <009001c7cea7$68a829e0$49427ad5@cr3lt> > I think that the signature > >> type Typ >> >> unit :: Typ -> Maybe () >> arrow :: Type -> Maybe (Typ,Typ) > > is *wrong* if what you really mean is > >> type Typ >> >> data TypView = Unit | Arrow Typ Typ >> view :: Typ -> TypView different =/= wrong !-) > That is, if what you mean is that every Typ is either Unit or an Arrow > *and nothing else* then the latter signature should be preferred, as it > makes this fact explicit in the type system. but that is not what you're saying there at all! you're saying that -within view 'view' of Typ- Typ is mapped to either Unit or Arrow, if the mapping is successfull. there can be other views of Typ, and the types do not guarantee that 'view' itself is exhaustive over Typ (there can be variants of Typ that 'view' fails to map to TypView). in the abstract deconstructor variant, this partiality is explicit in the types, in the concrete view type variant, it is hidden from the types, implicit in the implementation of 'view'. > In former signature, it's implicit: you have to say externally that a group > of destructors, taken together, define a total view. When programming > with the former signature, you always have an extra case to consider, > in which all of the destructors fail. even with concrete view types, you still have to consider the case that the mapping into that view type can be partial or non-exhaustive (if you add a constructor to Typ, but forget to update 'view', the type system will not complain, and matches over TypView will still be 'exhaustive'..). > The whole point of sum types is that they tell you exactly what cases > you have to consider. There's a big difference between the type A and > the type A+1, and you should use the type system to track this > difference (or else you end up wiht things like null pointer exceptions > in Java). one should also be careful not to expect more from a type than it can deliver, and not to use A when dealing with A+1. btw, it might be useful to permit association of abstract types with abstract deconstructors, so that an extended abstract type (export) declaration somewhat like type Typ as unit -> () | arrow -> (Typ,Typ) tells us (and the compiler) that the abstract patterns in the size function are exhaustive (or at least as exhaustive as clients of the abstract type Typ are supposed to be). the proof obligation would be on the exporter of the abstract type, and any pattern match failures relating to this should be reported as view failures. doing so would declare a virtual view type, similar to the concrete view types used in other examples, so there might be several 'as' clauses for a single abstract type, declaring separate sets of exhaustive abstract deconstructors. claus From haskell at list.mightyreason.com Wed Jul 25 06:39:10 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Wed Jul 25 06:32:02 2007 Subject: [Haskell] math library for Haskell In-Reply-To: <200707251059.01311.aruiz@um.es> References: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> <200707251059.01311.aruiz@um.es> Message-ID: <46A7284E.9020604@list.mightyreason.com> Alberto Ruiz wrote: > I have included a binding to gsl_sf_gamma in the darcs repo of GSLHaskell: > > http://dis.um.es/~alberto/GSLHaskell/doc/GSL-Special.html#v%3Agamma > > I will try to upload to hackage a recent version of the library in a few days. > > Alberto It occurs to me that generating the binding for all the GSL "Special" functions by hand may be labor intensive. Would it be reasonable to have a (perhaps customized) tool generate the wrapping code? I am interested since I just ported various data processing from Mathematica to GSL plus C code. (At the moment much of what I use (e.g. interpolation) is not in the GSL wrapper). Cheers, Chris Kuklewicz From gwright at comcast.net Wed Jul 25 06:52:57 2007 From: gwright at comcast.net (Gregory Wright) Date: Wed Jul 25 06:46:04 2007 Subject: [Haskell] math library for Haskell In-Reply-To: <46A7284E.9020604@list.mightyreason.com> References: <200707250803.l6P834ra017551@nexus.csse.monash.edu.au> <200707251059.01311.aruiz@um.es> <46A7284E.9020604@list.mightyreason.com> Message-ID: <61E9B1D2-9BC8-482E-A7C7-4A4EE151250C@comcast.net> On Jul 25, 2007, at 6:39 AM, Chris Kuklewicz wrote: > Alberto Ruiz wrote: >> I have included a binding to gsl_sf_gamma in the darcs repo of >> GSLHaskell: >> http://dis.um.es/~alberto/GSLHaskell/doc/GSL-Special.html#v%3Agamma >> I will try to upload to hackage a recent version of the library in >> a few days. >> Alberto > > It occurs to me that generating the binding for all the GSL > "Special" functions by hand may be labor intensive. Would it be > reasonable to have a (perhaps customized) tool generate the > wrapping code? > I have some functions that make wrapping the GSL special functions much simpler. I've used them to wrap all of the Airy and Bessel functions. The process could be automated, but there are a few more cases than convenient. (For example, the computationally expensive functions take an additional argument specifying how much precision is desired.) It wouldn't be too much work to automate the most common cases (double arg, double return and double arg, error struct return); perhaps doing the remainder by hand is reasonable. I also have bindings for all of the ODE integration routines and all of the numerical differentiation routines. All are low level, just exposing the underlying GSL routines without any "convenience wrapper". I can make them available if anyone is interested. Best Wishes, Greg From ajb at spamcop.net Wed Jul 25 07:21:35 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Jul 25 07:14:22 2007 Subject: [Haskell] View patterns in GHC: Request for feedback In-Reply-To: <009001c7cea7$68a829e0$49427ad5@cr3lt> References: <20070723214858.v8ys080osksogks4@webmail.spamcop.net><004a01c7cde1$04b190f0$2e3f8351@cr3lt> <20070725100128.GA30880@cs.cmu.edu> <009001c7cea7$68a829e0$49427ad5@cr3lt> Message-ID: <20070725072135.fbnc74s8ws0ogwck@webmail.spamcop.net> G'day all. Quoting Claus Reinke : > different =/= wrong !-) [...] > but that is not what you're saying there at all! you're saying that -within > view 'view' of Typ- Typ is mapped to either Unit or Arrow, if the mapping > is successfull. there can be other views of Typ, and the types do not > guarantee that 'view' itself is exhaustive over Typ (there can be variants > of Typ that 'view' fails to map to TypView). data TypView = Unit | Arrow Typ Typ | Other I still vote for "wrong". :-) The problem, and we've been through this before, is that it's very tempting to use types like Maybe because it's there, when it's better replaced with a custom algebraic data type. Even probably 90% of uses of Bool are better replaced with a two-element enumerated type. I see a lot of things like this: data Something = Something { ... leftHanded :: Bool ... } Where this is safer, more expressive, more future-proof and more meaningful: data Handedness = LeftHanded | RightHanded data Something = Something { ... handedness :: Handedness ... } > even with concrete view types, you still have to consider the case that > the mapping into that view type can be partial or non-exhaustive (if you > add a constructor to Typ, but forget to update 'view', the type system > will not complain, and matches over TypView will still be 'exhaustive'..). There should be a compiler warning you can turn on in the implementation of "view" which tells you if the pattern matching is exhaustive or not. Cheers, Andrew Bromage From claus.reinke at talk21.com Wed Jul 25 09:39:53 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Jul 25 09:32:38 2007 Subject: [Haskell] View patterns in GHC: Request for feedback References: <20070723214858.v8ys080osksogks4@webmail.spamcop.net><004a01c7cde1$04b190f0$2e3f8351@cr3lt><20070725100128.GA30880@cs.cmu.edu><009001c7cea7$68a829e0$49427ad5@cr3lt> <20070725072135.fbnc74s8ws0ogwck@webmail.spamcop.net> Message-ID: <00c201c7cec1$48f7d540$49427ad5@cr3lt> > The problem, and we've been through this before, is that it's very > tempting to use types like Maybe because it's there, when it's better > replaced with a custom algebraic data type. i'm sure we have, and others before us. i was just arguing that one is not necessarily better than the other. i'm not using Maybe because its there, i tend to use Monad, so my code would work on either Maybe or your custom type, if they both implement the interface that allows me to encode and capture failure (and i need that interface, because i want to program with patterns and match failure in ways not hardcoded into the language syntax). of course, you might say that we shouldn't use Monad just because it is there, and that we should always define our own, more descriptive class with the same semantics?-) having descriptively named types is fine, but unless you really want to emphasize and verify that your Maybe is different from all other Maybes (in which case a newtype + deriving might be more suitable than a completely separate type), using Maybe encodes (by convention) the intended semantics, thus making code easier to comprehend. the question, i guess, is whether you want to communicate to readers of your code that your type is like Maybe, but distinguishable, or that it is an entirely new type, with some similarities to Maybe. specific names have to be offset against reuse of general understanding, but language features for combining both exist (if not as widely supported as they could be; nor as expressive as one might want, eg. one can rename constructors for expressions, but not deconstructors for patterns, which is why Connor keeps asking for pattern synonyms, or why i'd like to use view patterns for abstract deconstructors, with those funny Maybes behind the scenes..). claus From grelck at isp.uni-luebeck.de Wed Jul 25 15:45:25 2007 From: grelck at isp.uni-luebeck.de (Clemens Grelck) Date: Wed Jul 25 15:38:13 2007 Subject: [Haskell] KPS'07: Einladung zum Kolloquium Programmiersprachen Message-ID: <46A7A855.7030107@isp.uni-luebeck.de> Our sincere apologies to all non German speaking readers of this mailing list for this workshop invitation in German. ====================================================================== Einladung zur Teilnahme KPS'07 Kolloquium Programmiersprachen und Grundlagen der Programmierung Timmendorfer Strand 10.-12. Oktober 2007 Anmeldeschluss: 1. August 2007 http://www.isp.uni-luebeck.de/kps07 Liebe Kollegen, das 14. Kolloquium Programmiersprachen und Grundlagen der Programmierung setzt eine traditionelle Reihe von Arbeitstagungen fort, die 1980 von den Forschungsgruppen der Professoren Friedrich L. Bauer (TU M?nchen), Klaus Indermark (RWTH Aachen) und Hans Langmaack (CAU Kiel) ins Leben gerufen wurde. Heute pr?sentiert sich die Veranstaltung allen interessierten deutschsprachigen Wissenschaftlern als ein offenes Forum zum zwanglosen Austausch neuer Ideen und Ergebnisse aus den Forschungsbereichen Programmiersprachen sowie Grundlagen des Programmierens. Wir w?rden uns freuen, Sie als Teilnehmer des 14. Kolloquiums Programmiersprachen und Grundlagen der Programmierung vom 10. bis zum 12. Oktober 2007 im Hotel Atlantis in Timmendorfer Strand an der Ostsee begr??en zu k?nnen. Mit besten W?nschen Dr. Annette St?mpel und Dr. Clemens Grelck Institut f?r Softwaretechnik und Programmiersprachen Universit?t zu L?beck http://www.isp.uni-luebeck.de From b.hilken at ntlworld.com Thu Jul 26 17:14:06 2007 From: b.hilken at ntlworld.com (Barney Hilken) Date: Thu Jul 26 17:06:53 2007 Subject: [Haskell] View patterns in GHC: Request for feedback In-Reply-To: <20070723090900.GA25820@cs.cmu.edu> References: <20070723090900.GA25820@cs.cmu.edu> Message-ID: I think you should add the form: (function -> pattern) @ pattern as well. The reason you don't need general 'pattern @ pattern' with normal patterns is that, if anything is going to match, the two patterns must have the same outermost constructor, so you can push the @ inside. This doesn't hold for view patterns, and you might well want to match against several views. Of course you can do this with 'both', but the readability is terrible, especially if you want to match against more than two patterns. Nested 'both' gets extremely long, or do you want to define 'allThree', 'allFour', ... The reason I think this might be important is that you could use view patterns for records: (label1 -> x)@(label2 -> y)@(label3 -> z) ... gives a reasonable syntax for a record pattern, and it would be compatible with any form of extensible records. Barney. From himself at poczta.nom.pl Fri Jul 27 15:53:05 2007 From: himself at poczta.nom.pl (Andrzej Jaworski) Date: Fri Jul 27 14:45:32 2007 Subject: [Haskell] Nirvana Message-ID: <004801c7d087$e72d5a60$5b66ce57@bzdryk> Hi, I guess most of you have already watched this laughing contest: http://download.microsoft.com/download/c/d/2/cd213f37-2a1d-4b79-80a6-fc82978bf69b/Meijer_Peyton-Jone s_Language_MSRCam2007.wmv It offers first hand information that the usefulness of Haskell as programming language amounts exactly to 0. This is a big surprise for me. On the contrary, I think Haskell has been getting too expressive at the expense of fundamental issues left neglected like relatively weak module system. But here up comes another surprise - this complex fancy but pragmatic sugar developed to support human reasoning was selected to manage alien low level environment. Yet another shock comes form worshiping C, C#, Java as perpetually useful. So, it seems Okasaki wrote for an alternative world. This is becoming incomprehensible for me and I shall retreat to mathematics. But perhaps my impressions could stir up some useful discussion here, as I have great sympathy for you guys:-) Best regards, -Andrzej From taralx at gmail.com Fri Jul 27 15:12:55 2007 From: taralx at gmail.com (Taral) Date: Fri Jul 27 15:05:31 2007 Subject: [Haskell] Nirvana In-Reply-To: <004801c7d087$e72d5a60$5b66ce57@bzdryk> References: <004801c7d087$e72d5a60$5b66ce57@bzdryk> Message-ID: On 7/27/07, Andrzej Jaworski wrote: > It offers first hand information that the usefulness of Haskell as programming language amounts > exactly to 0. This is a big surprise for me. On the contrary, I think Haskell has been getting too > expressive at the expense of fundamental issues left neglected like relatively weak module system. I think you very much misunderstood what was being said. What Simon appears to say (in my opinion, admittedly) is that Haskell pre-IO was not useful. By adding selective unsafeness (IO, unsafe* functions), Haskell is made into a significantly more useful programming language. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From duncan.coutts at worc.ox.ac.uk Fri Jul 27 15:20:57 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jul 27 15:12:59 2007 Subject: [Haskell] ANNOUNCE: Gtk2Hs version 0.9.12 released Message-ID: <1185564057.29694.159.camel@localhost> Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.12 is now available from: http://haskell.org/gtk2hs/download/ The source tarball and an installer for Windows are available. Packages for various platforms should become available soon, hopefully including Debian, Fedora, Gentoo, FreeBSD and Darwin. Changes since 0.9.11: * ps, pdf and svg cairo backends are now supported * drag & drop support added * can run mainGUI in GHCi after :reload * Graphics.SOE.Gtk now works with threaded rts and GHCi * Windows build now includes OpenGL and SourceView packages * c2hs no longer chokes on some system headers (eg glibc-2.4) * various bug fixes and minor code cleanups * major overhaul of the code generator (will help binding Gtk+ 2.10) Gtk2Hs feature highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.8 API * support for several additional Gtk+/Gnome modules: * Glade visual GUI builder * cairo vector graphics library * SVG rendering for cairo * OpenGL extension (works with HOpenGL) * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * an implementation of the Graphics.SOE API * extensive haddock API reference documentation * multi-platform support with native look * LGPL licence Platforms and requirements: * builds from source on Linux, Windows, MacOS X, FreeBSD and Solaris * builds with GHC 6.2 - 6.6.1 * works with Gtk+ version 2.0 through to 2.10 * SVG support requires librsvg version 2.16 or later Please report all problems to gtk2hs-devel@sourceforge.net Contributions and feedback are also most welcome. Windows release notes: The installer expects GHC 6.6.1. As always if you need a build for a different version of GHC then that's possible by building from source. The windows build now includes the gtkglext and sourceview packages, but not svgcairo as that has pretty heavy dependencies. This makes the download a bit bigger, but on the other hand currently it includes support for only one GHC version, so overall the installer is rather smaller than in the last release. Duncan (on behalf of the Gtk2Hs team) From sebastian.sylvan at gmail.com Fri Jul 27 15:23:54 2007 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Fri Jul 27 15:16:31 2007 Subject: [Haskell] Nirvana In-Reply-To: References: <004801c7d087$e72d5a60$5b66ce57@bzdryk> Message-ID: <3d96ac180707271223n51252933oafe390b066f817fe@mail.gmail.com> On 27/07/07, Taral wrote: > On 7/27/07, Andrzej Jaworski wrote: > > It offers first hand information that the usefulness of Haskell as programming language amounts > > exactly to 0. This is a big surprise for me. On the contrary, I think Haskell has been getting too > > expressive at the expense of fundamental issues left neglected like relatively weak module system. > > I think you very much misunderstood what was being said. What Simon > appears to say (in my opinion, admittedly) is that Haskell pre-IO was > not useful. By adding selective unsafeness (IO, unsafe* functions), > Haskell is made into a significantly more useful programming language. Exactly. As I understand it, he's saying that the C style of languages and Haskell are trying to approach the same goal from two different, somewhat orthogonal, directions. Haskell by starting pure and doing what they can to make it pragmatic without destroying any nice properties. The imperative languages are doing it by starting unsafe/unproductive and "useful" and trying to make it less unsafe/unproductive (often by borrowing from languages like Haskell, but general non-FP-specific features like garbage collection certainly comes to mind)... So I think he's saying that Haskell, with monads for IO, ST, STM, and concurrency, and FFI etc. *is* very useful and securely located in the realm of practical feasibility for most projects, but that it arrived at this position from a different starting point. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 From knomenet at gmail.com Fri Jul 27 17:23:41 2007 From: knomenet at gmail.com (Michael Speer) Date: Fri Jul 27 17:16:18 2007 Subject: [Haskell] Irrefutable patterns allowing mutually dependent functions. In-Reply-To: <314e9ce40707271419v38fc493wae62b471ee38f965@mail.gmail.com> References: <314e9ce40707271419v38fc493wae62b471ee38f965@mail.gmail.com> Message-ID: <314e9ce40707271423m6d4ccb25u87e9bab94c890219@mail.gmail.com> Some time ago I wrote to this list linking to a regular expression engine I was writing in order to learn the Haskell programming language. I had noted the ability to send a single functions output into it as the its input and had tried using this property of the language in a rather winding way to transform a string regular expression into an integer based array of rules approximating DFAs. At the time I just smashed the stack as mutually dependent functions called one another recursively, each depending on the output of the other to execute. I didn't know a way around this, or even if Haskell provided a way around this. Yesterday a link from reddit to a site concerning `irrefutable patterns` caused me to jump back to the code and see if they allowed for what I wanted. They did. The working code can be found here : http://rx-haskell.googlecode.com/svn/trunk/rx.hs The link goes to a simple regular expression matcher a little under 200 lines long that can accept a regex string with operands (*), (*?), (?), (??), (+) and grouping using parenthesis. I hope to update the code with bracketed ranges and things soon. Any comments, questions, or criticisms from the list would be highly appreciated. - Michael Speer . From jgoerzen at complete.org Sun Jul 29 00:24:53 2007 From: jgoerzen at complete.org (John Goerzen) Date: Sun Jul 29 00:17:41 2007 Subject: [Haskell] ANN: hpodder 1.0.0 Message-ID: <200707282324.53954.jgoerzen@complete.org> Hi, I'm pleased to announce version 1.0.0 of hpodder, the command-line podcatcher (podcast downloader) that just happens to be written in everyone's favorite language. You can get it from: http://software.complete.org/hpodder Version 1.0.0 sports a new mechanism for detecting and disabling feeds or episodes that repeatedly result in errors, updates to the Sqlite database schema, and several bugfixes. -- John From heron_carvalho at bol.com.br Sun Jul 29 23:19:07 2007 From: heron_carvalho at bol.com.br (heron_carvalho) Date: Sun Jul 29 23:11:40 2007 Subject: [Haskell] Call for Submissions - First Workshop on Languages and Tools for Parallel and Distributed Programming (LTPD 2007) Message-ID: ------------------------------------------------------------ First Workshop on Languages and Tools for Parallel and Distributed Programming (LTPD 2007) http://computacao.ucpel.tche.br/ltpd/ Gramado, RS - Brazil Co-located with SBAC-PAD 2007 (24-27 October 2007) *** Submiss?o de artigos: 24 de Agosto *** ------------------------------------------------------------ The objective of this workshop is to bring together researchers working on the design and implementation of programming languages, tools and techniques for distributed, parallel and mobile programming. Submitted papers should present original research that is unpublished and not submitted elsewhere. We encourage the submission of work in progress, especially by MSc and PhD students. We plan to provide a friendly environment where researchers can discuss current and future trends in programming languages for parallel and distributed programming. Papers can be written in English, Portuguese and Spanish. Papers should have 4 pages, following the IEEE Computer Society Proceedings Manuscript Formatting Guidelines. All accepted papers will be published in the On-Line conference proceedings, and as a technical report. The SBAC-PAD organization will also publish the electronic proceedings in CD. We plan to publish selected high quality papers from the proceedings in a local brazilian journal. At least one author of an accepted paper must attend the workshop and all workshop attendees must be registered to SBAC-PAD. Topics of Interest ------ -- -------- Topics of interest include, but are not limited to: * Programming Multi-Core Machines * Coordination Languages * Concurrent and Parallel Garbage Collection * Type systems and semantics for parallel, distributed and mobile languages * Declarative parallel, distributed and mobile languages * Languages for mobile and ubiquitous computing * Calculi for Mobility and Concurrency * Design Patterns * Distributed Objects * Distributed Component Models * Mobile Agents Languages * Software issues for multicore or multithreaded processors Important Dates --------- ----- * Deadline for paper submission: August 24, 2007 * Accepted Papers Notification: September 10, 2007 * Camera-Ready Submission: September 17, 2007 Organizing Committee ---------- --------- Andr? Rauber Du Bois (Chair) - UCPel Francisco Heron de Carvalho Junior (Chair)- UFC Program Committe ------- -------- Adenauer Correa Yammin - UCPel Alcides Calsavara - PUCPR ?lvaro Freitas Moreira - UFRGS Andr? Rauber Du Bois - UCPel Andr? Santos - UFPE Claudio Fernando Resin Geyer - UFRGS Cristiano Vasconcellos - UFPel Francisco Heron De Carvalho Jr - UFC Hans-Wolfgang Loidl - LMU, Germany Iara Augustin - UFSM Jorge Luis Victoria Barbosa - Unisinos Marco T?lio de Oliveira Valente - PUC-MG Phil Trinder - Heriot-Watt University, UK Rafael Dueire Lins - UFPE Ricardo Corr?a - UFC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070730/f1e0683f/attachment.htm From bulat.ziganshin at gmail.com Mon Jul 30 03:40:09 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Jul 30 03:58:44 2007 Subject: [Haskell] Haskell->Erlang compiler, sort of Message-ID: <1115451216.20070730114009@gmail.com> Hello haskell, http://blog.tornkvist.org/?id=1185571582964040 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From flippa at flippac.org Mon Jul 30 16:28:20 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Mon Jul 30 16:21:10 2007 Subject: [Haskell] Latest AngloHaskell news and a request Message-ID: Two pieces of news regarding AngloHaskell: 1) We've been offered WiFi access at Microsoft Research for any attendees who want it. We'll need a name, email address and company/institution affiliation where appropriate - see wiki for details. 2) We're being given lunch on Friday! Finally, a request: We're a little short on crashspace, and I suspect this is affecting who's able to show up. Could people who can only make it with crashspace (or who can only make one day without) add their names on the wiki? Is there anyone in the area able to offer people at least some space on a floor? Last year we had offers early, and I think this helped get plans moving. For those who could use the reminder, the wiki page is at http://www.haskell.org/haskellwiki/AngloHaskell Many thanks, and I hope to see you there! -- flippa@flippac.org Society does not owe people jobs. Society owes it to itself to find people jobs. From eijiro.sumii at gmail.com Tue Jul 31 00:51:41 2007 From: eijiro.sumii at gmail.com (Eijiro Sumii) Date: Tue Jul 31 00:44:08 2007 Subject: [Haskell] APLAS 2007 call for poster presentations (Singapore, Nov 29 - Dec 1) Message-ID: <20070731.135141.102769425.sumii@ecei.tohoku.ac.jp> CALL FOR POSTER PRESENTATIONS The Fifth ASIAN Symposium on Programming Languages and Systems (APLAS 2007) November 29 - December 1, 2007 Singapore http://flint.cs.yale.edu/aplas2007/ APLAS 2007 will include a poster session during the conference. The session aims to give students and researchers an opportunity to present their research to the community, and to get responses from other researchers. SCOPE: Poster presentations are sought in all areas of programming languages and systems, including (but not limited to): - semantics, logics, foundational theory - type systems, language design - program analysis, optimization, transformation - software security, safety, verification - compiler systems, interpreters, abstract machines - domain-specific languages and systems - programming tools and environments FORMAT: A space of A1 paper size (594 mm wide and 841 mm high) will be provided for each presentation. If you need more space, contact the poster chair (sumii AT ecei DOT tohoku DOT ac DOT jp). To prepare a good poster, search the Web for "poster presentation" and you will find many useful resources. REGISTRATION: Each presenter should e-mail a 1-2 page abstract in PDF or PostScript (including the title, authors, affiliations, and a summary of the work) to the poster chair (sumii AT ecei DOT tohoku DOT ac DOT jp) by September 14th, 2007. The program of the poster session will be announced by September 21st, 2007. We hope to accommodate every poster, but may restrict presentations (based on relevance and interest to the community) due to space constraints. IMPORTANT DATES: 1-2 page abstract September 14, 2007 notification September 21, 2007 conference November 29 - December 1, 2007 CONTACT: For questions or requests, please contact the APLAS 2007 poster chair, Eijiro Sumii (sumii AT ecei DOT tohoku DOT ac DOT jp). From simonpj at microsoft.com Tue Jul 31 04:24:25 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 31 04:16:50 2007 Subject: [Haskell] 3-yr post for language person Message-ID: Tim Griffin is advertising a 3-year research associate position at the Cambridge Computer Lab, working on a project that seeks to design and implement a meta-language for the specification and implementation of correct Internet routing protocols. He says "A PL person would be perfect". Details here: http://www.admin.cam.ac.uk/offices/personnel/jobs/vacancies.cgi?job=2114 Simon From conal at conal.net Tue Jul 31 15:08:45 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jul 31 15:01:08 2007 Subject: [Haskell] type class instance selection & search Message-ID: I keep running into situations in which I want more powerful search in selecting type class instances. One example I raised in June, in which all of the following instances are useful. > instance (Functor g, Functor f) => Functor (O g f) where > fmap h (O gf) = O (fmap (fmap h) gf) > instance (Cofunctor g, Cofunctor f) => Functor (O g f) where > fmap h (O gf) = O (cofmap (cofmap h) gf) > instance (Functor g, Cofunctor f) => Cofunctor (O g f) where > cofmap h (O gf) = O (fmap (cofmap h) gf) > instance (Cofunctor g, Functor f) => Cofunctor (O g f) where > cofmap h (O gf) = O (cofmap (fmap h) gf) My understanding is that this sort of instance collection doesn't work together because instance selection is based only on the matching the head of an instance declaration (part after the "=>"). I'm wondering why not use the preconditions as well, via a Prolog-like, backward-chaining search for much more flexible instance selection? Going further, has anyone investigated using Prolog as a model for instance selection? Better yet, how about LambdaProlog ( http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which generalizes from Horn clauses to (higher-order) hereditary Harrop formulas, including (restricted but powerful) universals, implication, and existentials? Once search is in there, ambiguity can arise, but perhaps the compiler could signal an error in that case (i.e., if the ambiguity is not eliminated by further search pruning). My motivation: I've been playing with a programming style in which my type formulation leads to automatic construction of much of the code, thanks to use of Functor, Applicative, Monoid, and type composition. An example is http://haskell.org/haskellwiki/Applicative_data-driven_programming, and I'm trying now to do the same to create a much simpler implementation of Eros ( http://conal.net/papers/Eros). I think this programming style is what Conor was alluding to recently as "types don't just contain data, types explain data" (http://article.gmane.org/gmane.comp.lang.haskell.cafe/26520). (Conor: I hope you chime in.) My hunch is that this programming style tends to run up against the head-only instance matching mechanism and would work much better with a more powerful means of selecting instances. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070731/143c1ee8/attachment.htm From ccshan at post.harvard.edu Tue Jul 31 17:51:51 2007 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Tue Jul 31 17:52:18 2007 Subject: [Haskell] Re: type class instance selection & search References: Message-ID: Conal Elliott wrote in article in gmane.comp.lang.haskell.general: > I keep running into situations in which I want more powerful search in > selecting type class instances. I agree that it's quite useful for instance search to backtrack, if not desirable in all cases. Proof search is program search, after all. Of course, allowing undecidable instances, we can build backtracking into instance search ourselves by representing the state of a backtracking machine as a type. http://okmij.org/ftp/Haskell/poly2.txt -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig And if thou gaze into the abyss, the abyss...actually finds you pretty creepy. From conal at conal.net Tue Jul 31 19:05:09 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jul 31 18:57:33 2007 Subject: [Haskell] Re: type class instance selection & search In-Reply-To: References: Message-ID: Thanks for these pointers, Ken. And belated thanks to Oleg for his reply in June. Impressive tricks! Perhaps I'm not the only person who'd prefer a more straightforward formulation of backtracking search? Cheers, - Conal On 7/31/07, Chung-chieh Shan wrote: > > Conal Elliott wrote in article < > ea8ae9fb0707311208j9f3fcf7m92bef8f54aea3dd8@mail.gmail.com> in > gmane.comp.lang.haskell.general: > > I keep running into situations in which I want more powerful search in > > selecting type class instances. > > I agree that it's quite useful for instance search to backtrack, if not > desirable in all cases. Proof search is program search, after all. > > Of course, allowing undecidable instances, we can build backtracking > into instance search ourselves by representing the state of a > backtracking machine as a type. http://okmij.org/ftp/Haskell/poly2.txt > > -- > Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig > And if thou gaze into the abyss, the abyss...actually finds you pretty > creepy. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070731/41710788/attachment-0001.htm From conal at conal.net Tue Jul 31 19:12:57 2007 From: conal at conal.net (Conal Elliott) Date: Tue Jul 31 19:05:20 2007 Subject: [Haskell] Re: type class instance selection & search In-Reply-To: References: Message-ID: Here are some other instances that could work with backward chaining: \begin{code} instance Monad m => Applicative m where pure = return (<*>) = ap instance (Applicative f, Monoid a) => Monoid (f a) where mempty = pure mempty mappend = liftA2 mappend instance (Applicative f, Num a) => Num (f a) where (+) = liftA2 (+) fromInteger = pure . fromInteger -- etc \end{code} Currently, I place such instance declarations in comments as boilerplate to be instantiated manually. - Conal On 7/31/07, Conal Elliott wrote: > > I keep running into situations in which I want more powerful search in > selecting type class instances. One example I raised in June, in which all > of the following instances are useful. > > > instance (Functor g, Functor f) => Functor (O g f) where > > fmap h (O gf) = O (fmap (fmap h) gf) > > > instance (Cofunctor g, Cofunctor f) => Functor (O g f) where > > fmap h (O gf) = O (cofmap (cofmap h) gf) > > > instance (Functor g, Cofunctor f) => Cofunctor (O g f) where > > cofmap h (O gf) = O (fmap (cofmap h) gf) > > > instance (Cofunctor g, Functor f) => Cofunctor (O g f) where > > cofmap h (O gf) = O (cofmap (fmap h) gf) > > My understanding is that this sort of instance collection doesn't work > together because instance selection is based only on the matching the head > of an instance declaration (part after the "=>"). I'm wondering why not use > the preconditions as well, via a Prolog-like, backward-chaining search for > much more flexible instance selection? Going further, has anyone > investigated using Prolog as a model for instance selection? Better yet, > how about LambdaProlog ( > http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which > generalizes from Horn clauses to (higher-order) hereditary Harrop formulas, > including (restricted but powerful) universals, implication, and > existentials? Once search is in there, ambiguity can arise, but perhaps the > compiler could signal an error in that case ( i.e., if the ambiguity is > not eliminated by further search pruning). > > My motivation: I've been playing with a programming style in which my type > formulation leads to automatic construction of much of the code, thanks to > use of Functor, Applicative, Monoid, and type composition. An example is > http://haskell.org/haskellwiki/Applicative_data-driven_programming, and > I'm trying now to do the same to create a much simpler implementation of > Eros ( http://conal.net/papers/Eros). I think this programming style is > what Conor was alluding to recently as "types don't just contain data, types > explain data" (http://article.gmane.org/gmane.comp.lang.haskell.cafe/26520). > (Conor: I hope you chime in.) My hunch is that this programming style tends > to run up against the head-only instance matching mechanism and would work > much better with a more powerful means of selecting instances. > > - Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell/attachments/20070731/1b14327c/attachment.htm From mutjida at gmail.com Tue Jul 31 23:18:29 2007 From: mutjida at gmail.com (jeff p) Date: Tue Jul 31 23:10:52 2007 Subject: [Haskell] Re: type class instance selection & search In-Reply-To: References: Message-ID: Hello, > > My understanding is that this sort of instance collection doesn't work > together because instance selection is based only on the matching the head > of an instance declaration (part after the "=>"). I'm wondering why not use > the preconditions as well, via a Prolog-like, backward-chaining search for > much more flexible instance selection? Going further, has anyone > investigated using Prolog as a model for instance selection? > I have also wanted more powerful, Prolog-like search for instance selection; it would be particularly convenient to think of type variables as logic variables. I think the main argument against this is that it fundamentally changes the interpretation of constraints; in particular, if you really used a Prolog-style search, the order in which you place constraints can affect type checking. Is there a sensible way for instance selection to depend on the "body" which doesn't result in this? >Better yet, > how about LambdaProlog ( > http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), > which generalizes from Horn clauses to (higher-order) hereditary Harrop > formulas, including (restricted but powerful) universals, implication, and > existentials? > Having hereditary Harrop formulas at the type level would be cool. It would also probably require type level lambdas. There was a recent discussion about type level lambdas in Haskell which ended with the observations that 1) it would mess up unification (i.e. make it undecidable and/or too hard) to have explicit type level lambdas; and 2) they are already implicitly there (this was pointed out by Oleg) since one can define a type level application and type level functions. I think 1) is a bit of a cop-out since you could always restrict to pattern unification (L-lamda unification) which is decidable and has MGUs. 2) is true, but these implicit lambdas don't play very well with instance selection and require that all reductions are spelled out via an Apply type class. I think it might be useful/interesting to have type level lambdas, and pattern unification, even without turning instance selection into proof search. >Once search is in there, ambiguity can arise, but perhaps the > compiler could signal an error in that case ( i.e., if the ambiguity is not > eliminated by further search pruning). > This seems like a slippery slope to me. Although I would like having a full fledged (higher-order) logic programming language in which to write type level programs, I am not sure it's a good idea for Haskell in general. I tend to get concerned when type class constraints get too big/complicated to be obviously correct-- what good is the type checker saying something satisfies a constraint if we're not sure that the specification of the constraint itself is correct? -Jeff From jbapple+haskell at gmail.com Tue Jul 31 23:58:27 2007 From: jbapple+haskell at gmail.com (Jim Apple) Date: Tue Jul 31 23:50:49 2007 Subject: [Haskell] Type Lambdas in Gofer Message-ID: The code in "Bananas in Space: Extending Fold and Unfold to Exponential Types" http://citeseer.ist.psu.edu/293490.html mirror: http://www.cs.nott.ac.uk/~gmh/bananas.pdf uses Gofer, and has examples such as data Rec f = In (f (Rec f)) type P f a = f (Rec f, a) mapP :: Functor f => (a -> b) -> P f a -> P f b mapP g = fmap (\(x,a) -> (x, g a)) instance Functor f => Functor (P f) where fmap = mapP Why did Gofer have this power while Haskell does not? Jim