PsyScope is an integrated environment for designing and running psychology experiments on Macintosh computers. The primary goal ofPsyScope is to give both psychology students and trained researchers a tool that allows them to design experiments without the need for programming. PsyScope relies on the interactive graphic environment provided by Macintosh computers to accomplish this goal. The standard components of a psychology experiment-groups, blocks, trials, and factors-are all represented graphically, and experiments are constructed by working with these elements in interactive windows and dialogs. In this article, we describe the overall organization of the program, provide an example of how a simple experiment can be constructed within its graphic environment, and discuss some of its technical features (such as its underlying scripting language, timing characteristics, etc.), PsyScope is available for noncommercial purposes free of charge and unsupported to the general research community. Information about how to obtain the program and its documentation is provided.

While class-based object-oriented programming languages provide a flexible mechanism for re-using and managing related pieces of code, they typically lack linguistic facilities for specifying a uniform extension of many classes with one set of fields and methods. As a result, programmers are unable to express certain abstractions over classes.In this paper we develop a model of class-to-class functions that we refer to as mixins. A mixin function maps a class to an extended class by adding or overriding fields and methods. Programming with mixins is similar to programming with single inheritance classes, but mixins more directly encourage programming to interfaces.The paper develops these ideas within the context of Java. The results are 1. an intuitive model of an essential Java subset;2. an extension that explains and models mie and 3. type soundness theorems for these languages. Organizing Programs with Functions and ClassesObject-oriented programming languages offer classes, inheritance, and overriding to parameterize over program pieces for management purposes and re-use. Functional programming languages provide various flavors of functional abstractions for the same purpose. The latter model was developed from a well-known, highly developed mathematical theory. The former grew in response to the need to manage large programs and to re-use as many components as possible.Each form of parameterization is useful for certain situations. With higher-order functions, a programmer can easily define many functions that share a similar core but differ in a few details.As many language designers and programmers readily acknowledge, however, the functional approach to parameterization is best used in situations with a relatively small number of parameters. When a function must *Pmi=ion to mnke digihlhrd copies of all or part ofthis mateGal for PemolIal or dilssroonl use is granted without fee provided Ihal tile apie are not made or distributed for profit or commercial advmhge, the copyG&t SOli% ihe title of the publication and its date appear, ;md notice is given ihat copyright is by permission of the ACM, Inc. To copy &en&e, 10 republish, 10 post on servem or to redistribute to I&, requires specific pemkion .mdlor fee. POPL 98 San Diego CA USA CW+ht 1998 ACM O-89791-979-3/98/01..$3.50 171 consume a large number of arguments, the approach quickly beconies unwieldy, especially if many of the arguments are the same for most of the function's u~e.s.~ Class systems provide a simple and flexible mechanism for managing collections of highly parameterized program pieces. Using class extension {inheritance) and overriding, a programmer derives a new class by specifying only the elements that change in the derived class.Nevertheless, a pure class-based approach suffers from a lack of abstractions that specify uniform extensions and modifications of classes. For example, the construction of a programming environment may require many kinds of text editor frames, including frames that can contain multiple text buffers and frames t...

DrScheme is a programming environment for Scheme. It fully integrates a graphicsenriched editor, a parser for multiple variants of Scheme, a functional read-eval-print loop, and an algebraic printer. The environment is especially useful for students, because it has a tower of syntactically restricted variants of Scheme that are designed to catch typical student mistakes and explain them in terms the students understand. The environment is also useful for professional programmers, due to its sophisticated programming tools, such as the static debugger, and its advanced language features, such as units and mixins.Beyond the ordinary programming environment tools, DrScheme provides an algebraic stepper, a context-sensitive syntax checker, and a static debugger. The stepper reduces Scheme programs to values, according to the reduction semantics of Scheme. It is useful for explaining the semantics of linguistic facilities and for studying the behavior of small programs. The syntax checker annotates programs with font and color changes based on the syntactic structure of the program. On demand, it draws arrows that point from bound to binding occurrences of identifiers. It also supports α-renaming. Finally, the static debugger provides a type inference system that explains specific inferences in terms of a value-flow graph, selectively overlaid on the program text.

No abstract

Abstract. Programmers rely on the correctness of the tools in their programming environments. In the past, semanticists have studied the correctness of compilers and compiler analyses, which are the most important tools. In this paper, we make the case that other tools, such as debuggers and steppers, deserve semantic models, too, and that using these models can help in developing these tools.Our concrete starting point is the algebraic stepper in DrScheme, our Scheme programming environment. The algebraic stepper explains a Scheme computation in terms of an algebraic rewriting of the program text. A program is rewritten until it is in a canonical form (if it has one). The canonical form is the final result.The stepper operates within the existing evaluator, by placing breakpoints and by reconstructing source expressions from source information placed on the stack. This approach raises two questions. First, do the run-time breakpoints correspond to the steps of the reduction semantics? Second, does the debugging mechanism insert enough information to reconstruct source expressions?To answer these questions, we develop a high-level semantic model of the extended compiler and run-time machinery. Rather than modeling the evaluation as a low-level machine, we model the relevant low-level features of the stepper's implementation in a high-level reduction semantics. We expect the approach to apply to other semantics-based tools. The Correctness of Programming Environment ToolsProgramming environments provide many tools that process programs semantically. The most common ones are compilers, program analysis tools, debuggers, and profilers. Our DrScheme programming environment [9,8] also provides an algebraic stepper for Scheme. It explains a program's execution as a sequence of reduction steps based on the ordinary laws of algebra for the functional core [2,