<!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>Decomposition Without Regret (Poster)</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Weixin Zhang</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Cristina David</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Meng Wang</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>University of Bristol</institution>
          ,
          <country country="UK">United Kingdom</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Programming languages are embracing both functional and object-oriented paradigms. A key diference between the two paradigms is the way of achieving data abstraction. That is, how to organize data with associated operations. There are essential tradeofs between functional and object-oriented decomposition regarding extensibility and expressiveness. Unfortunately, programmers are usually forced to select a particular decomposition style in the early stage of programming. Once the wrong design decision has been made, the price for switching to the other decomposition style could be rather high since pervasive manual refactoring is often needed. In this talk, we show a bidirectional transformation system between functional and object-oriented decomposition. We formalize the core of the system in the FOOD calculus, which captures the essence of functional and object-oriented decomposition. We prove that the transformation preserves the type and semantics of the original program. We further implement FOOD in Scala as a translation tool called Cook and conduct several case studies to demonstrate the applicability and efectiveness of Cook.</p>
      </abstract>
      <kwd-group>
        <kwd>eol&gt;Bidirectional program transformation</kwd>
        <kwd>Functional decomposition</kwd>
        <kwd>Object-oriented decomposition</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>expressions. Besides extensibility, object-oriented and functional decomposition have diferent
expressive power. Object-oriented decomposition facilitates code reuse through inheritance
and enables interoperability between diferent implementations of the same interface whereas
functional decomposition allows inspection on the internal representation of data through
(nested) pattern matching, simplifying abstract syntax tree transformations.</p>
      <p>Unfortunately, programmers are forced to decide a decomposition style in the early stage of
programming. A proper choice, however, requires predictions on the extensibility dimension
and kinds of operations to model, which may not be feasible in practice. Once the wrong design
decision was made, the price for switching to the other decomposition style could be rather
high since pervasive manual refactoring is often needed.</p>
      <p>A better way, however, allows programmers to choose a decomposition style for prototyping
without regret. When the design choice becomes inappropriate, a tool automatically transforms
their code into another style without afecting the semantics. Even at later stages, such a
automatic translation tool could be used to make extensions of data variants or operations easier
by momentarily switching the decomposition, adding the extension, and then transforming
the program back to the original decomposition. Furthermore, studying the transformation
between the two styles can provide a theoretical foundation for compiling multi-paradigm
languages into single-paradigm ones. From an educational perspective, the tool can help novice
programmers to understand both decomposition styles better.</p>
      <p>
        To address this issue, we propose a bidirectional transformation between functional and
object-oriented decomposition based on the observation that restricted forms of functional
and object-oriented decomposition are symmetric. We formalize an automatic, type-directed
transformation in the core calculus FOOD, which captures the essence of Functional and
ObjectOriented Decomposition. We prove that the transformation preserves the type and semantics of
the original program. We further implement FOOD in Scala as a translation tool called Cook
and conduct several case studies to demonstrate the applicability of Cook. Interested readers
may want to consult the full paper for more details [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ].
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>J. C.</given-names>
            <surname>Reynolds</surname>
          </string-name>
          ,
          <article-title>User defined types and procedural data structures as complementary approaches to data abstraction</article-title>
          , in: D.
          <string-name>
            <surname>Gries</surname>
          </string-name>
          (Ed.),
          <source>Programming Methodology, A Collection of Articles by IFIP WG2.3</source>
          , Springer-Verlag, New York,
          <year>1978</year>
          , pp.
          <fpage>309</fpage>
          -
          <lpage>317</lpage>
          .
          <article-title>Reprinted from S. A</article-title>
          . Schuman (ed.),
          <source>New Advances in Algorithmic Languages</source>
          <year>1975</year>
          , Inst. de Recherche d'Informatique et d'Automatique, Rocquencourt,
          <year>1975</year>
          , pages
          <fpage>157</fpage>
          -
          <lpage>168</lpage>
          . Also in taoop.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>W. R.</given-names>
            <surname>Cook</surname>
          </string-name>
          ,
          <article-title>On Understanding Data Abstraction, Revisited</article-title>
          , in
          <source>: Proceedings of the 24th ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications</source>
          , OOPSLA '
          <volume>09</volume>
          ,
          <year>2009</year>
          , pp.
          <fpage>557</fpage>
          -
          <lpage>572</lpage>
          . doi:
          <volume>10</volume>
          .1145/1639949.1640133.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>W. R.</given-names>
            <surname>Cook</surname>
          </string-name>
          ,
          <article-title>Object-oriented programming versus abstract data types</article-title>
          ,
          <source>in: Foundations of Object-Oriented Languages</source>
          , Springer,
          <year>1991</year>
          , pp.
          <fpage>151</fpage>
          -
          <lpage>178</lpage>
          . doi:
          <volume>10</volume>
          .1007/BFb0019443.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>P.</given-names>
            <surname>Wadler</surname>
          </string-name>
          ,
          <source>The Expression Problem</source>
          ,
          <year>1998</year>
          . Note to Java Genericity mailing list.
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>W.</given-names>
            <surname>Zhang</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>David</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Wang</surname>
          </string-name>
          , Decomposition without regret,
          <year>2022</year>
          . URL: https://arxiv.org/ abs/2204.10411. doi:
          <volume>10</volume>
          .48550/ARXIV.2204.10411.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>