DOCSLIB.ORG

S Allegro Common Lisp Foreign Function Interface

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
S Allegro Common Lisp Foreign Function Interface Please do not remove this page Extensions to the Franz, Inc.'s Allegro Common Lisp foreign function interface Keane, John https://scholarship.libraries.rutgers.edu/discovery/delivery/01RUT_INST:ResearchRepository/12643408560004646?l#13643533500004646 Keane, J. (1996). Extensions to the Franz, Inc.’s Allegro Common Lisp foreign function interface. Rutgers University. https://doi.org/10.7282/t3-pqns-7h57 This work is protected by copyright. You are free to use this resource, with proper attribution, for research and educational purposes. Other uses, such as reproduction or publication, may require the permission of the copyright holder. Downloaded On 2021/09/29 22:58:32 -0400 Extensions to the Franz Incs Allegro Common Lisp Foreign Function Interface John Keane Department of Computer Science Rutgers University New Brunswick NJ keanecsrutgersedu January Abstract As provided by Franz Inc the foreign function interface of Allegro Com mon Lisp has a number of limitations This pap er describ es extensions to the interface that facilitate the inclusion of C and Fortran co de into Common Lisp systems In particular these extensions make it easy to utilize libraries of numerical subroutines such as those from Numerical Recip es in C from within ACL including those routines that take functions as arguments A mechanism for creating Lisplike dynamic runtime closures for C routines is also describ ed Acknowledgments The research presented in this do cument is supp orted in part by NASA grants NCC and NAG This research is also part of the Rutgers based HPCD Hyp ercomputing and Design pro ject supp orted by the Ad vanced Research Pro jects Agency of the Department of Defense through contract ARPADABT C Motivation Allegro Common Lisp from Franz Inc provides a means for Lisp routines to utilize subroutines written in C and Fortran called the foreign function interface Franz Though adequate for most purp oses the foreign function interface is not as easy to use as might b e desired and do es not supp ort certain kinds of interface with foreign co de as straightforwardly as we might wish In particular we found it dicult to dene and use foreign co de that takes functions as arguments such as a NewtonRaphson ro ot nder b ecause of the way in which Ccallable Lisp functions are dened Additionally ACL version and later utilizes two dierent mecha nisms for loading foreign co de into the Lisp image one for SVR and Posix op erating systems and one for BSD op erating systems Under SVR sys tems all foreign co de must b e rst linked into sharedob ject so libraries While this provides signicant improvement in the sp eed of loading foreign co de and reduces the size of the Lisp image it requires that the sharedob ject libraries b e dened and built ahead of time The two load mechanisms place an additional burden on Lisp user programs to b e aware of the system under which they are running and act accordingly if they are to b e p ortable In writing these extensions we wished to make using foreign co de as transparent to the user as p ossible We built on top of the solid foundation of the existing foreign function interface These extensions do not replace functionality in ACL they complement it The Foreign Function Extensions Calling Mo del Figure illustrates the mo del that is used for all foreign function inter actions dened through the extensions In the example the Lisp function foo wishes to call the C routine bar which wishes to call the Lisp func tion baz These calls are not made directly but are made through help er routines that are automatically generated when the functions are dened in Lisp These help er routines add a small amount of additional overhead to each foreign function call but provide imp ortant functionality in providing parameter management In Figure the Lisp function foo calls the Lisp standin function bar (foo ...) (bar (x y z) ...) bar_c_fe(P) bar(x',y',z') (baz-lisp-fe (P) ...) baz(a,b,c) (baz (a',b',c') ...) Lisp C Figure Foreign Function Extensions Calling Mo del This function takes the arguments of the C routine bar which it then re packages into a parameter control blo ck and calls the C frontend routine bar c fe This routine takes the parameter control blo ck and calls the target C routine bar after recovering the parameters The C routine bar calls the C standin routine baz This function takes the arguments of the Lisp function baz which it then repackages into a parameter control blo ck and calls the Lisp frontend routine bazlispfe This function takes the parameter control blo ck and calls the target Lisp function baz after recovering the parameters Dening Foreign Functions Two new functions have b een added to dene foreign functions These are ffxdefineCroutine header key typecheck nil writefiles t compile nil interfacelispdir interfacecdir ffxdefineFortranroutine header key typecheck nil writefiles t compile nil interfacelispdir interfacecdir Both functions have a required argument the header This sp ecies the calling parameters and return values of the function using C data types The header can b e automatically created by parsing the C header for the 1 function The typecheck argument sp ecies whether argument type checking co de is to b e included in the interface functions The writefiles argument sp ecies whether the generated interface co de is to b e written out The compile argument sp ecies whether the interface routines are to b e compiled The last two arguments give the target directories for the interface co de These routines dier from the ACL ffdefforeign function in that they do not need to b e invoked every time the foreign co de is included into a system If the interface routines are written out and compiled only the load function b elow need b e used Dening Ccallable Lisp Functions ffxdefineexternalcallable header key callback nil writefiles t compile nil interfacelispdir interfacecdir 1 C headers can b e generated for Fortran routines by using the widelyavailable fc Fortran to C compiler The arguments to this routine are much the same as for the previous two routines except that the function sp ecied in the header is a Lisp function If the callback argument is t the interface is generated as a callback which will allow C routines to call dynamic lambda expressions Loading Foreign Functions ffxloadexternalsystem key routines files libraries interfacelispdir interfacecdir solibname solibdir rebuildsolib t The routines argument is a list of strings containing the names of rou tines dened by ffxdefineCroutine ffxdefineFortranroutine or ffxdefineexternalcallable The files argument is a list of strings containing the names of ob ject les to load The libraries argument is a list of strings containing the names of system libraries or lo cal libraries to load with the foreign co de Under SVR systems the user must sp ecify solibname the name of the sharedob ject so lib If rebuildsolib is T the so lib will b e rebuilt b efore loading This function handles the entire foreign load pro cess under b oth SVR and BSD systems It issues the required ffdefforeign calls and invokes the foreign function loader It also takes care of registering the externally callable Lisp functions and passing the call p ointers to the asso ciated C interface functions If the interface routines have b een previously generated and compiled this function is the only one required to load external co de into the Lisp system Passing Lisp Functions to Foreign Func tions Many C routines take a C function p ointer as an argument If the user wishes to pass a named Lisp routine to a C function she may use the function ffxgetCfunctionpointer which takes the name of a Lisp function previously dened with ffxdefineexternalcallable and returns the p ointer to the C standin interface routine for that function Supp ose that the user wishes to pass a dynamically created lambda ex pression instead such as a function closure Because of their dynamic na ture it would b e highly inecient to have to generate a separate unique interface for each dynamic closure Instead the user may use the function ffxbindlispcallback This function takes as arguments a lambda ex pression and the name of a callback previously dened with ffxdefineexternalcallable taking the same formals as the lambda A C function p ointer is returned that when dereferenced by a C routine will cause the closure to b e called through the callback interface co de Any number of dynamically generated closures can b e b ound to a single callback and a unique C function p ointer will b e created for each The function ffxbindlispcallback works by creating a tiny machine language program called a function vector Each function vector is ab out bytes long and is malloced in Lisp foreign function space The function vec tor contains the address of the C standin interface routine for the callback the address of a designated storage lo cation in Lisp foreign function space and a unique Lisp index to the closure The address of the function vector is what is returned by ffxbindlispcallback When control is transfered to the function vector it stores the closure index into the designated storage lo cation and transfers control unconditionall y to the C standin interface routine Since the stack is not touched the C standin interface routine nds all the arguments it is exp ecting just as if it had b een called directly by the C routine It then builds the parameter blo ck and calls the Lisp front end for the callback The frontend function lo oks at the designated storage lo cation nds the index
Load more

Recommended publications
  • Introduction to Programming in Lisp
    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • Omnipresent and Low-Overhead Application Debugging
    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), nor to step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers, including those desired when it comes to debugging tools available to the of the system itself, such as the compiler.
    [Show full text]
  • PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63P
    DOCUMENT RESUME ED 290 438 IR 012 986 AUTHOR Cunningham, Robert E.; And Others TITLE Chips: A Tool for Developing Software Interfaces Interactively. INSTITUTION Pittsburgh Univ., Pa. Learning Research and Development Center. SPANS AGENCY Office of Naval Research, Arlington, Va. REPORT NO TR-LEP-4 PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63p. PUB TYPE Reports - Research/Technical (143) EDRS PRICE MF01/PC03 Plus Postage. DESCRIPTORS *Computer Graphics; *Man Machine Systems; Menu Driven Software; Programing; *Programing Languages IDENTIF7ERS Direct Manipulation Interface' Interface Design Theory; *Learning Research and Development Center; LISP Programing Language; Object Oriented Programing ABSTRACT This report provides a detailed description of Chips, an interactive tool for developing software employing graphical/computer interfaces on Xerox Lisp machines. It is noted that Chips, which is implemented as a collection of customizable classes, provides the programmer with a rich graphical interface for the creation of rich graphical interfaces, and the end-user with classes for modeling the graphical relationships of objects on the screen and maintaining constraints between them. This description of the system is divided into five main sections: () the introduction, which provides background material and a general description of the system; (2) a brief overview of the report; (3) detailed explanations of the major features of Chips;(4) an in-depth discussion of the interactive aspects of the Chips development environment; and (5) an example session using Chips to develop and modify a small portion of an interface. Appended materials include descriptions of four programming techniques that have been sound useful in the development of Chips; descriptions of several systems developed at the Learning Research and Development Centel tsing Chips; and a glossary of key terms used in the report.
    [Show full text]
  • Allegro CL User Guide
    Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format
    [Show full text]
  • Threading and GUI Issues for R
    Threading and GUI Issues for R Luke Tierney School of Statistics University of Minnesota March 5, 2001 Contents 1 Introduction 2 2 Concurrency and Parallelism 2 3 Concurrency and Dynamic State 3 3.1 Options Settings . 3 3.2 User Defined Options . 5 3.3 Devices and Par Settings . 5 3.4 Standard Connections . 6 3.5 The Context Stack . 6 3.5.1 Synchronization . 6 4 GUI Events And Blocking IO 6 4.1 UNIX Issues . 7 4.2 Win32 Issues . 7 4.3 Classic MacOS Issues . 8 4.4 Implementations To Consider . 8 4.5 A Note On Java . 8 4.6 A Strategy for GUI/IO Management . 9 4.7 A Sample Implementation . 9 5 Threads and GUI’s 10 6 Threading Design Space 11 6.1 Parallelism Through HL Threads: The MXM Options . 12 6.2 Light-Weight Threads: The XMX Options . 12 6.3 Multiple OS Threads Running One At A Time: MSS . 14 6.4 Variations on OS Threads . 14 6.5 SMS or MXS: Which To Choose? . 14 7 Light-Weight Thread Implementation 14 1 March 5, 2001 2 8 Other Issues 15 8.1 High-Level GUI Interfaces . 16 8.2 High-Level Thread Interfaces . 16 8.3 High-Level Streams Interfaces . 16 8.4 Completely Random Stuff . 16 1 Introduction This document collects some random thoughts on runtime issues relating to concurrency, threads, GUI’s and the like. Some of this is extracted from recent R-core email threads. I’ve tried to provide lots of references that might be of use.
    [Show full text]
  • A Quick Introduction to Common Lisp
    CSC 244/444 Notes last updated Feb 3, 2020 A Quick Introduction to Common Lisp Lisp is a functional language well-suited to sym- bolic AI, based on the λ-calculus and with list structures as a very flexible basic data type; pro- grams are themselves list structures, and thus can be created and manipulated just like other data. This introduction isn't intended to give you all the details, but just enough to get across the essential ideas, and to let you get under way quickly. The best way to make use of it is in front of a computer, trying out all the things mentioned. Basic characteristics of Lisp and Common Lisp: • Lisp is primarily intended for manipulating symbolic data in the form of list struc- tures, e.g., (THREE (BLIND MICE) SEE (HOW (THEY RUN)) !) • Arithmetic is included, e.g., (SQRT (+ (* 3 3) (* 4 4))) or (sqrt (+ (* 3 3) (* 4 4))) (Common Lisp is case-insensitive, except in strings between quotes " ... ", specially delimited symbols like |Very Unusual Symbol!|, and for characters prefixed with \\"). • Common Lisp (unlike John McCarthy's original \pure" Lisp) has arrays and record structures; this leads to more understandable and efficient code, much as in typed languages, but there is no obligatory typing. • All computation consists of expression evaluation. For instance, typing in the above (SQRT ...) expression and hitting the enter key immediately gives 5. • Lisp is a functional language based on Alonzo Church's λ-calculus (which like Turing machines provides a complete basis for all computable functions). For instance, a function for the square root of the sum of two squares can be expressed as (lambda (x y) (sqrt (+ (* x x) (* y y)))).
    [Show full text]
  • Parallel Programming with Lisp for Performance
    Parallel Programming with Lisp for Performance Pascal Costanza, Intel, Belgium European Lisp Symposium 2014, Paris, France The views expressed are my own, and not those of my employer. Legal Notices • Cilk, Intel, the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries. Other names and brands may be claimed as the property of others. Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. Intel does not control or audit the design or implementation of third party benchmark data or Web sites referenced in this document. Intel encourages all of its customers to visit the referenced Web sites or others where similar performance benchmark data are reported and confirm whether the referenced benchmark data are accurate and reflect performance of systems available for purchase. • Optimization Notice: Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instructions sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. (Notice revision #20110804) • Copyright © 2014 Intel Corporation.
    [Show full text]
  • Common Lisp Quick Reference
    Common Lisp Quick Reference Compiled by W Burger WS Symb ols nil Constant whose value is itself NIL t Constant whose value is itself T symbolp e Returns T if e evaluates to a symb ol otherwise NIL boundp e Returns T if the value of e whichmust b e a symb ol has neither a global nor a lo cal value defvar sym e Denes sym to b e a global variable with initial value e defparameter sym e Denes sym to b e a global parameter whose value initial e will maychange at runtime but is not exp ected to defconstant sym e Denes sym to b e a global constant whose value e will not change while the program is running Value Assignment setf place e Stores the value of e in the place sp ecied by place setq sym e Evaluates e and makes it the value of the symbol sym the value of e is returned InputOutput read stream Reads the printed representation of a single ob ject from stream which defaults to standardinput builds a corresp onding ob ject and returns the ob ject readline stream eoferrorp eofvalue recursivep Reads a line of text terminated by a newline or endoffile character from stream which defaults to standardinput and returns two values the line as a character string and a Bo olean value T if the line was terminated byanendoffile and NIL if it was terminated by a newline readchar stream eoferrorp eofvalue recursivep Reads one character from stream which defaults to standardinput and returns the corre sp onding character ob ject readcharnohang stream eoferrorp eofvalue recursivep Reads and returns a character from stream which defaults to standardinputif
    [Show full text]
  • The Racket Manifesto∗
    The Racket Manifesto∗ Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi Eli Barzilay, Jay McCarthy, Sam Tobin-Hochstadt Abstract The creation of a programming language calls for guiding principles that point the developers to goals. This article spells out the three basic principles behind the 20-year development of Racket. First, programming is about stating and solving problems, and this activity normally takes place in a context with its own language of discourse; good programmers ought to for- mulate this language as a programming language. Hence, Racket is a programming language for creating new programming languages. Second, by following this language-oriented approach to programming, systems become multi-lingual collections of interconnected components. Each language and component must be able to protect its specific invariants. In support, Racket offers protection mechanisms to implement a full language spectrum, from C-level bit manipulation to soundly typed extensions. Third, because Racket considers programming as problem solving in the correct language, Racket also turns extra-linguistic mechanisms into linguistic constructs, especially mechanisms for managing resources and projects. The paper explains these principles and how Racket lives up to them, presents the evaluation framework behind the design process, and concludes with a sketch of Racket’s imperfections and opportunities for future improvements. 1998 ACM Subject Classification D.3.3 Language Constructs and Features Keywords and phrases design
    [Show full text]
  • An Open Source Implementation of the Locator/ID Separation Protocol
    OpenLISP: An Open Source Implementation of the Locator/ID Separation Protocol L. Iannone D. Saucez O. Bonaventure TUB – Deutsche Telekom Laboratories AG, Universit´ecatholique de Louvain Universit´ecatholique de Louvain [email protected] [email protected] [email protected] Abstract—The network research community has recently description of the encapsulation and decapsulation operations, started to work on the design of an alternate Internet Archi- the forwarding operation and offer several options as mapping tecture aiming at solving some scalability issues that the current system. Nevertheless there is no specification of an API to Internet is facing. The Locator/ID separation paradigm seems to well fit the requirements for this new Internet Architecture. allow the mapping system to interact with the forwarding Among the various solutions, LISP (Locator/ID Separation Pro- engine. In OpenLISP we proposed and implemented a new tocol), proposed by Cisco, has gained attention due to the fact socket based solution in order to overcome this issue: the that it is incrementally deployable. In the present paper we give Mapping Sockets. Mapping sockets make OpenLISP an open a short overview on OpenLISP, an open-source implementation and flexible solution, where different approaches for the lo- of LISP. Beside LISP’s basic specifications, OpenLISP provides a new socket-based API, namely the Mapping Sockets, which makes cator/ID separation paradigm can be experimented, even if OpenLISP an ideal experimentation platform for LISP, but also not strictly related to LISP. To the best of our knowledge, other related protocols. OpenLISP is the only existing effort in developing an open source Locator/ID separation approach.
    [Show full text]
  • Proposal for a Dynamic Synchronous Language Pejman Attar, Frédéric Boussinot, Louis Mandel, Jean-Ferdy Susini
    Proposal for a Dynamic Synchronous Language Pejman Attar, Frédéric Boussinot, Louis Mandel, Jean-Ferdy Susini To cite this version: Pejman Attar, Frédéric Boussinot, Louis Mandel, Jean-Ferdy Susini. Proposal for a Dynamic Syn- chronous Language. 2011. hal-00590420 HAL Id: hal-00590420 https://hal.archives-ouvertes.fr/hal-00590420 Preprint submitted on 3 May 2011 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Proposal for a Dynamic Synchronous Language∗ Pejman Attar Fr´ed´eric Boussinot Louis Mandel INRIA - INDES INRIA - INDES Universit´eParis 11 - LRI [email protected] [email protected] INRIA - PARKAS [email protected] Jean-Ferdy Susini CNAM - C´edric [email protected] May 3, 2011 Abstract or Java threads). The simplification basically results from a cleaner and simpler semantics, which reduces We propose a new scripting language called DSL bas- the number of possible interleavings in parallel com- ed on the synchronous/reactive model. In DSL, sys- putations. However, standard synchronous languages tems are composed of several sites executed asyn- introduce specific issues (namely, non-termination of chronously, and each site is running scripts in a syn- instants) and have major difficulties to cope with dy- chronous parallel way.
    [Show full text]