Normal Service Should Now Be Resumed

We’ve had some problems with this blog over the last week, due mainly to issues with our commercial hosting provider.

Gracelang.org – and this blog – are now hosted at Victoria University of Wellington, in New Zealand, thanks to the ECS programming team & friends. So while it make take a little longer to load, it should always be here.

What’s in a Name: Variable and Constant bindings

As in most languages, Grace lets you bind names to values. In Grace’s case, the values are always objects. Some bindings are constant, that is, they don’t change until the names goes out of scope; others are variable, which means that the name can be re-bound to a new value. This re-binding is accomplished using assignment.

Constant Bindings

Constant bindings are used to bind method parameters to the arguments of the message that started the method execution. Grace supports constant bindings with the keyword const.

Const requires a name to define, and either or both an initialiser and a type. Const can be used to give a name to a literal, or to any other object.

If there is no initialiser, the identifier must be assigned (using =) before it is used.

The point of definitions like “const x : Rational” or const x — without an initialiser — is that in class definitions, they will be used to define per-instance constants that will be initialised when the object is constucted. For example, a point in Grace would declare two constants “x” and “y” — which would differ for each instance.

Uninitialised variables (of any type) are given a special “uninitialised” value; accessing this value is an error (caught either at run time or at compile time, depending on the cleverness of your implementor).

Variables

Naturally enough, Grace supports variable declarations via the “var” keyword.

Unlike constant name bindings, variables can be re-bound using assignment “:=”

Note that const uses = initialisation, while var uses := for both the initial and subsequent bindings.

As in Java, both const and var declarations may occur anywhere within a method or block: their scope is to the end of their defining block or method.

Fields

Within object or class constructors, fields are declared by the field keyword rather than var.

The idea here is that classes will contain methods defined by the method keyword, and fields defined by the field keyword. We are hoping that we can choose Grace’s keywords to guide the terminology used in discussing the language.

Const declarations an also appear in object and class constructors, to define per-instance constants.

Single Namespace

Grace has a single namespace for methods and variables. This means that methods should be able to override fields, and fields override methods.

A declaration of field or a constant named “x” creates a reader method called “x”. A declaration of a (writable) field creates a setter method called “set_x”. All code of the form “e1.x := e2” is executed by sending the “set_x” setter method to the object e1, passing e2 as an argument.

The upshot of this is, if a Grace program declares a pair of methods in an object:

clients (and subclasses) of that object are unable to distinguish this from a field declaration

This ensures that fields and constants are evaluated in Grace using the same message send evaluation rule as method sends.

Types

We haven’t mentioned types. That’s because we haven’t worked out the even the initial details – but that’s what we’ll look at soon.

Decisions

This note outlines our current design of Grace. We have a few questions or concerns about this design:

  1. Should Grace distinguish between var to declare temporary variables and field to declare instance fields – or if not, which one should we pick?
  2. Should Grace distinguish between := for mutable fields and variables, and = for constants?
  3. How should Grace name setter methods?  “set_x” or “s:=” or something else.

BNF