May 2004 - Haskell - Haskell.org

Queues / Lists with unbound tails
by andrew cooke 18 May '04

18 May '04

Hi, I'm trying to write a simple fifo queue of fixed length (containing type Maybe a - it would be initialised to Nothings) where pushing an item pops the "last" item "off the end". data Queue a = QUEUE (Maybe a -> (Queue a, Maybe a)) queue :: Maybe a -> Queue a queue n1 = QUEUE (\n2 -> (queue n2, n1)) consQ :: Queue a -> Queue a -> Queue a consQ (QUEUE q1) (QUEUE q2) = QUEUE (\n -> let (q1', n1) = q1 n (q2', n2) = q2 n1 in (consQ q1' q2', n2)) works, and lets me construct arbitrary length queues, but the push/pop operation is O(n) (I believe) in the length of the queue. I don't have Okasaki's book with me, but I'm pretty sure he gives a solution that has two lists, with the second inverted via an operation that is either amortized O(1), or inverted stepwise using lazy evaluation. However, it seems to me that there should be another solution, with a lazily constructed list whose tail does not yet exist. The queue would consiste of the head of the list (which is the "tail" of the queue!) and a closure that extends the list tail (ie the queue head). Pushing an element would involve invoking the closure, extending the tail of the (lazily constructed) list, and returning another closure to continue the process. The return ("pop") value would be the head of the list, with the next item carried forward as the next return value. I think this would be simple to implement in Prolog or Oz, for example, where the last element of a list can be unbound. I assume the same is possible in Haskell using laziness and closures. However, I cannot nail it down. Can anyone help? Apologies for the unclear description. If I could describe the solution clearly then I could write the code and wouldn't need to ask :o) Thanks, Andrew -- ` __ _ __ ___ ___| |_____ work web site: http://www.ctio.noao.edu/~andrew / _` / _/ _ \/ _ \ / / -_) personal web site: http://www.acooke.org/andrew \__,_\__\___/\___/_\_\___| list: http://www.acooke.org/andrew/compute.html

3 6

Updates using Field Labels
by Gregory Wright 17 May '04

17 May '04

Hi, I have a program that processes files and builds up records for later insertion into a database. (The actual program uses a lexer and some helper functions to extract the necessary information from the files; the attached program reproduces the behavior in question.) When I run the real program or the attached sample program I get the error Fail: ios.hs:50: Missing field in record construction Main.sigPriority (This is using GHC-6.2.1 on Mac OS X 10.3.3 built from darwinports.) I don't understand the reason for this error message. It seems to be more constraining than my reading of section 3.15.3 of the Report (Updates Using Field Labels). There is a workaround: explicitly update the field sigPriority. I had hoped that that would not be necessary. Could someone explicate this? Best Wishes, Greg Gregory Wright Antiope Associates LLC gwright(a)antiope.com

2 3

ANNOUNCE: cpphs-0.2
by Malcolm Wallace 17 May '04

17 May '04

cpphs-0.2 --------- Cpphs is a re-implementation (in Haskell) of the C pre-processor. Version 0.1 dealt only with conditional compilation (#if and friends) and file inclusion (#include). Version 0.2 now also implements the rest of cpp's functionality, namely in-line symbol replacement and macro expansion (#define and friends). I believe this to be a reasonably complete and correct implementation, and have tested it on some non-trivial examples from the standard libraries (e.g. Foreign.Storable and HOpenGL). Nevertheless, there will be bugs and I encourage you to find them and report them. http://www.cs.york.ac.uk/fp/cpphs/ ---- Why re-implement cpp? Rightly or wrongly, the C pre-processor is widely used in Haskell source code. It enables conditional compilation for different compilers, different versions of the same compiler, and different OS platforms. It is also occasionally used for its macro language, which can enable certain forms of platform-specific detail-filling, such as the tedious boilerplate generation of instance definitions and FFI declarations. However, there are two problems with cpp, aside from the obvious aesthetic ones: * For some Haskell systems, notably Hugs on Windows, a true cpp is not available by default. * Even for the other Haskell systems, the common cpp provided by the gcc 3.x series is changing subtly in ways that are incompatible with Haskell's syntax. There have always been problems with, for instance, string gaps, and prime characters in identifiers. These problems are only going to get worse. So, it seemed right to attempt to provide an alternative to cpp, both more compatible with Haskell, and itself written in Haskell so that it can be distributed with compilers. Share and Enjoy, Malcolm

3 2

SOS Workshop - final CfP
by Wan.Fokkink＠cwi.nl 17 May '04

17 May '04

Call for Papers Structural Operational Semantics http://www.cs.auc.dk/~luca/SOS-WORKSHOP/ A Satellite Workshop of CONCUR 2004 30 August, 2004, London, United Kingdom Structural operational semantics (SOS) provides a framework for giving operational semantics to programming and specification languages. A growing number of programming languages from commercial and academic spheres have been given usable semantic descriptions by means of structural operational semantics. Because of its intuitive appeal and flexibility, structural operational semantics has found considerable application in the study of the semantics of concurrent processes. Moreover, it is becoming a viable alternative to denotational semantics in the static analysis of programs, and in proving compiler correctness. Recently, structural operational semantics has been successfully applied as a formal tool to establish results that hold for classes of process description languages. This has allowed for the generalization of well-known results in the field of process algebra, and for the development of a meta-theory for process calculi based on the realization that many of the results in this field only depend upon general semantic properties of language constructs. The proposed SOS workshop aims to be a forum for researchers, students and practitioners interested in new developments and directions for future investigation in the field of structural operational semantics. One of the specific goals of the workshop is to establish synergies between the concurrency and programming language communities working on the theory and practice of SOS. The workshop will also mark the publication of a special issue of the Journal of Logic and Algebraic Programming, devoted to SOS. Together with original research papers on SOS, this special issue will feature a definitive version of Gordon Plotkin's 1981 DAIMI memo on SOS, together with a piece by Plotkin on the origins of SOS. Specific topics of interest include (but are not limited to): * programming languages * process algebras * higher-order formalisms * rule formats for operational specifications * meaning of operational specifications * comparisons between denotational, axiomatic and SOS * compositionality of modal logics with respect to operational specifications * congruence with respect to behavioural equivalences * conservative extensions * derivation of proof rules from operational specifications * software tools that automate, or are based on, SOS Papers reporting on applications of SOS to software engineering and other areas of computer science are welcome. Paper submission: We solicit unpublished papers reporting on original research on the general theme of SOS. Prospective authors are invited to submit a pdf or postscript file with their extended abstract, whose length should not exceed 15 pages, by email to all of the co-chairs at their respective email addresses. The email message with the submission should also include, in plain text, contact information for the author(s), together with the title and abstract of the submission. Submissions are to be received by Sunday, 6 June, 2004. Authors will be notified of acceptance by Wednesday, 30 June, 2004. Submissions from the PC members are allowed. Proceedings: Preliminary proceedings containing the abstracts of the talks will be published as a volume in the BRICS Notes Series, and will be available at the meeting. The final proceedings of the workshop will appear as a volume in the ENTCS series. If the quality and quantity of the submissions warrant it, the co-chairs plan to arrange a special issue of an archival journal devoted to full versions of selected papers from the workshop. Important Dates: * Submission: Sunday 6 June 2004 * Notification: Wednesday 30 June 2004 * Final version: Friday July 16 2004 * Workshop: Monday 30 August 2004 Invited Speakers: Andrew Pitts (Cambridge, United Kingdom) Gordon Plotkin (Edinburgh, United Kingdom) (To be confirmed) Program Committee: Luca Aceto (BRICS, Aalborg, Denmark, co-chair) Wan Fokkink (CWI, The Netherlands, co-chair) Rob van Glabbeek (NICTA, Sydney, Australia) Ralf Laemmel (CWI, The Netherlands) Peter Mosses (BRICS, Aarhus, Denmark) David Sands (Chalmers, Sweden) Alex Simpson (Edinburgh, United Kingdom) Simone Tini (Insubria, Italy) Irek Ulidowski (Leicester, United Kingdom, co-chair) Erik de Vink (Eindhoven, The Netherlands) Organizing Committee: Luca Aceto, email: luca AT cs.auc.dk, Wan Fokkink, email: wan AT cwi.nl, Irek Ulidowski, email iu3 AT mcs.le.ac.uk

1 0

FST&TCS 2004 Call for Papers
by R. Ramanujam 16 May '04

16 May '04

---------------------------------------------------------------- FST&TCS 2004 The 24th Conference on Foundations of Software Technology and Theoretical Computer Science December 16--18, 2004, Chennai, INDIA CALL FOR PAPERS * Important dates: Submissions: 21st June 2004 Notification: 20th August 2004 * Satellite Workshops: December 13--15, 2004. Algorithms for dynamic data, coordinated by S. Muthukrishnan and Pankaj Agarwal. Logic for dynamic data, coordinated by Uday Reddy. * Invited Speakers: Javier Esparza Piotr Indyk Pavel Pevzner John C. Reynolds Denis The'rien * For details see: http://www.fsttcs.org/ ----------------------------------------------------------------

1 0

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

16 May '04

>What about > >foo [/ (/ 2 (/ a _ /)* 3 /)* /] = a > >? What is the type of a here? I think it should be [[Int]]. Not quite, the type of a will be [Int]. The only context dependency of variable types is the difference between linear and non-linear contexts. In linear context, variables have the types you would normally expect in standard Haskell. In non-linear context, the type is a list of what it would otherwise be, regardless of what and how many enclosing non-linear regular pattern operators. If you want a full trace of where the items in a come from, you need to do it in several steps: foo [/ (/ 2 b@:(/ _ _ /)* 3 /)* /] = map (map bar) b -- here b :: [[[Int]]] where bar [a, _] = a The reason for b having type [[[Int]]] is that it binds to a pattern of type [[Int]] (a repeating * enclosing a sequence). In general: binding explicitly preserves the trace of the pattern it binds to; binding implicitly preserves no trace at all. To see why this is so, consider the following analogy: bar :: Maybe (Maybe (Maybe Int)) -> (Maybe (Maybe Int), Maybe Int, Int) bar (Just a@(Just b@(Just c))) = (a,b,c) When binding a , you look at the type of the subpattern it binds to. When looking at the value held by a on the right hand side, there is no way to trace the context it appeared in before the pattern match. When binding c, you also look at the subpattern it binds to, i.e. the pattern c is equivalent to the pattern c@_. There is no trace of where it comes from. Now look at this regular pattern: foo [/ a@:(/ _ b@:(/ _ c /) /) /] = (a,b,c) What is the type of foo? Well, the type of c is whatever it binds to, which is just an element of the list (assuming Int). But since it is bound in non-linear context, its type will be [Int]. This form of context dependence is the only one we ever need to consider, where a variable is bound implicitly. And the only question is, does it have a list type or not? Another way to look at it is to see that c is equivalent to c@:_ in non-linear context and c@_ in linear context. b is bound explicitly using the @: operator, so the type of b is a list of whatever it binds to. No context dependence. What it binds to is a a sequence, i.e. a list, so the type of b will be [[Int]]. a is bound explicitly using the @: operator, so the type of a is a list of what it binds to. No context dependece here either. It too binds to a list, so its type will be [[Int]]. Thus, foo :: ([[Int]], [[Int]], [Int]) >And then which special syntax for implicit binding am I supposed to use? >Is it > >foo [/ (/ 2 (/ a@:(/_ _/) _ /)* 3 /)* /] = a > >or maybe > >foo [/ (/ 2 (/ a@::(/_ _/) _ /)* 3 /)* /] = a The former. We have added the @: operator as a a non-linear counterpart of the linear @. Adding more : won't add more levels of lists... >? And what's the type? [[[Int]]]? Not quite right here either, the type will be [[Int]]. The first enclosing list comes from the fact that the subsequence (/ ... /) has type list (whatever will be matched against it is a sequence of items), and the second enclosing list comes from the use of the non-linear binding operator @:. Hopefully I make sense (more than before?). 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? Anyway, thanks for the interest and the comments =) /Niklas _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

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