<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Gradual typing using union typing with records</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Karla Ram rez Pulido</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Jorge Luis Ortega Arjona</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Lourdes del Carmen Gonzalez Huesca</string-name>
          <email>luglzhuescag@ciencias.unam.mx</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Departamento de Matematicas, Facultad de Ciencias, Universidad Nacional Autonoma de Mexico</institution>
        </aff>
      </contrib-group>
      <fpage>24</fpage>
      <lpage>36</lpage>
      <abstract>
        <p>Dynamic typed languages are characterized by their expressiveness and exibility to develop prototypes, while static typed languages allow early detection of errors and the optimization of source code. Gradual typing languages allow programmers to make use of both approaches, static and dynamic typing, and thus, obtaining the advantages that both represent. The objective here is to revisit the static part of the approach to a gradual interpretation of union types based on the design of Gradual Union Types through an extension with the record data-structure. This contributes to understand the abstraction and reasoning behind Gradual Typing in order to have useful future extensions for other data-structures.</p>
      </abstract>
      <kwd-group>
        <kwd>Gradual typing</kwd>
        <kwd>Union types</kwd>
        <kwd>Records</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Introduction
Commonly, programming languages can be broadly categorized according to
their typing as static or dynamic. Nevertheless, there are other typing
classi</p>
      <p>
        cations that allow to mix typing features between both static and dynamic
extremes, such as hybrid typing and gradual typing [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. In particular, gradual
typing languages allow programmers to make use of static and dynamic typing,
and thus, obtaining the advantages that both represent.
      </p>
      <p>Gradual typing makes use of typed and untyped code in the same language.</p>
      <p>
        The idea has been proposed by Siek and Taha in 2006 [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ], who expose the
idea that mixing dynamic and static features in a single language may improve
the intrinsic typing characteristics of such a programming language. Having
explicit types can guarantee certain properties about the program, related with its
soundness and security, and thus, certain kind of optimizations can be performed
during of executable code, since some typing information is already known.
Moreover, not having explicit types allows programmers to have a better
expressiveness, and generate prototypes of programs faster to test and execute.
      </p>
      <p>
        Since Siek and Taha introduced the term Gradual Typing [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ], several other
studies have been performed which encompass Gradual Typing with type
security [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], type states [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], Object-Orientation [
        <xref ref-type="bibr" rid="ref14 ref18">14,18</xref>
        ], and so on. AlthCooupygrhightht©e 2019 for this paper by its authors.
interest for Gradual Typed languages has been increased over the last Afetwtribution 4.0 International (CC BY 4.0)
years,
there are still questions about how more sophisticated language features can be
included into them [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
      </p>
      <p>
        In their original work, Siek and Taha [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] start from a language which is
statically typed to obtain a gradual system by adding the character ? to express
an unknown type. Having this type enforces the static properties of the system as
gradual types represent static information, in this way gradual typing supports
static and dynamic checking of program properties [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. Programmers can
explicitly write static types, as well as leave some parts of the code without typing. A
type that has not been de ned as \static" by the programmer should be veri ed
at run-time, and gradual type systems should be developed in order to preserve
type consistency.
      </p>
      <p>
        The relation of consistency has a signi cant importance in this approach,
because it must be guaranteed that programs do not fail, that is, if they reach
an unsoundness state. The relation of consistency has to be maintained, even
when the unknown type ? of Gradual Typing is present [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. A consistency relation
is given to extend conservatively the type equality: T T 0 expresses that during
run-time, T is structurally equal to T 0 with the exception of some features but
mainly to do not allow any type inconsistency.
      </p>
      <p>
        Robustness of usual extensions of functional languages are based on the
preservation of fundamental properties such as security. A meta-theory, as
presented by Toro and Tanter allows to extend a language into a gradual one in
a safe manner: the gradual union of types and the unknown type ? are
combined through the Abstract Gradual Typing (AGT) methodology. The AGT is
based on abstract interpretation due to [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], for a sound abstraction using Galois
connections. Abstract Interpretation describe the computations made in a given
system but in a di erent universe. For example, the elements in a program and
their operations can be modeled in another language, preserving their semantics.
      </p>
      <p>
        We present an extension of a functional language with records. Such an
structure allows the programmer to manipulate expressions that could have di erent
types. The gradual extension is cartied out with gradual union types, which
are intended to preserve the safety property. In this paper the extension of the
type system is provided in order to understand the abstraction behind the AGT
methodology, as proposed by [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ].
2
      </p>
      <p>
        Gradual Union Typing
Some proposals have been made to address the inexactness introduced by the
unknown type ? of Gradual Typing languages. Two are mainly used [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]:
1. The use of disjoint (or tagged) types, such as the sum of the types T1 + T2
      </p>
      <p>explicitly tagged; and
2. Untagged union types, denoted by T1 _ T2, which denotes the union of values
of type T1 and of type T2.</p>
      <p>Toro and Tanter combine these two proposals into a Gradual Union
Typing (GUT) approach, in which it is possible to have the two di erent types of
union: disjoint (also known as tagged) union types, and untagged union types.</p>
      <p>
        Mixing tagged and untagged unions in a language is named as optimistic type
checking [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] to ensure that statically any term will have a type. In particular,
optimistic type checking means that some statement is well typed without the
occurrence of any explicit projection or case analysis.
      </p>
      <p>An Abstract Gradual Interpretation of union types is presented in order to
understand both proposals for the union of types. Thus, it is possible to mix
both: disjoint (also known as tagged) union types (T1 + T2) and their variant
types, as well as untagged union types (T1 _ T2):
{ Disjoint union types or tagged unions (T1 + T2) denote values of di erent
types. It is called disjoint because some elements are explicitly tagged, so the
type system recognizes the type of each element. Hence, it guarantees and
ensures the type of each element during compilation and execution time.
{ Untagged unions (T1 _ T2) denote the unions of values of types T1 and T2
without any tagging mechanism. For example, a value v of type T1 is included
as a value of type T1 _ T2, that is, the type of value v appears in the union
of both sets of types T1 and T2, i.e. the highest lower bound between T1 and
T2. Untagged unions can be used in the branches of conditionals inside of an
if expression, where then and else branches can return a di erent type of
values. Thus, untagged unions can be safely compiled, but can lead to errors
during execution time.
2.1</p>
    </sec>
    <sec id="sec-2">
      <title>A Gradual Interpretation of Union Types</title>
      <p>
        Toro and Tanter, based on the AGT methodology, propose static semantics for
a Gradual Typed Functional Language, which make use of gradual unions and
unknown typing. The notion of gradual union types is to restrict the imprecise
types to denote a nite number of static types [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. Such a semantic is based on
the Simply-Typed Functional Language (STFL), which is statically typed.
      </p>
      <p>
        Types of a Gradual Type Functional Language (GTFL ) as de ned by Toro
and Tanter [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] extends the STFL syntax by adding the symbol ?, introduced as
the unknown type. This type is present in the Gradual Type Functional System
(GTFL) [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], which preserves the STFL structure, but static types, predicates,
and partial functions are lifted to gradual types. This transformation between
sets of static types and gradual types is based on a Galois connection as the
AGT approach states.
      </p>
      <p>
        In this paper, the extension with records is carried out using this
methodology [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. The rst transformation uses an abstraction function ? to convert
STFL into an GTFL, and a concretization function ? from GTFL to STFL to
complete the Galois connection. Second step is to obtain a GTFL from GTFL
by adding the gradual union denoted by: T1 T2 and using and functions
between these two languages for the Galois connection.
      </p>
      <p>
        For the purposes of this paper, the left side of Figure 1 shows the lifting of
the types on STFL, which is expressed by the in nite power set }(T Y P E), to
the syntactic category GTYPE using functions ? and ?. From these sets, it is
necessary to lift the set of types into a nite one, this implies the use of the power
set operator }. Then, functions ? and ? are de ned between }fin(}(T Y P E))
õ ô
and }fin(GT Y P E) [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ].
      </p>
      <p>
        Gradual Union Types with Records
This paper extends the GUT by Toro and Tanter with records. A record is a
datatype that describes variables (called elds) and their values. Fields possibly have
di erent types. Some programming languages use records to de ne new types,
and therefore, are able to extend the language [
        <xref ref-type="bibr" rid="ref12 ref6">6,12</xref>
        ]. A record is composed by
one or more labels, here denoted as `. Each label has an assigned term, which
also has a type. Adding records allows to extend a language maintaining complex
information in the same structure, and having the possibility to access it through
an identi er of each one of its elds. The extension here presented is based on
the system of Toro and Tanter [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] and is given in Figure 2. The system adds
records as primitive types (shown in boldface) where the labels `i belong to a
predetermined set LABEL.
      </p>
      <p>
        From Figure 2, a record type is denoted by [`i : Ti i21;:::;n], where `i denote
a label. A record term is expressed as [`i = ti i21;:::;n], where `i denotes a eld
for term ti and a record value is de ned as [`i = vi i21;:::;n] where each vi is a
value. Each record has a xed size n. The typing rules for records are Trec and
Tproj , following the typing rules given in [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]:
Trec: in order to assign a type to a record term, if each term ti has type Ti under ,
then term [`i = ti i21::n] has type [`i : Ti i21::n], in the same context .
      </p>
      <p>T ::= Int j Bool j T ! T j [`i : Ti i21::n]
v ::= n j b j x : T:t j [`i = vi i21::n]
2 V AR *n T Y P E; ` 2 LABEL</p>
      <p>(type)
(values)
t ::= v j x j t t j t + t jif t then t else t j t :: T j [`i = ti i21::n] j t:`j
(terms)
x : T 2
` x : T
(Tx)</p>
      <p>` n : Int
` t2 : T2
` t1 : T1 T2 = dom(T1)</p>
      <p>` t1 t2 : cod(T1)
` t1 : T1 T1 = Int ` t2 : T2 T2 = Int</p>
      <p>` t1 + t2 : Int
` t1 : T1 T1 = Bool ` t2 : T2 ` t3 : T3</p>
      <p>` if t1 then t2 else t3 : equate(T2; T3)
; x : T1 ` t : T2</p>
      <p>(T )
` ( x : T1:t) : T1 ! T2
` t : T T = T1
` (t :: T1) : T1</p>
      <p>(Tapp)
(Tn)
` b : Bool
(T+)
(Tif )
(Tb)
(T::)
` ti : Ti i21::n</p>
      <p>f or each i
` [`i = ti i21::n] : [`i : Ti i21::n]</p>
      <p>` t : [`i : Ti i21::n]
` t:`j : Tj f or some j 2 1::n
(Trec)
(Tproj )
dom:T Y P E*T Y P E cod:T Y P E*T Y P E equate:T Y P E T Y P E*T Y P E
dom(T ) undefined in other case cod(T ) undefined in other case equate(T1;T2) undefined in other case
` [`i = ti i21::n] : [`i : Ti i21::n] then
` t:`j : Tj f or some j 2 1::n then</p>
      <p>` ti : Ti f or each i 2 1::n.</p>
      <p>` t : [`i : Ti i21::n].
3.1</p>
    </sec>
    <sec id="sec-3">
      <title>A Gradual Typing Language</title>
      <p>
        The following step is to add records for a Gradual Typing Language (GTFL).
This means adding the unknown type ? to the STFL. In the following, we present
the extension with records based on the work of [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], the new cases are in
boldface:
      </p>
      <p>G 2 GT Y P E</p>
      <p>G ::= Int j Bool j G ! G j ? j [`i : Gi i21::n]
The concretization function is de ned as follows:
?(Int) = fIntg
?(Bool) = fBoolg
?(?) = T Y P E
?(G1 ! G2) = fT1 ! T2 j T1 2 ?(G1) ^ T2 2 ?(G2)g
?([`i : Gii21::n]) = f[`i : Tii21::n] j Ti 2 ?(Gi) i21::n]g</p>
      <p>
        Notice that the above function helps to preserve (i.e. to know) the static
information of gradual types [
        <xref ref-type="bibr" rid="ref19 ref7">19,7</xref>
        ]. The case for ?(?) = T Y P E states that the
unknown type could be any of the types in the category T Y P E de ned in STFL.
      </p>
      <p>
        The abstraction function, following [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], is de ned using Tó which denotes a
set of types induced by T :
      </p>
      <p>Tü1! T2 = fT 0 ! T 00 j T 0 2 Tõ1 ^ T 00 2 Tõ2g
[`i ÿTii21::n] : = f[`i : Ti;j i21::n] j Ti;j 2 Gõi ^ i 2 1::n ^ j 2 1::jGõijg
?(fT g) = T
?(Tü1! T2) = ?(Tõ1) ! ?(Tõ2)
?(;) = undef ined
?([`i ÿTii21::n]) : = [`i : ?(Tõi) i21::n]
?(Tó) = ? otherwise</p>
      <p>
        Th abstraction function ? helps the language to obtain or retain more
precision, while the unknown type is decreased, that is, the ? function can produce
a gradual type that abstracts a given set [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Toro and Tanter de ne optimal as
the best approximation of ?, that means the most precise gradual type that is
possible. Both functions ? and ? de ne the Galois connection [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ].
De nition 1 (GT Y P E Precision). G1 is less imprecise than G2, G1 v G2,
if and only if ?(G1) ?(G2).
      </p>
      <p>The next proposition de nes when ? is sound and optimal.</p>
      <sec id="sec-3-1">
        <title>Proposition 1 ( ? is sound and optimal). If Tó is non empty, then:</title>
        <p>1: Tó
?( ?(Tó))
2: Tó
?(G) =)
?(Tó) v G
Proof. Proof by induction on the structure of G, we show the case for records.</p>
      </sec>
      <sec id="sec-3-2">
        <title>Case 1 for records ([`i þTii21::n]) :</title>
        <p>If Tó = [`i ÿTii21::n] : = f[`i : Ti;j i21::n] j Ti;j 2 Tôi ^ i 2 1::n ^ j 2 1::jTôijg then
by de nition of ?: ?([`i ÿTii21::n]) : = [`i : ?(Tôi) i21::n]
and by de nition of ? for records we have
?([`i : Gi i21::n]) = f[`i : Ti i21::n] j Ti 2
?( ?(Tó)) = ?([`i : ?(Tôi) i21::n]) =
?(Gi) i21::ng = f[`i : Ti i21::n] j Ti 2
?( ?(Tôi)) i21::ng. By induction hypothesis Ti;j 2 Tôi
then the result holds.</p>
      </sec>
      <sec id="sec-3-3">
        <title>Case 2 for records ([`i þTii21::n]) :</title>
        <p>Let Tó = [`i ÿTii21::n], : and suppose Tó = [`i ÿTii21::n] :
and by de nition of ?: f[`i : Ti i21::n] j Ti 2 ?(Gi) i21::ng
?( ?(Tôi)) for each Ti;j
?([`i : Gi i21::n])
By de nition of ? for records: ?([`i ÿTii21::n]) : = [`i : ?(Tôi) i21::n]
By the induction hypothesis, for each Tôi if Tôi ?(Gi) then
?(Tôi) v Gi.</p>
        <p>Therefore, by de nition 1 ?( ?([`i ÿTii21::n])) : = ?([`i : ?(Tôi) i21::n])
?([`i : Gi i21::n]) and the result holds.</p>
        <p>
          The next step to give a Gradual Union Typing is to lift functions ? and ?
to sets, that is from }fin(}(T Y P E)) to }fin(GT Y P E) and vice-versa. Observe
that this lifting is over nite sets of types. We follow again Toro and Tanter [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ].
        </p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>De nition 2 (}fin(GT Y P E) Concretization).</title>
      <p>? : }fin(GT Y P E) ! }fin(}(T Y P E)) is de ned as: ô?(Gô) = f ?(G) j G 2 Gôg
ô</p>
    </sec>
    <sec id="sec-5">
      <title>De nition 3 (}fin(GT Y P E) Abstraction).</title>
      <p>? : }fin(}(T Y P E)) * }fin(GT Y P E) is de ned as:
õ
õ?(;) = undef ined
õ?(Tôô) = [</p>
      <p>
        ?(Tó)
Tó2Tóó
Proposition 2 ( ? is sound and optimal). If Tôô is non empty, then:
õ
1: Tôô
ô?(õ?(Tôô))
2: Tôô
ô?(Gô) =)
õ?(Tôô) v Gô
Proof. The proof is the same as in [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] as we are working with sets. An important
observation is that Tôô is indeed a Gô.
3.2
      </p>
    </sec>
    <sec id="sec-6">
      <title>A Gradual Union Typing Language</title>
      <p>
        In order to construct a Gradual Union Typing, it is proposed in [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] a ST Y P E
grammar for the static types. This grammar is made up only of gradual unions
(without the unknown type ?).
      </p>
      <p>S 2 ST Y P E</p>
      <p>S ::= Int j Bool j S ! S j S</p>
      <p>S j [`i : Si i21::n]</p>
      <p>
        The static types are integers (Int), booleans (Bool), functions (S ! S), the
gradual unions denoted by S S and the record type. Recall that gradual unions
represent a nite set of types [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], where the concretization and abstraction
functions are de ned between static types and nite sets of types generating a
Galois connection.
      </p>
      <p>For a gradual interpretation of union types with records, the next step is
to design gradual union types, using the AGT to construct the semantics for
gradual types in terms of pre-existing sets of static types.</p>
      <p>The new type system is composed of Gradual Unions , named GTFL ,
combining both ST Y P E and U T Y P E. The last syntactic category, U T Y P E,
is the extension including the unknown type, the gradual unions and records:
U 2 U T Y P E</p>
      <p>U ::= Int j Bool j U ! U j U</p>
      <p>U j ? j [`i : Ui i21::n]</p>
      <p>
        We de ne a Galois connection between U T Y P E and }fin(GT Y P E) as the
next concretization function in U T Y P E [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. The extension with records is again
expressed in boldface:
De nition 4 (U T Y P E concretization).
      </p>
      <p>: U T Y P E ! }fin(GT Y P E)
(Int) = fIntg
(Bool) = fBoolg
(?) = f?g
(U1 ! U2) = fG1 ! G2 j G1 2
(U1) ^ G2 2</p>
      <p>(U2)g
(U1</p>
      <p>U2) =
(U1) [
(U2)
([`i : Ui i21::n]) = f[`i : Gi i21::n] j Gi 2
(Ui) i21::ng</p>
      <p>
        The de nition of abstraction function (U T Y P E abstraction) is the same
de ned by Toro and Tanter [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] and produces nite sets, that is the gradual
union of all elements in Gô:
De nition 5 (U T Y P E abstraction).
      </p>
      <p>: }fin(GT Y P E) * U T Y P E
(Gô) = L G</p>
      <p>ô
= (G1)
(G2) : : :
(Gm)
if G 6= ;
where Gi 2 Gô
and jGönj = m.</p>
      <p>To prove that Gô</p>
      <p>The next proposition states that is sound and optimal for U T Y P E. The
notion of precision for U T Y P E is the same as the one given above, that is
U1 v U2 if and only if (U1) (U2)
Proposition 3. (</p>
      <p>is sound and optimal). If Gô is non empty, then:
1: Gô
(
(Gô))
2: Gô
Proof. The proof is carried out by induction on the structure of U .</p>
    </sec>
    <sec id="sec-7">
      <title>Case 1 for records.</title>
      <p>Suppose G = [`i : Gi i21::n] then Gô = f[`i : Ti;j i21::n] j Ti;j 2 Gõi ^ i 2 1::n ^ j 2
1)
1::jGõijg. Without loss of generality, take j = 1 for each Gõi with i 2 1::(n
(f[`i : Ti; `n : T 0] j T 0 2 Gön ^ i 2 1::n
(
(Gô)) we proceed by applying the de nition of
1g) =</p>
      <p>(Gô):
L f[`i : Ti; `n : T 0] j T 0 2 Gön ^ i 2 1::n 1g =
[`i : (Ti); `n : (Gn1)] : : : [`i : (Ti); `n : (Gnm)]
Using de nition of :
([`i : (Ti); `n : (Gn1)] [`i : (Ti); `n : (Gnm)]) =
([`i : (Ti); `n : (Gn1)]) [ [ ([`i : (Ti); `n : (Gnm)]) =
f[`i : ( (Ti)); `n : ( (Gn1))]g[ [f[`i : ( (Ti)); `n : (
f[`i : ( (Ti)); `n : Gnj] j Gnj 2 ( (Gön)) ^ j 2 1::mg:
By induction hypothesis, Ti 2 Gõi and also belongs to ( (Gõi)) for each
i 2 1::n 1 and Gnj 2 Gön belongs also to ( (Gön)) and therefore
Gô ( (Gô)).</p>
    </sec>
    <sec id="sec-8">
      <title>Case 2 for records.</title>
      <p>Suppose that Gô (U ) where Gô = [`i ÿGii21::n] : and</p>
      <p>(U ) = ([`i : Ui i21::n]) = f[`i : Gi i21::n] j Gi 2 (Ui) i21::ng
To prove
(Gô) v U we proceed by de nition of
(Gô):
([`i ÿGii21::n]) : = Lf[`i : Ti;j i21::n] j Ti;j 2 Gõi ^ i 2 1::n ^ j 2 1::jGõijg
Without loss of generality, take j = 1 for each Gõi with i 2 1::(n 1) and
jGönj = m, then by de nition of</p>
      <p>(f[`i : Ti; `n : T 0] j T 0 2 (Gön) ^ i 2 1::n 1g) =
S (f[`i : Ti; `n : T 0] j T 0 2 (Gön) ^ i 2 1::n 1g) =
Sf[`i : Ti; `n : T 0] j T 0 2 ( (Gön)) ^ i 2 1::n 1g
The induction hypothesis states that Gõi (Ui) =) (Gõi) v Ui for each i
which by de nition of precision gives ( (Gõi)) (Ui), in particular for Gn.
Therefore Sf[`i : Ti; `n : T 0] j T 0 2 (Ui) ^ i 2 1::n 1g which is indeed
f[`i : Gi i21::n] j Gi 2 (Ui) i21::ng.</p>
      <p>
        Therefore, following Toro and Tanter [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], the strati ed interpretation of
U T Y P E is de ned in terms of sets of sets of static types with the composition
of two presented Galois conections:
      </p>
    </sec>
    <sec id="sec-9">
      <title>De nition 6 (U T Y P E concretization).</title>
      <p>: U T Y P E ! }fin(}(T Y P E))
= ?
ô
(Gnm))]g =</p>
    </sec>
    <sec id="sec-10">
      <title>De nition 7 (GT Y P E abstraction).</title>
      <p>: }fin(}(T Y P E)) * U T Y P E
?
õ
The next proposition is needed to prove that is sound and optimal:
=
Proposition 4. ( is sound and optimal). If Tôô is non empty, then:
Proof. This proposition holds by Propositions 1, 3, and composition of sound
and optimal abstractions.
U 2 U T Y P E; x 2 V AR; et2 U T ERM;</p>
      <p>U ::= U U j Bool j Int j U ! U j ? j [`i : Uii21::n] (types)</p>
      <p>v ::= n j true j f alse j ( x : U:et) j [`i = vii21::n] (values)
et::= v j x j etetj et+ etj if etthen etelse etj et:: U j [`i = tei j21::n] j te:`j (terms)
x :`Ux2: U (Ux) ` n : Int (Un) (Ub)
; x : U1 ` et: U2 (U ) (U::)
` ( x : U1:et) : U1 ! U2</p>
      <p>` te1 : U1
` te1 : U1 U1</p>
      <p>` te2 : U2 U2
` te1 te2 : cÝod(U1)</p>
      <p>Int
` te2 : U2 U2</p>
      <p>Int
` te1 + te2 : Int
` te1 : U1 U1 Bool ` te2 : U2 ` te3 : U3
` if te1 then te2 else te3 : U2 u U3</p>
      <p>` tei : Ui i21::nf or each i
` [`i = tei i21::n] : [`i : Ui i21::n]</p>
      <p>` te : [`i : Ui i21::n]
` te:`j : Uj f or some j 2 1::n</p>
      <p>(Urec)
(Uproj)</p>
      <p>` b : Bool
` et: U U U1
` (et:: U1) : U1
dÞom(U1)
(Uapp)
(U+)
(Uif )
dÝom:UT Y P E*UT Y P E cod:UT Y P E*UT Y P E</p>
      <p>f
dÝom(U)= (dom( (U)) cfod(U)= (cod( (U))</p>
      <p>Ó c
De nition 8 (Gradual Meet). Let u : U T Y P E * U T Y P E be de ned as:</p>
      <p>8 U u U1 if U u U2 is undef ined
3. U u (U1 U2) = (U1 U2) u U = &lt; U u U2 if U u U1 is undef ined
: (U u U1) (U u U2) otherwise
4. (U11 ! U12) u (U21 ! U22) = (U11 u U21) ! (U12 u U22)
5. [`1 : U11; :::; `n : U1n] u [`1 : U21; :::; `n : U2n] = [`1 : (U11 u U21); :::; `n : (U1n u U2n)]
6. U1 u U2 is unde ned otherwise.</p>
      <p>The following de nition states the translation of the equate from STFL to a
function in GTFL , in order to preserve typing:</p>
    </sec>
    <sec id="sec-11">
      <title>De nition 9 (Equate Lifting).</title>
      <p>eàquate(U1; U2) = U1 u U2 =</p>
      <p>(fTõ1 \ Tõ2 j Tõ1 2 (U1); Tõ2 2 (U2)g) =
(feáquate?(G1; G2) j G1 2
(U1); G2 2
(U2)g)</p>
      <p>And the next proposition is needed to prove the gradual meet for GT F L
Proposition 6. u =</p>
      <p>
        eúúquate
Proof. Proof is made using structural induction and the de nition of meet as
intersection of sets of sets [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. The case for records is straightforward as the
meet is pointwise.
4
      </p>
      <p>
        Conclusion and Future Work
Gradual Union Typing was initially proposed by Toro and Tanter [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], showing
properties such as safety and consistency using AGT and Galois connections.
Nevertheless, there has been investigated a lot of settings related to gradual
typing in order to promote the development of more expressive programming
languages. For instance, subtyping by Garc a, Siek and Taha [
        <xref ref-type="bibr" rid="ref14 ref7">14,7</xref>
        ], Gradual
Typing systems and cast insertion procedures by Cimini and Siek [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], the
interaction between union types and Gradual Typing [
        <xref ref-type="bibr" rid="ref1 ref16">16,1</xref>
        ], typestates [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], re nement
types [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], information- ow security typing [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], set-theoretic types and subtyping
[
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], re nement sums for exhaustive and non-exhaustive matches [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], and studies
focused on performance at run-time and space management [
        <xref ref-type="bibr" rid="ref13 ref9">13,9</xref>
        ].
      </p>
      <p>
        The type setting here provides a static extension using records for the study of
Gradual Union Typing, as presented by Toro and Tanter in [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. This approach
contributes to the study of the theoretical perspective for the foundations of
programming languages. Adding records to a functional language allows to create
new variants of types, using them as basic types prede ned in the language, for
a richer and more versatile language. Extending the methodology for languages
with gradual typing helps to combine the advantages of using both static and
dynamic typing, while preserving the properties of consistency and security in it.
      </p>
      <p>
        A related work from Garcia, Clark and Tanter [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] proposes an extension
of a type system with records using subtyping, and formalizing a relation of
consistency on gradual typing language, by following the methodology proposed
by Siek and Taha [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. Our approach here di ers from theirs as we rely on gradual
union types. Here it is already provided a static formal system. Further, the
dynamic formal part, demonstrating its static and dynamic semantics properties,
is aimed as future work. The main goal is to obtain a gradual system with records
using the so-called Threesome Calculus [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ] for the dynamic semantics.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Castagna</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lanvin</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Gradual typing with union and intersection types</article-title>
          .
          <source>Proceedings of the ACM on Programming Languages 1(ICFP)</source>
          ,
          <volume>41</volume>
          (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Castagna</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Petrucciani</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          , Nguy~en, K.:
          <article-title>Set-theoretic types for polymorphic variants</article-title>
          .
          <source>In: Proceedings of the 21st ACM SIGPLAN International Conference on Functional Programming</source>
          . pp.
          <volume>378</volume>
          {
          <fpage>391</fpage>
          .
          <source>ICFP</source>
          <year>2016</year>
          , ACM, New York, NY, USA (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Cimini</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Siek</surname>
            ,
            <given-names>J.G.</given-names>
          </string-name>
          :
          <article-title>The gradualizer: a methodology and algorithm for generating gradual type systems</article-title>
          .
          <source>ACM SIGPLAN Notices</source>
          <volume>51</volume>
          (
          <issue>1</issue>
          ),
          <volume>443</volume>
          {
          <fpage>455</fpage>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Cousot</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cousot</surname>
          </string-name>
          , R.:
          <article-title>Formal language, grammar and set-constraint-based program analysis by abstract interpretation</article-title>
          .
          <source>In: FPCA</source>
          . vol.
          <volume>95</volume>
          , pp.
          <volume>170</volume>
          {
          <issue>181</issue>
          (
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Disney</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Flanagan</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Gradual information ow typing</article-title>
          . In: International workshop on scripts to programs (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Friedman</surname>
            ,
            <given-names>D.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wand</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Haynes</surname>
          </string-name>
          , C.T.:
          <article-title>Essentials of programming languages</article-title>
          . MIT press (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Garcia</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Clark</surname>
            ,
            <given-names>A.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tanter</surname>
          </string-name>
          , E.:
          <article-title>Abstracting gradual typing</article-title>
          .
          <source>In: Proceedings of the 43rd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages</source>
          . pp.
          <volume>429</volume>
          {
          <fpage>442</fpage>
          . POPL '16,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          , New York, NY, USA (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Garcia</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tanter</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wol</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aldrich</surname>
          </string-name>
          , J.:
          <article-title>Foundations of typestate-oriented programming</article-title>
          .
          <source>ACM Transactions on Programming Languages and Systems (TOPLAS) 36(4)</source>
          ,
          <volume>12</volume>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Herman</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tomb</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Flanagan</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Space-e cient gradual typing</article-title>
          .
          <source>Higher-Order and Symbolic Computation</source>
          <volume>23</volume>
          (
          <issue>2</issue>
          ),
          <volume>167</volume>
          (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Jafery</surname>
            ,
            <given-names>K.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dun</surname>
            <given-names>eld</given-names>
          </string-name>
          , J.:
          <article-title>Sums of uncertainty: Re nements go gradual</article-title>
          .
          <source>ACM SIGPLAN Notices</source>
          <volume>52</volume>
          (
          <issue>1</issue>
          ),
          <volume>804</volume>
          {
          <fpage>817</fpage>
          (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Lehmann</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tanter</surname>
          </string-name>
          , E.:
          <article-title>Gradual re nement types</article-title>
          .
          <source>In: Proceedings of the 44th ACM SIGPLAN Symposium on Principles of Programming Languages</source>
          . pp.
          <volume>775</volume>
          {
          <fpage>788</fpage>
          .
          <source>POPL</source>
          <year>2017</year>
          , ACM, New York, NY, USA (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Pierce</surname>
            ,
            <given-names>B.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Benjamin</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Types and programming languages</article-title>
          . MIT press (
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Rastogi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Swamy</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fournet</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bierman</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vekris</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          : Safe &amp;#
          <volume>38</volume>
          ; e
          <article-title>- cient gradual typing for typescript</article-title>
          .
          <source>In: Proceedings of the 42Nd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages</source>
          . pp.
          <volume>167</volume>
          {
          <fpage>180</fpage>
          . POPL '15,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          , New York, NY, USA (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Siek</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Taha</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Gradual typing for objects</article-title>
          .
          <source>In: European Conference on ObjectOriented Programming</source>
          . pp.
          <volume>2</volume>
          {
          <fpage>27</fpage>
          . Springer (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Siek</surname>
            ,
            <given-names>J.G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Taha</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Gradual typing for functional languages</article-title>
          .
          <source>In: Scheme and Functional Programming Workshop</source>
          . vol.
          <volume>6</volume>
          , pp.
          <volume>81</volume>
          {
          <issue>92</issue>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Siek</surname>
            ,
            <given-names>J.G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tobin-Hochstadt</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>The recursive union of some gradual types</article-title>
          .
          <source>In: A List of Successes That Can Change the World</source>
          , pp.
          <volume>388</volume>
          {
          <fpage>410</fpage>
          . Springer (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Siek</surname>
            ,
            <given-names>J.G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wadler</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Threesomes, with and without blame</article-title>
          .
          <source>In: Proceedings of the 37th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages</source>
          . pp.
          <volume>365</volume>
          {
          <fpage>376</fpage>
          . POPL '10,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          , New York, NY, USA (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Takikawa</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Strickland</surname>
            ,
            <given-names>T.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dimoulas</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tobin-Hochstadt</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Felleisen</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Gradual typing for rst-class classes</article-title>
          .
          <source>In: Proceedings of the ACM International Conference on Object Oriented Programming Systems Languages and Applications</source>
          . pp.
          <volume>793</volume>
          {
          <fpage>810</fpage>
          . OOPSLA '12,
          <string-name>
            <surname>ACM</surname>
          </string-name>
          , New York, NY, USA (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Toro</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tanter</surname>
          </string-name>
          , E.:
          <article-title>A gradual interpretation of union types</article-title>
          .
          <source>In: International Static Analysis Symposium</source>
          . pp.
          <volume>382</volume>
          {
          <fpage>404</fpage>
          . Springer (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>