Oscar Nierstrasz

Alexandre Bergel

Marcus Denker

Stéphane Ducasse

Markus Gälli

Roel Wuyts

On the Revival of Dynamic Languages

The programming languages of today are stuck in a deep rut that has developed over the past 50 years. Although we are faced with new challenges posed by enormous advances in hardware and internet technology, we continue to struggle with old-fashioned languages based on rigid, static, closed-world file-based views of programming. We argue the need for a new class of dynamic languages that support a view of programming as constant evolution of living and open software models. Such languages would require features such as dynamic first-class namespaces, explicit meta-models, optional, pluggable type systems, and incremental compilation of running software systems.

Introduction

It is no exaggeration to say that mainstream programming languages of today are inherently static. That is to say, these languages tolerate change at compile time, but precious little at run-time. To state the case more strongly, most languages assume a closed world view : specifically, they assume that the world is consistent, and it will not change.

That this assumption is patently false is obvious to anyone who has experienced the development of real, large software systems. Nevertheless, it is a fact that virtually no programming language today provides specific language mechanisms to help developers cope with the fact that the systems they work on will, inevitably change [LB85].

As concrete examples, we can observe that it is hard to:

modify a running system, make changes that impact the whole system, reason about consequences of change, introduce run-time reflection on-demand, keep code, documentation and tests synchronized.

Furthermore, we can observe that increasing trends towards open, distributed systems, and pervasive computing make these issues even more critical. In this paper we take the standpoint that:

Inherently static languages will always pose an obstacle to the effective realization of real applications with essentially dynamic requirements.

We therefore conclude that research is urgently needed to develop a new class of dynamic languages, i.e., languages that support change at run-time. With this in mind, we outline five complementary research tracks that explore support for change in dynamic programming languages.

In Section 2 we revisit the most basic assumption behind most programming languages today: that programs live in files. By challenging this assumption, we argue, we can make it easier to change a running system. In Section 3 we argue that first-class namespaces are a fundamental concept missing from most programming languages, yet are needed to properly manage the scope of change.

In Section 4 we explore the theme of type systems for dynamic languages (an apparent non sequitur ), and in particular argue in favour of pluggable type systems as a means to reason about change. In Section 5 we explore the notion of reflection on demand as a mechanism to support and control both run-time introspection and behavioural reflection. In Section 6 we argue that examples integrated into the programming language and environment offer an effective way to keep code, documentation and tests in sync. We conclude in Section 7 with some remarks on ongoing and future work.

Living Objects

The static nature of most programming languages is immediately evident in the programming model these languages support. Programs lives in files. To change a system, we must edit these files, recompile them, and restart the system. Oh, and by the way, if the layout of any persistent data changes, we will have to have some ad hoc way to migrate the data. It is essentially impossible to change a running system. The system must be stopped and restarted for changes to take effect.

Surprisingly little effort has been invested over the years in developing languages that support run-time change to the persistent program state. Smalltalk [Gol84] and its descendants, like Self [US87], support a programming model in which all objects live in a persistent program image. This model of persistence, however, is rather weak, as images reside in memory, and must be explicitly saved to the file system. Although intermediate changes are logged, disasters can occur, and images may be corrupted.

Smalltalk and CLOS [Kee89,KdRB91] also support shape-changing of objects: when a class' format is changed (for example, instances are added), the memory layout of instances of this class (or its subclasses) is updated to follow suit [MLW05]. Even though this is a very rudimentary form of data migration, it is quite effective.

Considerable work was done in the mid to late 1980s on object-oriented databases and their integration with programming languages [MOP85,PS87]. This work also led to research on schema evolution [BKKK87], addressing the problem of schema changes to running systems. Considerable research has also been carried out on so-called database programming languages [AB87], but these languages have only had a limited impact on programming language design in general.

Aside from various technical difficulties involved in resolving the dichotomy between databases and programming languages [TN88], Bloom and Zdonik noted as early as 1987 that there are numerous cultural differences that make it difficult for programming language and database designers to see eye to eye [BZ87].

Let us imagine what a truly dynamic and persistent object system would be like. In a such a system, one would have the illusion of directly interacting with software artifacts. Software entities and their meta-representations would be causally connected, so that changes would have an immediate effect. Furthermore, the histories of changes would be first-class entities so that change itself can be manipulated. In a distributed object system, local changes may even have a global impact.

Technically, none of these issues are especially problematic. For example languages such as Smalltalk and CLOS already offer dynamic and living object facilities with causally connected meta-representations. Several pragmatic issues must be addressed, however, in order to arrive at an effectively usable dynamic and persistent object system. How, for example, do we control the scope of change in an open, distributed and causally connected system? How do we reason about the impact of possible changes? How do we limit and control the cost of reflection? And how can we keep various software artifacts synchronized with tests and documentation? These are issues that we will touch on in the following sections.

First-Class Namespaces

Most programming languages are static in the sense that they assume the world is consistent. They do not tolerate inconsistency. As a consequence, changes must always be made in a way that restores consistency to the world.

Reality, however, dictates that in complex systems, consistency is an illusion. For this reason, workarounds are needed to maintain this illusion, such as deprecation, or ornate naming conventions to differentiate concurrent versions of software artifacts.

There is, in fact, a well-established programming language mechanism that supports inconsistent world views, but it is in most cases unfortunately realized at best as a second class citizen. Namespaces are well-defined boundaries providing a set of definitions, i.e. names bound to values. Every programming language supports various forms of namespaces, be they as fine-grained as the context of a procedure or a block, or as coarse-grained as packages or modules. With the notable exception of Scheme [Dyb03], virtually no mainstream programming languages exist that have all their namespaces as first-class citizens i.e. that can be passed and manipulated as any other value in the language.

As it turns out, first-class namespaces can be used to great effect to form the basis of a computational model for a programming language [ALSN01]. Firstclass namespaces can be used to model objects, classes, metaobjects, software [Kee89] have traditionally supported the ability for programmers to define a set of extensions to existing classes. Extensions typically are used to add or redefine methods in situations where subclassing is not an option. (For example, by extending the class Object, one can ensure that the extension will be available to all classes, not just those that inherit from a particular subclass.)

Classboxes are namespaces that define both classes and class extensions [BDNW05]. A classbox may import a class from another classbox, and extend it locally. The local rebinding feature ensures that extensions remain local to the classbox introducing the extension, and other classboxes that (transitively) import the extended classes. A method addition or redefinition can be executed only within the classbox that defines this extension and to other classboxes that import the extended class. Within a given classbox, the world is always consistent, so collaborating classes are always well-defined. But multiple classboxes can support very different views of a universe full of inconsistencies.

The following example illustrates a method extension with local rebinding. Figure 1 depicts a classbox WidgetsClassbox that defines a class Morph, which is the root of the graphic element hierarchy in the Squeak system [IKM + 97], and a subclass Button. Morph contains a paint() method and a repaint() method that calls paint(). The classbox EnhWidgetsClassbox imports Morph and redefines the paint() method. It also imports the subclass Button. In the context of WidgetsClassbox, invoking the repaint() method on an instance of Button invokes the definition of paint() in Morph defined by WidgetsClassbox. Within EnhWidgetsClassbox, invoking repaint() triggers the enhanced implementation of paint() defined in EnhWidgetsClassbox. This is an illustration of the local rebinding facility.

Static classboxes can be used effectively to bundle a set of related class extensions that capture cross-cutting concerns, much in the way that mixin layers bundle sets of related features that can be applied in tandem [SB02]. Dynamic classboxes furthermore offer the possibility to dynamically apply (or disable) a set of related class extensions.

Imagine the situation in which a running system has to be upgraded without being interrupted and while preserving behavior of its clients. Dynamic classboxes offer a disciplined way out of this predicament: A patch consisting of classboxes can be dynamically applied to a running system without it being halted. Modifications, consisting of method additions and redefinitions, and encapsulated as classboxes, are locally visible to these classboxes and to new clients that rely on them. Former clients are guaranteed not to be impacted whereas new clients can rely on the new system.

Dynamic, first-class namespaces would appear to offer a number of further interesting and useful capabilities. First of all, a namespace can be used to restrict the scope of certain changes. Within a single running system, namespaces could help to indicate which clients may see a given set of changes. More interestingly, dynamic namespaces could broaden their scope at run-time, much in the way that dynamic classboxes can be applied or disabled. With dynamic namespaces, one could gradually introduce changes to a running system, extending the scope of change till it applies to all concerned clients. At any one point in time, however, there would be no need for different parts of the universe of namespaces to be mutually consistent.

Pluggable Types

Generally speaking, static languages have obligatory and static type systems, that is, they attempt to use static type information to guarantee that no dynamic type errors may occur, and refuse any program that cannot be type-checked. The way this is achieved always entails a trade-off in the sense that any static type system will prevent you from writing certain "correct" programs simply because it cannot prove that no type error exists. The art of designing a usable type system is to make sure that no "interesting" program is forbidden (or that interesting programs can always be rewritten in an easy way to make them acceptable).

Static type systems, however, are the enemy of change. Reflective code, especially in statically typed object-oriented languages, can be especially cumbersome and verbose, since workarounds are needed for any operations that will not be known till run-time. Even languages that sport state-of-the-art type systems, such as (different variants of) ML or Haskell, struggle with overloading, polymorphism and reflection in the context of type-safety [Mac93]. For example, MetaOCaml, an extension of OCaml, provides a type-safe quasi-quoting mechanism that can be used to generate type-safe code at runtime [Tah03], but has no support for reflection. Extensions of polymorphism (such as first-class polymorphism in ML [Rus00] or in Haskell [Jon97]) exist but do not always allow for separate compilation (unless the type-preservation rules are relaxed) [KS04].

Furthermore, static type systems can produce a false sense of security. Runtime type-checks (i.e. "downcasts") in Java, for example, can hide a host of type-errors.

The issue of static typing is a divisive one, often splitting programmers into two camps: those who believe that dynamic languages are evil because they are "untyped" (not true -they are dynamically typed), and those who believe that static languages are evil because they prevent you from writing interesting programs without catching any interesting errors.

Instead of having static types hinder change, we would like to use them to support change. In particular, we want more, rather than less, expressiveness, fewer constraints, and more kinds of checks. We believe there exists a comfortable middle ground. At the center of this middle ground is a simple principle:

A type system should never be used to affect the operational semantics of a programming language.

Once this principle is out of the way, we can entertain various notions of optional type systems, such as that of the Strongtalk language [BG93], [Str], which introduce static typechecking without compromising flexibility. We can even go one step further and explore the notion of multiple, pluggable type systems proposed by Gilad Bracha It is clearly unrealistic to expect that static programming languages will or even could be developed to take advantage of all these new developments. A much more reasonable, and interesting alternative, is to envisage a dynamic programming language into which various non-standard type systems could be plugged. For example, a heuristics-based type inferencer can enable program understanding of dynamically typed programs [Wuy01]. Or a pluggable typesystem dealing with worst-case execution times for methods or components can check runtime properties for programs intended to be run in hard real-time systems [HBW02,WDN05].

Reflection On-demand

Reflection enables the changing of systems without the need to rebuild or even restart them. This is an important basis for building the dynamic sytems of the future: Mobile, Ubiquitous, Always-On.

To change a running system means that we must reify behavioural aspects, interact with them to indicate the desired changes, and reflect changes to obtain their effects in the running system.

Reflection is a well-understood research topic with a long tradition of support in various programming languages and within various paradigms [FJ89,KdRB91] but with limited support in most static languages [Chi95]. Nevertheless, totally reflective systems suffer from many disadvantages:

-Security: If a language is reflective, the client that uses reflection can do anything. -Stability: The effects of reflection are global: In a system with multiple clients, one client using reflection on a system service impacts all other clients. -Performance: Full reflection is costly: To enable it, all behavioral aspects need to be reified in such a way that clients have the opportunity to change them.

These disadvantages all stem from the absence of a scope concept in the context of reflection. Scope is needed to:

-Separate the meta-from the base-layer.

-Define where and when reflection should be available.

-Limit the reflective interface to certain clients.

-Constrain the effects of reflection to certain clients.

Ideally, we would like to have scoped reflection on demand, that is to control when and where and for whom reflective services should be available. Such a reflective language would first of all be more secure, as untrusted clients could be given restricted reflective access. It would also be more stable, since changes made using reflection could be limited to the client that made them. Last but not least it could be made faster, since the reification would only be done for those clients that need it. Two recent research activities give us some hints how this may be achieved.

Mirrors in Self and Strongtalk provide structural reflection on demand [BU04]. In order to reflect on a particular object, a mirror object will be created at run-time. The mirror reifies the reflective services for the object under study. Thus mirrors provide a dedicated interface for the reflective services: meta-and base-layer are separated, the particular interface handed to a client can be defined by the object and it can differ between multiple clients. So mirrors provide some of the properties we need. But they have shortcomings, as the support they offer for full behavioral reflection is limited. They do not support fine-grain reflection below the method level, nor mirror-based intercession. And mirrors do not provide a way to scope the effects of reflective change.

Reflex provides fine-grained behavioural reflection for Java entities [TBN01] [TNCC03]. The entities to be reified can be selected by time (enabled/disabled by the program), or space. For spatial selection we can specify the entity (e.g., a class or an object), the operation (e.g. message send or a field access) or combine these to select a specific operation (e.g. a certain message sent to a certain object).

Reflex uses bytecode transformations for reifying Java execution entities like instance variable access, method calls, exceptions and typecasts. Java as a static system does not allow bytecode to be modified at runtime, it needs to be done statically at load-time: Only those entities selected at load time can be reflective at runtime.

Geppetto is an implementation of Reflex for Squeak that provides the same fine-grained behavioural reflection for Squeak language entities. It supports reification of variables (instance variables and temps), message sends and message receive. Like Reflex, Geppetto uses bytecode transformation, but as Squeak is a dynamic system, these modifications are done at runtime. With Geppetto we want to explore the ideas of Reflex in a dynamic language, especially how to combine Geppetto with the idea of dynamic classboxes as outlined in Section 3.

Classboxes can be used to package reflective aspects of objects. When reflection is needed, the corresponding classbox can be dynamically loaded. Only clients that need reflection will see those services. Classboxes are used to extend the system without making the effect of this extension global. In the same way, classboxes could scope the effect of reflection.

Example Objects

Object-oriented code can be hard to understand, extend and adapt. One source of this difficulty is the disconnect between run-time architecture and source code: whereas at run-time we have a collection of interacting objects, the source code merely presents us with a class hierarchy. As a consequence it can be hard to identify the run-time structures in the code [Nie04]. Furthermore, architectural constraints and contracts tend to be implicit in the code, so it may be hard to tell whether given changes are consistent with the existing contracts in place.

Examples are a well-established medium for communicating how things works in virtually all domains. Dictionaries like the Oxford Dictionary of Current English [Soa01] provide the reader with lots of concrete examples of current usage of a given word. Curiously the use of examples is not widespread in running software systems, though they would offer many benefits. In particular, examples are run-time entities that can be manipulated, examples document usage scenarios, examples can form the basis of executable tests, and finally examples (that fulfil their tests) are guaranteed to be in sync with the running system.

A particularly useful notion is that of one-method commands. These are argument-free methods that serve as examples for methods and objects, focus on some given method under test, and return an example object. One-method commands may be composed to form suites of tests.

As an example, consider the following Smalltalk method (defined on the class side of the Account class: Taivalsaari [Tai97] gives an overview about the philosophical differences between prototypical and class-based languages. We believe that a class-based language with a built-in facility for composing and fetching examples can help to bridge the gap between these two paradigms.

[IKM + 97], attempted to bring more concreteness into the Smalltalk layer of Squeak by introducing the method initializedInstance. The idea there is to be able to recursively (re-)create exactly one prototypical instance for each class, resembling our idea of example objects. In Squeak 3.7 there are still only 13 implementations of initializedInstance so one could say that this concept of providing a single best example object for a given class did not take off.

Deursen et al.

[Deu01] discuss several benefits and drawbacks of unit tests for program comprehension. They do not discuss how one can navigate between tests and programs but it is clear that they should be together as close as possible.

In [DMBK01] Deursen et al. discuss several bad smells of test code. They describe the bad smell of eager tests which which test several methods of an object at the same time, and are hard to comprehend. They therefore suggest to apply the extract method refactoring to separate tests into what we call onemethod commands which exemplify exactly only one method. Other bad smells include "general fixture" and "test code duplication", which we suggest to clean using de-and recomposition of the test code into one-method commands.

Edwards [Edw04] coined the term "example centric programming". Based on user provided examples (which we again call one-method commands) the developer can browse abstract methods side by side with concrete calls of these methods triggered by the one-method commands. Edwards does not provide means of composing and linking these one-method commands as we do.

Conclusions

In many ways, we are still in the dark ages of programming language design. Consider, for example, the great innovations in programming languages over the past fifty years. To a large extent, most of these innovations were achieved in the 1950s and 1960s. It is harder and harder to identify significant contributions over the past 20 years. It is also hard to identify truly radical language designs in recent years.

One may interpret this as a sign that the state-of-the-art in programming language design is stabilizing, or even that research in programming languages is essentially dead. Another interpretation, however, is that language design is in a rut due to our fixation with a certain style of language design. We have argued in this paper that static languages have hampered innovation, and furthermore that the death of file-based languages is the first step towards a new generation of dynamic languages.

We need to come to terms with persistency, inconsistency and change in programming languages. This means that dynamic programming languages should support the notion of software as living, changing systems, they should provide support multiple and possibly inconsistent viewpoints of these systems. Static type systems still have their place, but they should serve rather than hinder expressiveness. To support dynamic change, behavioural reflection is needed, but it should be provided only on-demand, when and where it is needed. Finally, examples integrated into the language run-time can help one to document and test the software in a synchronized fashion.

Fig. 1 .

 1 Fig. 1. Implicitly rebinding classes within classboxes.

  [Bra04]. Considerable research has been carried out in recent years on non-standard type systems such as (for example) alias types [SWM00], confined types [GPV01], [ZPV03], flow-sensitive type qualifiers [Fos02,FTA02], proxy inference [PSH04], scoped types [ZNV04], and demand-driven type inference with subgoal pruning [SS04].

  This code is evaluated by sending the message Account deposit100On123. The method makes use of another one-method command of the Account class, called accountNumber123, which presumably returns an example Account.deposit-100On123 then focuses on the deposit: method, thus providing an example usage of this method. (self test: aBlock performs aBlock, while documenting what is actually under test). A test is performed, (self assert: ...) and the modified example object is returned.Here we can see how tests are composed from one-method commands, and explicitly link tests with methods under test, tests with classes under test, and tests with other tests.

	Account class >> deposit100On123
	|anAccount|
	anAccount:= Account accountNumber123.
	self test: [ anAccount deposit: 100 ].
	self assert: [ anAccount balance==100 ].
	^anAccount

Acknowledgments

We gratefully acknowledge the financial support of the Swiss National Science Foundation for the project "A Unified Approach to Composition and Extensibility" (SNF Project No. 200020-105091/1, Oct. 2004 -Sept. 2006).


Éric Tanter

Kris Gybels

Marcus Denker

Alexandre Bergel

Context-Aware Aspects

Context-aware applications behave differently depending on the context in which they are running. Since context-specific behavior tends to crosscut base programs, it can advantageously be implemented as aspects. This leads to the notion of context-aware aspects, i.e., aspects whose behavior depends on context. This paper analyzes the issue of appropriate support from the aspect language to both restrict the scope of aspects according to the context and allow aspect definitions to access information associated to the context. We propose an open framework for context-aware aspects that allows for the definition of first-class contexts and supports the definition of context awareness constructs for aspects, including the ability to refer to past contexts, and to provide domainand application-specific constructs.

Introduction

Context awareness [START_REF] Baldauf | A survey on context-aware systems[END_REF][START_REF] Dey | Towards a better understanding of context and context-awareness[END_REF], i.e., the ability of a program to behave differently depending on the context in which it is running, has been the subject of a number of research proposals, mainly in the field of ubiquitous computing [START_REF] Weiser | Some computer science issues in ubiquitous computing[END_REF], selfadaptive [START_REF] Mckinley | Composing adaptive software[END_REF] and autonomic systems [START_REF] Kephart | A vision of autonomic computing[END_REF]. In these areas, a major issue is that of perceiving the context surrounding an application (e.g., hardware or network state, user characteristics, location, etc.). Context awareness toolkits have been proposed to address this issue of context perception (e.g., WildCAT [START_REF] David | WildCAT: a generic framework for context-aware applications[END_REF]). In the area of programming languages, it has been recognized that beyond perceiving context, actually composing context-specific behavior with the application logic results in context-related conditionals (if statements) being spread out all over the program [START_REF] Costanza | Language constructs for context-oriented programming[END_REF]. Context awareness is therefore a crosscutting concern, which is a good candidate for being treated as an aspect. Doing so implies that aspects should be context aware; a context-aware aspect is an aspect whose behavior depends on the context. The "behavior" of an aspect includes the crosscut specification of the aspect as well as its associated action (a.k.a., advice). This paper explores aspect language constructs to scope aspects to certain contexts, and to allow aspect advices to be parameterized by information associated to contexts.

Current approaches to AOP support several means to restrict an aspect based on some kind of context: e.g., based on certain data associated with the join points it intercepts (e.g., the value of a certain parameter), or based on their relationship to past join points (e.g., current control flow or past execution history [START_REF] Douence | A pointcut language for control-flow[END_REF][START_REF] Douence | Trace-based aspects[END_REF]). However the notion of context used in context-aware applications is more general and AOP languages lack an explicit notion of context. Interestingly, context can also be related to particular application domains, such as a promotional context in an online shopping application. Also, current AOP languages are limited with respect to the kind of context dependencies that can be expressed: most do not consider past contexts. While there are approaches that keep track of past events and state of the program, the problem of contextdependent aspects has not been fully considered in these cases. Expressing context dependencies in aspects would imply relying on design patterns and idioms. Conversely, we believe context awareness is central enough to many systems to deserve dedicated language constructs. We therefore aim at studying appropriate aspect language constructs for context-aware aspects, including general-purpose and domain-/application-specific constructs. The contributions of this paper are: (a) a general analysis of the issues associated with context-aware aspects; (b) the description and implementation of an open framework for context-aware aspects that meets all identified requirements. This framework, implemented on the Reflex AOP kernel [START_REF] Tanter | A versatile kernel for multi-language AOP[END_REF], includes a context definition framework and a framework for defining context-related aspect language constructs. Section 2 introduces a running example on which we base our analysis of context-aware aspects, and distills a number of requirements for defining contexts and providing aspect language features for context awareness. We describe our framework for context-aware aspects in Section 3, and discuss related work in Section 4. Section 5 presents our conclusions.

Motivation and Requirements

Running Example

The running example is an online shop application. When a customer logs in, a shopping cart is created that can be filled with various items. When the purchase has to be ordered, the bill is calculated. Within this application, we consider a simple discounting aspect. The following is a skeleton implementation of a Discount aspect in AspectJ which is not at all dependent on current promotions but simply applies a constant discount of 10%: aspect Discount { double rate = 0.10; pointcut amount() : execution(double ShoppingCart.getAmount()); double around() : amount() { return proceed() * (1 -rate); } } There are several ways in which the discounting aspect can be related to a promotion. For instance, the discount can be based on (D1) the current promotion that is active either when the customer checks out, or (D2) when the customer logs in and the shopping cart is created, or (D3) when the item is added to the shopping cart.

The fact that a promotion is active or not can be described as the application being in a promotional context 1 . Whether the application is currently in a promotional context can be defined in several ways, e.g.: (P1) it can be time-based, based on whether the current time falls in any of the given intervals during which promotions are given; or (P2) the shop application can automatically give promotions when the shop's stock area is getting overloaded and needs to be cleared; or (P3) the shop's sales department may want to advertise a new web-services-based interface to the application, the application would then be in a promotional context if shopping is done through web-service requests.

Finally, the discount rate may (R1) simply be constant as in the example above, but (R2) may also vary depending on the actual promotion. In other words, instead of being in a promotional context or not, the application may also offer promotions with different discount rates.

Example Design Analysis

Context Definition. The definition of when to apply the discount and the definition of the promotional context should be separate. The reason for this is simply good separation of concerns. As discussed above, there are several variations possible both for the context definition itself and the discount aspect that depends on it. In an evolution scenario, the shopping company may either change when the discounts are applied without changing the definition of the promotion, or vice-versa. Also, the definition of the promotion may apply to other aspects besides the discount aspect, such as an advertising aspect which adds customized banners for each customer to the shop's web pages. Hence, separating aspects that are dependent on some contexts from the definition of contexts themselves serves well-established engineering principles. In addition to this logical separation between aspects and contexts, contexts should be:

-stateful: a context may have state associated to it. Support should be provided for both state internal to the context's implementation (e.g., the time slots when a promotion is active) and publicly accessible state, such as for variation R2 in the example when the rate of discount depends on the promotion. In that case, the discount aspect would define when to actually apply a discount, and would get the specific discount rate from the promotion which defines when this rate is determined. Of course, the state of a context may change dynamically. -composable: a context may be defined from more primitive contexts. For instance, one can define the stock overload context independently of the promotional context; this way, other contexts can be based on stock overload, and the promotional context can combine the time-based definition with the stock overload context. -parameterized: contexts can be defined generically, and parameterized by aspects that are restricted to it; for instance, the stock overload context can be parameterized by the actual threshold that leads to the context being active.

Finally, a context can be related to control flow properties (e.g., the web-servicesbased promotional context), in the broad sense of the term (not only as AspectJ's cflow, but also as past event sequences [START_REF] Douence | A pointcut language for control-flow[END_REF][START_REF] Douence | Trace-based aspects[END_REF]).

Contextual Restriction.

Restricting an aspect to a particular context requires the possibility to refer to a context definition in a pointcut definition. For instance:

pointcut amount(): execution(double Item.getPrice()) && inContext(PromotionCtx);

Furthermore, since the discount rate may vary on the actual promotion, the associated advice may need to access some external state of the considered context: The code above assumes that using rate in PromotionCtx(rate) relies on the fact that a promotional context exposes a rate property (e.g., via a getRate accessor). In addition to context state exposure, it has to be possible to parameterize a context when expressing a dependency on it: e.g., Discount The above inContext pointcut restrictor is semantically equivalent to an if restrictor in AspectJ: restricting an aspect based on whether a certain (context) condition is currently verified. However, it should also be possible to restrict an aspect based on whether the application was in a certain context previously.

There is one generally-useful past context dependency: the context during which an object is created (a.k.a., its creation context), e.g., the context during which a shopping cart is created. Using an appropriate language construct createdInCtx, the following implies that Discount applies for any shopping cart that was created when PromotionCtx was active, without considering whether the promotion is still active when the customer checks out:

pointcut amount(): execution(double ShoppingCart.getAmount()) && createdInCtx(PromotionCtx);
Finally, it should also be possible to define domain-or application-specific context restrictors; e.g., to refer to the context during which an item was added to the shopping cart (assuming an appropriate application-specific putInCartInCtx pointcut restrictor):

pointcut amount(): execution(double Item.getPrice()) && putInCartInCtx(PromotionCtx);

The combination of past context dependencies and stateful contexts implies the need for keeping track of past contexts and their associated state: on the one hand, contexts can be stateful and this state can vary over time; on the other hand, the actual application of the discount can depend on a past promotion context. We refer to this process of keeping track of past contexts and their states as context snapshotting, and to the frozen state of a context at a given point in time as a context snapshot. A global context snapshot is therefore a snapshot of all defined contexts at a given point in time.

For implementation considerations (basically, memory usage), it is obviously impossible to keep the global context snapshots at each and every point in time. It is thus important to be able to snapshot contexts only when really needed. For instance, snapshotting the creation context of an object is needed only if this object is affected by an aspect that is subject to a creation-context dependency. It is also desirable that snapshots be associated to the object they relate to in order to avoid maintaining huge global hashtables, as these would surely become bottlenecks.

Finally, the possibility of defining domain-and application-specific context restrictors implies that the corresponding snapshotting (when to snapshot, where to store the snapshots) be user-definable.

Summary

The above design analysis of the running example points out a number of requirements for appropriately modeling contexts on the one hand, and for providing aspect language features for context awareness on the other hand, which can be summarized as follows:

-Contexts and context-aware aspects must be separate entities.

-Contexts should possibly be parameterized, stateful, and composable.

-Context state should possibly be bound to pointcut variables.

-It should be possible to express dependencies on past contexts.

-New context-related constructs (possibly domain-specific) should be definable. -Non-naive implementation of context snapshotting must be supported.

An Open Framework for Context-Aware Aspects

We now present an open framework for context-aware aspects that meets the above requirements. The framework is an extension of Reflex3 , a versatile kernel for multi-language AOP in Java [START_REF] Tanter | A versatile kernel for multi-language AOP[END_REF]. Reflex supports AOP-like dynamic crosscutting, and the framework supports plugins that compile languages such as AspectJ to standard Java programs using Reflex [START_REF] Rodríguez | Supporting dynamic crosscutting with partial behavioral reflection: A case study[END_REF]. We do not discuss concrete syntax extensions for supporting context-dependent restrictions here; we focus on the extension of the framework.

Why a Framework Approach?

A major requirement we have identified is to be able to add new constructs to an aspect language, along with their corresponding semantics. Such an extensible aspect language can be achieved using one of the following alternatives:

modifying the interpreter of the aspect language; -using a reflective aspect language, i.e., an aspect language that has an account of itself embedded within it; -using an extensible compiler for that aspect language.

To the best of our knowledge, there have been no real reflective aspect language proposed to date. As regards extensible compilers, we could implement our proposal using abc, the AspectBench compiler, which is precisely an extensible AspectJ compiler [START_REF] Avgustinov | abc: an extensible AspectJ compiler[END_REF]. Our framework-based approach has an advantage in terms of simplicity of the implementation and hence rapidity in prototyping new language features. There is no doubt though that abc would lead to a more efficient implementation as a number of static optimizations could be done: but this is not the purpose of this paper; optimized implementations of context-aware aspects is deliberately left for future research. It has to be noted that working at the framework level is conceptually equivalent to working at the level of the interpreter of the aspect language.

The following section gives a brief overview of Reflex, to give the necessary background for understanding the description of the extended framework that follows. The presentation of the extension for context-dependence is divided in four parts, following the organization depicted in Fig. 1: we first present the context definition framework, followed by the context restriction framework, and we illustrate the use of both with user-defined extensions.

Background on Reflex

Reflex is an open reflective extension of Java that supports both structural and behavioral modifications of programs. The core concept of Reflex is the link; we hereby only need to explain behavioral links: a behavioral link invokes messages on a metaobject at occurrences of operations specified by a hookset [START_REF] Tanter | A versatile kernel for multi-language AOP[END_REF][START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF]. The selection conditions of a hookset are split into a selection on the type of operation, on the classes in which they occur and on the operations themselves. In the example, the hookset intercepts occurrences of MsgReceive operations, which corresponds to the execution join point type in AspectJ. The NameCS class selector specifies that the class should be WebServiceRequest -or one of its subclasses, as specified by the true parameter, which corresponds to the + in AspectJ. The operation selector AnyOS simply specifies no further conditions on operation occurrences (similar to the use of "*" wildcards).

The exact message sent to the metaobject, as well as how and even if it is really invoked, can be further controlled by setting attributes of the link. Following is an example link definition (amountHS is the hookset corresponding to the amount pointcut):

BLink discount = Links.createBLink(amountHS, new Discount()); discount.setCall(Discount.class, "amount"); discount.setControl(Control.BEFORE); // before advice kind discount.setScope(Scope.GLOBAL); // singleton metaobject discount.addActivation(new Condition()); // adding a dynamic condition

The discounting aspect's advice is here modeled as a metaobject, instance of the plain Java class Discount with an amount method, that simply applies the discount. The setCall invocation specifies that the link should send the amount message, with no arguments. The next two invocations illustrate setting the control and scope attributes, which correspond to advice kind and aspect instantiation, respectively.

Important for this paper is that the final invocation specifies an activation condition. The activation condition is implemented as an object implementing the interface Active which simply specifies a boolean method evaluate which takes exactly one parameter, the object in which the operation occurred. At runtime, interception occurs only if the activation condition evaluates to true. Hence, an activation condition basically plays the role of pointcut residues in AspectJ.

The messages invoked by links on metaobjects can take parameters. One can specify on a link what arguments to pass by giving a number of Parameter objects. There are several possible objects one can pass, but a number of predefined parameters are available, such as Parameter.THIS and Parameter.RESULT which represent the currently-executing object and the result of the intercepted operation, respectively.

Context Definition Framework

A simple usage of Reflex for defining context can represent contexts as objects with a boolean method active. Since Reflex supports first-class pointcuts via hooksets and activation conditions, AOP features can be used for defining when a context is active. For instance, consider the definition of the web-service-based promotion context: The CFlow object exposes the control flow of the hookset given to the CFlowFactory The active method is defined in terms of the in message of this object, which returns true when the application is in the control flow of an operation that matches the hookset.

We also need to define how contexts are snapshot: at any point in time, we may need to snapshot a context, in order to access its state later. One way to design this is to make contexts cloneable, and clone all active contexts when doing a snapshot. But this introduces the issue of managing the depth of context cloning; also, some state of the context is related to its initial parameterization and hence does not need to be cloned.

We rather opted for a design that forces context implementors to explicitly consider the issue of context snapshots. The above implementation ensures that the promotion context can be snapshot correctly: a PromotionState object holds the value of the discount rate at the time the snapshot was requested -although the current discount rate may be different.

The framework also includes a global context dictionary, Contexts, which keeps track of all contexts that have been defined (via define(c), as done in the constructor of the abstract Context class) and which can be asked for a global snapshot of all currently active contexts (via get). A global context snapshot is represented as a Snapshot object, which is simply a map of Context-to-ContextState objects. Recall that each context state object contains a reference to the context object that generated it.

Context Restriction Framework

The context-dependent pointcut restrictors of Section 2.2 can be defined in the Reflex framework as activation conditions on links. Two abstract classes implementing the Active interface are defined as a framework for defining contextdependent activation conditions (Fig. 1). We show here how these are specialized for defining the currentlyInCtx restrictor. The createdInCtx and putInCartInCtx restrictors are presented in the next section. First of all, the CtxActive abstract class is defined as follows: In the constructor, the context on which the activation condition relies is stored in an instance variable. The activation condition evaluates to true if the associated context is active, or more precisely, is determined to (having) be(en) active by getCtxState. This method is abstract because some context-related conditions rely on a past context state, and should therefore be able to retrieve the appropriate context snapshot associated to the currently-executed object. This is explained in more details in the rest of this section.

The CurrentlyInCtx condition restricts a link to be active only when the condition's context is active. When queried, such an activation condition extracts the relevant snapshot from the currently-executing object passed as parameter (getSnapshot), and queries the snapshot for the state associated to its context.

There are basically two design options for storing the snapshots of contexts associated with specific objects. One is to rely on a global map of objects to contexts, another is to associate snapshots as extra hidden state in the objects themselves. We opted for the latter option, to avoid a central bottleneck and also since it ensures that the snapshots are removed from memory when the objects they are associated with are garbage collected. We rely on a general object-level annotation framework based on Reflex and its abilities to perform structural changes to classes (not presented here due to space restrictions). To control snapshots, SnapshotCtxActive implements a number of utility methods to interact with this framework, such as:

void annotate(ClassSelector cs) -enable annotations in classes matched by cs.

void snapshot(Hookset hs, Parameter p) -upon operation occurrences matched by hs, store snapshot context in the parameter p of the occurrence. -Snapshot getSnapshot(Object o) -return snapshot stored in o.

User-Defined Extensions

Having presented the whole framework for context-aware aspects, we illustrate its use by showing how new pointcut restrictors are defined. Two examples are given, one for restricting based on the creation context of a particular object, the other is an application-specific one. Since both refer to past contexts, they are extensions of SnapshotCtxActive.

Creation Context. The creationCtx pointcut restrictor is implemented as the CreatedInCtx class for activation conditions. It can be added as an activation condition to the discount link as follows:

CtxActive createdInPromo = new CreatedInCtx(new PromotionCtx(), discount); discount.addActivation(createdInPromo);

Note that the discount link itself is passed as a parameter to the activation condition. This is done so that the link can be introspected, in order to determine which instantiations of which classes the discount aspect actually depends on; the snapshotting of the contexts can thus be limited to instantiations of just those classes. In the constructor of CreationCtx below, the class selector of the link is and used to define snapshotting on just the classes described by the selector: The class selector cs is retrieved from the link using its getClassSelector method and is used in a call to snapshot. The hookset passed to snapshot describes all invocations of constructors in classes matching the class selector. Context snapshots are consequently stored in the newly-created object (Parameter.THIS).

In Cart Context. We now illustrate how an application-specific pointcut restrictor is defined, by considering the case of the PutInCartInCtx discussed in Section 2.2. In Reflex, the corresponding activation condition would be used as follows:

CtxActive putInCartInPromo = new PutInCartInCtx(new PromotionCtx()); discount.addActivation(putInCartInPromo);

The implementation of PutInCartInCtx states that Item objects should be annotated, and that context snapshot annotation occurs upon execution of addItem on a shopping cart; The object to be annotated, the item, is the first parameter (NthParameter(1)) of the call: is based on the mechanism provided by Reflex to customize the invocation of a metaobject (recall Section 3.2). The above example would be implemented as follows:

Context promotionCtx = new PromotionCtx(); CtxActive inPromo = new CreatedInCtx(promotionCtx, discount); discount.addActivation(inPromo); discount.setCall(Discount.class, "amount", inPromo.getCtxParam("rate"));

The important line is the last one: the specification of the call to amount (the advice) is changed to include one parameter, bound to the value of the rate state property of the promotional context. getCtxParam is a method of CtxActive4 that returns a custom Parameter object. To evaluate the value of this parameter at runtime, the activation condition inPromo is queried for the context state corresponding to the currently-executing object, retrieves that context state in the adequate snapshot (in this case, the creation context snapshot), and invokes the getRate method on it.

More Extensions

In the current work we have only considered context dependencies related to the currently-executing object of an operation occurrence. The two constructs we have presented for past context dependencies always look for context snapshots in the this: if the currently-executing object has been created in a given context, or put in the shopping cart in a given context, etc. It would be equally interesting to be able to relate to past contexts associated with other objects, such as the target or any of the arguments of an operation occurrence, or even any object that is accessible from the join point. We could define additional activation conditions that are defined to check for context-dependency related to other objects than the this. Another option fitting in the Reflex framework would be to parameterize context-related activation conditions with a Parameter object to describe on which parameter of the operation occurrence the activation condition acts. In that case, the constructors of the activation condition will also have to perform a slightly more complex introspection of the link's hookset to determine on which classes snapshotting should be performed. We expect to research such extensions in future work.

Related Work

We now review related work in the area of contexts, and existing proposals to restrict the scope of aspects. The term context can be found in different meanings and definitions in many computer science disciplines, such as human-computer interaction and ubiquitous computing. We hereby only focus on the use of context as an element of a programming language.

Context-Oriented Programming. ContextL [START_REF] Costanza | Language constructs for context-oriented programming[END_REF] is a recent CLOS-based approach for Context-Oriented Programming (COP). While we have presented an extension of an aspect-oriented approach, COP is exploring a paradigmatically new approach. A major difference between both approaches is in the way time is dealt with. In the AOP approach an aspect can be made dependent on whether the application was previously in a certain context, while in COP this is reversed: when the application enters a state that qualifies as being in a certain context, code is redefined so that its future execution takes the "aspect" into account. As the two approaches are paradigmatically different, it is difficult to compare them, though one could state that our proposal has a more declarative nature as the conditions under which the application is in a certain context are encapsulated in context definitions, while in ContextL context has to be more explicitly activated.

Context in other AOP Approaches.

The term context has also been used in other AOP approaches: the term is meant to denote information associated with joinpoints, but is typically also limited to information directly associated with joinpoints such as arguments of messages, or the control flow "context" of the joinpoint. We have considered the term context in the more general meaning of all the information about the state of a program when a joinpoint occurs, and have also considered the use of context about past joinpoints, while limiting the amount of information that is kept about past contexts.

Technically, this can be realized in any AOP approach like it is done in the implementation of our framework, i.e., by defining additional pointcuts and advices to capture contexts when needed. However, in our framework these additional pointcuts (or hooksets) are automatically installed, they do not have to be written by hand (Sect. 3.5). Also, in our approach context dependencies can be checked in the pointcut, not in the advice, resulting in clearer code.

In AspectJ for example, one can implement a context definition such as the promotion context as an object and the discounting as an aspect. The discounting aspect has one advice for applying the discount, and a second one for snapshotting the promotion context when, e.g., a shopping cart is created. But any aspect depending on the promotion context needs an advice to snapshot the context as needed. An attempt to define a more general promotion context snapshotting aspect runs into the problem that it is not possible to analyze the pointcuts of the aspects that depend on the context. So the reusable definition of the snapshotting necessarily has to snapshot the context at all instance creations, leading to unnecessary overhead. In AspectJ, there is also the problem of defining context activation predicates as reusable named pointcuts because such pointcuts can neither be made dependent on a context using polymorphism (pointcut invocations are not late bound), nor can named pointcuts be parameterized with a context object (named pointcuts only have output arguments). In more advanced aspect languages it may be possible to achieve an implementation of contextaware aspects that is both more reusable and efficient than an implementation in AspectJ, for instance with CaesarJ [START_REF] Aracic | An overview of CaesarJ[END_REF]. Although a detailed comparison with the Reflex-based implementation presented here remains to be done, the interest of Reflex (apart that it is sufficiently expressive and open to cover our needs) is that it explicitly addresses the issue of extensible aspect languages on top of the framework, through the on-going integration of Reflex and MetaBorg [START_REF] Bravenboer | Concrete syntax for objects[END_REF]. Therefore the context-aware syntactic extensions formulated at the beginning of the paper can be provided over Reflex.

A number of proposals make it possible for aspects to depend on the past execution history, and to refer to state associated to past events [START_REF] Allan | Adding trace matching with free variables to AspectJ[END_REF][START_REF] Cottenier | Contextual pointcut expressions for dynamic service customization[END_REF][START_REF] Douence | Composition, reuse and interaction analysis of stateful aspects[END_REF][START_REF] Douence | A formal definition of crosscuts[END_REF]. These approaches make it possible to refer to past context, but only consider context in the sense of join point-related information, as above. Conversely, in this work we consider a more general notion of context, whose state can actually be computed arbitrarily. In other words, we can bind any context state to pointcut variables, which can then be used to parameterize advices. Although the extensions considered in this paper are not impossible to realize in, e.g., EAOP, they have not been explicitly considered. Allowing aspects to refer to the full state of the program was also introduced in the user-extensible logic-based language CARMA using object reifying predicates [START_REF] Gybels | Arranging language features for more robust pattern-based crosscuts[END_REF]. This work could also be extended to solve context-dependency problems.

The recent introduction of a let construct [START_REF] Avgustinov | Efficient trace monitoring[END_REF] in the AspectBench Compiler [START_REF] Avgustinov | abc: an extensible AspectJ compiler[END_REF] makes it possible to bind any context information to pointcut variables, as in our approach. This construct therefore solves the issue of being able to expose (external) context information in pointcuts. However, being an extension of AspectJ, an abc solution would not do any better with respect to the other issues discussed previously with AspectJ: lack of first-class pointcuts, no latebound pointcut invocations, no input pointcut arguments, etc.

Conclusion

Handling context-related behavior as aspects allows for better modularization. In this paper, we have analyzed what it means for aspects to be context aware and explored the associated aspect language features. We have exposed an open framework for context-aware aspects, i.e., aspects whose behavior is context dependent. This includes the possibility to restrict aspects to certain contexts, both currently and in the past, as well as to parameterize aspect advices with context-related information. Furthermore, our approach makes it possible to define application-or domain-specific context-related restrictors for aspects.

Future work includes experimenting with context-aware aspects in more elaborate scenarios, and implementing a set of contexts in our framework based on a context-awareness toolkit such as WildCAT [START_REF] David | WildCAT: a generic framework for context-aware applications[END_REF]. This should provide feedback on our aspect language feature approach to handling context awareness.

  class PromotionCtx { // cflow(execution(* WebServiceRequest+.*(..))) CFlow cf = CFlowFactory.get(new Hookset(MsgReceive.class, new NameCS("WebServiceRequest", true), new AnyOS())); boolean active() { return cf.in(); } }

class

  CreatedInCtx extends SnapshotCtxActive { CreatedInCtx(Context c, BLink l){ super(c); ClassSelector cs = l.getClassSelector(); annotate(cs); snapshot(new Hookset(Creation.class, cs, new AnyOS()), Parameter.THIS); } }

  could depend on both a time-based PromotionCtx, and the StockOverloadCtx, parameterized by a threshold of, say, 80% 2 .

	pointcut amount(double rate): execution(double ShoppingCart.getAmount())
	&& inContext(PromotionCtx(rate)) && inContext(StockOverloadCtx[.80]);

  Context definitions should extend the abstract class Context, which instead of having a boolean active method requires overriding a getState method. This method should return null if the context is not active, otherwise it should return a snapshot of the context as a ContextState object. ContextState is defined as an inner class of Context to ensure the snapshots have a relation to the originating context:

	abstract class Context {
	Context() { Contexts.define(this); } // define context (explained later)
	abstract ContextState getState(); // null if inactive
	class ContextState {
	Context getContext() { return Context.this; }
	}}
	Suppose that PromotionCtx is characterized by a variable discount rate:
	class PromotionCtx extends Context {
	CFlow cf = /* as above */	class PromotionState
	double rate; /* with setter */	extends ContextState {
	ContextState getState() {	double rate; // init in constructor
	if(!cf.in()) return null;	double getRate() { return rate; }
	return new PromotionState(rate);	}}
	}

  So getCtxState returns the value of the context's getState method:The following is an example of using this activation condition to restrict a link to activate only when the promotion context is active: The abstract class SnapshotCtxActive provides the necessary support for defining activation conditions that depend on past context snapshots.

	class CurrentlyInCtx extends CtxActive {
	ContextState getCtxState(Object o){ return itsContext.getState(); }
	}
	discount.addActivation(new CurrentlyInCtx(new PromotionCtx()));
	Past Dependencies. abstract class SnapshotCtxActive extends CtxActive {
	ContextState getCtxState(Object o){
	Snapshot snapshot = getSnapshot(o);
	return snapshot.get(itsContext);
	} }

State Exposure and Parameterization Since

  contexts are standard objects, their parameterization is naturally done by passing parameters at instantiation time, or by sending them configuration messages. For instance, restricting Discount to inContext(StockOverflowCtx[.80]) is implemented as: Exposing context state, such as the discount rate in:

	class PutInCartInCtx extends SnapshotCtxActive {
	PutInCartInCtx(Context c){
	annotate(new NameCS("eshop.Item"));
	snapshot(new Hookset(MsgReceive.class, new NameCS("eshop.ShoppingCart"),
	new NameOS("addItem")), new NthParameter(1));
	}}
	3.6 discount.addActivation(new CurrentlyInCtx(new StockOverflowCtx(.80)));
	aspect Discount {
	pointcut amount(double rate): execution(double ShoppingCart.getAmount())
	&& createdInCtx(PromotionCtx(rate));
	double around(double rate): amount(rate) { return proceed() * (1 -rate); }
	}

We also use the interchangeable phrases "the application is in a given context" and "a given context is active".

We assume the syntax: (..) for exposing context state, and [..] for context parameterization.

http://reflex.dcc.uchile.cl

The implementation of getCtxParam is not shown as this would lead us too far into details. The interested reader is welcome to ask the authors.

Acknowledgments: Many thanks to thank Johan Brichau, Pascal Costanza, Maja D'Hondt, Stéphane Ducasse, Johan Fabry, Oscar Nierstrasz and Roel Wuyts for fruitful discussions on context-oriented programming and contextaware aspects.

Author financed by the Milenium Nucleous Center for Web Research, Grant P01-029-F, Mideplan, Chile. Author supported by the Science Foundation Ireland and Lero -the Irish Software Engineering Research Centre, and the Swiss National Science Foundation, Project No. 200020-105091/1 "A Unified Approach to Composition and Extensibility".


R N Charrel
email: remi.charrel@univmed.fr

X De Lamballerie

ZOONOTIC ASPECTS OF ARENAVIRUS INFECTIONS

To date, the International Committee for Taxonomy of Viruses recognizes that the family Arenaviridae contains a unique genus Arenavirus that includes 22 viral species. There are 9 additional arenaviruses that either have been discovered recently, or which taxonomic status remains pending. Arenaviruses have been classified according to their antigenic properties into two groups, the Lassa-Lymphocytic choriomeningitis (LCM) serocomplex and the Tacaribe serocomplex which has been further divided into four evolutionary lineages. Each arenavirus is more or less tightly associated with a mammal host. The distribution of the host dictates the distribution of the virus. Humans may become infected by arenaviruses through direct contact with infected rodents, including bites, or through inhalation of infectious rodent excreta and secreta. Lassa, Junin, Machupo, Guanarito, and Sabia viruses are known to cause a severe hemorrhagic fever, in western Africa, Argentina, Bolivia, Venezuela, and Brazil, respectively. Infection by LCM virus can result in acute central nervous system disease, congenital malformations, and infection in organ transplantation recipients. Detection of arenaviruses in their animal host can be achieved by virus isolation, and has recently taken advantage of PCR-based techniques. The approach based on consensus degenerate primers has shown efficient for both detection of known arenaviruses, and discovery of new arenaviruses.

Introduction

The eight edition of the Report of the International Committee for Taxonomy of Viruses (ICTV) states that the family Arenaviridae contains a unique genus Arenavirus that includes 22 viral species (Salvato et al., 2005). New arenaviruses were discovered recently and will be discussed (Table). Virions are spherical to pleomorphic with a diameter of 50-300 nm (average diameter for spherical particles is 120 nm). They possess a dense lipid-containing envelope proteins covered with 8-10 nm long club-shaped projections. Ribosomes (20-25 nm) may be present in the viral particles, and are responsible for their sandy appearance when viewed by electron microscopy, hence the name arenavirus (arena: sand, Latin). Arenaviruses are enveloped single-stranded RNA viruses, with a genome consisting of two RNA segments, designated large (L) and small (S). Each RNA segment encodes 2 non-overlapping reading frames of opposite orientations. The S RNA segment (~3,400 nucleotides) encodes the structural nucleoprotein, and the glycoprotein precursor secondarily cleaved into the envelope proteins G1 and G2. The L RNA segment (~7,200 nucleotides) encodes the viral polymerase and the Z protein, a zincbinding matrix protein. The genes on both S and L segments are separated by an intergenic non coding region with the potential of forming one or more hairpin configurations. The 5' and 3' untranslated terminal sequences of each RNA segment possess a relatively conserved reverse complementary sequence spanning 19 nucleotides at each extremity. The arenaviruses have been classified according to their antigenic properties into two groups: the Tacaribe serocomplex (including viruses indigenous to the New world) and the Lassa-Lymphocytic choriomeningitis serocomplex (including the viruses indigenous to Africa and the ubiquitous lymphocytic African viruses and those in the Western Hemisphere. Individual viruses are immunologically distinct by neutralization assays, which depend on the specificity of epitopes contained in the envelope glycoproteins (Salvato et al., 2005). Each virus species is more or less tightly associated with a rodent species (the only exception known at this time is Tacaribe virus which is associated with a species of bat) [START_REF] Childs | Ecology and epidemiology of arenaviruses and their hosts[END_REF]. Accordingly the distribution of the host dictates the distribution of the virus. LCMV is the only arenavirus to exhibit a worldwide distribution due to its association with Mus musculus. Other arenaviruses are distributed either in the New World or in Africa.

History

The family prototype, LCMV, was first isolated in 1933 during serial passage in monkeys of human material obtained from a fatal infection in the first documented epidemic of St. Louis encephalitis [START_REF] Armstrong | Experimental lymphocytic choriomeningitis of monkeys and mice produced by a virus encountered in studies of the 1933 St Louis encephalitis epidemic[END_REF]. Lassa, Junin, Machupo, Guanarito, and Sabia viruses are known to cause a severe hemorrhagic fever, in western Africa, Argentina, Bolivia, Venezuela, and Brazil, respectively [START_REF] Peters | Arenaviruses[END_REF], and were first recovered during investigations of outbreaks in 1958 [START_REF] Parodi | Concerning the epidemic outbreak in Junin[END_REF]), in 1963[START_REF] Johnson | Virus isolations from human cases of hemorrhagic fever in Bolivia[END_REF]), 1969[START_REF] Buckley | Lassa fever: a new virus disease of man from West Africa. III. Isolation and characterization of the virus[END_REF]), 1989[START_REF] Salas | Venezuelan hemorrhagic fever[END_REF], and of a single case in 1990 [START_REF] Lisieux | New arenavirus isolated in Brazil[END_REF], respectively. They are included in the Category A Pathogen List as defined by the CDC, and listed as Biosafety Level 4 (BSL-4) agents. LCMV, Lassa, and related viruses from the Old World are associated with rodents from the family Muridae, subfamily Murinae. New World arenaviruses are associated with New World rodents in the family Muridae, subfamily Sigmodontinae (Wilson and Reeder, 2005). The relative correspondence between the phylogeny of the hosts and of the viruses has suggested a long association also known as cospeciation or coevolution with rodents [START_REF] Gonzalez | Evolutionary biology of a Lassa virus complex[END_REF][START_REF] Bowen | Phylogenetic analysis of the Arenaviridae: patterns of virus evolution and evidence for cospeciation between arenaviruses and their rodent hosts[END_REF]. However, this concept remains controversial due to the limited information in terms of dating the phenomenon and understanding the mechanisms involved. For example rates of evolution estimated for LCMV appear to contradict estimated evolution rates of viruses and rodents by several orders of magnitude. Moreover, Tacaribe virus has been isolated from bats, not rodents, and is not known to be a chronic, inapparent infection of rodents.

Newly discovered arenaviruses

Chapare virus was recently isolated from a unique fatal human case of hemorrhagic fever in the Chapare River region close to Cochabamba in Bolivia [START_REF] Delgado | Chapare virus, a newly discovered arenavirus isolated from a fatal hemorrhagic fever case in Bolivia[END_REF]. There is currently no information concerning the rodent host of Chapare virus. Morogoro virus was isolated from Mastomys sp trapped in Tanzania (Vieth et al., 2007). This virus is most closely related to Mopeia virus regardless of the gene used for analysis [START_REF] Charrel | Phylogeny of the genus Arenavirus[END_REF]. Dandenong virus was identified via a metagenomic approach, and subsequently isolated from tissue specimens collected from a fatal case of infection in a patient who underwent kidney transplantation in Australia from a donor who spent a 3-month visit in the former Yugoslavia, where he had traveled in rural areas [START_REF] Palacios | A new arenavirus in a cluster of fatal transplant-associated diseases[END_REF]. Genetic distance analyses suggested that the taxonomic status of Dandenong virus requires additional investigations for its resolution. For Catarina, Skinner Tank, Tonto Creek and Big Brushy Tank viruses, recently discovered in the United States of America, complete sequences are only available for the NP and GPC genes at present [START_REF] Cajimat | Catarina virus, an arenaviral species principally associated with Neotoma micropus (southern plains woodrat) in Texas[END_REF][START_REF] Cajimat | Diversity among Tacaribe serocomplex viruses (family Arenaviridae) naturally associated with the Mexican woodrat (Neotoma mexicana)[END_REF][START_REF] Milazzo | Diversity among tacaribe serocomplex viruses (family Arenaviridae) naturally associated with the white-throated woodrat (Neotoma albigula) in the southwestern United States[END_REF]. Their taxonomic classification is currently under investigation at the ICTV. These four viruses were isolated from Neotoma rodents. They appear most closely related to Whitewater Arroyo virus. As in the case of their close relatives, North American Whitewater Arroyo, Tamiami, and Bear Canyon virus, they demonstrate a discrepant grouping with clade A and clade B viruses depending on which structural protein (NP or signal peptide/G2) is used for analysis. This suggests that these seven viruses are derived from a common ancestor.

A c c e p t e d M a n u s c r i p t

Kodoko virus was detected, but not isolated, in tissues of Mus Nannomys minutoides trapped in Guinea. Partial sequence analysis indicates that Kodoko virus roots LCMV [START_REF] Lecompte | Genetic identification of Kodoko virus, a novel arenavirus of the African pigmy mouse (Mus Nannomys minutoides) in West Africa[END_REF]. This partial information tends to support the consideration of Kodoko virus as a new species. However, this must be confirmed by virus isolation, complete genome sequencing and identification of the natural host. Partial sequences of Pinhal virus (Calomys tener from Brazil) NP protein were obtained from Genbank with minimal information. Using these partial NP sequences for comparison, Pinhal virus is most closely related to Oliveros virus (19-20%) [START_REF] Charrel | Phylogeny of the genus Arenavirus[END_REF].

Evolutionary relationships

Genetic studies recently revealed congruency with serological delineation (Figure). Phylogenetic analyses were historically based on sequence representing a partial region of the NP gene [START_REF] Bowen | The phylogeny of New World (Tacaribe complex) arenaviruses[END_REF][START_REF] Bowen | Phylogenetic analysis of the Arenaviridae: patterns of virus evolution and evidence for cospeciation between arenaviruses and their rodent hosts[END_REF]. The genus was divided into two main groups corresponding to the Old World and the New World viruses. The Old World (Lassa-LCM serocomplex) lineage comprises seven viruses: LCM, Lassa, Mopeia, Mobala, Ippy, Morogoro and Kodoko and is distantly rooted to the three New World (Tacaribe serocomplex) lineages, designated A, B, and C. Lineage A includes five South American viruses, Pirital, Pichinde, Flexal, Parana, Allpahuayo. Lineage B includes eight South American viruses including Sabia, Junin, Machupo, Guanarito, Amapari, Tacaribe, Cupixi and Chapare viruses. Lineage C comprises two South American viruses: Oliveros and Latino. Phylogenetic studies conducted with complete S RNA sequences recently demonstrated that discrepancies observed in the topology of phylograms reconstructed from nucleoprotein and glycoprotein genes are attributed to the recombinant nature of the S RNA segment of the three North American viruses: Whitewater Arroyo, Tamiami, and Bear Canyon [START_REF] Charrel | Phylogeny of New World arenaviruses based on the complete coding sequences of the small genomic segment identified an evolutionary lineage produced by intrasegmental recombination[END_REF][START_REF] Charrel | New insights into the evolutionary relationships between arenaviruses provided by comparative analysis of small and large segment sequences[END_REF]. The recent discovery of additional North American arenaviruses, Skinner Tank, Catarina, Tonto Creek and Big Brushy Tank viruses (isolated from Neotoma rodents) confirmed this finding [START_REF] Cajimat | Catarina virus, an arenaviral species principally associated with Neotoma micropus (southern plains woodrat) in Texas[END_REF][START_REF] Cajimat | Diversity among Tacaribe serocomplex viruses (family Arenaviridae) naturally associated with the Mexican woodrat (Neotoma mexicana)[END_REF][START_REF] Milazzo | Diversity among tacaribe serocomplex viruses (family Arenaviridae) naturally associated with the white-throated woodrat (Neotoma albigula) in the southwestern United States[END_REF], and indicated that these 2 viruses underwent the same evolutionary mechanism (Figure).

Phylogenetic analyses were progressively updated with the availability of complete sequences for the L RNA segment. The most comprehensive study, based on the comparative analysis of complete sequences of the four genes for the largest set of viruses, was published recently [START_REF] Charrel | Phylogeny of the genus Arenavirus[END_REF]. The delineation into an Old World group and a New World group, which was subsequently divided into three clades corresponding to the antigenic findings, was confirmed. Comparative analysis of the NP and GPC sequences showed that the discrepant position observed in the two genomic regions respectively for the viruses indigenous to North America (Tamiami, Whitewater Arroyo, Bear Canyon, and the more recently discovered Skinner Tank, Catarina, Tonto Creek and Big Brushy Tank viruses is due to the recombinant nature of the S RNA segment of these viruses, as reported previously [START_REF] Charrel | The Whitewater Arroyo virus: natural evidence for genetic recombination among Tacaribe serocomplex viruses (family Arenaviridae)[END_REF]. No recombination was observed in the L RNA segment. From this dataset and analysis, it appeared that no arenavirus genome was the result of a reassortment (also known as intersegmental recombination) mechanism.

Disease in animals and man, therapy and diagnostic

Humans may become infected by arenaviruses through direct contact with infected rodents, including bites, or through inhalation of infectious rodent excreta and secreta. The domestic and peridomestic behavior of several species of rodent reservoir hosts is a major contributing factor facilitating viral transmission from rodent to human. However, in most cases, transmission of arenaviruses to humans occurs following recreational or agricultural incursions into environments providing critical habitat for rodent hosts. Additionally, professionals handling infected rodents in the field or laboratory are at Flexal and Tacaribe viruses have caused febrile illness in laboratory workers [START_REF] Peters | Arenaviruses[END_REF]. Whitewater Arroyo virus may have been associated with 3 fatal cases of infection in California (CDC, 2000). Exposure to Pichinde virus has resulted in numerous seroconversions among humans without any noticeable clinical significance (Buchmeier, unpublished results). Tacaribe virus is believed to have caused a single case of a febrile disease with mild CNS symptomatology (J. Casals, unpublished data).

A live attenuated Junin virus vaccine (Candid#1) was produced. Its efficacy was proven in a doubleblind trial in 15,000 agricultural workers at risk to natural infection in Argentina. Subsequently, more than 100,000 people were immunized in Argentina. A prospective study conducted over two epidemic seasons among 6,500 male agricultural workers in Argentina showed that Candid #1 vaccine efficacy was greater or equal to 84%, and no serious adverse effects were detected [START_REF] Maiztegui | Protective efficacy of a live attenuated vaccine against Argentine hemorrhagic fever. AHF Study Group[END_REF]. Development of Lassa virus vaccine was attempted during the last 30 years. The most advanced projects include (i) a replicationcompetent vaccine based on attenuated recombinant vesicular stomatitis virus vectors expressing the Lassa viral glycoprotein showed that a single intramuscular vaccination elicited a protective immune response in nonhuman primates against a lethal challenge (Geisbert et al., 2005); (ii) ML29, a recombinant Lassa/Mopeia virus vaccine which replication is attenuated in guinea pigs and nonhuman primates, and demonstrated protection against Lassa virus challenge in guinea pigs, Rhesus macaques [START_REF] Lukashevich | Safety, immunogenicity, and efficacy of the ML29 reassortant vaccine for Lassa fever in small non-human primates[END_REF]; (iii) a yellow fever 17D vaccine expressing Lassa virus glycoprotein precursor protected guinea pigs against fatal Lassa fever [START_REF] Bredenbeek | A recombinant Yellow Fever 17D vaccine expressing Lassa virus glycoproteins[END_REF]. Recently, a recombinant LCMV/Vesiculovirus vaccine which is attenuated, prevents lethal challenge with LCMV in mice, elicits rapid and long-lived cell-mediated immunity against lethal challenge with wildtype LCMV, confers rapid and long-lived cell-mediated protection against overwhelming systemic infection and liver disease, presents no detectable gain in pathogenicity after propagation in immunodeficient hosts (Bergthaler et al., 2007).

Antivirals

No antiviral is approved and commercialy available for arenaviruses, except for ribavirin, which proved to be efficient if treatment was administered at the early stage of Lassa fever (McCormick et al.

, 1986).

There is however an intense activity centered on molecules with potential antiviral activity against arenaviruses. To date, the most promising molecules are those which interfere with the membrane fusion through the interaction of the G2 fusion subunit with the signal peptide due to IC50 below 10nM [START_REF] Larson | Identification of a broad-spectrum arenavirus entry inhibitor[END_REF]York et al., 2008).

Immune plasma therapy

A c c e p t e d M a n u s c r i p t

For Junin virus infection, immune plasma therapy at an early stage showed efficient by reducing the mortality rate from 30% to 1% [START_REF] Maiztegui | Efficacy of immune plasma in treatment of Argentine haemorrhagic fever and association between treatment and a late neurological syndrome[END_REF].

Diagnostics and detection of arenaviruses in clinical and environmental samples

In the animal reservoir, detection of antibodies specific for arenaviruses is poorly indicative since they do not systematically correlate with the presence or absence of live virus. Depending on the virus, the mode, and age at the time of infection, the mammalian host may be persistently infected regardless of the presence or absence of antibodies. Alternatively, an efficient immune response may result in the eradication of the virus. Therefore, serology can be indicative of the circulation of arenaviruses for a given population in a specific region, and thus can be used as an indicator for further investigation of virus circulation by molecular means. Therefore, the following paragraph will focus on the molecular methods that can be used to detect arenaviruses in animal samples.

The detection of arenaviruses in animal specimens can be achieved by techniques based on consensus primer sequences or by assays that target specifically one virus. The latter require good knowledge of the genetic heterogeneity within a given species in order to avoid false negative results due to unaddressed mismatches in the primers or probes. Therefore, in the absence of this knowledge for most species, the consensus primer approach is preferred. Moreover, the frequent circulation of two or more arenaviruses in the same geographic region has encouraged the development of assays that amplify all recognized arenaviruses by combination of degenerate primers located in the conserved regions of the genome [START_REF] Lozano | Characterization of arenaviruses using a family-specific primer set for RT-PCR amplification and RFLP analysis: Its potential use for detection of uncharacterized arenaviruses[END_REF][START_REF] Bowen | The phylogeny of New World (Tacaribe complex) arenaviruses[END_REF]. However, there are no reports of the use of these strategies in practical situations. A few years ago, the diagnostic strategy based on degenerate primers was hampered by the lack of genomic data in regions other than the nucleoprotein gene [START_REF] Bowen | The phylogeny of New World (Tacaribe complex) arenaviruses[END_REF][START_REF] Bowen | Phylogenetic analysis of the Arenaviridae: patterns of virus evolution and evidence for cospeciation between arenaviruses and their rodent hosts[END_REF]. Nowadays, complete sequence data have been made available for all arenaviruses. However, degenerate primer strategies have not been fully reevaluated in light of these new data. This needs to be accomplished to enable identification of alternative genomic regions that can reveal relationships between both identified and as yet unidentified arenaviruses in human and animal samples. Recent discoveries of novel arenaviruses relied on the use of primers, broadly reactive for viruses within the genus, located in the L RNA segment. Kodoko virus and Morogoro virus were identified by using such an approach [START_REF] Lecompte | Genetic identification of Kodoko virus, a novel arenavirus of the African pigmy mouse (Mus Nannomys minutoides) in West Africa[END_REF]Vieth et al., 2007). Recent advances in high-throughput methods, based on pyrosequencing technology, have proven to be efficient at identifying a novel arenavirus in clinical samples with no previous evidence of the presence of this virus [START_REF] Palacios | A new arenavirus in a cluster of fatal transplant-associated diseases[END_REF]. As described above, the limited amount of knowledge on genetic diversity with a given species should be taken into account when designing diagnostic assays intended to detect specifically one arenavirus. For instance, new strains of LCMV were shown to be sufficiently divergent to hamper detection by the Taqman probe, due to mismatches. In the paper from McCausland et al, the two primers described for a real-time RT-PCR assay using the SybrGreen technology presented respectively 6 and 6 mismatches when aligned against an alignment of 6 LCMV strains (Armstrong, WE, CH, Traub, Pasteur, Marseille) [START_REF] Mccausland | Quantitative PCR technique for detecting lymphocytic choriomeningitis virus in vivo[END_REF]. Based on the same alignment, the four primers designed by McIver et al showed up to 6 mismatches in the sequence, and 6 mismatches in the TaqMan probe; such rates of mismatch will undoubtedly have a negative impact on the detection of LCMV RNA in clinical or environmental samples [START_REF] Mciver | Development of multiplex PCRs for detection of common viral pathogens and agents of congenital infections[END_REF]. To date, the assay described in [START_REF] Emonet | Mouse-to-human transmission of variant lymphocytic choriomeningitis virus[END_REF] based on SybrGreen technology is the only one to use primers designed to match all 6 previously listed sequences of LCMV [START_REF] Emonet | Mouse-to-human transmission of variant lymphocytic choriomeningitis virus[END_REF]). However, it has been inadequately evaluated, and merits further investigation to determine its sensitivity and specificity. Such evaluation will be rendered necessary whenever a new strain of LCMV is isolated and sequenced. To date, there is insufficient knowledge of genetic heterogeneity within the species LCMV. Accordingly, it is advocated to combine the two approaches.

A c c e p t e d M a n u s c r i p t RT-PCR is to date the only method available for rapid diagnosis of Junin virus infection. For these reasons, several RT-PCR assays have been developed [START_REF] Lozano | Rapid diagnosis of Argentine hemorrhagic fever by reverse transcriptase PCR-based assay[END_REF][START_REF] Lozano | A simple nucleic acid amplification assay for the rapid detection of Junin virus in whole blood samples[END_REF][START_REF] Bockstahler | Detection of Junin virus by the polymerase chain reaction[END_REF]. However, these techniques have never been employed practically in an epidemic situation to manage the outbreak, or more specifically to detect Junin virus infection at an early stage in order to initiate the immune plasma therapy that reduced the mortality rate from 30% to 1% [START_REF] Maiztegui | Efficacy of immune plasma in treatment of Argentine haemorrhagic fever and association between treatment and a late neurological syndrome[END_REF]. More recently, a real time RT-PCR assay, with a 0.5 TCID50 detection limit, has been reported (Vieth et al., 2005). However, it has not been used in a clinical or environmental situation. In the same study, an assay specific for Guanarito virus was designed and detected 5 TCID50.

Lassa virus is also a prominent threat outside the area of endemicity with several imported cases in Europe [START_REF] Gunther | Imported lassa fever in Germany: molecular characterization of a new lassa virus strain[END_REF][START_REF] Cummins | Lassa fever[END_REF]Van der Heide et al., 1982), Japan [START_REF] Hirabayashi | An imported case of Lassa fever with late appearance of polyserositis[END_REF], the United States [START_REF] Holmes | Lassa fever in the United States. Investigation of a case and new guidelines for management[END_REF], and the Middle East (Schlaeffer et al., 1988). RT-PCR diagnostic assays have been developed but never used for the early detection of human cases in epidemic situations in Africa [START_REF] Demby | Early diagnosis of Lassa fever by reverse transcription-PCR[END_REF]Trappier et al., 1993;Lukenheimer et al., 1990). More recently, a previously reported PCR assay was adapted to the real-time SybrGreen format and was tested with patient samples [START_REF] Drosten | Rapid detection and quantification of RNA of Ebola and Marburg viruses, Lassa virus, Crimean-Congo hemorrhagic fever virus, Rift Valley fever virus, dengue virus, and yellow fever virus by real-time reverse transcription-PCR[END_REF]; the detection limit was evaluated at 2245 genome-equivalent per ml of serum whilst the viral load in patients is generally very high (> 10 5 genome-equivalent per ml of serum). This assay has been compared to an L-assay based on 7 human specimens, and both tests showed a similar detection rate (Vieth et al., 2007). The first quality assurance study on the rapid detection of Lassa virus RNA included 24 participant laboratories from 17 countries; tenfold dilutions of Lassa virus inactivated genetic material were detected at a rate varying from 21 to 85% depending on the concentration in the sample [START_REF] Niedrig | First international quality assurance study on the rapid detection of viral agents of bioterrorism[END_REF]. Of interest is the fact that specimens containing high concentrations of viral RNA may produce false negative results due to inhibition of the enzymatic reactions. To date there is no study addressing the presence and prevalence of RT and PCR inhibitors depending on the organ used for analysis. This would be of utmost interest to deploy a strategy adapted to virus search. Meanwhile, it is therefore proposed that clinical specimens should be "spiked" with an internal control positive sample to monitor enzymatic reaction efficacy. Alternatively the test samples should be serially diluted to alleviate the problem of inhibition of enzymatic reactions in mammalian tissues. This point is pivotal to avoid underestimation of virus prevalence due to technical artifacts.

Conclusions and future prospects

During the last 3 years, the discovery of 9 new arenaviruses, of which 2 were human pathogens, strongly suggests that many more arenaviruses may be discovered in the future. As new technologies begin to impact on virus discovery it is now becoming clear that a large number of viruses remain to be unearthed as recently suggested [START_REF] Pybus | New inferences from tree shape: numbers of missing taxa and population growth rates[END_REF]. As illustrated above, the quest for new arenaviruses requires the combination of traditional virological approaches with innovative technologies such as large scale sequencing and extensive bioinformatic capacities. Schlaeffer, F., Bar-Lavie, Y., Sikuler, E., Alkan, M., Keynan, A., 1988. Evidence against high contagiousness of Lassa fever. Trans. R. Soc. Trop. Med. Hyg. 82, 311 Sewell, D.L., 1995. Laboratory-associated infections andbiosafety. Clin. Microbiol. Rev. 8, 389-405 Trappier, S.G., Conaty, A.L., Farrar, B.B., Auperin, D.D., McCormick, J.B., Fisher-Hoch, S.P., 1993. Evaluation of the polymerase chain reaction for diagnosis of Lassa virus infection. Am. J. Trop. Med. Hyg. 49,[214][215][216][217][218][219][220][221] Van der Heide, R.M., 1982. A patient with Lassa fever from Burkina Faso (formerly Upper Volta), diagnosed in the Netherlands. Ned. T. Geneesk. 126, 1-7.

Vieth, S., Drosten, C., Charrel, R., Feldmann, H., Günther, S., 2005. Establishment of conventional and fluorescence resonance energy transfer-based real-time PCR assays for detection of pathogenic New World arenaviruses. J. Clin. Virol. 32, 229-35. Vieth, S., Drosten, C., Lenz, O., Vincent, M., Omilabu, S., Hass, M., Becker-Ziaja, B., ter Meulen, J., Nichol, S.T., Schmitz, H., Günther, S., 2007. RT-PCR assay for detection of Lassa virus and related Old World arenaviruses targeting the L gene. Trans. R. Soc. Trop. Med. Hyg. 101, 1253-1264. Wilson, D.E., Reeder, D.M., 2005. Mammal Species of the World, 2nd edn. Johns Hopkins University Press, Baltimore York, J., Dai, D., Amberg, S.M., Nunberg, J.H., 2008. pH-induced activation of arenavirus membrane fusion is antagonized by small-molecule inhibitors. J. Virol. Sep 3.

Legends Table

List of arenavirus species and newly discovered arenavirus not yet classified, and respective characteristics.

  s c r i p t choriomeningitis virus (LCMV), recognized as the Old world group) (Salvato et al., 2005). Nucleocapsid antigens are shared by most arenaviruses, and quantitative relationships show the basic split between

  A c c e p t e d M a n u s c r i p t increased risk of infection(Sewell, 1995). Mostly, modifications of the environment due either to human activities (modern farming practices), or natural ecological changes (flooding, storms) have been implicated in the emergence of human disease caused by arenaviruses resulting from changes in behaviour of the reservoir host.To date, 7 arenaviruses are associated with human disease with different clinical pictures. Lassa, Junin, Machupo, Guanarito, Sabia and Chapare viruses are known to cause a severe hemorrhagic fever, in western Africa, Argentina, Bolivia, Venezuela, Brazil, and Bolivia respectively[START_REF] Peters | Arenaviruses[END_REF][START_REF] Delgado | Chapare virus, a newly discovered arenavirus isolated from a fatal hemorrhagic fever case in Bolivia[END_REF]. Infection by LCM virus can result in acute central nervous system disease and congenital malformations[START_REF] Barton | Lymphocytic choriomeningitis virus: reemerging central nervous system pathogen[END_REF][START_REF] Barton | Congenital lymphocytic choriomeningitis virus infection in twins[END_REF]; it has recently been described as an important cause of fatal infection in organ transplantation recipients, and immunocompetent patients(CDC, 2005;[START_REF] Fischer | Transmission of lymphocytic choriomeningitis virus by organ transplantation[END_REF] al., 2006; Amman et al., 2007; Charrel et al., 2006; Emonet et al., 2007, Palacios et al., 2008). Very little is known about the health consequences of infection with the other arenaviruses.

  Salvato, M.S., Clegg, J.C.S., Buchmeier, M.J., Charrel, R.N., Gonzalez, J.P., Lukashevich, I.S., Peters, C.J., Rico-Hesse, R., Romanowski, V., 2005. Family Arenaviridae. In: Van Regenmortel, M.H.V., Fauquet, C.M., Mayo, M.A., Maniloff, J., Desselberger, U., Ball, L.A., Virus Taxonomy, Eight report of the International Committee on Taxonomy of Viruses.Academic Press

Figure

  Figure Phylogenetic relationships between arenaviruses within evolutionary lineages. Red, Old world viruses; Green, lineage A new world viruses, Blue, lineage B new world viruses; Grey, lineage C new world viruses; Purple, recombinant new world viruses. Left panel, phylogram based on nucleoprotein amino acid sequences, right panel, phylogram based on concatenated signal peptide and glycoprotein 2 amino acid sequences. The neighbor-joining, poisson and bootstrapping (200 pseudoreplications) algorithms were computed by MEGA 2 software package.

Acknowledgements

We thank Stephan Günther for sharing results before publication. This work was partly supported by the Rivigene EU project.

Conflict of interest statement

Table 1