Hi Alex,
I had a few notes (mostly half or quarter-baked) in addition to your last
posting:
Scope:
- Do we need to define the scope of code within which identifiers are
recognized ? Can there be a case such as :
h := Http.makeHeader("Client-IP");
quick_code := {
h := Http.makeHeader("Server-IP");
contact_server(h);
};
Single assignment/Or not?:
- Should we be able to de-assign a variable (I guess this goes against the
very definition of single-assignment)? Something like:
h := Http.makeHeader("Client-IP");
free(h);
h := Http.makeHeader("Server-IP");
- Is there any specific reason we would want single-assignment ?
Processing Point Identification:
- Mechanism for identifying the processing points identifier (PPID) as the
points of activity for the rule
- Something such as interpretor.processingPoint("X"){} could be defined ->
This info can be used by the interpretor to classify the rules based on
PPIDs for quicker retrieval by the OPES processor. Or else allow something
like:
Core.PPID("X")
{
code;
}
to deliniate the processing point associated with the code.
Primitive types:
- Could we include support for arrays or lists of elements/objects ?
- Can we modify the 'identifier' to be defined as (for us C/Java programmers
who prefer using this for global static variables):
identifier = "_"/ALPHA *(ALPHA/DIGIT/"_")
Loops and Iterators:
- This is a powerful feature P-language could easily integrate but difficult
in an XML-based language
- 'for each element in <Y>', 'while (expression){code}', 'do-while'
Subsystems:
- I am assuming the IRML subsytem equivalent for extended functionality
would be encompassed by the Core.import("M") functionality
Failure detection/capture:
- Should we have a structure similar to 'try-catch-final' in contemporary
languages like Java/C# etc ?
- What happens in case a service cannot be found when doing 'Service.find'
? - see notes on the interpretor below.
- What happens in case a method called in an object does not
exist/fails/throws an error/returns invalid value
Interpretor & Security:
- Should the specs for the interpretor be defined or is it left for the
implementor?
- Should security be enforced by the interpretor that does the underlying
processing based on P language commands?
- IMHO, If we assume that the P language runs via the interpretor that acts
as a 'Virtual Machine', all security/error handling/authentication features
are delegated to the interpretor.
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 Alex
Rousskov
Sent: Friday, September 12, 2003 3:01 PM
To: OPES Group
Subject: Re: Decision on Rules Language
On Fri, 12 Sep 2003, Markus Hofmann wrote:
As mentioned earlier, we'd assume that the "P" syntax as specified
so far is accepted and we won't have to start discussions on syntax
modifications.
We would need to add the following items that will have minor affect
on P syntax. Again, I expect no Bikeshed problems, but I think I have
to mention these for correctness sake.
1. Fault/error detection/recovery mechanism. This will
most likely be something simple that resembles
boolean expressions while having core benefits of
"exceptions" mechanism common to modern languages:
{
// piece of any code
} or {
// piece of code executed if the above
// piece fails for any reason
} or {
// piece of code executed if the above
// two pieces fail for any reason
}
In other words, the "expression value" of a piece
of code is "true" unless the code fails for any
reason. Actually, I do not think this changes
existing syntax, but that's an important missing
feature.
2. Constants:
- boolean true/false
- "strings" (already used but not documented)
- numbers (decimal only or both decimal and hex?)
- other (IP addresses: '127.0.0.1' or '1::h:5')?
Note that XML-based language would have to
document this as well
3. Comments:
- none supported
- /* block comments */
- // line comments
- block and line comments
I like line comments a lot, but would probably vote
against them in P because they introduce a notion
of a "line", which may be a bad idea if we are
going to use P expressions in interesting contexts
like HTTP headers where there are no lines.
4. International support (i18n)
Can we just say that everything is UTF-8 encoded?
Does Unicode define "space characters"? Or do we have
to say explicitly what those [ASCII] characters are?
If you have a strong opinion regarding any of the above or know more
about UTF/Unicode, please let me know.
We're already late with the rules document, so we'd expect a first
WG document on "P" to be published by 9/20. Alex, can you please
take the responsibility to do so.
Sure. I will wait for objections until Tuesday night before
submitting.
Andre indicated that he'd be available to help and write text as
well, if this would be helpful, please get in touch with him.
Done. Thanks Andre for not holding this against me. I am sure P will
reuse most of your work.
Alex.