Results 1 
6 of
6
Programming monads operationally with Unimo
 In ICFP
, 2006
"... Monads are widely used in Haskell for modeling computational effects, but defining monads remains a daunting challenge. Since every part of a monad’s definition depends on its computational effects, programmers cannot leverage the common behavior of all monads easily and thus must build from scratch ..."
Abstract

Cited by 7 (2 self)
 Add to MetaCart
(Show Context)
Monads are widely used in Haskell for modeling computational effects, but defining monads remains a daunting challenge. Since every part of a monad’s definition depends on its computational effects, programmers cannot leverage the common behavior of all monads easily and thus must build from scratch each monad that models a new computational effect. I propose the Unimo framework which allows programmers to define monads and monad transformers in a modular manner. Unimo contains a heavily parameterized observer function which enforces the monad laws, and programmers define a monad by invoking the observer function with arguments that specify the computational effects of the monad. Since Unimo provides the common behavior of all monads in a reusable form, programmers no longer need to rebuild the semantic boilerplate for each monad and can instead focus on the more interesting and rewarding task of modeling the desired computational effects.
Proceedings Of The
, 1997
"... Its copyright notice follows below: Copyright 1997 SpringerVerlag This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction o ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
Its copyright notice follows below: Copyright 1997 SpringerVerlag This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication in its current version, and permission for use must always be obtained from SpringerVerlag. Violations are liable for prosecution under the German Copyright Law. The position papers are copyrighted by their authors. All rights are reserved.
An AspectOriented Design Framework
, 2000
"... With AspectOriented Programming (AOP), we see a problem as a collection of different issues, and try to find all issues relevant to the problem. We can therefore manage to achieve an improved separation of concerns in both design, and implementation. The goal of AOP is to decompose a problem into a ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
With AspectOriented Programming (AOP), we see a problem as a collection of different issues, and try to find all issues relevant to the problem. We can therefore manage to achieve an improved separation of concerns in both design, and implementation. The goal of AOP is to decompose a problem into a number of functional components as well as a number of aspects and then composing these components and aspects to obtain system implementations. Our work concentrates on the aspectual decomposition of concurrent objectoriented systems. We follow a component hierarchy within the objectoriented programming paradigm. At the lowest level we have a method. Methods are combined into objects. Each object belongs to a class, and several classes can belong to a package. We have categorized aspects according to their hierarchical level of crosscutting. We achieve composition of concerns through the use of an object we call the moderator that coordinates the interaction of components and aspects while preserving the semantics of the overall system. Since aspects can cut across components at every level, the moderator is a recurring pattern from intramethod to intrapackage. Our design framework provides an adaptable model and a component hierarchy using a design pattern. The moderator pattern is an architecture that allows for an open language where new aspects (specifications) can be added and their semantics can be delivered to the compiler through the moderator. In essence the moderator is a program that extends the language itself. Our goal is to achieve separation of concerns and retain this separation without having to produce an intermingled source code.
General Terms Design, Languages
"... Monads are widely used in Haskell for modeling computational effects, but defining monads remains a daunting challenge. Since every part of a monad’s definition depends on its computational effects, programmers cannot leverage the common behavior of all monads easily and thus must build from scratch ..."
Abstract
 Add to MetaCart
(Show Context)
Monads are widely used in Haskell for modeling computational effects, but defining monads remains a daunting challenge. Since every part of a monad’s definition depends on its computational effects, programmers cannot leverage the common behavior of all monads easily and thus must build from scratch each monad that models a new computational effect. I propose the Unimo framework which allows programmers to define monads and monad transformers in a modular manner. Unimo contains a heavily parameterized observer function which enforces the monad laws, and programmers define a monad by invoking the observer function with arguments that specify the computational effects of the monad. Since Unimo provides the common behavior of all monads in a reusable form, programmers no longer need to rebuild the semantic boilerplate for each monad and can instead focus on the more interesting and rewarding task of modeling the desired computational effects.
Skeletons and the Anatomy of Monads
, 2006
"... Monads are used heavily in Haskell for supporting computational effects, and the language offers excellent support for defining monadic computations. Unfortunately, defining a monad remains a difficult challenge. There are no libraries that a programmer can use to define a monad that is not a compos ..."
Abstract
 Add to MetaCart
Monads are used heavily in Haskell for supporting computational effects, and the language offers excellent support for defining monadic computations. Unfortunately, defining a monad remains a difficult challenge. There are no libraries that a programmer can use to define a monad that is not a composition of existing monad transformers; therefore every such effort must start from scratch despite that all monads share the same structure and need to satisfy the same minimum set of properties. I propose
An AspectOriented Design Framework for Concurrent Systems
 Position paper at Workshop on AspectOriented Programming, ECOOP’99
"... The goal of AOP is to achieve an improved separation of concerns in both design, and implementation. Our work concentrates on the aspectual decomposition of concurrent objectoriented systems. Following a component hierarchy within the objectoriented programming paradigm we categorized aspects as i ..."
Abstract
 Add to MetaCart
The goal of AOP is to achieve an improved separation of concerns in both design, and implementation. Our work concentrates on the aspectual decomposition of concurrent objectoriented systems. Following a component hierarchy within the objectoriented programming paradigm we categorized aspects as intramethod, intraobject and intrapackage according to their hierarchical level of crosscutting. We achieve composition of concerns, through the use of an object we call the moderator that coordinates the interaction of components and aspects while preserving the semantics of the overall system. As aspects can cut across components at every level, we view the moderator is a recurring pattern from intramethod to intrapackage. Our design framework provides an adaptable model and a component hierarchy using a design pattern as well as it allows for an open language where new aspects (specifications) can be added and their semantics can be delivered to the compiler through the moderator. In...