hEP 001 – Mathematical 𝐡 in the Standard Implementation

Enhancement Proposal for the h Programming Language

2022-03-18

hEP001
TitleMathematical 𝐡 in the Standard Implementation
AuthorZach Manson
StatusProposed
TypeFeature
hlang-version1.0

Abstract

This hEP proposes a framework for adding first-class support for additional forms of h used in mathematical contexts, and that "𝐡" be added to the h programming language standard implementation. As of version 1.0, the only supported output characters are "h" and "'".

Motivation

The h Programming language is borne from the conlang h which was formalised in 2019 by Xe Iaso.

In their unveiling of the language they exhibited how the conlang's simple syntax could be used for complex conversation, all within the use of a single written character and phone:

<Cadey> h
<DoesntGetIt> h h h h
* Cadey facepalms

As stated in h's formal specification, it can be used to represent all possible communications within the confines of the letter h.

She later developed a syntax, compiler and runtime for the h Programming Language (hlang). This programming language was designed for the output of the h conlang, and expanded the character set in use to include both the Romanic form "h" and its Lojbanic equivalent "'".

A long-standing difficulty for the programming language is expressing mathematical notation in its output. While it is entirely possible to express any and all equations in the language, for this purpose it doesn't utiltise the "h" character to its maximum capacity and as such is unnecessarily verbose.

Goals

The primary goals of this proposal are to provide a specification for implementing additional forms of "h" in hlang to enable more terse output for use in mathematical contexts. The only additional form of "h" proposed in this hEP is "𝐡" (U+1D421).

The proposal would enable programs such as this:

$ cat new_equation.h
𝐡 𝐡 h '

AST this would generate during compilation:

H("𝐡 𝐡 h '")

Program output:

𝐡 𝐡 h '

This is an improvement over the existing implementation, which would require the much longer and more cumbersome hlang 1.0 source to produce the equivalent equation:

$ cat old_equation.h
h h h ' ' h ' h h h h h h h h h ' h

Translating this from h (conlang) to English:

a^2 + b^2 = c^2

Non-Goals

This hEP is not an attempt to sully hlang with characters outside of the formal grammar of the h conlang. The scope of the specification, while allowing for additional forms of "h" to be supported, is exclusively for forms of "h". It is not applicable to other characters, such as "g".

This hEP only explicitly proposes the addition of "𝐡" (U+1D421) though is designed to allow other forms of "h" to be supported by hlang in the future, such as "𝒉" (U+1D489), "𝓱" (U+1D4F1), or "𝕙" (U+1D559). While these forms could be implemented in a near identical manner to "𝐡", that is outside of the scope of this hEP. All of these forms of "h" are UTF-8 characters designed for use in mathematical equations.

The hEP is also explicitly not intending to enable support for "h" with diacritics, such as "ḧ" (U+1E27). Etymologically related forms of modern "h" are also outside the scope of this hEP.

Semantics

Under this proposal, "𝐡" would receive first class support by hlang. To output it would be the same as the standard "h" character:

$ cat math_h.h
𝐡

Produced AST:

H(𝐡)

Output:

𝐡

Represented with a node tree:

&peg.Node{
    Name: "H",
    Text: "𝐡",
    Kids: nil,
}

The node tree for the earlier Pythagorean example would be:

&peg.Node{
    Name: "H",
    Text: "𝐡 𝐡 h '",
    Kids: {
        &peg.Node{
            Name: "",
            Text: "𝐡",
            Kids: nil,
        },
        &peg.Node{
            Name: "",
            Text: "𝐡",
            Kids: nil,
        },
        &peg.Node{
            Name: "",
            Text: "h",
            Kids: nil,
        },
        &peg.Node{
            Name: "",
            Text: "'",
            Kids: nil,
        },
    },
}

The "𝐡" character should be usable in all contexts where "h" and "'" are currently usable. Grammatically it should follow all the same principles and restrictions as "h" and "'".

Dependencies

As with hlang v1.0, this proposal not require any dependencies, other than UTF-8 formatted source files.

Acknowledgements

Thanks to Xe Iaso for creating h and hlang, as well as all their other incredible projects.