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

1. Methods. For example:
   

   method + other:Complex -> Complex Complex.new(self.real + other.real , self.imag + other.imag) method between(l:Number)and(u:Number) -> Boolean (self > l) and {self < u}

   1 2 3 4 5

   method + other:Complex -> Complex     Complex.new(self.real + other.real , self.imag + other.imag)   method between(l:Number)and(u:Number) -> Boolean     (self > l) and {self < u}

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

   6.between(5)and(9)

   1	6.between(5)and(9)

   looks a bit like a function application.

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

   const isNearby := { x:Complex -> (self-x).abs < 10 }

   1	const isNearby := { x:Complex -> (self-x).abs < 10 }

   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:

   if isNearby.apply(vertex) then { doSomething } else { doSomethingElse }

   1 2 3

   if isNearby.apply(vertex)                 then { doSomething }                 else { doSomethingElse }

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

   const Complex := class { re:Number , im:Number -&gt; const real:Number := re const imag:Number := im method + other:self.type -&gt; self.type { Complex.new(real + other.real , imag + other.imag) } method - other:self.type -&gt; self.type { Complex.new(real - other.real , imag - other.imag) } method abs -&gt; Number { (real.squared + imag.squared).sqrt } } method conj -&gt; self.type { real - imag.i }

   1 2 3 4 5 6 7 8 9 10 11

   const Complex := class { re:Number , im:Number ->         const real:Number := re         const imag:Number := im         method + other:self.type -> self.type {             Complex.new(real + other.real , imag + other.imag) }         method - other:self.type -> self.type {             Complex.new(real - other.real , imag - other.imag) }         method abs -> Number {             (real.squared + imag.squared).sqrt } }         method conj -> self.type {             real - imag.i }

   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:

   type { method real-&gt; Number method imag -&gt; Number method + other:self.type -&gt; self.type method - other:self.type -&gt; self.type method abs -&gt; Number method conj -&gt; self.type }

   1 2 3 4 5 6 7 8

   type {         method real-> Number         method imag -> Number         method + other:self.type -> self.type         method - other:self.type -> self.type         method abs -> Number         method conj -> self.type }

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

   const real:Number := re

   1	const real:Number := re

   which can be seen as a shorthand for

   method real -&gt; Number { re }

   1	method real -> Number { re }

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

   var address:String

   1	var address:String

   can be seen as a shorthand for

   method address := s:String { < <address>> := s }

   1	method address := s:String { < <address>> := s }

   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.