On Tue, 16 Sep 2003, Anwar M. Haneef wrote:
Sugestion 1:
************
(Section 3.6 ?) nil Object
While we might need a concept of an undefined value, I think we should
be able to get away without the nil object as a magic constant/value.
Perl does that, for example. Nil objects seem to be required only when
you support pointers, and P has no pointers. Please see below for more
specifics.
The (Core.)nil object is a special object that is the result of a
failed expression or statement. Operations on the nil object results
in a nil object, except in the case of the '==' operator in which
case a semantic comparision is made to see if the compared
expression also results in a nil object.
I think we can simplify quite a bit: Any use of an undefined value
must result in a failure (and not not another nil object). This makes
it easy to catch errors and abort early if needed. It also has a more
clear/uniform/straightforward semantics.
To make this interface complete, we would then need an unary operator
to test both for nil objects and member presence:
if (exists service) { ... };
if (exists Http.message.requestLine) { ... };
or
if (defined service) { ... };
if (defined Http.message.requestLine) { ... };
Note that the operator takes a name as input, it does not use the
value the name represents. No need for a special "nil"
constant/token!
Did I miss any use cases?
BTW, which name (exists or defined or something else) would you
prefer? I wish one could type the existential predicate using
ASCII :).
Moreover, we may be able to get rid of the whole "undefined value"
concept and use failures instead: if anything goes wrong, the code
fails. Failed code can be detected/caught using "or" operator. The
latter part is already documented.
To detect and substitute for missing services, for example, one would
write:
{ service := Services.find("A"); } or
{ service := Services.find("B"); }
Even a simpler expression below can probably be supported within the
current design, perhaps after defining "or" operator more clearly:
service := Services.find("A") or Services.find("B");
Do you think using failures like that is sufficient?
The nil object cannot be used in the assignments, and would result
in a fault if used. The result of a nil object being used as a
condition in a conditional statement such as an if-statement results
in a failure generation.
The failure of finding or applying a service correctly results in
nil returned as the result of the operation. In case of a situation
such as:
service := Services.find("opes://services/tran/german/french");
this will result in a failure generated as a result of applying the
nil object in an assignment as previously mentioned.
Agreed. The above no-undefined-use rule covers all these cases, IMO
(but using failure feature instead seems cleaner). What do you think?
Suggestion 2:
*************
XXX: Code blocks and inclusion of libraries:
The P language code is divided into blocks of code, with a default intial
block name of 'main'. (Members of a code block may be accessed using the '.'
operator.) For example:
my_freq_rule_library -> {
some_older_useful_code;
quick_expression -> {
code;
};
};
I am probably missing something important, but how is that different
from the current mechanism of assigning a piece of code?
my_freq_rule_library := {
some_older_useful_code;
quick_expression := ...;
};
Did you overlook that hidden(?) possibility or can your proposal do
more than name a piece of code?
Blocks of code from other files may be included in a P language program
using the 'include' statement. For example:
include <my_freq_rule_library.p>
This is already supported, I believe:
my_freq_rule_library := Core.import("my_freq_rule_library.p");
The algorithm to find module using its string name
("my_freq_rule_library.p") is Core implementation-dependent. I would
suggest that environments that support loading modules from P files,
use more explicit name syntax:
Core.import("file://my_freq_rule_library.p");
or some such. Http and other well-known module names should probably
be URIs (you talk about a similar requirement below).
XXX: Failure within Code Block:
Failures caught within a code block results in the program flow
exiting from the current code block. For example:
That is the current requirement as well, except the failure is
propagated until caught with an "or" trap. See current draft.
A failure in the service related operations would result in the
program flow continuing to the next expression in the 'main' block
as opposed to quiting the entire P program.
The "next expression" part may not be desirable because it would leave
certain failures undetected. Programmers must be explicit if they want
to ignore an error:
{ /* code that may fail */ } or {};
I believe current failure rules are close to exceptions in modern
programming languages. Do you agree that the current failure design is
sufficient to address your needs or do you see any missing
pieces/flaws?
Suggestions 3:
**************
XXX: Document lookup conflict resolution ((Section 4)
The modules as part of the interpretor's native language are
registered and given unique identifiers during the instantiation of
the interpretor. For instance, in case of a Java interpretor, the
Http modules may be registered to org.ietf.opes.PHttpModule. This
way a unique mapping between module names to native entities is
maintained and prevents a possibility of conflict. Modules may be
added at runtime, but need to be registered with the registry within
the interpretor.
Yes, I agree that modules should be identified by
[unique-per-interpreter-invocation] URIs and that those URIs have to
be known to the interpretor (or it would not know which module to
import!). This is indeed undocumented but needs to be.
Thanks for discovering more missing pieces and suggesting specific
improvements. I will try to incorporate all "undocumented but needs to
be" features you recently pointed out into the next draft release.
Please answer the above questions to resolve remaining issues.
Thank you,
Alex.
P.S. Current P draft (already submitted for publication as a WG
document) is at http://www.measurement-factory.com/tmp/opes/