Grace at SPLASH last week of October

October 15th, 2013

The Grace team will be well represented at SPLASH in Indianapolis from October 27 to October 31.  The main Grace event will be a tutorial from 1:30 p.m. to 5 p.m. in the Discovery Room at the conference site, the Indianapolis Hyatt Regency.

Members of the Grace team will also be involved in other presentations.  Kim Bruce will be giving an invited talk on the history of the FOOL workshop at the FOOL workshop (of course) on Sunday at 1 p.m.  He will also be giving a CS colloquium talk on Grace at Indiana University the Friday after SPLASH.  James Noble will be taking the counterpoint position in a debate titled “Should Software Conferences Respect Software?” Tuesday at 1:30 p.m.  He will also be giving a tutorial on Agile Studies of Agile Methods Thursday morning from 10:30 to noon.  Andrew Black will be chairing the OOPSLA Thursday morning session on Distribution and Parallelism.    While Kim is giving his talk at Indiana U on Friday, Andrew will be giving a similar talk on Grace at Cornell.  Michael Homer and Tim Jones will also be attending the SPLASH meeting.

Feel free to track any of us down for a discussion of the current state of Grace.

Grace is growing!

September 23rd, 2013

You wouldn’t know it by reading this Blog, but this has been an active summer in Gracelang. In fact, we’ve been so busy coding and editing the specification — and having fun with Grace — that we haven’t posed anything here.

Amongst other things, I’ve been working on a usable, if simple, version of GUnit — the ubiquitous unit testing framework — for Grace. It basically does what xUnit does in any other language: it let’s you write a bunch of test methods that contain assertions, and then runs them all, notifying you only of errors and failures. Grace’s blocks and exception handling find their niche here. For example, here is a test for lists:


import "GUnit" as GU
import "collections" as coll
def aList = coll.aList

class aListTest.forMethod(m) {
    inherits GU.aTestCase.forMethod(m)

    def oneToFive = aList.with(1, 2, 3, 4, 5)
    def evens = aList.with(2, 4, 6, 8)
    def empty = aList.empty
    method testFirst {
        assert{empty.first} shouldRaise (coll.boundsError)
        assert(evens.first) shouldBe (2)
        assert(oneToFive.first) shouldBe (1)
    }
}

def listTests = GU.aTestSuite.fromTestMethodsInClass(aListTest)
listTests.runAndPrintResults

The boilerplate is pretty standard for any xUnit. The only thing that needs explanation is the inherits clause: as in most implementations of xUnit, tests must be methods of a class that inherits from a framework class, which in Grace is called aTestCase.

Anyway, the nice thing is the first assertion:

assert{empty.first} shouldRaise (coll.boundsError)

Notice that the first argument is a block: it is evaluated as part of the action of the assert method, which enables the assert method to trap any exception that is raised.
So we are able to test that asking for the first element of an empty list does indeed raise the right exception — and then go on to run more tests.

The above code, when run, outputs:

1 run, 0 failed, 0 errors

and nothing else: passing tests are quiet.

If you would like to see all of the code, just drop us an email, and we will give you access to our subversion repository.

Three Talks on Grace

May 1st, 2013

In the next couple of weeks, there are three talks on Grace.

First, a virtual talk — a video Michael Homer’s talk at last year’s Strange Loop is now online

Second, this coming Tuesday, James Noble is talking about Grace in Vancouver at The University of British Columbia — 4pm Tuesday 7 May.

Third, as part of ICSE, James will be talking specifically about Can an Introductory Programming Language Support the Teaching of Software Engineering? at the CSEET conference, at 3pm on the 21st of May.

James is travelling to Vancouver, Pomona, then up to the Bay Area and San Francisco between now and then, if people would like to talk about Grace.

At SIGCSE

March 6th, 2013

Andrew, James, and I are at SIGCSE through Saturday, March 9. We are giving a talk on Grace on Thursday at 1:45 p.m. and would be pleased to talk to anyone interested in Grace afterward.

Kim Bruce

Laissez-parlent l’Eiffel!

January 28th, 2013

The Eiffel language has many features that support software engineering. One of these is a loop statement that allows programmers to specify loop variants and invariants. We hope Grace may also be used to teach about invariants, so it would be useful to write Eiffel-style loops in Grace:

def letters = "ABCDE"
var i : Number := 1

loop { 
    print(letters[i])
    i := i+1
  }
  invariant { i < = (letters.size + 1) }
  until { i > letters.size }
  variant { letters.size - i + 1 }

The key here is the loop/invariant/until/variant control structure — which in Grace is just a method that takes Blocks as arguments. Here’s a simple implementation of this method:

method loop (body) 
       invariant (invariant)
       until (condition) 
       variant (variant) { 

   if (!invariant.apply) then {error "Loop invariant failed before loop"
                               return "ERROR"}
   var variantValue := variant.apply
   while {!condition.apply} do {
       body.apply
        if (!invariant.apply) then {error "Loop invariant failed in loop"
                                    return "ERROR"}
        def variantValue' = variant.apply
        if (variantValue' < 0) then {error "Loop variant has gone negative"
                                     return "ERROR"}
        if ((variantValue - variantValue') < 1) 
                    then {error "Loop variant decreased by less than one"
                          return "ERROR"}
        variantValue := variantValue'                  
   }
}

Of course, in a practical Grace system, this method, like other control structures, would be defined in the system or dialect library. The key features that make this possible are not themselves complex: multi-part method names support defining every control structure (syntatically and semantically) as a method request, and then using blocks to pass code into those methods.