Results 1  10
of
10
The Expressive Power of Higherorder Types or, Life without CONS
, 2001
"... Compare firstorder functional programs with higherorder programs allowing functions as function parameters. Can the the first program class solve fewer problems than the second? The answer is no: both classes are Turing complete, meaning that they can compute all partial recursive functions. In pa ..."
Abstract

Cited by 30 (1 self)
 Add to MetaCart
Compare firstorder functional programs with higherorder programs allowing functions as function parameters. Can the the first program class solve fewer problems than the second? The answer is no: both classes are Turing complete, meaning that they can compute all partial recursive functions. In particular, higherorder values may be firstorder simulated by use of the list constructor ‘cons’ to build function closures. This paper uses complexity theory to prove some expressivity results about small programming languages that are less than Turing complete. Complexity classes of decision problems are used to characterize the expressive power of functional programming language features. An example: secondorder programs are more powerful than firstorder, since a function f of type &lsqb;Bool&rsqb;〉Bool is computable by a consfree firstorder functional program if and only if f is in PTIME, whereas f is computable by a consfree secondorder program if and only if f is in EXPTIME. Exact characterizations are given for those problems of type &lsqb;Bool&rsqb;〉Bool solvable by programs with several combinations of operations on data: presence or absence of constructors; the order of data values: 0, 1, or higher; and program control structures: general recursion, tail recursion, primitive recursion.
Database Query Languages Embedded in the Typed Lambda Calculus
, 1993
"... We investigate the expressive power of the typed calculus when expressing computations over finite structures, i.e., databases. We show that the simply typed calculus can express various database query languages such as the relational algebra, fixpoint logic, and the complex object algebra. In ..."
Abstract

Cited by 28 (6 self)
 Add to MetaCart
We investigate the expressive power of the typed calculus when expressing computations over finite structures, i.e., databases. We show that the simply typed calculus can express various database query languages such as the relational algebra, fixpoint logic, and the complex object algebra. In our embeddings, inputs and outputs are terms encoding databases, and a program expressing a query is a term which types when applied to an input and reduces to an output.
Space Usage in Functional Query Languages
 in &quot;LNCS 893: Proceedings of 5th International Conference on Database Theory,&quot; 439454
, 1995
"... We consider evaluation strategies for database queries expressed in three functional query languages: the complex value algebra, the simply typed lambda calculus, and method schemas. Each of these query languages derives its expressive power from a different primitive: the complex value algebra fr ..."
Abstract

Cited by 15 (2 self)
 Add to MetaCart
We consider evaluation strategies for database queries expressed in three functional query languages: the complex value algebra, the simply typed lambda calculus, and method schemas. Each of these query languages derives its expressive power from a different primitive: the complex value algebra from the powerset operator, the simply typed lambda calculus from list iteration, and method schemas from recursion. We show that "natural" evaluation strategies for these primitives may lead to very inefficient space usage, but that with some simple optimizations many queries can be evaluated with little or no space overhead. In particular, we show: (1) In the complex value algebra, all expressions with set nesting depth at most 2 can be evaluated in pspace, and this set of expressions is sufficient to express all queries in the polynomial hierarchy; (2) In the simply typed lambda calculus with equality and constants, all query terms of order at most 5 (where "query term" is a syntactic condition on types) can be evaluated in pspace, and this set of terms expresses exactly the pspace queries; (3) There exists a set of secondorder method schemas (with no simple syntactic characterization) that can be evaluated in pspace, and this set of schemas is sufficient to express all pspace queries.
Functional Database Query Languages as Typed Lambda Calculi of Fixed Order (Extended Abstract)
 In Proceedings 13th PODS
, 1994
"... We present a functional framework for database query languages, which is analogous to the conventional logical framework of firstorder and fixpoint formulas over finite structures. We use atomic constants of order 0, equality among these constants, variables, application, lambda abstraction, and le ..."
Abstract

Cited by 13 (5 self)
 Add to MetaCart
We present a functional framework for database query languages, which is analogous to the conventional logical framework of firstorder and fixpoint formulas over finite structures. We use atomic constants of order 0, equality among these constants, variables, application, lambda abstraction, and let abstraction; all typed using fixed order ( 5) functionalities. In this framework, proposed in [21] for arbitrary order functionalities, queries and databases are both typed lambda terms, evaluation is by reduction, and the main programming technique is list iteration. We define two families of languages: TLI = i or simplytyped list iteration of order i +3 with equality, and MLI = i or MLtyped list iteration of order i+3 with equality; we use i+3 since our list representation of databases requires at least order 3. We show that: FOqueries ` TLI = 0 ` MLI = 0 ` LOGSPACEqueries ` TLI = 1 = MLI = 1 = PTIMEqueries ` TLI = 2 , where equality is no longer a primitive in TLI = 2 . We also show that ML type inference, restricted to fixed order, is polynomial in the size of the program typed. Since programming by using low order functionalities and type inference is common in functional languages, our results indicate that such programs suffice for expressing efficient computations and that their MLtypes can be efficiently inferred.
On the expressive power of simply typed and letpolymorphic lambda calculi
 11th Annual IEEE Symp. on Logic in Computer Science (LICS'96)
, 1996
"... We present a functional framework for descriptive computational complexity, in which the Regular, Firstorder, Ptime, Pspace, kExptime, kExpspace (k 1), and Elementary sets have syntactic characterizations. In this framework, typed lambda terms represent inputs and outputs as well as programs. The ..."
Abstract

Cited by 9 (0 self)
 Add to MetaCart
We present a functional framework for descriptive computational complexity, in which the Regular, Firstorder, Ptime, Pspace, kExptime, kExpspace (k 1), and Elementary sets have syntactic characterizations. In this framework, typed lambda terms represent inputs and outputs as well as programs. The lambda calculi describing the above computational complexity classes are simply or letpolymorphically typed with functionalities of fixed order. They consist of: order 0 atomic constants, order 1 equality among these constants, variables, application, and abstraction. Increasing functionality order by one for these languages corresponds to increasing the computational complexity by one alternation. This exact correspondence is established using a semantic evaluation of languages for each fixed order, which is the primary technical contribution of this paper.
An Analysis of the CoreML Language: Expressive Power and Type Reconstruction
 In Proc. 21st Int'l Coll. Automata, Languages, and Programming
, 1994
"... CoreML is a basic subset of most functional programming languages. It consists of the simply typed (or monomorphic) calculus, simply typed equality over atomic constants, and let as the only polymorphic construct. We present a synthesis of recent results which characterize this "toy" ..."
Abstract

Cited by 5 (3 self)
 Add to MetaCart
CoreML is a basic subset of most functional programming languages. It consists of the simply typed (or monomorphic) calculus, simply typed equality over atomic constants, and let as the only polymorphic construct. We present a synthesis of recent results which characterize this "toy" language's expressive power as well as its type reconstruction (or type inference) problem. More specifically: (1) CoreML can express exactly the ELEMENTARY queries, where a program input is a database encoded as a term and a query program is a term whose application to the input normalizes to the output database. In addition, it is possible to express all the PTIME queries so that this normalization process is polynomial in the input size. (2) The polymorphism of let can be explained using a simple algorithmic reduction to monomorphism, and provides flexibility, without affecting expressibility. Algorithms for type reconstruction offer the additional convenience of static typing without type declarations. Given polymorphism, the price of this convenience is an increase in complexity from lineartime in the size of the program typed (without let) to completeness in exponentialtime (with let).
The Complexity of Higherorder Queries
"... Higherorder transformations are ubiquitous within data management. In relational databases, higherorder queries appear in numerous aspects including query rewriting and query specification. This work investigates languages that combine higherorder transformations with ordinary relational databas ..."
Abstract
 Add to MetaCart
(Show Context)
Higherorder transformations are ubiquitous within data management. In relational databases, higherorder queries appear in numerous aspects including query rewriting and query specification. This work investigates languages that combine higherorder transformations with ordinary relational database query languages. We study the two most basic computational problems associated with these query languages – the evaluation problem and the containment problem. We isolate the complexity of evaluation at every order, in an analysis similar to that for that standard typed lambda calculus. We show that the containment problem (and hence, the equivalence problem) is decidable in several important subcases, particularly in the case where query constants and variables range over the positive relational operators. The main decidability result relies on techniques that differ from those used in classical query containment. We also show that the analysis of higherorder queries is closely connected to the evaluation and containment problems for nonrecursive Datalog. 1.
General Terms
"... While relational algebra and calculus are a wellestablished foundation for classical database query languages, it is less clear what the analog is for higherorder functions, such as query transformations. Here we study a natural way to add higherorder functionality to query languages, by adding d ..."
Abstract
 Add to MetaCart
(Show Context)
While relational algebra and calculus are a wellestablished foundation for classical database query languages, it is less clear what the analog is for higherorder functions, such as query transformations. Here we study a natural way to add higherorder functionality to query languages, by adding database query operators to the λcalculus as constants. This framework, which we refer to as λembedded query languages, was introduced in [BPV10]. That work had a restricted focus: the containment and equivalence problems for querytoquery functions, in the case where only positive relational operators are allowed as constants. In this work we take an indepth look at the most basic issue for such languages: the evaluation problem. We give a full picture of the complexity of evaluation for λembedded query languages, looking at a number of variations: with negation and without; with only relational algebra operators, and also with a recursion mechanism in the form of a query iteration operator; in a stronglytyped calculus as well as a weaklytyped one. We give tight bounds on both the combined complexity and the query complexity of evaluation in all these settings, in the process explaining connections with Datalog and prior work on λcalculus evaluation.