(GADTs) have received much attention recently in the fp community. They generalize the type-parameterized datatypes by permitting constructors to produce different type-instantiations of the same datatype. We show that existing oopl such as Java and C# can express GADT definitions, and a large class of GADT-manipulating programs, through the use of generics, subclassing, and virtual dispatch. However, some programs can be written only through the use of redundant run-time casts. We propose a generalization of the type constraint mechanisms of C# and Java to avoid the need for such casts, present a Visitor pattern for GADTs, and describe a switch construct as an alternative to virtual dispatch on datatypes. This paper is, of course, related to the other items posted here about GADTs. The examples in the introduction might be somewhat relevant to the recent discussion about the static versus dynamic features of Java, and its type system.
Collection of links to monad implementations in various languages. Due to recent discussions here on LtU and on the Haskell mailing lists I've compiled a list of links to implementations of monads in various languages. If you know of any that aren't listed here, please submit them in a comment. * Clean * Haskell * Java * Joy * OCaml * Perl * Prolog * Python * Ruby * Scheme
concurrent paradigm, namely functional programming extended with threads and ports, which I call multi-agent dataflow programming. * The declarative concurrent subset (no ports) has no race conditions and can be programmed like a functional language. The basic concept is dataflow synchronization of single-assignment variables. A useful data structure is the stream, a list with dataflow tail used as a communication channel. * Nondeterminism can be added exactly where needed and minimally, by using ports - a named stream to which any thread can send. * All functional building blocks are concurrency patterns. Map, fold, filter, etc., are all useful for building concurrent programs. * Concurrent systems can be configured in any order and concurrently with actual use of the system. * Designing concurrent programs is any declarative part of the program can be put in own thread, loosening the coupling between system's parts * The paradigm is easily extended
Dependent type theory is rich enough to express that a program satisfies an input/output relational specification, but it could be hard to construct the proof term. On the other hand, squiggolists know very well how to show that one relation is included in another by algebraic reasoning. We demonstrate how to encode functional and relational derivations in a dependently typed programming language. A program is coupled with an algebraic derivation from a specification, whose correctness is guaranteed by the type system. Code accompanying the paper has been developed into an Agda library AoPA.
Advantages of Soft Typing This is a continuation of this discussion. The main points for soft typing are as follows. * Compile time type checks. Soft typing can catch the same amount of provable errors at compile time as static typing. * Automatic downcasts. Downcasts are done automatically assuming the program passes type checking. The main argument for explicit casts is that it provides the programmer with more information, but this is a misnomer. One does not have to write down information for it to be shown to him, so long as said information is inferrable. Note: whether or not you believe OCaml doesn't have casting is irrelevant, simply assume that, when I refer to casting, I also mean situations in which it's emulated. * Unimposing. Unless a piece of code is provably incorrect at compile time, the compiler can insert runtime checks.
As part of a larger project, we have built a declarative assembly language. This language enables us to specify multiple code paths to compute particular quantities, giving the instruction scheduler more flexibility in balancing execution resources for superscalar execution. The instruction scheduler is also innovative in that it includes aggressive pipelining, and exhaustive (but lazy) search for optimal instruction schedules. We present some examples where our approach has produced very promising results. I think this paper is a nice followup to the recent discussion of SPE because it goes further than that paper by analyzing what data are necessary to achieve the ultimate goal of optimal or near-optimal instruction scheduling on superscalar architectures. In other words, it strongly suggests that we can do better than simply embedding low-level instructions in a high-level language by instead embedding a graph of desired results (vertices) and instructions for reaching them