Skip to content
Free planNo credit card requiredStart writing
AI for Research home
AI for Research home
Dashboard
Sign inGet started

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 3,623 papers for “imperative programming”

Introducing Imperative Programming

Don Syme, Ádám Gránicz, Antonio Cisternino · Apress eBooks · 2010

In Chapter 3, you saw some of the simple but powerful data types and language constructs that make up F# functional programming. The functional programming paradigm is strongly associated with "programming without side effects," called pure functional programming. In this paradigm, programs compute the result of a mathematical expression and don't cause any side effects, except perhaps reporting the result of the computation. The formulas used in spreadsheets are often pure, as is the core of functional programming languages such as Haskell. F# isn't, however, a pure functional language. For example, you can write programs that mutate data, perform I/O communications, start threads, and raise exceptions. Furthermore, the F# type system doesn't enforce a strict distinction between expressions that perform these actions and expressions that don't.KeywordsPolished CodeFunctional ProgrammingMutable LocalLanguage ConstructTextual StringThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Cited by 0

Lazier Imperative Programming

Rémi Douence, Nicolas Tabareau · 2014

Laziness is a powerful concept in functional programming that enables reusing general functions in a specific context, while keeping performance close to the efficiency of dedicated definitions. Lazy evaluation can be used in imperative programming too. Twenty years ago, John Launchbury was already advocating for lazy imperative programming, but the level of laziness of his framework remained limited: a single effect can trigger numerous delayed computations, even if those are not required for the correctness of the evaluation. Twenty years after, the picture has not changed. In this article, we propose an Haskell framework to specify computational effects of imperative programs as well as their dependencies. Our framework is based on the operational monad transformer which encapsulates an algebraic presentation of effectful operations. A lazy monad transformer is then in charge of delaying non-necessary computations by maintaining a trace of imperative closures. We present a semantics of a call-by-need λ-calculus extended with imperative strict and lazy features and prove the correctness of our approach. While originally motivated by a less rigid use of foreign functions, we show that our approach is fruitful for a simple scenario based on sorted mutable arrays. Furthermore, we can take advantage of equations between algebraic operations to dynamically optimize imperative computations composition.

Cited by 0

Lazy Imperative Programming

John Launchbury · 1993

In this paper we argue for the importance of lazy state, that is, sequences of imperative (destructive) actions in which the actions are delayed until their results are required. This enables state-based computations to take advantage of the control power of lazy evaluation. We provide some examples of its use, and describe an implementation within Glasgow Haskell. 1 Introduction There has long been a tension between functional programming languages and their more traditional imperative counterparts. On the one hand, functional languages are commonly more expressive and easier to reason about than imperative languages, but on the other hand, certain algorithms and interactions seem to rely fundamentally on state-based computation. It is clearly worth attempting to combine the strengths of each. Some languages like Scheme and ML have incorporated imperative actions as side effects. This approach only makes sense in a call-by-value language where the order of evaluation is statically de...

Cited by 0

Constraint imperative programming

Bjorn Freeman‐Benson · 1992

Two major programming language paradigms are the imperative and declarative ones. Software engineers typically use concepts from both paradigms when designing a system, yet are forced to implement those ideas in a single-paradigm programming language. This dissertation presents an integration of specific features from the imperative and declarative paradigms in a new programming language framework: Constraint Imperative Programming. Explicit control flow and destructive assignment are taken from the imperative paradigm. Explicit, system-maintained constraints (i.e., data relations) are taken from the declarative paradigm. This dissertation claims that this integrated framework has a clean, well-defined semantics, and that languages in this framework can be implemented with reasonable efficiency. This dissertation further claims that these languages are more expressive than purely imperative or purely constraint languages, because they allow each concept to be expressed in whichever fundamental paradigm is most suitable, rather than forcing them all into a single paradigm. This dissertation includes a semantic definition of Constraint imperative Programming (CIP), a discussion of the design issues for CIP languages, and a proof-of-concept implementation: Kaleidoscope 90.

Cited by 25

Introducing Imperative Programming

Don Syme, Ádám Gránicz, Antonio Cisternino · Apress eBooks · 2007

In Chapter 3 you saw some of the simple but powerful data types and language constructs that make up F# functional programming. The functional programming paradigm is strongly associated with "programming without side effects," called pure functional programming. In this paradigm, programs compute the result of a mathematical expression and do not cause any side effects, except perhaps reporting the result of the computation. The formulae used in spreadsheets are often pure, as is the core of functional programming languages such as Haskell. F# is not, however, a "pure" functional language; for example, you can write programs that mutate data, perform I/O communications, start threads, and raise exceptions. Furthermore, the F# type system doesn't enforce a strict distinction between expressions that perform these actions and expressions that don't.KeywordsPolished CodeFunctional ProgrammingLanguage ConstructTextual StringImperative ProgrammingThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Cited by 0

Lazier Imperative Programming

Rémi Douence, Nicolas Tabareau · HAL (Le Centre pour la Communication Scientifique Directe) · 2014

International audience

Cited by 0Open access

Imperative Genetic Programming

Iztok Fajfar, Žiga Rojec, Árpád Bűrmen et al. · Symmetry · 2024

Genetic programming (GP) has a long-standing tradition in the evolution of computer programs, predominantly utilizing tree and linear paradigms, each with distinct advantages and limitations. Despite the rapid growth of the GP field, there have been disproportionately few attempts to evolve ’real’ Turing-like imperative programs (as contrasted with functional programming) from the ground up. Existing research focuses mainly on specific special cases where the structure of the solution is partly known. This paper explores the potential of integrating tree and linear GP paradigms to develop an encoding scheme that universally supports genetic operators without constraints and consistently generates syntactically correct Python programs from scratch. By blending the symmetrical structure of tree-based representations with the inherent asymmetry of linear sequences, we created a versatile environment for program evolution. Our approach was rigorously tested on 35 problems characterized by varying Halstead complexity metrics, to delineate the approach’s boundaries. While expected brute-force program solutions were observed, our method yielded more sophisticated strategies, such as optimizing a program by restricting the division trials to the values up to the square root of the number when counting its proper divisors. Despite the recent groundbreaking advancements in large language models, we assert that the GP field warrants continued research. GP embodies a fundamentally different computational paradigm, crucial for advancing our understanding of natural evolutionary processes.

Cited by 2Open access

Imperative Functional Programming

Simon L Peyton, Jones Philip Wadler · 1992

We present a new model, based on monads, for performing input/output in a nonstrict, purely functional language. It is composable, extensible, efficient, requires no extensions to the type system, and extends smoothly to incorporate mixed-language working and in-place array updates. 1 Introduction Input/output has always appeared to be one of the less satisfactory features of purely functional languages: fitting action into the functional paradigm feels like fitting a square block into a round hole. Closely related difficulties are associated with performing inplace update operations on arrays, and calling arbitrary procedures written in some other (possibly side-effecting) language. Some mostly-functional languages, such as Lisp or SML, deal successfully with input /output by using side effects. We focus on purely-functional solutions, which rule out side effects, for two reasons. Firstly, the absence of side effects permits unrestricted use of equational reasoning and program transf...

Cited by 0

Higher Order Imperative Programming

Aaron Kershenbaum, David R. Musser, Alexander A. Stepanov · 2004

It is argued that a programming style based on higher order techniquesthe use of procedures that have other procedures as arguments andor resultscan be most eectively employed if it is driven by abstraction from real algorithms rather than attempting to work with a xed set of functional forms and the use of imperative forms and mutative procedures is permitted even encour aged \t rather than restricting to a purely applicative style A sequence of examples is presented illustrating a number of higher order techniques operators iterators accumulation reduction parallel reductionand their eective use in conjunction with mutative procedures The examples culminate with an interesting family of sorting algorithms illustrating how higher order techniques can lead naturally to new algorithms

Cited by 12

Search and imperative programming

Apt KR, SCHAERF, Andrea · Institutional Research Information System (University of Udine) · 1997

We augment the expressive power of imperative programming in order to make it a more attractive vehicle for problems that involve search. The proposed additions are limited yet powerful and are inspired by the logic programming paradigm. We illustrate their use by presenting solutions to a number of classical problems, including the straight search problem, the knapsack problem, and the 8 queens problem. These solutions are substantially simpler than their counterparts written in the conventional way and can be used for different purposes without any modification. The proposed language is an intermediate stage on the road towards a realization of a strongly typed constraint programming language that combines the advantages of the logic programming and imperative programming.

Cited by 0

Search and imperative programming

Krzysztof R. Apt, Andrea Schaerf · 1997

We augment the expressive power of imperative programming in order to make it a more attractive vehicle for problems that involve search. The proposed additions are limited yet powerful and are inspired by the logic programming paradigm. We illustrate their use by presenting solutions to a number of classical problems, including the straight search problem, the knapsack problem, and the 8 queens problem. These solutions are substantially simpler than their counterparts written in the conventional way and can be used for different purposes without any modification.The proposed language is an intermediate stage on the road towards a realization of a strongly typed constraint programming language that combines the advantages of the logic programming and imperative programming.

Cited by 0Open access

Imperative Programming in ML

Lawrence C. Paulson · Cambridge University Press eBooks · 1996

Functional programming has its merits, but imperative programming is here to stay. It is the most natural way to perform input and output. Some programs are specifically concerned with managing state: a chess program must keep track of where the pieces are! Some classical data structures, such as hash tables, work by updating arrays and pointers.

Cited by 0

Imperative programming with dependent types

Hongwei Xi · 2002

The article enriches imperative programming with a form of dependent types. We start by explaining some motivations for this enrichment and mentioning some major obstacles that need to be overcome. We then present the design of a source level dependently typed imperative programming language Xanadu, forming both static and dynamic semantics and then establishing the type soundness theorem. We also present realistic examples, which have all been verified in a prototype implementation, in support of the practicality of Xanadu. We claim that the language design of Xanadu is novel and it serves as an informative example that demonstrates a means to combine imperative programming with dependent types.

Cited by 67

Implementing constraint imperative programming languages

Gus Lopez, Bjorn Freeman‐Benson, Alan Borning · 1994

Constraint Imperative Programming (CIP) languages integrate declarative constraints with imperative state and destructive assignment, yielding a powerful new programming paradigm. However, CIP languages are difficult to implement efficiently due to complex interactions between the two donor paradigms. Neither the virtual machines for classical object-oriented languages, nor those for existing constraint languages, are suitable for implementing CIP languages, as each assumes a purely imperative or a purely declarative computation model. We have developed a new virtual machine for CIP languages, the K-machine, an imperative machine with an incremental constraint solver and a constraint-based, rather than value-based, data store. This virtual machine allows user-defined constraints to be defined using constraint constructor definitions which are the CIP analog to method definitions. Similar to methods, these constructors are able to reference variables indirectly through many levels of pointers. The K-machine maintains relations between objects in the presence of state change to these indirectly referenced objects. The K-machine is capable of supporting a wide variety of CIP languages, including our most recent: Kaleidoscope'93.

Cited by 19