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.

Leave a Reply

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