The spec needs to talk about abstract methods

[apblack]

Are abstract declarations required? Or are they optional? And what is the semantics of abstract?

Personally, because I want to be able to use Grace for experimental as well as production coding, I would like abstract methods to remain optional. It would be fine for a dialect to prevent the instantiation of a class that contains an abstract method, but not for the base language.

This all needs to be specified.

[kjx]

drafted https://github.com/gracelang/language/blob/portland-james/spec.md#abstract-methods

[kjx]

check that local declns of abstract methods override traits

[apblack]

We agreed to start talking about required methods, rather than abstract methods.

[kjx]

updated in spec https://github.com/gracelang/language/blob/portland-james/spec.md#required-methods

[kjx]

A related point is that requires is not the same as abstract, I think.

It's not. The main difference is that a local definition of a required method is an absence that will be filled - any inherited definition will override a required method, while a local definition of an abstract method overrides any inherited definition.

I was keen earlier to switch back to abstract but now I think required semantics are the better ones - notably because as Kim says above, a local definition of a required method is a way to ensure the request will be dispatched on self, rather than writing self.x at the call site. #145..

To simplify the syntax, I'd just make required an annotation, an annotation that should also require the method body to be empty.

[kjx]

Oh yeah my other reason for preferring required is I think it works better with fully symmetric inheritance resolution --- no implicit overriding, you have to exclude something you want to override #137

[apblack]

To simplify the syntax, I'd just make required an annotation, an annotation that should also require the method body to be empty.

It's not a simplification, but I agree that it would be an improvement — if a method with an is required annotation has no body at all. Perhaps that's what you meant by requiring the method body to be empty.

The reason that I'm suggesting this is that the old syntax, where the body is { required } does provide a body, which ought to override any existing body. Whereas a declaration with no body at all (but with the is required annotation) is a statement that someone else should provide a body.

I related question is: what error should be generated when a required method is not provided? An object composition error at object construction time, or a NoSuchMethod exception at request time?

[kjx]

if a method with an is required annotation has no body at all

I think @apblack means:

method foo is required

where I think we're nominally at now is:

method foo required

what I currently suggest is:

method foo is required { }

because the other two cases make the method syntax irregular

[kjx]

what error should be generated when a required method is not provided? An object composition error at object construction time, or a NoSuchMethod exception at request time?

these should also be consistent. I assume @apblack wants a construction time error; I would prefer a dynamic error, or just not specifying it - if only because I could kid myself that in some non-existent dynamic IDE you should be able to run the code, drop into the debugger, and then supply the necessary error then.

The key issue here is: what invariants can the compiler (or checkers) assume about Grace programs.
Should the interpreter / code-generator ever have to see a "naked" required method, on an unresolved internal request. Are just types gradual, or program structures too?

We all seem to agree that nothing should see a syntactically incorrect methods. I take this as a matter of tradition.

[apblack]

What we are at now is

method foo { required }

because that's the same syntax as a normal declaration. What I' m proposing is that the syntax should be different from a normal declaration, because the semantics is also different.

[kjx]

Hmm the spec has one example

method id⟦T⟧ is required  { }

and one sentence that says the body is "required" which I thought meant required not { required }. The body being request for required is clearly not the right thing.

(Of course, if we removed all braces execpt for blocks (everything else just layout) then the deign issue goes away.)

[apblack]

You are right about that example; it's another one of the inconsistencies that we need to fix. The spec also says that required is a reserved word, whereas making it an annotation would mean that it is an identifier.

The Spec also says that

a required local method overrides an inherited method in the normal way

That's what we are discussing changing here, right?

I assume @apblack wants a construction time error

What I want is for the spec to explain the difference between saying nothing at all about foo and saying that method foo is required. One difference is that self.foo can be abbreviated as foo. Is that the only difference?

[kjx]

What I want is for the spec to explain the difference between saying nothing at all about foo and saying that method foo is required.

well that's probably a good idea :-)

One difference is that self.foo can be abbreviated as foo. Is that the only difference?

I don't know - someone needs to write down the whole semantics of inheritance --- including required, overrides, who knows what else --- in a comprehensible way. I've only got halfway there.

Depends on details of the semantics. I could imagine a world where you weren't allowed to write self.foo unless you had a local definition of foo or an inherited definition - you couldn't go "off piste".
If superclasses all have to be manifest, and you're eager about composition errors, that makes good sense to me.

It will I imagine do something about types, at least static types.
We carefully (so far) say almost nothing about typing across inheritance.