KiCS2: A New Compiler from Curry to Haskell

Braßel, Bernd; Hanus, Michael; Peemöller, Björn; Reck, Fabian

doi:10.1007/978-3-642-22531-4_1

Cited by 45 publications

(80 citation statements)

References 33 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Since this transformation is performed on FlatCurry programs, it can be easily integrated into the compilation chain for Curry programs. In fact, the transformation is fully integrated into the current releases of the Curry systems PAKCS [19] and KiCS2 [10].…”

Section: Methodsmentioning

confidence: 99%

“…For instance, the expression time since non-deterministic search is transformed to deterministic bindings, as demonstrated by some benchmarks. We used the Curry implementation KiCS2 [10] for the benchmarks. KiCS2 evaluates the Boolean equality operator by narrowing with the "==" rules shown in Sect.…”

Section: Methodsmentioning

confidence: 99%

“…Since Curry with all its syntactic sugar (we have only presented a small fragment of it) is a quite rich source language, a simpler intermediate representation of Curry programs has been shown to be useful to describe the operational semantics [1], compile programs [10,19], or implement analyzers [20] and similar tools. Programs of this intermediate language, called FlatCurry, contain a single rule for each function where the pattern matching strategy is represented by case expressions.…”

Section: Functional Logic Programming and Currymentioning

confidence: 99%

“…As mentioned above, the transformation tool is integrated into the compilation chain of the recent releases of the Curry systems PAKCS [19] and KiCS2 [10]. The configuration files of these systems allow the user to set the following usage modes: "off" (do not apply this transformation), "full" (analyze programs as described in Sect.…”

Section: Practical Evaluationmentioning

confidence: 99%

See 3 more Smart Citations

From Boolean Equalities to Constraints

Antoy

Hanus

2015

Logic-Based Program Synthesis and Transformation

Self Cite

View full text Add to dashboard Cite

Abstract. Although functional as well as logic languages use equality to discriminate between logically different cases, the operational meaning of equality is different in such languages. Functional languages reduce equational expressions to their Boolean values, True or False, logic languages use unification to check the validity only and fail otherwise. Consequently, the language Curry, which amalgamates functional and logic programming features, offers two kinds of equational expressions so that the programmer has to distinguish between these uses. We show that this distinction can be avoided by providing an analysis and transformation method that automatically selects the appropriate operation. Without this distinction in source programs, the language design can be simplified and the execution of programs can be optimized. As a consequence, we show that one kind of equational expressions is sufficient and unification is nothing else than an optimization of Boolean equality. MotivationFunctional as well as logic programming languages are based on the common idea to specify computational problems in a high-level and descriptive manner. However, the computational entities and, thus, the programming styles are different. This can be seen in a prominent feature of such languages: the discrimination between logically different cases of a given problem. Functional (as well as imperative) languages use Boolean equations for this purpose, i.e., an equational expression is reduced to either True or False and, depending on the computed result, a different computation path is selected. A typical example is the factorial function where the base case is distinguished from the recursive case by comparing the argument with 0: 1 fac n = if n==0 then 1 else n * fac (n-1) The equality symbol "=" used in this program is different from the Boolean equality "==" above. For instance, in the first rule it is not intended to evaluate X=[] to True or False, but this equality must hold to proceed with this rule, i.e., it is a constraint for subsequent evaluation steps. As a consequence, it is not necessary to fully evaluate equational expressions but one can continue a computation even with partial knowledge, as long as the constraint is ensured to hold. For instance, if we want to ensure that a list L ends with the element 0, we can write Functional logic languages attempt to combine the most important features of functional and logic programming in a single language (see [5,18] for recent surveys). In particular, the functional logic language Curry [21] extends Haskell by common features of logic programming, i.e., non-determinism, free variables, and equational constraints. Due to its roots in functional and logic programming, Curry provides two kinds of equalities: Boolean equality ("==") as in functional programming and equational constraints ("=:=") as in logic programming. The motivation for this decision is to support nested case distinctions, like in functional programming, as well as rule-oriented programming with partial i...

show abstract

Section: Methodsmentioning

confidence: 99%

Section: Methodsmentioning

confidence: 99%

Section: Functional Logic Programming and Currymentioning

confidence: 99%

Section: Practical Evaluationmentioning

confidence: 99%

See 2 more Smart Citations

From Boolean Equalities to Constraints

Antoy

Hanus

2015

Logic-Based Program Synthesis and Transformation

Self Cite

View full text Add to dashboard Cite

show abstract

“…Our work principally relates to the implementation of functional logic languages [19,21,22,24,30,45]. This is a long-standing and active area of research whose difficulties originate from the combination of laziness, non-determinism and sharing [41].…”

Section: Related Workmentioning

confidence: 99%

Compiling a Functional Logic Language: The Fair Scheme

Antoy

Jost

2014

Logic-Based Program Synthesis and Transformation

View full text Add to dashboard Cite

Abstract. We present a compilation scheme for a functional logic programming language. The input program to our compiler is a constructor-based graph rewriting system in a non-confluent, but well-behaved class. This input is an intermediate representation of a functional logic program in a language such as Curry or T OY. The output program from our compiler consists of three procedures that make recursive calls and execute both rewrite and pull-tab steps. This output is an intermediate representation that is easy to encode in any number of programming languages. Our design evolves the Basic Scheme of Antoy and Peters by removing the "left bias" that prevents obtaining results of some computations-a behavior related to the order of evaluation, which is counter to declarative programming. The benefits of this evolution are not only the strong completeness of computations, but also the provability of non-trivial properties of these computations. We rigorously describe the compiler design and prove some of its properties. To state and prove these properties, we introduce novel definitions of "need" and "failure." For non-confluent constructor-based rewriting systems these concepts are more appropriate than the classic definition of need of Huet and Levy.

show abstract

Non-linear Pattern Matching with Backtracking for Non-free Data Types

Egi

Nishiwaki

2018

Programming Languages and Systems

View full text Add to dashboard Cite

Pattern matching is an important feature of programming languages for data abstraction. Many pattern-matching extensions have been proposed and implemented for extending the range of data types to which pattern matching is applicable. Among them, the pattern-matching system proposed by Egi and Nishiwaki features practical pattern matching for non-free data types by providing an extensible non-linear pattern-matching facility with backtracking [20]. However, they implemented their proposal only in an interpreter of the Egison programming language, and a method for compiling pattern-matching expressions of Egison was not discussed. This paper proposes a method for translating a program that contains patternmatching expressions of Egison to a program that contains only the existing syntax constructs of functional programming languages. This method is based on the three key ideas: (i) transformation of a matcher to a function that takes a pattern and a target, and returns lists of triples of a pattern, a matcher, and a target; (ii) compilation of match-all to application of the map function; (iii) transformation of a value pattern to a function that takes an intermediate pattern-matching result and returns a value. This paper shows the proposed method works by showing Scheme macros that provide the users the patternmatching facility of Egison. This paper also presents benchmark results that show Egison pattern-matching embedded in Gauche Scheme is faster than the original Egison interpreter.

show abstract

KiCS2: A New Compiler from Curry to Haskell

Cited by 45 publications

References 33 publications

From Boolean Equalities to Constraints

From Boolean Equalities to Constraints

Compiling a Functional Logic Language: The Fair Scheme

Non-linear Pattern Matching with Backtracking for Non-free Data Types

Contact Info

Product

Resources

About