Grace at ECOOP 2016

Grace will be around in various ways at the ECOOP 2016 conference in Rome in July.

We’ve just heard that Tim Jones will be presenting at technical paper on inheritance design, which includes a models of Grace’s inheritance.

ECOOP is also hosting a workshop on GRACE (and similar language designs). The workshop is interested in short research papers, position papers, and tool demonstrations in areas such as:

  • experience implementing Grace
  • critiques and feedback on the Grace specification
  • proposed extensions to Grace
  • lessons that Grace may take from other related language projects (such as Pyret, Racket, BlueJ, Wyvern, Stride,TouchDevelop, TrumpScript etc)
  • lessons that Grace may take from language workbench implementation tools

particularly given the recent Draft Grace Language Specification

Expressions of interest to submit position papers or make presentations should be emailed to the organisers.

Grace specification draft 0.7: request for comments.

The Grace project team is delighted to announce that we have released the Grace Language Specification Draft Version 0.7.0 for public comment at gracelang.org. The core language specification is accompanied by a draft description of the standard prelude and key modules.

grace-spec-0.7.0.pdf Grace Draft Language Specification 0.7.0 (pdf)
grace-spec-0.7.0.html Grace Draft Language Specification 0.7.0 (html)
grace-prelude-0.7.0.pdf Grace Draft Standard Prelude 0.7.0 (pdf)
grace-prelude-0.7.0.html Grace Draft Standard Prelude 0.7.0 (html)

This specification is very much a draft. We expect the specification itself, and the langauge described by the specification, to continue to change as we work towards a stable version of the language — indeed, we hope that this evolution will be driven by the comments on this and subsequent drafts.

The specification drafts are supported by several implementations (minigrace, Kernan, and Hopper, also available at gracelang.org) none of which implement the full specification at the time of writing. We know these implementations are prototypes, which is why we are primarily interested in feedback on the language specification.

You can give us feedback in a range of ways: by commenting here; by emailling grace-spec@ecs.vuw.ac.nz; or by joining the
Grace community.
We look forwards to hearing from you.

Changes to Generics

The Grace 0.7.0 specification replaces the use of angle brackets for generic type arguments Foo<o> with double square brackets: Foo[[o]].

This change only affects the syntax of the language, not the semantics. Generic arguments remain optional, and if not supplied have the Unknown type.

*          *          *          *          *

The reasons for this change are to make Grace programs easier to read (for people) and to parse (for programs). Using the old syntax, for example, code such as:

could call a one-argument method run passing the result of a generic call a<B,C>(1), or it could call the two-argument method run, with arguments a<B and c>(1).

The new syntax resolves these cases clearly. Compare:

with

*          *          *          *          *

At the time of this post, no Grace implementation supports this new syntax.

Constructors for Collections

Grace 0.7 introduces Lineups – a built-in constructor for immutable iterables. So [1, 2, 3] is an iterable with three elements.  This will enable us to remove variable-arity methods.  For example, the constructors for Set, List, etc in the collections library will now take a single iterable rather than a variable number of arguments.

On the inside, methods that take an iterable as an argument are not very different from those with a variable number of parameters.  The method declaration is different, because the parameter is declared as xs:Iterable<Number> instead of *xs:Number, but we think that this is clearer. In both cases, the type of xs is such that the body of the method can iterate over it and deal with one Number at a time.

From the outside (the requestor’s view), the main change is that variable-arity method requests like

will be replaced by single argument requests like

You can use iterable constructors directly, for example, to initialise variables or constants

but, because we intentionally provide Iterables with a limited protocol, it’s more typical to use them to create collection objects:

*          *          *          *          *

The old design using variable-arity methods initially seemed more “neutral”, because it did not require honouring one particular kind of collections with the privileged of being built in, while others were relegated to a library.  However, if the truth be told, both designs rely on a built-in implementation of some sort of collection.  The old design created these collections implicitly whenever a request was received by a variable arity method; the new design creates the Iterable explicitly before the request is made.  Escape analysis should permit both designs to be optimised either in a JIT or by a whole-program compiler, should that become an issue.  But the new design makes it much simpler to check that methods are requested with the correct number of arguments.