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 |
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.
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…
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 🙂
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.
I was wondering do you have a more formal specification of the syntax somewhere?
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.