- Haskell - Haskell.org

Re: [Haskell] ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
by Niklas Broberg 16 May '04

16 May '04

Dylan Thurston wrote: >So I guess that in > >foo [/ a? 2 b /] = (a,b) > >the type of a is '[Int]', not 'Maybe Int', right? Aye. If you wanted Maybe Int, you would need to do foo [/ a@_? 2 b /] = (a,b) I wrote: > > I'm starting to think maybe our context dependent approach to implicit > > bindings isn't very good after all since it seems to confuse a lot of > > people. Perhaps variables bound inside regular patterns should always be > > non-linear... of course that would still be context dependent when >compared > > to normal Haskell patterns, but perhaps still less confusing? Dylan Thurston wrote: >Alternatively, you could forbid the use of simple variables nonlinearly, >since there's an alternative way to write it. Or, you could make >variables (and other pattern binding) more context dependent, recording >all the relevant parts of the context (and not just whether the context >is linear or not), if that makes sense. > >Interesting issues, anyway! Indeed they are. We basically have two reasons for not wanting to record the context in bound variables. The first is that it would not correspond very well with ordinary pattern matching, and we sought to minimize the differences by only adding the context dependence that was impossible to avoid. The second is that there is a way to get at that context information already, by explicitly binding larger patterns (cf. the example above). In contrast, were we to record contexts in all bound variables there would be no way to avaid the context information should you want to. As an example catMaybes :: [Maybe a] -> [a] catMaybes [/ (Just a | Nothing)* /] = a If we were to record the context in which a appears, we would have removed one data constructor (Just) but added another (Left). Perhaps even more illustrating would be catEithers :: [Either a a] -> [a] catEithers [/ (Left a | Right a)* /] = a Dylan Thurston wrote: >By the way, are nested regular expression matches allowed? Something >like: > >foo :: [[Int]] -> Int >foo [/ _* [/ 5* a 6* /] _* /] = a Absolutely. We've added regular patterns as a new pattern category in Haskell, so anywhere that you can use a standard pattern you can use a regular pattern, including inside a regular pattern. Dylan Thurston wrote: >? If so, what is the type of a in > >foo [/ _* [/ 5* a* /]* _* /] > >? It will be [[Int]]. a has type [Int] in the inner pattern, and in the outer pattern it appears in non-linear context (inside the *). Compare to foo [/ _* (Just a@(_:_))* _* /] = a Here the a clearly binds to a list in the inner expression, and in the regular pattern it appears in non-linear context. So here foo :: [Maybe [a]] -> [[a]] As an aside, the patterns above will always give a the empty list since the first _* will "eat" the entire input, being greedy and all. But of course that won't affect the types... With the package you can try out the types yourself. Just write these functions in a source file and load it into ghci following the guidelines on the homepage (http://www.dtek.chalmers.se/~d00nibro/harp/) Then you can let ghci infer the types for you. =) /Niklas _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

auto-qualification of identifiers in Haddock
by Wolfgang Jeltsch 15 May '04

15 May '04

Hello, take the following module: module InfiniteList where import Prelude hiding (repeat) data InfiniteList e = InfiniteList e (InfiniteList e) {-| Essentially the same as 'Prelude.repeat'. -} repeat :: e -> InfiniteList e repeat e = l where l = InfiniteList e l If I feed Haddock with this module, the resulting HTML page reads Essentially the same as repeat. at the end. But since repeat is also an identifier of the current module, this is IMO misleading. Maybe Haddock should produce the string Essentially the same as Prelude.repeat. instead of the above—not because the source code comment says "Prelude.repeat" (Source code "spelling" depends on the exact form of import declarations(?) and is therefore not always suited for Haddock output.) but just because it's the Prelude version of repeat what's mentioned here. What do others think about this issue? Wolfgang

1 0

ANNOUNCE: hs-plugins-0.9.2 - dynamically loaded plugins
by dons＠cse.unsw.edu.au 15 May '04

15 May '04

== hs-plugins-0.09.2, dynamically loaded plugins in Haskell == Release early, release often is the way to go. This is the first src release of <hs-plugins>, a library for compiling and loading Haskell plugins in Haskell. http://www.cse.unsw.edu.au/~dons/hs-plugins/ The library allows an application to compile and load a Haskell source file, and then run the code therein. The inspiration and foundation of hs-plugins based on Andre Pang's original runtime_loader code and GHCi binding. hs-plugins provides this functionality, along with layers of abstraction on top, as well as a 'make' mechanism to recompile plugins whose source has changed, and the following features: - runtime compilation and re-compilation of plugins - runtime loading of object files - automatic *dependency* loading of object files, based on .hi info - unload/reloading of object files - a mechanism to merge the abstract syntax of a plugin with a syntax stub, to factor out common/necessary declarations. This is to help out EDSL programmers - many examples, and a simple build system An example plugin, potentially written by a non-programmer: resource = plugin { function = reverse } An example application: import Plugins import API main = do make "Plugin.hs" [] (m,v) <- load "Plugins.o" "." "resource" putStrLn $ (function v) "hello" will print "olleh" You'll probably need GHC 6.2 or greater. This is a GHCi specific library, and will only work on platforms with a functional GHCi implementation. It is also BSD make friendly ;) The original inspiration was to provide a typesafe config language to replace configuration files for new applications (a muttrc and vimrc killer...) Haskell EDSLs and dynloaded plugins suit this quite fine, and the library is suited for EDSL purposes in general, I think. Feedback *very* welcome. Enjoy! -- Don

1 0

ANNOUNCE: HaRP (Haskell Regular Patterns) version 0.1
by Niklas Broberg 15 May '04

15 May '04

A wise man once said, release early and release often. We're obviously not very wise... ;) =============== Announcing HaRP 0.1 =============== HaRP is a Haskell extension that extends the normal pattern matching facility with the power of regular expressions. This expressive power is highly useful in a wide range of areas, including text parsing and XML processing [1]. Regular expression patterns in HaRP work over ordinary Haskell lists ([]) of arbitrary type. We have implemented HaRP as a pre-processor to ordinary Haskell. Where to get it: HaRP can be downloaded from http://www.dtek.chalmers.se/~d00nibro/harp/ along with notes on installation and usage. Description: Simple pattern matching on concrete, fully specified lists can be done in Haskell as so: foo [Foo, Bar, Baz] = ... We add an extension of this, regular pattern matching, an example: foo [/ Foo Bar* Baz /] = ... The intuition of the above is that we get a match for any list that starts with a Foo, ends with a Baz, and has zero or more Bar in between. If you have used regular expressions in any other language, this should not be new to you. Regular patterns that can be used are: * - match zero or more + - match one or more ? - match zero or one a | b - match a or b (/ a b /) - match the sequence of a, then b (this is also implicit in the top level [/ ... /]). For the three first, there is also the option of adding a ? afterwords to make the match non-greedy (the default is greedy). This means that p* tries to match p as many times as possible while still satisfying the whole pattern, whereas p*? tries to match p as few times as possible. Introducing regular expressions into the pattern matching facility gives some extra nice features. One is that the regular patterns are "type safe", i.e. they are not encoded in strings. Another is that identifiers can be named and bound inside regular patterns, examples: foo [/ _* a /] = ... => a is bound to the last element of the list foo [/ a@(/ _ _ /) _* /] = ... => a is bound to the list containing the first two elements foo [/ (/ a _ /)* /] = ... => a is bound to the list of the first, third, fifth etc elements of a list of even length Note that binding variables implicitly (i.e. without using @) is context dependent in regular patterns. This is because for some variables appearing in certain contexts, we cannot know the number of times that particular variable will be matched. Looking at the last example above, we see that the varible a appears inside the context of a *, meaning it can be matched zero or more times. A variable bound in such a context will contain the list of all values matched to it, whereas a normal linear variable is bound to exactly the value it matches, like the a in the first example above. Patterns that introduce non-linear contexts are *, +, ? (and the non-greedy versions), and | (union). For explicitly bound variables (i.e. variables bound using @) we must also look at types of matched sub-patterns. In the example foo [/ a@(/ _ _ /) _* /] = ... => a is bound to the list containing the first two elements we clearly see that the sequencing sub-pattern has a list type. The types of sub-patterns are as follows (a :: a, b :: b): a* => [a] a+ => [a] a? => Maybe a (/ ... /) => [e], where e is the type of the elements in the list matched, regardless of sub-patterns ( a | b ) => Either a b We also introduce an explicit binding operator for non-linear bindings, called @: (read "as-cons" or "accumulating as"), which adds each match of its associated pattern to a list of matches. An example: foo [/ (_ a@:(/ _ _ /))* /] = ... => a is bound to a list of lists (exactly what the elements will be is left as an exercise to the reader ;) A more complete example using all the presented features: foo [/ _ a@1 b c@3* 4+ d@5? e@(/ f@:6 g /)* h@( 8 | (/ 9 i /) ) /] = (a,b,c,d,e,f,g,h,i) Assuming all the numerical literals are of type Int, foo will have the following type: foo :: [Int] -> (Int, Int, [Int], Maybe Int, [[Int]], [Int], [Int], Either Int [Int], [Int]) Examples of applying foo to some lists: (NOTE, show is generally not defined over tuples this large, so to test these examples you need to do some trick, either define an instance for show or simply nest the tuples so that each is no larger than what can be shown) ?> foo [0,1,2,3,4,5,6,7,8] (1, 2, [3], Just 5, [[6,7]], [6], [7], Left 8, []) ?> foo [0,1,2,3,3,3,4,6,0,6,1,6,2,9,10] (1,2,[3,3,3], Nothing, [[6,0],[6,1],[6,2]], [6,6,6], [0,1,2], Right [9,10], [10]) Discussion of each variable in detail: a :: Int - a binds to a single element at top level (top level meaning it is bound outside any numerating pattern). b :: Int - b binds to a single element at top level. c :: [Int] - c is bound to a zero-or-many pattern, and it will contain all the matches of the sub-pattern, in this case all matches of 3. d :: Maybe Int - d is bound to a zero-or-one pattern, and it will be Nothing in case of zero matches, and Just the match to the sub-pattern in case of a match, in this case 5. e :: [[Int]] - e is bound to a zero-or-more pattern, and will thus contain a list of all the matches of the sub-pattern. In this case the sub-pattern is a sequence, which has a list type, so the type of e is a list of lists. f :: [Int] - f is bound using the list-binding operator @:, so its type will always be a list of the type of the sub-pattern, regardless of the context it appears in. It will contain all matches of the sub-pattern (Note that a normal bind using @ would have been illegal here). At top level (and in ordinary pattern matching), the pattern foo is equivalent to foo@_, but inside numerating patterns the pattern foo is equivalent to foo@:_. (see discussion below) g :: [Int] - g is equivalent to g@:_ as mentioned above, so the same will hold for g as for f. h :: Either Int [Int] - h is bound to a choice pattern (or union pattern if you prefer), so it will be bound to the match of one of the two sub-patterns, annotated with Left or Right. In this case the left sub-pattern matches a single element of type Int, whereas the right sub-pattern matches a sequence of type [Int]. i :: [Int] - Since the choice pattern is numerating (each of the sub-patterns are matched zero or one times), i is equivalent to i@:_. For completeness, another example to show how sequences work: bar :: [Int] -> [Int] bar [/ 0 a@(/ 1* 2 (3|4) (/ 5 6 /) 7? /) /] = a In this case a will have the type [Int], since a sequence will always have the type [e] where e is the type of the elements of the list to match. So in this example, ?> bar [0,2,3,5,6] [2,3,5,6] ?> bar [0,1,1,1,2,4,5,6,7] [1,1,1,2,4,5,6,7] A slightly more useful, real-life example: Assume a config file (or the like) of the following form: option-name : option-value option-name : option-value ... Parsing this into name-value pairs can be done like so: parseConf :: String -> [(String, String)] parseConf str = let [/ (/ names*? ' '* ':' ' '* vals*? '\n' /)* /] = str in zip names vals Hopefully that's enough examples, it should be fairly clear how it all works. =) Regarding @ vs @:, it would be fully possible to implement this just using @ and change its behavior depending on the context it appears in, much like we do with identifiers bound without using the explicit @ operator. We feel that doing so could lead to (even more) confusion regarding how variables are bound, and have therefore chosen to introduce the extra @: operator to make this differing behavior explicit. That identifiers bound without a @ or @: have differing semantics depending on context is unfortunate but unavoidable, and we feel that the added confusion is minor in this case. Open issues: * Greedy vs. non-greedy matching: The current implementation is greedy by default, but some voices have been raised (on this list) that non-greedy matching would be better as default. After some initial use of the system we have also come to find that we tend to use non-greedy patterns far more often than their greedy counterparts. Unless we hear some convincing arguments not to, it is very likely that our next release will have non-greedy patterns as the default. * Strings: Strings are a special syntactic case of a list, and we are planning an analogous special case of regular patterns for it, for instance [s/ "Hello " a* /] would be equal to [/ 'H' 'e' 'l' 'l' 'o' ' ' a* /], but this is not yet implemented. Any and all comments are welcome and appreciated, Niklas Broberg, d00nibro[at]dtek.chalmers.se Andreas Farre, d00farre[at]dtek.chalmers.se Chalmers University of Technology [1] XML processing is actually what we need these regular patterns for. Feel free to visit the project that lead to this spin-off, Haskell Server Pages, at http://www.dtek.chalmers.se/~d00nibro/hsp/ _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

[Haskell] UNIF'04 workshop @ IJCAR 2004: Deadline extension until 21/5
by Ralf Treinen 14 May '04

14 May '04

Call for Papers/Abstracts/System descriptions ***** Deadline extentended until Friday, Mai 21 ******* UNIF 2004 18th International Workshop on Unification July 4-5, 2004, Cork, Ireland Affiliated with IJCAR'04 http://www.faculty.iu-bremen.de/mkohlhase/event/unif04/ UNIF is the main international meeting on unification. Unification is concerned with the problem of identifying given terms, either syntactically or modulo a given logical theory. Syntactic unification is the basic operation of most automated reasoning systems, and unification modulo theories can be used, for instance, to build in special equational theories into theorem provers. The aim of UNIF 2004, as that of the previous meetings, is to to bring together people interested in unification, present recent (even unfinished) work, and discuss new ideas and trends in unification and related fields. In particular, it is intended to offer a good opportunity for young researches and researchers working in related areas to get an overview of the current state of the art in unification theory and get in contact with the experts in the field. ---------------------------------------------------------------------- TOPICS OF INTEREST ---------------------------------------------------------------------- A non-exclusive list of topics of interest is: * Unification * E-unification * Unification Algorithms * Higher-Order Unification * String Unification * Context Unification * Combination problems * Disunification * Typed Unification * Related Topics * Constraint Solving * Tree Descriptions * Matching * Narrowing * Applications * Type Checking and Type Inference * Automated Deduction * Rewriting * Functional and Logic Programming * Grammars * Computational Linguistics * Implementations ---------------------------------------------------------------------- INVITED SPEAKERS ---------------------------------------------------------------------- There will be two invited speakers. ---------------------------------------------------------------------- IMPORTANT DATES ---------------------------------------------------------------------- NEW: Deadline for electronic submission: Friday, May 21, 2004 Email: unif04(a)iu-bremen.de Notification of acceptance: Monday, May 24, 2004 Deadline for camera-ready papers: Monday, June 7, 2004 Workshop: July 4 - 5, 2004 ---------------------------------------------------------------------- SUBMISSION DETAILS ---------------------------------------------------------------------- Authors are invited to submit via email an abstract (1-5 pages), a paper (no longer than 15 pages), or a system description (no more than 5 pages) in Postscript or PDF format to: unif04(a)iu-bremen.de before May 21, 2004. Authors are encouraged to use LaTeX2e and the Springer llncs class. ---------------------------------------------------------------------- PUBLICATION ---------------------------------------------------------------------- Accepted papers, abstracts and system descriptions will be included in the proceedings which will be available at the workshop. ---------------------------------------------------------------------- ORGANIZING COMMITTEE ---------------------------------------------------------------------- Michael Kohlhase (International University Bremen, Germany) Hitoschi Ohsaki (National Institute of Advanced Industrial Science and Technology, Amagasaki, Japan) Steve Prestwich (Universtity College, Cork, Ireland) Ralf Treinen (Ecole Normale Superieure, Cachan, France) Manfred Schmidt-Schauss (Johann Wolfgang Goethe-Universit"at Frankfurt am Main, Germany) -- Ralf Treinen Laboratoire Spécification et Vérification CNRS & École Normale Supérieure de Cachan http://www.lsv.ens-cachan.fr/~treinen

1 0

[bctcs05-info] BCTCS 2005 Announcement
by Graham Hutton 13 May '04

13 May '04

+--------------------------------------------------------------------+ ANNOUNCEMENT 21st British Colloquium for Theoretical Computer Science BCTCS 2005 22-24 March 2005 University of Nottingham, UK The purpose of BCTCS is to provide a forum for researchers in theoretical computer science to meet, present research findings, and discuss developments in the field. It also aims to provide an environment for PhD students to gain experience in presenting their work, and benefit from contact with established researchers. SCOPE The scope includes all aspects of theoretical computer science, such as algorithms, complexity, semantics, formal methods, concurrency, types, languages and logics. Computer scientists, mathematicians and researchers from outside of the UK are all welcome to attend. PROGRAMME The programme will consist of 2.5 days of invited talks, tutorials, and contributed talks. The invited speakers are as follows: Alan Gibbons - King's College London Andrew Gordon - Microsoft Research, Cambridge Ralf Hinze - University of Bonn Conor McBride - University of Durham Rajeev Raman - University of Leicester LOCATION The colloquium will be held on the Jubilee Campus of the University of Nottingham, which has won many awards for its design and environmental features. Nottingham is centrally located in the UK, and is easily reachable by car, train and plane (Nottingham East Midlands Airport.) REGISTRATION The deadline for registration and submission of proposed talks is 7 February 2005. The registration fee will be approximately 275 UK pounds, including accommodation and all meals. Twenty funded places for UK-based PhD students are in the process of being sought. FURTHER DETAILS Google search - BCTCS 2005 Web page - http://www.cs.nott.ac.uk/~gmh/bctcs05.html +--------------------------------------------------------------------+ _______________________________________________ bctcs05-info mailing list bctcs05-info(a)cs.nott.ac.uk http://www.cs.nott.ac.uk/mailman/listinfo/bctcs05-info This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

[Haskell] generic currying (type classes and functional dependencies)
by Duncan Coutts 13 May '04

13 May '04

Hi All, I'm trying to write a generic curry (& uncurry) function that works for functions of any arity. I have a couple solutions that nearly work, both involving type classes. Here's the first one: class Curry tupled curried where genericCurry :: tupled -> curried genericUncurry :: curried -> tupled The base case is obvious: instance Curry ((a,b) -> c) (a -> b -> c) where genericCurry f x y = f (x,y) genericUncurry f' (x,y) = f' x y However, the inductive case is more tricky. We cannot generically create tuples of arbitrary size so we'll have to make do with left (or right) nested pairs. This nesting leads to problems later and for starters requires overlapping instances: instance Curry ( (b,c) -> d) ( b -> c -> d) => Curry ((a,(b,c)) -> d) (a -> b -> c -> d) where genericCurry f a b c = f (a,(b,c)) genericUncurry f (a,(b,c)) = f a b c This works, but when we come to use it we often run into cases where the type checker complains with messages such as: No instance for (Curry ((Int, Int) -> Int) (a -> b -> Int)) I guess that this is because it fails to be able to convince itself that a & b are Int, in which case there would be an instance. This can be solved by supplying enough type annotations, however this is annoying and part of the point of a generic curry is that we don't know the arity of the function to which we are applying it. So I thought that functional dependencies might help because the curried type should uniquely determine the uncurried type (and vice versa). However if I change the class declaration to: class Curry tupled curried | tupled -> curried, curried -> tupled where genericCurry :: tupled -> curried genericUncurry :: curried -> tupled Then the compiler complains about my instance declarations: Functional dependencies conflict between instance declarations: ./Curry.hs:11:0: instance Curry ((a, b) -> c) (a -> b -> c) ./Curry.hs:16:0: instance (Curry ((b, c) -> d) (b -> c -> d)) => Curry ((a, (b, c)) -> d) (a -> b -> c -> d) I don't fully understand why this is the case, but it is to do with the nested pairing, because individual instance declarations for 3-tuples, 4-tuples work find. Any insight or suggestions would be interesting. Duncan

4 3

LOPSTR'04 final call for extended abstracts
by Sandro Etalle 12 May '04

12 May '04

LOPSTR 2004 Verona, Italy, August 26-28, 2004 http://www.sci.univr.it/~lopstr04 FINAL CALL FOR EXTENDED ABSTRACTS DEADLINE (EXTENDED, FIRM): May 17, 2004 The aim of the LOPSTR series is to stimulate and promote international research and collaboration on logic-based program development, and the workshop is open to contributions in logic-based program development in any language paradigm. Starting this year, LOPSTR will put extra emphasis to the field of verification; in fact LOPSTR will also incorporate the VCL (verification in computational logic) workshop series. LOPSTR'04 will be held at the University of Verona http://www.univr.it co-located with SAS 2004 http://www.sci.univr.it/~sas04, the International Static Analysis Symposium, PEPM 2004 http://www.sci.univr.it/~pepm04 - ACM SIGPLAN 2004 Workshop on Partial Evaluation and Semantics Based Program Manipulation, and PPDP 2004 http://www.sci.univr.it/~ppdp04 - 6th ACM-SIGPLAN International Conference on Principles and Practice of Declarative Programming. Past workshops were held in Manchester, UK (1991, 1992, 1998), Louvain-la-Neuve, Belgium (1993), Pisa, Italy (1994), Arnhem, the Netherlands (1995), Stockholm, Sweden (1996), Leuven, Belgium (1997), Venice, Italy (1999), London, UK (2000), Paphos, Cyprus (2001), Madrid, Spain (2002), Uppsala, Sweden (2003). Since 1994 the proceedings have been published in the LNCS series of Springer-Verlag. LOPSTR also aims to be a lively, friendly forum for presenting and discussing work in progress, so it is a real workshop in the sense that it is also intended to provide useful feedback to authors on their preliminary research. Formal proceedings of the workshop are produced only after the workshop, so that authors can incorporate this feedback in the published papers. Scope of the Workshop We solicit extended abstracts and full papers (DEADLINE FOR FULL PAPER HAS PASSED). Topics of interest cover all aspects of logic-based program development, all stages of the software life cycle, and issues of both programming-in-the-small and programming-in-the-large. The following is a non-exhaustive list of topics: * specification * synthesis * verification * transformation * specialisation * analysis * optimisation * composition * reuse * applications and tools * proofs as programs * component-based software development * agent-based software development * software architectures * design patterns and frameworks * program refinement and logics for refinement Submission Guidelines Authors can either submit extended abstracts (short papers) describing work in progress or they can choose to submit full papers (DEADLINE FOR FULL PAPER HAS PASSED). Contributions should be written in English and should be submitted electronically in Postscript or PDF format at http://profs.sci.univr.it/~lopstr04/index.html. Authors are also asked to send the title and abstract of their submission three days before the deadline to lopstr04(a)sci.univr.it. Prospective authors who have difficulties for the electronic submission may contact the chairman at lopstr04(a)sci.univr.it. Extended abstracts should not exceed 6 pages in llncs format and may describe work in progress. Promising abstracts relevant to the scope of LOPSTR will be selected for presentation at the workshop. The submission deadline for extended abstract is May 17, 2004 (extended, strict). Full papers ... deadline for full papers has passed. Accepted papers and abstracts will be collected in informal pre-proceedings which will be available at the workshop. After the workshop, authors of extended abstract which are judged mature for publication will be invited to submit full papers. These will be reviewed according to the usual refereeing procedures, and accepted papers will be published in the final collection of papers (together with the accepted full papers) which is expected to be published in the Lecture Notes in Computer Science series by Springer-Verlag. All the full papers accepted before the workshop will automatically appear in that book as well; there will be no additional refereeing (although authors will be given a chance to revise their paper, if they so wish, based upon the feedback from the LOPSTR event). Program Committee * Gilles Barthe (France) * Annalisa Bossi (Italy) * Maurice Bruynooghe (Belgium) * Francisco Bueno (Spain) * Giorgio Delzanno (Italy) * Tom Ellman (USA) * Sandro Etalle (The Netherlands) program chair * Norbert Fuchs (Switzerland) * Gopal Gupta (USA) * Patricia M. Hill (UK) * Kung-Kiu Lau (UK) * Fabio Martinelli (Italy) * Alberto Pettorossi (Italy) * Andreas Podelski (Germany) * C.R. Ramakrishnan (USA) * Abhik Roychoudhury (Singapore) * Wim Vanhoof (Belgium) * German Vidal (Spain) Important dates * submission deadline for extended abstracts: May 17, 2004 (extended, strict) * Notification: June 4 * Camera-ready: June 16 Sponsor Lopstr 2004 is sponsored by the Association for Logic Programming (ALP) http::/www.cwi.nl/projects/alp

1 0

Call for Participation: Fourth International Workshop on Reduction Strategies in Rewriting and Programming (WRS'04)
by Salvador Lucas 12 May '04

12 May '04

=============================================================== Final call for participation, WRS'04, June 2, 2004. We apologize for multiple copies of this announcements =============================================================== *************************************** * * * WRS'04 CALL FOR PARTICIPATION * * * *************************************** The Fourth International Workshop on Reduction Strategies in Rewriting and Programming (WRS'04) will be held on June, 2, 2003, in Aachen, Germany, as a part of the Federated Conference on Rewriting, Deduction, and Programming (RDP'04). INVITED TALKS will be given by: * Olivier Danvy (University of Aarhus, Denmark), Normalization by Evaluation * Jan Willem Klop (Vrije Universiteit Amsterdam, The Netherlands), Reduction Cycles ROUND TABLE Strategies in Programming Languages Today * Moderator: Salvador Lucas * Speakers: Francisco Duran, Claude Kirchner, Ralf Laemmel PROGRAM Reduction Cycles (invited talk) Jan Willem Klop Autowrite: A Tool for Term Rewrite Systems and Tree Automata Irene Durand Integrating Decision Procedures in Reflective Rewriting-Based Theorem Provers Manuel Clavel, Miguel Palomino, Juan Santa-Cruz Some Undecidable Approximations of TRSs Jeroen Ketema Normalization by Evaluation (invited talk) Olivier Danvy Invariant-Driven Strategies for Maude Francisco Duran, Manuel Roldan and Antonio Vallecillo DS-forest: A Data Structure for Fast Normalization and Efficiently Implementing Strategies (position paper) Rakesh Verma and James Thigpen Strategies in Programming Languages Today (round table) Salvador Lucas moderator Maude's Internal Strategies (round table paper) Francisco Duran Strategic Rewriting (round table paper) Claude Kirchner Programmable rewriting strategies in Haskell (round table paper) Ralf Laemmel WEBSITE http://www-i2.informatik.rwth-aachen.de/WRS04/ For further questions please contact the program co-chairs: Sergio Antoy and Yoshihito Toyama at wrs04(a)redstar.cs.pdx.edu.

1 0

[Haskell] Call for Participation: Fourth International Workshop on Reduction Strategies in Rewriting and Programming (WRS'04)
by Sergio Antoy 10 May '04

10 May '04

=============================================================== Final call for participation, WRS'04, June 2, 2004. We apologize for multiple copies of this announcements =============================================================== *************************************** * * * WRS'04 CALL FOR PARTICIPATION * * * *************************************** The Fourth International Workshop on Reduction Strategies in Rewriting and Programming (WRS'04) will be held on June, 2, 2003, in Aachen, Germany, as a part of the Federated Conference on Rewriting, Deduction, and Programming (RDP'04). INVITED TALKS will be given by: * Olivier Danvy (University of Aarhus, Denmark), Normalization by Evaluation * Jan Willem Klop (Vrije Universiteit Amsterdam, The Netherlands), Reduction Cycles ROUND TABLE Strategies in Programming Languages Today * Moderator: Salvador Lucas * Speakers: Francisco Duran, Claude Kirchner, Ralf Laemmel PROGRAM Reduction Cycles (invited talk) Jan Willem Klop Autowrite: A Tool for Term Rewrite Systems and Tree Automata Irene Durand Integrating Decision Procedures in Reflective Rewriting-Based Theorem Provers Manuel Clavel, Miguel Palomino, Juan Santa-Cruz Some Undecidable Approximations of TRSs Jeroen Ketema Normalization by Evaluation (invited talk) Olivier Danvy Invariant-Driven Strategies for Maude Francisco Duran, Manuel Roldan and Antonio Vallecillo DS-forest: A Data Structure for Fast Normalization and Efficiently Implementing Strategies (position paper) Rakesh Verma and James Thigpen Strategies in Programming Languages Today (round table) Salvador Lucas moderator Maude's Internal Strategies (round table paper) Francisco Duran Strategic Rewriting (round table paper) Claude Kirchner Programmable rewriting strategies in Haskell (round table paper) Ralf Laemmel WEBSITE http://www-i2.informatik.rwth-aachen.de/WRS04/ For further questions please contact the program co-chairs: Sergio Antoy and Yoshihito Toyama at wrs04(a)redstar.cs.pdx.edu.

1 0