[Grace-core] RFC: Compile-time constants

[Timothy Jones]

On 02/05, Michael Homer wrote:
> It seems like these are what you want for inheritance ("definitively
> static") too, so it's worth factoring in what that needs as well.

I disagree (with the spec, I suppose) that this should even be a thing. An
invalid inheritance chain should be a runtime error. If a dialect wants to check
this (as the type checking dialect should) then it can, and in that context
"definitively static" means whatever the dialect wants it to mean (presumably
whether it can see the definition site).

A dialect can still try and reason about anything in the code that it wants.
'let' and 'static' are about how to deal with type-like things that need to work
like static values and then translate into the runtime.

> What is the semantics of "a method that is annotated as static"? Notably:
> - What relation does it have to what we might call "final"?

It's a more specific form: every static method is final, but they have even more
restrictions.

> - What is it allowed to refer to?

Other static declarations (and I guess local variables as well, though those
could be declared with let too), and requests to static methods on them.

> - Can it be inherited?

No, for similar reasons as 'let'.

> - What is it allowed to return?

A request for another static value, or a fresh object (like a brand -- this is
why you can annotate a class as static). Also, maybe a type literal? I don't see
why you couldn't just use a normal declaration in that case though, though
arguably 'let' is just sugar for a static method:

  let Name<T*> = Expr
    ==>
  method Name<T*> is static { Expr }

> - What arguments can be given to it?

Other static values. This is a murky issue, because that value might not be
fully initialised at runtime while the hoisting is happening (you have a similar
problem when just referring to other values as well). It might be the case that
attempting to request a non-static method on an object in a static method always
causes an 'undefined' exception (similar to referencing variables down the
inheritance chain) -- so statically known objects can be stored for later, but
not 'used' during the hoisting phase.

I think these restrictions make sense: you shouldn't need to 'do' anything in a
static method, just build an object that might include other definitions. The
methods in the object you build can do whatever they want if they're not marked
static, as they'll only be used after the hoisting is over (so you can write
whatever behaviour you want in the match method, for example).

-- 
Tim