dataesr/scientific-paragraphs-categorization huggingface dataset:
However, the authors pointed to an enrichment of drug metabolism pathway from their down-regulated genes  [6] , confirming our results and further stressing the importance of components of this pathway in CRC pathogenesis. Unexpected links were identified using different sources in the STRING database. For example, a physical interaction, indexed in the BioGRID database  [48] , was identified between NME1, which possesses geranyl and farnesyl pyrophosphate kinase activities, and FDPS, a key enzyme in isoprenoid biosynthesis, which catalyzes the formation of farnesyl diphosphate  [49]. The upregulation of transcript and protein levels in CRC highlights the importance of this complex for synthesizing secondary metabolites (geranyl and farnesyl pyrophosphates) in pathogenesis. Acting on the mevalonate pathway to reduce secondary metabolites and ultimately counteract the activities of FDPS and NME1 looks attracting as a novel cancer therapy, in agreement with several data  [50].
In addition, we also identified the CASP7 (Apoptosis) gene as a positive target of the SREBP-1 protein  [52]. NQO1, an NADPH dehydrogenase implicated in the detoxification system, has been shown to directly interact with NME1 and TP53 (Cancer Pathway) in studies retrieved from the BioGrid database  [48]. Furthermore, NQO1 stabilized TP53 and partially inhibited its degradation under conditions of oxidative stress, making it a possible contributor to tumor development  [53]. Putative homologs of CHECK2 and INSIG1 from Saccharomyces cerevisiae, of DHCR7 and CYP51A1 and of CYP2B6 and NSDHL were found to have physical interactions in Intact and BioGRID databases, which may explain the relations observed in our network  [48, 54]. Putative homologs of CYP2B6 and NR1H4 in Caenorhabditis elegans were also found in these databases.
Interrogation of the STITCH database (Search Tools for Interactions of Chemicals)  [29]  for associations between deregulated genes in CRC and the 3 chemotherapeutic drugs tested in our study showed that these two types of genes could be targeted (Additional file 10). On the other hand, none of the drugs targeted members from the Wnt signaling pathway, except CCND1 that could be affected by Oxaliplatin and 5-Fluorouracile  [56] [57] [58]. Anticancer agents targeting Wnt/β-catenin signaling have been developed in recent years and their use could be proposed in combination with classical colon cancer therapies. As expected, in light of our network analysis, the use of Lovastatin seems to be very interesting to target members of the Lipoprotein signaling and cholesterol metabolism pathway. Nevertheless, in absence of a comprehensive analysis of the effects of the drugs on several additional endpoints (apoptosis, gene/protein expression profiling, etc.
Conclusion In conclusion to this work, we have obtained selected transcriptome data through a dedicated PCR array approach comparing colon cancer samples with normal colon mucosae. Although the majority of deregulations were already reported in CRC, about 10% of those events were not known to occur in colon cancer or in cancer in general. The genes most important to the structures of the networks indeed were known to play important regulatory roles in the tumors, but some were new, most significantly from the Lipoprotein signaling and cholesterol metabolism pathway. Use of this array also revealed that eight genes from this pathway were not engaged in any interaction within the corresponding sub-network or with other networks. This observation, which likely reflects the smaller number of investigations on those genes, also opens the path to uncover novel targets to treat colon cancer, potentially through the use of lipid-lowering drugs such as statins whose potential in combination with anticancer drugs is under scrutiny through clinical trials, as recorded at the National Cancer Institute.
This article describes the key innovations used in the massive open online course łIntroduction to Functional Programming using OCamlž that has run since the fall semester of 2015. A fully in-browser development environment with an integrated grader provides an exceptional level of feedback to the learners. A functional library of grading combinators greatly simplifies the notoriously complex task of writing test suites for the exercises, and provides static type-safety guarantees on the tested user code. Even the error-prone manual process of importing the course content in the learning platform has been replaced by a functional program that describes the course and statically checks its contents. A detailed statistical analysis of the data collected during and after the course assesses the effectiveness of these innovations.
INTRODUCTION At the beginning of 2014 started the preliminary work that led to the creation of the first massive open online course (MOOC) to propose an introduction to functional programming using the OCaml programming language, now known as the OCaml MOOC  [Di Cosmo et al. 2015] , on the FUN platform 1  , an instance of the Open edX open source project 2. It has been running once per academic year starting October 2015, exposing already 8000 learners from more than 120 countries to functional programming and the OCaml programming language. The goals of this MOOC were at the same time humble and ambitious: expose a wide public to the three key notions of languages from the ML family (functional programming, static typing with type inference and algebraic data types), and ensure that the learners who completed the course master all of them, and are able to write medium sized programs using OCaml.
In just seven weeks. Reaching these goals turned out to require a huge effort, especially for building the integrated environment that allows learners to do all the exercises directly in the browser, and for designing and implementing the automatic grading framework that is necessary to evaluate the exercises in a safe way. Even the apparently innocuous task of uploading the course content to the MOOC platform became a challenge, when the graphical user interface that is offered to perform this task turned up to require thousands of gestures just for the initial upload. The solutions designed to solve these challenges are faithful to the type-safe, static checking philosophy that underlies the ML family of languages: an innovative library of highly parametric test functions and combinators has been designed to allow writing tests and grading code concisely and type safely, and to force the test designer to handle all error cases; a unique integrated development environment has been developed to run fully in the browser, avoiding the hassles and bottlenecks of remote execution servers; even the course description itself has been built as an OCaml program, whose execution produces a ready-to-import archive that is statically guaranteed to have no dangling pointers.
In this article, we describe the choices made, the challenges faced, and the solutions found during the journey that led to the successful first run of the course. There are innovations both on the educational and the technical side. We will start by exposing the main goals of the OCaml MOOC, and explaining how the course content has been organized in Section 2. Section 3 presents the design of the exercise platform that has been developed for the course, taking into account the external constraints imposed by the particular MOOC platform that was used. The format of the exercises is explained through a first, simple example. Sections 4 and 5 contain the main technical contributions of the paper: they describe the challenges that arose while developing the exercises, and the elegant solutions that could be provided, leveraging all the power of the strongly typed, functional programming model offered by the OCaml language.
DESIGNING THE COURSE Teaching introductory courses in programming is a significant challenge which has always been at the center of heated debates in Computer Science departments. There are strongly differing opinions on what language one should use  [Bryant et al. 2010; Dewar and Astrachan 2009] , what features of a programming language should be emphasized  [Felleisen et al. 2015] , what kind of exercises are the most appropriate for retaining attention and fostering participation, and what development environment is most adapted for newcomers. Teaching introductory courses in functional programming may seem to simplify issues a bit, but in reality it also raises quite a few questions. Shall we be pure or impure? Shall we use typed or untyped languages? Shall we use a subset of the language or the full language? Scaling up Functional Programming Education: Under the Hood of the OCaml MOOC 4:3 Teaching a massive online course adds to the complexity of the course design space.
New issues are raised such as the automated evaluation of learners' code, the wide variety of learners, with different backgrounds and expectations, and the choice of the development and execution environment offered to them. For the OCaml MOOC, some of these decisions were obvious: the focus is on functional programming, and the language chosen is OCaml. Many others were extensively debated among the community of OCaml teachers that offered advice when the course was in its early stages of design. With no pretension of possessing the ultimate truth, we describe here the rationale of the final structure of the course that was chosen, and how the design of the course and the exercise environment were nicely intertwined. The main educational objective of the course was to familiarize a wide public to the three key notions: functional programming, static typing with type inference and algebraic data types.
Particular care was taken to avoid possible confusions with notions coming from the usual imperative programming languages: for example, the term variable is never used, and identifier is employed instead. Finally, students get their first notions of functional code architecture in the last course week about the module system of OCaml. All these notions are extensively put into play in a dense set of problems and exercises: the learners can work on them in a full fledged development environment that sports a toplevel (or REPL) running in the browser. This approach allows the course to go through the material of these four core weeks without introducing any I/O functions, and without spending an ounce of the learners' energy on installing a local environment on their machines. Pointers to the documentation 4:4 Benjamin Canou, Roberto Di Cosmo, and Grégoire Henry for installing a standalone OCaml development environment are of course provided, but nothing, not even the final project, requires it: special care has been taken to ensure that everything can be done entirely in the in-browser exercise environment.
Up to Week 4, the content covered is the pure, polymorphic, strongly typed functional core of OCaml with algebraic data types. According to some learners' feedback, it provides a very satisfactory introduction even for users of other dialects of the ML family, like F# and SML. The last two weeks introduce the notions needed for real world programming: input / output and compilation units for writing standalone programs, exceptions and mutable data for the performance hungry, and modules, functors and abstract data types for programming in the large. To complete the course, a choice between two full-fledged projects is offered to the learners. Our stated goal was not to rank learners on how quickly they did their homework, but to retain them all along the course and to make sure that those who completed it successfully became able to write medium sized functional programs of reasonable complexity using OCaml.
William Glasser As seen in the previous section, the OCaml MOOC gradually introduces newcomers to functional programming, exposing the learners step by step to notions that are quite new if the only previous experience in programming has been obtained using imperative languages. Hence, minimizing the distractions coming from the difficulties of setting up and learning to use a proper development environment was our top priority, to maximize the time and energy that the learners spend understanding the relevant new notions, and collaborating among themselves. This section first details and motivates our design choices, then provides an overview of the environment interface and implementation, and finally presents the process of exercise authoring. Design Choices. From the start, there were two key points on which we decided to make no concessions.
Neither of these approaches were satisfactory for a course that was going to use the OCaml programming language on a MOOC platform on which very little control was provided. So, we decided to go much further, and pursue an original solution: move everything into the browser, with a real client-side only environment allowing development, execution and testing of the learner's code. To the best of our knowledge, this had never been done before. We started from the existing experiment of the in-browser toplevel TryOCaml 3  , available for OCaml thanks to the js_of_ocaml  [Vouillon and Balat 2014]  OCaml to JavaScript compiler. On top of it, we built a complete, standalone development environment, with a full-fledged code editor, and a flexible, type-safe grading environment that allows to write easily and safely program tests that will be executed directly in the learner's browser.
But of course, all this could have been achieved by simply using different implementations of an abstract report API. The real argument is that reports can be introspected. This can be used for various tasks, such as skipping an exercise if the previous one was unsuccessful, redact or filter a report a posteriori, compare several reports in a smart way thanks to the structural information, or gather reports in order to compute statistics. Safe execution and introspection of learners' code. We rely on OCaml's toplevel mechanism, whose main use is the interactive OCaml evaluator ocaml, a tool used by beginners to apprehend the language as well as experienced users to quickly try short fragments of code. But the toplevel system can be used in various other ways. First, it can be linked with any other compiled OCaml unit to build custom evaluators which are aware of a specific set of libraries or application components.
In the same vein, it can be plugged in a running application as a debug port. Finally, it can be used to load new code in a running application, using OCaml as its own scripting language. For this, the main program can introspect the toplevel environment and obtain its values as if they were its own. But this interface is not typed. All values have type Obj. t, an internal OCaml type castable to any other without any check. The introspection library we describe here is basically a typed layer over this mechanism. In order to use values from the toplevel properly, we had to define a safe type cast operation for OCaml. This is not generally possible, since OCaml does not keep run time type information. In fact, OCaml drops most of the type information just after typing to keep the bare minimum necessary for its language constructs and memory manager.
Experiments have been led to verify that a value is compatible with a type by using only its representation and this minimal information  [Henry et al. 2012]. But in our context, we really want to check that the learner's code has the expected types, not just that it will not make our grader crash. So we had to actually unify the types of the learner's code with our expectations. Obtaining the types of the learner's values is not difficult. The OCaml toplevel works by calling an embedded OCaml compiler to produce a small chunk of byte-code (or assembly depending on the chosen flavour) for each sentence, which is then dynamically loaded and run. We just had to expose the typing environment of the compiler so that our introspection library can obtain the type of any symbol. We also had to provide a way to reflect the types expected by the grader at run-time in the same format.
These type witnesses are also used to derive safe printers and samplers, to produce readable reports and generate test cases. Printers simply output values in OCaml syntax. Samplers are built by derivation of the types' structures, and using a table of custom samplers indexed by type constructors. The table initially contains samplers for built-in types, and is alterable from the grader. The author just has to define a function sample_t: unit -> t to update the sampler for values of type t for the rest of the grading. Advanced ways of customizing random sampling are also provided, but this very simple approach is often enough, as in the example of Figure  4. Once we have this ability to lift the learner's functions in the grader, we have to run them on test cases. Since OCaml is not a purely functional language, this has to be done carefully, in order to handle side effects properly.
For instance, one of the questions was to produce a variable x_power_8, whose name speaks by itself, given an existing x. To help learners debug their solution, the chosen value for x is then provided at the beginning of the report. Then, at some point, the learners were taught how to read code written by other people. For exercising this, we gave them the implementation of a small in-memory database, in which we introduced a bug on purpose. The learners were then asked to find the bug, and to produce a sequence of database queries that would lead to the expected corruption, in a global variable. To check the solution, the grader simply fed the sequence to the originally flawed implementation and to the fixed one, expecting a difference. Complexity. Along with simple exercises, we gave learners a few more complex problems to solve per week.
To examine effects on mutable structures, we use the callbacks of function graders shown in Figure  9. Basically, before_reference will save the state of the structure before launching the solution, then before_user will save the reference result and restore the structure so that both the learner's code and the solution's are launched in the same state, and finally, after will save the the learner's result and restore the Fig. 10. Grading mutations structure to its original value. After that, test will simply have to produce a report using exactly the same mechanism as the one for result values. To avoid reimplementing the technique for each exercise, the library provides a series of callback generators that cover the built-in mutable types of OCaml. For instance, Figure  10  gives an example from the MOOC that uses a callback generator for checking effects on a reference passed as argument.
The exercise asks the learner to write a function that increments a reference and returns its previous value. The report will contain one line for the result and one line for the side effect for each test case (if the result type were unit, the results would be ignored). I/Os. Even if they are also implemented as imperative constructs in OCaml, I/Os are conceptually less difficult to handle than mutations. After all, inputs and outputs can be considered as parameters and results of the the learner's code to grade. That is exactly how it works in the grading library, as already shown in Figure  7. The exec function will trick the learner's code into producing its outputs into buffers, whose contents can simply be tested as if they were result values. Conversely, inputs can be faked by filling input buffers before running the learner's code.
This way, learners were able to find their bugs as early as possible, but they were still difficult to identify, because manually examining parsing states was very tedious. So finally, the last step was to write a result tester by hand that examined the parser states to give hints. And because the library is written as plain OCaml functions and combinators, it was very easy to tweak just the right part. Modules. The last week of the MOOC was dedicated to the module language. Learners learned about wrapping types and values in modules, giving them interfaces, and using the parametric modules of the standard library. To grade exercises that require the learner to define modules, we simply use the first class module mechanism of OCaml. When the get_value introspection primitive is called with an uppercase identifier and a first class module type witness, instead of looking for a variable, it looks for a module.
In practice, to generate this testing code, rather than forging an AST, we simply used plain OCaml functions. We started by defining the basic operations as functions that take as input the module to test. Then, we sequence them using combinators, to obtain the test procedure as a plain OCaml function that takes the module to test as argument. A big advantage is that the generated test code is as well typed as the rest of the grader. Sensible random sampling. As motivated in Sections 3 and 4, we wanted the automatic grader and its reports to be central in the workflow of learners. They would just run the grader and correct their code in a cycle until their reports became completely green. This put lots of constraints on the test cases. First, they had to be exhaustive, to actually find bugs.
WRITING THE OCAML MOOC IN OCAML The platform on which the OCaml MOOC was hosted relies on the Open edX software stack. As most MOOC software, it features a course player for learners, and a WYSIWYG course editor for teachers. These components communicate via a common course archive format, that is also used to download and restore backups. Quite soon in the development of the MOOC, we understood that the WYSIWYG editor was nothing more than an obstacle. Indeed, as computer scientists, the nice level of user friendliness and abstraction provided was not necessary for us, whereas the important amount of clicks necessary to perform basic tasks very frustrating. A lot of operations felt really repetitive, or in other words, could have been automated. So we decided to produce the internal archives offline and use the backup system to upload them.
We also wrote checks that are specific to this MOOC. For instance, each exercise grader is compiled and checked before inclusion, and its maximum score is computed using our reference solution. In the end, the amount of static guarantees lowered the required testing to almost zero, and allowed us to update the MOOC in place in production without hesitation, even for fixing small typos, without even thinking about it. It may not seem that impressive, but to put things into perspective, all other teachers we know who used the same platform told us that they were really reluctant to touch anything once their course was online. Most of the checks listed above are not done at all when updating via the editor or importing an archive, potentially leading to broken or wrongly formatted course contents, and in not-so-extreme cases, data loss, including grades.
4:19 Finally, the level of abstraction of our DSL unties us almost completely from the platform's format, so we will be able to deploy the OCaml MOOC somewhere else in the future, if that becomes necessary. So for all these reasons, we clearly recommend anyone working on a programming MOOC to give this approach a try. The amount of code necessary to implement the DSL was reasonable compared to the actual description of the MOOC, as shown in Figure  23  at the end of the article, yet it was not negligible, so we would be happy if it could serve others' needs.