Emmanuel Pietriga
email: emmanuel.pietriga@inria.fr

Giorgio Filippi
email: gfilippi@eso.org

Luis Véliz
email: luis.veliz@inria.cl

Fernando Del Campo
email: fernando.delcampo@inria.cl

Jorge Ibsen
email: jibsen@alma.cl

A Web-based Dashboard for the High-level Monitoring of ALMA

Keywords: ALMA, Radio-telescope, Operations Monitoring, Dashboard, Human-Computer Interaction, Data Visualization

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

INTRODUCTION

The ALMA radio-telescope is the largest millimeter/submillimeter radio astronomy observatory in the world, at an altitude of 5,000 meters in the high Atacama desert of Chile. With spatial and spectral resolution two orders of magnitude better than that of existing facilities, ALMA gives astronomers unprecedented views of star and planet formation in our galaxy and of the early Universe. It is a complex instrument made of many different components: antennas, correlator, pads, power generation and distribution network, etc. Its operations depend on the availability of high-level, easy-to-understand status information about all of these components. We have developed a Web-based application called the ALMA Dashboard, that both provides an overview of the observatory's status and allows users to get a more detailed report about particular components. The ALMA Dashboard does not intend to replace the specialized real-time monitoring and reporting subsystem tools used in the control room. [START_REF] Pietriga | Interaction Design Challenges and Solutions for ALMA Operations Monitoring and Control[END_REF][START_REF] Schwarz | Goodbye to WIMPs: A Scalable Interface for ALMA Operations[END_REF][START_REF] Schilling | Human Computer Interaction in the ALMA Control Room[END_REF] It rather aims at providing an easily accessible, all-in-one-place near-real-time overview of the observatory's key elements and figures to both line and senior management.

The Dashboard features views on the data that can be tailored according to different user profiles, from a high-level overview of the instrument's performance to a detailed view of each antenna's primary components. Interactive queries that can be made on the data include, e.g., how many antennas are currently available for science, or more elaborate ones such as how many antennas feature fully operational B4 and B6 receivers in the array's central cluster. Query results can be displayed in multiple ways, including: a table view, a compact view fitting on a single screen, a geographical map. Addition views are available, such as a timeline showing the status of the main components of an antenna over time, and a logbook.

The Dashboard initially focused on the observatory's 66 antennas. Following the successful deployment and use of this first version, it is now getting extended to cover a wider range of elements beyond antennas and their constitutive components, such as pads holding the antennas, correlator and central local oscillator, and the power network. One of the Dashboard's main design goals is to add little-to-no overhead to the existing work processes, by aggregating data from manual user input, from existing software systems, and as a by-product of organizational processes.

Following a user-centered design process similar to the one adopted for the design of real-time visualization components for the ALMA control room, 1 representatives of the different Dashboard user groups -including astronomers, operators and engineers -have been working jointly with human-computer interaction researchers on the design of the Dashboard.

In this paper, we describe the method employed to inform the Dashboard's user interface design. We then give an overview of the first version of the Dashboard, followed by a description of the extensions and improvements currently being developed. Information about the technical implementation follows, and we conclude with some words about other ALMA systems now making use of Dashboard data in other contexts, such as the control room for manual array creation.

METHOD

Antennas are the main components of the ALMA radio-observatory. Their availability and characteristics (what receivers are operational, where is the antenna located, etc.) have a direct impact on what observations can be performed. It was thus decided to focus the Dashboard primarily on those elements during the first phase of its development. The Dashboard took inspiration from the ad-hoc tools that were in use during construction to track the status of antennas delivered to the Array Operations Site (AOS), which included a collaborative spreadsheet that was used by various teams to track the primary components of each antenna. An analysis of these tools and discussions with their users helped identify the relevant pieces of data captured in those status tracking tools and the work processes associated with them. A set of requirements and a first user interface design was elaborated on this basis and iterated upon with a subgroup of representative target end-users (December 2012). This initial design is described in Section 3. Following the successful deployment of this first version (April 2013), which eventually led to the withdrawal of some of the above-mentioned ad-hoc tools and their replacement by the Dashboard, several iterations were made to make improvements. It was then decided to start a second phase of development, extending the scope of the Dashboard beyond antennas, adding alternate views on the antenna status data, and improving user interaction with the system. This second phase (initiated in October 2013 and planned for delivery in the third quarter of 2014), described in Section 4, was essentially driven by a user-centered design approach, which involved:

• a participatory design workshop organized by the HCI researchers and engineers, involving a small group of end-users (operators, astronomers, etc.) who are the domain-expert end-users of the Dashboard;

• in-situ interviews with ALMA operators, engineers and astronomers;

• rapid low-fidelity prototyping of ideas resulting from this workshop;

• discussions on this basis with stakeholders, gathering feedback and new ideas;

• high-quality implementation of the ideas identified through this process and incremental delivery and deployment of novel features over several months.

Each category of actors plays an essential role. Operators and astronomers have significant domain expertise, they are well aware of the context-of-work, the associated requirements, and the needs of end-users. They contribute ideas, and can quickly provide feedback about the relevance of different options. HCI researchers are best aware of the state-of-the-art, and can suggest possible solutions to a given problem that other members of the group who are less familiar with the latest research and development advances in the field might not be aware of. Finally, ALMA and INRIA engineers also participate in the brainstorming, suggesting solutions and later in the process providing feedback about the feasibility of the considered options. The participatory design workshop was organized in sessions that focused on well-identified topics. Each session was limited to a small number of people, taken from a total of 18 participants depending on the subject at hand. Overall, the workshop lasted 1.5 days and included a half-dozen focus sessions, so as to ensure that participants were highly committed and actively contributed to the discussions and idea generation process.

From the very beginning, and given the wide variety of end-users targeted by the Dashboard, it was decided to develop it as a Web-based application to facilitate access to it from any device (workstation, handheld device such as tablets and smartphones), without requiring users to install specific software components on their computer.

AN ANTENNA-CENTRIC DASHBOARD

The Dashboard's main page (Figure 1) is organized in two main parts: the top part gives an overview of antenna availability for scientific observations at the AOS, while the lower part provides more detailed information, indicating the operational status of each antenna's primary components. The information is organized in a table, reminiscent of the original spreadsheet, each row corresponding to an antenna. The table also serves as the main entry point to access and modify the detailed status of each antenna. The Dashboard also provides mechanisms to navigate back in time and see the observatory's status at an earlier date, as detailed below.

Overview of Antennas

The upper part of Figure 1 shows the Overview section of the Dashboard's main page (Summary). It is designed to provide users with a high-level summary of the observatory's status, from an antenna-centric perspective.

The chart in the middle shows in a prominent manner the current number of antennas available for science. In this example, 44 out of the 65 antennas delivered to the AOS are considered as usable to perform scientific observations. An antenna's availability for science is automatically determined based on a logical expression that computes this overall status based on the operational status of that antenna's primary components.

The stacked area chart on the right shows the evolution of this figure over some time span that can be changed interactively by users, ranging from the last few hours to several years. Its purpose is both to indicate the trend at different time scales, and to act as a quick shortcut to navigate back in time, as detailed in Section 3.5. While the use of stacked area charts as opposed to line charts is debatable, we opted for the former in this particular case because the total number of antennas is constant and only three statuses exist: available (blue ), not available (orange ) and not delivered (gray ). The latter was needed because the Dashboard was deployed while some of the antennas had not yet been handed over for scientific operational use. In the near future, this particular status may be omitted, or used for another purpose; for instance, to indicate that and antenna is not at the high site, but at the base camp for maintenance.

The table on the left side provides a summary of available antennas broken down by receivers (columns) and current geographical location or antenna type (rows). For instance, twelve antennas in the Inner Array/Central Cluster geographical area have a receiver for B7 operational; and five 7-meter antennas (CM) from the Atacama Compact Array have a receiver for B9 operational. Zero values are painted with a dark, low-contrast color so as to de-emphasize them. This helps users both focus on populated cells, and identify antenna types or geographical areas that lack any observation capabilities, for a given frequency band. For instance, one immediately sees from Figure 1 that B5 and B10 are unavailable no matter the geographical region considered or the antenna type (at the time, neither B5 nor B10 receivers had been commissioned). One can also observe that there is no antenna in any of the three arms (Southern, Western, Pampa La Bola) since at the time, the array was operated with a compact baseline.

Detailed Antenna Status

The Array Elements table is laid out below the Summary section described above. As mentioned earlier, this table is reminiscent of the original spreadsheet crated ad-hoc to track the status of antennas during ALMA's construction phase. It exposes detailed information about each antenna's primary components in tabular form, each row corresponding to one antenna. Information displayed in this table includes the pad on which the antenna is currently positioned, the operation status of primary components as well as that of all receivers, as well as free text comments used to share status information across groups of users and help coordinate tasks.

Rows can be filtered using a conjunction of criteria available from the table header. Figure 2 filtering, sorting capabilities are also available and can be applied to any of the columns, letting users reorder antennas according to some specific variable of interest.

Row height in this table is necessarily limited to a single line of text so as to fit as many antennas as possible on a single screen. All 66 antennas will usually not fit, but the goal is to avoid users having to scroll through antennas too much. This means that most of the time, text comments will not fully fit in the corresponding table cells. They are truncated, but users can still efficiently browse through them by brushing with the cursor through a column immediately to the left of the first comments column. As illustrated in Figure 3, the full text of all comments fields for the corresponding antenna are shown simultaneously.

White text labels correspond to tickets in ALMA's issue trackers relevant to a particular antenna. Those ticket identifiers are entered as free text by the Dashboard users. Then the system automatically detects them based on their prefix, e.g., PRTSIR-or AIV-, and displays them as hypertext links so that users can easily get to the corresponding entry in the issue tracker, which is also a Web-based application.

Updating Antenna Component Status

Clicking on a row in the table pops-up a modal window showing additional details about the corresponding antenna. When authenticated, users can update the status of the antenna, as illustrated in Figure 4. All data in this first version of the ALMA Dashboard is input manually by users, because the purpose of the Dashboard is to reflect in a near-real-time manner what subject-matter experts consider to be the current status of an antenna and its components. What this status is depends on human decision making processes involving parameters that might not be captured by any automatic system or monitoring point in the field, and thus requires users to be able to change status variables manually.

Geographical View of Antennas

Finally, users can choose to show a map of antennas below the table (Figure 5). Antennas are overlaid on top of a satellite picture of the AOS site as colored icons reflecting their overall status, giving an overview of antenna availability in the different geographical areas of the array. A similar map is embedded in the Map tab of the antenna modal window. It is centered by default on the corresponding antenna. As all three sections (Summary, ArrayElements, Map) might not always be relevant depending on a given user's tasks and interests, each can be collapsed individually. This saves both screen space and resources when refreshing the Web page.

Navigating through Time

By default, the Dashboard shows the current status of the observatory. But as all edit operations get logged and snapshots taken every hour, users can navigate back in time and inspect the status of the observatory at any arbitrary time in the past. In addition, the antenna modal window features a Timeline tab (Figure 7) that contains a visualization showing the evolution of each status variable over time, as well as when free text comment fields were edited. Finally, users can browse through changes made over a given time span by going to the Logbook tab. This can be useful, e.g., when a shift ends and another group of users takes over. By looking at the logbook (Figure 8) for the last 24 hours, a user returning to duty will get a summary of all changes that occurred while she was away. The antenna modal window also features a Logbook tab, that behaves essentially as the general Logbook but only shows events related to the corresponding antenna. Figure 9. Alternative, more compact view of antennas that fits on a single screen without scrolling while still showing all data about the 66 antennas. The matrix on the left-hand-side enables users to select multiple antennas using the usual spreadsheet-inspired mouse drag and click interaction combined with shift and control keyboard modifiers to select ranges and non-contiguous rows. Changes can then be applied simultaneously to all selected antennas. As this compact view does not allow to properly label every row and column, the information is shown only when brushing the matrix, and only for the column and row intersected by the mouse cursor. In this example, the cursor is over receiver B3 of antenna DA44. White markers help identify antennas by type (CM, DA, DV, PM), and vertical separators create boundaries between three groups of columns: overall status, main components, and receivers. Selecting an antenna in the matrix updates the detailed antenna panel on the right-hand side, whose content is similar to that of the modal window (Section 3.3) that pops-up when selecting a row in the original antenna table.

EXTENDING THE DASHBOARD

The first version of the Dashboard was deployed in March 2013 and effectively replaced some previous ad-hoc tools such as the collaborative spreadsheet to track the status of antennas. It went through a series of maintenance releases featuring minor improvements over the following 6 months, taking user feedback into account. As deployment was successful and the user base grew and gained experience with the system, several limitations were identified, as well as opportunities for extension to cover key subsystems beyond antennas. It was thus decided to launch a second design and development phase, following the user-centered design approach described in Section 2. The following sections describe the ongoing work on this second phase of development.

A Compact View for Easier Monitoring and Multi-Antenna Editing

A first limitation identified is that the antenna table on the main page would not fully fit on a single monitor, requiring users to scroll up and down to see all antennas, making interaction somewhat tedious, but more importantly preventing the use of the Dashboard for static monitoring. A second limitation reported by endusers was that updating the status of numerous antennas was relatively tedious as they had to be changed one at a time, even if the changes to apply were the same. To address both limitations, we designed an alternative, more compact view of all 66 antennas, that fits on a single screen. Figure 9 illustrates this new view. Beyond enabling static monitoring, this view lets users select multiple antennas and apply changes to all of them simultaneously (Figure 10). This view also features sorting and filtering mechanisms quite similar to those of the original antenna table described in Section 3.2, as illustrated in Figure 11. As opposed to the original antenna table (Section 3.2), filtering rows does not remove them, but simply de-emphasizes them by rendering them with darker, low-contrast colors. We made this choice because we wanted to keep the matrix visually as stable as possible, and because there was no obvious advantage in hiding those rows as this representation is already quite compact. In addition, keeping all rows visible and de-emphasizing those not selected by the filter has the advantage of enabling users to focus on items of interest while still providing some contextual information about the other items.

Further Improving Data Input

Another way to improve data input, beyond the multi-antenna editing capabilities introduced in the previous section, would be to streamline the process by gathering information from other subsystems. Indeed, some of the information currently being input manually by users in the Dashboard could be fetched from other systems such as specific issue trackers. Feeding data to the Dashboard from these sources is a process that cannot be fully automated, because even if those sources hold structured data about issues related to the status of antennas and other elements of the observatory, some ambiguities can remain. Most importantly, the process requires human supervision because it might not always be relevant to update a component's status based on changes made in an issue tracker.

Our goal is thus not to feed data directly to the Dashboard's database, but to feed a queue of changes that first have to be validated. Suggestions for modifications to Dashboard status data would be generated from this queue and presented to workers in charge of the Dashboard. Based on their knowledge of the system and external information they may have, they can decide either to apply the suggested changes automatically simply by validating them, to modify them before they get applied, or to ignore them. The first and third option would only require clicking on a button, which should make the task of reviewing the queue of suggested updates a fairly smooth and efficient process.

Implementing such a solution requires making changes both to the Dashboard and to the source systems from which data would be fetched to generate the suggestions. Two strategies are currently being considered: 1. implementing a push mechanism, where each of these source systems makes, e.g., an HTTP request to the Dashboard using its REST API whenever transitions in their workflows or any kind of change associated with a potential antenna status update happens; or 2. implementing a pull mechanism, where the Dashboard regularly polls these systems for any new tracker issue creation or update that might generate a suggestion for antenna status update. The technical feasibility of these solutions is currently being evaluated. distribution network, the pads holding the antennas. All of these are complex systems with multiple sub-states that ALMA personnel need to keep track of during operations and maintenance.

Tracking Additional Equipment

Following an approach similar to that used for antennas, new tabs are being added to the Dashboard for these systems, as shown at the top of Figure 9. These are all work-in-progress. Figure 12 illustrates the current mockup for the Pads tab, where four sub-states are associated with each pad.

In addition to these supplemental systems, the new version of the ALMA Dashboard will also feature an overview page, summarizing the status of all main systems in one diagram, as well as a widget to display and post important, site-wide messages including incidents, unusual weather conditions or reminders about maintenance actions that affect multiple groups.

IMPLEMENTATION

As illustrated in Figure 13, the Dashboard is implemented as a typical client-server Web application. Multiple clients can connect to the server and make concurrent modifications. Users need to be authenticated to update the data. The data are stored in a MySQL database as snapshots taken every hour, complemented with a log of all update events performed by users. On the server side, Django is used as the Web framework connecting to the database. It exposes the data to clients through a REST API. On the client side, the Dashboard makes heavy use of Javascript libraries, including JQuery, DataTables, and D3 5 for the interactive data visualization components. The UI eventually gets rendered as a combination of HTML 5 content, SVG graphics and CSS 3 styling instructions.

REUSE OF DASHBOARD DATA IN OTHER SYSTEMS

As the Dashboard exposes its data to clients using a REST API, third-party clients, not necessarily running in a Web browser, can query it and make use of its data (read-only) for arbitrary purposes. It is the case, for instance, of the latest version of the ZVTM-based [START_REF] Pietriga | A Toolkit for Addressing HCI Issues in Visual Language Environments[END_REF] Antenna Navigator 1 that provides a multi-scale 7 interactive map of the AOS for the Operations Monitoring and Control (OMC) software that runs in the observatory's control room. This component now enables operators to identify on the AOS map antennas that meet particular criteria based on data stored in the Dashboard, such as, e.g., all antennas available for science having B3 and B6 receivers operational. This should eventually help operators create arrays of antennas. Indeed, they formerly had to look into different places to find the relevant information: the collaborative spreadsheet, real-time monitoring data in the OMC to check the online status of antennas; once this information collected, they would then create arrays using a dedicated user interface component. With the new Antenna Navigator, that was already showing online status information based on the real-time monitoring data, and that is now able to fetch Dashboard data, operators will be able to perform all operations from a single interface component that makes all this information readily available.

Figure 14 shows an interactive multi-scale visualization that was derived from the Antenna Navigator and will be used for array configuration planning. It provides users with a dynamic query interface to inspect different antenna configurations, highlighting particular geographical regions (pads) and antennas meeting specific criteria.

Figure 1 .

 1 Figure 1. Dashboard main page, giving an overview of antenna availability in the upper part (Summary), and a breakdown of the primary components' operational status for each antenna (Array Elements).

Figure 2 .

 2 Figure 2. Filtering the antenna table: (a) full complement of antennas, (b) showing only antennas from the Atacama Compact Array, (c) further filtering this list to show only antennas from the Atacama Compact Array that have receiver for B6 fully operational.

Figure 3 .

 3 Figure 3. Quickly brushing through comments by moving the cursor in column

Figure 4 .

 4 Figure 4. Detailed view on an antenna. This view lets authenticated users update the status of any variable and edit comments. (a) Changing the status of receiver B3. (b) Assigning the antenna to another pad. Pads already occupied are grayed-out and cannot be selected.

Figure 5 .

 5 Figure 5. Representation of antennas showing their geographical location using a Google Map widget. Tabs on the left-hand side of the map act as navigation shortcuts to center and zoom the map on a particular area of ALMA.

Figure 6 .

 6 Figure 6. Navigating back in time: (a) current status, (b) status two months earlier. To avoid users mistaking a past situation for the current one, when navigating back in time, the Dashboard's look and feel is slightly altered: the UI color scheme switches to a mostly grayscale color map except for status variables, and the snapshot's date & time are prominently displayed right above the antenna table.

Figure 7 .

 7 Figure 7. Timeline showing the evolution of each status variable of a given antenna over time. The lower part shows this data in detail. The upper part corresponds to an overview of the same data at a coarser time scale. It can be used to navigate quickly through time. The color palette corresponds to that used in the antenna table on the main page. Punctual events labeled, e.g, ADE, correspond to text editing operations in the corresponding comment field.

Figure 8 .

 8 Figure 8. Logbook of events. Users can choose between predefined and custom time spans. Additionally, they can filter for specific types of events, specific antennas, a specific user making changes, or by doing a free text search in the comment fields. The Change columns provides a semi-graphical, colored-diff-like representation of what status variables and text comments changed during each editing operation.

Figure 10 .

 10 Figure 10. Setting receiver B3 to Operational for antennas DA44 to DA56 with a single edit operation. The small bar charts inside the buttons indicate the distribution of statuses for the corresponding element over the selection of antennas.

4

 4

Figure 11 .

 11 Figure 11. Filtering and sorting in the compact view: (a) default view, (b) highlighting antennas whose B6 receiver is in status Needs attention from science, (c) sorting rows according to the status of the Antenna Element (AE).

Figure 12 .

 12 Figure 12. Mockup of the Pads tab. Pads are grouped by geographical area. Four substates are associated with each one of them, and can be toggled by simple clicks on the corresponding colored square: accessibility of pad to ground vehicles, signal vault, power vault, ridges and structure.

Figure 13 .

 13 Figure 13. Dashboard architecture.

Figure 14 .

 14 Figure 14. Java-based interactive visualization tool for array configuration, making use of Dashboard data through the REST API. The view is configured to emphasize antennas that have a B3 receiver operational.

ACKNOWLEDGMENTS

We wish to thank all astronomers, engineers and operators who participated in discussions and provided us with insightful comments and ideas, including: Hector Alarcon, Denis Barkats, Emilio Barrios, Pablo Carillo, Maurizio Chavan, Vasco Cortez, Antonio Hales, Daniel Kent, Ruediger Kneissl, Stéphane Leon Tanne, Gianni Marconi, Rodrigo Olguin, Joaquin Penroz, Diego Rojas, Norman Saez, Masao Saito, Marcus Schilling, Nick Whyborn.


Benoit Fuentes

Roland Badeau

Gaël Richard

CONTROLLING THE CONVERGENCE RATE TO HELP PARAMETER ESTIMATION IN A PLCA-BASED MODEL

Keywords: PLCA, NMF, EM algorithm, multipitch estimation

Probabilistic Latent Component Analysis (PLCA) is a tool similar to Non-negative Matrix Factorization (NMF), which is used to model non-negative data such as non-negative timefrequency representations of audio. In this paper, we put forward a trick to help the corresponding parameter estimation algorithm to converge toward more meaningful solutions, based on the new concept of brakes. The idea is to control the convergence rate of the parameters of a PLCA-based model within the estimation algorithm: the parameters which are known to be properly initialized are braked in order to stay close to their initial values, whereas the other ones keep a regular convergence rate. This is an effective way to better account for a relevant initialization. In this paper, these brakes are implemented in the framework of PLCA, and they are tested in an application of multipitch estimation. Results show that the use of brakes can significantly influence the decomposition and thus the performance, making them a powerful tool to boost any kind of PLCA-based algorithm.

INTRODUCTION

Factorizations of non-negative time-frequency representations (TFR + ) are used in many audio applications such as multipitch estimation, automatic transcription and source separation. They require to put forward models of TFR + and to find algorithms to estimate the model parameters given an observation. To this aim, many mathematical frameworks can be used, either deterministic [START_REF] Lee | Learning the parts of objects by nonnegative matrix factorization[END_REF][START_REF] Dessein | Real-time detection of overlapping sound events with non-negative matrix factorization[END_REF] or probabilistic [START_REF] Virtanen | Bayesian extensions to non-negative matrix factorisation for audio signal modelling[END_REF][START_REF] Shashanka | Probabilistic Latent Variable Models as Nonnegative Factorizations[END_REF][START_REF] Yilmaz | Generalized Coupled Tensor Factorization[END_REF]. Those methods, though quite efficient, may also suffer from several flaws. Indeed, depending on the model and algorithm considered, the following problems are often faced:

• Unidentifiability of the model: several sets of parameters can explain the same observation.

• Local optima: the algorithm may stay stuck in a suboptimal local optimum.

The research leading to this paper was partly supported by the Quaero Programme, funded by OSEO, French State agency for innovation.

• Relevancy of the solution: the optimal solution is not necessarily the most meaningful one. In order to overcome these problems, an often used solution is the addition of penalty terms or priors on the parameters. For instance, many studies have been conducted in order to enforce sparsity or temporal continuity of a subset of parameters for a given model [START_REF] Fuentes | Harmonic Adaptive Latent Component Analysis of Audio and Application to Music Transcription[END_REF][START_REF] Virtanen | Monaural sound source separation by nonnegative matrix factorization with temporal continuity and sparseness criteria[END_REF].

In this paper, we study a new idea, which, as well as the addition of prior or penalty terms, helps parameter estimation algorithms to converge towards meaningful solutions. The idea is to slow down the rate of convergence of the parameters that are well initialized, through the use of a brake 1 . By doing so, it is ensured that after convergence, the estimates of the braked parameters stay close to their initial values. The other parameters -the value of which we have no prior knowledge on -keep a regular convergence rate. In the same way a sled turns right if only the right brake is used, this approach is a simple way to affect the direction that the algorithm takes and make it converge to a more relevant local optimum, by better accounting for a proper initialization.

In order to explore this idea, we choose to focus on the mathematical framework of PLCA with its basic model [START_REF] Shashanka | Probabilistic Latent Variable Models as Nonnegative Factorizations[END_REF], that we recall in section 2. In section 3, the brakes are introduced in order to independently control the convergence rate of different sets of parameters. Experimental studies are then conducted in section 4, through the problem of multipitch estimation. Finally, conclusions are drawn in section 5.

PLCA

PLCA [START_REF] Shashanka | Probabilistic Latent Variable Models as Nonnegative Factorizations[END_REF] is a method for analyzing non-negative data: here the non-negative coefficients that compose a TFR + V of an input audio signal. The observations V of coefficients V f t , t ∈ 1, T and f ∈ 1, F being respectively time and frequency indexes, are modeled as the histogram of the sampling of J independent random variables (r.v.) (f, t). These variables are drawn according to the probability distribution P Λ (f, t), and the way this distribution is modeled induces the wanted decomposition. The brakes, introduced in next section, could be used for any observation model, but for the sake of simplicity, only the basic model [START_REF] Shashanka | Probabilistic Latent Variable Models as Nonnegative Factorizations[END_REF] is considered here. In this model, a latent variable n ∈ 1, N is introduced (it can for instance represent a MIDI note), f and t are considered independent conditionally to n and P Λ (f, t) is modeled as:

P Λ (f, t) = n P (n, t)P (f |n). (1)
The set of parameters Λ is defined as {P (n, t), P (f |n)} n,t,f . In this paper, we suppose that P (f |n) represents the basis spectrum of note n (also called atom) and P (n, t) its time activation.

Given an observation, the parameters can be estimated by means of the Expectation-Maximization (EM) algorithm [START_REF] Dempster | Maximum likelihood from incomplete data via the EM algorithm[END_REF]. It provides update rules for the parameters so that the likelihood of the observations does not decrease at each iteration j:

P (n, t) j+1 ∝ P (n, t) j f V f t P Λ j (f, t) P (f |n) j (2) P (f |n) j+1 ∝ P (f |n) j t V f t P Λ j (f, t) P (n, t) j (3)
where ∝ means "proportional to" (i.e. the parameters must be normalized after their updates, so that the probabilities sum to 1) and where P Λ (f, t) is defined in equation [START_REF] Lee | Learning the parts of objects by nonnegative matrix factorization[END_REF]. From now on and for the sake of clarity, we deliberately omit to specify that a given distribution depends on the parameters Λ and that the value of a parameter depends on the iteration j of the algorithm. For instance, P Λ j (f, t) is thus denoted P (f, t).

TAKING CONTROL OF THE CONVERGENCE RATE

Many works have been done in order to influence the convergence rate of NMF-based algorithms (e.g. [START_REF] Nakano | Convergence-guaranteed multiplicative algorithms for nonnegative matrix factorization with β-divergence[END_REF]), but their goal is to study or improve the overall convergence speed. In this section, we suggest to independently control the convergence rate of different sets of parameters ({P (n, t)} n,t and {P (f |n)} f,n for instance in the case of basic PLCA model) in order to influence the result of an optimization algorithm, without looking at the resulting global speed convergence. A simple idea to do so is to compute a weighted mean between the optimal solution of the M step and the value of the parameters at the previous iteration. Equations ( 2) and (3) would then become:

P (n, t) ∝ P (n, t)   f V f t P (f, t) P (f |n) + β 1 brake   , ( 4
)
P (f |n) ∝ P (f |n) t V f t P (f, t) P (n, t) + β 2 brake , ( 5
)
where β 1 brake and β 2 brake are two positive coefficients, that we call brakes. They indeed act as a brake on the convergence, since the larger they are, the more the value of the parameters at a given iteration is close to the previous iteration. If the two brakes are set with different values (for instance β 1 brake = 0 and β 2 brake > 0), they will act as a "steering wheel", and then influence the direction in which the algorithm goes. The parameters may then converge towards a different local minimum than if no brakes were use, as shown in next section. For instance, one use that can be put forward is to brake the parameters which are known to be well initialized. In this way, it is more likely that, after convergence, they will not be far from their initialization.

There is a formal way to introduce the brakes in the framework of PLCA, so that equations ( 4) and ( 5) are directly derived from the EM algorithm. The reader is referred to appendix A for further explanations.

EXPERIMENTAL STUDY AND APPLICATION

In this section, we study how the use of brakes can influence the decomposition algorithm. To do so, we chose to address the problem of multipitch estimation. The purpose of this section is not to provide new state of the art algorithms but to show that the use of brakes can improve the performance of existing methods, whether they are naive or sophisticated. By doing so, we hope that other researchers will be able to use brakes in order to improve the parameter estimation algorithm of their own models, whatever the problem considered.

From now on, the TFR + used is the absolute value of the constant-Q transform (CQT) with 3 bins/semitone, for frequencies from 27.5 to 7040 Hz and with a time step of 10 ms. Besides, only piano signals are considered since for the piano, the assumption that each note can be modeled by a single basis spectrum is a reasonable assumption. In all the following multipitch estimation applications, the dataset used is a subset of the MAPS database [START_REF] Emiya | Multipitch Estimation of Piano Sounds Using a New Probabilistic Spectral Smoothness Principle[END_REF] composed of nine 20s excerpts. It is denoted as DB eval . For each of the following algorithms, in order to set the values of the brakes when they are non-zero, another subset of MAPS of the same size is used as a training dataset.

Blind PLCA

The model of the first conducted experiment is similar to the one put forward in [START_REF] Bertin | Blind Signal Decompositions for Automatic Transcription of Polyphonic Music: NMF and K-SVD on the Benchmark[END_REF]. It concerns blind PLCA, i.e. when no knowledge is provided on the nature of the atoms P (f |n) or the activations P (n, t). To do so, P (n, t) is initialized with a uniform distribution and P (f |n) is initialized with some random distribution. Since the total number of different notes in an input signal is also unknown, we consider that all MIDI notes might be present and the number of atoms used to model them is thus set to 88 (the total number of keys on a piano). Moreover, 4 additional atoms are reserved to model the possible presence of noise, which makes a total of N = 92 atoms. Fig. 1 illustrates how the use of a brake on P (f |n) can influence the decomposition. In fact, in a given musical excerpt, it is unlikely to have all the 88 MIDI notes (especially if the signal is short), and N is then overestimated. If we let the algorithm converge without using brakes, all the atoms available will be used to model the input data, with for instance several atoms used to model a single note. If one wants to model each note by a single atom, it is possible to slow down the convergence rate of the basis spectra. In this way, the algorithm is informed that the solution for P (f |n) must be close to initialization, i.e. that the lowest possible number of atoms must correspond to note spectra (harmonic spectra), the others keeping their initial shape.

It is interesting to note that temporal activations become then much sparser, as well as the overall energy of the atoms P (n) = t P (n, t): many atoms are never activated and the overestimation of N is no longer a problem. However, it can be noticed that with the use of brakes, the convergence of the log-likelihood is slower.

In order to quantify the benefits of using the brake on P (f |n) in the framework of blind PLCA, a multipitch evaluation is performed on DB eval . After convergence of the algorithm, at time t 0 , a note n 0 is considered to be active if P (n 0 , t 0 ) dB > max n,t P (n, t) dB -A min where A min is a detection threshold. The pitch of each atom P (f |n) is estimated using a simple spectral sum. The quality of the resulting note activation estimation can then be quantified through the three classical measures of Recall, Precision and F-measure [START_REF] Emiya | Multipitch Estimation of Piano Sounds Using a New Probabilistic Spectral Smoothness Principle[END_REF]. In Fig. 2, the average F-measure w.r.t. A min is illustrated, whether the brake is used or not. It can be seen that the brake can significantly improve the results, and at the same time can reduce the necessity of a fine tuning of the A min threshold.

Harmonic PLCA

The second experiment is very similar to the previous one, with the same number of atoms used (N = 92). The only difference is that we add some knowledge on the nature of the signals to be analyzed by initializing the 88 first atoms as harmonic spectra. The coefficients of P (f |n) are thus set to a very low value ǫ for frequencies between theoretical harmonics of note n ∈ 1, 88 . Moreover, its spectral envelope is decreasing w.r.t. frequency, as usually observed in note spectra of acoustic instruments. This model and its initialization is thus similar to what is proposed in [START_REF] Raczynski | Multipitch analysis with harmonic nonnegative matrix approximation[END_REF]. The four atoms used to model noise and activations are initialized in the same way as in the previous experiment.

Here again, a brake can be applied on the basis spectra since we can consider that they are properly initialized. In practice, we can notice that this induces sparser activations after convergence of the algorithm, as well as for blind PLCA. Here again, the use of brakes is evaluated through the same application of multipitch estimation on DB eval . In this case, it is no longer necessary to estimate the pitch of each harmonic atom, since it has been established during initialization. Results are shown in Fig. 3, and the use of brakes again appears to be beneficial in terms of F-measure.

BHAD

Until now, only the basic PLCA model [START_REF] Shashanka | Probabilistic Latent Variable Models as Nonnegative Factorizations[END_REF] has been considered. Though, as shown in this section, it is also possible to apply the principle of brakes to any kind of PLCA-based model, by using the same approach as in section 3. Here, we want to apply it to the Blind Harmonic Adaptive Decomposition (BHAD) [START_REF] Fuentes | Blind Harmonic Adaptive Decomposition Applied to Supervised Source Separation[END_REF]. It is a more sophisticated model which allows modeling harmonic notes having time variations of pitch and spectral envelope. The evaluation conducted in [START_REF] Fuentes | Blind Harmonic Adaptive Decomposition Applied to Supervised Source Separation[END_REF] has also shown that BHAD was at the state of the art for multipitch estimation. In no brake (max=41.1%) brake on atoms (max=44.2%) Fig. 2. Study of the influence of a brake on basis spectra in the framework of blind PLCA: average F-measure w.r.t. A min for two multipitch estimation algorithms. When the brake is used, β 1 brake = 0 and β 2 brake = 250. no brake (max=55.1%) brake on atoms (max=60.6%) Fig. 3. Study of the influence of a brake on basis spectra in the framework of harmonic PLCA: average F-measure w.r.t. A min for two multipitch estimation algorithms. When the brake is used, β 1 brake = 0 and β 2 brake = 250.

this model, each column of an input CQT is first decomposed into a smooth spectrum (noise) and a polyphonic harmonic spectrum. This last component is modeled as a weighted sum of various harmonic spectra, each one having its own pitch (denoted by a hidden variable i) and a time-dependent spectral envelope. In order to consider any number of active notes at a given time, all possible pitches are considered, with possible zero weights. The spectral envelope of each harmonic spectrum of pitch i at time t is encoded via a set of coefficients, which we call envelope coefficients and which are denoted P h (z|i, t) in [START_REF] Fuentes | Blind Harmonic Adaptive Decomposition Applied to Supervised Source Separation[END_REF].

The BHAD model is a very expressive model, and it is thus necessary to constrain the parameter estimation algorithm so that it gives relevant solutions. In [START_REF] Fuentes | Blind Harmonic Adaptive Decomposition Applied to Supervised Source Separation[END_REF], a sparse prior is added to the weights of the harmonic spectra and it is shown that the performance is improved when BHAD is applied to multipitch estimation. Here, in order to constrain the decomposition, a brake on the envelope coefficients is added: we force the spectral envelopes of the harmonic spectra to be close to their initialization (decreasing in frequency). Results of multipitch estimation on DB eval are shown in Fig. 4. They show that the use of brakes in the BHAD model can also significantly improve the performance. no brake (max=59.7%) brake on atoms (max=65.5%) Fig. 4. Study of the influence of a brake on envelope coefficients in the framework of BHAD: average F-measure w.r.t. A min for two multipitch estimation algorithms. When the brake is used, β brake = 10.

CONCLUSIONS

In this paper, we have introduced a new way of helping a parameter estimation algorithm converge towards a more meaningful solution in the framework of PLCA-based models. This is done by slowing down the convergence rate of parameters that are properly initialized -the other ones keeping a regular convergence rate -, in order to better account for the initialization. In other words, it is a simple way to introduce prior knowledge on the signals to be analyzed. A major advantage of the use of brakes is that they are easily implemented and that they do not increase the complexity, even if they can also slow down the overall convergence of the algorithm. Three multipitch estimation algorithms have been tested with and without brakes, and it appears that brakes have significantly improved the performance in all cases. In future work, we plan to theorize the use of brakes for other kind of mathematical frameworks ( [START_REF] Lee | Learning the parts of objects by nonnegative matrix factorization[END_REF][START_REF] Virtanen | Bayesian extensions to non-negative matrix factorisation for audio signal modelling[END_REF][START_REF] Yilmaz | Generalized Coupled Tensor Factorization[END_REF]).

The Matlab implementation of the algorithms used in this article as well as the database DB eval can be found online: http://www.benoit-fuentes.fr/publications.

A. THEORETICAL INTRODUCTION OF BRAKES

In PLCA, observations V are the outcome of a generative process, and equations ( 2) and (3) result from the EM algorithm applied to this process. In order to formally introduce the brakes in equations ( 4) and ( 5), while remaining in the framework of the EM algorithm, one needs to slightly change the generative process of V (below, italics represent the addition of brakes to classic PLCA):

• ∀(f, t) ∈ 1, F × 1, T , set V f t = 0.
• Repeat J times:

draw (n, t) according to P (n, t), draw f according to P (f |n),

-set V f t = V f t + 1.
• Repeat β 1 brake times:

draw (n 0 , t 0 ) according to P (n 0 , t 0 ) and do nothing with those variables.

• For each n, repeat β 2 brake times: draw f n according to P (f n |n) and do nothing with this variable. In this last step, n is no longer a random variable. The notation f n (r.v. representing a frequency) is used because different r.v. names are needed depending on the value of n. β 1 brake and β 2 brake are integer values defining the strength of two brakes: one on parameters P (n, t) and one on parameters P (f |n). The main difference with classic PLCA is that some additional "virtual" variables linked to no observation are drawn, thereby making the estimation algorithm slower. We can now derive the EM algorithm. Firstly, the joint log-probability of hidden and observed variables is calculated (we denote x the set of all drawn variables x):

L Λ f , t, n, n0 , t0 f 1 , • • • , f N = ln P f , t, n, n0 , t0 f 1 , • • • , f N = J j=1
ln (P (n j , t j )) + ln (P (f j |n j )) Then, if we remember that V f t corresponds to the number of times (f, t) is observed, the conditional expectation

Q Λ = E L Λ f , t, n, n0 , t0 f 1 , • • • , f N | f , t; Λ
is given by:

Q Λ = f,
) 7
The notation P (x|-) is used to mean that the probability is an a posteriori probability but that the hidden variable x depends on no observation. Moreover, notation P n (f |-) means that the probability depends on the value of n.

In the E-step, posterior probabilities are calculated with respect to the current values of the parameters due to Bayes' theorem: P (n|f, t) = P (n, t)P (f |n) P (f, t) , (

P (n, t|-) = P (n, t), (9) P n (f |-) = P (f |n), [START_REF] Emiya | Multipitch Estimation of Piano Sounds Using a New Probabilistic Spectral Smoothness Principle[END_REF] where P (f, t) is given by equation [START_REF] Lee | Learning the parts of objects by nonnegative matrix factorization[END_REF]. In the M-step, Q Λ is maximized with respect to the parameters, under the constraint that all probability distributions sum to one:

P (n,
By merging the E and M steps, one can deduce the multiplicative updates given by equations ( 4) and [START_REF] Yilmaz | Generalized Coupled Tensor Factorization[END_REF]. It can be noticed that if we multiply V , β 1 brake and β 2 brake by a same positive scalar, the update rules do not change. It is thus unnecessary to fix β 1 brake and β 2 brake to integer values, as well as it is not necessary to multiply an input TFR + V by a scaling factor so that its coefficients are integers.

Fig. 1 .

 1 Fig. 1. Blind PLCA: illustration of the use of a brake on basis spectra (β 1 brake = 0 and β 2 brake = 250). The input signal is an 8s excerpt from the BWV 850 Bach's Prelude. The same random initialization of P (f |n) has been used in the two experiments.

The word "brake" is a new term we put forward in this context, defined in section 3.


Mathieu Acher
email: mathieu.acher@irisa.fr

Benoit Combemale
email: benoit.combemale@inria.fr

Philippe Collet
email: philippe.collet@unice.fr

Metamorphic Domain-Specific Languages

Keywords: D. Software [D.2 SOFT-WARE ENGINEERING]: D.2.6 Programming Environments, D. Software [D.3 PROGRAMMING LANGUAGES]: D.3.0 General programming, domain-specific languages, metamorphic

External or internal domain-specific languages (DSLs) or (fluent) APIs? Whoever you are -a developer or a user of a DSLyou usually have to choose side; you should not! What about metamorphic DSLs that change their shape according to your needs? Our 4-years journey of providing the "right" support (in the domain of feature modeling), led us to develop an external DSL, different shapes of an internal API, and maintain all these languages. A key insight is that there is no one-sizefits-all solution or no clear superiority of a solution compared to another. On the contrary, we found that it does make sense to continue the maintenance of an external and internal DSL. Based on our experience and on an analysis of the DSL engineering field, the vision that we foresee for the future of software languages is their ability to be self-adaptable to the most appropriate shape (including the corresponding integrated development environment) according to a particular usage or task. We call metamorphic DSL such a language, able to change from one shape to another shape.

Introduction

Domain-specific languages (DSLs) are more and more used to leverage business or technical domain expertise within complex software-intensive systems. DSLs are usually simple and little languages, focused on a particular problem or aspect of a (software) system. Outstanding examples of DSLs are plentiful: Makefiles for building software, Matlab for numeric computations, Graphviz language for drawing graphs, or SQL (Structured Query Language) for databases.

DSLs are found to be valuable because a well-designed DSL can be much easier to use than a traditional library. The case of SQL is a typical example. Before SQL was conceived, querying and updating relational databases with the available programming languages led to a huge semantic gap between data and control processing. With SQL, users can write a query in terms of an implicit algebra without knowing the internal layout of a database. Users can also benefit from performance optimization: a query optimizer can determine the most efficient way to execute a given query.

Another benefit of DSLs is their capacity at improving communication with domain experts [START_REF] Mernik | When and how to develop domain-specific languages[END_REF][START_REF] Fowler | Domain Specific Languages[END_REF][START_REF] Voelter | DSL Engineering -Designing, Implementing and Using Domain-Specific Languages[END_REF], thus tackling one of the hardest problems in software development. But DSLs are also ordinary languages, in the sense that many difficult design decisions must be taken during their construction and maintenance [START_REF] Mernik | When and how to develop domain-specific languages[END_REF]. They usually can take different shapes: plain old to more fluent Application Programming Interface (APIs) ; internal or embedded DSLs written inside an existing host language ; external DSLs with their own syntax and domainspecific tooling. To keep it simple, a useful and common distinction is to consider that a DSL can come in two main shapes [START_REF] Fowler | Domain Specific Languages[END_REF]: external or internal. When an API is primarily designed to be readable and to "flow", we also consider it as a DSL.

As for SQL -invented in 1974 and one of the first DSLsit is interesting to note that it comes itself in different shapes. Figure 1 shows three of these shapes on the same basic query example. The top part of the figure shows the plain SQL variant, with a classical "select, from, where" clause. In the middle part of the figure, we show the same query written in Java with JOOQ (http://jooq.org), a fluent API that emphasises its typesafe nature. The lower part of the figure shows again the same query using the Slick API in Scala (http://slick.typesafe.com).

All shapes of a DSL have strengths and weaknesses whoever you are -a developer or user of the DSL. These SQL shapes illustrate this situation. The plain SQL version is an external DSL, making it easier for database experts to write complex queries, but making harder the software engineering job of integrating the DSL with other programming languages. On the entire other side, the JOOQ API is a Java internal DSL. As Java does not provide enough mechanisms to host DSL, the best result is a fluent API which mimics the SQL statement in successive method calls. Some of the SQL concepts are clearly recognizable by SQL experts, but some constructs, such as the AND clause, may lead to scoping errors. The job of the DSL developers is also reduced to an API implementation. The third example in Slick shows what can be achieved when the host language, here Scala, has some powerful constructs, such as "filter", that can be reused. The syntax is then less close to the original SQL, but easier for the average Scala developer. Another solution could have been to use the syntactic flexibility of Scala to closely mimic SQL, but this would not have suppressed some drawbacks, i.e., the internal DSL is a leaky abstraction: some arbitrary code may appear at different places in the domain scope [START_REF] Mernik | When and how to develop domain-specific languages[END_REF][START_REF] Fowler | Domain Specific Languages[END_REF], and its concrete syntax can pose a problem for domain experts or non programmers [START_REF] Stefik | An Empirical Investigation into Programming Language Syntax[END_REF].

The basic trade-offs between internal and external DSLs have been already identified and are subject to extensive discussions and research for several years. A new trend though is observed. DSLs are now so widespread that they are used by very different users with separate roles and varied objectives. In the case of SQL, users can be marketers, database experts, prototyping of basic queries to search some data, sophisticated integration of SQL queries into a web application, etc. Depending on the kinds of users, roles or objectives, an external shape or an internal shape of a language tends to be a better solution. Most of the new learners of SQL (e.g., students) have started to learn SQL with explanations and examples written in the external shape of the language as well as a dedicated interactive environment. On the other hand, software engineers may have the need to use an internal shape when integrating database concerns. This diversity poses a major challenge for the DSL engineering discipline:

How to provide the good shape of a DSL according to the needs of a user?

The idea of having different shapes of a language is indeed appealing. In the case of SQL we can envision the use of different shapes and a transformation from one shape to another, for example, plain SQL could be converted to JOOQ code (and vice-versa). Users could rely on a familiar syntax, in their own environments; the integration of their work with other software ecosystems and languages could be facilitated as well. Yet it must be acknowledged that there is no concrete solution for realizing and supporting the idea.

One reason for the lack of solutions may be the complexity of the problem. By itself, developing one shape of a DSL with a dedicated syntax coming with a set of tools (e.g., type checkers, editing and refactoring facilities) is a difficult and time-consuming task [START_REF] Kelly | Worst Practices for Domain-Specific Modeling[END_REF]. Fortunately, the increasing maturity of language technologies (e.g., workbenches for creating external DSLs) has democratized the creation of numerous DSLs [START_REF] Fowler | Domain Specific Languages[END_REF][START_REF] Voelter | mbeddr: instantiating a language workbench in the embedded software domain[END_REF][START_REF] Tratt | Domain Specific Language Implementation via Compile-time Meta-programming[END_REF][START_REF] Erdweg | The State of the Art in Language Workbenches -Conclusions from the Language Workbench Challenge[END_REF][START_REF] Kelly | MetaEdit+ at the Age of 20[END_REF]. Providing the support for transitioning from one shape to another is another difficult problem and open challenge. The number of bridges between N languages (N ≥ 2) is theoretically exponential. Language workbenches such as Jetbrain's MPS support the transformation of a shape, but with the strong limitation of projecting in a fixed host language and/or environment.

Another barrier is the possible drawbacks of combining multiple programming languages (and multiple paradigms) in application development -sometimes called polyglot programming [START_REF] Wampler | Polyglot programming[END_REF][START_REF] Meyer | Multi-language programming: how .NET does it[END_REF][START_REF] Fowler | One language[END_REF]. Yet we want to emphasize the fact that a user usually focuses on an unique shape -the most optimal one according to her task, know-how, education, or simply taste [START_REF] Meyerovich | Socio-PLT: Principles for Programming Language Adoption[END_REF][START_REF] Leo | Empirical analysis of programming language adoption[END_REF]. It is the other stakeholders that are using different shapes in another context and environment.

Despite these socio-technical difficulties, our vision for the future of DSL engineering is as follows:

The discipline, its foundations, methods, and tools, should go beyond the constraints which are imposed by the shapes that a DSL can take for its respective various users. We claim that developers and users of DSLs should not have to choose sides: a DSL should be metamorphic and change its shape accordingly! Our vision is not only supported by an analysis of the DSL area (Section 2), but also grounded on practical experiences. SQL is not an isolated case of what a metamorphic DSL could be. We directly faced similar issues on building and evolving a DSL, called FAMILIAR [START_REF] Mathieu Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF]. Similarly to SQL, a diversity of shapes emerged and does make sense for a diversity of users, roles or objectives (Section 3). We hope that this essay will influence language designers and researchers so that they work at unifying the identified first steps towards DSLs that can change from one shape to another.

Shapes of DSL

We now discuss different socio-technical aspects of DSLs and how the idea of metamorphic DSLs came about w.r.t. these aspects.

API, Internal, External, Embedded, etc.

What is a DSL? A consensual, precise answer is hard to formulate. From a conceptual and very broad perspective, a DSL provides notations and constructs tailored toward a particu-lar application domain. By trading generality for a focused support, DSLs promise substantial gains in productivity and ease of use in a limited domain. For instance, the Graphviz DSL provides a concise notation that makes the drawing of graphs easy and efficient.

DSLs are usually distinguished from general-purpose languages (GPLs). The distinction is useful to emphasize the restricted nature of DSLs and the specific abstractions they provide. In practice, the boundary between a GPL and a DSL is not as clear. For instance, a "fluent" API written in a GPL like Java, C# or Scala can be considered as a DSL. Not all APIs are DSLs; but when an API is primarily designed to be readable and to "flow", people1 tend to consider it as a DSL. The reason is that fluent APIs (as DSLs) provide a convenient, concise notation and set of constructs to resolve specific problems in a domain. Another source of confusion for the boundary between GPL and DSL is the case of embedded DSL. For instance, in Lisp languages (GPLs), programmers can use macro systems to create new syntax and thus embed DSL.

The dichotomy between external and internal is generally employed to characterize DSLs. An external DSL is a completely separate language with its own custom syntax and environment. The domain-specific tooling includes editors (with syntax highlighting, auto-completion, etc.), debuggers, interpreters, compilers, etc. An internal DSL is a solution written on top of a host language (e.g., Java). Fluent APIs and embedded DSLs fall in this category. An internal DSL is limited to the syntax and structure of its host language. Some GPLs (e.g., Lisp languages) offer built-in facilities (e.g., macros) to develop and integrate new constructs. Extension mechanisms can also been developed to augment the syntax of a GPL [START_REF] Erdweg | Sugarj: Library-based syntactic language extensibility[END_REF] and embed DSLs. Both internal and external DSLs have strengths and weaknesses (learning curve, cost of building, programmer familiarity, communication with domain experts, mixing in the host language, strong expressiveness boundary, etc.) [START_REF] Fowler | Domain Specific Languages[END_REF]. The case of SQL (see Figure 1) is quite representative of the phenomenon, and we will give another example in Section 3. But it is not the role of this essay to empirically investigate the superiority (if any) of a solution. We rather want to emphasize that a multiplicity of shapes does exist in practice.

The diversity of terminology shows the large spectrum of shapes DSLs can take. For example, these shapes include Fluent APIs, internal DSLs, (deeply) embedded DSLs, external DSLs, . . .

Syntax and Environment Matter

Usability, productivity, learnability, expressiveness, reusability: all are factors developers and users of DSLs have to consider [START_REF] Hermans | Domain-Specific Languages in Practice: A User Study on the Success Factors[END_REF]. For instance, the users of a DSL have to learn an extra language, which takes time and effort. A very long learning curve may preclude the adoption of a DSL, despite the promise of a much better productivity. In fact, the adoption of a programming language, being a GPL or a DSL, is a very complex socio-technical problem [START_REF] Meyerovich | Socio-PLT: Principles for Programming Language Adoption[END_REF][START_REF] Leo | Empirical analysis of programming language adoption[END_REF]. We argue that both the syntax and the supporting environment play a key role in this process.

Stefik et al. [START_REF] Stefik | An Empirical Investigation into Programming Language Syntax[END_REF] investigated the role of syntax in what they call the programming language wars through four empirical studies. Ruby, Java, Perl, Python, Randomo, and Quorum (i.e., GPLs) have been considered. Results show that many aspects of traditional C-style syntax, while they have influenced a generation of programmers, exhibit problems in terms of usability for novices. Some languages are also considered more intuitive than others, by both programmers and nonprogrammers.

Denny et al. [START_REF] Denny | Understanding the syntax barrier for novices[END_REF] conducted an empirical study showing that syntax in programming languages such as Java remains a major barrier to students. In an experiment involving 330 students in an introductory programming course, they found that even excellent students experience syntax issues. In [START_REF] Denny | All syntax errors are not equal[END_REF] Denny et al. showed that the understanding of syntax errors varies as well.

The learnability of programming languages (e.g., Logo [START_REF] Lukas | Uses of the LOGO Programming Language in Undergraduate Instruction[END_REF], Scheme [START_REF] Bruce Findler | DrScheme: A Programming Environment for Scheme[END_REF], Smalltalk [START_REF] Borning | Deltatalk: An Empirically and Aesthetically Motivated Simplification of the Smalltalk-80 Language[END_REF]), the usability of a language [START_REF] Mciver | Syntactic and Semantic Issues in Introductory Programming Education[END_REF][START_REF] Pane | Studying the language and structure in non-programmers' solutions to programming problems[END_REF], or the relationship between programming and natural languages [START_REF] Delorey | Mining programming language vocabularies from source code[END_REF] have also been investigated in the past. A number of authors have established that programming language usage impacts productivity in both the industry and open-source communities [START_REF] Comstock | Strategic software development: Productivity comparisons of general development programs[END_REF][START_REF] Daniel | Do Programming Languages Affect Productivity? A Case Study Using Data from Open Source Projects[END_REF]. At the paradigm level, Ramalingam and Wiedenbeck [START_REF] Ramalingam | An Empirical Study of Novice Program Comprehension in the Imperative and Object-oriented Styles[END_REF] compared comprehension with imperative and object-oriented styles. This study shows that language notations do influence novices. The authors suggest that language designers can exploit some of these findings to improve their languages.

In terms of programming language usability, a wide variety of topics have been studied, such as method naming [START_REF] Einar | Understanding programmer language[END_REF][START_REF] Høst | The programmer's lexicon, volume i: The verbs[END_REF] coding standards [START_REF] Binkley | To camelcase or under_score[END_REF], the use of identifiers [START_REF] Deissenboeck | Concise and consistent naming[END_REF], or API designs [START_REF] Stylos | Usability Implications of Requiring Parameters in Objects' Constructors[END_REF][START_REF] Stylos | The Implications of Method Placement on API Learnability[END_REF][START_REF] Monperrus | What Should Developers Be Aware Of? An Empirical Study on the Directives of API Documentation[END_REF][START_REF] Clarke | Measuring API usability[END_REF][START_REF] Ellis | The Factory Pattern in API Design: A Usability Evaluation[END_REF]. These topics are considered as well when designing an internal DSL (e.g., a fluent API). The choice of proper method names or identifiers, and the way of structuring them both contribute to the quality of a DSL syntax.

Another important aspect of a computer language (GPL or DSL) is the supporting tools. They can drastically influence human performance. No one now wants to (seriously) edit or program without advanced features offered by an IDE (Integrated Development Environment), such syntax highlighting, code completion, debugging or refactoring services. DSLs can provide sophisticated static analyses and checks that go far beyond what can be done with GPLs. Even basic features (such as locating the source of error and presenting explanations) can be optimized thanks to the focus of a DSL. Eventually DSL users have to rely on specialized tools and dedicated environments to get the best of the language.

As syntax and development environment matter, IDEs should allow the user to choose the right shape of a DSL for each task.

Language Workbenches

Numerous approaches for implementing external or internal DSLs have been proposed.

Language workbenches have emerged as an efficient means to make the development of new DSLs affordable [START_REF] Fowler | Domain Specific Languages[END_REF]. Developers can define, reuse and compose DSLs and obtain a comprehensive set of services, generally on top of an IDE.

A language workbench typically provides mechanism to define the concrete syntax of a DSL -being a textual or graphical notation or a combination thereof. Most language workbenches also provide syntactic and semantic editor services. Syntactic services include language-specific syntax coloring, outline views (for navigation support), folding facilities to hide part of a program, completion templates that suggest code, auto formatting of a program presentation, etc. Semantic services include semantics-preserving refactoring steps of programs, an error marker highlighting the source of error and presenting a message to the user, and quick fixes for cor-recting an error. Language workbenches offer mechanisms to specialize the behavior of an editor, according to the specific syntax and semantics of a DSL.

With Spoofax [START_REF] Lennart | The Spoofax Language Workbench: Rules for Declarative Specification of Languages and IDEs[END_REF] or Xtext [START_REF] Efftinge | Xbase: Implementing Domain-specific Languages for Java[END_REF], developers provide highlevel specifications of a language while editor services are generated and integrated into an Eclipse environment. Projectional language workbenches such as Jetbrain's MPS support the projection of a representation into textual, symbolic, and tabular notations. MPS realizes the language-oriented programming paradigm introduced by Sergey Dmitriev [START_REF] Dmitriev | Language oriented programming: The next programming paradigm[END_REF]. For embedded software engineering, embeddr [START_REF] Voelter | mbeddr: instantiating a language workbench in the embedded software domain[END_REF] provides an IDE and a set of integrated and extensible languages on top of the C language.

In addition, different strategies for embedding a DSL have been proposed [START_REF] Tratt | Domain Specific Language Implementation via Compile-time Meta-programming[END_REF][START_REF] Erdweg | Sugarj: Library-based syntactic language extensibility[END_REF][START_REF] Hofer | Polymorphic embedding of dsls[END_REF][START_REF] Gill | Domain-specific Languages and Code Synthesis Using Haskell[END_REF]. LMS proposes a staging mechanism to define an external DSL on top of the Scala language [START_REF] Rompf | Lightweight Modular Staging: A Pragmatic Approach to Runtime Code Generation and Compiled DSLs[END_REF]. Tratt proposes a compile-time meta-programming facility to embed a DSL [START_REF] Tratt | Domain Specific Language Implementation via Compile-time Meta-programming[END_REF]. SugarJ demonstrates how to syntactically extend Java with a library of languages [START_REF] Erdweg | Sugarj: Library-based syntactic language extensibility[END_REF].

The community of language engineering is providing more and more mature solutions for building DSLs -being external or internal. Developers of DSLs have now a variety of strategies to choose from and build an appropriate shape.

Shaping up DSLs

An analysis of the language engineering era shows that the idea of having different shapes of a DSL is not so surprising:

• beyond the terminological clarifications and the ongoing debate of what is and what is not a DSL, we can observe that different shapes of a DSL have been characterized (internal, external, embedded DSLs, mini-languages, fluent API, etc.) by the community;

• the shape of a DSL is constituted by its syntax and its environment (e.g., IDE), two important factors for the adoption and success of a language;

• numerous tool-supported solutions exist to devise new shapes of DSL.

What is still missing is a systematic solution for transitioning from one shape to another. That is, we would like to open a given artefact (expressed in a DSL) with another syntax and another environment. In the next section, we will be more concrete to emphasize the argumentation and idea. We report on a practical experience representative of the multiplicity of shapes a DSL can take.

A Polymorphic Journey: The FAMILIAR experience

Over the past four years, we have continuously designed, developed, used, and maintained different solutions for managing feature models on a large scale. Feature models are by far the most popular notation in industry for variability modeling [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF]. The formalism can be seen as a technologyindependent, high-level, formal representation of options (features) and constraints of a configurable system (e.g., Linux [START_REF] Berger | A study of variability models and languages in the systems software domain[END_REF]) or a family of products, also called software product lines [START_REF] Apel | Feature-Oriented Software Product Lines: Concepts and Implementation[END_REF]. As we will see, the FAMILIAR case study is representative of the "diversity" phenomenon we point out: multiple kinds of users, each with different objectives and needs, may potentially have to manage feature models. The purposes of feature models vary as well. Here is a non-exhaustive list of feature modeling users, together with an usage example:

• marketing engineers when characterizing the options (and their constraints) of products offered to customers;

• end users visualising feature models through an intuitive and interactive interface, a (Web) configurator;

• system engineers in charge of identifying common and reusable components;

• experts in model checking that use the feature modeling formalism for efficiently verifying complex properties of a configurable system;

• software engineers, for example, web developers in charge of deriving a web configurators from the feature model.

The diversity of usage impacts the important properties a solution should exhibit (e.g., learnability, expressiveness, reusability, usability, performance). Intuitively, the emphasis is likely to be more on usability and learnability for non programmers and on ease of integration and performance for software engineers. Our story is that we developed "many shapes" of a language to mirror "many forms" of usage, making us question the nature of our solution.

The story of FAMILIAR started at the beginning of 2010. At that time, the effort of researchers was mostly centered around the design of a graphical and textual language with a formal semantics for specifying feature models, and the development of efficient reasoning operations. On top of the feature modeling languages, numerous Java APIs arose for computing properties of the model. Naturally we looked at existing Java APIs (SPLAR, FeatureIDE, FAMA, etc.) that provide operations, based on different kinds of solvers (SAT, CSP, BDD). In terms of readability and learnability the APIs were rather complex to comprehend for a programmer (non expert in feature modeling) or a non programmer. The specific audience -people that want to develop efficient heuristics and have a fine-grained control over the internal details of the solvers -leads to an API design that did not fit all our requirements.

We aimed at providing a much more concise solution with less boilerplate, less technical details about the loaders and the solvers, and also more focused on the essential concepts users want to manipulate -feature models, configurations, and operations on the feature models themselves. In the meantime, we aimed at providing novel operations and a comprehensive environment for reverse engineering, composing, decomposing, and managing (in a broad sense) large-scale feature models.

#1 First try: FAMILIAR, an external DSL

We thus decided to move to a DSL. We created FAMILIAR [START_REF] Mathieu Acher | Familiar: A domain-specific language for large scale management of feature models[END_REF] (for FeAture Model scrIpt Language for manIpulation and Automatic Reasoning) an external DSL with its own syntax and its own environment (editors, interactive console, etc.). Figure 2 gives an example of a FAMILIAR code, see shape #1. The first three lines almost implement the same behavior as the Java code written in SPLAR (see shape #0 in the same figure): loading of a feature model, counting of number of configurations and checking consistency properties. All the results are stored into variables (respectively fm1, n1, and b1). We also developed new facilities for supporting numerous formats and composing ("merge") or decomposing ("slice") feature models. Lines 4 to 6 of the FAMILIAR script load a new feature model (fm2) and compute two new models (fm3 and fm4). The conciseness of the solution, the manipulation of specific abstractions and syntax, the hiding of solver details, the absence of boilerplate code, all are arguments in favor of a larger adoption. We report on some experiences hereafter to illustrate why the shift to a DSL appears to be beneficial. In the context of collaborative research projects in different application domains (military applications, video analysis, system engineering, web development) we collaborated and exchanged with experts usually unfamiliar with feature models and/or programming. Using FAMILIAR facilitated the communication during the meetings or brainstormings. Besides we taught to MSc students in Belgium and France an advanced introduction to feature modeling. Again using FAMILIAR facilitated the communication during the courses and lab sessions. The code we presented and discussed was only about feature modeling ; a well-defined vocabulary (e.g., counting, isValid) unifies the terminology and facilitates a common understanding. Students also experimented advanced aspects of feature modeling like the "merge" and "slice" with a specific environment. In both situations, users can interact with a read-eval-print loop (REPL) to have an immediate evaluation, possibly visual, of the result of the operations. Users can modify of the scripts, if needs be, and repeat the process. REPL and the scripting nature of FAMILIAR allow users to manually verify that the behavior is indeed what is expected, e.g., what have been understood for students.

We also used FAMILIAR code snippet into our scientific publications to ease our explanations (the vocabulary of the language is based on the terminology used by scientists) and to develop other advanced concepts. So far we cannot claim that FAMILIAR was crucial or simply better than existing so-lutions -evaluating the properties of a DSL is a very complex activity and a hot research topic per se we and others are currently investigating. But clearly, as industrial consultants and collaborators, teachers, or scientists, we identified advantages of using the external DSL and its dedicated environment.

#2 The (not so surprising) shift to a fluent Java API

So everything is done in a brave new world? Unfortunately no. The external nature of the DSL posed two kinds of problems.

First, the integration of FAMILIAR into complete applications was trickier than expected. For instance, we used FAMILIAR to model variability of video surveillance processing chains, with the ultimate goal of re-configuring the different vision algorithms according to contextual changes. Calling the FAMILIAR interpreter at runtime -each time a reconfiguration is needed -was clearly not a solution due to performance issues. Programming the "glue" between the adaptation logic, as provided by FAMILIAR, and the actual algorithms of the application was also a problem. We also faced integration problems when deploying configurable scientific services into the grid or when generating web configurators. We needed to operate over feature models and configurations, but in practice, the isolated nature of the external DSL leads to difficult or inefficient connections with the outside world and other software ecosystems (e.g., Java).

Second, the specific boundary of the language naturally limits its expressiveness. It is a desirable property of a DSL to restrict the users to essential language constructs and concepts of a domain. However there may be cons; and it was the case for FAMILIAR. Users wanted to iterate over a collection of feature models, e.g., to rename some features; to check some properties and execute a specific operation, e.g., if the feature model is consistent, the "merging" with another is performed; to reuse some procedures, etc. We added to FAMILIAR some constructs of a general purpose language, like a "foreach"-like loop, an "if-then-else", and ways to define and call reusable scripts. We also added basic facilities for manipulating strings and integers -something offered for free by any general purpose language. Overall we found no elegant solution for comprehensively giving to users the right expressiveness, i.e., so that the language covers all feature modeling scenarios. And eventually we did not want FAMILIAR to resemble a general purpose language.

Due to the lack of integration and expressiveness of the external DSL in some situations, we developed a solution on top of a general purpose language. Specifically we designed a fluent Java API with the goal of being as close as possible to the initial syntax of FAMILIAR. Figure 2 gives the corresponding Java code of the initial FAMILIAR script (see shape #2). The API has the merit of being concise and provides idiomatic facilities for loading a feature model and executing reasoning operations. But compared to FAMILIAR scripts, we identified the following drawbacks. First, the distance with the original syntax leads to less concise code and more boilerplate code. Second, the boundary of the proposed solution is less rigid; domain-specific abstractions are as accessible as internal details of solvers or constructs of a general purpose language. For instance, users run the risk of developing inefficient operations instead of reusing existing ones. It may be relevant for some kinds of users but the experience can be disconcerting for others, e.g., new learners such as students. Third, no specific environment, e.g., with REPL and graphical editors, has been developed, thus making complex the realization of scenarios in which users interactively play with the models and the operations.

#3 Yet another attempt: going internal with FAMISCALE

To overcome some of the previous limitations, we then aimed at reducing the gap with the original FAMILIAR syntax while preserving some integration capabilities with a generalpurpose programming language. We thus developed yet another solution (another internal DSL). We build FAMISCALE on top of the Scala language that notably supports a flexible syntax, implicit type conversions, call-by-name parameters and mixin-class composition. Compared to the Java solution, the gap with FAMILIAR is largely reduced while the Scala interactive interpreter and integration facilities are directly reusable.

The corresponding FAMISCALE code of our feature model example is depicted in the lower part of Figure 2 (see shape #3). It clearly shows the nearness with the original FAMILIAR syntax, but still, one cannot directly interpret some FAMILIAR code. During some recent application, we faced the need to compute some additional metrics on feature models. Coding and integrating them in the software toolchain was very fast and the newly developed functionalities could be added to a future release seamlessly. On the contrary, using the advanced concepts of the Scala host language was a considerable engineering effort and the whole solution is not that close to FAMILIAR. For example handling variable namespaces and parameterized scripts led to a very different solution from FAMILIAR, but with the benefit of a better integration with the programming side of the Scala platform.

All wrong? No. Metamorphic!

So what is the best solution? The fluent Java API? The scripting language (FAMILIAR)? The internal DSL in Scala (FAM-ISCALE)? We considered various tradeoffs, e.g., learnability, expressiveness, reusability, throughout our exploration journey. Our experience is that there is no one-size-fits-all solution or clear superiority of a solution compared to another. We have a better expressiveness with a Java API, but a more difficult solution to apprehend. We have a better interactive environment with FAMILIAR but we cannot realize all feature modeling scenarios -we even doubted at certain points of our development that FAMILIAR is a DSL.

So, are we all wrong from the start? We may have missed a solution that outperforms all the others; or a future programming technology might emerge to develop such a solution. Yet, our experience is that it does make sense to continue the maintenance of external and internal solutions. Rather than choosing between an internal DSL or an external DSL, we argue that both solutions are eventually relevant.

For instance, new learners of feature models benefit from playing with a specific environment and a dedicated, epurated syntax (FAMILIAR). Software engineers make a far better use of the internal DSL to integrate the feature modeling logic as part of their software project. Why forcing a software engineer to use an external DSL? or a student to start with a Java API? Even for a specific kind of user, the different shapes of the language are likely to be useful. For instance, software engineers themselves can prototype a scripting solution with the external DSL, play with the FAMILIAR environment, and eventually get back to the "internal" shape. Different stakeholders can also be part of the process while using different shapes of the solution (see Figure 3). A marketing engineer will more likely use the external DSL to characterize the variability of the system under design, to control some properties of the feature model, etc. Once achieved, the software engineer in charge of connecting the different feature models will go on with the development.

We argue that this situation and scenarios are generalisable in many DSL engineering contexts, beyond SQL and FAMILIAR. Our key point is that the "best" shape of a language heavily depends on the usage context (tasks to perform, kinds of users, etc.): in the FAMILIAR experience, any existing shape we developed has, at some points, some qualities that others do not.

Metamorphic DSL: A Vision For the Future of Languages

Based on our own experience and the analysis of the timehonored evolution of computer languages, we now show how this vision of metamorphic DSLs finds its roots in ongoing work, how it can be defined and what challenges it brings to the community.

Ongoing Work. As we have analyzed in Section 2, some recent work already started to wipe off the gap between the different shapes. For example, some approaches for implementing external DSLs try to incorporate the benefits from internal DSL by supporting the reuse of already implemented languages and tools. For instance, Xtext supports the reuse of language libraries such as Xbase, which come with their whole tooling such as editor, type checker and compiler [START_REF] Efftinge | Xbase: Implementing Domain-specific Languages for Java[END_REF]. Conversely, some approaches try to limit the scope of the host infrastructure that can be reused in an internal DSL to ensure a well-defined isolation of the domain-specific constructs. For example, LMS relies on the staging mechanism to define an external DSL on top of the Scala host infrastructure [START_REF] Rompf | Lightweight Modular Staging: A Pragmatic Approach to Runtime Code Generation and Compiled DSLs[END_REF]. Besides, projectional language workbenches such as Jetbrain's MPS support the projection in a shape of a purely external DSL or as embedded in a host language similarly to internal DSLs [START_REF] Voelter | mbeddr: instantiating a language workbench in the embedded software domain[END_REF]. More generally different strategies for embedding a DSL have been proposed [START_REF] Tratt | Domain Specific Language Implementation via Compile-time Meta-programming[END_REF][START_REF] Erdweg | Sugarj: Library-based syntactic language extensibility[END_REF][START_REF] Hofer | Polymorphic embedding of dsls[END_REF][START_REF] Gill | Domain-specific Languages and Code Synthesis Using Haskell[END_REF]. These recent efforts attempt to integrate the advantages of the different approaches, progressively bridging the gap between them. This is an essential experience to master the various possible bridges and differences between the different shapes. Nevertheless, the same concern (variability or database queries in our example) usually flows through the life cycle, being addressed by different stakeholders with their specific points of view and objectives. Each user expects to manipulate the same programming artefact through the most appropriate shape of the DSL (incl., the whole tooling). For example, a product manager would manipulate SQL queries with plain text SQL and dedicated tools while a software engineer would use an internal DSL (see Figure 3 for an illustrative scenario).

+)))))))))))+)))))))))))))+)))))))))))+))))))))))+))))))))))))+ |'productID'|'productCode'|'name''''''|'quantity'|'gps''''''''| +)))))))))))+)))))))))))))+)))))))))))+))))))))))+))))))))))))+ |''''''
+)))))))))))+)))))))))))))+)))))))))))+))))))))))+))))))))))))+ 6'
Vision. Beyond the unification of the different approaches, the vision that we foresee is the ability of software languages to be self-adaptable to the most appropriate shape (including the corresponding IDE) and according to a particular usage or task. We call metamorphic DSL such a domain-specific language, able to change from one shape to another.

From the same language description, we envision the ability to derive various IDEs that can be used accordingly (see Figure 4). The challenge consists in supporting the manipulation of the same artefact from the different IDEs dedicated to the different points of view, each one with their specific representation as well as integration into a host infrastructure.

In our vision, the same programming artefact could be started in isolation so that a stakeholder could describe her concern with a highly dedicated environment. The same artefact would flow (e.g., refinement, transformation, composi-tion, consistency checking) and be combined to the other concerns until eventually obtaining the final global system. The vision we propose does not conflict with the use of multiple languages [START_REF] Benoit Combemale | Globalizing Modeling Languages[END_REF]. It is rather a way to support their integration for a coordinated development of diverse domain-specific concerns of a system.

The scenario of Figure 3 illustrates the vision on two DSLs, namely SQL and FAMILIAR. It involves different stakeholders (marketing engineer, product manager, software engineer) that aim at providing a configurator of sales product. Each DSL provides two IDEs from the same language definition (incl., one shared by the two DSLs) that can be indifferently used to edit the same conforming artefact. A shared IDE is used as a common infrastructure to integrate the two concerns (e.g., the integration of FAMILIAR and SQL in Java).

Challenges. The integration of multiple metamorphic DSLs raises many challenges. One must still find solutions for the integration of domains, especially between business and technical domains. Systematic methods for evaluating when a shape of a DSL meets the expected properties (e.g., learnability) and is more suitable to another would benefit to developers of DSL, but are far from being complete. The vision also gives rise to questions about the modularization of artefacts. The technical challenge is to share some information, while being able to visualize and manipulate an artefact in a particular representation and in a particular IDE. A global mechanism must ensure consistency of the artefacts between these heterogeneous IDEs.

The ability to shape up a DSL would open a new path for an effective communication between humans and the realization of global software engineering scenarios: could Metamorphic DSLs bring language engineering to the next level, enabling user-driven task-specific support in domainspecific worlds?

Figure 1 .

 1 Figure 1. Three SQL shapes: plain SQL, JOOQ fluent API in Java, Slick API in Scala

Figure 2 .

 2 Figure 2. An example of SPLAR API and three polymorphic variants of the same domain-specific code snippet

  1001'|'PEN'''''''''|'Car'Red'''|'''''5000'|'''''''true'| |''''''1002'|'PEN'''''''''|'Car'Blue''|'''''8000'|'''''''true'| |''''''1003'|'PEN'''''''''|'Car'Black'|'''''2000'|'''''''true'| |''''''1004'|'PEC'''''''''|'Car'2B''''|''''10000'|'''''''true'| |''''''1005'|'PEC'''''''''|'Car'2H''''|'''''8000'|'''''''false| |''''''1006'|'PEC'''''''''|'Car'HB''''|''''''''0'|'''''''false|''

Figure 3 .

 3 Figure 3. Concrete illustration of the vision for integrating a metamorphic SQL and a metamorphic FAMILIAR. Java allows one to generate an IDE for integrating the two languages

Figure 4 .

 4 Figure 4. Metamorphic DSL (abstract scenario)

We use the term people to denote scientists (scholars), software professionals, bloggers, and any person interested in software development and languages.

Acknowledgments

We thank our colleagues Thomas Degueule, Guillaume Bécan, Olivier Barais, Julien Richard-Foy, and Jean-Marc Jézéquel for fruitful comments and discussions on earlier drafts of this paper. We also thank Jonathan Aldrich for his advices and remarks. This work is part of the GEMOC Initiative, and partially funded by the ANR INS Project GEMOC (ANR-12-INSE-0011).