*This post is a continuation of the investigation into
U+237C ⍼ RIGHT ANGLE WITH DOWNWARDS ZIGZAG ARROW.
Many thanks to Barbara Beeton, James David Mason, Anders Berglund, David Bolton, Andy Whyte,
the Rare Books staff at the Cambridge University Library, and Bob Richardson at the St Bride Library.*

I’ve summarized a chronological timeline in the previous post, but here are the highlights in reverse chronological, corresponding roughly to the order in which I’ve discovered the information:

- ISO/IEC JTC1/SC2/WG2 N2191 (Proposal for Encoding Additional Mathematical Symbols) adds U+237C ⍼ to the Unicode standard, which took characters from
- The STIX project, whose character tables were compiled by Barbara Beeton, taking characters from, among many other sources,
- ISO/IEC TR 9573-13 (Public entity sets for mathematics and science), a technical report for SGML, where the trail ends.

Further investigation into various glyph registries and entity tables yielded no additional information.

About a year later, I went over everything I knew again and started looking for new leads. The rest of this post collects together the live Twitter updates I had been posting during this process.

The ISO standards site tells us that TR 9573-13 was the responsibility of subcommittee 34 (SC 34) under Joint Technical Committee 1 (JTC 1) of ISO/IEC. A fortuitous search led to a historical account of JTC 1/SC34, originally compiled by James David Mason, who was vice-chairman of SC 34. Given the age of the document, I doubted the email address listed for him was up to date, but eventually I found him on Linkedin, which indicated that he’s a co-chair for the Balisage Conference. I contacted the conference chair, who put me in contact with Mason.

From the historical account and Mason himself, I’ve found that working group 1 (WG 1) of SC 34 was responsible for ISO 8879, the SGML standard, as well as TR 9573-13. The main people working on these were Charles Goldfarb, the inventor of SGML, and Anders Berglund, who was responsible for TR 9573-13. The entire SC 34 committee records are now at the Charles Babbage Institute Archives at the University of Minnesota, and consists of 9.5 cubic feet of material in 10 boxes (!). Luckily, I wouldn’t have to fly to Minneapolis to sift through all of these records, because eventually Mason managed to find me a current email address for Berglund.

Berglund tells me that the entity sets for TR 9573-13 come from three sources:

- ISO/IEC 8859, a precursor of ISO/IEC 10646 and Unicode;
*MathSci, an expansion of mathfile, Appendix D*from the AMS; and- various typeface catalogues, notably Monotype.

Our glyph comes from Monotype under the matrix serial number S16139.

Unfortunately (but reasonably, as all of this is from three decades ago), Berglund doesn’t have any notes on which Monotype catalogues were referenced. However, I’ve separately confirmed that the symbol is indeed from Monotype from their archives. Although the Type Archive, which held the Monotype Collection, is now shutting down, the Science Museum Group has taken photographs of the collection. There are over 5000 punches and matrices in the collection, but I was extremely lucky with my search keywords and happened upon a set of punches, Extraneous sorts (L231)…

… which contains that very sort.

The SMG holds one catalogue, the *Specimen Book of ‘Monotype’ Printing Type*.
Its index
does list L231 as an “Extraneous sorts” series,
but those specimen sheets aren’t included in this book.

While looking for other catalogues that Monotype have published,
I came across Alembic Press’ collection
of Monotype publications.
I contacted David Bolton at the press for help with the catalogues,
who got back to me with a list of publications of lists of signs that do *not* contain S16139.
Since the serial number begins with S, it should be listed as a mathematical special sign,
but it was not found in any of:

*Monotype Special Sorts*(1931, 1947) — up to S1153, S6844;*Monotype Special Signs*(1954 – 1963) — up to S11819;*Monotype Mathematical Sorts List*(1956) — up to S10477;*4-Line Mathematics Classified List of Characters*(1967, 1970) — up to S19717, S20620.

Although the serial numbers in *4-Line Mathematics* do go past S16139,
it excludes several ranges such as S16137 – S16237 and S18325 – S18347,
likely characters not involved in 4-line mathematical typesetting
or were specialized commissioned characters.

Many signs were for individual customers, so might not merit being published in a list, although for example I happen to have signs S2120 to S2125, which were only for Jesus College Cambridge Boat Club as far as I know, but which do feature in the 1947 list.

Alembic Press lists, but does not possess, one final document, *List of Mathematical Characters*.
However, it can be found in the Morison Collection
at the Cambridge University Library.
According to their catalogue, they have three documents under this name:

- [
**1970.11.585**] List of mathematical characters. London, 1970. 72p; ring bdg. [For Monotype and Monophoto.] - [
**1972.12.177**] List of mathematical characters. np, 1972. 21 loose sheets. [Sheets for insertion in List (1970).] - [
**Morison.MC.D25**] List of mathematical characters. [London], nd. ca50 leaves

I contacted the Rare Books department, who sent me photographs of two documents with this name.
The first, under Morison.MC.D25, is
*List of mathematical characters: ‘Monotype’ 4-line Mathematics Series 569 & L231, ‘Monophoto’ Times Mathematics Series 569B & L231B*.
The second, under 1972.12.177, is
*L231 and L231B* (July 1972), a set of 21 sheets meant to be inserted at the end of the *List*.
Since S16139 was found in the set of punches of Extraneous Sorts in series L231,
I believe it may appear within these 21 sheets.

After this story received some attention from HackerNews (again), Cambridge alumnus Andy Whyte contacted me and offered to go visit and take photographs of the items in person, and determined that S16139 is indeed in 1972.12.177 on the sixth sheet. I requested a digital scan of that page, which cost 18£.

There it is, on the third-to-last row of the second column: S16139. Given its similarity to the photo that Berglund sent me, I think this is the very document from his notes.

St Bride Library is a library dedicated to the history of print, typography, and design, and they hold a number of Monotype documents. I’ve contacted them about some of these documents, and Bob Richardson got back to me with some information. Here are, I believe, the relevant ones:

*List of mathematical characters*, Monotype Corporation Ltd., 1972 — same as the above*List of Monotype founts and special sorts at the University Press Oxford*, Oxford University Press, 1976 — a “slim paperback” that doesn’t contain S16139*Monotype Special Sorts: Specimens of Arbitrary Characters not included in ordinary sets of Matrices*(SB49888), 1932 — according to Bob, “attempts have been made to update some pages by carefully drawing (or printing by hand) examples of newer characters”

As I’m likely physically visiting London next year for other purposes,
I might also visit St Bride Library to take a look at these documents,
especially the last one.
I’m also interested in the whimsically-titled
*Mathematical sorts in continuous creation: verses written partly in mathematical notation*
by Arthur H. Phillips from 1957.

I was also informed about the state of the documents that were formerly at the Type Archive:

All of the Monotype records relating to special characters have now been removed from the Type Archive site at Stockwell. The documents were palletised for transfer to the National Collections Centre at Wroughton several months ago and are completely inaccessible. The pallets will be stored in climate controlled conditions at their new home but I cannot imagine that it would be easy to gain access since this would involve a fork-lift truck and considerable manpower.

The Type Archive did hold some paper records for the kind of character you describe, but they were of a technical nature and would not have provided much more than a reference number, a date of creation and details of the point sizes and faces in which the character was available. I cannot recall seeing any details of a specific customer for any special characters, other than in the Typographical Committee records.

It appears there’s only a single surviving volume of the Typographical Committee Minutes from 1959 to 1964, which only contains “typefaces and decorative (border) materials and things like National Emblems”. I think these committee records would’ve been my best bet at uncovering the history of the mathematical sorts — if they had still existed.

]]>*Washington Square — 345 S 12th Street*

One of Philly’s largest and oldest queer bookstores!
They carry both used books and a lot of new queer fiction,
as well as some secondhand clothing and other miscellany.

*South Street — 704 South Street*

A small volunteer-run leftist anarchist bookstore.
They have a lot of leftist materials you wouldn’t see elsewhere and a lot of zines.

*Queen Village — 529 Bainbridge Street*

With an unassuming storefront,
they have a HUGE two-storey warehouse of books in the back.
This is probably the largest used bookstore in Philly.

*Bella Vista — 1010 S 9th Street*

What can I say?
It’s a small bookstore with records (or a record store with books) and good vibes.

*Logan Square — 311 N 20th Street*

A used bookstore I think associated with the public libraries of Philly.

*University City — 220 S 40th Street*

The nearest used bookstore to campus, which is super convenient for me.
Sometimes there’s a bookstore cat hanging around!
Open surprisingly late.

*University City — 3920 Spruce Street*

A Victorian rowhouse turned used bookstore with teetering towers of books.
The fiction selection upstairs is very large and tends to be older and more literary.

*Old City — 7 N 2nd Street*

A true labyrinth of a bookstore, with a similarly large and old collection of fiction upstairs.
They also have a lovely bookstore cat!

*Spruce Hill — 4530 Baltimore Avenue*

Just a quaint little bookstore, what more could you ask for?

*South Street – 530 S 4th Street*

A very cool shop full of local art!
They’ve got zines, stickers, pins, keychains, cards, prints, clothes, and so on.

*Fishtown – 2158 E Dauphin Street*

Imagine goth meets vintage.
You’ll find jewellery and trinkets of that aesthetic, spiders and skulls and sigils,
and some amazing taxidermy pieces too.

*South Street – 534 South Street*

High quality, curated vintage clothing and other oddities.
Note that they very much emphasize *not* being a thrift store!

*Old City – 142 North 2nd Street*

Less clothing but a wider range of cute vintageware,
including toys and household goods.

*Fishtown; Spruce Hill; Graduate Hospital*

Similar to A Four Foot Prune,
there’s three locations of antique furniture, houseware, and trinkets.

*South Street – 710 S 5th Street*

Sister store to Giovanni’s Room,
with a larger selection of clothing and houseware,
and a decent amount of books as well.

*Centre City – 1520 Chestnut Street*

A more traditional thrift clothing store with racks and racks and racks of clothes.

*Manayunk – 4165 Main Street*

A combination plant store and teashop.
Yes I know I said I wouldn’t include any food places but this place is really cute and I couldn’t not.

Here I collect a list of the shops that *are* as good as Rain or Shine,
ordered from west to east.
Prices are for the smallest (non-kid’s) scoop in a cup, including 8% tax, excluding tip.
This isn’t a total ranking of the ice cream shops,
because I think they’re *all* worthwhile to visit if you want ice cream.
However, I’ve put stars next to the ones I especially like,
so if you find yourself equidistant between an entry with a star and one without,
do go for the one with a star instead of flipping a coin.

This list only has shops specializing in ice cream scoops
(which they call “hard” or “frozen” ice cream here, for some reason,
as if anyone would want unfrozen ice cream).
I will *not* include soft serve, rolled ice cream, shaved ice,
or large ice cream chains like Ben & Jerry’s or Häagen-Dazs —
if I can buy a pint at a grocery store back in Vancouver,
there’s no point including it on a Philly-specific list.
If you’re curious about where I might visit next,
my map of ice cream shops
includes both places on this list and places I’ve yet to visit.
Photos can be found in the Twitter thread above,
or in my Instagram guide.

265 S 44th Street (bw Spruce & Locust)

Single scoop: 4.99$

2827 W Girard Avenue

Single scoop: 4.32$

2623 W Girard Avenue

Single scoop: 4$

229 S. 20th Street (bw Walnut & Locust)

Single scoop: 6.48$

1901 Chestnut Street

“Single” scoop (two flavours): 6.75$

115 S 18th Street / 119 S 13th Street

Single scoop: 6.21$

263 S 17th Street

Single scoop: 4.90$

1716 Chestnut Street

Small gelato: 5.94$

9 E Passyunk Avenue (by Dickinson)

Single scoop: 5.94$

2 E Passyunk Avenue (by 13th & Moore)

Single scoop (w/ topping and drizzle): 5.40$

903 S 9th Street (by Christian)

Single scoope: 5$

618 S 5th Street (by South)

Single scoop: 4.50$

2311 Frankford Avenue (by Dauphin)

Single scoop: 5$

1255 E Palmer Street (on Thompson)

Single scoop: 5$

6616 Germantown Avenue

Single scoop: 5.94$

4369 Main Street

Single scoop: 5.12$

Society Hill — 410 S 2nd Street

Oat milk ice cream: 5.40$

*A coffee shop that makes their own oat milk
and a very thick, pudding-like delicious oat ice cream.*

Manayunk — 4165 Main Street

Rose and saffron ice cream: 4.86$

*Not in the main list since it’s not an ice cream shop,
but for some reason this teahouse-turned-plantstore has one (1) single ice cream flavour
and it’s really good??*

Chinatown — 202 N 9th Street (by Race)

Soft serve: 7.29$

*They have a matcha and a hojicha flavour.
A little ridiculously expensive, but the flavour is excellent and very strong.*

Centre City — 243 Market Street

Single scoop: 6.48$

*According to their site, they use milk from their own cows, which I think is very unique and impressive.
A shame that the ice cream is incredibly melty, way too sugary, and overall not that good.*

Even though I spent a good amount of time repairing the physical machine in which Thulium lived, in anticipation of moving to an entirely different country for my PhD (I wasn’t going to physically lug a desktop tower with me everywhere), I decided to move Thulium onto a VPS with Hetzner in October 2021. I was also earning an income as a Master’s student, so I felt justified in spending money monthly on what barely constitutes a hobby (I’m glad to be in a position where 7€/month is now peanuts to me). I currently have the following with Hetzner:

- A CPX11 cloud server in Nuremberg, Germany with 2 vCPUs, 2 GB RAM, 40 GB disk space, and an IPv4 address for 3.99€/month;
- An additional attached 15 GB volume at 0.60€/month for my borg backups; and
- A BX10 storage box in Berlin, Germany with 100 GB storage at 2.90€/month for my photos backup.

I may turn the storage box into an attached volume later on. It’s a little more expensive at 0.04€/GB for a total of 4€/month, but a little more flexible with the storage size, and more convenient to access since the storage box doesn’t really have SSH access.

So far, using a VPS has worked quite well with the added bonus that
Thulium doesn’t go down every time my ISP decides to change my home IP address.
There is some lag when SSHing into the server,
probably because it’s physically located in Germany,
but the internet connection is *so* much faster—`apt update`

practically finishes instantaneously
compared to when it was in a box sitting in my home.

This brings us now, though, to a Ship of Theseus question, except it’s the Server of Thulium: is it still Thulium if I’ve reinstalled the entire server on my home machine in 2020 and then moved the entire server from my home machine to a VPS, having changed out both the software and the hardware?

In October 2020, I decided to no longer renew my very first domain name, ert.space. I already had my current domain, ionathan.ch, since November 2019, and I’ve now consolidated my server’s web services and my website to both be accessed from ionathan.ch. hilb.ert.space is thus no more, although in memory of it this blog is still named ⟨ortho|normal⟩.

In the last retrospective from two (!) years ago, I listed out what I was running from my server. Now, the cohort is:

- The same Nextcloud instance, although with a few update mishaps along the way;
- Gitbert on Gitea as always; and
- A FreshRSS instance in place of TTRSS after the latter kept breaking across updates;

I’m no longer hosting my personal wiki, and is instead just a collection of files in a GitHub wiki. Some of these are org-mode files rather than Markdown files, because I thought I’d finally learn how to use org mode in Emacs (I thought wrong). Additionally, I’ve moved this website from GitHub Pages to GitLab Pages, since it gives me more flexibility with the Ruby plugins, which I’ve written about in a previous post.

*Very* recently, I’ve also set up an MTA with Postfix on my server (not through Docker)
so that cron can send me emails when something goes wrong.
This was spurred by the fact that I ran out of disk space for borg to create new backups,
which failed silently, which resulted in a three-month gap in my backups.

It turns out it’s a lot of work to get everything running smoothly! My wiki page on MTA with Postfix has all the technical notes and annoying details. It can receive mail as well, which I didn’t originally set out to set up, but until I actually see spam incoming I’ll hold off on any more elaborate antispam measures like SpamAssassin. I’m still debating whether to also set up a MUA and some sort of mail client to interact with Postfix. Mail servers are so, so very complicated and convoluted.

Overall, I’m quite pleased with how everything is now set up.
I don’t usually need to go in to maintain anything,
except for updating Nextcloud when the GUI indicates there’s a new version,
and now hopefully I’ll immediately be notified by cron when there *is* something I need to handle.
Aside from considering moving the storage box to an attached volume and adding a MUA to my MTA,
I don’t have any other major changes or additions planned.

On the other hand, GitLab Pages is much less restrictive with what’s allowed,
because the build process is literally just a
CI script.
This bypasses the plugins allowlist, but not the configuration overrides, which are from the `github-pages`

Gem.
The first thing to do, then, is to forego the Gem and include only the plugins I need in `Gemfile`

.
On top of that, I have the Gems required to use KaTeX as kramdown’s math engine.

```
source "https://rubygems.org"
gem "jekyll-feed"
gem "jekyll-gist"
gem "jekyll-paginate"
gem "jekyll-remote-theme"
gem "jekyll-scholar"
gem "katex"
gem "kramdown-math-katex"
```

`github-pages`

also specifies a number of default configurations,
but most of these are either Jekyll defaults
or undesirable (namely allowlist plugins and kramdown configurations).
I also already have a number of configurations set from when I was using GH Pages.
The below are the only missing configurations that needed adding in `_config.yml`

to include the Jekyll plugins and to enable using KaTeX for kramdown.
I use the KaTeX option to output MathML so that I don’t need to include a stylesheet.

```
plugins:
- jekyll-feed
- jekyll-gist
- jekyll-paginate
- jekyll-remote-theme
- jekyll-scholar
kramdown:
math_engine: katex
math_engine_opts:
output: mathml
```

Finally, to use GitLab Pages, there needs to be a CI configuration script to install Node.js
(which `kramdown-math-katex`

needs to run KaTeX) and to build the Jekyll site.

```
image: ruby:latest
pages:
script:
- apt-get update && apt-get -y install nodejs
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts:
paths:
- public
```

Now inline LaTeX works everywhere using double dollar signs:
`$$\int_{\partial \Omega} \omega = \int_{\Omega} d\omega$$`

yields
$\int_{\partial \Omega} \omega = \int_{\Omega} d\omega$.
There aren’t any delimiters for display-style math,
but you can always add `\displaystyle`

to a block of LaTeX.

*For updates on the hunt for ⍼, see the new post.*

Known as right angle with downwards zigzag arrow,
angle with down zig-zag arrow,
`\rangledownzigzagarrow`

,
and `⍼`

,
no one knows what ⍼ is meant to represent or where it originated from.
Section 22.7 Technical Symbols
from the Unicode Standard on the
Miscellaneous Technical block
doesn’t say anything about it.

The original proposal that included this character is Proposal for Encoding Additional Mathematical Symbols in the BMP (N2191) from 14 March 2000, with origins from the STIX project. That project page links to a number of relevant files dating all the way back to 1997, and most importantly to the very first collation of character tables by Barbara Beeton last updated on 24 June 1997. Here we find that, in table &ac-&cirmid under codes with TR 9573 names, an entry for the character.

AFIIISO TR9573 entityISO TR9573 descriptionD97C ⍼ angle with down zig-zag arrow

(This table is later merged into a larger table.) A table from 18 July 1997 clarifies that these are characters from the technical report TR 9573-13. A later table from 7 Feburary 1998 with accompanying glyphs confirms that this is indeed the character we’re looking for.

UnicodeGlyphSGMLNameDescriptionE248 angzarr ISOAMSA angle with down zig-zag arrow

The Unicode code point E248 is, of course, not its current actual code point. That one is located in a Private Use Area (PUA) in the Basic Multilingual Plane (BMP), and so was likely a temporary encoding within STIX before acceptance into Unicode proper. The AFII code point D97C will be explained later, as will what AFII stands for and what it is.

Related is the Mathematical Markup Language (MathML) Specification: Section 6.2.5.1 ISO Symbol Entity Sets provides the same tables as STIX, and our character can again be found in group ISO AMS-A.

The technical report, whose long name is
ISO/IEC TR 9573-13:1991 Techniques for using SGML — Part 13: Public entity sets for mathematics and science,
was published in July 1991;
its editor was Anders Berglund.
Although the ISO site claims there was never a newer version,
there is a document with the same name
last updated on 8 December 2003.
It indeed lists U+237C in Section 7.1 isoamsa,
but evidently this came *after* it was added to the Unicode Standard.

The actual tech report itself doesn’t provide much more information than the newer document,
shown in the capture above:
all it contains is its short name, the glyph, its old code point D97C, and a description.
(If you’re a UBC student or faculty, you can get access to the
tech report via Techstreet
or here.)
The only other reference is found in Section 6.2.5 Arrow Relations,
which gives the same entity listings as
ISOasma.ent
in the Debian package `sgml-data`

.

The Foreword of the tech report, though, mentions that it replaces an earlier annex.

h) Part 13 replaces ISO 8879:1986 annex D (in part)

Taking a look at ISO/IEC TR 9573:1988 Techniques for using SGML as well, which people at UBC can also access via CSA onDemand as CAN/CSA-Z243.210.1-89 (R2018), it also indicates that the symbols it uses comes from ISO 8879.

However, this Annex D of ISO 8879:1986 Standard Generalized Markup Language (SGML) (which UBC people can again access as CAN/CSA-Z243.210-89 (R2014) via CSA onDemand or here) doesn’t contain our character, neither under ISO AMS-A as expected, nor anywhere else. This does explain the category name, at least: “AMS” here stands for “Added Math Symbols”, and has nothing to do with the American Mathematical Society.

Annex D.4.4 Technical Use has a brief note on the origin of the names of the entities it *does* list, though.

NOTE — Visual depictions of most of the technical use entities are identified by their entity names in Association of American Publishers Electronic Manuscript Series: Markup of Mathematical Formulas, published by the Association of American Publishers, Inc., 2005 Massachusetts Avenue, N.W., Washington, DC 20036, U.S.A.

I obtained a second edition copy of *Markup of Mathematical Formulas*
from the University of Victoria, which lists the same entities, also missing our character.

Back in TR 9573-13, Section 5 mentions that the symbols tables contain

a glyph identifier, registered in accordance with ISO/IEC 10036. The glyph identifier is shown in decimal and hexadecimal representation;

this refers to the code point D97C/55676. While ISO/IEC 10036:1993 Procedure for registration of glyph and glyph collection identifiers (accessible as CAN/CSA-ISO/IEC 10036-01 (R2014)) only describes glyph registration, the actual 10036 registry exists online. Our character can be found among code points 556xx. In 2020, the glyph table was standardized as ISO/IEC TR 10036:2020 Registered glyph identifiers, containing the same glyphs.

55676

The registry indicates that this glyph is among thousands inherited from the Association for Font Information Interchange (AFII), established in 1987 (according to this search). They had their own registry as well, cited by ISO/IEC 10036:1996, Annex D Bibliography.

Association for Font Information Interchange (AFII)

International Glyph Register, Volume 1: Alphabetic Scripts and Symbols. 1993.

The AFII is long dissolved in favour of Unicode over their glyph registry; an email from Asmus Freytag, their former president, describes its history just before dissolution. Notably, it appears that anyone could register a glyph with the AFII for a fee of 5$ to 50$ (about 8.60$ to 86$, accounting for inflation).

There doesn’t seem to be a digitized version of the *International Glyph Register*,
but thankfully, there is a copy at the Library of Congress.
Additionally, *Font Technology: Methods and Tools* by Peter Karow
(which can be found here)
includes photocopies of the first 23 pages of the register in Appendix C Glyph Identifier Register.
In the Introduction, Edwin Smura, the registrar, describes its contents:

The first published document of the Association for Font Information Interchange contains a glyph identifier, at least one sample glyph shape, and a description including at least a name or title for the glyph and any significant information about the meaning or intended usage.

Unfortunately, no more information is provided by the register than is already present in ISO/IEC TR 10036.

After asking on the TeX Stack Exchange about the origin and meaning of the character, Barbara Beeton herself gave a response.

I had no idea what it meant or was used for, thus assigned it a “descriptive name” when collating the symbols for the STIX project. (I still have no idea, nor can supply an example of the symbol in use.) […] it is the case that ISO 9573-13 existed long before either AFII or the STIX project were formed. […] I once asked Charles Goldfarb what the source of these entities was, but remember that he didn’t have a definitive answer.

So its appearance in AFII’s registry comes *after* TR 9573-13,
which explains the fact that the registry was published in 1993 while the tech report in 1991,
although the tech report does reference ISO/IEC 10036,
whose earliest version was apparently published in 1993.
It’s possible there were earlier, unpublished versions of these documents.

In a follow-up comment, Beeton says:

Although I did ask, no one was able to tell me whether there was a single source or the entities were just picked up from a number of sources.

And in reference to Half as Interesting’s video:

The information in the video is inaccurate. It fails to recognize that the inclusion of the character in the STIX collection was based on its presence in a version of ISO 9573-13 earlier than the 1991 version cited, a version which existed long before AFII was formed. So any claim that it originated with AFII is chronologically invalid.

If she was unable to find a source while actively working with AFII and STIX back in the 90s, I doubt I would be able to uncover anything new now, three decades later. Here, then, I close the book on my investigation. The meaning of ⍼ will be whatever meaning is assigned by whoever uses it next… if anyone uses it at all.

- 1983: AAP Electronic Manuscript Project
begins, publishing a series that includes
*Markup of Mathematical Formulas* - 1986-10-15: ISO 8879 (SGML) is published,
containing ISO AMS-A without ⍼, referencing
*Markup of Mathematical Formulas* - 1987-09-15: AFII is established
- 1987-11:
*Markup of Mathematical Formulas*, 2 ed. is published without ⍼, referencing ISO 8879 - 1988-12: ISO/IEC TR 9573 (Techniques for using SGML) is published, referring to ISO 8879
- 1988: ISO 8879 is revised with a new Annex J
- 1988: ANSI/NISO Z39.59 (AAP Electronic Manuscript Standard) is published, based on part of the published series, likely with no entity tables
- 1991-07-01: ISO/IEC TR 9573-13 (Public entity sets for mathematics and science) is published, containing ISO AMS-A with the first verifiable occurrence of ⍼, referencing ISO/IEC 10036
- 1993-06: ISO/IEC 10036 (Glyph registration) is published
- 1993:
*International Glyph Register*by the AFII is published, containing ⍼ with no new information - 1994:
*Font Technology: Methods and Tools*by Peter Karow is published, containing a short excerpt of the*International Glyph Register* - 1994-09: ISO 12083 (Electronic manuscript preparation and markup) is published, based on ANSI/NISO Z39.59, with no entity tables
- 1996-07: ISO/IEC 10036 is revised,
referencing the
*International Glyph Register* - 1997-06: The STIX project begins, taking character tables from ISO/IEC TR 9573-13
- 2000-03-14: ISO/IEC JTC1/SC2/WG2 N2191 (Proposal for Encoding Additional Mathematical Symbols) is proposed, adding ⍼ to the Unicode Standard

What is the glyph *supposed* to look like?
Obviously without a definitive source, we can’t answer this question,
but we can look at what various interpretations of a downwards zig-zag arrow
overtop a right angle exist, starting with a vector reproduction of the glyph in the 10036 registry,
originally a 96 px × 96 px GIF and supposedly copied from AFII’s registry.

The zig-zag in question has a horizontal middle bar, with the lower bar crossing the corner of the angle. Then we have the glyph from TR 9573-13, which is luckily available as a proper PDF with vector glyphs rather than a scanned document.

The zig-zag in question also contains a horizontal middle bar, but the lower bar doesn’t cross the angle corner. The arrowhead has a rather unusual shape, but is in line with the arrowheads of the other glyphs. Strangely, the vertical bar of the right angle doesn’t have a consistent width. Next is a vector reproduction of the glyph from both STIX and MathML, which were originally 32 px × 32 px GIFs.

For some reason, the middle bar of the zig-zag is now diagonal rather than horizontal. There’s also an extra pixel at the bottom bend, and the arrow now crosses the corner of the right angle. Fun fact: the horizontal bar of the right angle is a single pixel shorter than the vertical bar. Then we have the glyph as designed in the Unicode proposal document.

This one just looks like a vectorized version of the previous pixellated version. I don’t think the pixellated glyph is a downsampled version of this glyph, since the arrowhead in this glyph is larger and extends beyond the angle corner.

These last four are examples of the character in four different fonts that provide it: GNU Unifont, STIX Two, Julia Mono, and Noto Sans Math/Noto Sans Symbols. Unifont’s glyph looks like an improved version of the pixellated version: the extra pixel is gone, both bends are the same size around the vertical bar, and the arrowhead is slightly larger and more distinguishable. STIX Two’s resembles the proposal version but with a fancier arrowhead. Julia Mono’s resembles it as well, but with more acute angles and a shorter horizontal axis. (I previously said that the bottommost bar of the zig-zag wasn’t straight, and that the vertical bar of the angle had inconsistent widths; the issue has since been resolved.) Finally, Noto Sans’ glyph doesn’t even have a zig-zag; They’ve chosen to interpret the character as a wavy arrow rather than a zig-zag arrow. All of these have an arrow crossing the right angle corner, which seems to be a distinguishing characteristic of the character.

*What is ⍼ used for?*on TeX SE and Math SE- Twitter thread about this post
- Ellis (), a chaos magic sigil that looks suspiciously similar to ⍼
*The Assault on Reality*, the origin of Ellis (referred to as the Linking Sigil)- Hacker News, Hacker News again, Lobste.rs, and Hackaday discussions
- XKCD #2606 mentions ⍼ and its Explain XKCD entry cites this post
- Half as Interesting did a video on this post (don’t bother, it’s less than half as interesting)

```
⎾⎿⏀⏁⏂⏃⏄⏅⏆⏇⏈⏉⏊⏋⏌
```

The first two and last two are part of Palmer notation for denoting human teeth by their position. What are the rest for?

The Unicode Standard, Section 22.7 Technical Symbols, doesn’t have much specific to say about the matter.

Dental Symbols.The set of symbols from U+23BE to U+23CC form a set of symbols from JIS X 0213 for use in dental notation.

Looking at the Miscellaneous Technical code chart, their names describe the appearance of the symbols but not so much their function.

```
23C0 ⏀ DENTISTRY SYMBOL LIGHT VERTICAL WITH CIRCLE
23C1 ⏁ DENTISTRY SYMBOL LIGHT DOWN AND HORIZONTAL WITH CIRCLE
23C2 ⏂ DENTISTRY SYMBOL LIGHT UP AND HORIZONTAL WITH CIRCLE
23C3 ⏃ DENTISTRY SYMBOL LIGHT VERTICAL WITH TRIANGLE
23C4 ⏄ DENTISTRY SYMBOL LIGHT DOWN AND HORIZONTAL WITH TRIANGLE
23C5 ⏅ DENTISTRY SYMBOL LIGHT UP AND HORIZONTAL WITH TRIANGLE
23C6 ⏆ DENTISTRY SYMBOL LIGHT VERTICAL AND WAVE
23C7 ⏇ DENTISTRY SYMBOL LIGHT DOWN AND HORIZONTAL WITH WAVE
23C8 ⏈ DENTISTRY SYMBOL LIGHT UP AND HORIZONTAL WITH WAVE
23C9 ⏉ DENTISTRY SYMBOL LIGHT DOWN AND HORIZONTAL
23CA ⏊ DENTISTRY SYMBOL LIGHT UP AND HORIZONTAL
```

The JIS X 0213 is yet another character set encoding standard and doesn’t explain much either. Any technical documents would probably be in Japanese, which I can’t read. Luckily, the Wikipedia page on Miscellaneous Technical keeps a pretty extensive historical record of how its characters were introduced into Unicode. According to the table, the dentistry symbols were introduced in version 3.2 originating from a proposal in 1999. Here’s where we’ll start our hunt for their meaning.

The dentistry symbols along with some circled digits were introduced in Addition of medical symbols and enclosed numbers on 13 September 1999. The document doesn’t actually explain what the symbols mean.

The Unicode Technical Committee has the same questions I do. The meeting minutes for a committee meeting over 26–29 October 1999 note:

Twenty Seven Dentist Characters

Consensus 81-C5: The circled characters will considered as part of a general mechanism as documented in 81-C4. Respond to the Shibano-san on the remaining proposed dentist symbols that we need evidence of usage. The UTC is not accepting any of the dentist symbols at this time. [L2/99-238]

Action Item 81-33 for Lisa Moore: Inform Shibano-san that we are not accepting any of the dentist symbol characters, and provide our feedback.

And so in a proposal comment on 23 November 1999, Lisa Moore, chair of the Committee, writes:

6) Twenty Seven Dentist Characters. The UTC will consider the ten double circled numbers as part of the general mechanism to be defined in the future. See 4) above. The remaining seventeen dentist symbols were not accepted due to insufficient evidence of usage. Please provide documents with examples of usage, and explain if any of these characters are combining, or if any extend across other symbols to delineate quadrants of the jaw.

The 17 symbols refer to the 15 dentistry symbols along with U+29FA ⧺ double plus and U+29FB ⧻ triple plus, which are later encoded in Miscellaneous Mathematical Symbols-B. In a proposal revision on 31 January 2000, Professor Kohji Shibano, chairman of the JCS committee, writes:

(c) Evidence of usage

You requested to submit evidence of usage for some characters. We are now preparing the requested document for the following characters with some explanation in English. This document will be sent to you as soon as possible.

Finally, in Rationale for non-Kanji characters proposed by JCS committee on 15 March 2000, the dentistry symbols are… “explained”.

(2) Dentist’s symbols

These symbols are used in dentistry when drawing XXX together with some BOX DRAWING characters. The proposal includes two types of characters; those used in single-line drawing and those in triple-line drawing.

It makes sense that the lines are meant to be used with box-drawing characters in dental notation to illustrate the teeth. But what do the circle, the triangle, and the tilde mean? The Wikipedia article on dental notation doesn’t seem to use these symbols (and nor does the corresponding German article, which is much more comprehensive).

The committees, on the other hand, seem satisfied with this explanation. The meeting minutes for an ISO/IEC subcommittee meeting over 21–24 March 2000 note a comment (Section 8.20, page 44) by Dr. Ken Whistler of Sybase, Inc.:

ii) The Dental symbols are sufficiently explained - these are box-drawing characters overlaid in specific manner.

The meeting minutes for a Unicode Technical Committee meeting on 28 April 2000 read:

[83-M3] Motion: Accept the twenty five characters documented in the report on the Beijing meeting, sections E 1, 2, 3, 5, 6, 7, 8, 9 [L2/00-108]:

⚬ Double plus sign and triple plus sign

⚬ 15 dentist symbols

So there aren’t any more explanations we can expect to see from these documents. Subsequent meeting minutes only discuss technical details. From 19–22 September 2000 (Section 7.21, page 40):

Action Items: Messrs. Michael Everson and Takayuki Sato - will provide better glyphs for the DENTIST Symbols (from document N2093). The amendment text is to be prepared by the editor.

From 9 March 2001 (Irish comments, page 5):

Table 63 (67) - Row 23: Miscellaneous Technical

The Japanese remarked in Athens that the glyphs for the dentistry symbols 23C0-23CC should fill a notional square. We have provided the editor with corrected glyphs.

And from 2–5 April 2001, more remarks on the shape of the characters (Section 7.1, page 21), and the proposed character names are changed from DENTIST to DENTISTRY (Section 7.1, page 22):

Comment 14: Shapes of JIS X0213 characters – Accepted.

Japan will supply suitable fonts. Kana has to cover all existing Kana characters also. As to the Dentist symbols, glyphs do not seem to look square. We need to know why current glyphs are not acceptable. A single font is needed for a range.

SE6: […] Rename DENTIST to DENTISTRY symbols … should it be DENTAL? Accept DENTISTRY.

On 27 March 2002, Unicode 3.2 is released. The current blurb on dentistry symbols is added as part of the Unicode Standard Annex #28; the new code points are highlighted in this code chart.

I don’t have any dentistry friends, but surely someone knows, so I asked around. I asked the Medical Sciences Stack Exchange, I asked on the Unicode mailing list, and I even threw the question out there on Twitter. In the end, though, someone I knew found it with a method so simple it never occurred to me.

And indeed, an explanation can be found right there in Dental Computing and Applications: Advanced Techniques for Clinical Dentistry by Andriani Daskalaki, published in 2009. In fact, a simple “dentistry unicode” search on Google Books takes me right there.

Of course, this isn’t the *origin* of the symbols, but it does explain what they mean.
According to Chapter XVII on
Unicode Characters for Human Dentition^{†},
the notation comes from Japan’s dental insurance claim system.

Although these signs are not specific to dentistry, we assigned a specific meaning to these modified numerical symbols in accordance with the dental insurance claim system in Japan.

…

Figure 4 shows nine characters in three groups denoting artificial teeth, supernumerary teeth and an abbreviation for a group of teeth respectively. A triangle with a bar indicates an artificial spacer, especially on a denture, a circle with a bar indicates a supernumerary tooth, and a tilde with a bar indicates an abbreviation for a group of teeth.

So that’s the end of the mystery. I should go update all the places I’ve asked with this discovery now.

Since the original publication of this post I’ve received some replies to my question posted to the Unicode mailing list, in particular Ryusei Yamaguchi’s response. Some of the sources cited agree with the above: 歯式の記載について on dental notation lists using ⏈ for describing a span of upper teeth and ⏇ for describing a span of lower teeth.

⏈: この記号の両端の歯の間に存在する全ての歯（上顎用で正中を越える）

[DeepL translation: “All teeth present between the teeth on either side of this sign (for maxillary and beyond the median)”]

⏇: この記号の両端の歯の間に存在する全ての歯（下顎用で正中を越える）

[DeepL translation: “All teeth present between the teeth on either side of this sign (for mandible and beyond the midline)”]

On the other hand, 電子レセプトの作成手引き on filing electronic dental insurance claims uses △ to indicate 「部近心隙」 (page 25), which seems to mean a diastema, or a tooth gap, so that ⏅⏃⏄ are used to indicate a gap between the front teeth, rather than artificial teeth as previously suggested. This usage is further backed up by the 歯式メーカー app, which describes using △ to indicate a gap.

△で隙を入力します。選択した歯の近心の隙を入力します。

[Google Translate: “Enter the gap with △. Enter the mesial gap of the selected tooth.”]

Finally, there doesn’t seem to be any other explanation of the circle and the usage of ⏂⏀⏁. Circled numbers indicate dental implants at the given tooth position, so it doesn’t make sense in that case for the circle to go in between teeth. It’s likely, then, that they are indeed for indicating supernumary teeth, and in particular the mesiodentes that occur between the two front teeth.

^{†}This does require access to IGI Global’s resources,
but you can just find the entire book here.

- Well-Founded Trees
- Indexed Well-Founded Trees
- Indexed Inductives and Fording
- Nested Inductives
- Inductive–Inductives
- Inductive–Recursives
- Indexed Well-Founded Trees as Canonized Well-Founded Trees

```
data W (A : 𝒰) (B : A → 𝒰) : 𝒰 where
sup : ∀ a → (B a → W A B) → W A B
```

`A`

selects the constructor as well as providing the constructor’s nonrecursive arguments.
`B`

then selects the recursive element as well as providing the recursive element’s arguments.

```
data Ord (A : 𝒰) : 𝒰 where
Z : A → Ord A
S : Ord A → Ord A
L : (ℕ → Ord A) → Ord A
Ord A = W (A + 𝟙 + 𝟙) B
where
B (in1 a) = 𝟘
B (in2 ∗) = 𝟙
B (in3 ∗) = ℕ
Z a = sup (in1 a) absurd
S o = sup (in2 ∗) (λ _ → o)
L f = sup (in3 ∗) f
```

```
data IW (I : 𝒰)
(A : I → 𝒰)
(B : ∀ i → A i → 𝒰)
(d : ∀ i → (a : A i) → B i a → I) :
I → 𝒰 where
isup : ∀ i → (a : A i) →
((b : B i a) → IW I A B d (d i a b)) →
IW I A B d i
```

The indexed W type can be seen as either encoding an inductive type with nonuniform parameters
or as encoding mutual inductive types, which are indexed inductive types anyway.
`I`

selects the nonuniform parameters, which I’ll call the index for now
`A`

selects the constructor, `B`

selects the recursive element,
and `d`

returns the index of that recursive element.

```
data Even : 𝒰 where
Z : Even
Sₑ : Odd → Even
data Odd : 𝒰 where
Sₒ : Even → Odd
EvenOdd = IW 𝟚 A B d
where
Even = in1 ∗
Odd = in2 ∗
A Even = 𝟚 -- Even has two constructors
A Odd = 𝟙 -- Odd has one constructor
B Even (in1 ∗) = 𝟘 -- Z has no recursive elements
B Even (in2 ∗) = 𝟙 -- Sₑ has one recursive element
B Odd ∗ = 𝟙 -- Sₒ has one recursive element
d Even (in1 ∗) = absurd
d Even (in2 ∗) ∗ = Odd
d Odd ∗ ∗ = Even
Z = isup Even (in1 ∗) absurd
Sₑ o = isup Even (in2 ∗) (λ _ → o)
Sₒ e = isup Odd ∗ (λ _ → e)
```

```
variable
T : 𝒰
_<_ : T → T → 𝒰
data Acc (t : T) : 𝒰 where
acc : (∀ s → s < t → Acc s) → Acc t
Acc t = IW T (λ _ → 𝟙) (λ t ∗ → ∃[ s ] s < t) (λ t ∗ (s , _) → s) t
```

```
data PTree (A : 𝒰) : 𝒰 where
leaf : A → PTree A
node : PTree (A × A) → PTree A
PTree = IW 𝒰 (λ A → A + 𝟙) B d
where
B A (in1 a) = 𝟘
B A (in2 ∗) = 𝟙
d A (in1 a) = absurd
d A (in2 ∗) ∗ = A × A
leaf A a = isup A (in1 a) absurd
node A t = isup A (in2 ∗) (λ _ → t)
```

So far, (nonuniformly) parametrized inductives and mutual inductives can be encoded. Indexed inductives can be encoded as well by first going through a round of fording to turn them into nonuniformly parametrized inductives. Meanwhile, mutual inductives can also be represented as nonuniform parametrized inductives by first turning them into indexed inductives.

```
variable
A B : 𝒰
data Image (f : A → B) : B → 𝒰 where
image : ∀ x → Image f (f x)
-- Forded image type
data Image' (f : A → B) (b : B) : 𝒰 where
image' : ∀ x → b ≡ f x → Image f b
Image' f b = W (∃[ x ] b ≡ f x) 𝟘
image' x p = sup (x , p) absurd
```

```
data Fin : ℕ → 𝒰 where
FZ : ∀ n → Fin (S n)
FS : ∀ n → Fin n → Fin (S n)
-- Forded finite sets type
data Fin' (m : ℕ) : 𝒰 where
FZ' : ∀ n → m ≡ S n → Fin m
FS' : ∀ n → m ≡ S n → Fin n → Fin m
Fin' = IW ℕ (λ m → 𝟚 × ∃[ n ] m ≡ S n) B d
where
B m (in1 ∗ , n , p) = 𝟘
B m (in2 ∗ , n , p) = 𝟙
d m (in1 ∗ , n , p) = absurd
d m (in2 ∗ , n , p) ∗ = n
FZ' m n p = isup m (in1 ∗ , n , p) absurd
FS' m n p fin = isup m (in2 ∗ , n , p) (λ _ → fin)
```

Nested inductive types, when represented as recursive μ types, have nested type binders. Nonindexed inductive types potentially with nonuniform parameters, on the other hand, are single μ types.

```
Ord A = μX: 𝒰. A + X + (ℕ → X)
EvenOdd = μX: 𝟚 → 𝒰. λ { in1 ∗ → 𝟙 + X (in2 ∗) ; in2 ∗ → X (in1 ∗) }
Acc = μX: T → 𝒰. λ t → ∀ s → s < t → X s
PTree = μX: 𝒰 → 𝒰. λ A → A + X (A × A)
Fin' m = μX: ℕ → 𝒰. (∃[ n ] m ≡ S n) + (∃[ n ] (m ≡ S n) × X n)
```

Nested inductives, when not nested within themselves, can be defunctionalized into indexed inductives, which can then be forded into nonuniformly parametrized inductives, which can finally be encoded as indexed W types.

```
data FTree : 𝒰 where
ftree : List FTree → FTree
FTree = μX: 𝒰. List X = μX: 𝒰. μY: 𝒰. 𝟙 + X × Y
data I : 𝒰 where
Tree : I
List : I → I
data Eval : I → 𝒰 where
nil : Eval (List Tree)
cons : Eval Tree → Eval (List Tree) → Eval (List Tree)
ftree : Eval (List Tree) → Eval Tree
data Eval' (i : I) : 𝒰 where
nil' : i ≡ List Tree → Eval' i
cons' : i ≡ List Tree → Eval' Tree → Eval' (List Tree) → Eval' i
ftree : i ≡ Tree → Eval' (List Tree) → Eval' i
Eval' = IW I A B d
where
A i = i ≡ List Tree + i ≡ List Tree + i ≡ Tree
B _ (in1 _) = 𝟘
B _ (in2 _) = 𝟚
B _ (in3 _) = 𝟙
d _ (in1 _) = absurd
d _ (in2 _) (in1 ∗) = Tree
d _ (in2 _) (in2 ∗) = List Tree
d _ (in3 _) ∗ = List Tree
```

It’s unclear how this might be encoded either as indexed inductives or as an indexed W type.

```
data Bush (A : 𝒰) : 𝒰 where
bnil : Bush A
bcons : A → Bush (Bush A) → Bush A
Bush = μX: 𝒰 → 𝒰. λ A → 𝟙 + A × X (X A)
```

While mutual inductives allow the types of constructors of multiple inductives to refer to one another, inductive–inductives further allow one inductive to be a parameter or index of another.

```
data A : 𝒰 where
…
data B : A → 𝒰 where
…
```

That is, the entries of a context must be well formed under the correct context, while the context under which types are well formed must themselves be well formed.

```
data Ctxt : 𝒰 where
· : Ctxt
_∷_ : ∀ Γ → Type Γ → Ctxt
data Type : Ctxt → 𝒰 where
U : ∀ Γ → Type Γ
Var : ∀ Γ → Type (Γ ∷ U Γ)
Pi : ∀ Γ → (A : Type Γ) → Type (Γ ∷ A) → Type Γ
```

To encode this inductive–inductive type, it’s split into two mutual inductives:
an “erased” one with the type interdependency removed (i.e. `Type'`

does not have a `Ctxt'`

parameter),
and one describing the relationship between the two.

```
data Ctxt' : 𝒰 where
· : Ctxt'
_∷_ : Ctxt → Type → Ctxt
data Type' : 𝒰 where
U : Ctxt' → Type'
Var : Ctxt' → Type'
Pi : Ctxt' → Type' → Type' → Type'
data Ctxt-wf : Ctxt' → 𝒰 where
·-wf : Ctxt-wf ·
∷-wf : ∀ {Γ} {A} → Ctxt-wf Γ → Type-wf Γ A → Ctxt-wf (Γ ∷ A)
data Type-wf : Ctxt' → Type' → 𝒰 where
U-wf : ∀ {Γ} → Ctxt-wf Γ → Type-wf Γ (U Γ)
Var-wf : ∀ {Γ} → Ctxt-wf Γ → Type-wf (Γ ∷ U Γ) (Var Γ)
Pi-wf : ∀ {Γ} {A B} → Ctxt-wf Γ → Type-wf Γ A →
Type-wf (Γ ∷ A) B → Type-wf Γ (Pi Γ A B)
```

In other words, `Ctxt'`

and `Type'`

describe the syntax,
while `Ctxt-wf`

and `Type-wf`

describe the well-formedness rules.

```
Γ ⩴ · | Γ ∷ A (Ctxt')
A, B ⩴ U | Var | Π A B (Type' with Ctxt' argument omitted)
─── ·-wf
⊢ ·
⊢ Γ Γ ⊢ A
────────── ∷-wf
⊢ Γ ∷ A
⊢ Γ
────────── U-wf
Γ ⊢ U type
⊢ Γ
──────────────── Var-wf
Γ ∷ U ⊢ Var type
⊢ Γ Γ ⊢ A Γ ∷ A ⊢ B
───────────────────── Pi-wf
Γ ⊢ Π A B type
```

The final encoding of a context or a type is then the erased type paired with its well-formedness.

```
Ctxt = Σ[ Γ ∈ Ctxt' ] Ctxt-wf Γ
Type (Γ , Γ-wf) = Σ[ A ∈ Type' ] Type-wf Γ A
· = · , ·-wf
(Γ , Γ-wf) ∷ (A , A-wf) = Γ ∷ A , ∷-wf Γ-wf A-wf
U (Γ , Γ-wf) = U Γ , U-wf Γ-wf
Var (Γ , Γ-wf) = Var Γ , Var-wf Γ-wf
Pi (Γ , Γ-wf) (A , A-wf) (B , B-wf) = Pi Γ A B , Pi-wf Γ-wf A-wf B-wf
```

These indexed mutual inductives can then be transformed into a single indexed inductive with an additional index,
then into a nonuniformly parametrized inductive, and finally into an indexed W type.
The same technique can be applied to generalized inductive–inductives, e.g. “infinitary” `Pi`

.

```
data Type' : 𝒰 where
…
Pi∞ : Ctxt' → (ℕ → Type') → Type'
data Type-wf : Ctxt' → Type' → 𝒰 where
…
Pi∞-wf : ∀ {Γ} {T : ℕ → Type'} → Ctxt-wf Γ →
(∀ n → Type-wf Γ (T n)) → Type-wf Γ (Pi∞ Γ T)
Pi∞ (Γ , Γ-wf) TT-wf = Pi∞ Γ (fst ∘ TT-wf) , Pi∞-wf Γ-wf (snd ∘ TT-wf)
```

You can’t encode these as W types apparently.

*This section is lifted from Dan Doel’s encoding
of indexed W types as W types following the canonical construction from
Why Not W? by Jasper Hugunin.*

An indexed W type can be encoded as an unindexed one by first storing the index
together with the `A`

type as in `IW'`

below.
Then, define the `canonical`

predicate to assert that, given some index selector `d`

as would be found in an indexed well-founded tree,
not only is the current index the one we expect,
but the index of all recursive elements are the ones dictated by `d`

.
That is, `f b`

gives the actual recursive element from which we can extract the index,
while `d i a b`

gives the expected index, and we again assert their equality.
Finally, an encoded indexed W type `EIW`

is a `IW'`

type such that the index is canonical.

```
variable
I : 𝒰
A : I → 𝒰
B : ∀ i → A i → 𝒰
d : ∀ i → (a : A i) → B i a → I
IW' (I : 𝒰) →
(A : I → 𝒰) →
(B : ∀ i → A i → 𝒰) → 𝒰
IW' I A B = W (∃[ i ] A i) (λ (i , a) → B i a)
canonical : (∀ i → (a : A i) → B i a → I) → IW' I A B → I → 𝒰
canonical d (sup (i , a) f) i' = (i ≡ i') × (∀ b → canonical d (f b) (d i a b))
EIW : (I : 𝒰) →
(A : I → 𝒰) →
(B : ∀ i → A i → 𝒰) →
(d : ∀ i → (a : A i) → B i a → I) → I → 𝒰
EIW I A B d i = Σ[ w ∈ IW' I A B ] (canonical d w i)
isup : (i : I) → (a : A i) → ((b : B i a) → EIW I A B d (d i a b)) → EIW I A B d i
isup i a f = sup (i , a) (fst ∘ f) , refl i , (snd ∘ f)
```

Untyped conversion (and therefore reduction), I think, is meant to model the implementation of a conversion checker. (I’m really not the best person to ask.) Ideally, you’d want it to be entirely decoupled from the type checker, which is a very Software Engineering 110 reasonable thing to expect. An implementation outline might look like this:

- Reduce both terms sufficiently.
- If they look different, give up.
- Recur on subterms.

“Sufficiently” might mean normal form or weak head normal form or whatever reasonable form you like. So we might formalize that as follows:

```
───────────────────────── β
(λx: τ. e) e' ⊳ e[x ↦ e']
────── ⊳*-refl
e ⊳* e
e₁ ⊳ e₂
e₂ ⊳* e₃
──────── ⊳*-trans
e₁ ⊳* e₃
eᵢ ⊳* eᵢ'
─────────────────────── ⊳*-cong
e[x ↦ eᵢ] ⊳* e[x ↦ eᵢ']
e₁ ⊳* e
e₂ ⊳* e
─────── ≈-red
e₁ ≈ e₂
```

The “sufficiently” part comes from `⊳*-trans`

, where you take as many steps as you need.
The congruence rules are the most tedious, since you need one for every syntactic form,
so I’ve instead lazily written them as a single substitution.
Conversion is an equivalence relation, as you’d expect:
it’s reflexive (by `⊳*-refl`

), it’s symmetric (by swapping premises in `≈-red`

),
it’s substitutive (by `⊳*-cong`

), and it’s transitive *if* reduction is confluent,
because then you can construct the conversion by where the pairs meet.
(Confluence left as an exercise for the reader.)

```
e₁ ≈ e₂ ≈ e₃
\ / \ /
e₁₂ e₂₃ ← confluence gives this diamond
\ /
e*
e₁ ⊳* e*
e₃ ⊳* e*
────────
e₁ ≈ e₃
```

Dually to β, let’s now add η-contraction, but suppose we had cumulativity
(or more generally, *any* subtyping relation).
Then η-contraction is no good, since it breaks confluence.
Supposing we had types `σ ≤ τ`

, `λx: σ. (λy: τ. f y) x`

could either β-reduce to `λx: σ. f x`

,
or η-contract with congruence to `λy: τ. f y`

, but these are no longer α-equivalent due to the type annotation.
Breaking confluence then means breaking transitivity of conversion as well.
η-contraction then isn’t an option with Church-style type-annotated intrinsically-typed terms.

What about η-expansion? If you had a neutral term typed as a function, you may expand it once. But with untyped conversion, there’s no way to tell whether the term is indeed typed as a function, and you can’t go around η-expanding any old neutral term willy-nilly.

The remaining solution is then to add η-equivalence as part of conversion. There are two ways to do this; the first is the obvious way.

```
────────────── ≈-ηₗ (+ ≈-ηᵣ symmetrically)
λx: τ. f x ≈ f
```

This immediately requires explicit transitivity and congruence rules,
since `λx: τ. λy: σ. f x y ≈ f`

wouldn’t hold otherwise.
The other way is to check that one side is a function,
then apply the other side.

```
e₁ ⊳* λx: τ. e₁'
e₂ ⊳* e₂'
x ∉ FV(e₂')
e₁' ≈ e₂' x
──────────────── ≈-ηₗ (+ ≈-ηᵣ symmetrically)
e₁ ≈ e₂
```

This looks more ideal since it seems like it easily extends the implementation outline:

- Reduce both terms sufficiently.
- If one of them looks like a function, recur according to
`≈-η`

. - If they look different, give up.
- Recur on subterms.

You then still need congruence rules for step 4;
otherwise `F G ≈ F (λX: 𝒰. G X)`

would not hold given some `F: (𝒰 → 𝒰) → 𝒰`

and `G: 𝒰 → 𝒰`

.
It seems like transitivity *might* hold without explicitly adding it as a rule,
again by confluence, but this time requiring induction on derivation heights rather than structural induction,
and first showing that the derivation of any symmetric conversion has the same height.

Suppose we were in a setting with multiple syntactic functions, for instance the Calculus of Constructions or System F, where abstraction by and application of a type differs from ordinary term abstractions and applications.

```
Γ, x: σ ⊢ e: τ Γ, α: ⋆ ⊢ e : τ
─────────────────────── ─────────────────
Γ ⊢ λx: σ. e : Πx: σ. τ Γ ⊢ Λα. e : ∀α. τ
Γ ⊢ e : Πx: σ. τ Γ ⊢ e : ∀α. τ
Γ ⊢ e' : σ Γ ⊢ σ : ⋆
──────────────────── ────────────────────
Γ ⊢ e e' : τ[x ↦ e'] Γ ⊢ e [σ] : τ[α ↦ σ]
(λx: τ. e) e' ⊳ e[x ↦ e'] (Λα. e) [σ] ⊳ e[α ↦ σ]
```

If both of these functions had η-conversion rules, transitivity wouldn’t hold,
especially for open terms.
Specifically, the conversions `λx: τ. f x ≈ f`

and `f ≈ Λα. f [α]`

are both derivable
(despite being ill-typed when considered simultaneously, since conversion is untyped),
but `λx: τ. f x ≈ Λα. f [α]`

is impossible to derive.

In Oury’s Extensional Calculus of Constructions [2],
equality reflection is added to untyped conversion
(`≡`

denoting the equality *type*).

```
Γ ⊢ p: x ≡ y
──────────── ≈-reflect
Γ ⊢ x ≈ y
```

There’s a clash between the fact that ill-typed terms can still be convertible,
and that equality reflection only makes sense when everything is well-typed.
In particular, you cannot simultaneously have congruence and transitivity of conversion,
since it allows you to derive an inconsistency.
Concretely, using an ill-typed proof of `⊤ ≡ ⊥`

(where `⊤`

is trivially inhabited by `∗`

and `⊥`

is uninhabited),
you can convert from `⊤`

to `⊥`

.

```
· ⊢ ⊤ ≈ (λp: ⊤ ≡ ⊥. ⊤) refl (by β-reduction)
≈ (λp: ⊤ ≡ ⊥. ⊥) refl (by ≈-cong and ≈-reflect on (p: ⊤ ≡ ⊥) ⊢ p: ⊤ ≡ ⊥)
≈ ⊥ (by β-reduction)
```

Note the ill-typedness of the application:
`refl`

is clearly not a proof of `⊤ ≡ ⊥`

.
Evidently this leads to a contradiction,
since you could then convert the type of `∗`

from `⊤`

to `⊥`

.

Coq’s conversion algorithm can be found in its kernel,
which is actually one giant algorithm parametrized over whether it should be checking convertibility or cumulativity.
The below is my attempt at writing it down as rules (ignoring cases related to (co)inductives),
with MetaCoq’s conversion in pCuIC as guidance.
`[ʀ]`

represents the relation over which they are parametrized,
which can be either `[≈]`

or `[≤]`

.

```
i = j
────────── ≈-𝒰
𝒰ᵢ [≈] 𝒰ⱼ
i ≤ j
────────── ≤-𝒰
𝒰ᵢ [≤] 𝒰ⱼ
τ₁ [≈] τ₂
σ₁ [ʀ] σ₂
───────────────────────── ʀ-Π
Πx: τ₁. σ₁ [ʀ] Πx: τ₂. σ₂
t₁ [ʀ] t₂
e₁ [≈] e₂
─────────────── ʀ-app
t₁ e₁ [ʀ] t₂ e₂
τ₁ [≈] τ₂
e₁ [ʀ] e₂
───────────────────────── ʀ-λ
λx: τ₁. e₁ [ʀ] λx: τ₂. e₂
τ₁ [≈] τ₂
t₁ [≈] t₂
e₁ [ʀ] e₂
───────────────────────────────────────────── ʀ-let
let x: τ₁ ≔ t₁ in e₁ [ʀ] let x: τ₂ ≔ t₂ in e₂
e₁ [ʀ] e₂
─────────────────────── (catch-all for remaining syntactic constructs)
t[x ↦ e₁] [ʀ] t[x ↦ e₂]
e₂ x ⊳* e₂'
e₁ [≈] e₂'
──────────────── ʀ-ηₗ
λx: τ. e₁ [ʀ] e₂
e₁ x ⊳* e₁'
e₁' [≈] e₂
──────────────── ʀ-ηᵣ
e₁ [ʀ] λx: τ. e₂
```

The “real” conversion and subtyping rules are then the confluent closure of the above. The actual implementation performs more reduction as needed; I think this is just for performance reasons, and because there’s no way to forsee how many steps you’ll end up having to take during initial reduction.

```
e₁ ⊳* e₁'
e₂ ⊳* e₂'
e₁' [≈] e₂'
───────────
e₁ ≈ e₂
e₁ ⊳* e₁'
e₂ ⊳* e₂'
e₁' [≤] e₂'
───────────
e₁ ≤ e₂
```

Reflexivity and symmetry of conversion and reflexivity of subtyping are easy to see. Congruence is built into the rules (shown with the same substitution notation as before). Evidently conversion implies subtyping, but this time indirectly.

[1] McBride, Conor. (9 January 2015). *universe hierarchies*. ᴜʀʟ:https://pigworker.wordpress.com/2015/01/09/universe-hierarchies/.

[2] Oury, Nicolas. (TPHOLs 2005). *Extensionality in the Calculus of Constructions*. ᴅᴏɪ:10.1007/11541868_18.