Grace Workshop San Jose, Sat 4 June

Here are the details for the Grace Workshop on Saturday 4 June:

Four Points by Sheraton San Jose
211 S First Street
San Jose, CA 95113
United States of America
Phone: 1 (408) 282-8800

We’ll aim to start around 10am.

If you feel that you will be able to come, and have not yet emailed Andrew or James your name, please do so when you get a chance.

Grace Workshops

We are planning to hold more three Grace workshops in the rest of this year:

  • Saturday 4th June – San Jose (before PLDI)
  • Saturday 30 July – Lancaster (after ECOOP)
  • Late October – Portland (around SPLASH/OOPSLA)

These workshops are to report progress on the design, to discuss challenges, and hopefully to involve others to the project.

So, if you’re interested in the Grace project, and would like to come to one of these workshops, the please let us know by emailing James, kjx@ecs.vuw.ac.nz.

Declaring Things with Parameters

As Kim recently pointed out, we have several inconsistent ways of
declaring “things with parameters”:

  1. Methods. For example:

    Methods are not first class. Still, a typical method request,

    looks a bit like a function application.

  1. Blocks, which are first-class values. For example:

    Blocks denote objects, with a single method named apply that takes as many arguments as the block has parameters, in this case, exactly one. Note that the self inside that above block denotes not the block object, but the object in which the block itself lives.

    This block would be used as follows:

  1. Class constructors, which are also first-class values.

    Class constructors denote objects too; these objects have a single method named new that takes as many arguments as the class constructor has parameters. You can see examples of the application of the resulting class in the bodies of the methods + and -. Note that the self inside the above class constructor denotes not the class object that it constructs, but the object that will be created when the method new is invoked on the class. Note that we may want, in addition to the above, for this form to also bind Complex to a type that looks like the body of the class constructor:

  1. Fields, which are really a shorthand for method declarations. For example, in the above object constructor, we have

    which can be seen as a shorthand for

    But, you say, constant reader methods don’t have parameters. Quite true. However, variable writer methods do, and

    can be seen as a shorthand for

    which does have a parameter.

Notational Differences

There are several dimensions of difference in the above four notations:

  1. nominal versus anonymous. Method and field declarations always construct named entities; block and class constructors always create anonymous entities, which are typically returned as answers or bound to names in a separate step;
  2. parameter placement – the nominal forms put the parameters with the name; the anonymous forms put them after an invisible lambda;
  3. the meaning of self; and
  4. the presence or absence of a keyword; blocks alone have no keyword.

Open Questions

The elephant underlying this post is the question: should we abolish one or more of these forms, or seek to unify them? At present Andrew proposes that the answer to both of these questions should be no. We introduced each one for a good reason; I believe that we need them all. And I don’t think that a uniform syntax will make programs more readable; Beta did that, and I don’t think that it works.

Still, I may be wrong, and I may change my mind. Or we may want to discuss this further. This post provides a place for that discussion.