This page lists current and historical documents describing the design of Grace and its evolution.

Drafts for comments

Grace Draft Language Specification
Grace Draft Standard Prelude
minitest testing dialect

Older documents

panelAbstract.pdf SPLASH 2010 Panel Abstract
panelSlides4up.pdf SPLASH 2010 Panel Slides
splash2011BofSlides.pdf SPLASH 2011 Grace BOF Slides
StateOfGrace-WG2.16-Feb28.pdf London Feb 2012 Programming Language Design Working Group Slides
Lang.Next talk2.key.pdf Lang.Next 2012 Slides
onward-final2012.pdf “Grace: the absence of (inessential) difficulty.” To be presented at Onward 2012.
UnitTestingWithGUnit-1255.pdf Unit Testing with GUnit (version 1255)
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)
grace-spec0095.pdf Draft Grace language specification version 0.095
grace-spec0100.pdf Draft Grace language specification version 0.100
grace-spec0132.pdf Draft Grace language specification
version 0.132
grace-spec0353.pdf Draft Grace language specification
version 0.353
grace-spec031303.pdf Draft Grace language specification
version 0.3.1303

6 thoughts on “Documents

  1. In grace-spec0353.pdf, page 14, the last paragraph of 7.3 says “Classes with more than one method cannot be built using the class syntax…”. I believe this is a typo, missing “factory” in front of “method”.

    Also, if the “var” keyword is used to define a variable, then “const” would be a great candidate for constants. “def” seems to be a poor choice.

  2. Hi Harry

    thanks – we’re currently working on revising that part of the spec.

    Yes we thought of “const” but the difficulty is that an object referred to by a “const” declaration can itself be mutable, which seems odd. But CONST of course comes from Pascal, which is cool…

  3. Hi James,

    Thanks for the reply. About const – it seems to be a matter of const reference vs. const value (immutable object). For example in C we can put const at different places to specify 1) a pointer always points at the same address or 2) the thing a pointer points to does not change. Reading through the spec it seems only the first case can happen in Grace so maybe using “const” is okay. The current choice of “def” is confusing because it defines a function in Python.

    Also, I found the if-elseif syntax highly unnatural. More specifically, the condition of an “elseif” is enclosed within a pair of curly brackets. This is inconsistent with the condition of an “if”.

    A little background: my wife is taking Professor Black’s class with Grace right now. I took his Smalltalk class a few years ago. I’m just trying to help my wife 🙂

  4. Harry – yes, cons ref vs cons value is just the distinction I was making.

    the point of “def” being confusing wrt Python is a good one, as is the issue with the if syntax.

  5. I was wondering do you have a more formal specification of the syntax somewhere?

  6. Hi Michiel – not sure what you mean by “more formal”. We have a more useful version of this one lurking messily on my GitHub. That runs in Kernan with parser combinators done in Grace – the productions are in a more sensible order there, and there are some tests. The problem is not necessarily formality but correctness – even in this version things are missing or wring, notably comments and layout rules.

Leave a Reply

Your email address will not be published. Required fields are marked *