<?xml version='1.0' encoding='UTF-8'?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2026-05-21T19:39:41Z</responseDate>
  <request verb="GetRecord" metadataPrefix="jpcoar_1.0" identifier="oai:ipsj.ixsq.nii.ac.jp:00194237">https://ipsj.ixsq.nii.ac.jp/oai</request>
  <GetRecord>
    <record>
      <header>
        <identifier>oai:ipsj.ixsq.nii.ac.jp:00194237</identifier>
        <datestamp>2025-01-19T23:36:20Z</datestamp>
        <setSpec>934:935:9619:9620</setSpec>
      </header>
      <metadata>
        <jpcoar:jpcoar xmlns:datacite="https://schema.datacite.org/meta/kernel-4/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcndl="http://ndl.go.jp/dcndl/terms/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:jpcoar="https://github.com/JPCOAR/schema/blob/master/1.0/" xmlns:oaire="http://namespace.openaire.eu/schema/oaire/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rioxxterms="http://www.rioxx.net/schema/v2.0/rioxxterms/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="https://github.com/JPCOAR/schema/blob/master/1.0/" xsi:schemaLocation="https://github.com/JPCOAR/schema/blob/master/1.0/jpcoar_scm.xsd">
          <dc:title>Evaluating Portable Mechanisms for Legitimate Execution Stack Access with a Scheme Interpreter in an Extended SC Language</dc:title>
          <dc:title xml:lang="en">Evaluating Portable Mechanisms for Legitimate Execution Stack Access with a Scheme Interpreter in an Extended SC Language</dc:title>
          <jpcoar:creator>
            <jpcoar:creatorName>Masahiro, Yasugi</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:creator>
            <jpcoar:creatorName>Reichi, Ikeuchi</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:creator>
            <jpcoar:creatorName>Tasuku, Hiraishi</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:creator>
            <jpcoar:creatorName>Tsuneyasu, Komiya</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:creator>
            <jpcoar:creatorName xml:lang="en">Masahiro, Yasugi</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:creator>
            <jpcoar:creatorName xml:lang="en">Reichi, Ikeuchi</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:creator>
            <jpcoar:creatorName xml:lang="en">Tasuku, Hiraishi</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:creator>
            <jpcoar:creatorName xml:lang="en">Tsuneyasu, Komiya</jpcoar:creatorName>
          </jpcoar:creator>
          <jpcoar:subject subjectScheme="Other">[通常論文] interpreters, proper tail recursion, execution stacks, closures, transformation</jpcoar:subject>
          <datacite:description descriptionType="Other">Scheme implementations should be properly tail-recursive and support garbage collection. To reduce the development costs, a Scheme interpreter called JAKLD, which is written in Java, was designed to use execution stacks simply. JAKLD with interchangeable garbage collectors was reimplemented in C. In addition, we have proposed an efficient C-based implementation written in an extended C language called XC-cube, which features language mechanisms for implementing high-level programming languages such as “L-closures” for legitimate execution stack access, with which a running program/process can legitimately access data deeply in execution stacks (C stacks). L-closures are lightweight lexical closures created from nested function definitions. In addition to enhanced C compilers, we have portable implementations of L-closures, which are translators from an extended S-expression based C language into the standard C language. Furthermore, we have another mechanism for legitimate execution stack access, called “closures”. Closures are standard lexical closures created from nested function definitions. Closures can also be implemented using translators. In this study, JAKLD was reimplemented in an extended SC language (S-expression based C language) that features nested functions to evaluate (L-)closures and their implementations, including translators.
------------------------------
This is a preprint of an article intended for publication Journal of
Information Processing(JIP). This preprint should not be cited. This
article should be cited as: Journal of Information Processing Vol.27(2019) (online)
------------------------------</datacite:description>
          <datacite:description descriptionType="Other">Scheme implementations should be properly tail-recursive and support garbage collection. To reduce the development costs, a Scheme interpreter called JAKLD, which is written in Java, was designed to use execution stacks simply. JAKLD with interchangeable garbage collectors was reimplemented in C. In addition, we have proposed an efficient C-based implementation written in an extended C language called XC-cube, which features language mechanisms for implementing high-level programming languages such as “L-closures” for legitimate execution stack access, with which a running program/process can legitimately access data deeply in execution stacks (C stacks). L-closures are lightweight lexical closures created from nested function definitions. In addition to enhanced C compilers, we have portable implementations of L-closures, which are translators from an extended S-expression based C language into the standard C language. Furthermore, we have another mechanism for legitimate execution stack access, called “closures”. Closures are standard lexical closures created from nested function definitions. Closures can also be implemented using translators. In this study, JAKLD was reimplemented in an extended SC language (S-expression based C language) that features nested functions to evaluate (L-)closures and their implementations, including translators.
------------------------------
This is a preprint of an article intended for publication Journal of
Information Processing(JIP). This preprint should not be cited. This
article should be cited as: Journal of Information Processing Vol.27(2019) (online)
------------------------------</datacite:description>
          <dc:publisher xml:lang="ja">情報処理学会</dc:publisher>
          <datacite:date dateType="Issued">2019-01-30</datacite:date>
          <dc:language>eng</dc:language>
          <dc:type rdf:resource="http://purl.org/coar/resource_type/c_6501">journal article</dc:type>
          <jpcoar:identifier identifierType="URI">https://ipsj.ixsq.nii.ac.jp/records/194237</jpcoar:identifier>
          <jpcoar:sourceIdentifier identifierType="ISSN">1882-7802</jpcoar:sourceIdentifier>
          <jpcoar:sourceIdentifier identifierType="NCID">AA11464814</jpcoar:sourceIdentifier>
          <jpcoar:sourceTitle>情報処理学会論文誌プログラミング（PRO）</jpcoar:sourceTitle>
          <jpcoar:volume>12</jpcoar:volume>
          <jpcoar:issue>1</jpcoar:issue>
          <jpcoar:file>
            <jpcoar:URI label="IPSJ-TPRO1201002.pdf">https://ipsj.ixsq.nii.ac.jp/record/194237/files/IPSJ-TPRO1201002.pdf</jpcoar:URI>
            <jpcoar:mimeType>application/pdf</jpcoar:mimeType>
            <jpcoar:extent>2.0 MB</jpcoar:extent>
            <datacite:date dateType="Available">2021-01-30</datacite:date>
          </jpcoar:file>
        </jpcoar:jpcoar>
      </metadata>
    </record>
  </GetRecord>
</OAI-PMH>
