On Tue, 26 Oct 1999, Chip Morningstar wrote:
> And Bill is right! But we can still use MarkM's form consistently, merely by
> some verbal slight of hand. According to me, MarkM's form:
>
> define square(x : int) : int { x * x }
>
> says: "x is an int" and "square(x : int) reveals an int". Voila, the syntax
> MarkM likes with the consistency that Bill (and I) like.
[+] Yup, this is the way i like to think of it, and it is what i had in mind when writing it out like this. Note also that
define square(x : int) : int {
...pages of code...
}
admits the possibility of extracting an "interface spec" just by removing anything at the appropriate level of braces:
define square(x : int) : int
define point {
to getX : int
to getY : int
}
etc.
So, when informally discussing APIs, they can be presented in a familiar fashion consistent with the grammar already used in E.
I suppose that, as well as automatically generating an overview from an implementation in this way, it might also serve some purpose to be able to parse these kinds of specifications (the grammar would be pretty easy, right?). Then one could take a parse tree for an interface spec and present a parse tree for an object to be mechanically verified as a rudimentary sanity check.
"This code is better than any code that doesn't work has any right to be."