Results 11  20
of
41
Semantics of fixIO
, 2001
"... Recent work on recursion over the values of monadic actions resulted in the introduction of a family of fixed point operators, one for each di#erent kind of monadic e#ect. In the context of Haskell, the function fixIO is the corresponding operator for the IO monad. Unfortunately, both the IO monad a ..."
Abstract

Cited by 6 (3 self)
 Add to MetaCart
Recent work on recursion over the values of monadic actions resulted in the introduction of a family of fixed point operators, one for each di#erent kind of monadic e#ect. In the context of Haskell, the function fixIO is the corresponding operator for the IO monad. Unfortunately, both the IO monad and fixIO are language primitives in Haskell, i.e. they can not be defined within the language itself. Therefore, any attempt to formally reason about fixIO is futile without a precise semantics for computations in the IO monad. Quite recently, Peyton Jones introduced an operational semantics based on observable transitions as a method for reasoning about I/O in Haskell. Building on this work, we show how one can model fixIO as well, and we argue that it indeed belongs to the family of fixed point operators that enable monadic value recursion.
Matrices As Arrows! A Biproduct Approach to Typed Linear Algebra
 in: Mathematics of Program Construction
"... Abstract. Motivated by the need to formalize generation of fast running code for linear algebra applications, we show how an indexfree, calculational approach to matrix algebra can be developed by regarding matrices as morphisms of a category with biproducts. This shifts the traditional view of m ..."
Abstract

Cited by 6 (4 self)
 Add to MetaCart
(Show Context)
Abstract. Motivated by the need to formalize generation of fast running code for linear algebra applications, we show how an indexfree, calculational approach to matrix algebra can be developed by regarding matrices as morphisms of a category with biproducts. This shifts the traditional view of matrices as indexed structures to a typelevel perspective analogous to that of the pointfree algebra of programming. The derivation of fusion, cancellation and abide laws from the biproduct equations makes it easy to calculate algorithms implementing matrix multiplication, the kernel operation of matrix algebra, ranging from its divideandconquer version to the conventional, iterative one. From errant attempts to learn how particular products and coproducts emerge from biproducts, we not only rediscovered blockwise matrix combinators but also found a way of addressing other operations calculationally such as e.g. Gaussian elimination. A strategy for addressing vectorization along the same lines is also given. 1
Type Inference for FirstClass Messages with Feature Constraints
 International Journal of Foundations of Computer Science
, 1998
"... We present a constraint system OF of feature trees that is appropriate to specify and implement type inference for firstclass messages. OF extends traditional systems of feature constraints by a selection constraint xhyiz "by firstclass feature tree" y, in contrast to the standard sel ..."
Abstract

Cited by 5 (0 self)
 Add to MetaCart
We present a constraint system OF of feature trees that is appropriate to specify and implement type inference for firstclass messages. OF extends traditional systems of feature constraints by a selection constraint xhyiz "by firstclass feature tree" y, in contrast to the standard selection constraint x[ f ]y "by fixed feature" f . We investigate the satisfiability problem of OF and show that it can be solved in polynomial time, and even in quadratic time in an important special case. We compare OF with Treinen's constraint system EF of feature constraints with firstclass features, which has an NPcomplete satisfiability problem. This comparison yields that the satisfiability problem for OF with negation is NPhard. Based on OF we give a simple account of type inference for firstclass messages in the spirit of Nishimura's recent proposal, and we show that it has polynomial time complexity: We also highlight an immediate extension that is desirable but makes type inference NPhard.
Continuations for Parallel Logic Programming
 In Proc. of 2nd International ACMSIGPLAN Conference on Principles and practice of Declarative Programming (PPDP’00
, 2000
"... This paper gives denotational models for three logic programming languages of progressive complexity, adopting the \logic programming without logic" approach. The rst language is the control ow kernel of sequential Prolog, featuring sequential composition and backtracking. A committedchoice con ..."
Abstract

Cited by 4 (3 self)
 Add to MetaCart
(Show Context)
This paper gives denotational models for three logic programming languages of progressive complexity, adopting the \logic programming without logic" approach. The rst language is the control ow kernel of sequential Prolog, featuring sequential composition and backtracking. A committedchoice concurrent logic language with parallel composition (parallel AND) and don't care nondeterminism is studied next. The third language is the core of Warren's basic Andorra model, combining parallel composition and don't care nondeterminism with two forms of don't know nondeterminism (interpreted as sequential and parallel OR) and favoring deterministic over nondeterministic computation. We show that continuations are a valuable tool in the analysis and design of semantic models for both sequential and parallel logic programming. Instead of using mathematical notation, we use the functional programming language Haskell as a metalanguage for our denotational semantics, and employ monads in order to facilitate the transition from one language under study to another. Keywords Parallel logic programming, basic Andorra model, denotational semantics, continuations, monads, Haskell. 1.
Labelled BNF: a highlevel formalism for defining wellbehaved programming languages
 Proceedings of the Estonian Academy of Sciences: Physics and Mathematics, 52:356–377
, 2003
"... Abstract This paper introduces the grammar formalism Labelled BNF (LBNF), and the compiler construction tool BNF Converter. Given a grammar written in LBNF, the BNF Converter produces a complete compiler front end (up to, but excluding, type checking), i.e. a lexer, a parser, and an abstract syntax ..."
Abstract

Cited by 3 (2 self)
 Add to MetaCart
(Show Context)
Abstract This paper introduces the grammar formalism Labelled BNF (LBNF), and the compiler construction tool BNF Converter. Given a grammar written in LBNF, the BNF Converter produces a complete compiler front end (up to, but excluding, type checking), i.e. a lexer, a parser, and an abstract syntax definition. Moreover, it produces a prettyprinter and a language specification in LATEX, as well as a template file for the compiler back end. A language specification in LBNF is completely declarative and therefore portable. It reduces dramatically the effort of implementing a language. The price to pay is that the language must be &quot;wellbehaved&quot;, i.e. that its lexical structure must be describable by a regular expression and its syntax by a contextfree grammar.
PType system: A featherweight parallelizability detector
 IN PROCEEDINGS OF 2ND ASIAN SYMPOSIUM ON PROGRAMMING LANGUAGES AND SYSTEMS (APLAS 2004), LNCS 3302
, 2004
"... Parallel programming is becoming an important cornerstone of general computing. In addition, type systems have significant impact on program analysis. In this paper, we demonstrate an automated typebased system that soundly detects parallelizability of sequential functional programs. Our type infer ..."
Abstract

Cited by 3 (2 self)
 Add to MetaCart
Parallel programming is becoming an important cornerstone of general computing. In addition, type systems have significant impact on program analysis. In this paper, we demonstrate an automated typebased system that soundly detects parallelizability of sequential functional programs. Our type inference system discovers the parallelizability property of a sequential program in a modular fashion, by exploring a ring structure among the program’s operators. It handles selfrecursive functions with accumulating parameters, as well as a class of nonlinear mutualrecursive functions. Programs whose types are inferred to be parallelizable can be automatically transformed to parallel code in a mutumorphic form – a succint model for parallel computation. Transforming into such a form is an important step towards constructing efficient data parallel programs.
Tejfel M.: Proving Invariants of Functional Programs
 Proceedings of Eighth Symposium on Programming Languages and Software Tools
, 2003
"... Abstract. In a pure functional language like Clean the values of the functional variables are constants; variables of functional programs do not change in time. Hence it seems that temporality has no meaning in functional programs. However, in certain cases (e.g. in interactive or distributed progra ..."
Abstract

Cited by 2 (1 self)
 Add to MetaCart
(Show Context)
Abstract. In a pure functional language like Clean the values of the functional variables are constants; variables of functional programs do not change in time. Hence it seems that temporality has no meaning in functional programs. However, in certain cases (e.g. in interactive or distributed programs, or in ones that use IO) we would like to consider a series of values computed from each other as different states of the same “abstract object”. For this abstract object we can already prove temporal properties. In this paper we present the concept of object abstraction and show how to interpret and prove temporal properties of functional programs. 1
M.: Verifying invariants of abstract functional objects — a case study
 6th International Conference on Applied Informatics
"... In a pure functional language like Clean the values of the functional variables are constants; variables of functional programs do not change in time. Hence it seems that temporality has no meaning in functional programs. However, in certain cases (e.g. in interactive or distributed programs, or in ..."
Abstract

Cited by 2 (1 self)
 Add to MetaCart
In a pure functional language like Clean the values of the functional variables are constants; variables of functional programs do not change in time. Hence it seems that temporality has no meaning in functional programs. However, in certain cases (e.g. in interactive or distributed programs, or in ones that use IO) we would like to consider a series of values object we can already prove temporal properties (e.g. invariants). In this paper we present a case study: our example is an interactive database with some simple operations like updating, sorting, querying records. We specify an invariant property of our program and we show how to prove this property. We utilize Sparkle, a theorem prover designed for the Clean language. Since Sparkle is not capable of handling temporal logical properties, the application of certain rules of the proof system are performed by hand. This way we simulate the behaviour of a more sophisticated theorem prover, which is currently under development.
Parallelizing MCPHaskell for Evaluating Haskel# Parallel Programming Environment
 SIMPÓSIO BRASILEIRO EM ARQUITETURA DE COMPUTADORES E PROCESSAMENTO DE ALTO DESEMPENHO (SBACPAD'2001)
, 2001
"... In this paper, we present the parallelization of a sequential functional implementation of a Monte Carlo Transport Problem, called MCP Haskell[Hammes et al., 1995], using Haskell# . This experiment gave us important feedback for evaluating Haskell# features, helping us to answer some questions, lik ..."
Abstract

Cited by 2 (2 self)
 Add to MetaCart
In this paper, we present the parallelization of a sequential functional implementation of a Monte Carlo Transport Problem, called MCP Haskell[Hammes et al., 1995], using Haskell# . This experiment gave us important feedback for evaluating Haskell# features, helping us to answer some questions, like how expressive is Haskell# for representing known parallel computational patterns, how easy it is to build large scale parallel programs in an elegant and concise way, and how efficient are Haskell# programs. Based on our conclusions, we suggest new features to be incorporated in Haskell# to improve its expressiveness and performance. We also present the performance figures for the MCPHaskell# benchmark.
Efficiently Generating Structurally Complex Inputs with Thousands of Objects
"... Abstract. We present Shekoosh, a novel framework for constraintbased generation of structurally complex inputs of large sizes. Given a Java predicate that represents the desired structural integrity constraints, Shekoosh systematically explores the input space of the predicate and generates inputs ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
(Show Context)
Abstract. We present Shekoosh, a novel framework for constraintbased generation of structurally complex inputs of large sizes. Given a Java predicate that represents the desired structural integrity constraints, Shekoosh systematically explores the input space of the predicate and generates inputs that satisfy the given constraints. While the problem of generating an input that satisfies all the given constraints is hard, generating a structure at random, which may not satisfy the constraints but has a desired number of objects is straightforward. Indeed, a structure generated at random is highly unlikely to satisfy any of the desired constraints. However, it can be repaired to transform it so that it satisfies all the desired constraints. Experiments show that Shekoosh can efficiently generate structures that are up to 100 times larger than those possible with previous algorithms, including those that are based on a dedicated search and also those that use offtheshelf enumerating SAT solvers.