Subject: Decision on Rules Language

From: Markus Hofmann <[email-masked]>
Date: Fri, 12 Sep 2003 14:55:50 -0400

Folks,

in order to move forward with the rules language, we'd like to do the 
following:

Since both proposals - IRML and "P" - can basically do the job, it's 
more a question of personal style preference. From the discussions on 
this mailing list, it looks like only two people are leaning toward 
IRML, while four are leaning toward "P".

As such, we'd like to move forward with "P" and drop IRML.

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'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. 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.

Thanks,
   Markus and Marshall

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 12 Sep 2003 14:01:05 -0600 (MDT)

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.

---

From: "Anwar M. Haneef" <[email-masked]>
Date: Mon, 15 Sep 2003 19:40:37 -0500

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Alex Rousskov
Sent: Friday, September 12, 2003 3:01 PM
To: OPES Group
Subject: Re: Decision on Rules Language

		{
			// piece of any code
		} or {

	2. Constants:

		- boolean true/false

	3. Comments:

		- none supported
		- /* block comments */
		- // line comments

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 15 Sep 2003 19:11:33 -0600 (MDT)

On Mon, 15 Sep 2003, Anwar M. Haneef wrote:

> I had a few notes (mostly half or quarter-baked) in addition to your
> last posting:

You will find mostly half-baked answers below :-)

> 		h := Http.makeHeader("Server-IP");

P uses global scope. There is no big benefit from a local scope
because we do not have user-defined functions. Global scope makes it
easy to support/interpret/explain single-assignment. This is not yet
documented.

> very definition of single-assignment)?

Yes, this goes against the very definition/purpose of a
single-assignment. You will get a lot more complexity and fewer easy
optimizations with multiple assignments (true variables). Single
assignment along with lazy evaluation allows you to treat assignments
as macros -- very easy to support and relatively easy to optimize.

> - Is there any specific reason we would want single-assignment ?

Simplicity and performance. Single assignment allows you to manipulate
large protocol structures with little overhead. Without variables, you
cannot reuse computed values. With true variables, you get into all
sorts of complexity and memory management problems, even if you do not
want to optimize. Single-assignment makes slow interpreters simple and
complex interpreters fast.

Single assignment allows you to reuse code as well. See current draft
(the retry example: A or A or A).

> points of activity  for the rule

This is application-specific, IMO. Each module like "HTTP" would
define its own notion of processing points. You should be able to find
my rant about this on the OPES list archives ("Subject: processing
points in draft-beck-opes-irml-03").

> to deliniate the processing point associated with the code.

See above. Also, I believe that in many situations, the rules will be
assigned to a processing point by a higher-level interface. Again,
processing point is not a uniform concept that Core should support,
IMO.

> - Could we include support for arrays or lists of elements/objects ?

Not explicitly because there would be no way to iterate them. Remember
that there are no loops in P. However, modules can implement
structures and containers of any complexity; they would need to
provide appropriate access methods, of course (find, for_each, etc.)

For example, Services module is, essentially, a searchable map of
services.

> 	identifier = "_"/ALPHA *(ALPHA/DIGIT/"_")

Yes. Please remind me if I forget.

> - 'for each element in <Y>', 'while (expression){code}', 'do-while'

I agree that it would be relatively easy to add loops to P.

The rationale for not including explicit loops is that they are
error/leak prone and difficult to check for correctness. We want to
reduce chances that some P code loops forever or starves the proxy to
death. I think this is a weak argument because time-based and
memory-based limits for rule execution must be implemented at the
proxy anyway. But, I guess, we do not want to push too far. See my
comment about module-defined structures above as well.

> would be encompassed  by the Core.import("M") functionality

Yes.

> languages like Java/C# etc ?

See current draft for how it is handled today (section "Failures"):
	http://www.measurement-factory.com/tmp/opes/

> ? - see notes on the interpretor below.

In this case, find() returns some kind of an "undefined"/"nil"
object. If used, this object will result in a failed expression or
statement. This needs to be documented, of course. We also need a way
to test for nil values (and for member presence, for that matter).

> exist/fails/throws an error/returns invalid value

... the corresponding expression fails. See section Failures in current
draft at the above URL.

> - Should the specs for the interpretor be defined or is it left for the

We already have a few interpreter-specific MUSTs. Is that what you
mean by the "specs for the interpreter"? P draft _is_ the specs for
the interpreter, is it not?

> - Should security be enforced by the interpretor that does the
> underlying processing based on P language commands?

Not sure what you mean. What is your threat model?

> - 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.

I think that should be implementation-dependent, but I am not sure I
understand the issue fully. Note that extension modules are _not_
(cannot be) written in P so it is impossible to do what Java tries to
achieve with its security model. This is a good thing -- we do not
want to invent a new general-purpose language to write modules! Does
that answer your question?

Thank you,

Alex.