On Tue, 13 Jul 2004, Markus Hofmann wrote:
How will P interpreter know what parameters are available? Which
parameters are optional? What are their types?
I consider this out-of-scope for the current work. The author of the
rules needs to know about the parameters and their types when writing
For example, when I'm writing rules like
invoke Service_A(p1, p2, p3)
then I assume to know about Service_A and its parameters. How I learn
about this is out-of-scope (could be either human interaction or
I am not sure you can get away with this without making a major
sacrifice. I agree that how _you_ learned about the parameters is out
of scope. However, P interpreter has to check your rules and translate
them into specific OCP messages. To do that, it needs to know what
parameters Service_A has (by name or position), which of them are
optional, and what their types are.
You can say that the programmer will supply parameter names and/or use
much more dangerous positional notation. While technically possible,
it would make it impossible to check your rule set for correctness
without executing it. For example, if P interpreter does not know that
Service_A only has two parameters, then P interpreter cannot tell you
that the above code snippet with Service_A(p1, p2, p3) is buggy. Only
the service can, at runtime.
Same for parameter types. You can get away with trusting the
programmer to supply the right types, but in reality that means that
a P interpreter will not be able to detect a type mismatch.
invoke Service_A(p1, p2, p3);
invoke Service_A(p2, p1, p3);
will all look the same to the interpreter (but not to the service!).
We know how poor humans are at writing bug-free code. I think that
being able to validate much of P code off-line is an essential rule
language feature that we should strive to preserve. Unfortunately,
that seems to require informing the interpreter of service interface,
independent of P code itself.
Can we have a safe/validate-able service invocation without the
knowledge of service interfaces (service "feature" definition in terms
P.S. If P programs are "rules", what should we call P programmers?