Simulating futures in extended common LISP

Stack-groups comprise the mechanism underlying implementation of multiprocessing in Extended Common LISP, i.e., running multiple quasi-simultaneous processes within a single LISP address space. On the other hand, the future construct of MULTILISP, an extension of the LISP dialect scheme, deals with parallel execution. The source of concurrency that future exploits is the overlap between computation of a value and use of the value. Described is a simulation of the future construct by an interpreter utilizing stack-group extensions to common LISP

Some Notes on the Past and Future of Lisp-Stat

Lisp-Stat was originally developed as a framework for experimenting with dynamic graphics in statistics. To support this use, it evolved into a platform for more general statistical computing. The choice of the Lisp language as the basis of the system was in part coincidence and in part a very deliberate decision. This paper describes the background behind the choice of Lisp, as well as the advantages and disadvantages of this choice. The paper then discusses some lessons that can be drawn from experience with Lisp-Stat and with the R language to guide future development of Lisp-Stat, R, and similar systems.

A LISP-Ada connection

The prototype demonstrates the feasibility of using Ada for expert systems and the implementation of an expert-friendly interface which supports knowledge entry. In the Ford LISP-Ada Connection (FLAC) system LISP and Ada are used in ways which complement their respective capabilities. Future investigation will concentrate on the enhancement of the expert knowledge entry/debugging interface and on the issues associated with multitasking and real-time expert systems implementation in Ada

Some Notes on the Past and Future of Lisp-Stat

Lisp-Stat was originally developed as a framework for experimenting with dynamic graphics in statistics. To support this use, it evolved into a platform for more general statistical computing. The choice of the Lisp language as the basis of the system was in part coincidence and in part a very deliberate decision. This paper describes the background behind the choice of Lisp, as well as the advantages and disadvantages of this choice. The paper then discusses some lessons that can be drawn from experience with Lisp-Stat and with the R language to guide future development of Lisp-Stat, R, and similar systems

A novel security protocol for resolving addresses in the location/ID split architecture

The Locator/ID Separation Protocol (LISP) is a routing architecture that provides new semantics for IP addressing. In order to simplify routing operations and improve scalability in future Internet, the LISP uses two different numbering spaces to separate the device identifier from its location. In other words, the LISP separates the 'where' and the 'who' in networking and uses a mapping system to couple the location and identifier. This paper analyses the security and functionality of the LISP mapping procedure using a formal methods approach based on Casper/FDR tool. The analysis points out several security issues in the protocol such as the lack of data confidentiality and mutual authentication. The paper addresses these issues and proposes changes that are compatible with the implementation of the LISP

Securing address registration in location/ID split protocol using ID-based cryptography

The Locator/ID Separation Protocol (LISP) is a routing architecture that provides new semantics for IP addressing. In order to simplify routing operations and improve scalability in future Internet, the LISP separates the device identity from its location using two different numbering spaces. The LISP also, introduces a mapping system to match the two spaces. In the initial stage, each LISP-capable router needs to register with a Map Server, this is known as the Registration stage. However, this stage is vulnerable to masquerading and content poisoning attacks. Therefore, a new security method for protecting the LISP Registration stage is presented in this paper. The proposed method uses the ID-Based Cryptography (IBC) which allows the mapping system to authenticate the source of the data. The proposal has been verified using formal methods approach based on the well-developed Casper/FDR tool

The Jack Lisp API Version 1.1

The Lisp interface to Jack will allow general programming of Jack internals and should simplify all forms of Jack development. It will be distributed with Jack-5.7 and will allow users without source code to extend or modify Jack, and users with source code to have a high-level, object-oriented, interactive prototyping environment. After prototyping in lisp, developers can rewrite their code in C++ if speed is crucial, otherwise, code can be left in lisp to simplify maintenance and to insure upward compatibility with future Jack versions

And now for something completely different: running Lisp on GPUs

The internal parallelism of compute resources increases permanently, and graphics processing units (GPUs) and other accelerators have been gaining importance in many domains. Researchers from life science, bioinformatics or artificial intelligence, for example, use GPUs to accelerate their computations. However, languages typically used in some of these disciplines often do not benefit from the technical developments because they cannot be executed natively on GPUs. Instead existing programs must be rewritten in other, less dynamic programming languages. On the other hand, the gap in programming features between accelerators and common CPUs shrinks permanently. Since accelerators are becoming more competitive with regard to general computations, they will not be mere special-purpose processors in the future. It is a valid assumption that future GPU generations can be used in a similar or even the same way as CPUs and that compilers or interpreters will be needed for a wider range of computer languages. We present CuLi, an interactive Lisp interpreter, that performs all computations on a CUDA-capable GPU. The host system is needed only for the input and the output. At the moment, Lisp programs running on CPUs outperform Lisp programs on GPUs, but we present trends indicating that this might change in the future. Our study gives an outlook on the possibility of running Lisp programs or other dynamic programming languages on next-generation accelerators