definition of manifest

[kjx]

We need to define what it means to be manifest (aka static).

Types and parent objects must be manifest!

There is a wrong definition here:

https://docs.google.com/document/d/1BMI2lLyPmRHmP2W7tXKY7mB6Lr56dX-THsGvO2cKWXg/edit#

[kjx]

(derived from the Pomona draft above and emails w/ Michael)

What is required to be manifest?

The idea of "manifest" is that enough of the result of an expression can be determined at "manifest time" - i.e. when the module are loaded but before any code starts running.

• superclasses/supertrait must be manifest, enough to determine the "shape" of the object inherited from
• types must be manifest, enough to determine the actual type
• annotations must be manifest, enough to determine the actual annotation

What makes something manifest?

• literals are manifest
  • blocks and string literals with substitutions are manifest if all their expressions are manifest
• imported nicknames are manifest
• implicit requests or outer requests resolving to local definitions in surrounding method scopes, the module, or the dialect, are manifest
• an explicit request is manifest if the receiver and all arguments are manifest, and if they resolve to a manifest method (probably a method that uniquely tail-returns a manifest expression)

manifest and inheritance

As Michael wrote: "Anything that can be inherited is an unsafe leftmost (implicit or explicit) receiver, including all surrounding classes and traits."

The biggest question is whether we need this restriction or not - do we want to add in:

• self is manifest
• implicit self requests are manifest if they resolve to manifest methods

Alternatively we could undo some of the damage by adding in:

• implicit self requests are manifest if they resolve to final manifest methods/declarations
• then e.g. we could make class and type shortcuts build things that are manifest..

[kjx]

Note that this manifestness issue is only about things declared within traits and classes (objects), not types. We could have types being overriden within objects (although we'd have to recheck all supertraits/classes for each object see e.g. #72) and still NOT have types being overriden without types

[kjx]

drafted based on cleaned up version of what I wrote above - https://github.com/gracelang/language/blob/portland-james/spec.md#manifest-expressions

[kjx]

The definition in the spec says that self, outer, or any named method request resolved through a non-method scope are not manifest. So: should this be legal?

class A {
   class B { }
   class C { inherit B } 
}

if the answer is no, then any manifest declaration (class, trait, type, annotation) can only makes sense at the top level. (local classes are OK I guess, but they can only be instantiated, never inherited from).

If we want the answer to be yes then e.g. we either need a "final" annotation to stop things being overridden or excluded; probably make all classes and traits final; or have a version of manifest where everything is computed per-concrete-subclass class, rather than per-class definition. at which point many of these problems go away, at a cost of making checking harder (I hope) or impossible.

[kjx]

Note that arguments to the things in use or inherit clauses shouldn't be manifest.

[apblack]

Note also that you can't inherit from a potentially-overridable class. The spec needs to make this clear.

[kjx]

about to be updated here - https://github.com/gracelang/language/blob/portland-james/spec.md#manifest-expressions