Top PDF Functional Programming for Systems Software

Functional Programming for Systems Software

Functional Programming for Systems Software

Functional Programming for Systems Software pages, I felt more confident when I was able to use the initialization functions in LC since those functions are guaranteed to never go out of bounds. In the C implementation, I am still not confident that this initialization is correct, even after reverifying the math and stepping through this process several times to justify that it correctly zeroes out the entire page, but nothing else. While LC felt more predictable than C, it only felt slightly more portable than the C code, and not as portable as its equivalent Habit code could be. The bitdata for page directory entries, and their associated functions, felt reasonably portable and easy to expand upon. Page allocation felt portable and adjustable as well, where different initialization functions could be used to set the paging structures in different ways, and more page allocation functions could easily be added if needed. Unfortunately, LC does not have type classes, which could have otherwise made for even more portable and extendable code, with potentially less boilerplate as well. One area more portable in C is that initdir can be explicitly referenced in the C code, which works as anticipated. However, for LC a new global variable has to be created that just stores the address of initdir. If there were more global variables for arrays or other objects, extra variables would be needed to reference them, thus making LC less portable when wanting to use the address of a global variable. Also, C macros can be used in both the C program and the assembly, allowing for constants to be defined that are used throughout the program. Without this, LC needs to define the constants in several places, making it less portable than C if any of the constants needed to be changed. The common theme here is that C has an easier time interacting with assembly, in a way that could easily be updated or moved to another program, which LC currently lacks.
Show more

40 Read more

An Analysis of the Impact of Functional Programming Techniques on Genetic Programming

An Analysis of the Impact of Functional Programming Techniques on Genetic Programming

The system is implemented in Haskell 1.4 [Peterson and Hammond 1997] using the Glasgow Haskell Compiler version 2.02. Haskell is a non-strict purely functional programming lan­ guage. Non-strict languages evaluate a program expression only when its value is needed; this is commonly referred as lazy evaluation. This is an advantage to the GP system because pro­ gram trees normally contain “redundant expressions” (introns). W ithout the need to evaluate these redundant expressions, the GP system may take less time to evolve problem solution. The “purity” feature means no side-efiFect operation is allowed in the language. Consequently, each time a member o f the population is updated, a new copy o f the population may be made. Fortunately, the Glasgow Haskell compiler provided an updatable data structure (array) which can be used to implement GP population. This data structure supports effective m eth­ ods in accessing and m odifying the members o f the population. Nevertheless, compared with other GP systems which are implemented in imperative languages, such as C and C++, the functional GP system is still slow.
Show more

186 Read more

A functional quantum programming language

A functional quantum programming language

The idea that quantum computing is possible was first put forward, independently, in 1982 by Richard Feynman [ 25 ] and Paul Benioff [ 7 , 8 ]. Feynman’s main motivation was the simulation of other systems which are chiefly governed by quantum mechan- ics. He theorised that a quantum system could more naturally and quickly simulate quantum systems, such as chemical interactions, which can be modelled considering the wavefunctions of the constituent atoms. To perform these kinds of calculations on classical computers requires an exponentially large amount of time, relative to the size of the system, but a quantum computer could efficiently simulate any quan- tum system. Benioff’s premise centred on the continuing trend of miniaturisation in electronic circuitry. Circuits have steadily been manufactured at increasingly smaller scales until now, where they have reached the stage where quantum mechanical effects are significant in the behaviour of the devices. Benioff argued that a computer which makes use of these quantum effects may help the management of this hardware crisis, and perhaps move beyond the miniaturisation barrier.
Show more

214 Read more

Testing and debugging functional reactive programming

Testing and debugging functional reactive programming

There are two sources of uncertainty in FRP programs that may affect system-level referential transparency. First, some FRP implementations use IO inside core definitions to increase versatility and performance. This makes those systems susceptible to the problems discussed earlier. Second, even if we run a simulation twice with the same initial state and user input, we may obtain different outputs if our simulations are sampled at different points in time, due to differences in system load and OS scheduling decisions outside our control, for example. This is demonstrated by the force-directed graph simulation depicted in Figure 1. This simulation does not depend on user input, yet different stable configurations are reached depending on the sampling step, due to small differences in floating point calculations.
Show more

27 Read more

A Programming System for\ud
End-user Functional Programming

A Programming System for\ud End-user Functional Programming

Haskell type system easier for them at a later stage. There are some interesting areas of functional programming which may attract end-users to attempt to learn functional programming languages. Researchers have long maintained that computer programs will be developed and easily maintained in func- tional programming languages. Unlike traditional imperative programming languages, functional programming languages have no notion of sequence or state (Hughes, 1989). A function call computes its result without any side- effects, because variables, once given a value, can never be changed, which eliminates a major source of bugs. A functional programmer does not need to specify the flow of control and an expression can be evaluated at any time. While conventional programming languages place limits on the way that con- trol theory, hybrid systems, vision, artificial intelligence, and human-computer interaction can be expressed, functional programming languages push back these limits (Hughes, 1989).
Show more

340 Read more

A DYNAMIC PROGRAMMING APPROACH TO THE PARISI FUNCTIONAL

A DYNAMIC PROGRAMMING APPROACH TO THE PARISI FUNCTIONAL

As a further demonstration how Theorem 1 can be combined with methods from stochastic optimal control, we present a simple proof of the strict convexity of the Parisi functional. As background, recall the prediction by Parisi [13] that the minimizer of the Parisi functional should be unique and should serve the role of the order parameter in these systems. The question of the strict convexity of P was first posed by Panchenko in [14] as a way to prove this uniqueness. It was studied by Panchenko [14], Talagrand [18, 19], Bovier and Klimovsky [4], and Chen [5], and finally resolved by Auffinger and Chen in their fundamental work [2]. The work of Auffinger and Chen rested on a variational representation of the log-moment generating functional of Brownian motion [3, 7], which they combine with approximation arguments to give a variational representation for the solution of the Parisi PDE. We note here that an early version of this variational representation appeared in [4], where it is shown, using the theory of viscosity solutions, to hold when the coefficient µ[0, t] is piecewise continuous with finitely many jumps.
Show more

15 Read more

Improving the Design and Implementation of Software Systems uses Aspect Oriented Programming

Improving the Design and Implementation of Software Systems uses Aspect Oriented Programming

. B. Aspect Oriented Modelling AOM Developers should be aware of, and understand the software modelling or architecture before staring implementing AOP. AOM (Aspect Oriented Modelling) is an approach to produce a logical aspect oriented architectural model. Early usage of AOM in development stage will reduce the software development risk of conflicts and undesirable behavior emerging during implementation. The cross cutting element is common in AOP and AOM, but the difference is between the artifices versus source code, it could rise difference technique in representing it. For instance, the code can represent in single functionality, while a model can represent the system with different diagram views. Another difference between AOP and AOM in code is aspect weaving is primarily concerned with inserting functionality at program execution. AOM module consists of major components: primary model, aspect model and composition model Fig.1[7] below shows this model .
Show more

8 Read more

How functional programming mattered

How functional programming mattered

of copying lists. The advantage of giving each process its own heap is that processes can garbage collect in- dependently while other processes continue work- ing, which avoids long garbage collection pauses and makes Erlang suitable for soft real-time applications. Erlang adds mechanisms for one process to mon- itor another, turning a crash in the monitored pro- cess into a message delivered to the monitoring one. These mechanisms are used to support fault toler- ance, with a hierarchy of supervisor processes which are responsible for restarting subsystems that fail; indeed, Erlang developers advocate a ‘let it crash’ approach, in which error-handling code (which is often complex and poorly tested) is omitted from most application code, relying on the supervisors for fault tolerance instead. Common patterns for build- ing fault-tolerant systems are provided in the ‘Open Telecom Platform’ libraries—essentially higher or- der functions that permit fault-tolerant systems to be constructed just by instantiating the application- dependent behaviour.
Show more

22 Read more

The functional perspective on advanced logic programming

The functional perspective on advanced logic programming

probabilistic problem monadically. On the other, there has been much research towards a measure theoretic formalisation of such monadic probabilistic programs [14]. However, little has been done into other more general algebraic structures related to monads. In particular, so called applicative functors or idioms [9] appear to model precisely those programs where the structure of the program is static, with respect to probabilistic choices that are made. This is especially relevant for probabilistic logic systems such as ProbLog, where the structure of the clauses is fixed. Moreover, as these structures are more restrictive, they may actually admit faster inference routines. Or conversely, ProbLog’s specialised inference may apply to probabilistic programming languages that have applicative structure. There are already some promising early results, for instance, it is cleary that ProbLog programs exhibit applicative structure. However, the implications of these results are not yet fully understood, and are subject of ongoing research.
Show more

8 Read more

Fuzzy functional programming

Fuzzy functional programming

The implementation of a fuzzy expert system in a functional setting may seem at rst to be a highly complex problem. An Expert System is large collection of rules with a sophisticated inference engine which manages these rules; fuzzy expert systems have the added complexity of consequence combination and defuzzication. In addition, the order in which the rules re is largely non-deterministic. How can we hope to implement a largely non-deterministic problem in a deterministic functional language?

22 Read more

Definition of a hybrid programming language for interoperability of heterogeneous software systems at the semantic level

Definition of a hybrid programming language for interoperability of heterogeneous software systems at the semantic level

Declarative programming is used in a different way. The idea is to define what to do but not how to do it. The user declares functions and uses recursion to obtain the desired results. Structured Query Language–SQL is an example of a language that uses this paradigm (Lloyd, 1994). In this case, if you want to know the salaries of the employees you do not iterate over the records, you just select the field (salary) from the table (employees) with an instruction. Note that you do not need to describe how to obtain the results, just specify what you need. In procedural or object-oriented programming you should do it with a loop, specifying how to achieve it. Other examples of declarative languages are regular expressions, CSS, and Prolog.
Show more

117 Read more

Clojure - Functional Programming for the JVM

Clojure - Functional Programming for the JVM

Refs are used to ensure that changes to one or more bindings are coordinated between multiple threads. This coordination is implemented using Software Transactional Memory (STM). Refs can only be modified inside a transaction. STM has properties that are similar to database transactions. All changes made inside an STM transaction only become visible to other threads at a single point in time when the transaction commits. This makes them both atomic and isolated. Validation functions make it possible to insure that changes are consistent with the values of other data.

64 Read more

Michael Gregorowicz. Objective. Overview. Operating Systems. Programming Languages. Server Software.

Michael Gregorowicz. Objective. Overview. Operating Systems. Programming Languages. Server Software.

Dadmin is the Wayne State University C&IT Help Desk's directory administration utility. The toolset includes tools for creating and removing accounts from our directory, as well as configuring access to E-Mail, Administrative Systems, and UNIX machines. Tools also include quota management, temporary password swaps, and group account creation. Through intuitive interface design Dadmin ][ has reduced time to resolution from an average of 10 minutes per call to less than 3 minutes per call. dadmin ][ is currently a proprietary application in production at Wayne State University.

5 Read more

Extra Functional Properties Evaluation of Self-managed Software Systems with Formal Methods

Extra Functional Properties Evaluation of Self-managed Software Systems with Formal Methods

The Component Control layer accomplishes the application function of the system, in our case the workflows of the software services the infrastructure deploys. The software services modules represent the executable files of these software services. They are the instance of software application and infrastructure in Figure 2.1. Note that they are replicated, really to represent several services but also several running instances of each service. Each running instance, which manages requests until its maximum capacity, will execute in a server of the infrastructure. Each server can host several running instances. The Component Control layer also features a HardwareController and a LoadMonitor software modules. They are the instances of sensors and actuators in the general architecture and they include facilities to report the current status of the processing infrastructure and to support modifications on it. The HardwareController implements: a sensor functionality for communicating with its upper layer to inform the current state of the servers (e.g., booting completion), and an actu- ator functionality to receive orders to reconfigure the server infrastructure (increase/decrease frequency or switch on/off of servers). We think of it as a software module that manages the servers through the Wake on LAN (WoL) facility. The LoadMonitor monitors current system workload and informs to its upper layer when the workload exceeds some thresholds, i.e., a problem to solve. Thresholds of interest were previously identified by the upper layer to this module.
Show more

203 Read more

Why Functional Programming Matters

Why Functional Programming Matters

As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write and to debug, and provides a collection of modules that can be reused to reduce future programming costs. In this paper we show that two fea- tures of functional languages in particular, higher-order functions and lazy evaluation, can contribute significantly to modularity. As examples, we manipulate lists and trees, program several numerical algorithms, and im- plement the alpha-beta heuristic (an algorithm from Artificial Intelligence used in game-playing programs). We conclude that since modularity is the key to successful programming, functional programming offers important advantages for software development.
Show more

23 Read more

Functional Requirements of the Software

Functional Requirements of the Software

e. The Database structure shall have the ability to use Microsoft Jet Engine 4.0 files, Microsoft Access, or an OLE DB drivers, such as Oracle or Microsoft SQL Server. f. The database shall support simultaneously the following code systems: WRc, PACP, CUES standard and individual custom codes. The “Customer” shall provide the “Contractor” the code requirement prior to inspection creation. The code editor shall provide the ability to add, modify, and/or delete the code systems per the inspection requirements or user’s preferences. Each project shall be able to utilize a different code system and units of measurement based on the “Customer” inspection requirements. The “Customer” shall have full and independent access to the code editor for customization needs without the use of third party applications.
Show more

10 Read more

A Brief Overview of Functional Programming Languages

A Brief Overview of Functional Programming Languages

In 1977, FP was presented by John Backus in his lecture “Can Programming Be Liberated from the von Neumann Style? A Functional Style and its Algebra of Programs”. In his lecture, Backus compared functional programs with programs based on the von Neumann style. The von Neumann style program dominated the development of programs during the time. In programming languages based on Von Neumann’s architecture, the state of the program is changed throughout its execution. This change in state is known as mutation. Backus argued that this concept created complex systems. Complex systems are bigger in size which results in higher maintenance costs so he put forwarded FP as an alternative [10].
Show more

5 Read more

Monadic Functional Reactive Programming

Monadic Functional Reactive Programming

Abstract Functional Reactive Programming (FRP) is a way to program reac- tive systems in functional style, eliminating many of the problems that arise from imperative techniques. In this paper, we present an alternative FRP formulation that is based on the notion of a reac- tive computation: a monadic computation which may require the occurrence of external events to continue. A signal computation is a reactive computation that may also emit values. In contrast to signals in other FRP formulations, signal computations can end, leading to a monadic interface for sequencing behavioral changes. This interface has several advantages: routing is implicit, sequencing behaviors is easier and more intuitive than the switching combina- tors found in other FRP approaches, and dynamic lists require much less boilerplate code. In other FRP approaches, either the entire FRP expression is re-evaluated on each external stimulus, or impure techniques are used to prevent redundant re-computations. We show how Monadic FRP can be implemented straightforwardly in a purely functional way while preventing redundant re-computations. 1. Introduction
Show more

12 Read more

Models for persistence in lazy functional programming systems

Models for persistence in lazy functional programming systems

Being applied systematically on a large scale, this technique would allow ad-hoc, user programmed sharing to be preserved, but the cost of doing all this in terms of programming effort and complexity would have increased considerably in the meantime. Writing a function to generate the textual representation of the data- structure is significantly more difficult. This task would have to be repeated from scratch for every kind of topology which was required. In addition, it is a task that has nothing to do with the problem being solved. Users of lazy functional programming languages should not have to expend effort in performing such transformations by hand. Systems exist (e.g. PGraphite [Tarr89]) though not functional ones, where similar transformations have been automated. This kind of problem is com m on to large scale software developm ent [Parn79]. M any applications need to build large data-structures which should only be constructed once and persist thereafter.
Show more

186 Read more

A Comparison of Functional and Imperative Programming Techniques for Mathematical Software Development

A Comparison of Functional and Imperative Programming Techniques for Mathematical Software Development

Imperative programming performs computation as a sequence of statements that manipulate stored data until a desired result is achieved. The functional style of programming, in contrast, represents programs as relationships between mathematical expressions which are based on dependencies. Functional programming has been described as powerful and expressive, yet it has never achieved the success and widespread use of imperative programming. An impediment to the growth of functional programming is that many tasks are most naturally attacked by imperative means and cannot be represented as readily in a functional manner. Some functional languages include imperative constructs. These inclusions compromise the functional model, but allow the imperative tasks to be accomplished through the most direct means. In other cases imperative languages have been equipped with some functional tools to make them more expressive.
Show more

5 Read more

Show all 10000 documents...