Modularity

From CoreASM Wiki

Approaches Considered

Modules Parsed Separately

Each module file is parsed by the Modularity Plugin and then functions, universes, and rules are provided to the engine through the standard process. Problems:

• The format of the modules should follow the standard format of CoreASM specifications (i.e., "CoreASM" header, init rule, etc.)
• Modularity Plugin has to offer the list of plugins used by the module to the engine before the engine creates the parser.
• Modularity is limited to functions, universes, and rules

Injecting Lines

Each module file is filtered (to get rid of the header and stuff) and then the lines are injected to the main CoreASM spec. Problems:

• Screws up line numbering
• CoreASM spec structure (the order of the declarations) has to be flexible

Benefits:

• Easier to implement, only if the line numbering problem can be solved
• Less restrictive