Why do Zoe keywords have to start with a capital letter?

[dckc]

What is the motivation for the Zoe keyword constraint?

Some of us (@ivanlei , ...) were discussing this in the context of...

• addAssetToVault does not support initial lower-case asset names #8235
• provisionPool Error: keyword ... must be an ascii identifier starting with upper case #8238

[dckc]

@erights explained...

I’ll start this with a true story of the hazard we’re trying to avoid before going into too much detail.
At one time, if you wrote a Google doc consisting only of the string __proto__ your document would hang.

---

JS has two main forms of property lookup: obj.name and obj[expr] , where expr is expected to evaluate to a property name or array index. We can generally divide most property names into two categories: those statically known by the author of the program, and those determined by data entering the program from the outside, such as all incoming messages. For statically known property names, they are almost always used as obj.name, where, for example, the type depends on the name. This is why most other languages with records / structs do not have such a lightweight way of looking up properties by computed property names — it is rarely needed by a program for its own statically known property names.

All such statically known property names built into JS begin either with a lowercase letter or an underscore. Widespread convention which we follow also names all such program internal property names with a lowercase letter.

When we do have an expression such as obj[expr], unless we have evidence to the contrary, we should assume that outside data may determine what expr evaluates to.

Given that most programs mostly avoid computed property lookup for their own statically known property names, another place where normal JS programs use obj[expr] is array lookup, where the program assumes that expr evaluates to an array index. For these cases, if expr evaluates to something else, then something unexpected is looked up. The Jessie grammar encourages expressing these as obj[+expr], where JS unary + coerces to a number. The [] themselves in theory coerce the expression to a string, so obj[+expr] is guaranteed to only lookup number-named properties, i.e., property names that could be the result of coercing a number to a string. This includes 'NaN' , 'Infinity', and '-Infinity'.

The main remaining utility of obj[expr] is for so-called “objects as maps”, i.e., to do in a lightweight way with an object what should in principle be done with an explicit Map. Modern good style for these is generally to just use a Map, sidestepping the notational collision. The ease of JSON notation, and the ability to write it literally and inline, is the main attractor in the other direction. For Zoe’s KeywordRecords, the notational convenience was irresistible. When we tried using Maps for this, it was just too painful. But once you admit objects-as-maps, then you will write obj[expr] often, where expr’s value is controlled by outside data. This is fine if the only values that can be looked up by this expression are values that are conceptually part of the map, i.e., that you would have stored in the conceptual map that you’re emulating. If all objects-as-maps inherited from nothing, so that the only properties it had are these conceptual map-keys, no problem. This is actually possible in JS. But again, the notational overhead was too great. And it is not what JSON objects unserialize to in any case.

Instead, Zoe’s KeywordRecords (like all CopyRecords) inherit from JavaScript’s Object.prototype, which defines a bunch of methods all these objects inherit. Most interesting is toString because it is called by a bunch of JS implicit coercions.

> y = JSON.parse('{"ToString": 8}')
> y + ''
'[object Object]'

> x = JSON.parse('{"toString": 8}')
> x + ''
Uncaught TypeError: Cannot convert object to primitive value

Our keyword rules not only insist only on identifiers beginning with an upper case letter, they also prohibit the number-names including NaN and Infinity . This effectively guarantees that their portion of the property name space does not collide either with program internal statically known properties nor with array indexes.