dataesr/scientific-paragraphs-categorization huggingface dataset:
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.
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.
English Specification of JS To illustrate the style in which the JavaScript standard (ECMA)  [6]  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.
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  [14].
Formal Specifications of JS In recent years, two projects, JSCert  [3]  and KJS  [11]  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  [5] ), formalized in the Coq proof assistant  [16]. 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  [13]. 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.
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.
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 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.
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  [8]  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.
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  [7]. 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.
RELATED WORK There are many formal semantics of JavaScript, from pen-and-paper ones  [10] , to the aforementioned JSCert  [3]  and KJS  [11]. 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. [9]. 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.
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  [5]  definitions from the reference semantics expressed in our small language, possibly using some amount of annotation to guide the process.
html). This assures that the light-loss is minimized. Each night we observed at least two flux standard stars  (HR 3454, HR 5501, HR 7596, HR 4468 and HR 5694)  to perform the spectral flux calibrations. The reduction procedure (overscan, bias, trimming, and flatfield corrections) was carried out with the iraf 2  software package (version 2. 14. 1) and all spectra were wavelength calibrated and corrected for atmospheric extinction. We used the atmospheric extinction coefficients published in CASLEO web-page (http://www. casleo. gov. ar/info-obs. php). An addition set of high-resolution spectra (R = 12 600) were taken with the echelle spectrograph REOSC in the spectral range 4225 -6700 Å to seek the Hα emission in the B stars with a SBD. These observations were done only for some of the star members identified in the eleven studied Galactic clusters (see Table  2 ).
To perform all these measurements, one of us (YA) wrote the interactive code MIDE3700 3  , in Python language. Its name corresponds to the Spanish acronym for Medición Interactiva de la Discontinuidad En 3700 Å (Interactive Discontinuity Measurement at 3700 Å). With this tool the user can work over the stellar spectrum and choose the best fits to Balmer and Paschen continua. The code then automatically delivers the values of D, λ 1 and Φ b and the corresponding fundamental parameters of a star. From observed and intrinsic color gradients we estimated the color excess, E(B -V) = 2. 1 (Φ b -Φ 0 b ) or E(B -V) = 2. 3 (Φ bb -Φ 0 bb ), of each star and its distance modulus, using the apparent visual magnitude available in the literature. In addition, we calculated the stellar luminosity (L /L ), stellar mass (M /M ) and age of each star interpolating in the stellar evolutionary models, for a non-rotating case and Z = 0.
While among the 13 (∼ 7%), 11 are dwarfs and 2 are giants. Table  7  lists the Be and Bdd stars used for this analysis. We notice that according to the weather conditions, several observing restrictions and other stellar sample selections, the above fraction f = 21% of B emission-line stars can be biased, mainly because part of the sample of Be stars were not selected randomly. In order to evaluate a possible overestimate of the actual fraction of Be stars that we have calculated for open clusters, we first compare this fraction with the fraction that can be derived using the available Be and B stars in the WEBDA database for the same 11 clusters. Thus, in the WEBDA database we counted 57 Be stars among 236 B stars. This implies a fraction of 24% which is larger than the one we have estimated in this work.
However, we must keep in mind that not all stars in the WEBDA database are necessarily cluster members. A second test is to compute a Monte Carlo simulation of the distribution of an "actual" fraction, f actual = 21% B emissionline stars for N tot = 198 B+Be+Bdd stars in 11 open clusters, over 100 independent samplings. We obtained thus an average f simulated = 22% B emission-line stars with dispersion σ f = 9%. If we had observed N tot = 2000 B+Be+Bdd stars, the simulation predicts that we should have f simulated = 22% B emission-line stars with σ f = 4%. In this simulation we have assumed that all clusters have the same age, so that each can be able to bear the same fraction of B emission-line stars. Considering differences in cluster ages, the bias σ f could perhaps be larger. Hence, both results suggest that the fraction of Be stars in open clusters is probably larger than that of field Be stars.
ID Other D λ 1 Φ b S. T T eff log g M v M bol Φ 0 b Moffat/ designation [dex] [Å] [µ] [K] [dex] [mag] [mag] [µ] Table  12. NGC 6250: Physical parameters and distance to the stars. Notes. m v values obtained from SIMBAD database. The distances of the stars with negative color gradients were determined using the distance modulus assigned to the cluster. ( dd) Stars with a SBD. ( pm) Probable member star. ( nm) Non-member star.
ID Other D λ 1 Φ b S. T T eff log g M v M bol Φ 0 b Notes. The symbol : is used to indicate extrapolated values. g is the stellar surface gravity given in cm s -2. ( dd) Stars with a SBD. ( mk) Spectral types derived using the MK-system. ( BE) Spectroscopic Binary. ( BE2) Double line spectroscopic binary. ( BEc) Eclipsing binary. ( BS) Blue straggler star. (Em) Emission line star. ( IR) Star with infrared excess. ( MA) Magnetic Ap star. ( V) Variable star. ( VB) Visual binary. ( a) Values interpolated from  Cox & Pilachowski (2000). ( m) Value calculated in this work, using a relation between Φ 0 b and (B -V) 0 given by  Moujtahid et al. (1998). Notes. m v values obtained from SIMBAD database. ( dd) Stars with a SBD. ( pm) Probable member star. ( pnm) Probable non-member star. A&A-ms, Online Material p 26 Table  15.
Acknowledgements. We would like to thank our anonymous Referee for his/her careful reading and valuable comments and suggestions that certainly help to improve this manuscript. YJA:  Visiting Astronomer ,  Complejo Astronómico El Leoncito  operated under agreement between the  Consejo Nacional de Investigaciones Científicas y Técnicas de la República Argentina  and the  National Universities of La Plata ,  Córdoba  and  San Juan. This research has made use of the SIMBAD database, operated at  CDS, Strasbourg, France , and WEBDA database, operated at the  Department of Theoretical Physics and Astrophysics of the Masaryk University. This work was granted by the  National University of La Plata  (jóvenes investigadores 2016). LC thanks financial support from  CONICET  ( PIP 0177 ) and the  Universidad Nacional de La Plata (Programa de Incentivos   G11/137 ), Argentina.
A multitude of factors contribute to complex diseases and can be measured with 'omics' methods. Databases facilitate data interpretation for underlying mechanisms. Here, we describe the Virtual Metabolic Human (VMH, www. vmh. life) database encapsulating current knowledge of human metabolism within five interlinked resources 'Human metabolism', 'Gut microbiome', 'Disease', 'Nutrition', and 'ReconMaps'. The VMH captures 5180 unique metabolites, 17 730 unique reactions, 3695 human genes, 255 Mendelian diseases, 818 microbes, 632 685 microbial genes and 8790 food items. The VMH's unique features are (i) the hosting of the metabolic reconstructions of human and gut microbes amenable for metabolic modeling; (ii) seven human metabolic maps for data visualization; (iii) a nutrition designer; (iv) a user-friendly webpage and application-programming interface to access its content; (v) user feedback option for community engagement and (vi) the connection of its entities to 57 other web resources.
INTRODUCTION Metabolism plays a crucial role in human health and disease, and it is modulated by intrinsic (e. g. genetic) and extrinsic (e. g. diet and gut microbiota) factors. When considered individually, these factors do not sufficiently explain the development and progression of many complex noncommunicable diseases, including metabolic syndrome and neurodegenerative diseases. Hence, a systems approach is necessary to elucidate the contribution of each of these factors and to enable the development of efficient, novel treatment strategies. The VMH database is divided into two interfaces, and its database contains five distinct but connected resources. Users can interact with the database using the two available interfaces: (i) a user-friendly web interface and (ii) an application-programming interface that allows programmatic access to the information contained in the database.
At the core of the database is the representation of reconstructions as sets of reactions. The database connects the five resources through shared nomenclature: (i) the 'Human metabolism' and 'Gut microbiome' resources share metabolites and reactions, (ii) the nutrients in the 'Nutrition' resource are mapped to metabolites that can be shared by the human and gut microbes and (iii) the diseases in the 'Disease' resource include affected genes and metabolite biomarkers present in the 'Human metabolism' resource. Finally, the 'ReconMaps' resource is connected to the 'Human metabolism' resource via metabolites and reactions. Such a systems approach requires the easy sharing of knowledge and experimental data generated by different research communities. Databases represent a compelling method of storing, connecting, and making available a vast variety of information derived from primary literature, experimental data, and genome annotations.
In fact, biological databases have become valuable tools for facilitating knowledge distribution and enabling research endeavors. There is a wealth of biochemical databases (1), however, a database that explicitly connects human metabolism with genetics, human-associated microbial metabolism, nutrition, and diseases has not yet been developed. One reason for the lack of such a database may be the use of nonstandardized nomenclature, which complicates data integration. Moreover, manual curation of database content is time consuming and requires expert domain knowledge. Genome-scale metabolic reconstructions represent the full repertoire of known metabolism occurring in a given organism and describe the underlying network of genes, proteins and biochemical reactions  (2). High-quality reconstructions go through an intensive manual curation pro-cess that follows established protocols to ensure high standards and coverage of the information available on the organism (3).