Anwar,
Appreciate the research! Based on your information, and to
keep things correct and simple, I would propose the following:
- module importing and lookup facilities are
implemented by the interpreter (not Core)
and cannot be changed (C++ model)
- imported modules enter name space (Java model)
- ambiguities lead to interpretation-time errors
- every module documents the URI it wants to be
known as; URI scheme does not, by default,
imply access method to the module
- interpreters MAY support loading of raw P files
- URIs for loading of raw P files are
implementation-dependent and a "file" URI scheme is
used as an example for local files
- the Core module and the Services module are always
available as if they were autoloaded internally before
user code evaluation
For example, all of the import statements below pollute global name
space, but the first two provide a way for a programmer to resolve
conflicts, if any.
/* import HTTP module */
Http := import "http://ietf.org/opes/rules/p/HTTP";;
/* import a local file */
MyStuff := import "file:/usr/local/myrules.p";
/* import a local file without naming it */
import "file:/usr/local/globalrules.p";
Please let me know if there are any better ideas or objections. We
still need to investigate what HTTP module URI should look like from
IETF point of view. The same info is needed for OCP: we need URIs to
identify message parts and other negotiated features.
Thanks,
Alex.
On Fri, 19 Sep 2003, Anwar M. Haneef wrote:
In case of Java, the virtual machine is launched (equivalent to our
intepretor) is launched with a default Class Loader, System Class
Loader. This Class Loader is responsible for loading all the classes
to run the program. This usually picks up class files from the
classpath defined by the system. Users may customize the Class
Loader to their needs in terms of loading the classes (such as from
a database/HTTP URL etc). This may be defined when the VM is
launched (its a system property, or you can write your custom class
loader as the starting point of your program), in which case the
System Class Loader is over-ridden or in case a Custom Class Loader
is invoked in a program, it runs as a child of the System Class
Loader, loading classes that the System Class Loader cannot locate.
P could have similar 'system class loader' or 'System Module Loader'
which launches the Core module and launches subsequent modules. This
would need to be implemented at the interpretor and not as part of
the Core module. Users may be given the option of defining custom
loaders of modules (later ?). This loader would need to be written
native to the interpretor, and not in P.
BTW, that brings me to another question - why do we need a
Core.lookup(X) method? Shouldn't we be able to load the namespace of
the imported module by default ? - such as what is done in Java ?
The 'import' feature of the interpretor should be performing the
function of the 'System Module Loader' and the namespace initiator
[similar to 'using namespace' in C++].
In case of namespace conflict resolution, most languages such as
Java or C++ would catch the error in case there are multiple
possibilities for a method or field, during compile time.
Conflicting situations would call for explicit identification of the
method or variable. For example:
Smtp := import("SMTP");
Http := import("HTTP");
httpheader := getHeader();
senderEmailId := getSenderEmail();
might lead to a conflict in case both the HTTP and SMTP modules have
the same method 'getHeader()' and would lead to compile-time error
identification. The correct usage should be:
Smtp := import("SMTP");
Http := import("HTTP");
httpheader := Http.getHeader();
senderEmailId := getSenderEmail();
Core.import("file://my_freq_rule_library.p");
Should these suggestions be mentioned in the draft as 'recommended
practices' ?
I think they should be defined/required explicitly. I suspect some RFC
defines URI schemes applicable in this context. If not, we would have
to document ourselves. Care to research if any RFC defines URIs
suitable for a "include this resource" command?
I'll get back to you on this. But, on a similar discussion as the one above,
in case we let the module loading be a part of the interpretor and allow
users to define custom module loaders - won't it be advisable to let the
designers of these custom loaders/interpretors use whatever scheme is
convinient to them ? Would defaulting to "file://" be restrictive ? Would
there be ppl who would want to retrive their p file libraries from a http
url ? Comments ?
Thanks,
Anwar