Error Mining for Regular Expression Patterns

Castagna, Giuseppe; Colazzo, Dario; Frisch, Alain

doi:10.1007/11560586_13

Cited by 7 publications

(7 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This makes error detection quite difficult and the subsequent debugging very hard. And it is made even harder by the fact that, as argued in [18], such errors are not just created by typos-as shown here-but they may be of more conceptual nature.…”

Section: Error Miningmentioning

confidence: 85%

“…It has been shown [18] that the errors of this kind can be formally characterised and statically detected by using the set-theoretic operators of the types and patterns we presented here. In particular given a type t and a pattern p, it is not difficult to…”

Section: Error Miningmentioning

confidence: 99%

“…Finally, the implementation of such a technique in the current type-checkers of, among others, Xtatic, Duce, and XDuce, does not produce any noticeable overhead, since the rewriting can be performed by the normal type inference process itself. Further details are available elsewhere [18].…”

Section: Error Miningmentioning

confidence: 99%

See 2 more Smart Citations

Patterns and Types for Querying XML Documents

Castagna

2005

Database Programming Languages

Self Cite

View full text Add to dashboard Cite

Among various proposals for primitives for deconstructing XML data two approaches seem to clearly stem from practise: path expressions, widely adopted by the database community, and regular expression patterns, mainly developed and studied in the programming language community. We think that the two approaches are complementary and should be both integrated in languages for XML, and we see in that an opportunity of collaboration between the two communities. With this aim, we give a presentation of regular expression patterns and the type systems they are tightly coupled with. Although this article advocates a construction promoted by the programming language community, we will try to stress some characteristics that the database community, we hope, may find interesting.XDuce [40, 39], the ¦ © ¥ ¡ © ! primitive of Duce [4], the ¢ " ¦ § © ¦ § primitive of Xtatic [31], while for other languages, for instance XSLT [22], the iterator is hard-coded in the semantics itself of the language.For what concerns deconstructing primitives, instead, the situation looks clearer since, among various proposals (see the related work section later on), two different and complementary solutions clearly stem from practice: path expressions (usually XPath paths [21], but also the "dot" navigations of Cω or Lorel [1], caterpillar expressions [12] and their "looping" extension [33]) and regular expression patterns [41].Path expressions are navigational primitives that pinpoint where to capture data subcomponents. XML path expressions (and those of Cω and Lorel in particular) closely resemble the homonimic primitives used by OQL [23] in the context of OODB query languages, with the difference that instead of sets of objects they return sets or sequences of XML elements: more precisely all elements that can be reached by following the paths at issue. These primitives are at the basis of standard languages such as XSLT and XQuery.More recently, a new kind of deconstruction primitive was proposed: regular expression patterns [41], which extends by regular expressions the pattern matching primitive as popularised by functional languages such as ML and Haskell. Regular expression patterns were first introduced in the XDuce programming language and are becoming more and more popular, since they are being adopted by such quite different languages as Duce [4] (a general purpose extension of the XDuce language) and its query language QL [5], Xtatic [31] (an extension of C#), Scala [54] (a general purpose Javalike object-oriented language that compiles to Java bytecode), XHaskell [45] as well as the extension of Haskell proposed by Broberg et al. [11].The two kinds of primitives are not antagonist, but rather orthogonal and complementary. Path expressions implement a "vertical" exploration of data as they capture elements that may be at different depths, while patterns perform a "horizontal" exploration of data since they are able to perform finer grained decomposition on sequences of elements. The two kinds of primitives are quite useful and the...

show abstract

Section: Error Miningmentioning

confidence: 85%

Section: Error Miningmentioning

confidence: 99%

See 1 more Smart Citation

Patterns and Types for Querying XML Documents

Castagna

2005

Database Programming Languages

Self Cite

View full text Add to dashboard Cite

show abstract

“…Both can be viewed as a variety of regular expression. The existing analyses are complementary to ours, in that they assume correct syntax and try to determine semantic errors, such as subpatterns that will never match [3,6]. In Wilk and Drabant's type system for Xcerpt, if the application type-checks, it passes a set of test cases; that is, its results are in a given expected set [33].…”

Section: Related Workmentioning

confidence: 98%

A type system for regular expressions

Spishak

Dietl

Ernst

2012

Proceedings of the 14th Workshop on Formal Techniques for Java-Like Programs

View full text Add to dashboard Cite

Regular expressions are used to match and extract text. It is easy for developers to make syntactic mistakes when writing regular expressions, because regular expressions are often complex and different across programming languages. Such errors result in exceptions at run time, and there is currently no static support for preventing them.This paper describes practical experience designing and using a type system for regular expressions. This type system validates regular expression syntax and capturing group usage at compile time instead of at run time -ensuring the absence of PatternSyntaxExceptions from invalid syntax and IndexOutOfBoundsExceptions from accessing invalid capturing groups.Our implementation is publicly available and supports the full Java language. In an evaluation on five open-source Java applications (480kLOC), the type system was easy to use, required less than one annotation per two thousand lines, and found 56 previouslyunknown bugs.

show abstract

“…Further, because JS has no patternmatching construct, there is no need for an analysis of jQuery to define tree patterns or regular tree types (as in [11]), or check exhaustiveness of pattern matching (as in [5]). Instead, as we have shown, a simpler notion suffices.…”

Section: Related Workmentioning

confidence: 99%

Combining Form and Function: Static Types for JQuery Programs

Lerner

Elberty

et al. 2013

ECOOP 2013 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. The jQuery library defines a powerful query language for web applications' scripts to interact with Web page content. This language is exposed as jQuery's a p i, which is implemented to fail silently so that incorrect queries will not cause the program to halt. Since the correctness of a query depends on the structure of a page, discrepancies between the page's actual structure and what the query expects will also result in failure, but with no error traces to indicate where the mismatch occurred. This work proposes a novel type system to statically detect jQuery errors. The type system extends Typed JavaScript with local structure about the page and with multiplicities about the structure of containers. Together, these two extensions allow us to track precisely which nodes are active in a jQuery object, with minimal programmer annotation effort. We evaluate this work by applying it to sample real-world jQuery programs.

show abstract

Error Mining for Regular Expression Patterns

Cited by 7 publications

References 12 publications

Patterns and Types for Querying XML Documents

Patterns and Types for Querying XML Documents

A type system for regular expressions

Combining Form and Function: Static Types for JQuery Programs

Contact Info

Product

Resources

About