Arthur Charguéraud
email: arthur.chargueraud@inria.fr

Alan Schmitt
email: alan.schmitt@inria.fr

Thomas Wood
email: thomas.wood09@imperial.ac.uk

JSExplain: A Double Debugger for JavaScript

We present JSExplain, a reference interpreter for JavaScript that closely follows the specification and that produces execution traces. These traces may be interactively investigated in a browser, with an interface that displays not only the code and the state of the interpreter, but also the code and the state of the interpreted program. Conditional breakpoints may be expressed with respect to both the interpreter and the interpreted program. In that respect, JSExplain is a double-debugger for the specification of JavaScript.

Indeed, in JS, the evaluation of any sub-expression, of any type conversion, and of most internal operations from the specification may result in the execution of user code, hence the raising of an exception, interrupting the normal control flow. Throught its successive editions, the ECMA standard progressively introduced a notation akin to an exception monad ( §1.2). This notation is naturally translated into real code by a proper monadic bind operator of the exception monad.

Regarding the state, the standard assumes a global state. A reference interpreter could either assume a global state, modified with side-effects, or thread the state explicitly in purely-functional style. We chose the latter approach for three reasons. First, we already need a monad for exceptions, so we may easily extend this monad to also account for the state. Second, starting from code with an explicit state would make it easier to generate a corresponding inductive definition in a formal logic (e.g., Coq), which we would like to investigate in the future. Third, to ease the reading, one may easily hide a state that is explicitly threaded; the converse, materializing a state that is implicit, would be much more challenging.

We thus write our reference interpreter in a purely-functional language extended with syntactic sugar for the monadic notation to account for the state and the propagation of abrupt termination ( §2). For historical reasons, we chose a subset of OCaml as source syntax, but other languages could be used. In fact, we implemented a translator from our subset of OCaml to a subset of JS (a subset involving no side effects and no type conversions). We thereby obtain a JS interpreter that is able to execute JS programs inside a JS virtual machine-JS fans should be delighted. To further improve accessibility to JS programmers, we also translate the source code of our interpreter into a human-readable JS-style syntax, which we call pseudo-JS, and that essentially consists of JS syntax augmented with a monadic notation and with basic pattern matching.

Our reference semantics for JS is inherently executable. We may thus execute our interpreter on test suites, either by compiling and executing the OCaml code, or by executing the JS translation of that code. It is indeed useful to be able to check that the evaluation of examples from the JS test suites against our reference semantics produces the desired output.

Even more interesting is the possibility to investigate, step by step, the evaluation of the interpreter on a given test case. Such investigation allows to understand why the evaluation of a particular test case produces a particular output-given the complexity of JS, even an expert may easily get puzzled by the output value of a particular piece of code. Furthermore, interactive execution makes it easier for the contributor of a new JS feature to add new test cases and to check that these tests trigger the new features and correctly interact with existing features.

In this paper, we present a tool, called JSExplain, for investigating JS executions. This tool can be thought as a double debugger, which displays both the state of the interpreted program and that of the interpreter program. In particular, our tool supports conditional breakpoints expressed simultaneously on the interpreter program and the interpreted program. To implement this tool, we generate a version of our interpreter that is instrumented for producing execution traces ( §3), and we provide a web-based tool to navigate through such traces ( §4). As far as we know, our tool is the first such double debugger, i.e., debugger with specific additions for dealing with programs that interpret other programs ( §5).

English Specification of JS

To illustrate the style in which the JavaScript standard (ECMA) [START_REF]Ecmascript 2017 language specification[END_REF] is written, consider the description of addition, which will be our running example throughout the paper. In JS, the addition operator casts its arguments to integers and computes their sum, except if one of the two arguments is a string, in which case the other argument is cast to a string and the two strings are concatenated.

The ECMA5 presentation (prior to June 2016) appears in Figure 1. First, observe that the presentation describes both the parsing rule for addition and its evaluation rule. Presumably for improved accessibility, the JS standard does not make explicit the notion of an abstract syntax tree (AST). The semantics of addition goes as follows: first evaluate the left branch to a value, then evaluate the right branch to a value, then converts both values (which might be objects) into primitive values (e.g., string, number, ...), then test whether one of the two arguments is a string. If so, cast both arguments to strings and return their concatenation; otherwise cast both arguments to numbers and return their sum.

This presentation style used in ECMA5 gives no details about the propagation of exceptions. While the treatment of exceptions is explicit for statements, it is left implicit for expressions. For example, if the evaluation of the left branch raises an exception, the right branch should not be evaluated. It appeared that leaving the treatment of exceptions implicit could lead to ambiguities at what exactly should or should not be evaluated when an exception gets triggered. The ECMA committee hates such ambiguities, because it could (and typically does) result in different browsers exhibiting different behaviors-the nightmare of web-developers.

In ECMA6, such ambiguities were resolved by making the propagation of exceptions explicit. Figure 2 shows the updated specification for the addition operator. There are two main changes. First, each piece of evaluation is described on its own line, thereby making the evaluation order crystal clear. Second, the meta-operation ReturnIfAbrupt is invoked on every intermediate result. This metaoperation essentially corresponds to an exception monad. The ECMA6 standards, which aims to be accessible to a large audience, avoids the introduction of the word "monad". Instead, it specifies ReturnIfAbrupt as a "macro", as shown in Figure 3. Essentially, every result consists of a "completion record", which corresponds to a sum type distinguishing normal results from exceptions.

In all constructs except try-catch blocks, exceptions interrupt the normal flow of the evaluation. As a result, ECMA6 specification is scattered with about 1100 occurences of ReturnIfAbrupt operations. Realizing the impracticability of that style of specification, the standardization committee decided to introduce in ECMA7 an additional layer of syntactic sugar in subsequent versions of the Evaluation of: AdditiveExpression : AdditiveExpression + MultiplicativeExpression 1. Let lref be the result of evaluating AdditiveExpression. 2. Let lval be GetValue(lref). 3. Let rref be the result of evaluating MultiplicativeExpression. 4. Let rval be GetValue(rref). 5. Let lprim be ToPrimitive(lval). 6. Let rprim be ToPrimitive(rval). 7. If Type(lprim) is String or Type(rprim) is String, then -Return the String that is the result of concatenating ToString(lprim) followed by ToString(rprim). 8. Return the result of applying the addition operation to ToNumber(lprim) and ToNumber(rprim). specification. As detailed in Figure 4, they define the question mark symbol to be a lightweight shorthand for ReturnIfAbrupt steps. The specification of addition in that new style is shown in Figure 5.

The presentation of ECMA7 and ECMA8 (Figure 5) is both more concise than that of ECMA6 (Figure 2) and more formal than that of ECMA5 (Figure 1). The use of question marks is to be compared in §2 with the monadic notation that we use for our formal semantics.

Requests from the JS Committee

The JavaScript standardization body, part of ECMA and known as TC39, includes representatives from browser vendors, major actors of the web, and academics. It aims at defining a common semantics that all browsers should implement. TC39 faces major challenges. On the one hand, it must ensure full backward compatibility, to avoid "breaking the web". In particular, no feature used in the wild ever gets removed from the specification. On the other hand, the committee imposes the rule that no feature may be added to the standard before it has been implemented, shipped, and tested at scale in at least two distinct major browsers. Any member of the committee may propose new features, hence there are many proposals being actively developed, at different stages of formalization [START_REF]TC39 proposals[END_REF].

The rapid evolution of the standard stresses the need for appropriate tools to assist in the rewriting, testing, and debugging of the semantics. In particular, several members with whom we have had interactions expressed their need for several basic tools, such as:

• a tool for knowing whether all variables that occur in the specification are properly defined (bound) somewhere; • a tool to perform basic type-checking of the meta-functions and of the variables involved in the specification; • a tool for checking that effectful operations go on a line of their own, to avoid ambiguity in the order of evaluation; • a tool for checking that the behavior is specified in all cases; Evaluation of: AdditiveExpression : AdditiveExpression + MultiplicativeExpression 1. Let lref be the result of evaluating AdditiveExpression. 2. Let lval be ? GetValue(lref). 3. Let rref be the result of evaluating MultiplicativeExpression. 4. Let rval be ? GetValue(rref). 5. Let lprim be ? ToPrimitive(lval). 6. Let rprim be ? ToPrimitive(rval). 7. If Type(lprim) is String or Type(rprim) is String, then a. let lstr be ? ToString(lprim). b. let rstr be ? ToString(rprim). c. Return the String that is the result of concatenating lstr and rstr. 8. let lnum be ? ToNumber(lprim). 9. let rnum be ? ToNumber(rprim). 10. Return the result of applying the addition operation to lnum and rnum. • a tool able to tell which lines from the specification are not covered by any test from the main test suite (test262 [15]); • a tool able to execute step-by-step the specification on concrete JS programs, and to inspect the value of the variables.

In particular, step-by-step execution is critically needed to evaluate new features. When the committee decides that a feature proposal is worth integrating, it typically does not accept the proposal as is, but instead modifies the proposal in a way that is amenable to a simple, clear specification without corner cases, carefully trying to avoid harmful interactions with other existing features (or planned features). During this process, at some point the committee members have in their hand a draft of the extended semantics as well as a collection of test cases illustrating the new behaviors that should be introduced. Naturally, they would like to check that their formalization of the extended semantics assigns the expected behavior to each of the test cases.

One might argue that such a task could be performed by modifying one of the mainstream browsers. Yet, existing JS runtimes are built with efficiency in mind, with huge code bases involving numerous optimizations. As such, modifying the code in any way is too costly for committee members to investigate variations on a feature request. Even if they could invest the effort, the distance between the English prose specification and the implementation would be too large to have any confidence that the two match, i.e., that the behavior implemented in the code matches the behavior described by the prose.

An alternative approach to testing a new feature is to develop an elaboration (local translation) of that feature into plain JS. This can take the form of syntactic sugar adding a missing API, namely a polyfill, or the form of a source to source translation, namely a transpiler. For instance, one might translate so-called "template literals" into simple string concatenation.

While polyfills and transpilers are a simple approach to testing new features, they have two major limitations. First, the encoding might be very invasive. For instance, the 2015 version of ECMAScript added proxies, and as a consequence significantly changed the internal methods of the language; the Babel [1] transpiler for proxies [START_REF]Babel proxy plugin[END_REF] is able to simulate this feature in prior version of JS, but at the cost of replacing all field access operations with calls to wrapper functions. Second, the interaction of several new features implemented using these approaches is very difficult to anticipate.

Formal Specifications of JS

In recent years, two projects, JSCert [START_REF] Bodin | A trusted mechanised javascript specification[END_REF] and KJS [START_REF] Park | KJS: a complete formal semantics of javascript[END_REF] have proposed a formal specification for a significant subset of JS. JSCert provides a big-step inductive definition for ECMA5, (technically, a pretty-bigstep specification [START_REF] Charguéraud | Pretty-big-step semantics[END_REF]), formalized in the Coq proof assistant [START_REF]The Coq proof assistant reference manual[END_REF]. JSCert comes along with a reference interpreter, called JSRef, that is proved correct with respect to the inductive definition. JSRef may be extracted into executable OCaml code for executing tests. KJS describes a small-step semantics for JS as a set of rewriting rules, using the K framework [START_REF] Rosu | An overview of the K semantic framework[END_REF]. This framework has been used to formalize the semantics of several other real-world languages. It provides in particular tool support for executing (syntax-directed) transition rules on a concrete input program.

At first sight, it might seem that a formal specification addresses all the requests from the committee. Definitions are thoroughly type-checked; in particular, all variables must be properly bound. Definitions, being defined in a formal language, are ambiguityfree; in particular, the order of evaluation and the propagation of exceptions is precisely specified. The semantics can be executed on concrete input programs; moreover, with some extra tooling, one may execute a set of programs and report on the coverage of the specification by the tests.

Given all the nice features of formal semantics, why wouldn't the standardization committee TC39 consider one of these formal semantics as the reference for the language? After discussing with senior members from TC39, we understand that there are (at least) three main reasons why there is no chance for a formal semantics such as JSCert or KJS to be adopted as reference semantics.

(1) Formal specifications in Coq or in K use syntax and concepts that are not easily accessible to JS programmers. Yet, the specification is meant to be read by a wide audience. (2) These formal languages have a cost of entry that is too high for committee members to reach the level of proficiency required for contributing new definitions all by themselves. (3) JSCert and KJS come with specifications that can be executed, yet provide no debugger-style support for interactively navigating through an execution and for visualizing the state and the values of the variables, and thus do not help so much in tuning the description of new features.

In the present work, we temporarily leave aside the motivation of giving a formal semantics to JS that one could use to formalize properties of the language (e.g., security properties), and rather focus on trying to provide a formal semantics that meets better the day-to-day needs of the TC39 committee.

Contribution

In this paper, we present a tool, called JSExplain, which aims at providing a formal semantics for JS that addresses the aforementioned limitations of prior work. Our contribution is two-fold. First, we present a specification for JS expressed in a language that, we argue, JS programmers can easily read and write ( §2). Second, we present an interactive tool that supports step-by-step execution of the specification on an input JS program ( §3 and §4). Our tool mimics the features of a debugger, such as navigation controls, state and variable visualization, and conditional breakpoints, but does so for both the interpreter program and the interpreted program.

The language in which we display the specification consists of a subset of JS extended with syntactic sugar for monads and basic pattern matching. This language, which we call pseudo-JS, could be the source syntax for our specification. However, for historical and technical reasons, we use as input syntax a subset of OCaml, which is processed using the OCaml type-checker. Our current tool automatically converts the OCaml AST into pseudo-JS code. In the future, we might as well have our reference interpreter be directly in pseudo-JS syntax, and we could typecheck that code either by converting it to OCaml or by reimplementing a basic ML typechecker. A third alternative would be to use the Reason syntax [START_REF][END_REF], a JS-like syntax for OCaml programs. The only difference between the approaches is whether TC39 committee members would prefer to write OCaml style or JS style code.

SPECIFICATION LANGUAGE 2.1 Constructs of the Language

The input syntax in which we write and display the specification is a purely-functional language that includes the following constructs: variables, constants, sequence, conditional, let-binding, function definition, function application (with support for prefix and infix functions), data constructors, records (including record projections, and the "record-with" construct to build a copy of a record with a number of fields updated), tuples (i.e., anonymous records), and simple pattern matching (only with non-nested patterns, restricted to data constructors, constants, variables, and wildcards). For convenience, let-bindings and functions may bind patterns (as opposed to only variables).

We purposely aim for a specification language with a limited number of constructs and a very standard semantics, to minimize the cost of entry into that language. Note that the input code is typechecked in ML. (Polymorphism is used mainly for type-checking options and lists, and operations on them.)

As explained earlier ( §1.2), the semantics involves the propagation of exceptions and other abrupt behaviors (break, continue, and return). Their propagation can be described within our small language, using functions and pattern matching. Nevertheless, introducing a little bit of syntactic sugar greatly improves readability. For example, we write "let%run x = e1 in e2" to mean "if_run e1 (fun x -> e2)", where if_run is a function that implements our monad.

The monadic operator if_run admits a polymorphic type, hence functions from the specification may return objects of various types. Nevertheless, in practice most functions from the ECMA standard Figure 6: Current input syntax of our specification language: a subset of pure OCaml, extended with monadic notation.

are described as returning a "completion triple", which either describe abrupt termination or describe a value. In a number of cases, the value is in fact constrained to be of a particular type. For example, if to_number produces a value, then this value is necessarily a number. The standard exploits this invariant implicitly in formulation such as "let n be the number produced by calling to_number".

In constrast, our code needs to explicitly project the number from the value returned. To that end, we introduce specialized monads such as if_number, written in practice "let%number n = e1 in e2".

(An alternative approach would be to assign polymorphic types to completion triples, however following this route would require diverging slightly from ECMA's specification in a number of places.) Figure 6 shows the specification of addition in our reference interpreter, in OCaml syntax extended with the monadic notation. This code implements its informal equivalent from Figure 2. In that code, s denotes the state, c denotes the environment (variable and lexical environment, in JS terminology), op corresponds to the operator (here, the constructor C_binary_op_add corresponds to the AST token describing the operator +), v1 and v2 corresponds to the arguments, and w1 and w2 to their primitive values. The function strappend denote string concatenation, whereas "+." denotes addition on floating pointer numbers (i.e., JS's numbers).

First observe that, as explained earlier ( §1.1), the state is threaded throughout the code. We show in the next section how to hide the state variables ( §2.2). Observe also that the code also relies on a few auxiliary functions. The function type_compare implements comparison over JS types-to keep our language small and explicit, we do not want to assume a generic comparison function with nontrivial specification. The functions to_primitive_def, to_string, and to_number are internal functions from the specification that implement conversions. These operations might end up evaluating arbitrary user code, and thus could perform side-effects or raise exceptions, hence the need to wrap them in monadic let-bindings.

One important feature of this source language is that it does not involve any "implicit" mechanism. All type conversions are explicit in the code, so it is always perfectly clear what is meant. In particular, there is no need to type-check the code to figure out its semantics. In summary, the OCaml code of the interpreter (e.g., Figure 6) is well-suited as a non-ambiguous input language. Note that this code may be compiled using OCaml's compiler in order to run test cases; the current version of our interpreter passes more than 5000 test cases from the official test suite (test262).

Translation into Pseudo-JS Syntax

Although we believe that it is a desirable feature to have a source langage fully explicit, there is also virtue in pretty-printing the source code of our interpreter in a more concise syntax. The "noise" that appears in the formal specification (e.g. Figure 6) comes from three main sources:

(1) every function takes as argument the environment;

(2) every function takes as argument and returns a description of the mutable state (a.k.a. heap);

(3) values are typically built using numerous constructors, e.g. C_value_prim, which lifts a number (an OCaml value of type float) into a JS value (an OCaml value of type value).

Fortunately, we can easily eliminate these three sources of noises. First, the environment is almost always passed unchanged. It may be modified only during the scope of a function call, a with construct, or a block. When it is modified, new bindings are simply pushed into the environment (which behaves like a stack), and subsequently popped. Thus, we may assume, like the ECMA specification does, that the environment is stored in a global state. This saves the need to pass an argument called "c" around.

Second, the description of the mutable state is threaded through the code. The "current state" is passed as argument to every function that might perform side-effects, and, symmetrically, the "updated state" is returned to the caller, which binds a fresh name for it. Considering that there is only one version of the state at any given point of an execution, we may assume, like the ECMA specification does, that state to be stored in a global variable. This saves the need to pass values called "s1", "s2"... around.

Third, the presence of many constructors is due to the need for casts. Many of these casts could, however, be viewed as "implicit casts" (or "coercions", in Coq's terminology). For a carefully chosen set of casts, defined once and for all, and for a well-typed program with implicit casts, there exists a unique (non-ambiguous) way to insert casts in order to make the program type-check. Although we have previously argued that explicit casts are useful, as they allow giving a semantics that does not depend on type-checking, we now argue that it may also be useful to pretty-print the code assuming implicit casts, in order to improve readability.

In summary, we propose to the reader of the specification a version that features implicit state, implicit context, and implicit casts. Given that we are playing the game of pretty-printing syntax, we take the opportunity to switch along the way to a JS-friendly syntax, using brackets and semicolons. This target language, called pseudo-JS syntax, consists of a subset of the JS syntax, extended with monadic notation, and an extended switch construct that is able to bind variables (like OCaml's pattern matching, but restricted to non-nested patterns for simplicity).

The pretty-printing of the addition operator in pseudo-JS syntax appears in Figure 7. To illustrate our extended pattern matching syntax feature of pseudo-JS, we show below an excerpt from the main switch that interprets an expression.

switch (t) { case Coq_expr_identifier(x):

var%run r = identifier_resolution(x); return (r); case Coq_expr_binary_op(e1, op, e2): ...

TRACE-PRODUCING EXECUTIONS

JSExplain is a tool for interactively investigating execution traces of our JS interpreter executing example JS programs. The interface consists of a web page [START_REF][END_REF] that embeds a JS parser and a traceproducing version of our interpreter implemented in standard JS.

So far, we have shown how to translate the OCaml source into pseudo-JS syntax ( §2.2). In this section, we explain how to translate the OCaml source into proper JS syntax, and then how to instrument the JS code in a systematic way for producing execution traces.

Figure 8 illustrates the output of translating from our OCaml subset towards JS. Note that this code is not meant for human consumption. We implement monadic operators as function calls, introduce the return keyword where necessary, encode sum types as object literals with a tag field, encode tuples as arrays (encoding tuples as object literals would work too), turn constructor applications into functions calls, implement pattern matching by first switching on the tag field then binding fresh variables to denote the arguments of constructors.

We thus obtain an executable JS interpreter in JS which, like our JS interpreter in OCaml, may be used for executing test cases. One interest of the JS version is that it may be easily executed inside a browser, a set up that might be more convenient for a number of users. One limitation, however, is that the number of steps that can be simulated may be limited on JS virtual machines that do not optimize tail-recursive function calls. Indeed, the execution of monadic code involves repeated calls to continuations, whose (tail-call) invocation unnecessarily grows the call stack.

To set up our interactive debugger, we produce, from our OCaml source code, an instrumented version of the JS translation. This instrumented code produces execution traces as a result of interpreting an input JS program. These traces store information about all the states that the interpreter goes through. In particular, each event in the trace provides information about the code pointer and the instantiations of local variables from the interpreter code.

More precisely, we log events at every entry point of a function, every exit point, and on every variable binding. Each event captures the state, the stack, and the values of all local variables in scope of the interpreter code at the point where the event gets triggered. To reduce noise in the trace, we only log events in the core code of the interpreter, and not the code from the auxiliary libraries. Overall, an execution of the instrumented interpreter on some input JS program produces an array of events. This array can then be investigated using our double debugger ( §4). Figure 9 shows an example snippet of code, giving an idea of the mechanisms at play. Note, again, that this code is not meant for human consumption. The function log_event augments the trace. Consider for instance log_event("Main.js", 4033, ctx_747, "enter"). The first two arguments identify the position in the source file, as a file name and a unique token used to recover the line numbers. The third argument is a context describing values of the local variables, and the fourth argument describes the type of event.

When investigating the trace, we need to be able to highlight the corresponding line of the interpreter code. We wish to be able to do so for the three versions of the interpreter code: the OCaml version, the pseudo-JS version, and the plain JS version. To implement this feature, our generator, when processing the OCaml source code, also produces a table that maps, for each version and for each file of the interpreter, event tokens to line numbers.

The contexts stored in events are extended each time a function is entered, a new variable is declared, or the function returns (so as to capture the returned value). Contexts are represented as a purelyfunctional linked list of mappings between variable names and values. This representation maximizes sharing and thus minimize the memory footprint of the generated trace. The length of the trace grows linearly with the number of execution steps performed. For example, the simple program "var i = 0; while (i < N) { i++ }" var run_binary_op_add = function (s0, c, v1, v2) { var ctx_747 = ctx_push(ctx_empty, [{key: "s0", val: s0}, {key: "c", val: c}, {key: "v1", val: v1}, {key: "v2", val: v2}]); log_event("JsInterpreter.js", 4033, ctx_747, "enter"); var _return_1719 = if_prim((function () { log_event("JsInterpreter.js", 3985, ctx_747, "call"); var _return_1700 = to_primitive_def(s0, c, v1); log_event("JsInterpreter.js", 3984, ctx_push(ctx_747, [{key: "#RETURN_VALUE#", val: _return_1700}]), "return"); return (_return_1700); }()), function(s1, w1) { ... }); log_event("JsInterpreter.js", 4028, ctx_push(ctx_748, [{key: "#RETURN_VALUE#", val: _return_1718}]), "return"); return (_return_1718); }); log_event("JsInterpreter.js", 4032, ctx_push(ctx_747, [{key: "#RETURN_VALUE#", val: _return_1719}]), "return"); return (_return_1719); }; The fact that these numbers are large reflects the fact that the reference interpreter is inherently vastly inefficient, as it follows the specification faithfully, without any optimization. Due to our use of functional data structures, the memory footprint of the trace should be linear in the length of the trace. We have not observed the memory footprint to be a limit, but if it were we could more carefully select which events should be stored.

JSEXPLAIN: A DOUBLE DEBUGGER FOR JS

The global architecture of JSExplain is depicted in Figure 10. Starting from our JS interpreter in OCaml, we generate a JS interpreter in JS. We instrument the JS code to produce a trace of events. This compilation is done ahead of time and depicted by solid arrows.

When hitting the run button, the flow depicted by the dotted arrows occurs. The web page parses the code from the text area, using the Esprima library [START_REF]ECMAScript parsing infrastructure for multipurpose analysis[END_REF]. This parser produces an AST, with nodes annotated with locations. This AST is then provided as input to the instrumented interpreter, which generates a trace of events. This trace may then be inspected and navigated interactively.

For a given event from the execution trace, our interface highlights the corresponding piece of code from the interpreter, and shows the values of the local variables, as illustrated in Figure 11. It also highlights the corresponding piece of code in the interpreted program, as illustrated at the top of Figure 13, and displays the state and the environment of the program at that point of the execution, as illustrated in Figure 12.

Recovering the information about the interpreted code is not completely straightforward. For example, to recover the fragment of code to highlight, we find in the trace the closest previous event that contains a call to function with an argument named _term_. This argument corresponds to the AST of a subexpression, and this AST is decorated (by the parser) with locations. Note that, for efficiency reasons, we associate to each event from the trace its corresponding _term_ argument during a single pass, performed immediately after the trace is produced.

Similarly, we are able to recover the state and environment associated with the event. The state of the interpreted program consists of four fields: the strictness flag, the value of the this keyword, the lexical environment, and the variable environment. We implemented a custom display for these elements, and also for values of the languages, in particular for objects: one may click on an object to reveal its contents and recursively explore it.

We provide several ways to navigate the trace. First, we provide buttons for reaching the beginning or end of the execution, and buttons for stepping one event at a time. Second, we provide, similarly to debuggers, next and previous buttons for skipping function calls, as well as a finish button to reach the end of the current function. These features are implemented by navigating the trace, keeping track of the number of enter and return events. Third, we provide buttons for navigation based not on steps related to the interpreter program but instead based on steps of the interpreted program: source previous and source next find the closest event which induces a change in the location on the subexpression evaluated in the interpreted code, and source cursor finds the last event in the trace for which the associated subexpression contains the active cursor in the "source program" text area.

The aforementioned tools are sufficient for simple explorations of the trace, yet we have found that it is sometimes useful to reach events at which specific conditions occur, such as being at a specific line in the interpreter, in the interpreted code, with variables from the interpreter or interpreted code having specific values. We thus provide a text box to enter arbitrary breakpoint conditions to be evaluated on events from the trace. For example, the condition in Figure 13 reaches the next occurrence of a call to run_binary_op_add in a context where the source variable j has value 1. The break point condition may be any JS expression using the following API: I_line() returns the current line of the interpreter, S_line() returns the current line of the source, I('x') returns the value of x in the interpreter, S_raw('x') returns the value of x in the source (e.g. the JS object {tag: "value_number", arg: 5}), and S('x') returns the JS interpretation of the value of x in the source (e.g. the JS value 5).

RELATED WORK

There are many formal semantics of JavaScript, from pen-and-paper ones [START_REF] Maffeis | An operational semantics for javascript[END_REF], to the aforementioned JSCert [START_REF] Bodin | A trusted mechanised javascript specification[END_REF] and KJS [START_REF] Park | KJS: a complete formal semantics of javascript[END_REF]. As described in §1.4, these semantics are admirable but lack crucial features to be actively used in the standardization effort.

To our knowledge, the closest work to the double-debugger approach is the multi-level debugging approach of Kruck et al. [START_REF] Kruck | Multi-level debugging for interpreter developers[END_REF]. They present a debugger for an interpreter for domain-specific languages that lets developers choose the level of abstraction at which they debug their program. An abstraction is a way to display some values (encoded in the host language, or as present in the DSL) as well as showing only stack frames that represent computation at the DSL level. Our technique is more general as it does not focus on domain-specific languages.

In fact, our double-debugger approach could be easily adapted to interpreter for other languages than JS. To that end, it suffices to implemented an interpreter for the desired language in the subset of OCaml that we support, and to provide code for extracting and displaying the term and state associated with a given event. We have recently followed that approach and adapted our framework to derive a double-debugger for (a significant subset of) the OCaml programming language.

Regarding the translation from OCaml to JS that we implement, one might consider using an existing, general-purpose tool. Js_of_ocaml [START_REF] Vouillon | From bytecode to javascript: the js_of_ocaml compiler[END_REF] converts OCaml bytecode into efficient JS code. Presumably, we could implement the logging instrumentation as an OCaml source-to-source translation and then invoke Js_of_ocaml. Yet, with that approach, we would need to convert the representation of trace events from the encoding of these values performed by Js_of_ocaml into proper JS objects that we can display in the interactive interface. This conversion is nontrivial, as some information, such as the name of constructors, is lost in the process. As we already implemented a translator from OCaml to pseudo-JS, it was simpler to implement a translator from OCaml to plain JS.

Another translator from OCaml to JS is Bucklescript [START_REF]Bucklescript[END_REF], which was released after we started our work. Similarly to our translator, Bucklescript converts OCaml code into JS code advertised as readable. Bucklescript also has the limitation that the names of constructors are lost, although presumably this could be easily fixed. Besides, if we wanted to revisit our implementation to base it on Bucklescript, for trace generation we would need to either modify Bucklescript, which is quite complex as it covers the full OCaml language, or to reimplement trace instrumentation at the OCaml level, which should be doable yet would involve a bit more work than at the level of untyped JS code.

CONCLUSION AND FUTURE WORK

We presented JSExplain to TC39 1 and the committee expressed strong interest. They would like us to extend our specification to cover all of the specification. We have almost finished the formalization of proxies, which are a challenging addition to the language as they change many internal methods. Although all members seem to agree that the current toolset for developing the specification is inappropriate, it requires a strong leadership and a consensus to commit to a new toolchain. Our goal is to cover the current version of ECMAScript, we currently cover ECMAScript 5, and to help committee members use it to formalize new additions to JavaScript.

There are numerous directions for future work. (1) We plan to set up a modular mechanism for describing unspecified behaviors (e.g. "for-in" enumeration order) as well as browser-specific behaviors (sometimes browsers deviate from the specification, for historical reasons). (2) We could investigate the possibility of extending the formalization of the standard by also covering the parsing rules of JS; currently, our semantics is expressed with respect to the AST of the input program. (3) To re-establish a link with the original JSCert inductive definition, which is useful for conducting formal proofs about the metatheory of the langage, we would like to investigate 1 https://tc39.github.io/tc39-notes/2016-05_may-25.html#jsexplain-as--tw the possibility of automatically generating pretty-big-step [START_REF] Charguéraud | Pretty-big-step semantics[END_REF] definitions from the reference semantics expressed in our small language, possibly using some amount of annotation to guide the process. (4) To close even further the gap between a formal language and the English prose, we could also investigate the possibility of automatically generating English sentences from the code. Indeed, the prose from the ECMAScript standard is written in such a systematic manner that this should be doable, at least to some extent.

Figure 1 :

 1 Figure 1: ECMA5 specification of addition.

Figure 2 :

 2 Figure 2: ECMA6 specification of addition.

Figure 4 :

 4 Figure 4: ECMA7 and ECMA8 addition for ReturnIfAbrupt.

Figure 5 :

 5 Figure 5: ECMA7 and ECMA8 specification of addition.

and

  run_binary_op s c op v1 v2 = match op with | C_binary_op_add -> run_binary_op_add s c v1 v2 ... and run_binary_op_add s0 c v1 v2 = let%prim (s1, w1) = to_primitive_def s0 c v1 in let%prim (s2, w2) = to_primitive_def s1 c v2 in if (type_compare (type_of (Coq_value_prim w1)) Coq_type_string) || (type_compare (type_of (Coq_value_prim w2)) Coq_type_string) then let%string (s3, str1) = to_string s2 c (Coq_value_prim w1) in let%string (s4, str2) = to_string s3 c (Coq_value_prim w2) in res_out (Coq_out_ter (s4, (res_val (Coq_value_prim (Coq_prim_string (strappend str1 str2)))))) else let%number (s3, n1) = to_number s2 c (Coq_value_prim w1) in let%number (s4, n2) = to_number s3 c (Coq_value_prim w2) in res_out (Coq_out_ter (s4, (res_val (Coq_value_prim (Coq_prim_number (n1 +. n2))))))

Figure 7 :

 7 Figure 7: Generated code for the interpreter in pseudo-JS syntax, with implicit environments, state, and casts.

Figure 8 :

 8 Figure 8: Snippet of generated code for the interpreter in standard JS syntax, without trace instrumentation.

Figure 9 :Figure 10 :

 910 Figure 9: Snippet of generated code for the interpreter in standard JS syntax, with trace instrumentation.

Figure 11 :Figure 12 :

 1112 Figure 11: Display of the variables from the interpreter code

Figure 13 :

 13 Figure 13: Example of a conditional breakpoint, constraining the state of both the interpreter and the interpreted code.

/* new feature */ /* plain JavaScript */ var name = "me"; var name = "me"; `hello ${name}`;"hello " + name;

ACKNOWLEDGMENTS

We acknowledge funding from the ANR project AJACS ANR-14-CE28-0008 and the CominLabs project SecCloud.


Dr Christèle Dubourg
email: christele.dubourg@chu-rennes.fr

Wilfrid Carré

Houda Hamdi-Rozé

Charlotte Mouden

Joëlle Roume

Benmansour Abdelmajid

Daniel Amram

Clarisse Baumann

Nicolas Chassaing

Christine Coubes

Laurence Faivre-Olivier

Emmanuelle Ginglinger

Marie Gonzales

Annie Levy-Mozziconacci

Sally-Ann Lynch

Sophie Naudion

Laurent Pasquier

Amélie Poidvin

Fabienne Prieur

Pierre Sarda

Annick Toutain

Valérie Dupé

Linda Akloul

Sylvie Odent

Marie De Tayrac

Véronique David

Mutational Spectrum in Holoprosencephaly Shows That FGF is a New Major Signaling Pathway

Keywords: Holoprosencephaly, FGF signaling pathway, multigenic inheritance, targeted NGS, brain malformation

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

INTRODUCTION

Holoprosencephaly (HPE; MIM# 236100) is the most frequent congenital brain malformation (1 in 10,000 live births, 1 in 250 conceptuses). It results from incomplete midline division of the prosencephalon between 18 th and 28 th day of gestation, affecting both the forebrain and the face [START_REF] Dubourg | Holoprosencephaly[END_REF][START_REF] Marcorelles | Neuropathology of holoprosencephaly[END_REF]. The clinical spectrum is very wide, ranging from severe HPE with a single cerebral ventricle and cyclopia to clinically unaffected carriers in familial HPE. Three classic anatomical classes have been described, in decreasing order of severity: alobar, semi-lobar, and lobar HPE. The full spectrum of HPE includes also middle interhemispheric variants (MIH) or syntelencephaly, septopreoptic HPE and microforms characterized by midline defects (eg, single maxillary median incisor (SMMI) or hypotelorism) without the brain malformations typical of HPE [START_REF] Barkovich | Analysis of the cerebral cortex in holoprosencephaly with attention to the sylvian fissures[END_REF][START_REF] Hahn | Septopreoptic holoprosencephaly: a mild subtype associated with midline craniofacial anomalies[END_REF][START_REF] Lazaro | Phenotypic and molecular variability of the holoprosencephalic spectrum[END_REF][START_REF] Simon | The middle interhemispheric variant of holoprosencephaly[END_REF].

Not only is HPE highly variable phenotypically, but also very heterogeneous etiologically [START_REF] Bendavid | Holoprosencephaly: An update on cytogenetic abnormalities[END_REF][START_REF] Pineda-Alvarez | Current recommendations for the molecular evaluation of newly diagnosed holoprosencephaly patients[END_REF][START_REF] Roessler | The molecular genetics of holoprosencephaly[END_REF]. HPE may be due to chromosome abnormalities, such as trisomy 13, 18, and triploidy, or may be one of the components of a multiple malformation syndrome, such as Smith-Lemli-Opitz or CHARGE syndrome. The Hartsfield syndrome associates HPE with ectrodactyly, with and without cleft lip and palate. HPE may also result from exposure to maternal diabetes during gestation [START_REF] Johnson | Non-genetic risk factors for holoprosencephaly[END_REF][START_REF] Miller | Risk factors for nonsyndromic holoprosencephaly in the National Birth Defects Prevention Study[END_REF]. Isolated HPE presents a high genetic heterogeneity. To date heterozygous mutations in 15 genes have been identified in HPE patients with four major genes (Sonic hedgehog or SHH MIM# 600725, ZIC2 MIM#603073, SIX3 MIM# 603714, TGIF1 MIM# 602630), and eleven genes that are [START_REF] Arauz | A hypomorphic allele in the FGF8 gene contributes to holoprosencephaly and is allelic to gonadotropin-releasing hormone deficiency in humans[END_REF][START_REF] Bae | Mutations in CDON, encoding a hedgehog receptor, result in holoprosencephaly and defective interactions with other hedgehog receptors[END_REF][START_REF] Bendavid | Holoprosencephaly: An update on cytogenetic abnormalities[END_REF][START_REF] Dupe | NOTCH, a new signaling pathway implicated in holoprosencephaly[END_REF][START_REF] Mouden | Homozygous STIL Mutation Causes Holoprosencephaly and Microcephaly in Two Siblings[END_REF][START_REF] Pineda-Alvarez | Missense substitutions in the GAS1 protein present in holoprosencephaly patients reduce the affinity for its ligand, SHH[END_REF]. These genes encode proteins playing a role in early brain development, which mostly belong to the signaling pathway Shh, and to a lesser extent Nodal and Fgf pathways [START_REF] Arauz | A hypomorphic allele in the FGF8 gene contributes to holoprosencephaly and is allelic to gonadotropin-releasing hormone deficiency in humans[END_REF][START_REF] Mercier | NODAL and SHH dose-dependent double inhibition promotes an HPE-like phenotype in chick embryos[END_REF]. Mutations in SHH, SIX3 and TGIF1 are inherited from an unaffected parent or parent harboring only a microform of HPE in 70% of the cases [START_REF] Mercier | New findings for phenotypegenotype correlations in a large European series of holoprosencephaly cases[END_REF]. It suggests that other events are necessary to develop the disease. Consequently, the mode of inheritance initially described as autosomal dominant with an incomplete penetrance and a variable expression has been redefined [START_REF] Odent | Segregation analysis in nonsyndromic holoprosencephaly[END_REF][START_REF] Mouden | Complex mode of inheritance in holoprosencephaly revealed by whole exome sequencing[END_REF]. HPE is now listed as a polygenic disease having multiple inheritance modes. Among them, polygenic inheritance would require two or more events involving genes from the same or different signaling pathways with functional relationship. This polygenic inheritance plays a role in the variability of the phenotype especially when there is a functional relationship between mutated genes, as this is the case for HPE genes [START_REF] Mercier | NODAL and SHH dose-dependent double inhibition promotes an HPE-like phenotype in chick embryos[END_REF]. This has significant implications for genetic counseling and for risk assessment of patient relatives.

Until recently, HPE molecular diagnosis had relied on the detection of point mutations in the four main HPE genes (SHH, ZIC2, SIX3 and TGIF1) by Sanger sequencing and on the search for deletions in either known HPE genes or in the entire genome (using CGH array).

Targeted next-generation sequencing (NGS) has been proven in the recent years to be very beneficial clinically, especially for the molecular diagnosis of genetically heterogeneous diseases, such as intellectual disability, hearing loss [START_REF] Shearer | Comprehensive genetic testing for hereditary hearing loss using massively parallel sequencing[END_REF], and ciliopathies like Bardet-Biedl syndrome (M 'Hamdi et al., 2014). Targeted NGS appears to be more suitable for routine clinical practice than whole-exome sequencing as it provides better coverage of particular genes for a lower cost and easier and quicker data interpretation [START_REF] Rehm | Disease-targeted sequencing: a cornerstone in the clinic[END_REF]. Therefore we have developed a targeted NGS panel for the molecular diagnosis of HPE by screening twenty genes positively involved in HPE or defined as candidates for this disorder using the Ion Torrent AmpliSeq and Ion Personal Genome Machine (PGM) strategy.

In a cohort of 271 HPE probands tested since the beginning of 2014, we were able to provide a diagnosis in approximately 24% of patients. We also show that components of the FGF signaling pathway are clearly involved in HPE.

MATERIALS AND METHODS

Sample Collection

A total of 257 patients (131 fetuses and 126 living children) with normal conventional karyotype were referred by the French geneticists from the eight different CLAD (Centres Labellisés pour les Anomalies du Développement) of the country, French centers of prenatal diagnosis (CPDPN), fetopathologists from the French Fetopathology Society (SOFFOET), as well as several European centers. The 257 patients are described in Table 1. This cohort includes 130 males and 127 females, who have been diagnosed with alobar (n=62), semilobar (n=54), lobar (n=43), syntelencephaly (n=12), HPE microform (n=80), Hartsfield syndrome (n=3) or Kallmann syndrome (n=3). All samples were obtained with informed consent according to the protocols approved by the local ethics committee (Rennes hospital).

Gene selection and panel design

Gene

Library preparation and DNA sequencing

An adapter-ligated library was constructed with the Ion AmpliSeq Library Kit 2.0 (Life Technologies) following the manufacturer's protocol. Briefly, 10 ng of DNA was amplified in two pooled reactions then gathered together. Amplicons were partially digested at primer sequences before ligation with Ion Torrent adapters P1 and A, and the adapter-ligated products were then purified with AMPure beads (Beckman Coulter Genomics, Brea, CA, USA), and PCR-amplified for 7 cycles. The resulting libraries of 11 patients were equalized using the Ion Library Equalizer Kit (Life Technologies) and then pooled.

Sample emulsion PCR, emulsion breaking, and enrichment were performed with the Ion PGM Template OT2 200 Kit (Life Technologies), according to the manufacturer's instructions. Briefly, an input concentration of one DNA template copy per Ion Sphere Particles (ISPs) was added to emulsion PCR master mix, and the emulsion was generated with an Ion OneTouch system (Life Technologies). Next, ISPs were recovered, and templatepositive ISPs were enriched with Dynabeads MyOne Streptavidin C1 beads (Life Technologies). The Qubit 2.0 fluorometer (Life Technologies) was used to confirm ISP enrichment. An Ion PGM 200 Sequencing Kit was used for sequencing reactions, as recommended in the protocol, and chips 316 were used to sequence barcoded samples on the Ion Torrent PGM for 500 dNTP-flows.

In order to achieve a complete coverage of at least the four main genes for each patient, six fragments, respectively one in SHH, four in ZIC2 and one in SIX3, were systematically studied by Sanger method. Depending on the coverage, analysis of other genes was completed according to the patient phenotype by Sanger sequencing.

Bioinformatical analysis

The sequencing data produced by the PGM were first processed with the Torrent Suite 4.2.1, Ion Torrent platform-specific pipeline including signal processing, adapter trimming, filtering of poor signal-profile reads and alignment to the hg19 human reference genome with TMAP (Torrent Mapping Alignment Program). Four independent variant calling algorithms from the Torrent suite were used.

The four VCF (variant calling format) files were combined and annotated with ANNOVAR (February 2014 build) [START_REF] Wang | ANNOVAR: functional annotation of genetic variants from high-throughput sequencing data[END_REF]. A gene-based annotation identified whether SNPs cause protein-coding changes and the amino acids that were affected based on RefSeq. A filter based annotation identified variants and their associated frequency that were reported in the following databases: dbSNP138, 1000-Genome (1000G), NHLBI-ESP, ExAC (Exome Aggregation Consortium) and ClinVar [START_REF] Landrum | ClinVar: public archive of relationships among sequence variation and human phenotype[END_REF]. ANNOVAR was also used to annotate the predicted functional consequences of missense variants using dbNSFP (database for synonymous SNP's functional predictions) v2.6

(http://sites.google.com/site/jpopgen/dbNSFP) [START_REF] Liu | dbNSFP: a lightweight database of human nonsynonymous SNPs and their functional predictions[END_REF][START_REF] Liu | dbSNP v2.0: a database of human non-synonymous SNVs and their functional predictions and annotations[END_REF]. This database compiles prediction scores and interpretation from ten different algorithms: SIFT, Polyphen2_HDIV, Polyphen2_HVAR, LRT, MutationTaster, MutationAssessor, FATHMM, CADD, MetaSVM and MetaLR (Suppl. Tables S1 andS2). Three conservation scores (GERP++, PhyloP and SiPhy) are also included in dbNSFP v2.6 (Suppl. Tables S1 andS2).

The variant annotation was completed with "in-house" data regarding variants frequency within each run, across runs and during previous annotation helping to identify recurring false positives and polymorphisms. Furthermore only variants with a frequency less than 1/1,000 in 1000G, EVS (Exome Variant Server), ExAC held our interest.

After variants validation by visualization with IGV (Integrative Genomics Viewer), complementary annotations were performed using Condel v2.0 (Gonzalez-Perez and Lopez-Bigas, 2011) and Alamut Visual v2.4.5 (Interactive Biosoftware) to estimate variant pathogenicity. The information given by different tools were re-examined with caution to provide accurate results: PolyPhen [START_REF] Adzhubei | Predicting Dunctional Effect of Human Missense Mutations Using PolyPhen-2[END_REF], SIFT [START_REF] Kumar | Predicting the effects of coding non-synonymous variants on protein function using the SIFT algorithm[END_REF], Mutation Taster [START_REF] Schwarz | MutationTaster2: mutation prediction for the deep-sequencing age[END_REF], and Align-GVGD [START_REF] Tavtigian | Comprehensive statistical study of 452 BRCA1 missense substitutions with classification of eight recurrent substitutions as neutral[END_REF] were tested for exonic variants. In order to study the effect of potential splice variations, Alamut Visual integrates various splice site prediction methods: SpliceSiteFinder-like [START_REF] Zhang | Statistical features of human exons and their flanking regions[END_REF],

MaxEntScan [START_REF] Yeo | Maximum entropy modeling of short sequence motifs with applications to RNA splicing signals[END_REF], NNSPLICE [START_REF] Reese | Improved splice site detection in Genie[END_REF], GeneSplicer [START_REF] Pertea | GeneSplicer: a new computational method for splice site prediction[END_REF], Human Splicing Finder [START_REF] Desmet | Human Splicing Finder: an online bioinformatics tool to predict splicing signals[END_REF], ESEFinder [START_REF] Cartegni | ESEfinder: A web resource to identify exonic splicing enhancers[END_REF], RESCUE-ESE [START_REF] Fairbrother | Predictive identification of exonic splicing enhancers in human genes[END_REF] and EX-SKIP [START_REF] Raponi | Prediction of single-nucleotide substitutions that result in exon skipping: identification of a splicing silencer in BRCA1 exon 6[END_REF] were interrogated. The first five gave scores increasing with the importance of the predicted impact on the splice.

Finally, a variant was retained for diagnosis when a majority of tools predicted it as potentially deleterious and/or when family pedigree segregation was consistent. Nucleotide numbering uses +1 as the A of the ATG translation initiation codon in the reference sequence, with the initiation codon as codon 1. We use the tool ProteinPaint (http://pecan.stjude.org) for visualizing amino acid changes corresponding to the retained variants [START_REF] Zhou | Exploring genomic alteration in pediatric cancer using ProteinPaint[END_REF].

Mutation validation

All variants with a potential deleterious effect were confirmed by Sanger sequencing. They were submitted to ClinVar (ClinVar accessions SCV000268717 -SCV000268738 on http://www.ncbi.nlm.nih.gov/clinvar/). Segregation analyses were performed whenever DNA was available for additional family members.

RESULTS

Targeted NGS analysis of the 257 patients identified candidate and diagnosis variants in 23.7% of the cases: mutations with high confidence in their deleterious effect in three of the main genes SHH, ZIC2 and SIX3 were identified in 13.2% of the cases (34/257), and in other tested genes in 10.5% (27/257). For these cases, we were able to give a diagnosis. We also found variants classified as variants of uncertain significance (VUS) in 10% (26/257) of the cases.

From these data, the ten first-ranked genes involved in HPE are SHH (5.8%), ZIC2 (4.7%), GLI2 (3.1%), SIX3 (2.7%), FGF8 (2.3%), FGFR1 (2.3%), DISP1 (1.2%), DLL1 (1.2%) and SUFU (0.4%) (Table 1, Fig. 1). All variants were found in a heterozygous state and were held for diagnosis.

SHH, ZIC2 and SIX3 retain their position of major genes.

Description of the SHH, ZIC2 and SIX3 mutations is provided in Figures 1 and2. As previously described by Mercier et al. [START_REF] Mercier | New findings for phenotypegenotype correlations in a large European series of holoprosencephaly cases[END_REF], our results confirmed that SHH is the major gene implicated in HPE. SHH mutations are mostly missense (Fig. 1) and are inherited in 80% of cases of this study. The spectrum of clinical manifestations associated with SHH mutations is very large and includes severe forms as well as microforms. ZIC2 is the second major gene, which is affected by all types of mutations: missense (42%), frameshift and nonsense (42%) and also splice mutations (16%). ZIC2 alterations are generally associated with severe HPE forms and few facial features and are de novo in 92%

of cases in our study. Probands with SIX3 mutation mostly had severe HPE correlated with severe facial features. Like SHH mutations, SIX3 variants are mostly inherited.

Altogether, these results support that mutations in SHH and SIX3 are highly inherited, whereas most of the ZIC2 mutations are de novo.

GLI2 is mostly involved in midline abnormalities.

Six GLI2 heterozygous variants were hold for diagnosis (Fig. 1 and 3, Table 2, Suppl. Table S2).

The c.596dupG/p.Ala200Argfs*151 (A200Rfs*151) mutation was identified in a boy with nasal pyriform aperture atresia and was inherited from his asymptomatic mother.

The c.790C>T/p.Arg264* (R264*) mutation was identified in a 2-years-old girl with isolated solitary median maxillary central incisor and was inherited from her asymptomatic mother.

The c.2064delC/p.Ser690Alafs*5 (S690Afs*5) mutation was identified in a 20-years-old girl with hexadactyly, choanal atresia, hypopituitarism and cerebellar atrophia. This mutation occurred de novo.

The c.2237G>A/p.Trp746* (W746*) mutation was identified in a male fetus aborted because of lobar holoprosencephaly, premaxillary agenesis, hexadactyly, pituitary hamartoma, and short femur. Moreover his karyotype revealed a mosaic fragility on chromosome 3 (3p24.1, so very far from TDGF1). This mutation was not inherited from his mother, and DNA from the father was unavailable.

The c.4761G>C/p.*1587Tyrext*46 (*1587Y) mutation was found in a 16-year-old boy with hypopituitarism, solitary median maxillary central incisor and choanal atresia. It was inherited from his asymptomatic mother.

The c.349G>A/p.Ala117Thr (A117T) variant was found in two brothers, one with hypopituitarism and optic atrophia, the other with bilateral cleft lip and palate. This variant was inherited from the father presenting only subtle hypotelorism. The effect of this variant is uncertain as it involves a moderately conserved amino acid and the physicochemical gap between alanine and threonine is low (Grantham distance = 58).

Except the A117T, which is of uncertain clinical significance, all the other variations modify the stop codon. They are inherited in the majority of cases, implicating that these variants in GLI2 clearly show incomplete penetrance.

Altogether, the mutations in GLI2 are mostly associated with spectrum linked to midline and characterized by solitary median maxillary central incisor and pituitary insufficiency. Only one is associated with classic HPE.

FGF8 reaches the top genes.

Six patients of our cohort presented heterozygous variations in FGF8 gene (Fig. 1 and3, Table 2, Suppl. Table S2).

A fetus with semilobar HPE presented the c. 356C>T/p.Thr119Met (T119M) variant in FGF8

in association with a splice mutation in FGFR1. The couple had already had a termination of pregnancy due to semilobar HPE and the paternal grandmother presents a right cleft lip. DNA samples were not available, preventing further Sanger validation.

The c.317C>A/p.Ala106Glu (A106E) was identified in 4-years old boy with semi-lobar HPE.

This variant implicates a highly conserved aminoacid (through 13 species until Fugu) located in the interleukin-1/heparin-binding growth factor domain. It is predicted as possibly damaging by SIFT, PolyPhen and Mutation taster. This mutation occurred de novo. This is the first time that a FGF8 mutation is described in association with syntelencephaly.

The c.385C>T/p.Arg129* (R129*) was identified twice in two unrelated families. The first patient is a boy with alobar HPE and the second one is a boy with syntelencephaly. In both cases, the mutation was inherited from the asymptomatic father.

The c.617G>A/p.Arg206Gln (R206Q) was also identified twice in two unrelated families.

The first case is a 3 year-old girl with microform (pyriform aperture stenosis, solitary median maxillary central incisor, hypotelorism) presenting an additional variant in DLL1 (p.Asp601_Ile602delinsVal). These two variants are also present in her older sister who was operated on for bilateral cleft lip and palate and are inherited from the mother presenting hypotelorism and microretrognathism. So there is an apparent co-segregation of these mutations with minor signs of HPE spectrum in this family. The second case is a female fetus with lobar HPE.

Overall, the mutation frequency (2.2%) in FGF8 demonstrates that this gene can be classified as a major gene.

FGFR1 is a new major gene in HPE.

Six heterozygous variants in FGFR1 (NM_023110.2) were identified in our cohort: five in the intracellular tyrosine kinase domain (TKD, aminoacids 478-767): p.Gly485Val, p.Gly490Arg, p.Gly643Asp, c.1977+1G>A, p.Glu692Lys, and one in the extracellular ligand binding domain (p.Arg250Pro) (Fig. 1 and 3, Table 2, Suppl. Table S2).

The c.1454G>T/p.Gly485Val (G485V) and the c.1468G>C/p.Gly490Arg (G490R) were identified in patients with Harstfield syndrome and occurred de novo. The latter has already been reported by Simonis et al. [START_REF] Simonis | FGFR1 mutations cause Hartsfield syndrome, the unique association of holoprosencephaly and ectrodactyly[END_REF].

The c.1928G>A/p.Gly643Asp (G643D) mutation occurred de novo in a patient with nasal pyriform aperture hypoplasia, single central incisor and intellectual deficiency. It involves a highly conserved residue (through 16 species from Caenorhabiditis elegans to Homo sapiens) located in the serine-threonine/tyrosine-protein kinase catalytic domain and the physicochemical gap between glycine and aspartate is important (Grantham distance = 94).

AlignGVGD, SIFT and MutationTaster predict a deleterious effect.

The c.1977+1G>A variant was identified in a patient with semilobar HPE in association with a variant in FGF8, p.Thr119Met, as described above. The c.1977+1G>A variant is predicted to induce a skipping of exon 17 by all five splice prediction tools.

The c.2074G>A/p.Glu692Lys (E692K) mutation was identified in a fetus with HPE and cleft lip and palate, and was inherited from his mother with hypogonadotropic hypogonadism.

The c.749G>C/p.Arg250Pro (R250P) mutation was identified in a boy with lobar HPE and bilateral cleft lip and palate. Sanger sequencing suggested a very low proportion of the mutated base (cytosine) to the normal base (guanine) in the father leucocyte DNA (Fig. 4).

This was confirmed by NGS sequencing showing mosaicism for the presence of the mutation (GRCh37 genome build: g.38282214C>G) with a frequency of 6% in the peripheral blood, and was perfectly correlated with the phenotype of the father presenting a microform with a right unilateral hypoplasia of the orbicularis of the upper lip and bilateral nasal slot, and MRI showed agenesis of the corpus callosum. The 15-month-old boy now presents diabetes insipidus and septo-optic dysplasia.

Mutations in FGFR1 were recently described in Hartsfield syndrome (OMIM 300571), that is a rare and unique association of HPE and ectrodactyly, with or without cleft lip and palate, and variable additional features [START_REF] Hong | Dominant-negative kinase domain mutations in FGFR1 can explain the clinical severity of Hartsfield syndrome[END_REF][START_REF] Simonis | FGFR1 mutations cause Hartsfield syndrome, the unique association of holoprosencephaly and ectrodactyly[END_REF]. Here we identified four FGFR1 mutations in patients presenting HPE without extremities abnormalities.

Minor HPE genes present mutations that are associated with a second one in most of the cases.

The three HPE minor genes identified by our study are DLL1, DISP1 and SUFU (Fig. 1, Table 2, Suppl. Table S2).

In the DLL1 gene, we identified twice the same mutation c.1802_1804del/p.Asp601_Ile602delinsVal (or 601_602del) in two unrelated patients. First, this mutation was found in a patient with semilobar HPE and has already been reported by our group [START_REF] Dupé | NOTCH, a new signaling pathway implicated in holoprosencephaly[END_REF]. Secondly, it was identified in a 3 year-old girl with microform (pyriform aperture stenosis, solitary median maxillary central incisor, hypotelorism). It was found in association with a VUS in FGF8 (R206Q); the two variants perfectly co-segregate with the phenotype in the family and may be implicated in the phenotype as we have shown that Fgf pathway might regulate expression of DLL1 in the chick developing brain [START_REF] Dupé | NOTCH, a new signaling pathway implicated in holoprosencephaly[END_REF].

We also found the c.2117C>T/p.Ser706Leu (S706L) mutation in the DLL1 gene in a fetus with alobar HPE in association with an in-frame deletion in SHH (c.1157_1180del/p.Leu386_Ala393del). The two mutations were however inherited from her asymptomatic father.

Regarding the DISP1 gene, we identified two compound heterozygous mutations in a 9-yearold girl with a mild form of lobar HPE, facial dysmorphism and hypotelorism: the c.1087A>G transition leading to a missense mutation p.Asn363Asp (N363D) and the c.1657G>A transition leading to a missense mutation p.Glu553Lys (E553K). The p.Asn363Asp mutation was inherited from the father and the p.Glu553Lys mutation was inherited from the mother [START_REF] Mouden | Complex mode of inheritance in holoprosencephaly revealed by whole exome sequencing[END_REF].

In one polymalformative fetus with bilateral cleft lip and facial dysmorphism suggesting HPE microform, we found a nonsense heterozygous mutation c.2898G>A or p.Trp966* (W966*) in DISP1, associated with a mutation in SUFU (c.1022C>T/p.Pro341Leu) that substitutes the last base of exon 8 and that is predicted deleterious by most bioinformatics prediction tools mutation. Family study unfortunately could not be performed because DNA samples were not available.

These results suggest that mutations in minor genes would be found more often in HPE patients with polygenic inheritance.

DISCUSSION

HPE is a very complex disorder both in clinical and genetic terms involving two or more genetic events. We present here the first large HPE series studied by targeted NGS and we provide a new classification of genes involved in HPE. SHH, ZIC2 and SIX3 remain the top genes in terms of importance with GLI2, and are followed by FGF8 and FGFR1. The fraction of mutations in the major genes (SHH, ZIC2, SIX3) is reduced in the present study compared to previous studies [START_REF] Mercier | New findings for phenotypegenotype correlations in a large European series of holoprosencephaly cases[END_REF]; it is probably due to the present cohort which included more patients with microforms and syntelencephaly. TGIF1 was previously classified as a major HPE gene [START_REF] Mercier | New findings for phenotypegenotype correlations in a large European series of holoprosencephaly cases[END_REF] but did not present any mutation in our study. Similarly PTCH1, GAS1, TDGF1, CDON, FOXH1, NODAL and SHH regulating sequences LMBR1 and RBM33 showed no mutations held for diagnosis in the 257 cases sequenced. New case-control studies need to be performed in larger cohorts to better evaluate their role and diagnosis potential in HPE. Such studies may be much more capable to evaluate the implication of rare variants. The candidate HHAT and SOX2 genes did not present any mutation either.

Significantly, the identification of numerous mutations in FGF8 and FGFR1 in our cohort strengthens FGF signaling involvement in HPE.

FGF8 is a ligand of the large fibroblast growth factor (FGF) family and is important for gonadotropin releasing hormone (GnRH) neuronal development with human mutations resulting in hypogonadotropic hypogonadism and Kallmann syndrome [START_REF] Falardeau | Decreased FGF8 signaling causes deficiency of gonadotropin-releasing hormone in humans and mice[END_REF][START_REF] Hardelin | The complex genetics of Kallmann syndrome: KAL1, FGFR1, FGF8, PROKR2, PROK2, et al[END_REF]. Our targeted NGS approach demonstrates that mutation in FGF8 occurs more commonly than previously thought [START_REF] Arauz | A hypomorphic allele in the FGF8 gene contributes to holoprosencephaly and is allelic to gonadotropin-releasing hormone deficiency in humans[END_REF][START_REF] Mccabe | Novel FGF8 mutations associated with recessive holoprosencephaly, craniofacial defects, and hypothalamo-pituitary dysfunction[END_REF]. The phenotype associated with FGF8 alterations is variable and mutation can be de novo or inherited. Interestingly, the same inherited nonsense mutation (p.Arg129*) was identified in two unrelated patients, one with a severe HPE and the other with a mild form. It supports that another event could be necessary to lead to severe HPE.

We also describe here convincing examples of FGFR1 mutations in patients with isolated HPE. FGFR1 belongs to the tyrosine kinase receptor superfamily and contains an extracellular ligand binding domain with three immunoglobulin (Ig)-like domains (D1-D3) and a cytoplasmic domain responsible for tyrosine kinase activity (Fig. 3). The clinical manifestations of FGFR1 alterations are very heterogeneous since loss-of-function mutations in FGFR1 have been linked to Kallman syndrome (Dode et al., 2003;[START_REF] Albuisson | Kallmann syndrome: 14 novel mutations in KAL1 and FGFR1 (KAL2)[END_REF] Villanueva and de Roux, 2010), hypogonadotropic hypogonadism with or without anosmia [START_REF] Balasubramanian | Prioritizing genetic testing in patients with Kallmann syndrome using clinical phenotypes[END_REF][START_REF] Villanueva | Congenital hypogonadotropic hypogonadism with split hand/foot malformation: a clinical entity with a high frequency of FGFR1 mutations[END_REF][START_REF] Vizeneux | Congenital hypogonadotropic hypogonadism during childhood: presentation and genetic analyses in 46 boys[END_REF], and Hartsfield syndrome [START_REF] Hong | Dominant-negative kinase domain mutations in FGFR1 can explain the clinical severity of Hartsfield syndrome[END_REF][START_REF] Simonis | FGFR1 mutations cause Hartsfield syndrome, the unique association of holoprosencephaly and ectrodactyly[END_REF]. Gain-of-function mutations in FGFR1

have also been identified in about 5% of Pfeiffer syndrome with or without craniosynostosis [START_REF] Chokdeemboon | FGFR1 and FGFR2 mutations in Pfeiffer syndrome[END_REF]. We describe here one case of FGFR1 mutation (p.Glu692Lys) associated both with Kallmann syndrome and HPE. The location of this mutation is consistent with Kallmann syndrome as mutations of neighboring residues (p.Leu590Pro, p.Ile693Phe) were already described in patients with this syndrome [START_REF] Bailleul-Forestier | Dental agenesis in Kallmann syndrome individuals with FGFR1 mutations[END_REF]Dodé et al., 2007).

Out of the six FGFR1 mutations described in our study, two were found in patients with Hartsfield syndrome. Previous reports of Hartsfield syndrome implicate FGFR1 mutations in the ATP binding site and the protein tyrosine kinase domain [START_REF] Dhamija | Novel de novo heterozygous FGFR1 mutation in two siblings with Hartsfield syndrome: a case of gonadal mosaicism[END_REF][START_REF] Hong | Dominant-negative kinase domain mutations in FGFR1 can explain the clinical severity of Hartsfield syndrome[END_REF][START_REF] Simonis | FGFR1 mutations cause Hartsfield syndrome, the unique association of holoprosencephaly and ectrodactyly[END_REF]. These mutations would have a dominant-negative activity that would account for the most severe phenotype of Hartsfield syndrome [START_REF] Hong | Dominant-negative kinase domain mutations in FGFR1 can explain the clinical severity of Hartsfield syndrome[END_REF].

Concordantly, the two FGFR1 mutations (p.Gly485Val, p.Gly490Arg) that are associated with Hartsfield syndrome in our cohort are localized in the region coding for ATP binding site (Fig. 3). However, two of the mutations identified in HPE patients without abnormalities of the extremities are also found in the region coding for activation loop of the protein tyrosine kinase domain (p.Gly643Asp; c.1977+1G>A). We hypothesized that these FGFR1 mutations rather lead to a classic loss of function [START_REF] Hong | Dominant-negative kinase domain mutations in FGFR1 can explain the clinical severity of Hartsfield syndrome[END_REF]. FGF8 and FGFR1 are not the only members of the FGF family to be expressed in the early forebrain. Other members should be considered as strong potential candidates for HPE.

FGF signaling pathway plays a dominant role in embryonic development and is essential for ventral telencephalon development and digits formation [START_REF] Ellis | ProNodal acts via FGFR3 to govern duration of Shh expression in the prechordal mesoderm[END_REF][START_REF] Gutin | FGF signalling generates ventral telencephalic cells independently of SHH[END_REF][START_REF] Li | FGFR1 function at the earliest stages of mouse limb development plays an indispensable role in subsequent autopod morphogenesis[END_REF]. FGF signaling is involved in maintaining Shh expression in the prechordal tissue, where it plays a crucial role in induction of the ventral forebrain [START_REF] Ellis | ProNodal acts via FGFR3 to govern duration of Shh expression in the prechordal mesoderm[END_REF].

FGFR1 also maintains expression of Shh in the developing limb [START_REF] Li | FGFR1 function at the earliest stages of mouse limb development plays an indispensable role in subsequent autopod morphogenesis[END_REF]. According to our hypothesis, dominant-negative FGFR1 mutations would lead to a more severe downregulation of Shh activity compared to a classic loss of function. It would explain the presence of limb defect in Hartsfield syndrome similar to those observed in the Shh-/knockout mice [START_REF] Chiang | Cyclopia and defective axial patterning in mice lacking Sonic hedgehog gene function[END_REF].

The knowledge of the mode of inheritance in HPE has evolved since the description of an autosomal dominant model with an incomplete penetrance and a variable expression [START_REF] Odent | Segregation analysis in nonsyndromic holoprosencephaly[END_REF] through an autosomal dominant model with modifier genes [START_REF] Roessler | Utilizing prospective sequence analysis of SHH, ZIC2, SIX3 and TGIF in holoprosencephaly probands to describe the parameters limiting the observed frequency of mutant genexgene interactions[END_REF]. Thanks to our NGS strategy targeting twenty genes, we have shown that sixteen per cent of mutations kept for diagnosis was found in association with a second one (FGF8/FGFR1, FGF8/DLL1, DLL1/SHH, DISP1/DISP1, DISP1/SUFU). These cases of double-mutations in two different genes -and even in the same one -strengthen the polygenic inheritance previously illustrated by [START_REF] Mouden | Complex mode of inheritance in holoprosencephaly revealed by whole exome sequencing[END_REF]. Here, a second event in FGF8 was identified in one patient with FGFR1 mutation. In the same way, a gene synergistic interaction between a deleterious FGFR1 allele transmitted from one parent and a loss-of-function allele in FGF8 from the other parent was recently described in two sisters with semilobar and lobar HPE respectively [START_REF] Hong | Dominant-negative kinase domain mutations in FGFR1 can explain the clinical severity of Hartsfield syndrome[END_REF]. Altogether these observations strongly suggest that a cumulative effect on the FGF signaling pathway leads to HPE. We showed that most of mutations were inherited mainly from an asymptomatic parent, which suggests that another event could be necessary to cause HPE. The important and wide variability of expression from an asymptomatic to severe form for a same mutation, the incomplete penetrance and the identification of several mutations in the same patient argue for this oligogenic inheritance. Furthermore, the description of numerous mouse models carrying mutations in two genes of the same or different signaling pathways involved in forebrain development strongly support this mode of inheritance by showing that a cumulative partial inhibition of signaling pathways is necessary to develop HPE [START_REF] Allen | The Hedgehog-binding proteins Gas1 and Cdo cooperate to positively regulate Shh signaling during mouse development[END_REF][START_REF] Krauss | Holoprosencephaly: new models, new insights[END_REF][START_REF] Mercier | NODAL and SHH dose-dependent double inhibition promotes an HPE-like phenotype in chick embryos[END_REF]. However, only a few examples of digenic inheritance in human were reported in the literature until now [START_REF] Hong | Dominant-negative kinase domain mutations in FGFR1 can explain the clinical severity of Hartsfield syndrome[END_REF][START_REF] Lacbawan | Clinical spectrum of SIX3-associated mutations in holoprosencephaly: correlation between genotype, phenotype and function[END_REF][START_REF] Ming | Multiple hits during early embryonic development: digenic diseases and holoprosencephaly[END_REF][START_REF] Mouden | Complex mode of inheritance in holoprosencephaly revealed by whole exome sequencing[END_REF][START_REF] Nanni | The mutational spectrum of the Sonic Hedgehog gene in holoprosencephaly: SHH mutations cause a significant proportion of autosomal dominant holoprosencephaly[END_REF]. The present study demonstrates that digenism would not be so rare in human HPE. Systematic implementation of next generation sequencing in HPE diagnosis will be necessary to account for this multigenic inheritance and to improve genetic counselling.

  considered as minor genes (PTCH1 MIM#601309, TDGF1 MIM#187395, FOXH1 MIM# 603621, GLI2 MIM# 165230, DISP1 MIM# 607502, FGF8 MIM# 600483, GAS1 MIM# 139185, CDON MIM#608707, NODAL MIM# 601265, DLL1 MIM# 606582 and very recently STIL MIM# 181590)

  selection was based on their proved or suspected involvement in HPE, or in syndromes including HPE, membership in signaling pathways implicated in HPE, and expression in the developing forebrain compatible with HPE. Known regulatory regions of SHH (LMBR1 MIM# 605522, RBM33) have also been included. The panel was designed with Ion AmpliSeq™ Designer (Life Technologies, ThermoFisher Scientific). It includes coding and flanking intronic sequences (50 base pairs) of the following 20 genes: SHH (NM_000193.2), ZIC2 (NM_007129.3), SIX3 (NM_005413.3), TGIF1 (NM_170695.2), GLI2 (NM_005270.4), PTCH1 (NM_000264.3), GAS1 (NM_002048.2), TDGF1 (NM_003212.3), CDON (NM_016952.4), DISP1 (NM_032890.3), FOXH1 (NM_003923.2), NODAL (NM_018055.4), FGF8 (NM_033163.3), HHAT (NM_018194.4) MIM# 605743, DLL1 (NM_005618.3), SUFU (NM_016169.3) MIM# 607035, SOX2 (NM_003106.3) MIM# 184429, RBM33 (NM_053043.2), LMBR1 (NM_022458.3) and FGFR1 (NM_023110.2) MIM# 136350. It covers 111 kb.

Figure 1 .

 1 Figure 1. Distribution of mutations held for diagnosis in the top ten holoprosencephaly genes

Figure 2 .

 2 Figure 2. Mutational landscape of SHH, ZIC2 and SIX3 genes. This comprehensive

Figure 3 .

 3 Figure 3. Mutational landscape of FGF8, FGFR1 and GLI2 genes, performed with

Figure 4

 4 Figure 4. p.Arg250Pro (R250P) mutation in FGFR1. (I) Proband. (II) Father. (a) Partial

Table 1 . Distribution of holoprosencephaly types and mutations in the cohort of 257 patients. Type All (Male,Female) SHH ZIC2 GLI2 SIX3 FGF8 FGFR1 DISP1 DLL1 SUFU

 1

	Alobar	62 (24,38)	9,7% 8,1% -	6,5% 1,6% -	-	1,6% -
	Semilobar	54 (26,28)	3,7% 5,6% -	1,9% 3,7% 3,7%	-	1,9% -
	Lobar	43 (27,16)	2,3% 9,3% 2,3% 2,3% 2,3% 2,3%	4,7% -	-
	Syntelencephaly 12 (7,5)	8,3% -	-	8,3% 8,3% -	-	-	-
	Microform	80 (42,38)	6,3% -	8,8% -	1,3% 1,3%	1,3% 1,3% 1,3%
	Hartsfield	3 (3,0)		-	-	-	-	66,7% -	-	-
	Kallmann	3 (1,2)	-	-	-	-	-	-	-	-	-
	TOTAL	257	5,8% 4,7% 3,1% 2,7% 2,3% 2,3%	1,2% 1,2% 0,4%

Table 2 . Characteristics of variants identified in GLI2, FGF8, FGFR1, DLL1, DISP1 and SUFU, and associated phenotypes.

 2 The GenBank references used for nucleotide numbering were NM_005270.4 for GLI2, NM_033163.3 for FGF8, NM_023110.2 for FGFR1, NM_005618.3 for DLL1, NM_032890.3 for DISP1, NM_016169.3 for SUFU and NM_000193.2 for SHH. Nucleotide numbering uses +1 as the A of the ATG translation initiation codon in the reference sequence, with the initiation codon as codon 1. The deleterious score was given by 10 predictions tools (SIFT, Polyphen2_HDIV, Polyphen2_HVAR, LRT, MutationTaster, MutationAssessor, FATHMM, CADD, MetaSVM and MetaLR).*: For detailed prediction data, see Suppl. TableS2. D, deleterious; P, possibly deleterious; T, tolerated; NPAS, nasal pyriform aperture stenosis; SMMCI, solitary median maxillary central incisor; ND: not determined.

					Deleteri
	Gen e	Variant (gDNA)	Variant (cDNA)	(protein)	ous score*	Patient's phenotype	Inheritance	Paired mutation
					or effect
						hypopituitar
	GLI2	g.121708913G> A	c.349G> A	p.Ala117Thr	D:2 P:1 T:7	ism, optic atrophia / bilateral	father (hypoteloris m)
						cleft
		g.121712959dup G	c.596du pG	p.Ala200Argfs *151	Frameshi ft	NPAS	mother
		g.121726436C>T	c.790C> T	p.Arg264*	Stop gain SMMCI	mother
						hexadactyly
						, choanal
		g.121743961del C	c.2064d elC	p.Ser690Alafs *5	Frameshi ft	atresia, ism, hypopituitar	de novo
						cerebellar
						atrophia
						lobar HPE,
						premaxillary
		g.121744134G> A	c.2237G >A	p.Trp746*	Stop gain	agenesis, pituitary hamarthom	not inherited from the mother
						a,
						hexadactyly
						hypopituitar
		g.121748251G> C	c.4761G >C	p.*1587Tyrex t*46	Stop loss	ism, choanal SMMCI,	mother
						atresia
	FGF 8	g.103534509G> T	c.317C> A	p.Ala106Glu	D:9 P:0 T:1	semilobar HPE	de novo

ACKNOWLEDGMENTS

This work was supported by the CHU of Rennes (Innovation Project).

We would like to thank the families for their participation in the study, all clinicians who referred HPE cases, the eight CLAD (Centres Labellisés pour les Anomalies du Développement) within France that belong to FECLAD, French centers of prenatal diagnosis (CPDPN) and the SOFFOET for fetus cases, and the "filière AnDDI-Rares".

We particularly thank all members of the Molecular Genetics Laboratory (CHU, Rennes) and of the Department of Genetics and Development (UMR6290 CNRS, Université Rennes 1) for their help and advice. We are grateful to Артем Ким for carefully reading this manuscript.

The authors acknowledge the Centre de Ressources Biologiques (CRB) Santé BB-0033-00056 (http://www.crbsante-rennes.com) of Rennes for managing patient samples.