Package code.loader

Loader Package contains classes that load modules on demand.

See:
Description

Interface Summary

ModuleLoader

The interface implemented by all module loaders.

Class Summary

ClassModuleLoader	The interface implemented by all module loaders.
CurryModulePath	This class encapsulates PATHS where source files can be located.
LoadManager	LoadManager loads a module and its imported modules on demand.
ModuleLoaderFactory	ModuleLoaderFactory instantiates a ModuleLoader based upon the type of the module file to be loaded (currently one of .class/.txt/.xml) This class is responsible for Creating suitable ModuleLoader based upon module filename's extention.
TxtXMLModuleLoader	The interface implemented by all module loaders.

Package code.loader Description

Loader Package contains classes that load modules on demand.

Overview

1. CurryModulePath is responsible for maintaining a list of paths where curry files are stored. When a module is requested to be loaded, This list of paths is searched to locate the .txt file for the requested module. If the module is found exactly once in all the specified paths, then and then only it is loaded.
2. Command establishes the CurryModulePath by either loading it from a ConfigFile or by appending specific paths to the existing paths.
3. Command invokes LoadManager with request to load a some module.
4. LoadManager is responsible for loading a module on demand from some file in the CurryModulePath into the FLVM.
5. LoadManager interfaces with with ModParser and obtains parsed module information from it.
6. The responsibility of ModParserFactory is to select and return either TXT or XML parser to LoadManager. That specific parser does the actual task of parsing the module file.
7. TxtParser is a CUP JLEX based parser that parses TXT files containing module.
8. XMLParser parses XML files containing module. this is obsolete.
9. the package except contains exceptions that may be thrown by the classes in this package.

Details

The following features are implemented.

CurryModulePath Related

1. Any legal path (from the Operating System perspective) can be specified as a CurryModulePath.
2. A user should be able to specify a colon separated list of paths to be appended to the existing CurryModulePath.
3. Requesting to add a nonexisting path to CurryModulePath, should report an error on stderr.
4. Requesting to add a path that is not a readable directory to CurryModulePath, should report an error on stderr.

Planned Enhancements

These enhancements are either planned or being reviewed (as of 9/22/04). Higher priority items appear earlier in the list.

CurryModulePath Related

1. Almost DONE: Need tests to test the correct functioning of CurryModulePath. These test directories, modules should be placed in code.test.currypath-dir directory. The test itself should be called test.currypath. What should go in the currypath-dir? Need more thought. Any new development ideally should be preceeded with creating test case(s).
2. DONE: Need a mechanism to display the current CurryModulePath from the command prompt. implement this with a command :path (without any arguments) that displays the CurryModulePath. This is a required feature for automatic testing.
3. DONE: Request to add a null path to CurryModulePath, should report an error on stderr. Currently if you just type ":path" (without the quotes) at the FLVM command prompt, it causes an exception that crashes the FLVM. The problem is in how Command implements the :path command. DONE: Similarly the command ":paths" crashes the FLVM, again Command.java has the bug. This item was given a higher priority, since part of it (the part about :paths command) can be addressed by satisfying the previous item.
4. DONE: Problem of path aliases:Since paths can be relative and paths can contain .. (the parent), it is possible that two paths actually point to the same location in the filesystem. This implies that a module in such a location is perceived as duplicate and hence not loaded. Need some mechanism to detect these multiple aliases to the same location in the file system and eliminate the later of the two.
   • Proposed Solution: When a path is requested to be added to the CurryModulePath, its AbsolutePath should be added to the search list, if it has not been already added. This eliminates the possibility that 2 paths alias to the same location in the file system.
5. DONE: Absolute Paths are not relative. It is possible that a user may request to add . (the current directory) to the CurryModulePath. As per the solution outlined in the previous item, this will get replaced by the absolute path. Then if the user changes (or wishes to change) the current directory, the CurryModulePath will not reference the new current directory. This is undesirable.
   • Solution 0Add the absolute path of the current dir to the paths on initialization. this is done in the $FLVMHOME/bin/flvm script
   • Solution 1 Make . a special member of the CurryModulePath. An attempt to add . to the CurryModulePath should set up a flag, but not add the dir to the list of search paths. At load time, if a module cannot be located in the list of search paths, Then if the flag is set, the . dir should be scanned for the presence of the requested module. This eliminates the possibility that some explicitly specified path is the same as . and hence the module is preceived as duplicate and hence loading is abandoned.
   • Solution 2 For each path that is requested to be appended to the CurryModulePath, maintain both the "requested path" and "its abolute path". The CurryModulePath also maintains the "current working directory". Before fulfilling any request(setConfigFile, append and getFilePath), it checks if the current working directory has changed and if so recomputes the absolute paths. Only after this it responds to the requests. Since this solution maintains the requested path, it will retain the semantics of .. (the parent) in the CurryModulePath. Since it will maintain the absolute paths, it will address the problem of path aliases.
6. DONE: If after adding a path to the CurryModulePath, it cannot be "used" for searching for any reason, then this should be reported on stderr, and the search should continue with the remaining search paths.
7. DONE: Need ability to remove a specific path from the CurryModulePath. This can be used to test one version, remove the path, add another path and test a new version without encountering duplicate module exception. The implementation of this feature is dependent on how the "problem of path aliases" and "absolute paths are not relative" implemented. the command ":path - pathname" should remove the absolute path of the pathname if present
8. DONE: Encapsulate the behaviour of AbsolutePath java method in our NormalizePath method.
9. DONE: Optimize CurryModulePath.getFilePath by eliminating the enumeration of all files in all dirs in the CurryModulePath.

LoadManager Related

1. It should be possible to request the load of a specific .txt file. This feature should make it possible to Load a specified file (which contains a curry module) ignoring the contents of CurryModulePath. The filename will be specified by either an absolute path or a relative path. The "relative path" is relative to the working directory of the FLVM's JVM. Currently the LoadManager can only load a module specified by its modulename. Implementing this enhancement requires a redistribution and/or redesign of the responsibilities of the methods load, load_r and read in LoadManager.
2. Need to check that the module being requested to be loaded is not a "standard" or "builtin" module.
3. Need to crystallize the "RESET" algorithm as a separate method.
4. Need to factorize activities of load, load_r, read so that they can be better composed.