<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
  <!ENTITY docName "draft-whited-static-shell-00">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     obsoletes=""
     updates=""
     submissionType="independent"
     ipr="trust200902"
     docName="&docName;"
     category="info"
     xml:lang="en"
     tocInclude="true"
     symRefs="true"
     sortRefs="true"
     version="3">
  <!-- xml2rfc v2v3 conversion 2.39.0 -->
  <front>
    <title abbrev="Static Shell">The "Static" Shell Scripting Language</title>
    <seriesInfo name="Internet-Draft" value="&docName;"/>
    <author initials="S." surname="Whited" fullname="Sam Whited">
      <organization>Individual</organization>
      <address>
        <email>sam@samwhited.com</email>
        <uri>https://blog.samwhited.com/</uri>
      </address>
    </author>
    <author initials="C." surname="Paul" fullname="Cameron Paul"/>
    <date/>
    <keyword>scripting</keyword>
    <abstract>
      <t>
        We describe a statically typed scripting language with a focus on type
        safety and shell integration.
      </t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <section>
        <name>Overview</name>
        <t>
        This is a description of the Static shell scripting language.
        </t>
        <t>
        Static is a scripting language designed to be executed by a terminal
        emulator and used as the users shell.
        It is statically typed and has explicit support for standard streams and
        for executing external programs.
        </t>
      </section>
      <section>
        <name>Terminology</name>
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
          "MAY", and "OPTIONAL" in this document are to be interpreted as
          described in BCP 14 <xref target="RFC2119"/>, <xref target="RFC8174"/>
          when, and only when, they appear in all capitals, as shown here.
        </t>
        <t>
          Many important terms used in this document are defined in
          <xref target="RFC6365"/>, and <xref target="Unicode"/>.
        </t>
      </section>
      <section>
        <name>Methodology</name>
        <t>
        The syntax is specified using Augmented Backus-Naur Form (ABNF) as
        specified in <xref target="RFC5234"/>.
        </t>
      </section>
    </section>
    <section>
      <name>Source Code Representation</name>
      <t>
        Source code is Unicode text encoded with <xref target="RFC3629">UTF-8</xref>.
        The text is not canonicalized.
      </t>
      <t>
        Implementation restriction: For compatibility with other tools, a
        compiler may disallow the NUL character (U+0000) in the source text.
      </t>
      <t>
        Implementation restriction: For compatibility with other tools, a
        compiler may ignore a UTF-8-encoded byte order mark (U+FEFF) if it is
        the first Unicode code point in the source text. A byte order mark may
        be disallowed anywhere else in the source.
      </t>
      <section>
        <name>Characters</name>
        <t>
          The following terms are used to denote specific Unicode character
          classes:
        </t>
        <artwork><![CDATA[
newline        = /* the Unicode code point U+000A */ .
unicode_char   = /* an arbitrary Unicode code point
                    except newline */ .
unicode_letter = /* a Unicode code point classified as
                    "Letter" */ .
unicode_digit  = /* a Unicode code point classified as
                    "Number, decimal digit" */ .
]]></artwork>
        <t>
            In The Unicode Standard 8.0, Section 4.5 "General Category" defines
            a set of character categories.
            Static treats all characters in any of the Letter categories Lu, Ll,
            Lt, Lm, or Lo as Unicode letters, and those in the Number category
            Nd as Unicode digits.
        </t>
      </section>
      <section>
        <name>Letters and digits</name>
        <t>
          The underscore character _ (U+005F) is considered a letter.
        </t>
        <artwork><![CDATA[
letter        = unicode_letter | "_" .
decimal_digit = "0" … "9" .
octal_digit   = "0" … "7" .
hex_digit     = "0" … "9" | "A" … "F" | "a" … "f" .
]]></artwork>
      </section>
    </section>
    <section>
      <name>IANA Considerations</name>
      <t>
      This document requires no interaction with the Internet Assigned Numbers
      Authority (IANA).
      </t>
    </section>
    <section>
      <name>Security Considerations</name>
      <t>
      TODO
      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="BCP" value="14"/>
          <author initials="S." surname="Bradner" fullname="S. Bradner">
            <organization/>
          </author>
          <date year="1997" month="March"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml">
        <front>
          <title>UTF-8, a transformation format of ISO 10646</title>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="STD" value="63"/>
          <author initials="F." surname="Yergeau" fullname="F. Yergeau">
            <organization/>
          </author>
          <date year="2003" month="November"/>
          <abstract>
            <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
        <front>
          <title>Augmented BNF for Syntax Specifications: ABNF</title>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="STD" value="68"/>
          <author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
            <organization/>
          </author>
          <author initials="P." surname="Overell" fullname="P. Overell">
            <organization/>
          </author>
          <date year="2008" month="January"/>
          <abstract>
            <t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC6365" target="https://www.rfc-editor.org/info/rfc6365" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6365.xml">
        <front>
          <title>Terminology Used in Internationalization in the IETF</title>
          <seriesInfo name="DOI" value="10.17487/RFC6365"/>
          <seriesInfo name="RFC" value="6365"/>
          <seriesInfo name="BCP" value="166"/>
          <author initials="P." surname="Hoffman" fullname="P. Hoffman">
            <organization/>
          </author>
          <author initials="J." surname="Klensin" fullname="J. Klensin">
            <organization/>
          </author>
          <date year="2011" month="September"/>
          <abstract>
            <t>This document provides a list of terms used in the IETF when discussing internationalization.  The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.   This memo documents an Internet Best Current Practice.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="BCP" value="14"/>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization/>
          </author>
          <date year="2017" month="May"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="Unicode" target="http://www.unicode.org/versions/latest/">
        <front>
          <title>The Unicode Standard</title>
          <author>
            <organization>The Unicode Consortium</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="Go" target="https://golang.org/ref/spec">
        <front>
          <title>The Go Programming Language Specification</title>
          <author/>
          <date/>
        </front>
      </reference>
    </references>
    <section>
      <name>Acknowledgements</name>
      <t>
        Some text in this document was copied from <xref target="Go"/>.
      </t>
    </section>
  </back>
</rfc>
