dataesr/scientific-paragraphs-categorization huggingface dataset:
Helium's open-source, nearcomplete implementation of Haskell 98 provides a roadmap for high-quality error messages and additional language features (e. g. , typeclasses) in future versions of PureCake. Separating the two phases also modularises their implementations and proofs. To the best of our knowledge, we are the first to mechanise such an approach and demonstrate its applicability to verified compilation. Note that CakeML's verified Hindley-Milner type inference uses a traditional, one-pass algorithm. We assume familiarity with Hindley-Milner type schemes ( ::= ∀. ), typing judgements Γ ⊢ ce : , parametric polymorphism, and unification. Polymorphism is introduced by rule HMLet (fig. 5 ) only for type variables not free in the typing context. Using this rule, standard inference algorithms first infer the type of ce 1 fully and generalise it with respect to Γ to produce ∀ n.
Method: Verify Compiler Relations, Not Functions We separate verification of compiler passes from their implementations to keep the PureCake compiler extensible: verification of new passes should be minimally impacted by the design choices of previous ones. Therefore, instead of verifying semantics-preservation of concrete compiler functions, we verify syntactic relations encapsulating each pass. It then suffices to define concrete functions and prove they inhabit the relations. This two-phase approach has several benefits: • Relations can easily impose syntactic restrictions on input code by narrowing their domains. By contrast, similarly restricting total functions requires cumbersome invariants which must be carried between proofs. Now, each relation can be verified orthogonally instead.
The compiler implements both transformations simultaneously. However, we use two distinct syntactic relations to keep proofs tractable: one for a naïve translation into StateLang, and another which compiles away thunk operations. Therefore, the semantics of StateLang must support the thunk values (and corresponding force/delay operations) of EnvLang. Note also that a top-level PureLang program is monadic; it is therefore compiled to a suspended computation in StateLang, and must await unit input to trigger the evaluation of its monadic effects in the correct order. Figure  10  illustrates some of the implementation of this initial pass (denoted ⌊-⌋). In particular, monadic operations return, raise, and bind are compiled to suspended computations; correct compilation of bind relies on the right-to-left evaluation order of StateLang and CakeML.
Following this initial pass, we implement one further optimisation within StateLang. Figure  10  shows that the result of compilation is a soup containing -abstractions that ignore their argument ( _. -) and applications to a unit (-• unit). We clean this up by pushing applications to unit in through let-/letrec-/case-statements and simplifying ( _. ce) • unit to ce wherever possible. A Note on Semantics. As in all predecessor languages, exp_of : ce → e maps compiler expressions to semantic expressions in StateLang. However, the semantics of StateLang is otherwise quite different: a small-step CESK machine  [Felleisen and Friedman 1987]  produces the expected ITree. There is also no need for stateful interpretation of monadic operations ( § 3. 3), as StateLang implements its effectful operations as primitives (i.
(  2 ) (pg. 6), classical quantification over the clock distinguishes diverging and terminating computations. The I/O trace is a growing log of the program's I/O events: each entry contains an output from the program and the response received from the environment. An oracle parametrises the semantics, and is used to determine the environment's response on any given output. Note that the I/O trace may be infinite for diverging programs: it is calculated as the limit of all finite I/O traces. CakeML's core correctness results refer to its functional big-step semantics; however relational big-step and CESK machine  [Felleisen and Friedman 1987]  semantics have also been specified. The former is proved equivalent to the functional big-step style, but the latter is not specified for top-level declarations and its equivalence proofs omit I/O traces for diverging outcomes.
CakeML's compiler correctness theorem states: compilation of a program which does not cause a runtime type error produces machine code with identical semantics up to out-of-memory errors. Machine code semantics is also specified in a functional big-step style per-architecture  (Fox et al. [2017]  give a full account). The "lack of runtime type error" assumption is common for optimising compilers: ill-formed programs can be optimised arbitrarily. New Definitions and Results. To support our work on PureCake, we augment CakeML's CESK semantics with top-level declarations, and strengthen equivalence results to equate I/O traces for diverging outcomes. We also define a new ITree-producing semantics for CakeML in a CESK style. Though we cannot directly equate linear oracle semantics with branching ITree semantics, we can derive a linear trace (tr) from an ITree (tree) by traversing it using an oracle (Δ): tree Δ tr.
ITree-based CakeML compiler correctness. ⊢ target_configs_ok config machine ∧ safe_itree prog ∧ compile config prog = Some code ∧ code_in_memory config code machine ⇒ machine M prunes prog Given well-formed compiler/machine configurations (target_configs_ok) and a source semantics with no derivable type errors (safe_itree), the compiled program can be installed in memory (code_-in_memory) with a machine semantics ( -M ) which prunes the source semantics. Pruning is straightforwardly defined as ITree equality up to out-of-memory errors and ill-formed FFI responses. PureCake Compiler Correctness. Theorem 2 establishes correctness for the PureCake compiler. If the compiler converts an input string str to output CakeML AST ast , then the compiler frontend has both successfully parsed str to a PureLang compiler expression ce and a well-formed namespace of data types ns and type-checked ce to deduce that it is safe, i.
Alternative compiler correctness. ⊢ frontend str = Some (ce, ns) ⇒ safe_itree exp_of ce pure ∧ ∃ ast. compiler str = Some ast ∧ itree_rel exp_of ce pure ast Theorem 4. End-to-end correctness. ⊢ compiler str = Some ast ∧ compile config ast = Some code ∧ target_configs_ok config machine ∧ code_in_memory config code machine ⇒ ∃ ce ns. frontend str = Some (ce, ns) ∧ machine M prunes exp_of ce A Verified Compiler Binary. We build on CakeML's verified bootstrapping  [Myreen 2021b ], which relies on proof-producing synthesis of CakeML AST  [Myreen and Owens 2014]. Given computable HOL4 functions (e. g. , the PureCake compiler), this synthesises CakeML code which is proven to implement the input HOL4 faithfully. Composing synthesis with in-logic evaluation of the CakeML compiler produces a binary that is faithful to the verified PureCake compiler definition.
Performance Metrics We measure performance of PureCake optimisations in the style of an ablation study: removing individual optimisations highlights their contributions to the efficiency of generated code. Isolating optimisations is tricky due to PureCake's verification and multiple intermediate languages: some passes cannot be disabled without breaking proofs, and others are necessary to transform between languages. For example, compilation from PureLang to ThunkLang ( § 5. 2) carries out several optimisations which cannot be separated. Therefore, we consider the following, isolatable passes: • pure, binding group analysis and the associated cleanup within PureLang ( § 4. 2); • demands, demand analysis within PureLang ( § 4. 4); • thunk, the mk_delay smart constructor and optimisations within ThunkLang ( § 5.
It further enables tailored extraction of executable ITrees: users can flexibly target language primitives for efficient testing. ITrees can be considered a Coq-compatible version of the prior constructions above. Our usage is similarly motivated: we need to model uninterpreted effects, non-termination, and general recursion in HOL4's simple type theory. ITrees are conveniently expressible in HOL4 with minimal modification. We noted ( § 3. 3) that we use ITrees as a "convenient semantic domain only", i. e. , we encode the observable behaviour of PureLang programs in the branching structure of ITrees. We do not specify a compositional semantics using the ITree monad, or construct interpreters from event handlers (even to the lesser extent permitted by our modifications). To reason about preservation of semantics in compiler correctness proofs, we simply equate ITrees using strong bisimulation.
Future work might explore a denotational semantics for PureLang using the ITree monad. As in § 6, ITrees are known to admit simple connections to trace-based semantics  [Xia et al. 2020, §7]. Koh et al. [2019]  axiomatise system calls in the Verified Software Toolchain's  [Appel 2014 ] separation logic for CompCert-flavoured C by using ITrees to specify their permitted external interactions. Mansky et al. [2020]  build on this by proving the ITree-based specifications sound with respect to oracle-based CertiKOS  [Gu et al. 2016 ] specifications, which consider only linear traces. Like in § 6, their proofs rely on traversal of ITrees to derive traces. However, they consider only one direction, showing that each ITree specifying the permitted interactions of a CompCert system call encompasses all possible traces of the underlying CertiKOS specification.
CONCLUSION AND FUTURE WORK We have presented PureCake, an end-to-end verified compiler for PureLang, a featureful, Haskelllike language. Our correctness results lift the achievements of CompCert and CakeML to the nonstrict, purely functional paradigm. PureLang's equational theory permits straightforward reasoning about its programs; its compiler front end implements novel formalisations of indentation-sensitive parsing and constraint-based type inference; its compiler back end produces realistic code in the presence of non-strict semantics, and targets the mature CakeML ecosystem. To the best of our knowledge, ours is the first such language to provide these features. Our work is only a first version of PureCake, and we have identified several immediate avenues for fruitful improvements throughout the compilation pipeline: enriching PureLang's syntax, particularly the expressiveness of case-expressions; iterating on our proof-of-concept type inference, taking inspiration from Helium to support more of Haskell 98; improving our implementation of demand analysis; and further optimisations within our compiler back end.
ACKNOWLEDGEMENTS We thank our anonymous reviewers for their constructive feedback and helpful shepherding. We thank  Maximilian Algehed  and  Ulf Norell  of  QuviQ  for their real-world usage of PureCake ( § 7) and for providing a thorough experience report. Kanabar is supported by the  UK Research Institute  in Verified Trustworthy Software Systems (VeTSS); Abrahamsson by the  Swedish Foundation for Strategic Research ; and Myreen by the  Swedish Research Council  (grant no. 2021-05165 ).
Ret error bind e 1 e 2 , , = eval wh e 1 , bind • e 2 :: , return e, , = Ret termination return e 1 , bind • e 2 :: , = eval wh (e 2 • e 1 ), , raise e 1 , frame ::. :: handle • e 2 :: , = eval wh (e 2 • e 1 ), , PureCake: A Verified Compiler for a Lazy Functional Language 145:7 diverge, , = eval wh e = literal (loc l) ⇒ len e, , = Div error, , = return int | ( )| , , action (msg ch s), , = Vis (ch, ) (. ) where bind e 1 e 2 def = monadic bind[e 1 e 2 ], similarly for other monadic operations above. 2 Unlike Haskell's String, PureLang's string is not a list of characters-rather, an efficient representation using packed bytes (like Haskell's Text. ) Proc. ACM Program. Lang. , Vol. 7, No. PLDI, Article 145. Publication date: June 2023.
Commercial software based on artificial intelligence (AI) is entering clinical practice in neuroradiology. Consequently, medico-legal aspects of using Software as a Medical Device (SaMD) become increasingly important. These medico-legal issues warrant an interdisciplinary approach and may affect the way we work in daily practice. In this article, we seek to address three major topics: medical malpractice liability, regulation of AI-based medical devices, and privacy protection in shared medical imaging data, thereby focusing on the legal frameworks of the European Union and the USA. As many of the presented concepts are very complex and, in part, remain yet unsolved, this article is not meant to be comprehensive but rather thought-provoking. The goal is to engage clinical neuroradiologists in the debate and equip them to actively shape these topics in the future.
For example, makers of Software as a Medical Device (SaMD) typically need to describe where their device fits in the diagnostic workflow, regardless of whether it is based on AI or not, by answering the following questions: (a) Who are the intended users of the tool (e. g. , physicians, nurses, or laymen)? (b) Which patient group is the target (e. g. , age range, asymptomatic population vs. patients, clinical presentation)? (c) What input data are needed (e. g. , technical aspects of radiological imaging, the possibility of active quality control)? (d) What is the output of the SaMD and how is this supposed to be used in the diagnostic workflow (e. g. , is it a fully automated diagnosis, a diagnostic recommendation, or worklist prioritization)? The latter furthermore defines the degree of human supervision needed for correctly using the device.
The MDR deals with all sorts of medical devices, regardless of whether they are physical or software products. Most AI algorithms aiming for clinical use will constitute "stand-alone" SaMD (as opposed to software in a medical device, SiMD, which is used to run, for example, an ultrasound machine). The MDR recognizes four risk classes, spanning from I (minimal risk), IIa, IIb, to III (maximum risk), which determine the requirements under the MDR to place the device on the market (see Fig. 1 ). Any SaMD "provid[ing] information which is used to take decisions with diagnosis or therapeutic purposes" needs to be classified at least as risk class IIa  [25]. Going further from here, it is important to consider the possible worst-case scenario (disregarding its probability). If one could think of a "serious deterioration of a person's state of health or a surgical interventional," the device will be classified as IIb; if "death or an irreversible deterioration of a person's state of health" is possible, risk class III is assigned  [25].
Privacy protection in shared medical imaging data Key Points: • Privacy protection is critical for sharing medical imaging data, especially brain imaging. • The way personal data or protected health information, respectively, is being handled is regulated by the GDPR in the European Union and HIPAA in the United States. • Various software solutions exist to de-identify medical imaging data, including the removal of the face for 3D imaging data, but they need to be used with caution due to a risk of re-identification and potential corruption of medical imaging data. • Federated learning may be a way to avoid sharing medical imaging data for training a machine learning algorithm. As current AI algorithms need a large amount of training data during development, many hopes lie in large, aggregated imaging datasets.
As imaging techniques like magnetic resonance imaging (MRI) have become more accessible and sharing large amounts of data has become feasible, several large-scale datasets have been collected and made available to the public  [27, 28]. In addition, individual study datasets can be shared through repositories such as openneuro. org [29]. However, several important points have to be considered before sharing imaging data in neuroradiology. First, who actually owns medical imaging data and is there a problem regarding ownership when it comes to data sharing? It has been stated that, in general, healthcare facilities in the USA have "'ownership' rights" over medical imaging data that they generate  [30]. However, this ownership is usually not the only factor to consider since the patients are granted certain rights in their medical imaging, and their privacy needs to be protected when it is shared.
After providing a broad overview of HIPAA and the GDPR, we will now look at what kind of data is actually stored in medical imaging. Digital Imaging and Communications in Medicine (DICOM) objects and images are made up of both pixel data and metadata. Metadata includes information like the patient's name, date of birth, and data about the particular scanner where the images were acquired. De-identification under HIPAA, for example, requires 18 specific identifiers that need to be eliminated in order to make a data set free of PHI  [39]. Among those are the patient's name, date and time, medical record numbers, social security numbers, device identifiers, full face, photographic and comparable images, and any other unique identifying number (e. g. , the serial number of an implanted device such as a pacemaker)  [34].
It can be very challenging to de-identify a dataset in case of so-called burned-in PHI. This could either be information like a project, a name, time, and date stamps in the image, which are common in ultrasound, fluoroscopic, radiographic images, and also secondary captures. These burned-in pixel data need to be "blacked out" (redacted) by replacing the pixel values using an image editor or dedicated tools. An overview about available software tools for de-identification or pseudonymization can be found in Table  1. A specific problem associated with 3D brain imaging is the possibility of reconstructing the face, which can then be processed by widely available face recognition software (e. g. , for smartphone unlocking)  [6]. Of particular note, an AI face recognition company was recently fined 20 million euros for several breaches under the GDPR  [40].
There are a couple of different noncommercial approaches that allow the removal of facial features, such as PyDeface (https:// github. com/ poldr acklab/), mridefacer (https:// github. com/ mride facer/), and Freesurfer's mrideface (https:// surfer. nmr. mgh. harva rd. edu/ fswiki/ mri_ deface)  [41]. However, they do not work in all cases and may affect the imaging properties of the brain itself. After de-facing with common software, a recent study has shown that 28 to 38% of scans still retained sufficient data for successful automated face matching  [42]. Moreover, studies demonstrated that volumes and quality measurements are affected differently by de-facing methods. It is likely that this will have a significant impact on the reproducibility of experiments or performance if used by SaMD  [42] [43] [44].
Both compounds were docked into the target binding site (PDB ID: 5HJ9) using MOE 2016. Arginase was taken as the targeted enzyme which is an important enzyme for leishmania species' survival. Arginase up-regulates amastin that impacts amastigote replication and survival. This approach aimed to explore the binding modes of the two isolated flavonoids and to predict their inhibitory activity against arginase. Results: The two flavonoid compounds isolated from P. integerrima were evaluated for their antileishmanial activity. Compounds 1 and 2 were tested at a concentration of 5 lg/mL against the selected Leishmanial species. The percent inhibition was 70. 43 and 74. 76 regarding compounds 1 and 2, respectively with IC 50 of 29. 43 and 16. 43 lM. The reference standard drug used, amphotericin-B, displayed the highest leishmanicidal effect (IC 50 of 0.
Docking studies The ChemDraw Ultra 8. 0 was used to draw the 2D structures of the two isolated flavonoid constituents, naringenin 1, and the 3,5,4 0 -trihydroxy-7-methoxy-flavanone 2. The crystal structure of leishmanial Mexicana arginase PDB ID 5HJ9 was retrieved from the PDB (Protein Data Bank)  Hai et al. , 2016. Energy minimization was fixed and charges were added by the MOE software. The minimized structure was used to dock the compounds in the active site of the receptor. Furthermore, the best score compounds were selected and visualized in the MOE software for protein-ligand interaction analysis  (Malayeri et al. , 2017).
Results The two flavonoid compounds isolated from P. integerrima were evaluated for their anti-leishmanial activity, as presented in Table  1. Compounds 1 and 2 were tested at a concentration of 5 lg/mL against the selected Leishmanial species. The percent inhibition was 70. 43 and 74. 76 regarding compounds 1 and 2, respectively with IC 50 of 29. 43 and 16. 43 lM. The reference standard drug used, amphotericin-B, displayed the highest leishmanicidal effect (IC 50 of 0. 22 lM) with 84. 09 % inhibition at half concentration compared to compounds 1 and 2. To investigate the nature of the interactions between the two flavonoids and the targets, both compounds were docked into the target binding site (PDB ID: 5HJ9) using MOE 2016  (Mirzaei et al. , 2020). The targeted enzyme was arginase, which is an important enzyme for leishmania species' survival.
Statistical analysis Statistical analyses were performed with GraphPad Prism 9. 4. 1 (GraphPad Software, San Diego, CA, USA). A Two-Way Anova with Sidak Post-Hoc test was used to assess whether there were signi cant differences between the ltration e ciency results of the BFE test method and the VFE test method. Pvalues < 0. 05 were considered signi cant. Correlation coe cients for the comparison of ltration e ciency between the test methods were obtained using Excel.
From this analysis, chromatin regulatory genes were identified in cases but not controls. This was followed by a gene set approach to investigate 19 gene sets chosen from genes that are constrained, essential to cell function, genes that are likely to have features of haploinsufficient genes as well as gene sets chosen from the Pediatric Cardiac Genomics Consortium (PCGC) for studies of sporadic CHD in the general population. We then used two different statistical approaches for analysis. We used an over-representation method and a weighted gene set method based upon gene expression, on genes affected in one or more subject. We then compared our findings to that of sporadic CHD in the general population as a validation step and examined expression of the genes in mouse embryonic transcriptomic data relevant to heart development.
1b ). Comprehensive annotation software and algorithms were used (see Methods) to identify 55,379 variants including LoF, splicing and putative damaging missense variants (Supplementary Table  2 ; Supplementary Fig. 4 ). Additional software and algorithms were used for further filtering (phastCons > = 0. 5, for evolutionarily conserved variants; CADD > = 10 for deleteriousness of variants, CCRS > = 80 for constrained coding regions; Supplementary Fig. 4 ) to identify 1861 highconfidence, predicted most damaging rare coding/splicing variants (MDRV, Fig. 1b ; Supplementary Table  3 ; Supplementary Figs. 4  and 5 ). Once the variants were identified, the number of MDRVs were calculated per subject. A total of 1. 78 MDRVs were found per subject in 22q11. 2DS-CTD cases and 1. 85 MDRVs were found per subject in controls, with no significant overall excess of MDRVs in either group (P = 0.
2DS-CTD cases were missense changes predicted to be damaging (Fig. 4c ). From examination of clinical databases, 39 of 42 were considered variants of unknown significance (VUS; Table  2  and Supplementary Table  10 ). We then wanted to ask whether the types of variants in chromatin regulatory genes found in 22q11. 2-CTDs might be similar to those found in studies of sporadic CHD. In contrast to 22q11. 2-CTDs, protein truncating variants (PTVs; loss of function, LoF) were found more frequently in sporadic CHD by the PCGC (Fig. 4c )  21, 22, 31. This was similar for studies by Sifrim et al. 23  (Fig. 4c ). Further, many of the variants identified in studies of sporadic CHD, in particular for chromatin regulatory genes, were de novo heterozygous mutations, but the variants we identified were of unknown inheritance.