Overview of Reification Process - Paramecium13/LSN GitHub Wiki

I: What Files to Reify

The reifier will reify all source files that have been modified more recently than their corresponding object file has been updated (or that do not have a corresponding object file) and all source files that depend on a file that is set to be reified. ... The reifier creates a separate task for each file that it will reify.

II: Tokenization

Tokenization in LSN is not context sensitive. The whole source file is tokenized at once...

III: Pre-Parsing

Rules...

When the reifier encounters a using statement, it check to see if the requested file is being (or has been) updated this session. If so, the task for the current file will wait until the task for the requested file has completed before loading the object file from the disk. (I know it could cache the result in memory but loading it from the disk does help test the serialization format.) Otherwise, it simply loads the requested file's object file from the disk. Either way, the reifier will mark the current file as dependent on the requested file so it knows for future sessions that when the requested file has been updated, the current file also needs to be reified again.

IV: Parsing

Once the reifier has finished pre-parsing the file, it knows the name and kind (e.g. is it a host interface? A struct?) of each type, allowing it to move into the first stage of parsing, parsing type and procedure signatures.

IV.i: Parsing Signatures

The signature of a procedure (i.e. a function, conversation, method, constructor, or event listener) consists of its name, the type, name, and order of its parameters, and, for functions and methods, its return type. The signature of a type consists of its name, the names and types of its fields, and the signatures of its methods, constructors, and events (the signatures of its event listeners are not considered part of its signature but are still parsed at this step). For the reifier to properly parse and validate these, it needs to know the name of every type.

IV.ii: Signature Validation

(might actually be done in the next stage, but logically belongs here.) Ensure that each event listener corresponds to and matches the signature of an event defined in the script class's host interface. This step occurs after parsing signatures because the reifier needs to know the signatures of the host interface's event(s).

IV.iii: Parsing Procedures

Now that the reifier knows the signatures of all the usable types and functions, it can parse and validate code in procedures. It can use this information to ensure that functions are used properly and to infer the types of local variables. ...

Procedure Rules ...

Control Structure Rules ...

Expression Rules ...