Event Handling Thoughts

Total Page:16

File Type:pdf, Size:1020Kb

Event Handling Thoughts Event Handling Thoughts Keyboard Input Focus Problem Statement: Assume a McCLIM frame has the keyboard input focus on the window manager/desktop environment level.1 1. How do we communicate to the (human) user which sheet/pane/gadget would receive a key event if a key was pressed? (And what do we do for McCLIM frames that do not have the focus on the window manager/desktop environment level) 2. When a key is actually pressed, to which sheet/pane/gadget should the key-pressed-event (and key-released-event) be delivered? Denitions Note how in the "no wm focus"/inactive gadgets case the foreground color is dimmed an the list gadget does not highlight the selected item. Also note how the blue border indicates the keyword input focus in the "wm focus" case. 1Can the window manager focus and keyboard input focus be separate on this level? 1 Constraints from the Specication cursor-focus cursor When true, the sheet owning the cursor has the input focus. (setf port-keyboard-input-focus) focus port The client to which keyboard events are to be dispatched stream-set-input-focus stream with-input-focus (stream) &body body Implemented in terms of the above, but note: By default, an application frame gives the input focus to the window associated with frame-query-io. Specication of Desired Behavior This section describes the expected behavior in terms of user-observable reactions to events generated by the user and the environment. It does not describe the implementation. Reaction to Specic Events 1. The window manager takes the focus away from a McCLIM frame (a) The sheet/pane/gadget that has the keyboard input focus loses the keyboard input focus and indicates this visually. (b) All sheets/panes/gadgets within the McCLIM frame switch from state active to state inactive and indicate this visually (we do not currently do this, but GTK applications, for example, do). 2. The window manager gives the focus to a McCLIM frame without a pointer button press in the frame (i.e. the behavior typically bound to M-Tab) (a) All sheets/panes/gadgets within the McCLIM frame switch from state inactive to state active and indicate this visually (we do not currently do this, but GTK applications, for example, do). (b) A sheet/pane/gadget gets the keyboard input focus: 2 If the frame gets the window manager focus for the rst time According to the specication, the sheet that is the value of frame-query-io gets the keyboard input focus and indicates this visually. If the frame has had the window manager focus before the sheet/pane/gadget that had the keyboard input focus when the frame last had the window manager focus gets the key- board input focus and indicates this visually. 3. The window manager gives the focus to a McCLIM frame in response to a pointer button press in the McCLIM frame. Is this just 2. followed by 5.? 4. The pointer enters a sheet/pane/gadget (within a McCLIM frame). This does not have an eect on the keyboard input focus (A "focus follows mouse" policy might be added later, though). 5. A pointer button is pressed over a sheet/pane/gadget (within a Mc- CLIM frame that already has the window manager focus). (a) The sheet/pane/gadget that has the keyboard input focus loses the keyboard input focus and indicates this visually. (b) The new port pointer sheet gets the keyboard input focus and indicates this visually. What happens if the new port pointer sheet does not accept input? The keyboard input focus could either remain unchanged or be delegated to some other sheet/pane/gadget. What happens if the pointer is moved out of the sheet instead of released? If the new port pointer sheet accepts input, it should get the keyboard input focus irregardless of the button release. 6. A key is pressed or released over a sheet/pane/gadget (within a Mc- CLIM frame). (a) The event is dispatched If the gesture of the event is bound to the "focus next" (or "focus previous", "focus parent", etc.) command then ???. 3 If the gesture of the event is not bound to the "focus next" command the event is dispatched to the sheet/pane/gadget s that has the keyboard input focus. (b) What happens if s does accept/handle the event? Imagine a slider-pane has the keyboard input focus. when the "down" key is pressed the slider adjusts its value, repaints, keeps the keyboard input focus. If however, say, the "f1" or "escape" key is pressed, maybe some other sheet like a menu should respond. Also, the frame's command table can have keystrokes bound to commands. Consider the McCLIM debugger which binds "e" to Evaluate In Frame. This currently prevents the user from typ- ing "e" into text editors and input streams. On the other hand, typing "e" while a slider-pane has the keyboard input focus could run the debugger command just ne. 7. The user inputs a "focus next" command. Probably out of scope for now Implementation Port Event Distribution Overview TODO what about enabled/disabled sheets? Ports generate "raw" events (KIND; s; p) where KIND is the event kind, s is the event sheet (a mirrored sheet) and p is the event position in s. These raw events are processed in distribute-event which does one or more of the following for each event: dispatch event e to its event sheet se dispatch event e to a dierent dispatch synthesized events instead of or in addition to e raw event -> distribute-event maybe -> synthesize -> synthesized event -> dispatch event maybe -> dispatch event 4 Denitions port pointer sheet Let e be the most recent pointer event distributed by a given port, let se be e's sheet and let pe be e's position. If e is not an exit event, the port pointer sheet after processing e is the sheet (mirrored or not) s such that s is a descendant of se 0 and pe 2 region(s) and there is no descendant s of s such that 0 pe 2 region(s ). If e is an exit event, let sm be se's rst mirrored ancestor. The port pointer sheet after processing e is sm if sm is not a graft nil if sm is a graft port pressed sheet Let epress be the most recent button press event and erelease the most recent button release event distributed by a given port. Let let se be epress's sheet and let pe be epress's position. If erelease occurred after epress, the port pressed sheet is nil. If erelease did not occur after epress, the port pressed sheet is the sheet (mirrored or not) s such that s is a descendant of se and 0 pe 2 region(s) and there is no descendant s of s such that pe 2 region(s0). port grabbed sheet TODO Synthesis of Boundary Events Specication Let e1; e2;::: be the sequence of (potentially synthesized) boundary events 2 dispatched by a given port . Let stacki be the state of a stack that is main- tained according to stack0 = () ( stack if is an enter event (sei ; i−1) ei stacki = rest where stacki−1 = (s; rest) if ei is an exit event 2I.e., this specication describes the expected event output of a port after potentially discarding, re-routing and synthesizing events. It does not describe the root causes of the eventually produced events or how the port processes events. 5 The following properties must hold for each stack : i = (si;1; : : : ; si;ni ) 1. is a graft (the parent of the sheet at the bottom of the parent(si;ni ) stack must be a graft) 2. 8si;j; si;j+1; 1 ≤ j ≤ ni − 1 : parent(si;j) = si;j+1 (adjacent sheets on the stack must be parent and child) 3. If is an exit event, then stack (exit events must only ei i = (sei ;::: ) refer to the sheet at the top of the stack) These properties ensure that It is not possible to dispatch two enter events for a given sheet without an exit event between them. Otherwise property 2) would be violated. There fore, no sheet appears on the stack twice. It is not possible to dispatch two exit events for a given sheet without an enter event between them. Other property 3) would be violated when dispatching the second exit event. Algorithm Let e0 and e be the two most recent events with e0 occurring before e. Let 0 se be e's sheet and let pe be e's position. Let spointer and spointer be the port pointer sheets after processing e0 and e respectively. 0 1. If e is neither an enter nor an exit event, it must be true that mirrored-ancestor(spointer) = mirrored-ancestor(spointer). Let sma = mirrored-ancestor(spointer) and 0 sca = common-ancestor(spointer; spointer). sma = sca may or may not hold, but it is true that sma is an ancestor of sca. Dispatch a sequence of synthesized exit events: 0 (exit; spointer; pe) 0 (exit; parent(spointer); pe) . (exit; s; pe) where parent(s) = sca Dispatch a sequence of synthesized enter events: (enter; s1; pe) where parent(s1) = sca ^ s1 ancestor of spointer (enter; s2; pe) where parent(s2) = s1 ^ s2 ancestor of spointer 6 . (enter; spointer; pe) 2. If e is an enter event (a) Dispatch synthesized exit events (b) Dispatch e (c) Dispatch synthesized enter events 3. Exit (a) Dispatch synthesized exit events (b) Dispatch e (c) Dispatch synthesized enter events Specics of X Has multiple kinds of boundary events, some of which must be handled specially to t our model: "inferior" enter/exit events The events are generated when the pointer moves from a parent X window to a child X window or the other way around.
Recommended publications
  • 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]
  • How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)
    How Lisp Systems Look Different In Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008) Adrian Dozsa Tudor Gˆırba Radu Marinescu Politehnica University of Timis¸oara University of Berne Politehnica University of Timis¸oara Romania Switzerland Romania [email protected] [email protected] [email protected] Abstract rently used in a variety of domains, like bio-informatics (BioBike), data mining (PEPITe), knowledge-based en- Many reverse engineering approaches have been devel- gineering (Cycorp or Genworks), video games (Naughty oped to analyze software systems written in different lan- Dog), flight scheduling (ITA Software), natural language guages like C/C++ or Java. These approaches typically processing (SRI International), CAD (ICAD or OneSpace), rely on a meta-model, that is either specific for the language financial applications (American Express), web program- at hand or language independent (e.g. UML). However, one ming (Yahoo! Store or reddit.com), telecom (AT&T, British language that was hardly addressed is Lisp. While at first Telecom Labs or France Telecom R&D), electronic design sight it can be accommodated by current language inde- automation (AMD or American Microsystems) or planning pendent meta-models, Lisp has some unique features (e.g. systems (NASA’s Mars Pathfinder spacecraft mission) [16]. macros, CLOS entities) that are crucial for reverse engi- neering Lisp systems. In this paper we propose a suite of Why Lisp is Different. In spite of its almost fifty-year new visualizations that reveal the special traits of the Lisp history, and of the fact that other programming languages language and thus help in understanding complex Lisp sys- borrowed concepts from it, Lisp still presents some unique tems.
    [Show full text]
  • ESA: a CLIM Library for Writing Emacs-Style Applications
    ESA: A CLIM Library for Writing Emacs-Style Applications Robert Strandh Troels Henriksen LaBRI, Université Bordeaux 1 DIKU, University of Copenhagen 351, Cours de la Libération Universitetsparken 1, Copenhagen 33405 Talence Cedex [email protected] France [email protected] David Murray Christophe Rhodes ADMurray Associates Goldsmiths, University of London 10 Rue Carrier Belleuse, 75015 Paris New Cross Road, London, SE14 6NW [email protected] [email protected] ABSTRACT style applications. The central distinguishing feature of an We describe ESA (for Emacs-Style Application), a library Emacs-style application, for our purposes, is that it uses for writing applications with an Emacs look-and-feel within short sequences of keystrokes as the default method of in- the Common Lisp Interface Manager. The ESA library voking commands, and only occasionally requires the user to takes advantage of the layered design of CLIM to provide a type the full name of the command in a minibuffer. A spe- command loop that uses Emacs-style multi-keystroke com- cial keystroke (M-x) is used to invoke commands by name. mand invocation. ESA supplies other functionality for writ- This interaction style is substantially different from the one ing such applications such as a minibuffer for invoking ex- provided by CLIM by default, and therefore required us to tended commands and for supplying command arguments, write a different CLIM top level. Fortunately, CLIM was Emacs-style keyboard macros and numeric arguments, file designed to make this not only possible but fairly straight- and buffer management, and more. ESA is currently used forward, as the implementation of a replacement top level in two major CLIM applications: the Climacs text editor can build on the protocol layers beneath, just as the default (and the Drei text gadget integrated with the McCLIM im- top level is built.
    [Show full text]
  • Pipenightdreams Osgcal-Doc Mumudvb Mpg123-Alsa Tbb
    pipenightdreams osgcal-doc mumudvb mpg123-alsa tbb-examples libgammu4-dbg gcc-4.1-doc snort-rules-default davical cutmp3 libevolution5.0-cil aspell-am python-gobject-doc openoffice.org-l10n-mn libc6-xen xserver-xorg trophy-data t38modem pioneers-console libnb-platform10-java libgtkglext1-ruby libboost-wave1.39-dev drgenius bfbtester libchromexvmcpro1 isdnutils-xtools ubuntuone-client openoffice.org2-math openoffice.org-l10n-lt lsb-cxx-ia32 kdeartwork-emoticons-kde4 wmpuzzle trafshow python-plplot lx-gdb link-monitor-applet libscm-dev liblog-agent-logger-perl libccrtp-doc libclass-throwable-perl kde-i18n-csb jack-jconv hamradio-menus coinor-libvol-doc msx-emulator bitbake nabi language-pack-gnome-zh libpaperg popularity-contest xracer-tools xfont-nexus opendrim-lmp-baseserver libvorbisfile-ruby liblinebreak-doc libgfcui-2.0-0c2a-dbg libblacs-mpi-dev dict-freedict-spa-eng blender-ogrexml aspell-da x11-apps openoffice.org-l10n-lv openoffice.org-l10n-nl pnmtopng libodbcinstq1 libhsqldb-java-doc libmono-addins-gui0.2-cil sg3-utils linux-backports-modules-alsa-2.6.31-19-generic yorick-yeti-gsl python-pymssql plasma-widget-cpuload mcpp gpsim-lcd cl-csv libhtml-clean-perl asterisk-dbg apt-dater-dbg libgnome-mag1-dev language-pack-gnome-yo python-crypto svn-autoreleasedeb sugar-terminal-activity mii-diag maria-doc libplexus-component-api-java-doc libhugs-hgl-bundled libchipcard-libgwenhywfar47-plugins libghc6-random-dev freefem3d ezmlm cakephp-scripts aspell-ar ara-byte not+sparc openoffice.org-l10n-nn linux-backports-modules-karmic-generic-pae
    [Show full text]
  • Mcclim Demonstration
    McCLIM Demonstration Daniel Kochmanski´ TurtleWare – Daniel Kochmanski´ Przemysl,´ Poland [email protected] ABSTRACT tectural pattern in a consistent way while also providing We describe what is a Common Lisp Interface Manager[2] defaults and the ability to customize its behavior. implementation called McCLIM[7]. In particular, we de- McCLIM is a free open source implementation of CLIM scribe recent improvements of the code base. We illustrate II specification with extensions proposed by Franz Inc. in the CLIM 2 User Guide, version 2.2.2. As of 2017, Mc- McCLIM and recent development by developing a demo ap- 1 plication \Clamber", which is a book collection managament CLIM (and recently opensourced clim2 ) is the only avail- tool, which was created in purpose of explaining CLIM con- able native graphic user interface toolkit available to the cepts in form of a tutorial. Common Lisp ecosystem . Other solutions are based on foreign tools (LTK2, CommonQt3 or EQL54) or are com- mercial (Common Graphics5, CAPI[?]). Another frequently CCS Concepts used approach is creating web applications with frameworks. •Software and its engineering ! Integrated and vi- A few applications and libraries written in McCLIM are sual development environments; shipped with McCLIM code repository: Keywords • Listener Common Lisp, graphic user interfaces The McCLIM Listener provides an interactive toplevel with full access to the graphical capabilities of CLIM 1. INTRODUCTION and a set of built-in commands intended to be useful for Lisp development and experimentation. The CLIM specification[3] is large and requires some ini- tial work from the programmer to start writing programs • Inspector using CLIM.
    [Show full text]
  • Non-Profit Foundation Formed to Proceed with Housing Plan
    0 u Go Mnivoutli, 111 Read the Herald H . Pomp Read the Herald For Local Mews For Local News Serving Summit Im $8 Ytmn ERALD Serving Summit for 68 fear§ Record 68th Year—No, 20 Cm»rH •• Sftooi Claw Mattrr at Ih* tolofftr* SUMMIT, N. J., THURSDAY, OCTOBER II. 1956 kt Summit. N 1, lain tk« 4rl bt Ma/cb 1 ItTf K A YEAR 10 CUNTS Non-Profit Foundation Formed Case and Forbes Women Voters Tow United Appeal Opens Sunday; To Proceed With Housing Plan Both Speaking at Lack of Space Cuts October 18 Italy Library Services Ministers Back $145,800 Goal A major step in a community plan to provide low-cost Inadenuate library facilities, due ' Summit clergymen for the first time in the 19-year Two of New Jersey's foremost hotting unit* lor local residents was disclosed this week bv largely to lack if space, wan thp ihistojy of the United Campaign have united to back thU Republic***, U. S. Senator Clif- the announcement of the formation of a non-profit corpora- sub-eci of a discussion recently year's fund drive and to urge all-out support of the cam- tion called Summit Civic Foundation, Inc. tait will attempt ford P. Case aod State Sen. Mai cclra S. Foitoet, wiS urge Summit *h>nthr Summit League of Worn-ipaign by their respective congregations. Only once before * <o raise $90,000 to 3 per cent notes to finance the i>rmx*£i '• en Y»ters met to consider the need voters to give complete support has the nty a clergy publicly banded to support a civic 14 unit housing project on Weaver i for a new library building here.
    [Show full text]
  • A Free Implementation of CLIM
    A Free Implementation of CLIM Robert Strandh∗ Timothy Moorey August 17, 2002 Abstract McCLIM is a free implementation of the Common Lisp Interface Man- gager, or CLIM, specification. In this paper we review the distinguishing features of CLIM, describe the McCLIM implementation, recount some of the history of the McCLIM effort, give a status report, and contemplate future directions. McCLIM is a portable implementation of the Common Lisp Interface Man- gager, or CLIM, specification[9] released under the Lesser GNU Public License (LGPL). CLIM was originally conceived as a library for bringing advanced fea- tures of the Symbolics Genera system[3], such as presentations, context sensitive input, sophisticated command processing, and interactive help, to Common Lisp implementations running on stock hardware. The CLIM 2.0 specification added \look-and-feel" support so that CLIM applications could adopt the appearance and behavior of native applications without source code changes. Several Lisp vendors formed a consortium in the late 80s to share code in a common CLIM implementation, but for a variety of reasons the visibility of CLIM has been limited in the Common Lisp community. The McCLIM project has created an implementation of CLIM that, in the summer of 2002, is almost feature complete. Initially created by merging several developers' individual efforts, McCLIM is being used by several programs including a music editor, a web browser, and an IRC client (see Figure 1). Some non-graphic parts of CLIM have been adopted into the IMHO web server[2]. In this paper we review the distinguishing features of CLIM, describe the McCLIM implementation, recount some of the history of the McCLIM effort, give a stlatus report, and contemplate future directions for McCLIM.
    [Show full text]
  • Common Lisp Ecosystem and Software Distribution
    Introduction to Common Lisp Compilation and system images System definition and building Software distribution Summary Common Lisp ecosystem and the software distribution model Daniel Kochma´nski TurtleWare July 3, 2016 Daniel Kochma´nski Common Lisp software distribution Introduction to Common Lisp Compilation and system images Historical note System definition and building Distinctive features Software distribution Current state Summary 1936 { Alozno Church invents Lambda Calculus 1960 { John McCarthy presents paper about LISP 1973 { MIT Lisp Machine Project 1984 { AI winter (and the unfortunate marriage with Lisp) 1994 { Various dialects unification with Common Lisp 2000 { Renaissance of the community Daniel Kochma´nski Common Lisp software distribution Introduction to Common Lisp Compilation and system images Historical note System definition and building Distinctive features Software distribution Current state Summary Figure: \John McCarthy presents Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I" { Painting by Ferdinand Bol, 1662 Daniel Kochma´nski Common Lisp software distribution Introduction to Common Lisp Compilation and system images Historical note System definition and building Distinctive features Software distribution Current state Summary Figure: John McCarthy (1927-2011) Daniel Kochma´nski Common Lisp software distribution Introduction to Common Lisp Compilation and system images Historical note System definition and building Distinctive features Software distribution Current state Summary
    [Show full text]
  • Mcclim Manual Draft
    McCLIM User's Manual The Users Guide and API Reference Copyright c 2004,2005,2006,2007,2008,2017,2019 the McCLIM hackers. i Table of Contents Introduction ::::::::::::::::::::::::::::::::::::::::: 1 Standards ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 How CLIM Is Different :::::::::::::::::::::::::::::::::::::::::::::: 1 1 User manual ::::::::::::::::::::::::::::::::::::: 3 1.1 Building McCLIM :::::::::::::::::::::::::::::::::::::::::::::: 3 1.1.1 Examples and demos::::::::::::::::::::::::::::::::::::::: 3 1.1.2 Applications ::::::::::::::::::::::::::::::::::::::::::::::: 3 1.2 The first application :::::::::::::::::::::::::::::::::::::::::::: 4 1.2.1 A bit of terminology ::::::::::::::::::::::::::::::::::::::: 4 1.2.2 How CLIM applications produce output :::::::::::::::::::: 4 1.2.3 Panes and Gadgets :::::::::::::::::::::::::::::::::::::::: 6 1.2.4 Defining Application Frames ::::::::::::::::::::::::::::::: 6 1.2.5 A First Attempt ::::::::::::::::::::::::::::::::::::::::::: 6 1.2.6 Executing the Application ::::::::::::::::::::::::::::::::: 8 1.2.7 Adding Functionality :::::::::::::::::::::::::::::::::::::: 8 1.2.8 An application displaying a data structure :::::::::::::::: 11 1.3 Using incremental redisplay:::::::::::::::::::::::::::::::::::: 13 1.4 Using presentation types::::::::::::::::::::::::::::::::::::::: 15 1.4.1 What is a presentation type::::::::::::::::::::::::::::::: 16 1.4.2 A simple example::::::::::::::::::::::::::::::::::::::::: 16 1.5 Using views :::::::::::::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • ASDF: Another System Definition Facility This Manual Describes ASDF, a System Definition Facility for Common Lisp Programs and Libraries
    ASDF: Another System Definition Facility This manual describes ASDF, a system definition facility for Common Lisp programs and libraries. You can find the latest version of this manual at http://common-lisp.net/project/ asdf/asdf.html. ASDF Copyright c 2001-2014 Daniel Barlow and contributors. This manual Copyright c 2001-2014 Daniel Barlow and contributors. This manual revised c 2009-2014 Robert P. Goldman and Francois-Rene Rideau. Permission is hereby granted, free of charge, to any person obtaining a copy of this soft- ware and associated documentation files (the \Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED \AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONIN- FRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. i Table of Contents 1 Introduction::::::::::::::::::::::::::::::::::::: 1 2 Quick start summary :::::::::::::::::::::::::::
    [Show full text]
  • 9 European Lisp Symposium
    Proceedings of the 9th European Lisp Symposium AGH University of Science and Technology, Kraków, Poland May 9 – 10, 2016 Irène Durand (ed.) ISBN-13: 978-2-9557474-0-7 ISSN: 2677-3465 Contents Preface v Message from the Programme Chair . vii Message from the Organizing Chair . viii Organization ix Programme Chair . xi Local Chair . xi Programme Committee . xi Organizing Committee . xi Sponsors . xii Invited Contributions xiii Program Proving with Coq – Pierre Castéran .........................1 Julia: to Lisp or Not to Lisp? – Stefan Karpinski .......................1 Lexical Closures and Complexity – Francis Sergeraert ...................2 Session I: Language design3 Refactoring Dynamic Languages Rafael Reia and António Menezes Leitão ..........................5 Type-Checking of Heterogeneous Sequences in Common Lisp Jim E. Newton, Akim Demaille and Didier Verna ..................... 13 A CLOS Protocol for Editor Buffers Robert Strandh ....................................... 21 Session II: Domain Specific Languages 29 Using Lisp Macro-Facilities for Transferable Statistical Tests Kay Hamacher ....................................... 31 A High-Performance Image Processing DSL for Heterogeneous Architectures Kai Selgrad, Alexander Lier, Jan Dörntlein, Oliver Reiche and Marc Stamminger .... 39 Session III: Implementation 47 A modern implementation of the LOOP macro Robert Strandh ....................................... 49 Source-to-Source Compilation via Submodules Tero Hasu and Matthew Flatt ............................... 57 Extending Software
    [Show full text]
  • ASDF: Another System Definition Facility Manual for Version 3.3.5 This Manual Describes ASDF, a System Definition Facility for Common Lisp Programs and Libraries
    ASDF: Another System Definition Facility Manual for Version 3.3.5 This manual describes ASDF, a system definition facility for Common Lisp programs and libraries. You can find the latest version of this manual at https://common-lisp.net/project/ asdf/asdf.html. ASDF Copyright c 2001-2019 Daniel Barlow and contributors. This manual Copyright c 2001-2019 Daniel Barlow and contributors. This manual revised c 2009-2019 Robert P. Goldman and Francois-Rene Rideau. Permission is hereby granted, free of charge, to any person obtaining a copy of this soft- ware and associated documentation files (the \Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED \AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONIN- FRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. i Table of Contents 1 Introduction :::::::::::::::::::::::::::::::::::::
    [Show full text]