Results 1 - 10
of
124
Generalising Monads to Arrows
- Science of Computer Programming
, 1998
"... this paper. Pleasingly, the arrow interface turned out to be applicable to other kinds of non-monadic library also, for example the fudgets library for graphical user interfaces [CH93], and a new library for programming active web pages. These applications will be described in sections 6 and 9. Whil ..."
Abstract
-
Cited by 133 (3 self)
- Add to MetaCart
this paper. Pleasingly, the arrow interface turned out to be applicable to other kinds of non-monadic library also, for example the fudgets library for graphical user interfaces [CH93], and a new library for programming active web pages. These applications will be described in sections 6 and 9. While arrows are a little less convenient to use than monads, they have significantly wider applicability. They can therefore be used to bring the benefits of monad-like programming to a much wider class of applications. 2 Background: Library Design Using Monads
Modular Domain Specific Languages and Tools
- in Proceedings of Fifth International Conference on Software Reuse
, 1998
"... A domain specific language (DSL) allows one to develop software for a particular application domain quickly and effectively, yielding programs that are easy to understand, reason about, and maintain. On the other hand, there may be a significant overhead in creating the infrastructure needed to supp ..."
Abstract
-
Cited by 95 (5 self)
- Add to MetaCart
A domain specific language (DSL) allows one to develop software for a particular application domain quickly and effectively, yielding programs that are easy to understand, reason about, and maintain. On the other hand, there may be a significant overhead in creating the infrastructure needed to support a DSL. To solve this problem, a methodology is described for building domain specific embedded languages (DSELs), in which a DSL is designed within an existing, higher-order and typed, programming language such as Haskell or ML. In addition, techniques are described for building modular interpreters and tools for DSELs. The resulting methodology facilitates reuse of syntax, semantics, implementation code, software tools, as well as look-and-feel.
Region streams: functional macroprogramming for sensor networks
, 2004
"... Sensor networks present a number of novel programming challenges for application developers. Their inherent limitations of computational power, communication bandwidth, and energy demand new approaches to programming that shield the developer from low-level details of resource management, concurrenc ..."
Abstract
-
Cited by 85 (6 self)
- Add to MetaCart
Sensor networks present a number of novel programming challenges for application developers. Their inherent limitations of computational power, communication bandwidth, and energy demand new approaches to programming that shield the developer from low-level details of resource management, concurrency, and in-network processing. We argue that sensor networks should be programmed at the global level, allowing the compiler to automatically generate nodal behaviors from a high-level specification of the network’s global behavior. This paper presents the design of a functional macroprogramming language for sensor networks, called Regiment. The essential data model in Regiment is based on region streams, which represent spatially distributed, time-varying collections of node state. A region stream might represent the set of sensor values across all nodes in an area or the aggregation of sensor values within that area. Regiment is a purely functional language, which gives the compiler considerable leeway in terms of realizing region stream operations across sensor nodes and exploiting redundancy within the network. We describe the initial design and implementation of Regiment, including a compiler that transforms a macroprogram into an efficient nodal program based on a token machine. We present a progresssion of simple programs that illustrate the power of Regiment to succinctly represent robust, adaptive sensor network applications.
Type Classes: An Exploration of the Design Space
- In Haskell Workshop
, 1997
"... When type classes were first introduced in Haskell they were regarded as a fairly experimental language feature, and therefore warranted a fairly conservative design. Since that time, practical experience has convinced many programmers of the benefits and convenience of type classes. However, on occ ..."
Abstract
-
Cited by 84 (8 self)
- Add to MetaCart
When type classes were first introduced in Haskell they were regarded as a fairly experimental language feature, and therefore warranted a fairly conservative design. Since that time, practical experience has convinced many programmers of the benefits and convenience of type classes. However, on occasion, these same programmers have discovered examples where seemingly natural applications for type class overloading are prevented by the restrictions imposed by the Haskell design. It is possible to extend the type class mechanism of Haskell in various ways to overcome these limitations, but such proposals must be designed with great care. For example, several different extensions have been implemented in Gofer. Some of these, particularly the support for multi-parameter classes, have proved to be very useful, but interactions between other aspects of the design have resulted in a type system that is both unsound and undecidable. Another illustration is the introduction of constructor cla...
Forms/3: A First-Order Visual Language to Explore the Boundaries of the Spreadsheet Paradigm
"... Although detractors of functional programming sometimes claim that functional programming is too difficult or counterintuitive for most programmers to understand and use, evidence to the contrary can be found by looking at the popularity of spreadsheets. The spreadsheet paradigm, a first-order subs ..."
Abstract
-
Cited by 81 (37 self)
- Add to MetaCart
Although detractors of functional programming sometimes claim that functional programming is too difficult or counterintuitive for most programmers to understand and use, evidence to the contrary can be found by looking at the popularity of spreadsheets. The spreadsheet paradigm, a first-order subset of the functional programming paradigm, has found wide acceptance among both programmers and end users. Still, there are many limitations with most spreadsheet systems.
Lambda in Motion: Controlling Robots with Haskell
, 1999
"... . We present our experiences using a purely functional language, Haskell, in what has been traditionally the realm of low-level languages: robot control. Frob (Functional Robotics) is a domain-specific language embedded in Haskell for robot control. Frob is based on Functional Reactive Programming ( ..."
Abstract
-
Cited by 45 (10 self)
- Add to MetaCart
. We present our experiences using a purely functional language, Haskell, in what has been traditionally the realm of low-level languages: robot control. Frob (Functional Robotics) is a domain-specific language embedded in Haskell for robot control. Frob is based on Functional Reactive Programming (FRP), as initially developed for Fran, a language of reactive animations. Frob presents the interaction between a robot and its stimuli, both onboard sensors and messages from other agents, in a purely functional manner. This serves as a basis for composable high level abstractions supporting complex control regimens in a concise and reusable manner. 1 Introduction Robotics is a an excellent problem domain to demonstrate the power and flexibility of declarative programming languages. Among the more interesting problem areas in this domain are control systems, constraint solving, reactive programming, sensor fusion, and real-time control. We have developed Frob (for Functional Robotics) as ...
Functional Reactive Programming from First Principles
- In ACM SIGPLAN Conference on Programming Language Design and Implementation
, 2000
"... Functional Reactive Programming, or FRP, is a general framework for programming hybrid systems in a high-level, declarative manner. The key ideas in FRP are its notions of behaviors and events. Behaviors are time-varying, reactive values, while events are time-ordered sequences of discrete-time ev ..."
Abstract
-
Cited by 44 (3 self)
- Add to MetaCart
Functional Reactive Programming, or FRP, is a general framework for programming hybrid systems in a high-level, declarative manner. The key ideas in FRP are its notions of behaviors and events. Behaviors are time-varying, reactive values, while events are time-ordered sequences of discrete-time event occurrences. FRP is the essence of Fran, a domainspeci c language embedded in Haskell for programming reactive animations, but FRP is now also being used in vision, robotics and other control systems applications. In this paper we explore the formal semantics of FRP and how it relates to an implementation based on streams that represent (and therefore only approximate) continuous behaviors. We show that, in the limit as the sampling interval goes to zero, the implementation is faithful to the formal, continuous semantics, but only when certain constraints on behaviors are observed. We explore the nature of these constraints, which vary amongst the FRP primitives. Our results show both the power and limitations of this approach to language design and implementation. As an example of a limitation, we show that streams are incapable of representing instantaneous predicate events over behaviors. 1.
Arrows, Robots, and Functional Reactive Programming
- Advanced Functional Programming, 4th International School, volume 2638 of LNCS
, 2002
"... Functional reactive programming, or FRP, is a paradigm for programming hybrid systems -- i.e., systems containing a combination of both continuous and discrete components -- in a high-level, declarative way. The key ideas in FRP are its notions of continuous, time-varying values, and time-ordere ..."
Abstract
-
Cited by 41 (9 self)
- Add to MetaCart
Functional reactive programming, or FRP, is a paradigm for programming hybrid systems -- i.e., systems containing a combination of both continuous and discrete components -- in a high-level, declarative way. The key ideas in FRP are its notions of continuous, time-varying values, and time-ordered sequences of discrete events.
Genuinely functional user interfaces
- In Proceedings of the 2001 Haskell Workshop
, 2001
"... Fruit is a new graphical user interface library for Haskell based on a formal model of user interfaces. The model identifies signals (continuous time-varying values) and signal transformers (pure functions mapping signals to signals) as core abstractions, and defines GUIs compositionally as signal t ..."
Abstract
-
Cited by 33 (3 self)
- Add to MetaCart
Fruit is a new graphical user interface library for Haskell based on a formal model of user interfaces. The model identifies signals (continuous time-varying values) and signal transformers (pure functions mapping signals to signals) as core abstractions, and defines GUIs compositionally as signal transformers. In this paper, we describe why we think a formal denotational model of user interfaces is useful, present our model and prototype library implementation, and show some example programs that demonstrate novel features of our library.
On embedding a microarchitectural design language within Haskell
- In Proceedings of the ACM SIGPLAN International Conference on Functional Programming (ICFP ’99
, 1999
"... Based on our experience with modelling and verifying microarchitectural designs within Haskell, this paper examines our use of Haskell as host for an embedded language. In particular, we highlight our use of Haskell's lazy lists, type classes, lazy state monad, and unsafePerformIO, and point to seve ..."
Abstract
-
Cited by 32 (4 self)
- Add to MetaCart
Based on our experience with modelling and verifying microarchitectural designs within Haskell, this paper examines our use of Haskell as host for an embedded language. In particular, we highlight our use of Haskell's lazy lists, type classes, lazy state monad, and unsafePerformIO, and point to several areas where Haskell could be improved in the future. We end with an example of a benefit gained by bringing the functional perspective to microarchitectural modelling.

