There are no checks for subnode types

[exfret]

We have constructs like...

@dataclass
class If(Map):
    spec: Tags = (
        Tag("if", Expression),
        Tag("then", Sequence),
        Tag("else", Sequence, optional=True),
    )

But I don't see a specification that the "then" tag actually corresponds to a Content node, not just a Sequence node. I'm leaving it as is in case there is a technical reason that prevents this from being easily implementable yet, but I also want to leave this as an issue to remind ourselves to fix this in the future.

We need this feature in order to properly type check a user's program to make sure the interpreter doesn't come across unforeseen tags, or worse, expect a tag where there is none. Informing the user when the story is parsed rather than when they randomly come across this point in their program is of course a much better experience for them.

[maxsu]

This is a good point. A more correct definition is:

@dataclass
class If(Map):
    spec: Tags = (
        Tag("if", Expression),
        Tag("then", Content),
        Tag("else", Content, optional=True),
    )

This requires Content and StoryCommand, which should look something like this:

class StoryCommand(Disjunct):
    types = [If, Choice, Goto, Gosub ....]

class Content(Sequence):
    list_of = StoryCommand

The depends on:

1. Type checked initializers for sequence nodes
2. Disjunct nodes

I expect we will have these both soon. Lets keep this issue open until we confirm this.

[maxsu]

Note, this issue may invoke the forward reference problem:

1. StoryCommand requires forward references/string references if command nodes are defined afterwards
2. If that's the case, Disjunct needs to dereference strings and ForwardReferences

Two mititagations of this issue:

1. Define command nodes prior to StoryCommand
2. Write an utility function that dereferences type references:
   • string references
   • ForwardReferences

[exfret]

Yes, I suspect us running into circular dependency problems. We'll have to discuss whether to use the ForwardReferences or string references at meeting. I certainly don't want to use the current way of mixing them! I want to also say after some of my own research I feel more appreciation for this problem since it really does appear that python doesn't have a good solution. I am more in favor of ForwardReferences but you mentioned python is moving toward string references in the future, which would definitely sway me toward preferring those if so.