dataesr/scientific-paragraphs-categorization huggingface dataset:
The motivation for this paper is to devise a system for reporting type errors in ML programs that (1) produces messages that are always concise;  (2)  eliminates as much as possible of the left-to-right bias associated with traditional type-checking algorithms;  (3)  does so in an efficient and predictable manner; (4) integrates smoothly into an existing type-checker for a full-blown language. In this paper, we show that, with a small number of carefully-crafted changes to the order in which unifications are performed by the type inference engine of OCaml, and with appropriate processing of the conflicts that may arise from these unifications, we are able to generate messages that, we argue, provide the programmer with much more useful information for locating and fixing type errors, and also requires less knowledge of the type inference algorithm.
The main features of our approach are as follows: -Improved error messages for function applications; in particular, better treatment of errors involving higher-order functions (e. g. , List. fold) and arithmetic operators (e. g. , '+' in place of '+. '), as described in Section 2. -Improved error messages for incompatible branches in conditional and pattern matching constructs, as described in Section 3. -Improved error messages for subexpressions that do not have the type expected by the language construction in which they appear, e. g. , a while loop condition that does not have type bool, as described in Section 4. -Improved error messages for very common ML-specific errors: missing '()' arguments, missing '!' operators, or missing 'rec' keywords, as described in Section 5. Our approach is implemented as a patch to the OCaml compiler, consisting of a few hundred lines of code.
The patched compiler offers a new flag, called -easy-type-errors. When this flag is activated, the compiler first runs the original OCaml type-checking algorithm. If there is no error, then our modified type-checking algorithm is not executed at all. Otherwise, our patched compiler considers the first toplevel definition that fails to type-check and attempts to type-check it again, this time using our modified algorithm, in order to produce the error message that will be reported to the user. (Note that the top-level definition considered for re-type-checking could be one item from a local module definition. ) Thanks to our strategy of first running the original type-checking algorithm, we are able to guarantee full backward compatibility: any program that compiles with the traditional OCaml compiler also compiles with our patched compiler in -easy-type-errors mode, and moreover compiles without any runtime overhead.
Besides, since our modified type-checking algorithm is only slightly slower than the original algorithm, we are able to report errors efficiently even in large-scale programs. For example, we tested the ability of our patched compiler to produce error messages for bugs artificially introduced in several-hundred lines long functions located in the middle of the implementation of the OCaml typechecker itself. Our patch is compatible with nearly all of the OCaml language, with GADTs and overloading of record fields as notable exceptions. Programs including GADTs can be compiled with the flag -easy-type-errors activated, however if a type error occurs in a top-level definition using GADT features then the error message produced will not be helpful. One exception is for format functions (e. g. "printf"), whose types now make use of GADTs in OCaml.
We recognize calls to such format functions and locally process them using the original type-checking algorithm. Regarding overloading record field names, our patch does not support them because the overloading resolution is sensitive to the order in which unifications are performed, and this order is modified by our alternative type-checking algorithm. (More generally, our patch expects the source code to correctly type-check with the -principal option of OCaml. ) Our patched compiler can be obtained and executed through the following commands. Towards a new algorithm To type-check a curried application, the OCaml type-checker first infers the type of the function, extracts from it the types expected for the arguments, and then unifies these types one by one with the types of the arguments provided to the function.
This process introduces a significant left-to-right bias in the case of polymorphic functions. Indeed, the unification of the first arguments may result in instantiation of polymorphic variables that may later raise conflicts when processing the subsequent arguments. Our new algorithm for type-checking applications instead works as follows. First, we compute the most-general type of the function and of each of the arguments provided, independently. Then, we try to unify the types for the application, using the same code as the original OCaml type-checker. However, if this unification process raises an error, then we catch this error and rely on a new piece of code for generating the error message. The message we produce systematically locates the error on the entire application. It then reports a table with a first column showing the types expected for the arguments, and a second column showing the types of the arguments actually provided.
Note that, in order to properly report the type of the arguments when they include polymorphic components, we need to save copies of the types before we start to unify them. We construct these copies by computing the types or type schema associated with the arguments, following a process similar to the procedure involved for generalizing the type of the body of a let-binding. The following example illustrates a case where the function passed to List. map operates on integers although a list of float values is provided. The source code is followed by the error message produced by the original OCaml compiler, then by the error message produced by our patched compiler. File "examples/example_map_bad. ml", line 1, characters 35-38: Error: This expression has type float but an expression was expected of type int New error: File "examples/example_map_bad.
For the example above, we would report that 'a is being instantiated as int -> int. Extension for labelled and optional arguments We have extended our algorithm to support labelled arguments and optional arguments featured by the OCaml language. Note that our current implementation does not place arguments with corresponding labels face to face; we plan to fix this in future work. An example follows. File "examples/example_apply_labels. ml", line 6, characters 25-28: Error: This expression has type float but an expression was expected of type int New error: File "examples/example_apply_labels. ml", line 6, characters 2-3: Error: The function 'f' cannot be applied to the arguments provided. | Types of the expected arguments: | Types of the provided arguments:  ---|-------------------------------------|----------------------------------.
Error reporting for incompatible subexpressions If a language construct expects a subexpression to be of a given type (e. g. , loop conditions should have type bool) but that the subexpression provided by the programmer does not have this type, then we produce a specific error-message, e. g. "This expression is the condition of a while loop, so it should have type bool, but it has type foo. " We find that such specific error messages are much easier to parse and to interpret than generic unification error messages, especially for beginners. The idea of syntax-specific rules for type error messages is not new. Yet, somewhat surprisingly, it does not seem to have been applied in the implementation of popular ML compilers, although we learned that Ishii and Asai  [12]  recently implemented such syntax-specific error messages in an external type debugging tool for OCaml.
let _ = while 1 do () done Old error: File "examples/example_while_bad_condition. ml", line 3, characters 9-10: Error: This expression has type int but an expression was expected of type bool New error: File "examples/example_while_bad_condition. ml", line 3, characters 9-10: Error: This expression is the condition of a while loop, so it should have type bool but it has type int. The next example involves a conditional without an else branch. This example is particularly interesting because it consists of a program that is perfectly valid from a semantics point of view, yet fails to type-check. We have seen equivalent programs written in practice by beginners using OCaml as a first programming language, and we have seen them being completely stuck-it appears to be very hard for a beginner to fix a program that is inherently correct! The function considered takes two arguments and returns an ordered list storing these two values.
" The following example shows a program with a call to read_int that is missing its unit argument. File "examples/example_missing_unit_readint. ml", line 2, characters 10-11: Error: This expression has type unit -> int but an expression was expected of type int New error: File "examples/example_missing_unit_readint. ml", line 2, characters 0-9: Error: The function 'print_int' cannot be applied to the arguments provided. | Types of the expected arguments: | Types of the arguments:  ---|-------------------------------------|---------------------------------- -- 1 | int | unit -> int You probably forgot to provide '()' as argument somewhere. The next example shows another instance of a missing unit argument, this time on a call to the function print_newline. When OCaml is used without the strict-sequence flag, it reports that some arguments are missing, whereas we are able to be more specific, reporting that the argument "()" is missing.
To that end, McAdam proposes to type-check subterms bottom-up, returning a type and a substitution for flexible type variables, and to then try to unify the substitutions involved. In our work, we also type-check subterms bottom-up, and the subterms are processed relatively independently, even though we do not manipulate and compare substitutions explicitly but instead stick to a standard global union-find data structure. In particular, our implementation reuses all the data structures and infrastructure that already exist in the OCaml compiler. By processing the subterms more independently, we are able to remove nearly all of the left-to-right bias, even though, as we have explained, there remain a few cases where unification leads to side-effects visible across subterms. We find our approach to be a good compromise between the aim to treat subterms as independently as possible and the need for conciseness, predictability, simplicity and efficiency.
The possibility of performing unifications in different orders is also discussed in by Lee and Yi  [14] , who show how several existing algorithms (W , SML/NJ's algorithm, OCaml's algorithm, H , M ) can be viewed as particular instantiations of a general algorithm. It is likely the case that our strategy for typechecking applications could also be described as an instantiation of this general algorithm. However, Lee and Yi do not discuss which instantiations might be best suited for error reporting, and do not discuss the treatment of n-ary applications and pattern matching. Heuristic-based approaches Helium  [10, 9] , by Hage and Heeren, is a type-checker designed to produce better error messages for a subset of the Haskell language. The Helium type-checker builds the complete unification graph, and then relies on a number of heuristics for reporting a probable cause of the error.
Seminal  [16, 15] , by Lerner et al. , is a tool that applies interactive debugging to the core OCaml language, making use of the standard OCaml type-checker as a black-box. Once the type-checker has produced a list of probable locations for the error, Seminal relies on a number of heuristics for ranking the error messages and reporting the presumably most-useful ones first. We ran Seminal on our set of example programs. We observed that Seminal produces very useful error messages for swapped arguments, for missing "!" and missing "()". However, for a number of programs, the error messages were not so helpful, and sometimes worse than the error produced by the original OCaml type-checker. Moreover, every time the tool reports not just a single cause but several plausible causes for the error, the error message was fairly long, which we felt could discourage programmers or at least decrease their productivity.
Conclusion We have presented a practical approach to improving type error messages in OCaml, in particular by decreasing the amount of left-to-right bias, while preserving an efficient and predictable algorithm that produces concise messages. Our implementation covers all the commonly-used features of the OCaml language. As we have argued, the approach scales up to large-scale programs with virtually no overhead. While our work has been mainly motivated by OCaml, we believe that our approach to reporting errors for applications and branching constructs could be similarly applied in other functional programming languages.
Introduction Viet Nam has experienced rapid demographic changes over the last three decades, illustrated by the now almost completed fertility transition and the intensification of migration across the country. In contrast with these phenomena, accompanying changes in household structures are poorly documented even when they reflect crucial transformations in the social and demographic fabric of contemporary Vietnamese society. In particular, there is no research devoted to the trends affecting the population living alone, in spite of its significant growth since the 1990s. This paper presents a systematic analysis of the growing number of one-person households observable in the country. We will begin with a presentation of the data used and an overview of the Vietnamese context and of household structures to highlight the variety of family arrangements during the last census.
Data and methodology used for a disaggregated analysis of household Our analysis is based on the micro-data drawn from the 2009 census of Viet Nam. Compared with other data sources, such as the sample surveys recently conducted in the country, this source presents several advantages as well as limitations. The major asset of using the census dataset is its size, and this is the first reason why we are using it for our analysis. Census micro-data are based on the long-form questionnaire that was used for 15% of the population in 2009. As such, it covers 14. 2 million individuals and 3. 7 million households. 3  In comparison, the regular Household Viet Nam Living Standards Survey (VLSS) (conducted since the early 1990s) is much smaller. The most recent VLSS round covered 69,360 households in 2010 and is therefore fifty times smaller than the 2009 census sample.
The 2010 VLSS subsample, with all the complete social and economic information, is reduced to 9,400 households. This size proscribes any social and regional disaggregated analysis of the one-person households, which account for less than 5% of the VLSS sample. 4 he considerable size of the census sample allows us to focus on the less frequent one-person households that constitute 7. 3% of all households. This proportion, derived from the census count, is significantly higher than that reported by the 2010 VLSS survey (4. 9%), a difference that may be attributed to the more systematic approach of census operations. The 2009 census sample includes about 260,000 such households, 5  with people living in a one-person household representing 2. 7% of the population aged 15 and over. Census data can be further disaggregated by urban and rural areas, as well as for the 63 provinces (Tinh) that comprise Viet Nam at the time of the census.
Available data include standard census variables related to individual sociodemographic, educational and economic characteristics, as well as household-level information on housing quality and amenities. Household members are defined in the census as persons "sharing food and living space", but they do not necessarily have a joint budget or a family relationship. Since the definition of household members is de jure, some short-term migrants may be considered as "usual members of the household" even though they may be absent. This may account for the high overcount rate (1. 8%) reported by the post-enumeration survey. One of the main limitations of the census is the absence of residential or economic data on other family members staying in separate households, such as longterm migrants or married children.
In addition to the tabulations obtained from census microdata, we will present results of multivariate logistic analyses. We will use all sociodemographic, sociocultural, socioeconomic, disability and geographic data from the census data to identify the main determinants of solo living. This multivariate model allows us to study the influence of each factor, after controlling for other factors, and provides net (adjusted) odds ratios. We will also present results from an additional regression model of the probability of living alone, restricted to the widowed population, at the end of the paper.
The strong number of adults aged 20-50 years can explain the high participation rate, but the distribution across employment categories and sectors reflects that of the entire population of Viet Nam. Yet, the reason why this population resides alone is not as straightforward as for the first cluster. Why are younger single people living apart when they have not migrated to a different district? Why are currently married people living on their own and not with the rest of their family? In the absence of reported migration, these solitary living arrangements appear somewhat startling, with the exception of people who are divorced or separated from their spouse (21% of this cluster). A possibility is that census data do not faithfully reflect mobility because it ignores long-term migrants (migration longer than five years) or simply by underreporting migration.
It is therefore worth examining whether a statistical analysis can shed light on the factors linked to the isolation of some widows and widowers. To do this, we have again used the 2009 census data and isolated from the 15% sample the widowed population -composed of about 680,000 individuals, irrespective of their household type. The method used is similar to the earlier multivariate logistic analysis of the determinants of living alone, except that it is only applied to the widowed population. The results of this analysis are presented in Table  6. This statistical analysis brings out several significant findings about the factors accounting for the isolation of widows and widowers (Table  6 ). In particular, it allows us to identify the precise impact of specific factors, such as urbanization, impairment or ethnicity.
1 We hypothesised that either alteration in pathways of muscle atrophy or in the components of muscle itself might provide more robust biomarkers. Muscle wasting occurs as a result of an imbalance between protein synthesis and degradation. ] [8] [9] [10]  Despite this knowledge, there remains limited data relating to human cancer cachexia. 2] [13] [14]  Ideally, a biomarker should be assessed with the minimum of discomfort or complexity to the patient. However, at the level of biomarker discovery and biomarkers that can inform pathophysiology or drug targets, more invasive methods (e. g. muscle biopsies) may be required until a less invasive correlate can be identified. We sought to identify potential clinically relevant cachectic biomarkers in skeletal muscle biopsies from UGIC patients in relation to weight-loss and post-operative survival.
Quantitative real-time-polymerase chain reaction Total RNA was extracted as described previously. cDNA was prepared using 1 μg RNA, TaqMan reverse transcription reagents (Applied Biosystems, Foster City, CA, USA), and random hexamer primers (Applied Biosystems). Primers were designed to span introns using primer express 3. 0 software (Applied Biosystems), and the primers were constructed by Invitrogen (Paisley, UK). Primer sequences used were BNIP3_Fw; GTC AAG TCG GCC GGA AAA TA, BNIP3_Rv; GCG CTT CGG GTG TTT AAA GA, GABARAPL1_Fw; CCA CCG CAA GGA GAC AGA AG, GABARAPL1_Rv; GAA AAT GTG ATG ACG GTG TGT GT, MAFBX_Fw; CCG GCT GTT GGA GCT GAT A, MAFBX_Rv; TTG GGC GAT GCC ACT CA, MURF1_Fw; GCT AGG CGT GGC TCT CAT TC, and MURF1_Rv; TCC TGG ATC AGG CTC GAC TT. Samples were run on an Applied Biosystems 7900HT fast real-time polymerase chain reaction (PCR) system (Applied Biosystems) in triplicates of 20 μL per well using SYBR green PCR master mix (Applied Biosystems) as per manufacturer's instructions.
Acknowledgements We are grateful to the consultant oesophagogastric ( Mr S. Paterson-Brown ,  Mr A. C. de Beaux ,  Mr G. W. Couper ,  Ms A. Paisley ,  Mr P. Lamb , and  Mr B. Tulloh ) and hepatobiliary surgeons ( Professor O. J. Garden ,  Professor S. J. Wigmore ,  Professor R. W. Parks ,  Mr R, Ravindran ,  Mr E. L. Hidalgo ,  Mr J. J. Powell , and  Mr J. Casey ) at the  Royal Infirmary of Edinburgh  for assistance with patient recruitment and muscle biopsies. We thank  Professor Jamie Timmons  for help with PCR methodology and primer design. The study complies with the ethical guidelines for authorship and publishing in the  Journal of Cachexia, Sarcopenia and Muscle (von Haehling S, Morley JE, Coats AJS ,  Anker SD. Ethical  guidelines for authorship and publishing in the Journal of Cachexia, Sarcopenia and  Muscle.
Study Participants and Methods The study was conducted at the Department of Molecular Biology and Genetics, Silesian Medical University School of Medicine in Katowice, from February to May 2012. Twenty three male patients, mean age 19. 3 ± 6. 6, affected by Fragile X syndrome, confirmed by detection of full mutation in the FMR1 gene, were recruited through registry databases maintained by Medical University of Silesia, Upper Silesia Center of the Children's Health John Paul II in Katowice. All participants harboured the "full mutation" form of the FMR1 gene. Diagnosis of Fragile X syndrome was based on clinical criteria and molecular analysis of the FMR1 gene. The control group comprised 24 healthy males, mean age 21. 8 ± 5. 8 years. The study protocols were approved by the local Ethical Committee of the Faculty of Medicine, Medical University of Silesia in Katowice.
Statistical Analysis Data are presented as means ± standard deviations. The Kolmogorov-Smirnov test was used to determine whether continuous variables are normally distributed. Differences between normally distributed variables were assessed with the independent samples t test. The Mann-Whitney U test was used to examine all non-normal continuous variables and Spearman's non-parametric correlation coefficient to calculate correlations. For all tests, a probability (p) of less than 0. 05 was considered statistically significant. Statistical analyses were performed with SPSS statistics software, version 10 (StatSoft. Inc. DELL, USA).
Results Patients and controls were matched for age. The demographic and anthropometric data are shown in Table  1. Serum lipid profiles are shown in Table  2. The results are presented as means and standard deviations. Overweight and obesity were observed in 60. 86 % of FXS group. Comparison of the TC, HDL, LDL and triacylglycerols, values from FXS patients to those from the control group showed that mean values of the serum levels of HDL-C were significantly lower in FXS patients (43. 4 ± 7. 0 FXS vs 56. 3 ± 12. 6 control, p < 0. 001), the serum levels of triacylglycerols, were higher in FXS patients (133. 3 ± 57. 2 FXS vs 94. 7 ± 64. 6 controls, p = 0. 035). The TC and LDL-C levels did not differ statistically from the controls. There was no significant correlation between BMI and TC, HDL-C or LDL-C levels in FXS group.