<?xml version="1.0" standalone="yes"?>
<Paper uid="P98-2137">
  <Title>Babel: A testbed for research in origins of language</Title>
  <Section position="4" start_page="830" end_page="833" type="metho">
    <SectionTitle>
3 Implementation
</SectionTitle>
    <Paragraph position="0"> The choice of language for the implementation was determined by the need for a standardized language suitable for rapid prototyping with good symbolic and list-processing capabilities.</Paragraph>
    <Paragraph position="1"> While the portability of Java was tempting, we eventually decided on Common LISP ((Steele, 1990)) with its more powerful symbol and list manipulation facilities.</Paragraph>
    <Paragraph position="2"> Babel was developed using Macintosh Common LISP from Digitool, and has since been ported to Windows under Allegro Common LISP by colleagues at the Vrije Universiteit Brussel. The core of the system is portable Common LISP that can run on any platform, leaving only the interface to be ported to other platforms. In future, when stable implementations of the Common LISP Interface Manager (CLIM) are widely available, it may be possible to produce a single version which will run on any system. The task of porting is, however, not too onerous, since the majority of the code is contained in the portable core. Most important of all, experimenter code - definitions of agents, game types and environments - can typically run without modification on any platform. The high-level services provided by the toolkit mean that experimenters rarely need to get involved in platform-specific interface programming.</Paragraph>
    <Section position="1" start_page="830" end_page="831" type="sub_section">
      <SectionTitle>
3.1 Class library
</SectionTitle>
      <Paragraph position="0"> Building blocks for experimental development are provided by a rich class library of  * data structures that can be used to implement agent memories and learning mechanisms null The two most important kinds of classes are the agent and the world classes. The agent classes define the capabilities of individual agents - the way they store information, the kind of utterances they can produce, and the mechanisms they use to learn or to build structure. Depending on the nature of the environment, agents may also have attributes such as position, age, energy state, social status, or any other property that might be relevant. The core class library provides a root class of agents, together with some specializations appropriate to given interaction types or learning models. Experimenters can use these classes as foundations for building agents to function in a specific experimental context.</Paragraph>
      <Paragraph position="1"> While agent classes define the capabilities and properties of individual speakers in the language community, the world classes capture the properties of the world and, more importantly, the nature of interactions between the agents. In this way, procedural definitions of the different kinds of language games can be given as part of the definition of a basic world class. The experimenter can use a given language game simply by basing their experimental world on the appropriate class.</Paragraph>
      <Paragraph position="2"> As an example, consider the following code fragment taken from the ng-world class:  This defines the basic form of the naming game - the choice of speaker and hearer, the choice of a context (including a topic), and the  construction of an utterance by the speaker, followed by recognition of the utterance by the hearer 1. The state of the world - including the 1 To make the code easier to read, function arguments are not shown object ,~ gurable- I ' ' . _ ' object ::::::::: ::::::::::/i : : \] r~il wodd reporter monitor :::::: ::::::::::::::::::: ::::::: spatial- ii object wodd-with- i i open- objects \[ \[ world</Paragraph>
      <Paragraph position="4"> agents' own memory structures - is then updated and the interaction is registered by the monitoring system (described later). Each of the methods called by this method can be individually overridden by subclasses, giving experimenters fine control over the procedures used to choose speakers or hearers, formulate utterances, store information and so forth.</Paragraph>
      <Paragraph position="5"> The class library is implemented in a modular fashion, so that experimenters can extend the functionality of the base classes by loading additional modules. The multiple-inheritance system in CLOS allows properties to be attached to experimental objects simply by making them inherit from different subclasses. For instance, any object can be given a position by making it inherit from the class spatial-object defined in the Space module, as shown in Figure 1, which shows a portion of the existing class library.</Paragraph>
      <Paragraph position="6"> As Babel evolves, useful classes and data structures defined by experimenters are absorbed into the core library set where they can in turn serve as building blocks for future experiments. null</Paragraph>
    </Section>
    <Section position="2" start_page="831" end_page="832" type="sub_section">
      <SectionTitle>
3.2 Control interface
</SectionTitle>
      <Paragraph position="0"> In addition to the core class library, Babel must provide an interface that can be used to control  the simulations. As previously noted, the core Babel functions and the code defining the interface are carefully separated, in order to facilitate porting and allow experimenters to write code that does not depend on - or require knowledge of- any specific operating system platform.</Paragraph>
      <Paragraph position="1"> The control interface in Babel is realised by a single window that allows the user to launch simulations, to set experimental parameters, to configure data reporting tools and even to write simple batch scripts to control ongoing simulations. The different functionalities are separated out into subpanes that group related controls together. Figure 2 shows a stylised view of the interface, showing each of the main control panes.</Paragraph>
      <Paragraph position="2"> Access to interface functions is available to experimenter code through a well-defined API.</Paragraph>
      <Paragraph position="3"> For instance, experimental parameters can be declared using a simple description language that specifies the type, range and default values for each parameter. Parameters declared in this way are automatically accessible for editing through the parameter editor, and can even be updated programmatically at runtime by batch scripts executed by Babel's built-in task processor. null</Paragraph>
    </Section>
    <Section position="3" start_page="832" end_page="833" type="sub_section">
      <SectionTitle>
3.3 Visualization tools
</SectionTitle>
      <Paragraph position="0"> A major challenge has been to provide a way to allow experimenters to follow the progress of their experiments and to view and extract data from the simulations. The same considerations that governed design of the interface are applicable here as well: the code needed to display simulation data (for instance by drawing a graph onscreen) is typically platformdependent, but experimenters should not need to get involved in user interface programming simply to see their results. Moreover, they should not need to 'reinvent the wheel' each time; once a particular way of visualizing data has been implemented, it should be available to all experiments that can make use of a similar representation.</Paragraph>
      <Paragraph position="1"> The approach taken in Babel has been to separate out the task of data collection from the task of data display. We call the data collectors monitors, because they monitor the simulation as it proceeds and sample data at appropriate intervals or under specific circumstances. Data display is handled by reporters, which take information from the monitors and present it to the user or export it for analysis by other programs. null Monitors and reporters stand in a many-to-many relationship to each other. The data from a given monitor type can be shown by a range of different possible reporters; in the same way, a single reporter instance can show the output from multiple monitors simultaneously. In the case of a graph display, for example, different experimental variables or measures may be drawn on the same chart, as shown in Figure 3, where change in population is graphed against communicative success over time. Similarly, a map might show the positions of individ' ual agents and the zones of occurrence of different linguistic features. The control interface allows users to instantiate and combine monitors and reporters, while a description system allows the Babel framework to ensure that users do not attempt to combine incompatible reporters and monitors at runtime, issuing a warning if the user attempts to make an inappropriate match.</Paragraph>
      <Paragraph position="2"> Communication between monitors and reporters is defined by a high-level API, allowing the monitors to remain platform-independent.</Paragraph>
      <Paragraph position="3"> Experimenters can build their own monitors based on a library of core monitor classes which define appropriate behaviors such as taking samples at specified intervals; reacting to events in the world or watching for the occurrence of particular conditions. Other classes may spec- null ify the sampling range of a given monitor - a single agent, a defined group, or the entire population - and multiple-inheritance makes it possible to flexibly combine the different types. Efforts have been made to provide powerful base classes to perform commonly-required tasks. In some cases, adding new monitoring functionality can involve as little as defining and declaring a single sampling function.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>