Imperatrix Mundi — Current Ideas

Introduction

See Introduction for the purpose, main references, and name.

I put the rest of this page in reverse chronological order.

2010-08-27

Revisions

On 2010-02-13 under "Scope for Identifiers" I said I will make areas of scope for variables explicit, using (curly) braces. I now trash that idea because I want to use curly braces as inspired by the Oz language, as I explain below.

On 2010-02-04 I laid out in a table some sigils for certain modes of argument. For an oracle pool, I indicated that no identifier would be necessary. I thought that all oracle pools would have the same potential uses, so there would be no need to identify different lineages of them. Since then, however, it has occurred to me that since an oracle pool provides a handle on some computing resources, it should be possible to name and distinguish them so they can be used for example to control the resources in a specific remote computer.

Learn Syntax from the Oz Language

I think the syntax of the Oz language should inspire that for Imperatrix Mundi.

Oz requires no statement separators, nor does it rely on significant line endings as Ruby and some other languages do. Consequently, if I write a parser for a sufficiently Oz-like syntax, I shan't have to deal with line endings as different from any other whitespace. This property of a programming-language syntax has the further advantage of simplifying unparsers.

I need to chose and start using some tool that can assure me that a given draft grammar is unambiguous.

In Oz, the procedure-call syntax uses the curly braces. No doubt, in typical Oz code, many of the statements are procedure calls. No doubt, in Oz, the procedure call is the principal means whereby anything gets expressed in code. Since I want to steal from Oz syntax the properties mentioned above about parsing statements, I will make the top-level elements of the syntax for Imperatrix Mundi mimic those of Oz, in their outermost features (e. g., the braces). Inside of the braces, I can safely introduce differences.

In Imperatrix Mundi, true to its name, the easiest command to write should be the message send into a bag chanel. Therefore, I will begin composing the grammar by taking from Oz its easiest construct to use, that being the procedure call, and from the outer syntax of the Oz procedure call, begin to construct the syntax for the message send into a bag channel for Imperatrix Mundi.

I must examine all statement-level syntax in Oz and prescribe in each case what it should mean for Imperatrix Mundi.

Another very nice thing to copy from the Oz way of seeing things is their treatment of symbols and messages. A symbol in Oz is semantically a message devoid of parameters. I should copy this wholesale if possible.

I think to proceed by examining all constructs in Oz and deciding which will apply to Imperatrix Mundi. Once I have eliminated the Oz constructs that are totally inapplicable to Imperatrix Mundi (for example, the assignment), I shall have the basic framework for the grammar. I can then adapt the insides of borrowed constructs that need it, then if necessary create new constructs for the aspects of Imperatrix Mundi semantics that are not as yet addressed by the draft grammar.

2010-02-13 — Scope for Identifiers

Until some other rule becomes obviously better, I will make areas of scope for variables explicit, using (curly) braces. The braces will mean scope and only scope.

If I were going to require the variables to be declared, I'd say put them in vertical bars, as in Smalltalk. I'd have that just inside the opening left brace for the given scope. However, I think the use of variables can suffice to declare them, at least, provided that I use a special syntax to wrap the use of varaibles from an outer scope.

Prefix dollar sign can denote reference to a variable from the next outer scope.

Suffix bang marks where, in a given scope, the value of a copyable variable is being determined. At the places where the value of the copyable variable is being cited, the identifier appears naked.

2010-02-04 — Let the Orinoco Flow

The language has to express certain kinds of flow for the communication of information or authorities. Typically the flows are not symmetric. That is, they have direction. When I describe a given kind of flow, I might arbitrarily name the directions along it as "forward" and "backward", for example. One could adopt the practices of some railroads and call the directions "northbound" and "southbound". No matter how we label the two directions along a flow, when we describe the type of flow, we have to explain what kind of information and authority goes in each direction.

A type of flow taken together with a particular direction constitutes a "mode", similar to how the term is used in connection with the Mercury programming language.

Let's see whether my thinking coheres well enough at this point that I can give a table of the kinds of flow from the modal viewpoint.

Flow Mode	example of one end	example of the other end
Value	foo!	foo?
Oracle Pool	<->	>-<
Bag Channel	foo^	foo#
Linear Flow	foo	foo