Ronie Salgado

Marcus Denker

Stéphane Ducasse
email: stephane.ducasse@inria.fr

Anne Etien

Vincent Aranega

Towards a Smart Data Processing and Storage Model

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The first objective of this paper is to introduce the need for new object-oriented and distributed database management with automatic and guaranteed support for the following three properties or operations on the data system:

We start in Section 2 by describing three different use case scenarios motivating the need for this system: keeping track of medical clinical trial data; keeping soft real time track and monitoring of medical data coming from sensors such as the heart beat of a person; and the accounting and book-keeping process in a company. After describing these use case scenarios, we present a problem statement and a research hypothesis in Section 3 with the objective of identifying the general principles and requirements that need to be on the foundational object-oriented system to facilitate the construction of a solution. In Section 4 we compile a list of fundamental requirements, and in Section 5 we present a list with fundamental problems, risks, along with possible strategies of mitigation. Finally we present our design and implementation for our smart data system in Section 6.

Motivational scenarios

Clinical trial data. Any new medicine or medical procedure needs to be subject to extensive clinical trials to evaluate its safeness and efficacy before it can be applied to the general public. This clinical trial process typically involves several phases, several populations, and several years of extended controlled experiments. All of these controlled experiment processes generate massive amounts of data whose traceability has to be tightly controlled to ensure the reliability of gathered data. Tampering with the gathered data should not be possible. Further posterior analysis, peer reviewal and auditing on the gathered data may reveal a flaw during certain experiment instances which may require the revocation of the affected data. This revocation process may have a cascade effect on complete or partial revocation on the data. In addition raw data may be used to generate derived data and it is important to know when a derived data is impacting by the revocation of primary form of data.

Vital sign monitoring system. The diagnostics and treatment of several medical disorders such as hyper-tension, hypo-tension, cardiac arrhythmia, and insulin dependent diabetes may require the constant monitoring of a patient. This monitoring is carried with an electronic sensor during long periods of time such as weeks, months and in some cases even during the whole life of the patient. The ubiquity of some sensors such as a heart rate sensor present in a watch being weared by an individual makes constant and daily monitoring feasible for non-diagnostic or treatment purposes. With the case of hear rate monitoring, a simple scenario involving three different actors is the following:

1. The heart rate of a patient is being monitored by a sensor. 2. The family of the patients want to know on whether he or her is alive, dead, or dying. 3. The doctor that treats its patient needs to check a log and a chart of the patient heart rate data once perweek.

In Section 7 we present a prototype and simulation for this distributed scenario using our smart data storage and processing system prototype.

Company accounting system. Many companies need to keep a complete accounting system on every commercial movement that they perform. The need for keeping an accounting system comes from two different, but related problem: keeping track of the everyday operations of the company, and complying with legally required book-keeping obligations for taxing purposes. In the first case the company has some flexibility on deciding which additional accounting records to keep and some specific reports that it might generate typically for taking commercial and strategic decisions on the company business. For the case of the taxing purposes, the company needs to keep track of at least every cash movement flow, by keeping track on each one of its incomes and outcomes, keep copies of bills, receipts and invoices for each acquisition and sale. Then the company, depending on its jurisdiction, it needs to aggregate this data to generate periodically different accounting books in a specific way with a format that is mandated by the law.

Problem statement and hypothesis

Problem Statement. From the previous use case scenarios, we derive the following general problem statement:

How do we model, design and construct a data storage and processing system that supports automatic traceability of origins, integrity verification, and revocability of invalid and or private data in a distributed and decentralized environment?

The Need for Distribution In the vital sign monitoring scenario the need for distribution and decentralization is an evident requirement due to the fact that the sensors are physical distinct machines to the one that is used by the medic and the family members of the patient. In the other cases, the need for distribution and decentralization is not that evident, but it stems from the way that large organizations operate in a distributed geographical scale. For example, large pharmaceutical companies may conduct their clinical trials in different countries simultaneously. In the case of the accounting system a large multi-national may have the need to aggregate and audit the balances of their different local subsidiaries, in order to keep a global balance for advertising their total value so that the company can trade its shares in the stock market. For these reasons, the need for distribution and decentralization can only be ignored in the case the whole system needs to be executed in a single machine, and there is also not going to be any need to scale in the future. Otherwise, the system is gonna require a full redesign and rewriting to add support for distribution when is needed. On the other hand, a system designed for distribution can always be executed in a single physical node in case it is required to reduce hardware cost.

Proposal. To facilitate the solution of this problem we propose the construction of a framework in Pharo [START_REF] Black | Pharo by Example[END_REF] around the concept of Smart Data for describing and storing object oriented data models with the following capabilities:

1. Automatic support for traceability of origins. 2. Guaranteed structural data consistency via immutability enforced in transaction boundaries for specific historical data snapshot. 3. Automatic data replication and distribution is always possible, and easy for scenarios with a fixed and known data distribution topology.

In the next section we discuss the actual requirements for our smart data processing and storage system by defining these requirements.

4 Smart data storage system requirements 4.1 Traceability of origins Definition of Traceability. We define traceability of origins as the ability of knowing where each piece of data in a data base comes from. A more concrete definition means that for each datum 𝐷 that is present in a database in a specific period of time we should be able to answer at least the following questions:

• Who wrote the datum 𝐷?

• When the datum 𝐷 was written?

• With which and whose permissions was the datum 𝐷 written?

Origin as Metadata. The first important observation of these questions is that they are all about requesting a specific metadata about the datum 𝐷. The presence of this metadata in this context is orthogonal to the actual data, so a desirable property is to keep the specification of this metadata completely separate from the specification of the actual domain specific data model.

Transactions.

The second important observation is that all of these questions has the verb write. For our purposes, we are going to define a transaction as a contained and isolated process where a sequence of reads and writes is performed on the data stored in a database. To simplify our design we are also going to mandate that data accesses happen during the context of a transaction. A transaction might end on a commit where the data is actually written into the data store, or it might end in a rollback where the new data is completely discarded. During a transaction commit, the newly written data has to be serialized and transmitted into the final persistent data store, which may be a single disk drive, or even a replicated cluster. The important aspect here is that transactions introduce synchronization points where a specific version of the data is read and written.

Transaction as the Origin. Since any piece of data can only be written during the context of a transaction, then it becomes evident that all of the data written in the system has a single transaction as its source of origin. This implies that the problem of traceability of origin can be solved by just tagging transaction themselves with additional metadata that is part of the transaction life cycle. In other words, the previous questions about the data origin can be re-phrased in the following ways:

• Who initiated the transaction 𝑇 that wrote the datum 𝐷? • When was the transaction 𝑇 that wrote the datum 𝐷 committed? • With which and whose permissions were used to initiate and commit the transaction 𝑇 wrote the datum 𝐷?

Transaction Context Specific Data. Since adding this metadata to the transaction itself is completely orthogonal to the actual data domain, then we propose that the problem of traceability of origin can be solved by using transaction context specific data. We propose this mechanism as an elegant and more robust alternative than to actually model the concept of origins in the data model itself.

Integrity verification

The capability of performing integrity verification implies that we have a predicate function 𝐼 that receives at least a subset of the whole data set, and answers true or false on whether the subset of the data set complies with some requirements on data integrity. For our purposes, we decided to define our predicate 𝐼 as the simultaneous compliance of the following three related predicates: structural consistency on the data (𝑆); domain defined constraints (𝐷 𝑐 ), and bit-level data correctness (𝐵 𝑐 ). In algebraic form, this is summarized in the following way:

𝐼 (𝐷) = 𝑆 (𝐷) ∧ 𝐷 𝑐 (𝐷) ∧ 𝐵 𝑐 (𝐷)
We also define each of these different components of the integrity verification predicate as the simultaneous compliance of multiple boolean predicates. We define these three predicates as grouping of different aspects on the concept of data integrity.

Structural Consistency. We define structural consistency as the correctness on the organization of the stored data. The main factor required for enforcing this is type checking correctness. For example, this implies that it should be impossible to write a date in a place where a home address is required. In addition to type checking, we also define the requirements on the data topology as being part of its structural consistency requirement. For example, it should not be possible to have a cyclic graph of objects in a location where a tree is required. Simple cases of these requirement on the topology might be encoded as type checking requirements, but non-trivial cases might need additional predicates and graph traversal algorithm for testing. Domain Defined Constraints. In the 𝐷 𝑐 predicate we group all of the boolean predicates that specify additional domain specific constraints that are mandated by the application. These predicates are completely user defined and they encode the invariants and the contracts that their data model always has to comply. For example, in double-entry accountability each book keeping entry that represents an income from one account must have a corresponding outcome entry from another account.

Bit-level Correctness. Data has to eventually be serialized and transmitted via some link to its final persistence storage medium. This transmission and storage process may be imperfect and suffer of data losses. We define as bit-level correctness to the data integrity aspects that arise during this serialization, encoding and storage process. The standard mechanism to detect and repair this problem consists on the usage of checksum, and error detection and corrections codes. Stronger mathematical guarantees on this aspect can be provided through the usage of cryptographic hashes. The introduction of cryptography on this level also provides the opportunity of using a digital signatures algorithms (DSA) or a message authentication code (MAC) to also guarantee the authenticity of the data. The capability of adding cryptographic validation at this level also allows one to add an additional layer to detect and prevent data tampering by unauthorized parties.

Revocation

We define data revocation as the process of turning previously valid data into invalid data, and automatically reacting on the dependent data by repairing it or also marking it as invalid data. We identify two main reasons for revocating data: data that was previously valid is not valid anymore because new sources of information arrived and contradicted the previous validation of data; and the need for destructing or hiding information that is not needed anymore and has become private.

Revocation as Data Invalidation. After data is committed into a data store, new information may be added that may invalidate at least partially the modified data during a previous transaction. For example, in the case of the clinical trial, it may be determined after an auditing process that some instances of a controlled experiment for a drug are invalid due to a mistake committed during the execution of those specific experiment. Once the flawed experiments are detected, it becomes necessary to re-generate the reports that depend on this experimental data by excluding the data from those experiments, and in some extreme cases it may even invalidate an actual approval for a drug. As another example, in the case of a company accounting system, sometimes sold products are refunded, so that specific sale becomes invalid.

Revocation as Data Destruction. Data may need to be destructed or its access may be needed to make private due to many possible reasons. One important motivation for destroying data is the need to preserve the privacy of individuals and respect laws on data protection and privacy such as the GDPR. These laws also allow the individual the right for having their private data removed from electronic services. This means that they may be even necessary by a mandate by law to completely destroy the private data from the storage system. In some cases it might be enough to replace the private data by completely anonimized data, however proper automatic anonimization of data is a difficult problem because it is also necessary to provide the guarantee of making it impossible to de-anonimize the data by correlating multiple data sources.

Cascade Effect. Revocated data may exist in a dependency to additional data which may also need to be revocated. In the case of revocated data due to invalidation, it might be enough to mark the data that depends on it as invalidated and generate a new version of it to re-validate the data. This may produce a cascade sequence effect of invalidation and revalidation. If the set of affected data forms a directed acyclic graph (DAG), then the problem of re-validating this data is a just a matter of performing a topological sort on the directed graph, and then execute the single sequence of invalidation and revalidations. If the affected data instead has cycles, it may not even be possible to completely validate it, and this process may even have a catastrophic effect. For example, a directed cyclic graph with two vertices 𝑉 = {𝑎, 𝑏}, and two edges 𝐸 = {(𝑎, 𝑏), (𝑏, 𝑎)}. In this graph the invalidation and re-validation of 𝑎 may trigger the invalidation of 𝐵, whose revalidation may trigger a new invalidation of 𝐴. In the general case, the invalidation and revalidation process may never reach a steady state where it completes. This means that in the cyclic case it is required to find a strategy that either:

• Ensures that a revalidation steady state is always reached.

• Detect this oscillatory process, forces them into a new state, or destroys them. • Perform re-validation in a lazy process. This mitigates the nasty meta stability issues by bounding computations during revalidation into single slice of a breadfirst search style graph traversal.

As for the case of revocated objects due to destruction, if the cascade effect of revocation involves the destruction of objects that depends on it, it becomes evident that the consequences might be completely catastrophic. If on the other hand it only involves a process of invalidating and re-validating the affected data.

In our current prototype we have not yet implemented any kind of support for the data revocation capability yet, and we still have to decide on how to properly model and express these two different cases of data revocation.

Concurrency, Distribution and Decentralization

Concurrency and distribution are nowadays two central requirements on any real world data storage and processing system that needs scale to large numbers of connections and simultaneous transactions. This implies that our smart data storage and processing system has to be designed at the architectonic level to support concurrent transactions, and to at least facilitate the possibility of replicating and propagating data.

Another desirable property is the ability to decentralize the management structures and authorities that are involved in the operation of a distributed system. This desire to support decentralization comes from two sides: real work requirements on how data is produced, stored and shared by different real world organizations; the need of having robustness against failures, and even against some malicious attacks on a data infrastructure by one owner.

Fundamental Problems, Risks and Mitigations

Concurrency and Distribution Issues

Since the support for concurrency and distribution is an important and desirable property, this means that our system has to be designed to avoid, and if possible, to make impossible the main threats of concurrent and distributed system that might bring the whole system down. These crucial well known threats that need to be at least mitigated are the followings:

• Deadlocks: mutual locks that are never released.

• Livelocks: mutual actors that are waiting for each other. • Race conditions: conflicting read-modify-writes on shared state.

Deadlock. Deadlocks are caused by two different processes that are taking two different locks in a different order. Deadlocks are solved by holding these locks always on the same order. The presence of explicit transactions helps on mitigating this issue since transactions induce an ordering constraints on the operations, which also provides an opportunity for taking the locks in the proper order.

Livelock. Livelocks typically happens on the presence of two synchronous processes that are waiting for each other, so they never end waiting and doing an actual useful work. One solution to this problem is on having actors that only communicate via asynchronous communication. This also introduces the problem that some concurrent and distributed processes need to be designed and implemented in terms of state machines. In our smart data storage and processing system we are still not modeling and supporting properly actors, so for now we are not attacking this problem yet.

Race Condition. Race conditions are the product of conflicting read-modify-write (RMW) operations on a shared state by two or more simultaneous processes. The traditional way for preventing race conditions consists on introducing locks. Another way of preventing race conditions consists on not sharing data that is simultaneously being written at the same time at all. One way of enforcing this property is by making all data immutable, which is the main property that is guaranteed by pure functional programming languages. The problem of this approach is that it prevents conducting traditional object-oriented programming which is plagued of mutation everywhere. In the next subsection we discuss a hybrid approach where we enforce immutability on certain points in our data model to simplify our data storage model, and to also retain the convenience of mutable object state oriented programming for data manipulation.

Mixing Mutability and Immutability

An Apparent Contradiction. Since several concurrency issues are solved by having immutable data, then it becomes desirable to enforce it as a property on the stored, transmitted and replicated data. However, since we are implementing and using Pharo, a purely object-oriented programming language that is not designed to deal and ensure immutability at every moment unlike a purely functional language such as Erlang [START_REF] Hebert | Learn you some Erlang for great good!: a beginner's guide[END_REF], then the need to enforce immutability at the language level looks like an unnecessarily restrictive constraint.

Serialization as a Conversion. Fortunately, data is always manipulated in the context of a transaction. This means that we only "perform mutation" in a transient object-oriented representation of the data that is serialized for persistence at the end of the transaction. For final transmission or storage, the data has to be converted into a linear string of bits through a process of serialization. If we decide to always serialize the complete modified objects, then this serialized version of the object is by definition immutable. However, we lose this immutability property on the serialized data if we simply replace the old serialized version of the object with the new version. If instead of replacing the old version, we decide to keep both versions, and to always append data at the end of data store, then we have an immutable data persistence system. This means that there are no data races at the object persistence level because we are only storing immutable data by appending it to existing one.

Transaction Delimited Immutability. In other words, we use read operations during the context of a transaction for deserializing a snapshot of the database and converting an immutable version of an object into a mutable object that is local to the transaction context. At the end of a committed transaction, we serialize the mutable objects into an immutable representation, and we submit this representation into the data store. From the point of view of the final data store, there are only immutable operations on it. But the user sees an object-oriented interface that looks like holding convenient mutable objects.

The CAP theorem

The Brewer's CAP theorem [START_REF] Gilbert | Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services[END_REF][START_REF] Simon | Brewer's cap theorem[END_REF] is a well known result and fundamental problem in distributed computing. This theorem states that it is impossible to construct a distributed system that guarantees all of the time the following three properties:

• Consistency (C).

• Availability (A).

• Tolerance to network partitions (P). The CAP theorem also states that it is possible to construct distributed system that guarantees at most two of these properties at the same time. Under this view, it is typically said that traditional relational database management systems (RDBMS) are designed to guarantee consistency and availability through ACID transactions.

In the case of distributed systems, all of them have to actually support the P component of theorem [START_REF] Hebert | Learn you some Erlang for great good!: a beginner's guide[END_REF]. This means that a distributed system might only be able to choose providing an additional guarantee for either Consistency or Availability [START_REF] Hebert | Learn you some Erlang for great good!: a beginner's guide[END_REF]. Also, for different components of a distributed system it might be desirable to make different choices between keeping A or C [START_REF] Hebert | Learn you some Erlang for great good!: a beginner's guide[END_REF]. For example, the accounting department of a seismographic research institute needs to guarantee consistency, but its seismic data reception, storage and aggregation has to instead guarantee the availability.

ACID Transaction

ACID is the acronym with the main properties that have to be fullfilled by transactions that are used in traditional relational databases. These properties are the followings:

• Atomicity: the whole transaction cannot be divided.

• Consistency: the database only ends on a valid state at the end. • Isolation: transactions runs as if there was only a single transaction running at a time. • Durability: once the transaction is finished and committed, its result is stored in a permanent storage medium.

In terms of the CAP theorem, ACID transactions are used for guaranteeing the Consistency attribute in the database. For this reason, it is mandatory for our system to be able to support this kind of transaction. By the previous definition of transaction, the ACID properties in our system can only be violated by running multiple concurrent transactions that are either: conflicting by themselves, or the summation of both transactions invalidates an integrity constraints on an object depends on the modified objects by the transaction. With our system we can support ACID semantics by having a global synchronization mechanism that prevents conflicting transactions, and by also triggering the automatic repairing of invalidated data as a consequence of these transactions.

BASE Transaction

BASE is an alternative to the traditional ACID semantics that instead of preserving the C property of the CAP theorems preserves the Availability [START_REF] Pritchett | Base: An acid alternative[END_REF]. The objective of BASE transactions is to preserve the Availability guarantee by sacrificing the Consistency property from the CAP triangle. The definition of the BASE acronym is the following:

• Basically Available: the A part of the CAP theorem.

• Soft state: lack of consistency guarantees.

• Eventual consistency.

Eventual consistency means that after some time, the data on these systems converges into a stable value, and reads will always produce the same value [START_REF] Vogels | Eventually consistent[END_REF]. One mechanism to guarantee eventual consistency is by merging the updates performed by two conflicting transactions [START_REF] Shapiro | Conflict-free replicated data types[END_REF] [START_REF] Hebert | Learn you some Erlang for great good!: a beginner's guide[END_REF]. However, there are some requirements on how this merge operation has to be defined to achieve eventual consistency [START_REF] Shapiro | Conflict-free replicated data types[END_REF]. It has been shown that simple and trivial case that always achieves eventual consistency is when the merge operation is commutative [START_REF] Shapiro | Conflict-free replicated data types[END_REF].

In our current infrastructure, we still have not decided on a proper way to model and provide support for these highavailability distribution scenarios where BASE semantics are required. However, the ability of being able to structure data in terms of historical versioned immutable structured provides a simple degradated conflict resolution mechanism. This mechanism is to represent the latest version of the conflicting objects as a set that contains the versions that have a conflict. With this strategy no data is ever lost, but the conflict has to be solved explicitly by a new transaction, which could in the worst case be manually initiated merge procedure by a human individual. This conflict resolution mechanism is exactly the same mechanism that is used by software versioning control systems such as Git to solve conflicts.

Consensus reaching algorithm

Reaching consensus is a fundamental problem on any distributed system. The ability to reach consensus is crucial for guaranteeing correctness on the data that is computed by a distributed. Unfortunately, there are several known instances where it has been proven the impossibility of reaching consensus [START_REF] Michael | Easy impossibility proofs for distributed consensus problems[END_REF]. This implies that the design decisions that we make for constructing our smart data storage and processing system has to be aware of the existence of these impossibilities. This also implies that measures have to be taken for detecting and mitigating these situations where a consensus cannot be reached. In the cases where consensus can be reached, the implementation should provide mechanism to reach it by using existent algorithm [START_REF] Cortés | Distributed algorithms for reaching consensus on general functions[END_REF]. This problem can only be ignored in the cases where there is zero data distribution replication that is meant to improve fault tolerance.

Smart Data System Design

Layered Architecture. To facilitate the design, and to enforce separation of concerns of the different aspects of our problem, we decided to construct our smart data storage and processing system in terms of three layered processes: physical data representation, transaction context processing, and domain specific modeling and processes.

Physical Data Representation

Key-Value store for Physical Persistence. In the lowest level we eventually need to persist the serialized bits of objects in a persistent data store. As a simple and standard solution to this problem we decided to use a key-value store [START_REF] Han | Survey on NoSQL database[END_REF] for our lowest level persistence layer. In abstract terms, it means that we have a single large dictionary whose key is an ID for retrieving a specific instance of a serialized object. A key-value store offers the advantage of being easy to implement in a transient and in-image memory only by using a single Dictionary instance, and a single 𝑆𝑒𝑚𝑎𝑝ℎ𝑜𝑟𝑒 for mutual exclusion and ensuring atomic read and writes of serialized object data. Having this abstraction also allows one to use different backends, such as:

• Use an existent RDBMS such as MySQL [START_REF] Ab Mysql | MySQL[END_REF] only for final disk persistence. A relational database with a single table of two columns is enough for this purpose. This takes advantage of the existent database optimizations for storing data on disk in an efficient and safe way. • Use another document based, NoSQL [START_REF] Han | Survey on NoSQL database[END_REF] database such as MongoDB [START_REF]Mongodb[END_REF]. These NoSQL databases are typically designed around this very same abstraction of a key-value data store [START_REF] Han | Survey on NoSQL database[END_REF]. Since many of these existent databases already have support for data replication [START_REF] Han | Survey on NoSQL database[END_REF], their usage might also help on this aspect, but we still need to implement an additional layer of synchronization if we want to enforce ACID constraints in some transactions.

Document Based Data Encoding. A good definition for a document database is the following one given by Han et al.:

"Document database and Key-value is very similar in structure, but the Value of document database is semantic, and is stored in JSON or XML format. " [START_REF] Xie | Salt: Combining {ACID} and {BASE} in a Distributed Database[END_REF] This means that databases of this kind such as MongoDB [START_REF]Mongodb[END_REF] can be used for storing data structured in terms of a document object model (DOM). The JSON structure for text based object serialization tends to be preferred over XML for reasons of simplicity, and better performance due to shorter documents [START_REF] Maeda | Performance evaluation of object serialization libraries in XML, JSON and binary formats[END_REF]. JSON is a text format, but there are several binary formats that are compatible with JSON, faster to parse, and directly supported by databases such as BSON [START_REF]BSON (Binary JSON): Specification[END_REF] and MessagePack [START_REF] Furuhashi | MessagePack[END_REF]. The existence of these compact and binary alternatives that follow the exact same model of JSON means that using this same model for structuring and serializing objects is a safe design decision.

A JSON document is composed of a single dictionary object. An object in JSON can have one of the following recursively defined structure:

• An atomic literal value: Numbers Strings Boolean values Nil.

• An array of objects.

• A dictionary of objects. Keys are always strings, but values can be any kind of object, including other dictionaries and arrays. The subset of JSON objects composed by atomic literal values and arrays can be concisely expressed in Pharo syntax in terms literal arrays through the #(12(𝑡𝑟𝑢𝑒 𝑓 𝑎𝑙𝑠𝑒) syntax, and in terms of array construction with the {1.2.{𝑡𝑟𝑢𝑒.𝑓 𝑎𝑙𝑠𝑒}} syntax. Unfortunately, in Pharo we do not have a special syntax for defining dictionaries. However, a simple and concise way to specify a dictionary in Pharo is to use successive pairs of keys and values. These arrays of key-value pairs can be passed to the Dictionary newFromPairs: method for constructing objects. For this reason, and to facilitate writing unit tests of our object serialization process, we decided to implement our serialization process in terms of these arrays, but in our deserialization process we are in fact converting them into dictionaries to relax the requirement of having the same order on the encoded fields all of the time.

Another advantage of encoding the serialized data in terms of these document formats, is that they also allow generating a canonical encoded bitstream of the serialized data. This canonical encoding is a deterministic definition on how to encode the data to obtain always the same result. Having a canonical encoding form is crucial for applying cryptographical algorithms for guaranteeing bit-level data integrity and authentication.

The Problem of Nominative IDs. One important observation is that is not enough to just store directly serialized objects into the data store. If we store a serialized graph of inter-dependent objects directly by using the nominative ID (i.e., the name) of each object in the graph as the keys in the key-value store, then it becomes impossible to modify a single object without having to simultaneously re-validate and modify all of the objects that depend on it. In other words, by associating directly the name of the objects with its content we lost any possibility of having an immutable and an append only store of serialized objects. We solve this problem by using versioned object ID. We define a versioned ID as an ordered pair composed of the nominative object ID, and a version ID number. During serialization of object graphs, we replace object references by a reference into a specific version of the object. However, it its still desirable being able to obtain the latest version of an object from just its ID. It is also a desirable property to be able to navigate the whole history of a stored object. We achieve such properties by keeping a single separate mutable mapping from an object nominative ID into its last versioned ID. In addition each serialized versioned object has a reference to its previous version. This means that different versions of an object maintain a linked-list data structure that allows support for arbitrary navigation on the history of an object.

Atomic Values, Entities and Roles. We define three different kinds of objects that need to be manipulated and persisted through our smart data storage and processing system: atomic values, entities and roles. Atomic values. We define as an atomic value any objects whose individual internal components are not separately versioned and traced for origins. These are the indivisible units of data such as a number, a string, a boolean, a date, or even some aggregate objects such as street address. Versioning and origin traceability of atomic values is conducted on the whole value itself. The only requirements on atomic values is being able to serialize-deserialize them, and to evaluate their integrity constraints. Entities. Entities are objects which have complete historical versioning and traceability of origins. Unlike atomic values, the individual components of an entity are also versioned and traced. For this reason, we define the internal persisted state of an entity as a composition of different atomic values. For reasons of convenience, we define the different components of an entity by using slots [START_REF] Verwaest | Flexible object layouts: enabling lightweight language extensions by intercepting slot access[END_REF]. The usage of these slots has the following purposes:

• Replace the persisted variables by value holders that intercept reads and writes. These are used for tracing modified objects, and automatically tagging the modified data with its new origin. By replacing the slots with a value holder, each read and write into it becomes a message send. The origin of the values only change when the write message is received. On the processing of a slot write message, the data originator in the value holder is compared with the data originator of the current transaction context. If the data originators do not match, then the originator of the value holder is changed into the new one, and the object version id is updated to be the current in memory version. The interception of reads is used to implement lazy deserialization of referenced objects, which allows to avoid reading and deserializing the whole object graph from the data store. • Make explicit the database schema, and the types of the stored object. Typing allows enforcing the type checking integrity constraints. • Provide automatic serialization and deserialization of objects. Each slot knows its type, and each type knows how to serialize and deserialize its data. Roles. We define as a role as any object that can act as a data originator 1 . Many domain specific roles are also entities, and we call them role-entities. But they are some special roles such as the super-user administrator that is required for creating the initial roles in a data store that we are not modeling as entities. For this reason, we construct an object that we call concrete role that represents the act of exercising a role. We mandate the presence of a concrete role for being able to actually initiate a transaction, and we use these concrete roles for actually tagging the origin of a transaction.

Transaction Processing

Transaction Life-Cycle. The life-cycle of a transaction is composed of three parts: the beginning of the transaction, a sequence of read-modify-write operations in the transaction context, and the end of a commit or an abortion that originates a rollback. Listing 1 shows an example of how a transaction looks like in our system.

We represent the sequence of read-modify-write operations in as just a standard Pharo block. We also mandate the requirement of having a specific concrete role for starting a transaction. This concrete role represents the origin of the transaction which allows enforcing traceability of origins.

The withRole:doTransactionWith: method takes care of all of the transaction management required book-keeping. The most important action of this method is to store the 1 We might have just call them data originator, but we think that the term role is more adequate since it can be seen as an analog to a real world individual that is full-filing a specific social role. In a future version we may replace the concrete role term with the data originator term. Listing 1. Example code of a transaction active transaction context in a process local variable. This active transaction context is used by the automatic data originator tagging machinery through the interception of value writes as described in the previous section. This interception of writes is also used for compiling a list of objects that need to be serialized and written to the data store at the end of the transaction (i.e., constructing the transaction log) Another important usage of this transaction context is on the implementation of automatic object reads and deserialization on-demand through the interception of reads.

We implement the explicit transaction commit and abort operations as the signaling of specific exceptions. The exceptions that are raised during a transaction block are all caught. If the caught exception is an explicit commit signal, then the modified objects during the transaction are serialized and submitted for persistence into the data store. All of the other cases generate a transaction rollback operation, which in the current implementation version is implemented by simply ignoring the modified objects.

Domain Specific Modeling

Once having these basic building blocks, the next step is to actually model domain specific data and processes that are actually required by a specific application. These objects can be modeled by creating additional definitions of entities, roles, and in some cases, even new atomic value types. In our implementation, such definitions can be created by just defining new subclasses. We present a concrete example of this in Section 7.

Heart Rate Monitoring Demo

With our smart data storage and processing system we constructed for testing it a simplistic scenario. This scenario is composed of three different actors:

1. A heart rate sensor that monitors a patient in real time. 2. The family member of the patient that want to know on whether he is still alive. 3. A medic that needs to check once per week the heart rate of the patient.

Non-distributed Implementation. For reasons of simplicity, we implemented this scenario in terms of three concurrent processes running inside a single image. In other words, our current demo is not distributed, but it still has all of the transaction, object serialization, and traceability of origin, and automatic object history versioning support capabilities.

For this demo we are using a single transient in-memory data store that is implemented through the combination of some Pharo dictionaries and semaphores for mutual exclusion.

Data model. In this scenario, we have the following four different role-entities: The main objective in this scenario is to collect a set of heart-rate samples. This means that we also need to define how a heart-rate sample looks like. Since each one of these samples is an atomic object by itself, then it makes sense to model it as an aggregate object with two fields: the timestamp of when the sample is measured, and the number of beats per minute measured at that time. Listing 6 shows the use of the class SMDCompositeValue to define this composite value object. immediately perform a transaction for transmitting the samples into the data store. The main problem of this simplistic approach is performance because of two important sources of overhead: the overhead of setting up a transaction, and the overhead of establishing a network connection in the case of network distribution. In addition to this problem, samples may need to pass through electronic and digital filters to actually recover the heart beat sensing data. For this reason, it is desired to accumulate batches of samples during several seconds, or even minutes and then perform a transaction to submit the complete batch of samples. The objective of this batching process is to reduce the frequency of transmission from the order of milliseconds which might be even less than the actual latency of the network, to an order of magnitude that is greater to the normal latency of the network. One important objective of this is to avoid flooding the excessive TCP control packet, which might even have a catastrophic effect on the data transmission infrastructure. In this demo, instead of using an actual heart rate sensor, we are fabricating a procedural signal through the combination of mathematical sine functions, and we are adding noise through the usage of a random number generator. Each time we have a large enough batch of samples to send, our sensor process performs a transaction for storing the new samples in the batch. See Listing 9 for the method that performs this batch submission transaction. Listing 9. Heart rate batch transmission transaction.

Liveness Monitor Implementation. The patient liveness polling monitoring UI is implemented as a morph that performs periodical polling on the data store with a period of 500𝑚𝑠. This polling is implemented through the automatic stepping facilities of Morphic by overriding the step method (See Listing 10). Once a new status state is received, then this UI morph is redrawn and a color the last bpm is displayed on it. Since this transaction is only used for reading data, it is never committed to ensure that the stored data is not changed. When there is no explicit commit during the transaction, the transaction is aborted by default. The explicit transaction abort in Listing 10 is used with the objective of avoiding an error when sending the last message to the empty collection of samples.

Medic Heart Monitoring Dashboard. The UI for the medic that needs to periodically check its patient is simply a window with a single button. The action associated to the button in this window takes care of initiating the transaction for

Limitations

The lack of Actors. The main limitation in our prototype for our data storage and processing model is the lack of a way for defining Actors. We identify the need for at least two different kind of actors:

1. Autonomous actors that decide when and how to interact with the data storage model. 2. Data dependent actors, whose life cycle and operations are triggered by a condition met due to data changed in a transaction. In our heart rate scenario we are only implementing actors of the first kind in a completely ad-hoc way. Making a proper API for streamlining the actor implementation of this kind should not be complicated in Pharo. The interesting problem is actually how to model actors of the second kind, and how to implement and manage their lifecycle. It may even be desirable to automatically spawn these actors on a separate node to the one that handled the transaction that required spawning this actor.

Permissions and Authorizations. In our current implementation, we are using concrete roles for modeling data origins. The problem with this mechanism is that we still need a proper way to define per-object access control constraints and related permissions. One option for doing this is to associate additional predicates for asking about permitted actions on objects for a concrete role. There is also the problem on validating on whether a concrete role does actually have the permissions for doing a certain operations. We think that for this authorization validation problem that association of a one-time use cryptographical token to a concrete role might help.

Threats to Validity

Single Scenario Tested. The main threat of validity for our approach of implementing this smart data storage and processing infrastructure is that we have only tested it in a single highly artificial and controlled test scenario. We still have to validate our system with at least real world data, and at least try to attempt to simulate usage scenarios that are much closer to real world usage. Real world usage scenarios involve network partitions that force changes on the topology of distribution, nodes that fail and are resurrected for multiple reasons in a completely random and uncontrolled way.

Implementing Revocability. Another important problem is that we still need to address the issue of data revocation, and specially the issue of of having to destroy data for reasons such as enforcing the privacy of individual. We also want to be able to implement this support for data revocation and removal in a way that does not destroy the advantages of having an append-only storage of immutable data.

Related work

Git. Git is a content addressable distributed database that is normally used through a version control system user interface. The data storage model used by the Git database is similar and a source of inspiration to our data storage model. This distributed database aspect of Git is very well hidden through this interface to be point that most users know Git only as a distributed version control system. Internally, Git is implemented as set of objects where a cryptographic hash of any stored object can be used as a key for actually retrieving the object. The usage of cryptographic hashes as keys is what makes Git content addressable database. Directories in Git are represented as list with the hashes of the files and subdirectories that are contained in it. A commit is simply a tuple with hashes to the new root directory, the parent commits, and the commit message. Branches and tags are pointers to specific commits, which means that in practice they are labels for the hashes of commits.

Blockchain. The blockchain is a completely distributed and decentralized data base that was designed originally as a mechanism for implementing the virtual currency of Bitcoin [START_REF] Xu | A Taxonomy of Blockchain-Based Systems for Architecture Design[END_REF]. The blockchain is built upon a decentralized tree of cryptographic hashes that are replicated among all of the nodes running on a blockchain [START_REF] Hari | The Internet Blockchain: A Distributed, Tamper-Resistant Transaction Framework for the Internet[END_REF]. All nodes execute all transactions in a completely deterministic way, so that all nodes can be verify the validity of the transactions. The blockchain is also based around the concept of having an append-only store of transactions, and this is also one of our sources of inspiration on reusing this concept for our system.

Mnesia. The Erlang purely functional and actor based programming language comes by default with Mnesia. Mnesia is a distributed relational database that can store any Erlang object [START_REF] Hebert | Learn you some Erlang for great good!: a beginner's guide[END_REF]. Transactions in Mnesia are represented as Erlang functions, and queries are typically encoded as tuples that are generated via a macro transformation of an Erlang function that encodes a boolean predicate function. We took inspiration on Mnesia for the idea of representing transactions as blocks in our smart data prototype.

Conclusions and Future Work

In this paper we discussed the main requirements, theoretical problems, and an architecture that seems to solve many of these problems for the construction of a smart data storage and distribution system. We started by establishing the requirements on having a system for storing and processing data with complete traceability of origins, support for integrity validation, and capability of revocating data. We also mention that any real world implementation of these systems have to be prepared and designed to support concurrency and distributed computing, due to the very nature of how this data is typically produced and consumed. For these reasons we also discuss several important well-known issues in the field of distributed computing, and distributed data bases that at least need to be taken into account.

To mitigate the risks associated to implement this system, and to also facilitate the support for the properties of traceability of origin, and integrity verification, we decided to construct a model where data that is transmitted during transactions is completely immutable, and the database only stores new data in append-only mode. To keep the convenience of mutable state object oriented programming, we keep ephemeral mutable copies of the deserialized objects during the context of preparing and computing the bulk of a new transaction. But we serialize these objects back into immutable copies that are stored in append-only fashion at the end of a transaction.

After the description of this data model we presented a demo for our prototype implementation for this smart data storage and processing system. This demo presents promising results in terms of being able to express complex data storage and processing infrastructure in a concise way by using Pharo classes. In the future we will expand this very same demo by first modeling actors in a proper way, having much more complexity in terms of the data processing and distribution topologies. We also think that is crucial to add properly the concepts of actors, and actors that are triggered by data model changes into our framework. We think that by properly modeling actors, we might be able to remove the explicit data storage polling that is used in our demo by a much more efficient event subscription model.

  dataStore withRole: hospitalService doTransactionWith: [ :transaction | patient := SMDPatient createWithID: 'Patient1'. patient names: 'John'; surnames: 'Doe'; birthDate: (Date year: 2000 month: 1 day: 1); address: '25 av marechal foch'. transaction commit. ].

Figure 1 .

 1 Figure 1. Screenshot of the heart rate monitoring demo.

  1. The patient who is also an individual. See Listing 2. 2. The medic that treats the patient. The medic is an individual. See Listing 3. 3. An individual who is a family member of the patient. See Listing 4. 4. The heart rate sensor itself. See Listing 5. Definition for the heart rate sensor entity

	SMDIndividual subclass: #SMDPatient
	slots: {
	#medics => SMDMedic set .
	#heartRateSamples => SMDHeartRateSample set }
	Listing 2. Definition for the patient entity
	SMDIndividual subclass: #SMDMedic
	slots: { #patients => SMDPatient set }
	Listing 3. Definition for the medic entity
	SMDRoleEntity subclass: #SMDIndividual
	slots: {
	#names => SMDStringType .
	#surnames => SMDStringType }
	Listing 4. Definition for the individual entity
	SMDRoleEntity subclass: #SMDHeartRateSensor
	slots: { #patient => SMDPatient }
	Listing 5.

  Listing 10. Liveness state polling transaction. querying the samples. In our current version, we are simply reading the whole data set because we have not yet implemented additional indices that are required for optimally restricting the query into a specific range of dates. See Listing 11 for the query that is used for retrieving this data. For the final plot of the data we are simply using Roassal 3[1], a data visualization framework. Heart rate data query by the medic.

	step
	| newStatus samples |
	newStatus := nil.
	dataStore withRole: role doTransactionWith: [ :
	transaction |
	samples := patient lastVersion heartRateSamples.
	samples ifEmpty: [ transaction abort ].
	newStatus := samples last.
	].
	newStatus ~= currentStatus ifTrue: [
	currentStatus := newStatus.
	self changed.
	].
	fetchDataSet
	| result |
	result := #().
	self dataStore
	withRole: self medicRole
	doTransactionWith: [ :trans |
	| medic patient |
	medic := self medicRole lastVersion.
	medic patients ifEmpty: [ trans abort ].
	patient := medic patients first lastVersion.
	result := patient heartRateSamples value
	collect: #yourself.
	].
	^result
	Listing 11.

SMDCompositeValue subclass: #SMDHeartRateSample slots: { #timestamp => SMDDateAndTimeType . #beatsPerMinute => SMDFloatType }

Listing 6. Definition for a heart rate sample Data Store Creation and Initialization. At the beginning of this demo, it is required to define the set up of the database by creating actual instances of these roles, and connect them in the context of a transaction. For this demo, the code required for creating the data store, and performing this initialization is given in Listing 7.

Listing 7. Data store creation and population

Spawning the Actors. Once the data store is initialized, the next step consists on actually spawning the different actors that need to interact as shown in Listing 8.

Unfortunately, currently we have not yet defined a proper framework for actors that have to interact with one of our data stores. For this reason, we are currently using the term actor as a completely ad-hoc definition for any distributed process that performs transactions. We are calling them actors in analogy to the actors of a theater play. In Section 8 we discuss the limitations of this ad-hoc approach.

Sensor Implementation. The heart rate monitoring sensor actor is the physical sensor that takes care of actually sampling the patient heart beat. A simplistic implementation for this sensing process could be to read a sample, and then


Yujia Liu

Julien Berges

Fouad Yassir Zaid

Ouazzani Chahdi

Arie Van Der Lee

Dominique Harakat

Eric Clot

Florian Jaroschik

Marc Taillefer

Julien Bergès

Fouad Ouazzani Chahdi

Arie Van

Der Lee

Aerobic and Ligand-Free Manganese-Catalyzed Homocoupling of Arenes or Aryl Halides via in Situ Formation of Aryllithiums

Keywords:

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

ABSTRACT: Ligand-free manganese-catalyzed homocoupling of arenes or aryl halides can be carried out under aerobic conditions via the in situ formation of the corresponding aryllithiums. A wide range of biaryls and derivatives has been obtained and a mechanism involving monomeric manganese-oxo complexes has been proposed on the basis of DFT calculations.

Manganese, a cheap, abundant and non-toxic transition metal, is an excellent alternative to precious metals for homogeneous catalysis and an ever increasing number of methods allowing the manganese catalyzed C-H, C-O, C-N, C-X or C-C bond formation has been reported over the last five years. 1 Among them, in a strive towards more sustainable processes, several reactions involving the combination of catalytic amounts of Mn salts and ambient air have been successfully developed, such as the hydroxyazidation of olefins, 2 the oxytrifluoromethylation of styrene derivatives, [START_REF] Yang | Manganese-Catalyzed Aerobic Oxytrifluoromethylation of Styrene Derivatives Using CF3SO2Na as the Trifluoromethyl Source[END_REF] the cyclization of unsaturated oximes [START_REF] Yamamoto | Manganese-Promoted Oxidative Cyclization of Unsaturated Oximes Using Molecular Oxygen in Air under Ambient Conditions[END_REF] or the coupling of Grignard reagents. 5 Mn-dioxygen complexes are also under strong investigation due to their role in biological photosynthetic processes. 6 In this context we wondered whether air-sensitive aryllithium reagents could be employed under MnCl 2 /O 2 conditions in order to provide a highly versatile and green entry to biaryls. The latter are found in numerous natural products, biologically active compounds, agrochemicals, commercial dyes, organic conductors and semi-conductors. [START_REF] Sévignon | Aryl-Aryl Bond Formation One Century after the Discovery of the Ullmann Reaction[END_REF] Biaryls are usually obtained via transition metal catalyzed coupling reactions employing organometallic compounds [START_REF] Sévignon | Aryl-Aryl Bond Formation One Century after the Discovery of the Ullmann Reaction[END_REF] including in some cases organolithium derivates. 8 In this field the most recent work dedicated to the synthesis of symmetrical biaryls has been reported with a catalytic system combining an aryl halide, tert-butyllithium and palladium associated with carbene type ligands. 8k We herein present our preliminary results on the ligand-free MnCl 2 /O 2 catalyzed homocoupling of aryllithium derivatives in-situ generated from aryl halides or via activation of aromatic C-H bonds. The mechanism of this system, less costly and more favourable for toxicity issues than the methods based on palladium, has been investigated by ESI-MS and DFT calculations.

For the preliminary trials iodobenzene (X = I) and a simple and readily available manganese salt (MnCl 2 : purity 99,998 %) were chosen as the model substrate and precatalyst, respectively (Figure 1). After addition of THF, the temperature of the mixture, first maintained at -78 °C for the generation under argon of the phenyllithium with t-BuLi (step a), was then increased up to 25 °C and the reaction medium was stirred under argon for 1 hour (step b). Under these conditions, the expected biphenyl 1 was obtained but only with a 20 % yield. The presence of one equivalent of a potential ligand (1,10phenanthroline), or of a neutral Lewis base (TMEDA or trimethylamine) did not improve the system (see the Table S1 in SI). A very significant enhancement of the yield for 1 (85 %) was obtained when argon was exchanged by dioxygen (O 2 ) once the mixture reached 25 °C (step b). Finally, when step b was performed under atmospheric, dry air, we were pleased to observe the almost quantitative formation of biphenyl (99 %) and this was also the case starting from the less reactive bro-mobenzene (X = Br: 91%). Remarkably, a good yield in biphenyl 1 (75 %) was achieved from the even more challenging chlorobenzene (X = Cl) (Figure 1). Solutions of s-BuLi or n-BuLi also provided biphenyl 1 in good yields but this was not the case with the other manganese salts we tested (see the Table S1 and Figure S1 in SI). Finally, complete absence of 1 was observed when blank experiments were carried out without manganese.

We next studied the substrate scope applying the optimized reaction conditions to various substrates with both electrondonating (EDG) and electron-withdrawing (EWG) groups on the aromatic ring (Table 1). With bromotolyl and bromoanisyl derivatives, the reaction was successfully performed to give the expected products 2-7 with good to excellent yields wherever the substituents (-Me and -OMe) were located (ortho-, meta-, para-position). A high yield (78%) was obtained with tert-butyl in the para position to generate 4,4'-di-tert-butyl-1,1'-biphenyl 8 which is a direct precursor of Freeman's reagent [START_REF] Freeman | Alkyllithium reagents from alkyl halides and lithium radical anions[END_REF] and we succeeded in scaling up to 10 mmol without decreasing the output. N4,N4,N4 ',N4'-tetramethyl-[1,1'-biphenyl]-4,4'-diamine 9 was also obtained almost quantitatively. We then attempted substrates with electron-withdrawing groups. Good yields were achieved from p-and m-trifluoromethyl bromobenzene (biphenyls 10, 11). When the trifluoromethyl group was in the ortho-position, only 30 % of the corresponding biaryl 12 was obtained. The reduction product and a small amount of corresponding phenol derivate were then also observed. Starting from the iodide derivative, for which the lithium-halide exchange rate is higher than the bromide derivative, 10 led to an increase in the yields of 12 to 50 %. Two heteroaryl halides were successfully transformed to 2,2'-bipyridine and 1,1'biisoquinoline (13, 14), which are well known as ligands for transition metal complexes. 11 We then carried out the homocoupling reactions with larger substrates such as 2-bromo-1,1'-biphenyl, 1-bromonaphtalene and 2-bromonaphtalene and excellent yields were acquired (15, 16, 17). These products are common material precursors and are used to synthesize large size polycyclic aromatic compounds. 12 In addition, the reaction works well for benzyl bromide leading to 1,2-diphenyl ethane 18. This offers an alternative approach to the known methods [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] for the synthesis of 9,10-dihydrophenanthrene 19, which we obtained via the double dimerization of 1-bromo-2-(bromomethyl)benzene. To extend again the application field of the method, we also performed some tests on polyhalobenzenes. The latter are promising substrates, as the resulting biaryls can be readily further functionalised. Starting from the p-chloroiodobenzene and m-chlorobromobenzene, fair to good yields of expected 4,4'-and 3,3'-dichlorobiphenyl (20, 63 %; 21, 45 %) were obtained. With the o-chlorobromo analogue we did not observe any homocoupling product but instead the polycyclic aromatic triphenylene 22 was obtained in 91 %. As triphenylene derivatives are attractive compounds in supramolecular and material fields, 14 we then tested a methylsubstituted o-chlorobromobenzene and the corresponding two triphenylene isomers (23a and 23b) were obtained with a 80 % yield and ratio 1/3. 23b was recrystallized and its X-ray structure showed that the molecules are essentially planar and stacked in layers parallel to the plane (see Figures S2,S3 in SI). Within these planes they are arranged in chains connected by very weak van der Waals interactions between methyl moieties (Figure S4). In further substrate scope studies, we succeeded in applying the catalytic system to acetylene or arene derivatives possessing an activated C-H bond (Table 2). We have thus performed the homocoupling reactions of phenylacetylene and of 1methyl-1H-benzo [d]imidazole to give 1,4-diphenylbuta-1,3diyne 24 and 1,1'-dimethyl-1H,1'H-2,2'-bibenzo [d]imidazole 25, respectively, in very good yield. Starting from Nmethylpyrrole, only poor yield of corresponding product 26 was obtained. However 2,2'-dimethoxy-1,1'-biphenyl 7 was synthesized directly from anisole via directed ortho metalation. [START_REF] Snieckus | Directed ortho metalation. Tertiary amide and O-carbamate directors in synthetic strategies for polysubstituted aromatics[END_REF] It is worth noting that from trifluoromethylbenzene, for which the strong electron-withdrawing inductive effect of CF 3 promotes the formation of ortho-lithiated intermediate, 2,2'ditrifluoromethyl-1,1'-biphenyl 12 was obtained in higher yields than starting from arylhalides. [START_REF] Garden | Donor-Activated Lithiation and Sodiation of Trifluoromethylbenzene: Structural, Spectroscopic, and Theoretical Insights[END_REF] Interestingly, biferrocene 27, investigated in the field of molecular electronics 17 and usually gained through the use of haloferrocenes via an Ullmann coupling reaction, 18 was synthesized using this catalytic system via C-H activation on the cyclopentadienyl ring.

To interpret the role of dioxygen, a key factor for the efficiency of this system in the homocoupling reactions, we monitored the reaction by electrospray ionization mass spectrometry (ESI-MS). Various aryl halides were tested and in order to detect more easily the potential formation of metal intermediates, a stoichiometric amount of MnCl 2 (50 mol%) was used. After exposure of the reaction mixture to air, the most interpretable spectrum was obtained when 1-chloro-4-iodobenzene was used as substrate due to the existence of isotopes of chlorine atom, which facilitates the identification of the intermediate compounds. In this case a peak at m/z = 624.8309 corresponding to an empirical formula C 24 H 16 Cl 4 Mn 2 O 2 K was observed (Figure 2). It is worth noting that the experimental spectrum matches well with the theoretical one. The formula of this compound, that we could not detect under Mn-catalytic conditions, corresponds to either a bis(μ-oxo) manganese (IV) dimer A, or a μ-η 2 :η 2 -peroxo manganese (III) dimer A', or a μ-1,2-peroxo manganese (III) dimer A" (Figure 2). If the existence of a structure as dimer A' has not been proven yet, the related dimers A and A" have been already described with polydentate thiolate and nitrogen ligands. 6 DFT(PBE-D3) calculations were then carried out on the dimer to elucidate the nature of the bonding pattern. 19 Despite many attempts, no linear structure such as A" could be located on the potential energy surface. A symmetric structure, Dimer-1, similar to structure A, could be optimized as a singlet. The four Mn-O bond distances are identical (1.745 Å) and there is no significant bonding interaction between the two oxygen atoms (O…O = 2.560 Å)(see Figure S5 in the SI). A triplet geometry, Dimer-2, was located at ΔG = -6.4 kcal mol -1 with respect to Dimer-1. In the distorted triplet, the O…O distance is still too long (2.670 Å) to invoke any bonding interaction. The spin density (Figure S6 in the SI) is evenly shared between the two Mn atoms (1.077), and Dimer-2 can be described as an oxo-bridged Mn IV -Mn IV dimer. Another triplet structure, Dimer-3, could be optimized at ΔG = -23.3 kcal mol -1 with respect to Dimer-1. This structure presents two different Mn centers, with one having two long Mn-O bond distances (2.028 Å) and the other having two short Mn-O bond distances (1.662 Å). The O…O distance is still too long (2.592 Å) to invoke any bonding interaction. The spin density (Figure S6) is not evenly shared between the two Mn atoms (4.076 vs.

-1.621) and Dimer-3 is best described as a Mn II / Mn VI dimer. The DFT calculations are thus indicating that the dimer observed in the ESI-MS experiment is most likely a formally Mn II / Mn VI structure without any direct O…O nor Mn…Mn interaction. However, attempts to locate transition state structures associated to C-C bond formation on any of the Mn centers in Dimer-3 failed. Therefore calculations could not support that such dimeric structure is a competent catalyst for the biaryl formation. Scheme 1. Proposed mechanism for biaryl formation as deduced from the DFT calculations.

DFT calculations were then carried out to probe the mechanistic hypothesis depicted in Scheme 1 based on the involvement of Mn monomeric species. In situ generated aryllithium would first react with MnCl 2 salt probably coordinated with the solvent (S = THF) to generate a catalytic amount of diarylmanganese(II) C intermediate. 20 From C, a transition state structure, TS-C, associated to C-C bond formation could be located with an activation barrier of ΔG # = 34.8 kcal mol -1 . This transformation is only slightly exergonic (ΔG = -1 kcal mol -1 ) and the product of the reaction, P-C, is a complex between the biaryl 13 and a Mn(0) fragment (Mn(THF) value of the activation barrier is not compatible with a reaction time of 1 hour at room temperature. This is in perfect agreement with the lack of catalytic activity under inert atmosphere. However, DFT showed a more favourable route for which the oxidation of C in the presence of dioxygen leads to the exergonic (ΔG = -42.6 kcal mol -1 ) formation of a η 2 -oxo manganese (IV) intermediate D. 5 The activation barrier for C-C bond formation through TS-D on this oxidized manganese complex is significantly reduced with ΔG # = 10.0 kcal mol -1 . The transformation is exergonic (ΔG = -12.6 kcal mol -1 ) and the product E is a π-complex of the biaryl 13 on the Mn(II) oxo complex Mn(O 2 )(THF) 2 . In the presence of two equivalents of aryl lithium, the biaryl would be expelled and the catalytic species C regenerated, releasing the lithium peroxide (Li 2 O 2 ). The dimer observed in the ESI-MS experiment under non-catalytic conditions could be the result of an O-O oxidative addition in D stabilized by interaction with C resulting in the Mn(II)/Mn(IV) dimer.

In conclusion, we have disclosed original conditions for the synthesis of a wide range of symmetrical biaryls and derivatives such as biferrocene, 9,10-dihydrophenanthrene or even triphenylene derivatives. These molecules are obtained by using a ligand-free manganese catalytic system allowing the homocoupling of arenes (C-H activation) or aryl halides (C-X activation), via the intermediate formation of aryllithiums derivatives. The experiments together with the DFT calculations highlight the crucial role of dioxygen in the catalytic process. A mechanistic hypothesis based on the involvement of Mn monomeric species and on a Mn(II)/Mn(IV) sequence has been proposed. Work is in progress in our laboratory to further extend the application field of the system and to gain a deeper understanding of the mechanism.

EXPERIMENTAL SECTION

General Information. All reactions were performed in flame-dried Schlenk flasks under an atmosphere of argon. THF was distilled from sodium/benzophenone, stored on 4 Å activated molecular sieves under an argon atmosphere. MnCl 2 (99.998%) was purchased from Sigma-Aldrich ® , stored in a Schlenk flask under an atmosphere of argon. All other reagents were purchased from Sigma-Aldrich ® , Alfa Aesar ® or Acros ® and used as received, without further purification. All reagents were weighed in the air. 1 H, [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C and 19 F NMR spectra were recorded on a Bruker AC 400 MHz spectrometer in CDCl 3 . For 1 H NMR (400 MHz), CHCl 3 and TMS served as internal standards ( = 7.27 and 0 ppm) and data are reported as follows: chemical shift (in ppm), multiplicity (s = singlet, br s = broad singlet, d = doublet, t = triplet, m = multiplet), coupling constant (in Hz), and integration. For 13 C NMR (101 MHz), CHCl 3 was used as internal standard ( = 77.2 ppm) and spectra were obtained with complete proton decoupling. High-resolution mass spectra (HRMS) were recorded on an Agilent 6210 ESI TOF (time of flight) mass spectrometer or on a JEOL JMS-DX300 mass spectrometer (3 keV, xenon) in an m-nitrobenzylalcohol matrix. For the ESI-MS mechanistic studies high resolution ESI-MS spectra were recorded on a hybrid tandem quadrupole/time-of-flight (Q-TOF) instrument, equipped with a pneumatically assisted electrospray (Z-spray) ion source (Micromass, Manchester, UK) operated in positive mode. Flash column chromatography was performed on Silicycle silica gel (230-400 mesh) or Merck Geduran Si 60 silica gel (40-63 m) and analytical thin-layer chromatography (TLC) was carried out using 250 m silica gel plates. Visualization of the developed chromatograms was performed by UV irradiation (254 nm).

General Note on Safety. Organolithium compounds are highly reactive and generally pyrophoric, the use of them thus requires great caution and proper lab bench conditions. 21 Tertbutyllithium can easily catch fire and form peroxides on exposure to air and react violently with water, so the first step of the reactions should be carried out under strict air-free and water-free conditions. 21b In our case, before exposure the reaction mixture to dry air, tert-butyllithium has already reacted with aryl halides and turned to the corresponding aryllithium compounds which are much less pyrophoric. In addition, at the end of reaction we did not observe the formation of peroxides -a test was performed before the work-up of the reaction mixture.

General procedure 1 for the synthesis of symmetrical biaryls from arylhalides. After standard cycles of evacuation and back-filling with dry and pure argon, an oven-dried Schlenk flask equipped with a magnetic stirring bar was charged with MnCl 2 (0.1 mmol, 0.1 equiv.). The flask was evacuated and back-filled with argon, then dry THF (4 mL) and aryl halide (1.0 mmol, 1.0 equiv.). Then the flask was stirred, cooled to -78 °C and t-BuLi (2.0 mmol, 2.0 equiv. 1.1 ml of a 1.9 M solution in pentane) or s-BuLi (2.0 mmol, 2.0 equiv., and 1.5 ml of a 1.3 M solution in cyclohexane/hexane -92/8) was added under a stream of argon by syringe. The reaction mixture was stirred for about 20 minutes at -78 °C and then heated to room temperature. The air was introduced when the screwed cap of flask was replaced by a guard tube filled with silica gel. The reaction mixture was stirred at room temperature for 1 hour. Then, 1, 3,5-trimethoxybenzene (16.8 mg, 0.1 mmol) was added as internal standard. The resulting mixture was diluted with Et 2 O (10mL) and washed with NH 4 Cl saturated solution (3 x 15 mL). The aqueous layer was washed with Et 2 O (3 x 10mL). The organic layer was dried over anhydrous MgSO 4 and diethyl ether was evaporated under reduced pressure (rotary evaporator). The residue was purified by column chromatography to give the desired symmetrical biaryl.

General procedure 2 for the synthesis of symmetrical biaryls via C-H activation. After standard cycles of evacuation and back-filling with dry and pure argon, an oven-dried Schlenk flask equipped with a magnetic stirring bar was charged with MnCl 2 (0.1 mmol, 0.1 equiv.). The flask was evacuated and back-filled with argon, then dry THF (4 mL) and aryl halide (1.0 mmol, 1.0 equiv.). Then the flask was stirred, cooled to -78 °C and t-BuLi (1.0 mmol, 1.0 equiv. 0.55 ml of a 1.9 M solution in pentane) was added under a stream of argon by syringe. The reaction mixture was stirred for about 20 minutes at -78 °C and then heated to room temperature. The air was introduced when the screwed cap of flask was replaced by a guard tube filled with silica gel. The reaction mixture was stirred at room temperature for 1 hour. Then, 1, 3,5-trimethoxybenzene (16.8 mg, 0.1 mmol) was added as internal standard. The resulting mixture was diluted with Et 2 O (10mL) and washed with NH 4 Cl saturated solution (3 x 15 mL). The aqueous layer was washed with Et 2 O (3 x 10mL). The organic layer was dried over anhydrous MgSO 4 and diethyl ether was evaporated under reduced pressure (rotary evaporator). The residue was purified by column chromatography to give the desired symmetrical biaryl.

1,1'-biphenyl (1). 5a Yield: 152.6 mg, 99% (X = I); 140.3 mg, 91% (X = Br); 115.7 mg, 75% (X = Cl). 1 H NMR (400 MHz, CDCl 3 ) : 7.59 (d, J = 7.1 Hz, 4H), 7.44 (t, J = 7.6 Hz, 4H), 7.34 (t, J = 7.4 Hz, 2H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 141. 4, 128.9, 127.43, 127.35. GC-MS: rt = 7.17 min, m/z = 154. Column chromatography: SiO 2 , n-Pentane 100%. 4,4'-dimethyl-1,1'-biphenyl (2). [START_REF] Moncomble | Cobalt-Catalyzed Formation of Symmetrical Biaryls and Its Mechanism[END_REF] Yield: 154.9 mg, 85% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.56 (d, J = 8.1, 4H), 7.31 (d, J=8.1, 4H), 2.46 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 138. 4, 136.9, 129.6, 127.0, 21.3. GC-MS: rt = 8.36 min, m/z = 182. Column chromatography: SiO 2 , n-Pentane 100%. 3,3'-dimethyl-1,1'-biphenyl (3). [START_REF] Moncomble | Cobalt-Catalyzed Formation of Symmetrical Biaryls and Its Mechanism[END_REF] Yield: 164.0 mg, 90% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.46-7.44 (m, 4H), 7.37 (t, J = 7.5, 2H), 7.21 (t, J = 7.5, 2H), 2.47 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 141.5, 138. 4, 128.8, 128.14, 128.08, 124.5, 21.7. GC-MS: rt = 8.24 min, m/z = 182. Column chromatography: SiO 2 , n-Pentane 100%.

2,2'-dimethyl-1,1'-biphenyl ( 4). [START_REF] Moncomble | Cobalt-Catalyzed Formation of Symmetrical Biaryls and Its Mechanism[END_REF] Yield: 127.6 mg, 70% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.28 -7.19 (m, 6H), 7.10 (d, J = 6.8 Hz, 2H), 2.06 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 141.8, 136.0, 130.0, 129.5, 127.3, 125.7, 20.0. GC-MS: rt = 7.36 min, m/z = 182. Column chromatography: SiO 2 , n-Pentane 100%. 5) [START_REF] Cahiez | Iron-Catalyzed Homo-Coupling of Simple and Functionalized Arylmagnesium Reagents[END_REF] Yield: 171.4 mg, 80% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.49 (d, J = 8.8 Hz, 4H), 6.98 (d, J = 8.8 Hz, 4H), 3.86 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 158. 9, 133.7, 127.9, 114.4, 55.5. GC-MS: rt = 9.77 min, m/z = 214. Column chromatography: SiO 2 , n-Pentane/DCM 50/50. 6) [START_REF] Cheng | Homocoupling of Arylboronic Acids Catalyzed by CuCl in Air at Room Temperature[END_REF] Yield: 203.5 mg, 95% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.40 (t, J = 7.9 Hz, 2H), 7.23 (d, J = 7.9 Hz, 2H), 7.18 (t, J = 2.4 Hz, 2H), 6.95 (dd, J = 8.2, 2.4 Hz, 2H), 3.90 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 160. 1, 142.8, 129.9, 119.8, 113.1, 112.9, 55.4 2,2'-dimethoxy-1,1'-biphenyl (7) 5a Yield: 192.8 mg, 90% (X = Br); 150.0 mg, 70% (X = H). 1 H NMR (400 MHz, CDCl 3 ) : 7.38-7.32 (m, 2H), 7.27 (dd, J = 7.5, 1,7 Hz, 2H), 7.06 -6.97 (m, 4H), 3.79 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 157. 2, 131.6, 128.8, 128.0, 120.5, 111.3, 55. 4,4'-di-tert-butyl-1,1'-biphenyl (8) [START_REF] Cheng | Homocoupling of Arylboronic Acids Catalyzed by CuCl in Air at Room Temperature[END_REF] Yield: 207.8 mg, 78% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.56 (d, J = 8.4 Hz, 4H), 7.48 (d, J = 8.4 Hz, 4H), 1.39 (s, 18H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 150.1, 138. 4, 126.9, 125.8, 34.7, 31.6. GC-MS: rt = 10.37 min, m/z = 266. Column chromatography: SiO 2 , n-Pentane 100%.

4,4'-dimethoxy-1,1'-biphenyl (

3,3'-dimethoxy-1,1'-biphenyl (

N4,N4,N4',N4'-tetramethyl-[1,1'-biphenyl]-4,4'-diamine (9) 24

Yield: 228.3 mg, 95% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.49 (d, J = 8.5 Hz, 4H), 6.83 (d, J = 8.5 Hz, 4H), 3.00 (s, 12H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 149. 4, 130.0, 127.1, 113.3, 41.0. GC-MS: rt = 11.41 4,4'-bis(trifluoromethyl)-1,1'-biphenyl (10) [START_REF] Moncomble | Cobalt-Catalyzed Formation of Symmetrical Biaryls and Its Mechanism[END_REF] Yield: 209.0 mg, 72% (X = I); 145.1 mg, 50% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.77-7.71 (m, 8H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 143.4, 130.5 (q, J = 32.7 Hz), 127.8, 126.1 (q, J = 3.7 Hz), 124.1 (q, J = 272.0 Hz). 19 F NMR (377 MHz, CDCl 3 ) : -62.56. GC-MS: rt = 7.16 min, m/z = 290. Column chromatography: SiO 2 , n-Pentane 100%.

3,3'-bis(trifluoromethyl)-1,1'-biphenyl (11) [START_REF] Moncomble | Cobalt-Catalyzed Formation of Symmetrical Biaryls and Its Mechanism[END_REF] Yield: 232.2 mg, 80% (X = I); 203.1 mg, 70% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.85 (d, J = 0.5 Hz, 2H), 7.79 (d, J = 7.7 Hz, 2H), 7.68 (d, J = 7.8 Hz, 2H), 6.61 (t, J = 7.7 Hz, 2H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 140.8, 131.7 (q, J = 32.4 Hz), 130.7, 129.7, 124.9 (q, J = 3.7 Hz), 124.23 (q, J = 272.4 Hz), 124.20 (q, J = 3.8 Hz). 19 F NMR (377 MHz, CDCl 3 ) : -62.68. GC-MS: rt = 6.94 min, m/z = 290. Column chromatography: SiO 2 , n-Pentane 100%.

2,2'-bis(trifluoromethyl)-1,1'-biphenyl (12) [START_REF] Moncomble | Cobalt-Catalyzed Formation of Symmetrical Biaryls and Its Mechanism[END_REF] Yield: 145.1 mg, 50% (X = I); 87.1 mg, 30% (X = Br); 185.7 mg, 64% (X = H). 1 H NMR (400 MHz, CDCl 3 ) : 7.76 (dd, J = 7.6, 1.5 Hz, 2H), 7.54 (dd, J = 7.5, 1.5 Hz 4H), 7.31 (d, J = 7.5 Hz, 2H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 137. 7, 131.7, 130.8, 129.0 (q, J = 30.1 Hz), 128.3, 126.2 (m), 124.1 (q, J = 274.2 Hz). 19 F NMR (377 MHz, CDCl 3 ) : -58.12. GC-MS: rt = 7.16 min, m/z = 290. Column chromatography: SiO 2 , petrolium ether 100%.

2,2'-bipyridine (13) [START_REF] Shen | 1 H NMR spectroscopic identification of binding modes of 2,2′bipyridine ligands in complexes of square-planar d 8 metal ions[END_REF] Yield: 93.7 mg, 60% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 8.69 (d, J = 4.4 Hz, 2H), 8.40 (d, J = 8.0 Hz, 2H), 7.81 (ddd, J = 7.9, 2.8, 1.4 Hz, 2H), 7.30 (ddd, J = 7.4, 4.8, 1.2 Hz, 2H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 156. 3, 149.3, 137.1, 123.9, 121. 1,1'-biisoquinoline (14) [START_REF] Frediani | Ruthenium complexes with 1,1′-biisoquinoline as ligand. Synthesis and hydrogenation activity[END_REF] Yield: 199.9 mg, 78% (X = I). 1 H NMR (400 MHz, CDCl 3 ) : 8.72 (d, J = 5.7 Hz, 2H), 7.93 (d, J = 8.3 Hz, 2H), 7.80 (d, J = 5.7 Hz, 2H), 7.76 (dd, J = 8.5, 0.5 Hz, 2H), 7.69 (ddd, J = 8.3, 6.8, 1.1 Hz, 2H), 7.47 (ddd, J = 8.3, 6.8, 1.2 Hz, 2H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 158. 3, 142.1, 136.9, 130.4, 127.9, 127.6, 127.3, 127.0, 121. 1,1':2',1'':2'',1'' '-quaterphenyl (15) 27 Yield: 291.1 mg, 95% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.45-7.40 (m, 2H), 7.39-7.31 (m, 4H), 7.20-7.15 (m, 2H), 7.09 (t, J = 7.3 Hz, 2H), 7.01 (t, J = 7.4 Hz, 4H), 6.62 (d, J = 7.2 Hz, 4H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) d: 141. 2, 141.1, 140.2, 131.9, 130.1, 129.4, 127.63, 127.59, 127.2, 126.1. GC-MS: rt = 11.50 min, m/z = 306. Column chromatography: SiO 2 , n-Pentane 100%.

1,1'-binaphthalene (16) [START_REF] Cheng | Homocoupling of Arylboronic Acids Catalyzed by CuCl in Air at Room Temperature[END_REF] Yield: 234.0 mg, 92% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.98-7.95 (m, 4H), 7.65-7.57 (m, 2H), 7.52 -7.47 (m, 4H), 7.41 (d, J = 8.5 Hz, 2H), 7.34-7.28 (m, 2H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 138. 7, 133.7, 133.0, 128.3, 128.1, 128.0, 126.8, 126.2, 126.0, 125.6. GC-MS: rt = 11.41 min, m/z = 254. Column chromatography: SiO 2 , n-Pentane 100%. 5a Yield: 203.5 mg, 80% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 8.19 (s, 2H), 7.99 -7.95 (m, 4H), 7.93 -7.86 (m, 4H), 7.59 -7.48 (m, 4H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 138.6, 133.9, 132.9, 128.7, 128.4, 127.9, 126.6, 126.3, 126.2, 125.9. GC-MS: rt = 12.78 min, m/z = 254. Column chromatography: SiO 2 , n-Pentane 100%.

2,2'-binaphthalene (17)

1,2-diphenylethane (18) [START_REF] Black | Borrowing Hydrogen: Indirect "Wittig" Olefination for the Formation of C-C Bonds from Alcohols[END_REF] Yield: 131.2 mg, 72% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.39-7.32 (m, 4H), 7.30-7.25 (m, 6H), 3.00 (s, 4H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 142.0, 128.6, 128.5, 126.1, 38.1. GC-MS: rt = 7.89 min, m/z = 182. Column chromatography: SiO 2 , n-Pentane 100%. 9,10-dihydrophenanthrene (19) [START_REF] Deng | Nickel-catalyzed Carboannulation Reaction of o-Bromobenzyl Zinc Bromide with Unsaturated Compounds[END_REF] Yield: 108.2 mg, 60% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.81 (d, J = 7.7 Hz, 2H), 7.39-7.33 (m, 2H), 7.29-7.27 (m, 4H), 2.93 (s, 4H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 137.6, 134.7, 128.3, 127.6, 127.1, 123.9, 29.2. GC-MS: rt = 8.77 min, m/z = 180. Column chromatography: SiO 2 , n-Pentane 100%.

4,4'-dichloro-1,1'-biphenyl (20) [START_REF] Yuan | Efficient homocoupling reactions of halide compounds catalyzed by manganese (II) chloride[END_REF] Yield: 140.6 mg, 63% (X = I). 1 H NMR (400 MHz, CDCl 3 ) : 7.49 (d, J = 8.6 Hz, 4H), 7.42 (d, J = 8.6 Hz, 4H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] 135.0, 130.3, 128.1, 127.5, 125.5. GC-MS: rt = 9.218 min, m/z = 222. Column chromatography: SiO 2 , n-Pentane 100%.

Triphenylene (22) [START_REF] Hsieh | O-Dihaloarenes as aryne precursors for nickel-catalyzed [2 + 2 + 2] cycloaddition with alkynesand nitriles[END_REF] Yield: 207.7 mg, 91% (X = Br). 1 H NMR (400 MHz, CDCl 3 ) : 8.68 (dd, J = 6.2, 3.4 Hz, 6H), 7.68 (dd, J = 6.3, 3.3 Hz, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] (d, J = 8.3 Hz, 2H), 8.48 (d, J = 8.2 Hz, 2H), 8.44 (br s, 2H), 8.41 (br s, 2H), 7.48-7.44 (m, 4H), 2.64 (s, 6H), 2.63 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 136.8, 136.7, 136.43, 136.37, 130.1, 130.0, 129.7, 129.5, 128.63, 128.57, 128.33, 128.27, 127.9, 127.7, 127.4, 127.2, 123.40, 123.35, 123.3, 123.24, 123.19, 123.17, 123.1, 22. 1,4-diphenylbuta-1,3-diyne (24) [START_REF] Kakusawa | Palladiumcatalyzed cross-coupling reaction of ethynylstibanes with organic halides[END_REF] Yield: 192.1 mg, 95% (X = H). 1 H NMR (400 MHz, CDCl 3 ) : 7.60-7.53 (m, 4H), 7.43-7.34 (m, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 132. 7, 129.4, 128.6, 122.0, 81.7, 74.1. GC-MS: rt = 10.20 min, m/z = 202. Column chromatography: SiO 2 , n-Pentane/DCM 50/50.

1,1 '-dimethyl-1H,1'H-2,2'-bibenzo[d]imidazole (25) [START_REF] Truong | Manganese, Cobalt, and Iron-Catalyzed Deprotonative Arene Dimerization[END_REF] Yield: 196.7 mg, 75% (X = H). 1 H NMR (400 MHz, CDCl 3 ) : 7.89 (d, J = 7.6 Hz, 2H), 7.51 (d, J = 7.6 Hz, 2H), 7.52-7.35 (m, 4H), 4.35 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 143.5, 142.8, 136.4, 124.2, 123.1, 120.5, 110.3, 32.6. GC-MS: rt = 12.61 min, m/z = 262. Column chromatography: SiO 2 , n-Pentane/EtOAc 50/50.

1,1 '-dimethyl-1H,1'H-2,2'-bipyrrole (26) Yield: 32.0 mg, 20% (X = H). 1 H NMR (400 MHz, CDCl 3 ) : 6. 74-6.73 (m, 2H), 6.21-6.17 (m, 4H), 3.53 (s, 6H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 125. 9, 122.9, 110.7, 107.5, 34.6 4.38-4.35 (m, 4H), 4.19-4.17 (m, 4H), 4.01 (s, 10H). [START_REF] Revol | Compound 19 can be obtained by an intramolecular cyclization[END_REF] C{ 1 H} NMR (101 MHz, CDCl 3 ) : 77. 4, 69.4, 67.8, 66.6. GC-MS: rt = 12.687

ASSOCIATED CONTENT Supporting Information

Optimization tables, NMR spectra for all synthetic compounds, X-ray diffraction and mechanistic study details for ESI-MS and DFT. CCDC 1564505 contains the supplementary crystallographic data for this paper. This material is available free of charge via the Internet at http://pubs.acs.org.

Figure 1 .

 1 Figure 1. Mn-catalyzed synthesis of biphenyl 1 from chloro-, bromo-or iodobenzene, in the presence of t-BuLi. a

  Isolated yields. a Reaction conditions: a) ArX (1.0 mmol), MnCl 2 (0.1 mmol, 99.998 %, Sigma Aldrich), t-BuLi (2.0 mmol), THF (4 mL), -78 °C, 20 min, under argon; b) 25 °C, 1 h, dry air. Starting material: b benzyl bromide; c 1-bromo-2-(bromomethyl)benzene; d o-chlorobromobenzene; e 3-bromo-4-chlorotoluene.

Table 2 .

 2 Mn-catalyzed homocoupling of acetylene or arene via C-H activation. a Isolated yields. a a) phenylacetylene or arene (1.0 mmol), MnCl 2 (0.1 mmol, 99.998 %, Sigma Aldrich), t-BuLi (1.1 mmol), THF (4 mL), -78 °C, 20 min, under argon; b) 25 °C, 1 h, dry air.

Figure 2 .

 2 Theoretical (above) and observed (below) spectra of ESI-MS analysis of possible manganese dimers A, A' or A".

  . GC-MS: rt = 9.61 min, m/z = 214. HRMS (ESI + ) m/z: [M+H] + Calcd. for C 14 H 15 O 2 215.1072; Found : 215.1074. Column chromatography: SiO 2 , n-Pentane/DCM 50/50.

  9. GC-MS: rt = 8.67 min, m/z = 214. HRMS (ESI + ) m/z: [M+H] + Calcd. for C 14 H 15 O 2 215.1072; Found : 215.1073. Column chromatography: SiO 2 , n-Pentane/DCM 50/50.

  2. GC-MS: rt = 7.51 min, m/z = 156. Column chromatography: Al 2 O 3 , npentane/EtOAc 80/20.

  1. GC-MS: rt = 12.22 min, m/z = 256. Column chromatography: Al 2 O 3 , petrolium ether/EtOAc 70/30.

  C{ 1 H} NMR (101 MHz, CDCl 3 ) : 130.0, 127.4, 123.5. GC-MS: rt = 11.89 min, m/z = 228. Column chromatography: SiO 2 , n-Pentane/DCM 90/10. ) (1/3) 33 Yield: 216.3 mg, 80% (X = Br). M.p. of mixture : 128°C (lit. for 23a: 181 °C34a ; lit. for 23b: 142 °C) 34b,c 1 H NMR (400 MHz, CDCl 3 ) : 8.53 (d, J = 8.3 Hz, 2H), 8.52 (d, J = 8.2 Hz, 2H), 8.49

  0. HRMS (ESI + ) m/z: [M+H] + Calcd. for C 21 H 19 271.1487; Found : 271.1481. Column chromatography: SiO 2 , n-Pentane/DCM 90/10. A small crop of crystals suitable for Xray diffraction studies of 23b were obtained by slow diffusion of pentane into a dichloromethane solution of the mixture.

Table 1 . Mn-catalyzed homocoupling of aryl-and benzylic halides in the presence of t-BuLi : synthesis of compounds 1-21 and triphenylene derivatives 22-23. a

 1

  2

  ). The

	FJMTCl
	17HR231 (0.042) Is (1.00,1.00) C24H16Cl4Mn2O2K				1: TOF MS ES+
	100			626.8					3.25e12
		624.8
						628.8
	%
					627.8
			625.8				629.8	630.8
	0
	17HR231 210 (6.803) Sm (Mn, 2x3.00); Cm (158:210)				1: TOF MS ES+
	100			626.9					115
		624.9
						628.9
	%		625.9		627.9
								630.9
	624.1					629.3	629.9
	0	625	626	627	628	629	630	631	m/z

  min, m/z = 240. HRMS (ESI + ) m/z: [M+H] + Calcd. for C 16 H 21 N 2 241.1705; Found : 241.1703. Column chromatography: SiO 2 , n-Pentane/EtOAc 70/30.

  C{ 1 H} NMR (101 MHz, CDCl 3 ) : 138.6, 133.9, 129.2, 128.4. GC-MS: rt = 9.239 min, m/z = 223. Column chromatography: SiO 2 , n-Pentane 100%.

	3,3'-dichloro-1,1'-biphenyl (21) 31 Yield: 100.4 mg, 45% (X
	= Br). 1 H NMR (400 MHz, CDCl 3 ) : 7.56-7.55 (m, 2H), 7.46-
	7.34 (m, 6H). 13 C{ 1 H} NMR (101 MHz, CDCl 3 ) : 141.8,

  . GC-MS: rt = 6.941 min, m/z = 160. HRMS (ESI + ) m/z: [M+H] + Calcd. for C 10 H 13 N 2 161.1079; Found : 161.1079. Column chromatography: SiO 2 , n-Pentane/DCM 20/80. Yield: 148.0 mg, 40% (X = H). 1 H NMR (400 MHz, CDCl 3 ) :

	Biferrocenyl (27)

  min, m/z = 370. HRMS (ESI + ) m/z: [M+H] + Calcd. for C 20 H 19 Fe 2 371.0118; Found : 371.0107. Column chromatography: SiO 2 , n-Pentane/EtOAc 95/5.

ACKNOWLEDGMENT

ANR (program CD2I -CuFeCCBondCat) is greatly acknowledged for financial support.

AUTHOR INFORMATION

Corresponding Author *marc.taillefer@enscm.fr

Notes

The authors declare no competing financial interests.