Classes

Classes in Grace 0.6 are simpler than they used to be. A class declaration creates a “factory method”, that is, a method that returns a new object. Writing:

declares a factory method that returns an object with readable fields
colour and name, a variable that counts the number of mice the cat has
eaten, and two methods to eat a mouse and to miaow. Other than
Grace’s multi-part method names, this syntax is pretty much the same,
say, as Python or Scala, and with pretty much the same semantics.

To create objects from  the class, we just request the method directly:

Note that we don’t need parens around the arguments, because they are already delimited by quotes.  If the arguments had been expressions, then we would need parens.

More advanced programmer might want to know that classes aren’t primitive.  The cat()colour() class declaration above is pretty much equivalent to the following method declaration:


The key difference between this design and earlier and the earliest designs are that in the earlier designs, class declarations made objects that had a single factory method.  The main reason for the change is that the new design is simpler.  Most Grace programs did not use the actual class object; they simply requested the factory method. Programmers can always explicitly make an object if they need one, by putting the class declaration inside an object declaration.  In particular, classes at the top-level of a module are already inside an object: the module object.  There is often no need for another one.

One situation in which an enclosing object is useful is when there are several alternative ways to construct instances.  For example, a graphics library might provide methods r()g()b() and h()s()l() for constructing new colors, as well as a small selection of constants yellow, purple, brown, etc. It makes sense to make all of these methods on a colour object; r()g()b() might be a class, while h()s()l() and the named colors might make requests on r()g()b() with appropriately calculated arguments. Like this:

The old “dotted class” syntax did not support such a use, because the automatically declared object could have only a single factory method.

Ever Onward!

EVER ONWARD — EVER ONWARD!
That’s the spirit that has brought us fame!
We’re big, but bigger we will be
We can’t fail for all can see
That to serve humanity has been our aim!
Our products now are known, in every zone,
Our reputation sparkles like a gem!
We’ve fought our way through — and new
Fields we’re sure to conquer too
For the EVER ONWARD I.B.M.

Keeping up the blog has not been one of our strong points, but we have been making some progress in the last few months. We’ve been working our way through a review of Grace’s design and specification, with a few nontrivial changes:

  • Classes create methods, rather than objects, so no longer have “dots” in their name
  • Calling methods in superclasses relies on aliasing, not “super requests”
  • Traits support stateless reusable components
  • A simpler inheritance model that supports classes inheriting from multiple traits
  • Replacing variadic methods with primitive sequences

We expect to describe these changes in a few blog posts soon, as we are working through a thoroughly revised specification.  We plan to release the specification and implementations around the end of February,  for feedback from the community. We then plan to hold workshops (as we did in 2011) to go over what we hope will get getting close to a 1.0 version of the language design. So: Onward! Ever Onward!

A Graceful Summer

I (Andrew Black) have spent a large part of the summer teaching an introductory programming course to a small-ish group of post-bacc students. This was part of PSU’s “New Beginnings” program, which is designed to prepare students who have a bachelor’s degree in some other subject (history, accounting, chemistry, soil science, music …) to enter into our MS program. New Beginnings is intended to be very intensive: students spend 16 hours a week in the classroom, split between two subjects (discrete math and programming, in the case of this summer), plus another 8 hours in labs, plus homework.

My goal for the summer was to lead the students to roughly to the point that an undergraduate would reach after our three-course introductory programming sequence. This turned out to be a stretch goal for those who had never programmed before, but quite reasonable for those students who had a little background.

I never cease to be amazed at the variety of learning styles, even in a cohort of just 11 students. Some are happy to experiment, while other would have really benefited from a Graceful Data Structures book for the latter part of the course. We used Kalicharan’s excellent “Data Structures in C”, and my original plan was to just re-write the programs in Grace. That didn’t actually work out, because a C-based text has to emphasize things that are irrelevant in Grace, and a Grace text will need to talk about stuff that is irrelevant in C — primarily object structure. Still, the basic programs are parallel; I invite you to take a look at binary trees.

Grace at ECOOP

The European Conference on Object-Oriented Programming starts next month, and, once again Grace people will be there.

 

Andrew Black Tim Jones Kim Bruce

 

On Sunday, the first workshop day, Andrew Black will discuss
The Expression Problem, Gracefully
in the MASPEGHI workshop.

On Wednesday, the first day of the full conference, Tim Jones will present the technical paper Brand Objects for Nominal Typing by Tim Jones et al which describes how Grace can be extended to support nominal typing. Tim is also charing the ECOOP Doctoral Symposium this year.

On Thursday, Kim Bruce is presenting the talk Graceful Programming — Teaching Introductory Programming as part of the ECOOP Summer School.

Update:  Materials from the tutorial, including slides, documentation, sample programs, and homework exercises can be found at http://www.cs.pomona.edu/~kim/GraceStuff/GraceTutorial.html