More comments on the latest to-do:
Do we need a 'switch' statement in P ? - after all, this is a rules language
with lots of if-else statments...
++++++++++++++++++++++++++++++++
Native support for Regular Expressions?
These would be used a lot in a rules language. I would think one fo the
concerns in a debate for having it or not would be the potential
performance issue - which would be advisable? - having a pure native
implementation that is loaded as part of a module or interpreting the REGEX
engine that is part of the P language interpretor. Performance-wise I might
assume that the native implementation might be more optimized, while on the
other hand having it as part of the language would make the REGEX syntax
more standard and easier to migrate P code.
++++++++++++++++++++++++++++++++
Section 2. Escape sequences for the grammar (from C++):
escape-sequence:
basic-escape-sequence/
octal-escape-sequence/
hex-escape-sequence
basic-escape-sequence:
\'
\"
\?
\\
\a
\b
\f
\n
\r
\t
\v
octal-escape-sequence:
\octal-digit
\octal-digit octal-digit
\octal-digit octal-digit octal-digit
hex-escape-sequence:
\x hex-digit
hex-escape-sequence hex-digit
octal-digit:
0 / 1 / 2 / 3 / 4 / 5 / 6 / 7
hex-digit:
0 / 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / a / b / c / d / e / f / A / B /
C /
D / E / F
Regards,
Anwar
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Anwar
M. Haneef
Sent: Friday, September 19, 2003 1:07 AM
To: OPES Group
Subject: RE: Decision on Rules Language
Alex,
I have tried to answer one of the to-dos here related to namespaces:
Thus, importing a module cannot lead to name conflicts because all
references to the module would be via uniqueName. Aggressive use of
Core.lookup() can lead to multiple objects potentially accessible
under the same name. There are several known solutions:
- remove Core.lookup functionality
(but I do not want to write "Http." all the time
if all I use is the HTTP module)
- last applicable module in Core.lookup() order wins
(but that may bring big surprises when a newer
version of the last module includes names that
match already used names from the previous module
Core.lookup(m0);
Core.lookup(m1);
if (foo) { ... } /* used to be m0.foo, now m1.foo */
)
- all names are visible, but interpreter fails
if there is a conflict
(ugly because it is difficult to predict whether
there will be conflicts ahead of time -- we may
not know all the names that some module will
imports in the future)
The non-trivial use case I would like to support is this:
Smtp := Core.import("SMTP");
Http := Core.import("HTTP");
/* handle SMTP */
{
Core.lookup(Smtp);
...
}
/* handle HTTP */
{
Core.lookup(Http);
...
}
The above should lead to no conflicts regardless of what SMTP and HTTP
modules import or export.
I also do not like the recursive nature of this:
Core.lookup(Core);
I suspect that the lookup facility needs to be handled at the language
level, not Core module level. I though I can get away without it, but
this does not look good.
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