LSN Files

All LSN code exists in LSN files. LSN source code, which cannot be executed as it is, is in LSN source files. LSN object code, which can be executed, is in LSN object files. For each LSN source file, the reifier creates a corresponding object file.

For a program to execute LSN code, it must load the object file containing that code. This LSN code the program wants to run does not have to be the entry point of the file; indeed LSN files cannot even have a designated entry point. Any function or event listener can be used as an entry point. Actually, event listeners can only serve as entry points; they cannot be directly called by other LSN code.

Contents

An LSN file can contain functions, struct types, record types, host interfaces, and script classes.

To use a type or function that is defined in another file, the using file must be linked to the defining file.

Linking

Linking is used to access types and functions defined in another file. LSN object files are linked dynamically at load time; LSN files are not linked together to produce some output file. However, all the types and functions in the file that is being linked to must be available to the reifier at reification time so it can ensure that they exist and are being used correctly.

A file can be dynamically linked by using the '#using' directive followed by the name of the file to link. This tells the interpreter to load the file when the current file is loaded. The file must already exist so that the reifier can verify that the types and/or functions it contains are used correctly.

Circular dependencies between LSN files are not allowed! For example, if file 'a' depends on file 'b' (i.e. has a #using directive for it), then neither file 'b' nor any file that file 'b' depends on may depend on file 'a' or any file that depends on file 'a'. In other words, the graph of file dependencies must be a directed acyclic graph.

Partial Files

throw new NotImplementedException();