October 2005 - Haskell

Read Instances for Data.Map and Data.Set
by Georg Martius 21 Oct '05

21 Oct '05

Hi folks, I was really annoyed by the fact that for Data.Map and Data.Set are no Read instances declared, but Show instances are! I believe there should be some kind of unwritten rule that in the standart lib the Show and Read instances come pairwise and are fully compatible. Anyway since there was no response to S. Alexander Jacobson post [1], I decided to write these instances at least for GHC in the style of the other instances in GHC.Read. For the {a,b,...} syntax I have used a modified version of @list@ from GHC.Read Is there a chance of having this in the libs? Cheers, Georg [1] http://www.haskell.org//pipermail/haskell/2005-February/015380.html import qualified Data.Map as Map import qualified Data.Set as Set import Text.Read import qualified Text.Read.Lex as L import GHC.Read instance (Ord k, Read k, Read e) => Read (Map.Map k e) where readPrec = do elements <- set (readPair readPrec readPrec) return $ Map.fromList elements -- ^ @(readPrec p1 p2)@ parses a pair of things with the syntax @a:=b@ -- where @a@ is parsed by @p1@, -- and @b@ is parsed by @p2@ readPair :: ReadPrec a -> ReadPrec b -> ReadPrec (a,b) readPair reada readb = do a <- reset reada L.Symbol ":=" <- lexP b <- reset readb return (a,b) instance (Ord a, Read a) => Read (Set.Set a) where readPrec = do elements <- set (readPrec) return $ Set.fromList elements set :: ReadPrec a -> ReadPrec [a] -- ^ @(set p)@ parses a list of things parsed by @p@, -- using the curly-braces syntax. set readx = parens ( do L.Punc "{" <- lexP (setRest False +++ setNext) ) where setRest started = do L.Punc c <- lexP case c of "}" -> return [] "," | started -> setNext _ -> pfail setNext = do x <- reset readx xs <- setRest True return (x:xs) -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net ---------

5 5

TFP2006: call for papers
by Henrik Nilsson 21 Oct '05

21 Oct '05

Apologies for multiple copies. /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn(a)cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. TFP 2006 Seventh Symposium on Trends in Functional Programming Nottingham, UK, 19 - 21 April, 2006 http://www.cs.nott.ac.uk/~nhn/TFP2006 Co-located with Types 2006 CALL FOR PAPERS The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best papers presented at the symposium for publication in a high-profile volume. TFP 2006 is going to be held in Nottingham, UK, 19 - 21 April. Note that this is significantly earlier in the year than past TFPs that generally were held in August - September. TFP 2006 is co-located with Types 2006 (18 - 21 April). Previous TFP symposia were held in Scotland in 2002 and 2003, as successors to the successful series of Scottish Functional Programming Workshops, in Munich, Germany in 2004, and in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE). For further general information about TFP, see http://www.tifp.org/. SCOPE OF THE SYMPOSIUM The Symposium recognises that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five categories of paper. High-quality papers are solicited in any of these categories: Research Papers: leading-edge, previously unpublished research work Position Papers: on what new trends should or should not be Project Papers: descriptions of recently started new projects Evaluation Papers: what lessons can be drawn from a finished project Overview Papers: summarising work with respect to a trendy subject Papers must be original, and not submitted for simultaneous publication in any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Also applications of functional programming techniques to other languages may be considered. Papers on the following subject areas are particularly welcome: o dependently typed functional programming o validation and verification of functional programs o debugging for functional languages o functional programming and security o functional programming and mobility o functional programming and formally motivated computing o functional languages for telecommunications applications o functional languages for embedded systems o functional programming applied to global computing o functional GRIDs o functional languages for reasoning about imperative/object-oriented programs o interoperability with imperative programming languages o any new emerging trend in the functional programming area If you are in doubt on whether your paper is within the scope of TFP, please contact the TFP 2006 program chair, Henrik Nilsson, nhn(a)cs.nott.ac.uk. BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. To acknowledge this, a prize for the best student paper is awarded each year. CO-LOCATION WITH TYPES 2006 TFP 2006 is co-located with Types 2006 (to be held 18 - 21 April). To take advantage of the synergies offered by these two complementary events, we will invite a number of joint keynote speakers, hold joint sessions on topics of mutual interest, such as dependently typed functional programming, and run common social events. The schedule will be arranged so that participants may freely move between parallel sessions of the two events. SUBMISSION Acceptance to the symposium will be based upon extended abstracts of between 6 and 10 pages. Accepted abstracts are to be completed to full papers before the symposium for publication in the local symposium proceedings. Important dates: Deadline for abstract submission: 17 February, 2006 Notification of acceptance: 27 February, 2006 Registration deadline: 17 March, 2006 Camera-ready copy of full paper: 24 March, 2006 The submission must clearly indicate to which category it belongs: research, position, project, evaluation or overview paper. It should also indicate whether the main author or authors are research students. Abstracts and full papers must be written in English. Papers for the symposium proceedings must adhere to the formatting instructions using the provided on the TFP 2006 site. Papers must not exceed 16 pages; papers in some categories may comprise considerably fewer pages. POST SYMPOSIUM REFEREEING AND PUBLICATION In addition to the local symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. Revised papers will be refereed after the symposium to the normal conference standards and a subset of the best papers over all categories will be selected for publication. Papers will be judged on their contribution to the research area, with appropriate criteria applied to each category of paper. Papers submitted for publication by Intellect must follow formatting and any other instructions provided by the Programme Chair. For TFP 2005, in order to enhance the quality of student submissions, a process where student papers were given extra feedback was tried out. A similar process might be put in place for this TFP, contingent on the outcome of that trial. ORGANISATION Symposium Chair: Marko van Eekelen, Radboud University Nijmegen, NL Programme Chair: Henrik Nilsson, University of Nottingham, UK Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Joel Wright, University of Nottingham, UK PROGRAMME COMMITTEE: The programme committee is currently being assembled. The current members of the TFP Advisory Committee are: o Sharon Curtis, Oxford Brookes University o Gaetan Hains, Université d'Orléans o John Hughes, Chalmers University o Kevin Hammond, University of St Andrews o Hans-Wolfgang Loidl, Ludwig-Maximilians-Universität München o Rita Loogen, Philipps-Universität Marburg o Greg Michaelson, Heriot-Watt University o John O'Donnell, University of Glasgow o Ricardo Pena, Universidad Complutense de Madrid, o Phil Trinder, Heriot-Watt University o Marko van Eekelen, University of Nijmegen SPONSORS We are actively looking for additional TFP sponsors, who may help to subsidise attendance by research students, for example. If you or your organisation might be willing to sponsor TFP, or if you know someone who might be willing to do so, please do not hesitate to contact the Symposium chair: Marko van Eekelen. Your students will be grateful!

1 0

FM'06: CFP
by event＠mail.in.tu-clausthal.de 21 Oct '05

21 Oct '05

========================================================================= FM'06: 14TH INTERNATIONAL SYMPOSIUM ON FORMAL METHODS 21 - 27 August 2006 McMaster University, Hamilton, Ontario, Canada http://fm06.mcmaster.ca/ ANNOUNCEMENT AND CALL FOR SUBMISSIONS FM'06 is the fourteenth in a series of symposia organized by Formal Methods Europe, http://www.fmeurope.org, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. The symposia have been notably successful in bringing together innovators and practitioners in precise mathematical methods for software development, industrial users as well as researchers. Submissions are welcomed in the form of original papers on research and industrial experience, proposals for workshops and tutorials, entries for the exhibition of software tools and projects, and reports on ongoing doctoral work. FM'06 welcomes all aspects of formal methods research, both theoretical and practical. We are particularly interested in the experience of applying formal methods in practice. The broad topics of interest of this conference are: * Tools for formal methods: tool support and software engineering, environments for formal methods. * Theoretical foundations: specification and modelling, refining, static analysis, model-checking, verification, calculation, reusable domain theories. * Formal methods in practice: experience with introducing formal methods in industry, case studies. * Role of formal methods: formal methods in hardware and system design, method integration, development process. TECHNICAL PAPERS Full papers should be submitted via the web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Accepted papers will be published in the Symposium Proceedings, to appear in Springer's Lecture Notes in Computer Science series, http://www.springeronline.com/lncs . Submitted papers should have not been submitted elsewhere for publication, should be in Springer's format, (see Springer's web site), and should not exceed 16 pages including appendices. A prize for the best technical paper will be awarded at the symposium. INDUSTRIAL USAGE REPORTS One day will be dedicated to sharing the experience -- both positive and negative -- with using formal methods in industrial environments. The Industry Day is organized by ForTIA, the Formal Techniques Industry Association, http://www.fortia.org . This year's Industry Day investigates the use of formal methods in security and trust. Invited papers on organizational and technical issues will be presented. Inquiries should be directed to the Industry Day Chairs; see the web site for details. WORKSHOPS We welcome proposals for one-day or one-and-a-half-day workshops related to FM'06. In particular, but not exclusively, we encourage proposals for workshops on various application domains. Proposals should be directed to the Workshop Chair. TUTORIALS We are soliciting proposals for full-day or half-day tutorials. The tutorial contents can be selected from a wide range of topics that reflect the conference themes and provide clear utility to practitioners. Each proposal will be evaluated on importance, relevance, timeliness, audience appeal and past experience and qualification of the instructors. Proposals should be directed to the Tutorial Chair. POSTER AND TOOL EXHIBITION An exhibition of both research projects and commercial tools will accompany the technical symposium, with the opportunity of holding scheduled presentations of commercial tools. Proposals should be directed to the Poster and Tools Exhibition Chair. DOCTORAL SYMPOSIUM For the first time, FM'06 will feature a doctoral symposium. Students are invited to submit work in progress and to defend it in front of "friendly examiners". Participation for students who are accepted will be subsidized. Submissions should be directed to the Doctoral Symposium Chair. SUBMISSION DATES Technical Papers, Workshops, Tutorials: Friday, February 24, 2006 Posters and Tools, Doctoral Symposium: Friday, May 26, 2006 NOTIFICATION DATES Technical Papers: Friday, April 28, 2006 Workshops, Tutorials: Friday, March 10, 2006 Posters and Tools, Doctoral Symposium: Friday, June 9, 2006 ORGANIZATION General Chair: Emil Sekerinski (McMaster) Program Chairs: Jayadev Misra (U. Texas, Austin), Tobias Nipkow (TU Munich) Workshop Chair: Tom Maibaum (McMaster) Tutorial Chair: Jin Song Dong (NUS) Tools and Poster Exhibition Chair: Marsha Chechik (U. Toronto) Industry Day Chairs: Volkmar Lotz (SAP France), Asuman Suenbuel (SAP US) Doctoral Symposium Chair: Augusto Sampaio (U. Pernambuco) Sponsorship Chair: Juergen Dingel (Queens U.) PROGRAM COMMITTEE Jean-Raymond Abrial (ETH Zurich) Alex Aiken (Stanford U.) Keijiro Araki (Kyushu U.) Ralph Back (Abo Akademi) Gilles Barthe (INRIA) David Basin (ETH Zurich) Ed Brinksma (U. Twente) Michael Butler (U. Southampton) Rance Cleaveland (U. Stony Brook) Jorge Cuellar (Siemens) Werner Damm (U. Oldenburg) Frank de Boer (U. Utrecht) Javier Esparza (U. Stuttgart) Jose Fiadeiro (U. Leicester) Susanne Graf (VERIMAG) Ian Hayes (U. Queensland) Gerard Holzmann (JPL) Cliff Jones (U. Newcastle) Gary T. Leavens (Iowa State U.) Rustan Leino (Microsoft) Xavier Leroy (INRIA) Dominique Mery (LORIA) Carroll Morgan (UNSW) David Naumann (Stevens) E.-R. Olderog (U. Oldenburg) Paritosh Pandya (TIFR) Sriram Rajamani (Microsoft) John Rushby (SRI) Steve Schneider (U. Surrey) Vitaly Shmatikov (U. Texas, Austin) Bernhard Steffen (U. Dortmund) P.S. Thiagarajan (NUS) Axel van Lamsweerde (U. Louvain) Martin Wirsing (LMU Munich) Pierre Wolper (U. Liege) LOCAL ORGANIZATION Publicity: Wolfram Kahl, Alan Wassyng, Jeff Zucker Tools, Posters, Book Exhibition: Spencer Smith Social Events: Ridha Khedri Local Arrangements:: William Farmer, Mark Lawford Events Co-ordinator: Ryszard Janicki ------------------------------------------------------------------------ This e-mail was delivered to you by event(a)in.tu-clausthal.de, what is a moderated list runned by Computational Intelligence Group of Clausthal University of Technology, Germany. All event announcements sent through this list are also listed in our conference planner at http://cig.in.tu-clausthal.de/index.php?id=planner. In the case of any requests, questions, or comments, do not hesitate and contact event-owner(a)in.tu-clausthal.de ASAP. ****************************************************** * CIG does not take any responsibility for validity * * of content of messages sent through this list. * ****************************************************** Computational Intelligence Group Department of Computer Science Clausthal University of Technology Germany http://cig.in.tu-clausthal.de/

1 0

CFP: CICLing-2006 -- Computational Linguistics, Springer LNCS, February, Mexico -- one week reminder
by Alexander Gelbukh 19 Oct '05

19 Oct '05

CICLing-2006 7th International Conference on Intelligent Text Processing and Computational Linguistics February 19-25, 2006 Mexico City, Mexico Endorsed by the ACL www.CICLing.org/2006 PUBLICATION: LNCS: Springer Lecture Notes in Computer Science. SUBMISSION DEADLINE: Abstract: October 17, late submissions can be considered; Main text: October 24, 2005 (for registered abstracts). MODALITIES: Full paper: 12 pages, short paper: 4 pages. KEYNOTE SPEAKERS: Nancy Ide, Rada Mihalcea, 2 more to be announced, see website. EXCURSIONS: Ancient pyramids, Monarch butterflies, great cave and colonial city, and more. All tentative. See photos on www.CICLing.org. AWARDS: Best paper, best presentation, best poster, best demo. +------------------------------------------------------- | Topics +------------------------------------------------------- Computational linguistics research: Comp. Linguistics theories and formalisms, Knowledge representation, Comp. morphology, syntax, semantics, Discourse models, Machine translation, text generation, Statistical methods, corpus linguistics, Lexical resources; Intelligent text processing and applications: Information retrieval, question answering, Information extraction, Text mining, Document categorization and clustering, Automatic summarization, Natural language interfaces, Spell-checking; and all related topics. +------------------------------------------------------- | Schedule (tentative) +------------------------------------------------------- Sunday, Wednesday, Saturday: full-day excursions; Monday, Tuesday, Thursday, Friday: talks; Monday: Welcome party & poster session. See website. ==================================================== See complete CFP and contact on www.CICLing.org/2006 ==================================================== We send you this CFP in good faith of its usefulness for you. If you do not want to receive any new messages, please let us know replying to this message. We deeply apologize for any inconvenience.

1 0

RE: [Haskell] Excessive sharing and GHC
by Simon Peyton-Jones 19 Oct '05

19 Oct '05

| > >I was thinking it would be nice if one could put a pragma on CAFs that | > >basically made ghc treat them as WHNF so it would float them inward as | > >far as possible including inside lambdas. in particular, constant | > >strings that are created (cheaply) from efficient internal | > >representations should not be held onto in their inefficient form. I think the way to do this is to explain to GHC that unpackCString :: String# -> [Char] is a "cheap" function; that is, applications of it can safely be duplicated. There's no pragma to do this to an arbitrary at present, but it'd be a sensible sort of pragma to have. I wonder if it would make any difference in practice. Simon

1 0

RE: [Haskell] reader-like IO, parents of threads
by Simon Marlow 18 Oct '05

18 Oct '05

It seems that you can do this as long as you provide your own version of forkIO, but not if you want to use the built-in forkIO. One could argue that getting the parent ThreadId is something that should be supported natively by forkIO, and I might be inlined to agree. Unfortunately there are some subtleties: currently a ThreadId is represented by a pointer to the thread itself, which causes the thread to be kept alive. This has implications not only for space leaks, but also for reporting deadlock: if you have a ThreadId for a thread, you can send it an exception with throwTo at any time, and hence the runtime can never determine that the thread is deadlocked so it will never get the NonTermination exception. Perhaps we need two kinds of ThreadId: a weak one for use in Maps, and a strong one that you can use with throwTo. But then building a Map in which some elements can be garbage collected is a bit tricky (it can be done though; see our old Memo table implementation in fptools/hslibs/util/Memo.hs). Cheers, Simon On 16 October 2005 20:53, Frederik Eaton wrote: > John Meacham suggested that I should be a little more clear about the > semantics I'm seeking. Also, apparently it isn't possible to implement > writeTLRef/modifyTLRef with the data structure I gave: > >> data TLRef a = TLR a (MVar (Map ThreadId a)) > (the first argument is a default value, the second is a map storing > the values in each thread. The MVar is for safe concurrent access) > > Without those functions, it looks a little more like the Reader monad > I'm comparing it to. > > - What happens on fork? The child thread effectively gets a "copy" of > each TLRef in its parent. They have the same values, but modifying > them using withTLRef has no effect on the values in other threads. > > - Can you pass a TLRef to a different thread? Yes, but the value it > holds will not be the same when it is dereferenced in a different > thread. > > The problem with writeTLRef is that if a child thread looks up the > default value for an unbound reference by looking up the value in its > parent, but after calling forkIO the parent changes the value with > writeTLRef, then the child thread will get the wrong value. It is > supposed to only see the value which was stored in the reference at > the point where forkIO was called. > > Also, for this reason, I think withTLRef would have to be implemented > by creating a separate thread with forkIO and waiting for it to > finish. This would avoid overwriting a value which other child threads > might still need to access. > > Note that an e.g. "myParentThreadId" function isn't enough - what is > needed is a > > parentThreadId :: ThreadId -> IO (Maybe ThreadId) > > which can look up the parent of an arbitrary thread. > > Alternatively, if 'forkIO' supported hooks to run before and/or after > forking, then a 'parentThreadId' function could be implemented from > that. > > Frederik > > On Sun, Oct 16, 2005 at 04:40:40AM -0700, Frederik Eaton wrote: >> Hi, >> >> I'm trying to get MonadReader-like functionality in the IO monad. It >> doesn't appear possible implement it with the interfaces that >> Haskell98 or GHC provide. I'm looking for something like >> "thread-local variables". The interface could be something like this: >> >> newTLRef :: a -> IO (TLRef a) >> withTLRef :: TLRef a -> a -> IO b -> IO b >> readTLRef :: TLRef a -> IO a >> writeTLRef :: TLRef a -> a -> IO () >> modifyTLRef :: TLRef a -> (a -> a) -> IO () >> >> This would have a lot of uses. I am aware of the "Implicit >> Configurations" paper by Kiselyov and Shan, but a solution such as >> theirs which requires modifying the type signatures of all >> intermediate function calls is not suitable. I want to be able to say >> "run algorithm A using database D" without requiring all of the >> functions in algorithm A to know that databases are somehow involved. >> One way to look at it is that I am seeking something like the >> type-based approach, but easier and with less explicit syntax; >> another way to look at it is that I am seeking something like a >> global IORef based approach, but more safe. >> >> An implementation based on ThreadId-keyed maps is almost workable: >> >> data TLRef a = TLR a (MVar (Map ThreadId a)) >> >> The problem with this is that while it is possible to find out the >> ThreadId of the current thread, it doesn't appear to be possible to >> get the ThreadId of the parent thread, which would be needed for >> values to be properly inherited. >> >> Is there a way around this? Will there ever be standard support for >> either finding the thread id of the parent of the current thread, or >> for something like the thread-local references I have proposed? >> >> Thanks, >> >> Frederik >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell >> > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

3 2

RE: [Haskell] Excessive sharing and GHC
by Simon Peyton-Jones 18 Oct '05

18 Oct '05

| Clearly, in this instance GHC is not transforming either of these | definitions into the other. But are there other compile time transformations | performed by GHC that might result in more (excessive) sharing, in | particular the creation of new common sub-expressions such as pxs? If not, | is that a deliberate design decision? GHC tries not to create space leaks, but does not guarantee not to. In particular, the full laziness transformation is so beneficial most of the time that, even though it can create a space leak GHC still does it (unless you turn it off with a flag). GHC only does very limited common sub-expression elimination, which again is very beneficial usually but can have bad behaviour. It's not general CSE which is why it didn't kick in in the program you gave. | Since I guess the "excessive" bit of excessive sharing probably can't be | determined until run-time, would it be practical for the run-time system to | do something about it? For example, once the run-time system notices that | the graph size has breached a certain threshold it begins to decouple | references to "reduced" but bulky sections of the graph, forcing them to be | recomputed (from the original expression) at a later time. I don't know anyone who has tried to make this work. Sounds pretty tricky. Simon

3 3

Haskell Weekly News: October 18, 2005
by John Goerzen 18 Oct '05

18 Oct '05

Haskell Weekly News: October 18, 2005 Greetings, and thanks for reading the 12th issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * Decimal arithmetic library. Jeremy Shaw [3]announced the "premature release" of his new Decimal arithmetic library, which is designed for cases where binary floating point is not acceptable, such as money. 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8734 * JRegex. John Meacham [4]announced JRegex, a library that interfaces to both PCRE and Posix regular expressions. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12340 * Haskell XML Toolbox 5.3. Uwe Schmidt [5]announced version 5.3 of the Haskell XML Toolbox. The main changes in this release are improvements to the arrow system. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/12271 Requests for Participation Future Haskell Standard. Isaac Jones [6]posted a request for participation in the formation of the next standardized version of Haskell. 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8646 HCAR Clarification. Last week's HWN story on the Haskell Communities & Activities Report (HCAR) had some misleading wording. Participation in this report is open to all, and submissions are encouraged from everyone. Discussion Haskell mentioned on Slashdot. Haskell was [7]mention on Slashdot. The post was refering to [8]an article about optimizing development for fun and had [9]pugs as its example. 7. http://developers.slashdot.org/article.pl?sid=05/10/09/1831219&tid=156 8. http://www.oreillynet.com/pub/wlg/7996 9. http://www.pugscode.org/ ZLib bindings. Joel Reymont [10]asked about code for handling GZip files. Henning Thielemann suggested the code in Darcs. Malcom Wallace pointed out code in qforeign, and John Goerzen mentioned the pure-Haskell implementation in MissingH. 10. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8759 GADTs. Bulat Ziganshin began a [11]discussion asking for resources on GADTs. Several people posted links to helpful resources. 11. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8708 Class aliases. John Meacham began a long [12]discussion by proposing class aliases, a language extension to solve problems of multiple implementations of the same concept in different libraries. 12. http://thread.gmane.org/gmane.comp.lang.haskell.general/12276 About Haskell Weekly News Thanks to Josef Svenningsson for contributing material towards this week's HWN. Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [13]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 13. http://sequence.complete.org/hwn-contrib

1 0

RE: [Haskell] really undecidable instances?
by Simon Peyton-Jones 18 Oct '05

18 Oct '05

It's all very delicate. I believe, though I am not certain, that in the absence of functional dependencies, removing at least one type constructor might be an example of a rule that is sufficient to ensure termination. There are lots of such rules. Alas none known to me capture all cases. Functional dependencies make things much worse. Suppose you have instance C Int a => D Char [a] which looks safe enough. But now class C x y | x -> y instance D Char [b] => C Int [[b]] and now we loop. There's a paper on my home page explaining why functional dependencies are tricky (co-authored with Martin Sulzmann, Peter Stuckey and Gregory Duck). Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 17 October 2005 16:12 | To: Haskell ML | Subject: Re: [Haskell] really undecidable instances? | | Am Montag, 17. Oktober 2005 15:57 schrieben Sie: | > This one | | [That is the instance declaration instance C Int a => D Char [a].] | | > can't. But it's hard to formulate a general rule. | > -fallow-undecidable-instances simply says that you, the programmer, take | > responsibility for termination. Without the flag, GHC uses a simple but | > sometimes over-conservative rule | > | > Simon | | [Could you please put citations at the top of the respective mail?] | | Section 7.4.4.3 of the GHC User's guide says about the restrictions for | ensuring decidability: | | These restrictions ensure that context reduction terminates: each reduction | step removes one type constructor. | | But as far as I can see, in my example there is also one type constructor | removed. Why isn't this allowed then? | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 1

ANNOUNCE: JRegex library
by John Meacham 17 Oct '05

17 Oct '05

JRegex is a library that provides interfaces to both PCRE (perl comptatable regular expressions) and Posix regular expressions. it also provides an operator (=~) which is similar, but much more powerful than the perl operator. In addition, the syntax uses extensible type classes so you may extend it with any regular expression or list matching types and the ability to match lists of any type (not just chars). for an example, here is the output of several calls to =~ just used at different types: -- return number of times the regex matches print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: Int) => 2 -- returns the first matching expression print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: String) => "fooobar" -- returns the string before the first match, the matching string, and the string after the first match print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: (String,String,String)) => ("hello","fooobar","bobfoobarbad") -- returns true if there is a match at all and false otherwise print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: Bool) => True -- always returns (). useful with the (=~~) monadic operator print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: ()) => () -- returns all matching substrings print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: [String]) => ["fooobar","foobar"] -- returns an array off all matching parenthesised substrings in the regex for first match print ("hellofooobarbobfoobaaarbad" =~ "f(o*)b(a+r)" :: Array Int String) => array (0,2) [(0,"fooobar"),(1,"ooo"),(2,"ar")] -- returns an array off all matching parenthesised substrings in the regex for all matches print ("hellofooobarbobfoobaaarbad" =~ "f(o*)b(a+r)" :: [Array Int String]) => [array (0,2) [(0,"fooobar"),(1,"ooo"),(2,"ar")],array (0,2) [(0,"foobaaar"),(1,"oo"),(2,"aaar")]] here is its homepage: http://repetae.net/john/computer/haskell/JRegex/ I released a different version of this library in the past, but this version has been cleaned up, moved to a proper spot in the libraries, and is cabalized. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0