Declarations

[lucaswerkmeister]

My current plan for the Declaration type hierarchy (pseudo syntax):

• Declaration(Identifier, Annotations)
  • TypeDeclaration(UIdentifier, TypeParameters?, TypeConstraint[])
    • ClassOrInterface(CaseTypes?, SatisfiedTypes?)
      • AnyClass(Parameters, ExtendedType?)
        • ClassDefinition(ClassBody)
        • ClassAlias(ClassSpecifier)
      • AnyInterface
        • InterfaceDefinition(InterfaceBody)
        • InterfaceAlias(TypeSpecifier)
    • TypeAlias(TypeSpecifier)
  • TypedDeclaration(LIdentifier, Type, AnySpecifier|Block? definition)
    • AnyValue
      • ValueDeclaration { actual Null definition = null; }
      • ValueDefinition(AnySpecifier definition)
      • ValueGetterDefinition(Block definition)
    • AnyFunction(TypeParameters, [Parameters+], TypeConstraint[])
      • FunctionDeclaration { actual Null definition = null; }
      • FunctionDefinition(Block definition)
      • FunctionShortcutDefinition(LazySpecifier definition)
  • ValueSetterDefinition(Block|LazySpecifier definition) – but see Should we have several classes for value setter definitions? #55
  • ObjectDefinition(ClassBody, ExtendedType?, SatisfiedTypes?)
  • Variable? That’s the compiler node for the e in for (e in thingy) and if (exists e = foo). Not at all sure about that.
  • TypeParameterDeclaration – I don’t see why this is a subclass of Declaration in the compiler, clearly it can’t be an element of a body / block.

Auxiliary:

• Body(<Declaration|Statement>[] content)
  • Block
  • InterfaceBody(Declaration[] content)
  • ClassBody

(I’ll be editing this comment as the plan for the class hierarchy changes; you can track these changes in this gist, if you’re interested.)

[lucaswerkmeister]

Actually… instead of

• AttributeDeclaration
  • AttributeDefinition

perhaps it would make more sense to have

• AnyAttribute
  • AttributeDeclaration
  • AttributeDefinition

possibly with AttributeDefinition being abstract and two case types for lazy specifier / block?

Justification: while semantically, an attribute definition also declares the attribute, syntactically they’re different because a declaration without definition must be terminated by a semicolon.
It also feels more consistent with AnyClass and AnyInterface.

EDIT: And this of course also applies to functions.

[lucaswerkmeister]

Actually, the “syntactically different ‘cause semicolon-terminated” argument means of course that there should be different classes for attributes with blocks and with specifiers ;)

In fact, we could say that a declaration and a definition with specifier could have the same class, since they’re both semicolon-terminated – i. e., AttributeDeclaration(AnySpecifier? definition). This is how the compiler does it, and I now see how it can make sense. However, I don’t agree with it.

I would prefer three different classes for declaration, definition with specifier, and definition with block. But perhaps we don’t necessarily need a superclass for the two declaration classes. Something like this?

• AnyAttribute
  • AttributeDeclaration
  • AttributeDefinition
  • AttributeGetterDefinition

We’d then need something different for functions, because a function with a block is of course not a getter :)

• AnyFunction
  • FunctionDeclaration
  • FunctionDefinition
  • FunctionShortcutDefinition?

[lucaswerkmeister]

Should an ObjectDeclaration be a TypedDeclaration? After all, attribute declarations may also be missing their type (type inference)…

[lucaswerkmeister]

Yeah, perhaps TypedDeclaration.type should be Type|Modifier. (Or we introduce TypeModifier for all modifiers that can look like types.)

[lucaswerkmeister]

Ah, I forgot about one thing:

shared Value sum<Value>(values)
        given Value satisfies Summable<Value> {
    Value+ values;
    …
}

This one’s a bit weird. Value+ is not a proper type, so perhaps it’s not a typed declaration? But on the other hand, it’s definitely an attribute declaration – more so than variable value sum = first; in the function block, which doesn’t really define any attribute, but syntactically is an AttributeDefinition.

[gavinking]

It is an ordinary value declaration, according to the spec.

[gavinking]

By the way, you should be calling values and functions Value and Function, not Attribute and Method. That is the nomenclature that is standardized by the spec. The typechecker naming is legacy.

[lucaswerkmeister]

Alright… with Value, that makes more sense. (I already changed Method to Function.)

[lucaswerkmeister]

Perhaps it should be called TypeDefinition rather than TypeDeclaration? There’s always a definition of the class or interface.

[lucaswerkmeister]

What do we do about dynamic interfaces?

1. Same class, Boolean isDynamic? I don’t think we represent syntactical distinctions via Booleans elsewhere, though.
2. Same class, InterfaceModifier|DynamicModifier modifier? ‘interface’ doesn’t really feel like the other modifiers, though.
3. Different classes, superclass AnyInterfaceDefinition? A lot of Any (with AnyInterface as well), but probably tolerable.
4. Different classes, superclass AnyInterface (so on the same level as InterfaceAlias)? But these interfaces have a lot in common (syntactically they’re almost identical).

Leaning towards 3, I think. A bit more inheritance-heavy, but AST creators don’t have to worry about any abstract classes, and AST consumers can choose if they care about the distinction or not.

[lucaswerkmeister]

Actually, wrt dynamic interfaces I’m leaning more towards 2 now, I think. But still open for feedback!

Meanwhile, I’m wondering if the alias type should perhaps be suffixed -AliasDeclaration rather than just -Alias? The spec has TypeAliasDeclaration (the other aliases have no rules of their own), as has the RedHat compiler.

[lucaswerkmeister]

Oh shit, we already have TypeAlias (import aliases). So I guess I’ll have to make that TypeAliasDeclaration, and update ClassAlias to match it :-(

[lucaswerkmeister]

OTOH, perhaps Alias, TypeAlias and FunctionValueAlias should be renamed to -ImportAlias, to avoid some confusion.

[lucaswerkmeister]

Well, even with the Alias rename, it might still be best to have -AliasDeclaration for the other aliases. (Or are they definitions?)

[lucaswerkmeister]

(For the interface design, see the dedicated issue #57.)

[lucaswerkmeister]

With type aliases having been added in 43b1e59, we’re now done with this issue!