dataesr/scientific-paragraphs-categorization huggingface dataset:
2 and 4. 4). Finally, we also study how to extend this theory to account for mutation since, in modern languages, records are often also mutable structures, in which elds can be added removed, and modi ed; for space reasons this extension is not presented in the main text, but the motivated reader will nd its presentation in Appendix F. We want to conclude this discussion on our contributions, by stressing that we think that the interest of this work is less in de ning a catch-them-all theory for the di erent usage of records, than in developing some general implementation guidelines that, with minimal adaptions, can capture all the aspects outlined above. This is not just a theoretical challenge: at the moment of writing the very implementation techniques introduced here are being experimented by the development teams of Elixir and Ballerina languages to be included in their compilers.
Since we cannot consider all of them, we just give an example of a common one. In our calculus, \ℓ works also when ℓ is not de ned in , but some languages (e. g. , Elixir) require the eld to be present for deletion. It is possible to encode such a discipline by a suitable pattern matching (see Section 3. 3) or by directly modifying the static and dynamic semantics to do so. The modi cations in the latter case are really minimal: it su ces to use for the typing rule [D ] the same premise as in rule  [S ]. Also, the generic 1 + + + 2 can be used to type record operations other than concatenations and elds deletions. For instance,  Frisch [2004, Section 9. 5]  shows that, given an expression of record type and a set of labels = {ℓ 1 ,. , ℓ }, the record obtained by restricting to the elds in is typed by + + + • {[ℓ 1 = = • ,.
ℓ, which coincides with the rule  [S ]. Likewise, to de ne the delete operation that requires the presence of the eld ℓ to be deleted, we no longer need to modify the typing rules as we outlined in Section 3. 2. 3: it su ces to encode it as "match with { { {ℓ = = 1} } } → \ℓ" which returns a static type error if ℓ is not present in. The type system presented in this section is sound: every well-typed expression either diverges or returns a value of the same type (see  [Frisch 2004] ). It describes records (and, partially, pattern matching) as they are currently implemented in the language CDuce.
, , ⇒ 0} } }. With this new syntax we can now express the type of maps from labels to, say, integers as { { { ⇒ Int} } } (or, equivalently, {| {| {| ⇒ Int|} |} |}). This syntax covers the simple case of maps whose domain is always the whole set of labels. This is compatible with what happens for JavaScript objects where the set of labels (i. e. , the properties names) is the set of all strings. Likewise, in Ballerina the type map<T> is the set of mappings from keys of type string to values of type T: we show later in Section 4. 4 how to modify the calculus to re ne domains. The new syntax also allows us to combine structs with maps in the same type, as we showed by the example { { {ℓ 1 ⇒ 1 , ℓ 2 = = 2 , ⇒ 3 } } }. Thus, for instance, it is easy to express by a type the fact that a speci c label is used to determine the kind of the map, as in { { {output = = "int", ⇒ Int} } } ∨ { { {output = = "str", ⇒ String} } }.
Erlang-Style Maps In the rst part of this section we de ned a very simple case of maps whose domain was always the set of all labels. This suits languages in which record keys are of a speci c and limited type (e. g. , strings for Ballerina's maps and JavaScript's objects, integers and strings for PHP). However, there exist more re ned type-systems that allow a larger range of keys in maps, and for which it makes sense to specify the domain of the maps. For instance, in Go the syntax map[int]string denotes the type of maps from strings to integers, which is the same as Scala's Map[Int,String] and Swift's [Int: String]. We want to extend the previous system so that it is possible to restrict the domain of the maps and still be able to combine them with single eld declarations as in {| {| {|input = = "int", Int ⇒ Int|} |} |} ∨ {| {| {|input = = "str", String ⇒ Int|} |} |} which is a slightly modi ed version of the type we de ned at the beginning of Section 4, except we replaced the wildcard " " with a domain type.
Let us call this union type S. The idea that the (mandatory) eld input in the records of type S is used as a ag to specify the kind of map the record contains. It becomes then possible to deduce the type S→(integer|nil) for the following function (in pseudo-syntax): function foo(x : S) = match x with | { input = "int" } -> x. [42] | _ -> x. ["42"] The match expression checks whether the eld input contains the string "int" and if so it deduces that x maps integers to integers, otherwise it deduces that it maps strings to integers. Since the union S is formed by closed record types, trying to select in x anything that is not an integer in the rst branch and that is not a string in the second branch would yield a static type error. In some languages, like Erlang and Elixir, it is possible to de ne the union type above.
In practice, this amounts to modify the de nition of elds as follows: Fields ::= ℓ = = | ℓ ⇒ | ⇒ Key Types ::= Int | Bool | String | 1×1 | 0→1 | { { {} } } | where ℓ denotes a value of type L. For the sake of simplicity, we used in the de nition of key-types only three basic types (Int, Bool, and String) but in practice each language will choose some speci c basic types (e. g. , in Elixir key-types will also include atom(), the type of all atoms, but only String in JavaScript). For the sake of the example we also added 1×1 the type of all pairs (introduced in Section 2. 1). What does matter is that all the key-types (di erent from ) are pairwise disjoint and that their union is equivalent to L, that is it covers all the admitted record labels. 13  In the case above if we suppose that we speci ed in the key-types all basic types, then we also have that the union of all key-types is equivalent to 1 (i.
This partition must be the same for the whole program, but nothing prevents us to use di erent partitions in di erent programs. Therefore, this partitioning can be user-de ned. Of course, this raises modularity concerns when combining programs with di erent partitions. But again, this is a problem of language design and implementation, not of types. For instance, at the moment of writing we are studying with the development team of Elixir the possibility of having user-de ned partitions for maps whose keys are tuples. The idea is that the programmer will be allowed to declare the tuple key-types used in her/his program (e. g. , pairs of integers, triplets of a string and two integers,. ). Record type atoms will store in their tuple component a binary tree (instead of a single default type) that represents the nite partition of the tuple space, and when composing two di erent programs the subtyping algorithm will merge the two corresponding trees to compute the meet of the two partitions ( nite partitions form a complete lattice).
Once this will be achieved, then we will study how to make the system infer this partition, without the need for the programmer to declare them, thus making their use transparent. Default values. Another obvious variation that our theory can account for are record expressions with a default value (which is a feature of Ballerina's records). For instance, one could allow the program to initialize the constant part of a record expression, by using the syntax {ℓ 1 = = 1 ,. ℓ = = , _ = = }. It would then be possible to relax the constraint that elds for (in nite) key-types must be optional-e. g. , {"uno" = = 1, "due" = = 2, = = 0} is a map of type { { {String = = Int} } } (notice the mandatory eld in the type). The selection of a string key for a record of this type will then have type Int (rather than nil∨Int) and we should modify the map-selection operator.
CONCLUSION The motivation of this work comes from our recent and ongoing collaborations with the development teams of two languages, Elixir and Ballerina, aiming at de ning new type systems based on semantic subtyping to be implemented in their compilers. In both cases, an important amount of time was and is being spent on record types. Although the two languages are quite di erent, both needed to type single records uniformly both as maps and as structs in the way presented here. For this, the typing of records as implemented by the language CDuce and which is based on the theory of quasi-constant functions by  Frisch [2004, Section 9. 1]  was not enough, and we had to extend and generalize both the theory and the algorithmic aspects of quasi-constant functions, by devising the quasi K-step functions we introduced here.
For the sake of the presentation, in this article we recalled some results on records by  Frisch [2004] , such as the decomposition law of Lemma 2. 3, the properties (11-13), De nition 4. 1, and Theorem 4. 2: in those cases the original work is explicitly cited; in all the other cases the results presented here are new. In particular, the function Φ for the subtyping algorithm of Section 4. 3 is a high-level formal speci cation and a generalization of what happens in the (highly-optimized) code of the CDuce compiler, and that was never formalized; the proof of its correctness (Theorem 4. 5), thus, is a new result. Also, obviously, everything that concerns maps (as opposed to structs) is original to this work: the de nitions of the type operators for map-like operations; the generalization of quasi-constant functions into quasi K-step functions; the derivation of the corresponding decomposition law stated in Lemma 4.
7, which generalizes Lemma 2. 3; the generalization of the Φ function to work with quasi K-step functions, and the fact that the latter are de ned so that they preserve all the previous meta-theoretic properties. The work presented here lays the foundation to type-check records in Ballerina, Elixir, and, we hope, other languages, but both for Ballerina and Elixir, the problem of typing records goes well beyond what we presented here. For Ballerina, we had to formalize the fact that record elds in Ballerina may be mutable. The challenging part was that the design principles of Ballerina require the subtyping relation to satisfy properties at rst sight counterintuitive to a functional programmer (immutable pointers can be used where mutable ones are expected, reference types are covariant, pattern matching disregards mutability) and this yielded an original and intriguing theory for records with mutable elds that space constraints did not allow us to present here: the curious reader can nd it in Appendix F.
F MUTATION Records and mutations are often intertwined, especially in dynamic languages. In JavaScript, for instance, every eld is highly mutable: it can be added, modi ed, erased. Some languages introduce a more controlled way of mutating: in Ballerina, lists and records are by default mutable but only within certain limits established by the type statically declared for them ( elds can be declared to be readonly and there are ways to transform mutable elds into readonly ones and viceversa); in Julia, it is exactly the opposite since records (i. e. , composite types) are immutable by default (even if their elds can contain mutable values) but they can be declared mutable. Some functional languages introduce mutation via records: in OCaml a value of type ref int is a record with a eld contents that contains an integer, that is, a record of type {contents: int}; in CDuce a value of type ref int is also a record, but with two elds instead, get (to read the location) and set (to write the location), that is a record of type {set: int -> (), get: () -> int}, since this directly enforces the classic invariant subtyping relation for reference types (see below).
In this section we de ne a uni ed theory of mutable locations that encompasses such di erent type discipline as those de ned for OCaml/CDuce references and those for Ballerina locations, and then embed them in the record/map theory of the previous sections to type the structures of Ballerina and similar languages. In particular, we de ne a unique framework in which we will be able to interpret both the classic invariant mutable reference types that can be found in Rust or CDuce and the mutable record types of Ballerina. These constitute two extreme points in the design space for subtyping mutable locations. On one end of this design spectrum, invariant references form a stricter discipline with stronger static safety guarantees, but they break subtyping insofar as invariance is the only possible subtyping relation.
F. 1 A Theory of Locations The most general way to implement the ideas above is to add locations. Here we develop a general theory of locations and then show how to use it to interpret Ballerina's mutable structures and classic invariant reference types. We imagine a notion of location as a cell containing a value and which comes with two sets: a set 1 of values that can be read from it, and a set 2 of values that can be written to it. These two sets are used to drive the semantics of writes into the cell. We can for instance design the operational semantics such that if we try to write a value in it, it simply discards it if ∉ 1 ; if ∉ 2 , then either we can make the runtime raise an exception (as in Ballerina or the JVM) or design the type system so that it statically ensures that such a situation will never happen (as in languages with invariant reference types like Rust or CDuce).
e. , all elements of records, tuples, list,. are locations). The latter approach corresponds to considering the following model (without the co nite part): D = B+D×D+P n (D×D Ω )+(L (D×P n (D)×P n (D)) ⊥ ). In words, records map labels either to locations or to the unde ned value, and locations are used only for records. This is the approach followed by the language Ballerina with a small caveat that we are going to explain in the next subsection.
ACKNOWLEDGMENTS This research is issued from the author's collaboration with the  Ballerina and Elixir  development teams. I am particularly indebted to  José Valim  (designer, main developer, and omnipotent wizard of Elixir) and  James Clark  (who is supervising the design and implementation of the next generation Ballerina type system) for the long discussions and exchanges we had on record types. I am grateful to  Loïc Peyrot  who made an extensive reading of an earlier version of this work and spotted a couple of errors that are now xed. The presentation bene ted from important feedback provided by  Daniele Varacca ,  Guillaume Duboc , and  Mickaël Laurent. This work is dedicated, on the occasion of his retirement, to  Kim Bruce  whose paper on records, inheritance, and bounded quanti cation [ Bruce  and Longo 1988] was one of the rst scienti c papers I ever read.
a b s t r a c t To meet the growing demand of rich 3D content, the Computer Graphics industry needs tools to automatically create procedural textures and materials from image exemplars. In this paper, we focus on the inverse procedural modeling of cellular stochastic structures, i. e. , spatial distributions of repetitive, possibly blending similar shapes over a planar surface, resulting from stochastic processes. Such structures are very frequent in natural textures and materials, that exhibit random spatial variations. We represent cellular stochastic structures procedurally using thresholded Point Process Texture Basis Functions (PPTBFs). Previous approaches that learn PPTBF representations of structures maps solely rely on sampled data obtained by uniformly sampling the PPTBF parameter space, and parameter prediction based on these representations fails when the exemplars are visually too far from the training datasets.
In both cases, the methods depend on the sampling of the parameter space and may fail if the exemplar is visually too far from the training dataset. For the specific class of cellular stochastic structures we address here, we observed that the window and feature functions of the PPTBF can be defined with a reduced number of parameters, and in a differentiable way w. r. t. these parameters. Based on this observation, we propose a fully differentiable pipeline to achieve parameter prediction based on gradient descent, that involves a PPTBF defined with differentiable window and feature functions. We call our function C-PPTBF, for Cellular-PPTBF, as it covers a subset of the original PPTBF dedicated to cellular stochastic structures. Our contributions are as follows: • A C-PPTBF with differentiable window and feature functions w.
r. t. their parameters, covering cellular stochastic structures. • An appropriate loss function and optimization procedure for parameter estimation from structure map exemplars. • A complete code for the differentiable model and optimization procedure, as well as procedural representations of the structure maps extracted from natural textures made publicly available by Guehl et al. [1]. The code and procedural representations are available at:https://github. com/ASTex-ICube/DiffPPTBF. Our approach is automatic and efficient. We show that our method succeeds in producing results close to the input structure maps even when the latter incorporate details or spatial variations that are not represented by the C-PPTBF (Fig. 1 ). Between 2 and 5 min are required per exemplar. We present an evaluation of the DiffProxy model  [5]  that we trained to approximate our C-PPTBF.
Hu et al. [27]  extend the usage of the PPTBF model to represent compound and hierarchical stochastic structures. While the supported range of structures is extended, the parameter estimation procedure is gradient-free and remains close from the original method proposed in  [1] , with the same performance shortcomings. The authors report about 20 min to estimate the parameter values from an input exemplar. Hu et al. [5]  trained their neural generative model DiffProxy using 1M synthetic structure maps obtained by uniformly sampling the PPTBF parameters. The authors report computation times of 30 s to estimate the parameters from an exemplar. The method fails to provide good estimates for exemplars that are visually too far from the training dataset. The authors only present a few results obtained with DiffProxy trained on PPTBF images and do not provide any deep evaluation.
(7) The distance function d c : R 2 → R + involved in the partition of the plane in Voronoi cells, that we call Voronoi distance function, is chosen as an anisotropic distance, which significantly increases the variety of reachable cellular shapes as argued in  [1] , and is defined as: d c ( -→ x 1 x) = (1 -λ) ∥ -→ x 1 x∥ + λ d Til ( -→ x 1 x) (8) with d Til ( -→   Smooth cellular windows. The previous anisotropic distance function generates a great variety of polygonal cell shapes. But, based on their observation of a large database of cellular structures, obtained by segmentation of natural textures, Guehl et al. [1]  further argue that cellular structures with rounded shapes are also frequently encountered in nature. Smoothed cellular window shapes are obtained as described in  [1]  by splitting cellular windows in an equiangular way, and using Bézier interpolation.
We present reconstruction results from C-PPTBF images in Fig. 7 , showing the impact of the L bin term. Additional results are shown in Figs. 13, 14 and 15, in columns (a) to (c). Fig. 13  shows reconstruction results obtained with synthetic structure maps in input, whereas Figs. 14  and 15  show reconstruction results obtained with structure maps extracted from natural textures made available by Guehl et al. [1]. As shown by these results, our method has the ability to reconstruct plausible C-PPTBF images, despite the additional details or spatial variations that may appear in the input structure maps. In particular, the intensity variations computed over the cellular shapes are similar to the variations of the Gaussian kernel of the feature function. As one would expect, the quality of the reconstruction is dependent on the training dataset, and therefore depends on the sampling of the C-PPTBF parameters, and more particularly on the ranges of the values.
Optimization phase #1 Our goal in this stage is to get estimates of the tiling type and initial values for (θ T , β, θ W , θ F ) from U(I). We do not require highly accurate estimation of the continuous parameters, and we want to obtain these estimates with as little effort as possible. We have chosen to rely on a parameter-prediction ConvNet based on a ResNet-152V2 backbone  [31]  pretrained on ImageNet and finetuned with a dataset of C-PPTBF images. We add a global average pooling layer on top of the ResNet, followed by a Dropout layer, and by output layers. There is one output layer per parameter to estimate, in order to achieve classification for the tiling type (using Categorical Cross-Entropy loss), and regression to get values for the continuous parameters, that are normalized between 0 and 1 (using MSE loss).
Implementation. The preprocessing step has been implemented in OpenCL, keeping the original per-pixel implementation by Guehl et al. [1]  to generate the set of feature points. The k closest feature points are computed for each pixel of the output C-PPTBF image, and then gathered to get a single non-redundant point set. To account for the scaling and rotation adjustments that may arise during the optimization, the feature points are collected in an area that is 1. 25 time the area of the output C-PPTBF image. This is done only once for the whole optimization phase. We use the same ranges for the parameters as for the training datasets of the Pix2Pix and ResNet models (see E. 1). The optimization algorithm has been implemented with the machine learning and automatic differentiation framework JAX and optimized for GPU execution.
Our results show that even with relatively small training datasets, good estimates can be obtained with our approach. Since the output representation is procedural, it is worth mentioning that it can be adjusted or edited by hand afterwards if required. Our Optimization Phase #2 can be run with an initialization based on a random sampling of the continuous parameters, provided the tiling type, scaling factor and aspect ratio are given. Our implementation incorporates a parallel sampling scheme that is able to evaluate the loss function at 200 random locations in 68 s, which requires 1 GB of RAM on an NVidia Quadro RTX 6000 24 GB GDDR6. The results obtained with continuous parameters initialized this way are as good as the results obtained with the continuous parameters estimated via our Optimization Phase #1.
Comparison to Hu et al. [5] For the sake of evaluation and comparison, we trained the Diff-Proxy model introduced by Hu et al. [5]  on a dataset composed of 300k C-PPTBF images generated with parameters uniformly sampled (see Appendix E for the ranges). For fair comparison, we then performed parameter estimation using the SWD1D loss function and gradient descent using Adam. We perform a single gradient descent. The results are presented in Figs. 13 and 14-15, in column (g). Training. We did not train the DiffProxy model on binary thresholded images, as done by Hu et al. [5]. As it strongly impacts the visual appearance of the resulting structure images, the threshold In their paper, Hu et al. [5]  do not provide any information about the initialization of the parameters. Our experiments show that starting the gradient descent with random values yields unsatisfactory results, especially regarding the estimation of the tiling type.