December 2002 - Haskell

Constant space infinite itteration ... solution?
by b.i.mills＠massey.ac.nz 13 Dec '02

13 Dec '02

Hi all, Ok, I've got the Farari out of the garage, in to gear, and even driven it slowly around the block, but every time I put my foot down it just stalls. I'm trying to write a non trivial gui in Haskell. At the moment I'm using Hugs, and rapidly coming to the conclusion that I should be using something else such as GHC. As I see it the problem is basically that of tail recursion removal or as David Bergman calls it "last call optimisation". Specifically: David Bergman wrote > It is easy to get the feeling that the recursive call in > > recurse = do { f x ; recurse } > > is the last one, but this is just an illusion of the > iterative layout of "do". Sometimes the monads lure us > into old iterative thought patterns... > > Taking away the syntactic sugar, we end up with > > recurse = f x >> recurse > > This reveals the fact that there can be no last call > optimization, because the last call is ">>". In response Richard Uhtenwoldt echoed my own thoughts ... > What do you mean by this? Do you mean that that an > implementation cannot execute arbitrarily many > iterations/recursions of that last loop/definition > in constant space? And also said ... > If that's what you mean, you are wrong. GHC does that. > The IO monad would be pretty damned useless for actual > work if implementations did not do that! So, my problem is that I find that my program crashes with "garbage collector can't collect enough memory" after about 64 Million output operations. What's really annoying is that I can write the whole thing *recursively* in C in a very "functional" manner, and it works just fine. As I see it the problem is that >> and >>= are functions and David is right about the "not the last call" problem. But, Richard is right that related optimisations should be possible in Haskell, and if not then you can kiss the whole load good by and go back to system programming in C. In particular I would claim that the definition: recurse = f x >>= recurse is essentially using >>= as a proxy temporal execution handler. So in the above definition the call to recurse *is* a "last-call", at least according to >>=. I'm probably saying that in a rather unorthodox manner, but I hope my basic intention is clear. In fact we can see >> in Haskell as rather kin to ; in C (Or perhaps it should be >>=, since ; does transfer the state to the subsequent computation). So, I've loaded GHC and I'm looking to use it instead (I expected to eventually anyway), but does this solve my problem? Or have I misunderstood something here? Also ... I've been using the graphics libs with HUGS, but I can't find the equivalent in GHC ... what is the recomended library for writing GUIs in GHC Haskell? And where do I get it? Thanks in advance ... Bruce (IIMS, Massey at Albany). ps: I've also been looking at Fudgets, but the code seems a bit cranky.

5 4

FM2003: Call for TUTORIALS
by mailinglist-admin＠fmeurope.org 13 Dec '02

13 Dec '02

FM2003: Call for TUTORIALS The FME symposia on Formal Methods is a forum for the dissemination of basic as well as applied up-to-date culture on the use of formal methods for software development. Maintaining the tradition, a tutorial program that gives attendees the opportunity to gain new insights, knowledge and skills on evolving and emerging research topics in the area of formal methods will be an essential part of the symposium. The Tutorials are scheduled for September 8-9, 2003 at the beginning of the symposium. Survey papers and/or tutorial notes will be made available to the tutorial attendees at the symposium. Tutorials are intended to provide independent instruction on a relevant theme, therefore no commercial or sales-oriented presentations will be accepted. Proposals of Tutorials which encompass any topic dealing with precise mathematical methods for software development, and in particular their application to new application areas that are critical in the new aspects of the information society are solicited. A non-exhaustive suggested list of topics and areas in the scope of FM2003 is listed in the FM2003 Call for Papers (http://fme03.isti.cnr.it/) Instructors are invited to submit proposals for half-day and full-day tutorials and, upon selection, are required to provide tutorial notes or a survey paper on the topic of presentation before June 8, 2003 in postscript, pdf or on paper (no colour print). Proper tutorial notes are preferred, but well-printed transparencies will be accepted as well. Proposals should be send to the Tutorials Chair Mieke Massink by March 7, 2003. Proposals should be in Postscript or PDF format. Please include the following information in the proposal that should not exceed 5 pages: * name and affiliation of proposer/organizer (including address, phone number, fax number, e-mail address) * name and affiliation of additional presenters * instructor's experience in the area, such as other tutorials, courses etc. * title * objective * abstract * outline * duration * audio-visual and technical requirements * target audience * assumed background of attendees * brief biography of each instructor (for inclusion in publicity) * indication whether a survey paper will be provided (max. 30 pages) Evaluation of proposals will be based on the relevance of the subject matter and on the expertise and experience of the instructors. Important Dates Submission of Tutorial proposals: March 7, 2003 Notification of acceptance: March 20, 2003 Camera ready papers/notes: June 8, 2003 Conference: September 8-14, 2003 Web page of FM03: http://fme03.isti.cnr.it/ Tutorial proposals should be submitted to the FM2003 Tutorial Chair: Mieke Massink C.N.R.-Ist. ISTI "A. Faedo" Area della Ricerca di Pisa Via Moruzzi 1, I56124 Pisa, Italy Tel: +39-050-3152981 Fax: +39-050-3138091 email: Mieke.Massink(a)cnuce.cnr.it -- ---------------------------------------------------------------- Dr. Mieke Massink Ph.D. - Researcher FM&&T group (http://matrix.iei.pi.cnr.it/FMT) C.N.R. - Area della Ricerca di Pisa - Ist. ISTI Via G. Moruzzi, 1 - I56124 Pisa, Italy Tel: +39 050 3152981 http://www.cnuce.pi.cnr.it/people/M.Massink/ Fax: +39 050 3138091 E-mail: Mieke.Massink(a)cnuce.cnr.it ---------------------------------------------------------------- _______________________________________________ Mailinglist mailing list Mailinglist(a)fmeurope.org http://www.fmeurope.org/mailman/listinfo/mailinglist

1 0

lazy stream I/O
by Wolfgang Jeltsch 13 Dec '02

13 Dec '02

Hello, what are the arguments against lazy stream I/O? Wolfgang

2 1

RE: Constant space infinite itteration ... solution?
by David Bergman 12 Dec '02

12 Dec '02

Hi, Bruce. Just want to clarify the "last call optimisation"/"tail recursion" terminology. One does not "remove" a tail recursive call, one just make it O(1) w.r.t. stack (or any other "where have we been" call frame structure...) with the help of "tail recursion optimisation". "Last call optimisation" is a generalization of the latter optimisation, applicable to any call, recursive or not. In effect, implementers seldom care whether the last call is recursive or not, they just skip the "return address" pushing, making "last call optimisation" operationally equivalent to "tail recursion optimisation". Richard was (and still is) completely correct in that last call optimisation is not a crucial element in lazy evaluation, although that is not necessarily true when strictness analysis or explicit strictness annotations (!) allow the implementation to skip the general thunk creation/inspection/destruction loop and instead use the much more time-efficient eager evaluation (i.e., mapping to the C code you referred to...), which can be memory-inefficient, similar to your Hugs experience. Good luck with that Ferrari (that is the only Ferrari we Haskellers will ever see...) /David Bruce wrote: > > > Hi all, > > > Ok, I've got the Farari out of the garage, in to gear, and even driven > it slowly around the block, but every time I put my foot down it just > stalls. > > I'm trying to write a non trivial gui in Haskell. At the moment I'm > using Hugs, and rapidly coming to the conclusion that I should be > using something else such as GHC. > > As I see it the problem is basically that of tail recursion removal or > as David Bergman calls it "last call optimisation". > > Specifically: > > David Bergman wrote > > > It is easy to get the feeling that the recursive call in > > > > recurse = do { f x ; recurse } > > > > is the last one, but this is just an illusion of the iterative > > layout of "do". Sometimes the monads lure us into old iterative > > thought patterns... > > > > Taking away the syntactic sugar, we end up with > > > > recurse = f x >> recurse > > > > This reveals the fact that there can be no last call optimization, > > because the last call is ">>". > > In response Richard Uhtenwoldt echoed my own thoughts ... > > > What do you mean by this? Do you mean that that an implementation > > cannot execute arbitrarily many iterations/recursions of that last > > loop/definition in constant space? > > And also said ... > > > If that's what you mean, you are wrong. GHC does that. > > The IO monad would be pretty damned useless for actual > > work if implementations did not do that! > > So, my problem is that I find that my program crashes with "garbage > collector can't collect enough memory" after about 64 Million output > operations. > > What's really annoying is that I can write the whole thing > *recursively* in C in a very "functional" manner, and it works just > fine. > > As I see it the problem is that >> and >>= are functions > and David is right about the "not the last call" problem. But, Richard > is right that related optimisations should be possible in Haskell, and > if not then you can kiss the whole load good by and go back to system > programming in C. > > In particular I would claim that the definition: > > recurse = f x >>= recurse > > is essentially using >>= as a proxy temporal execution handler. So in > the above definition the call to recurse > *is* a "last-call", at least according to >>=. I'm > probably saying that in a rather unorthodox manner, > but I hope my basic intention is clear. > > In fact we can see >> in Haskell as rather kin to ; in C > (Or perhaps it should be >>=, since ; does transfer the > state to the subsequent computation). > > So, I've loaded GHC and I'm looking to use it instead > (I expected to eventually anyway), but does this solve > my problem? Or have I misunderstood something here? > > Also ... I've been using the graphics libs with HUGS, > but I can't find the equivalent in GHC ... what is > the recomended library for writing GUIs in GHC Haskell? > And where do I get it? > > Thanks in advance ... > > Bruce (IIMS, Massey at Albany). > > ps: I've also been looking at Fudgets, but the code seems > a bit cranky. > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell >

1 0

RE: Constant space infinite itteration ... solution?
by David Bergman 12 Dec '02

12 Dec '02

Hi, Bruce. Just want to clarify the "last call optimisation"/"tail recursion" terminology. One does not "remove" a tail recursive call, one just make it O(1) w.r.t. stack (or any other "where have we been" call frame structure...) with the help of "tail recursion optimisation". "Last call optimisation" is a generalization of the latter optimisation, applicable to any call, recursive or not. In effect, implementers seldom care whether the last call is recursive or not, they just skip the "return address" pushing, making "last call optimisation" operationally equivalent to "tail recursion optimisation". Richard was (and still is) completely correct in that last call optimisation is not a crucial element in lazy evaluation, although that is not necessarily true when strictness analysis or explicit strictness annotations (!) allow the implementation to skip the general thunk creation/inspection/destruction loop and instead use the much more time-efficient eager evaluation (i.e., mapping to the C code you referred to...), which can be memory-inefficient, similar to your Hugs experience. Good luck with that Ferrari (that is the only Ferrari we Haskellers will ever see...) /David Bruce wrote: > > > Hi all, > > > Ok, I've got the Farari out of the garage, in to gear, and even driven > it slowly around the block, but every time I put my foot down it just > stalls. > > I'm trying to write a non trivial gui in Haskell. At the > moment I'm using Hugs, and rapidly coming to the conclusion > that I should be using something else such as GHC. > > As I see it the problem is basically that of tail recursion > removal or as David Bergman calls it "last call optimisation". > > Specifically: > > David Bergman wrote > > > It is easy to get the feeling that the recursive call in > > > > recurse = do { f x ; recurse } > > > > is the last one, but this is just an illusion of the iterative > > layout of "do". Sometimes the monads lure us into old iterative > > thought patterns... > > > > Taking away the syntactic sugar, we end up with > > > > recurse = f x >> recurse > > > > This reveals the fact that there can be no last call optimization, > > because the last call is ">>". > > In response Richard Uhtenwoldt echoed my own thoughts ... > > > What do you mean by this? Do you mean that that an implementation > > cannot execute arbitrarily many iterations/recursions of that last > > loop/definition in constant space? > > And also said ... > > > If that's what you mean, you are wrong. GHC does that. > > The IO monad would be pretty damned useless for actual > > work if implementations did not do that! > > So, my problem is that I find that my program crashes with > "garbage collector can't collect enough memory" after about > 64 Million output operations. > > What's really annoying is that I can write the whole thing > *recursively* in C in a very "functional" manner, and it works just > fine. > > As I see it the problem is that >> and >>= are functions > and David is right about the "not the last call" problem. > But, Richard is right that related optimisations should > be possible in Haskell, and if not then you can kiss the > whole load good by and go back to system programming in C. > > In particular I would claim that the definition: > > recurse = f x >>= recurse > > is essentially using >>= as a proxy temporal execution handler. So in > the above definition the call to recurse > *is* a "last-call", at least according to >>=. I'm > probably saying that in a rather unorthodox manner, > but I hope my basic intention is clear. > > In fact we can see >> in Haskell as rather kin to ; in C > (Or perhaps it should be >>=, since ; does transfer the > state to the subsequent computation). > > So, I've loaded GHC and I'm looking to use it instead > (I expected to eventually anyway), but does this solve > my problem? Or have I misunderstood something here? > > Also ... I've been using the graphics libs with HUGS, > but I can't find the equivalent in GHC ... what is > the recomended library for writing GUIs in GHC Haskell? > And where do I get it? > > Thanks in advance ... > > Bruce (IIMS, Massey at Albany). > > ps: I've also been looking at Fudgets, but the code seems > a bit cranky. > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell >

1 0

Re: arrows
by Ashley Yakeley 12 Dec '02

12 Dec '02

At 2002-12-06 15:57, Wolfgang Jeltsch wrote: >I cannot see how this relatively simple representation can be used to >describe >certain parsers. If I would use Identity for baseMonad, I would have a type >for simple parsers. MyParser Identity would essentially be token -> output. You can't use Identity for baseMonad. You would need to use something that managed a stream. The idea is that your source is something of type "baseMonad token", and by repeatedly calling source, you pull off individual tokens. >Which function of this type should be used to describe, for instance, > (a) a parser reading no tokens and returning () MkMyParser (\_ -> return ()) > (b) a parser reading two tokens and returning the pair of these tokens? MkMyParser (\source -> do { a <- source; b <- source; return (a,b); }) You can then use parsers of type MyParser with all kinds of sources, such as those that read items from a file, or a state transformer that pops items off a list, or whatever. -- Ashley Yakeley, Seattle WA

2 1

GPCE 03
by Akos Ledeczi 12 Dec '02

12 Dec '02

I thought you might be interested in this conference. I apologize if you receive multiple copies of this anouncement. Best regards, Akos Ledeczi Publicity Chair GPCE 2003: Call for Contributions 2nd International Conference on Generative Programming and Component Engineering September 22-25, 2003 Erfurt, Germany Part of NetObjectDays'03 http://gpce.org In Cooperation with ACM SIGPLAN and SIGSOFT Generative and component approaches have the potential to revolutionize software development in a similar way as automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (elevating program specifications to compact domain-specific notations that are easier to write and maintain) are key technologies for automating program development. GPCE arose as a joint conference, merging the prior conference on Generative and Component-Based Software Engineering (GCSE) and the Workshop on Semantics, Applications, and Implementation of Program Generation (SAIG). The goal of GPCE is to provide a meeting place for researchers and practitioners interested in cutting edge approaches to software development. Thanks to the co-location with NetObjectDays, one of the largest main-stream software development conferences in Germany, the GPCE'03 presentations are expected to have a high attendance by industry practitioners, in addition to regular conference attendees. Important Dates: --------------- Technical paper submission: Apr 6, 2003 Workshop proposal submission: Apr 6, 2003 Practitioner report submission: May 18, 2003 Tutorials proposal submission: May 18, 2003 Demonstration proposal submission: May 18, 2003 Poster proposal submission: Jul 13, 2003 Notification of acceptance for Technical papers: May 25, 2003 Workshop proposals: Apr 20, 2003 Practitioner reports: Jun 1, 2003 Tutorials proposals: Jun 1, 2003 Demonstration proposals: Jun 1, 2003 Poster proposals: Jul 27, 2003 Camera ready copy: Jun 22, 2003 Detailed submission instructions are available at: http://gpce.org Technical Papers ---------------- The GPCE'03 conference invites high quality papers reporting research results and/or experience related to generative programming and component engineering. We seek papers both in software engineering and in programming languages, and especially those that bridge the gap and are accessible to both communities at the same time. The conference solicits submissions related (but not limited) to: * Generative Programming: Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, * Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, program transformation * Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, reflection. * Product Lines and architectures * Industrial Applications * Component-Based Software Engineering: Reuse, distributed platforms, distributed systems, evolution, analysis and design patterns, development methods, formal methods * Integration of Generative and Component-Based Approaches * Domain Engineering, analysis, and languages, domain-specific notations * Separation of Concerns: Aspect-Oriented Programming, Intentional Programming, and Multi-Dimensional Separation of Concerns * Model-driven architecture Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. Research papers should describe work that advances the current state of the art. The program committee will evaluate each contributed paper based on its relevance, significance, clarity and originality. The program committee is happy to advise on the appropriateness of a particular subject. Authors are invited to submit papers of at most 12 pages in ACM proceedings format, in PDF form, by April 6, 2003. This deadline is firm. Simultaneous submission to other venues and submission of previously published material are not allowed. Electronic submission will be required, except by special arrangement with the program chairs. Practitioner Reports -------------------- GPCE '03 will feature a track geared towards industry and practice, where practitioners will present their experience and insight in applying generative and component-based technologies. We solicit reports in two categories: * Project reports describing successfully completed projects that applied technologies within the scope of GPCE'03. * Experience reports focussing on a particular aspect of technology usage and practice, or describe broad project experiences. The report submissions will be reviewed separately from technical paper submissions by a practitioner report committee. Workshops --------- GPCE workshops provide intensive collaborative environment to explore a specific sub-area of generative and component technology in depth, cover areas that cross the borders of several sub-areas, or focus on the applications and deployment of generative and/or component technology in a particular application domain. Workshops will take place on the first day of the conference. Young Researchers Workshop -------------------------- As in the past year, the conference will feature a one day doctoral symposium, where a panel of experts will review and discuss submissions from graduate students and other young researchers. For more details about submissions, please contact the YRW Chairs Isabel John (john(a)iese.fhg.de) and Matthias Clauss (Matthias.Clauss(a)gmx.de) Tutorials --------- We invite proposals for high-quality tutorials in all areas of generative programming and component-based development. Tutorial levels may be introductory, intermediate, or advanced. Introductory tutorials should seek to educate the participants about the basic concepts and techniques of generative and component-based development. More advanced tutorials may cover advanced development techniques and/or underlying theory. Demonstrations -------------- We invite proposals for demonstrating novel tools, systems, or techniques from both commercial and academic communities. Demonstrations should focus on technical aspects. Demonstrations showing how a specific technology is used in real world scenarios are particularly welcome. Both work in progress or proven techniques are appropriate. Product marketing is inappropriate in this forum. Posters ------- Posters at GPCE provide an excellent forum for authors to present their work in an informal and interactive setting. Posters are ideal for presenting speculative, late-breaking results or for giving an introduction to interesting, innovative work. Exhibits -------- The GPCE '03 exhibits will be held together with the exhibits of NetObjectDays'03, one of the largest main-stream software development conferences in Germany. Therefore, this will be an excellent forum to reach potential customers with news and demonstrations of your latest products, publications or services. If you would like your company to participate as an exhibitor at the conference, please refer to the web site for submission instructions. GPCE'03 Best Contribution Awards -------------------------------- The GPCE'03 audience will elect the best contributions in the following categories: * Best Paper * Best Practitioner Report * Best Commercial Tool * Best Non-Commercial Tool * Best Industrial Project Organizing Committee -------------------- General Chair: (chair03(a)gpce.org) Krzysztof Czarnecki, DaimlerChrysler Research and Technology, Germany. Program Committee Chairs: (pc03(a)gpce.org) Frank Pfenning, Carnegie Mellon University, USA Yannis Smaragdakis, Georgia Institute of Technology, USA Workshop Chair: (workshops03(a)gpce.org) Kasper Osterbye, IT University of Copenhagen, Denmark Tutorial Chair: (tutorials03(a)gpce.org) Gerd Frick, FZI, Karlsruhe, Germany Demonstration Chair: (demos03(a)gpce.org) Markus Voelter, independent consultant, Germany Poster Chair: (posters03(a)gpce.org) Jorn Bettin, SoftMetaWare, New Zealand Industrial Chair: (industrial03(a)gpce.org) Ulrich W. Eisenecker, University of Applied Sciences Kaiserslautern, Germany Publicity Chair: (publicity03(a)gpce.org) Akos Ledeczi, Vanderbilt University, USA Young Researchers Workshop Chairs Isabel John, Fraunhofer IESE, Germany (john(a)iese.fhg.de ) Matthias Clauss, Solutionline CSS, Germany (Matthias.Clauss(a)gmx.de) Program Committee Members (near-final): ------------------------- Giuseppe Attardi, University of Pisa, Italy Don Batory, University of Texas, USA Ira Baxter, Semantic Designs, USA Ted Biggerstaff, softwaregenerators.com, USA Shigeru Chiba, Tokyo Institute of Technology, Japan Rowan Davies, University of Western Australia, Australia Premkumar Devanbu, University of California, Davis, USA Ulrich W. Eisenecker, University of Applied Sciences Kaiserslautern, Germany Robert Glueck, Waseda University, Japan Trevor Jim, AT&T Labs Research, USA Gregor Kiczales, University of British Columbia, Canada Kai Koskimies, Tampere University of Technology, Finland Julia Lawall, DIKU, University of Copenhagen, Denmark Eugenio Moggi, DISI, University of Genova, Italy Jim Neighbors, Bayfront Technologies, USA Calton Pu, Georgia Tech, USA Olin Shivers, Georgia Tech, USA Clemens Szyperski, Microsoft Research, USA Peter Thiemann, University of Freiburg, Germany Eelco Visser, Utrecht University, The Netherlands

1 0

New PhD Positions in Computing Science, Chalmers University of Technology & Göteborg University
by Reiner Haehnle 11 Dec '02

11 Dec '02

Please pass on to interested students. Apologies for multiple copies. --------------------------------------------------------------------- New PhD Positions (DEADLINE 15 February 2003! See "How to apply" below) Department of Computing Science, Chalmers University of Technology & Göteborg University Gothenburg, Sweden http://www.cs.chalmers.se/Cs/ The Department has about 80 researchers, half being faculty members and half PhD students. Our focus is on programming logic, type theory, functional programming, formal methods, distributed and concurrent systems, security, algorithms, bioinformatics, interaction design, and language technology, but research is not restricted to these topics. For more information, see http://www.cs.chalmers.se/Cs/Research. PhD positions are for 5 years. There is no tuition fee. A PhD position is a regular job with social benefits; the salary amounts currently to about 18000 SEK per month in the first year (the exact amount depends on teaching duties, usually 20% of your time). Knowledge of Swedish is not a prerequisite for application. English is our working language for research. Both Swedish and English are used in undergraduate courses. Half of our researchers and PhD students are native Swedes; the rest come from more than 20 different countries. Applicants must have a very good undergraduate degree in Computing Science or in a related subject with a strong Computing Science component. They must also have a strong, documented interest in doing research. You may even apply if you have not yet completed your degree, but expect to do so by 1 September 2003. You are also invited to apply for our new International Master's Programme in Dependable Computer Systems, which can help you to obtain the necessary qualification, if you do not yet have it (see http://www.cs.chalmers.se/Cs/Education/dcs/) The School especially welcomes female applicants. How to apply ------------ First, immediately register your intention to apply using the electronic application form on the WWW via http://www.md.chalmers.se/Jobs/PhD/phd-03-en.thtml The full application should contain 1 A letter of application, listing specific research interests 2 A curriculum vitae 3 Attested copies of degrees and other certificates 4 Copies of relevant work, for example dissertations or articles, that you have authored or co-authored 5 A description of: a previous teaching experience, documented b previous PhD studies, also in other subjects; state financial support obtained for these, if any c previous work experience 6 Letters of recommendation from your teachers or employers If you have financial support of your own (industry job, grant, etc.), please state this fact clearly. It will increase your chances to be accepted considerably, because you need not compete for the limited number of fully financed positions. The reference number of this job opportunity is 3/2003. Send your full application (paper mail) to Department of Computing Science School of Computer Science and Engineering Chalmers University of Technology 412 96 Gothenburg Sweden to arrive by 15 February 2003. You will know the result of your application by 1 May 2003.

2 1

video4linux
by Martin Huschenbett 11 Dec '02

11 Dec '02

Hi all, does anybody know how to read a single image from a video4linux device under Haskell? Thanks for all help, Martin

2 1

RTA'03: call for papers
by Femke van Raamsdonk 10 Dec '02

10 Dec '02

****************************** * * * RTA'03 CALL FOR PAPERS * * * ****************************** http://www.dsic.upv.es/~rdp03/rta The 14th Int. Conf. on Rewriting Techniques and Applications (RTA'03) will be part of the Federated Conf. on Rewriting, Deduction and Programming (RDP'03). IMPORTANT DATES: Jan 15 2003: Deadline electronic submission of title+short abstract Jan 22 2003: Deadline electronic submission of papers Mar 15 2003: Notification of acceptance of papers Apr 7 2003: Deadline for final versions of accepted papers Jun 9-11 '03: Conference. RTA is the major forum for the presentation of research on all aspects of rewriting. Typical areas of interest include (but are not limited to): * APPLICATIONS: case studies; (rule-based) programming; symbolic and algebraic computation; theorem proving; system synthesis and verification; proof checking. * FOUNDATIONS: matching and unification; narrowing; completion techniques; strategies; constraint solving; explicit substitutions. * FRAMEWORKS: string, term, and graph rewriting; lambda-calculus and higher-order rewriting; proof nets; constrained rewriting/deduction; categorical and infinitary rewriting. * IMPLEMENTATION: compilation techniques; parallel execution; rewriting tools. * SEMANTICS: equational logic; rewriting logic. INVITED TALKS will be given at RTA'03 by: * David McAllester Toyota Technological Institute at Chicago Joint invited speaker with TLCA * Jean-Louis Giavitto Universit� d'Evry, France * Pat Lincoln SRI International BEST PAPER AWARDS: A 1000 Euro award wil be given to the best paper or papers as decided by the PC. The award may also totally or partially go to the best paper with a student as main author, according to the submission letter. RTA'03 PROGRAM COMMITEE: * Harald Ganzinger (Max-Planck-Institut) * Claude Kirchner (Nancy) * Salvador Lucas (Valencia) * Chris Lynch (Clarkson) * Jos� Meseguer (Urbana) * Robert Nieuwenhuis (Barcelona, Chair) * Tobias Nipkow (Munich) * Vincent van Oostrom (Utrecht) * Christine Paulin (Paris-sud) * Frank Pfenning (Carnegie Mellon) * Mario Rodr�guez-Artalejo (Madrid) * Sophie Tison (Lille) * Ashish Tiwari (SRI) * Andrei Voronkov (Manchester) * Hantao Zhang (Iowa) RTA'03 SUBMISSIONS: Submissions must be original and not submitted for publication elsewhere. Submission categories include regular research papers and system descriptions. Also problem sets and submissions decribing interesting applications of rewriting techniques will be very welcome. As usual, accepted papers will appear in the Springer-Verlag Lecture Notes in Computer Science series. See the RDP'03 web page <http://www.dsic.upv.es/~rdp03/> for details. For further questions please contact the program chair: RTA'03 PROGRAM CHAIR: Robert Nieuwenhuis Technical University of Catalonia Jordi Girona 1, E-08034 Barcelona, Spain roberto(a)lsi.upc.es

1 0