On Wed, 17 Sep 2003, Anwar M. Haneef wrote:
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?
I would think that we should stay with maintaining the "{}" brackets
before the or for clarity - especially for cases with multiple
statements within the blocks. Also in section 2, we would need to
add:
Section 2:
expression =
name / function-call / "{" code "}" *( "or {" code "}" )
Not exactly. The "... ; more to be defined (logical and arithmetic
expressions)" part in the current BNF just needs to be defined.
Roughly,
expression = name / function-call / "{" code "}"
unaryOp expression /
expression binaryOp expression
binaryOp = "and" / "or" / ...
Code {block} is just one of the expression atoms, no special treatment
is needed in BNF or in the interpreter.
What is missing though, is cblock in the statement definition:
statement = assignment / function-call / if-statement / cblock
cblock = "{" code "}"
Will add.
XXX: Code blocks and inclusion of libraries:
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?
The key difference here was unique identification of the 'member
code' within a block. By 'member code', I refer to the ability to
identify the block of code assigned to 'quick_expression' within the
larger block, 'my_freq_rule_library'.
Do you want to refer to my_freq_rule_library.quick_expression from
outside of the my_freq_rule_library block? If you do not, then this is
already supported. If you do, then this is equivalent to user-defined
structures which, I would argue, is a too-heavy feature for P.
This might be useful when including libraries where there might be
conflicts due single assignment. Included libraries are identifed by
a unique code-block name, preventing conflict of names.
But libraries are already identified by a unique name on the left hand
side of the assignment, when they are imported:
uniqueName := Core.import(module_id);
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.
This problem is common to all languages that support namespaces. Would
you care to research the namespace issue in other languages (XML, C++,
Java) and tell us what the common solution seems to be, if any.
This might make large rule files more structured similar to 'rule'
blocks ("<rule></rule>") in IRML deliniated rules.
Is the "{ code }" construct equivalent to "<rule></rule>"?
What
Blocks of code from other files may be included in a P language program
using the 'include' statement. For example:
This is already supported, I believe:
my_freq_rule_library := Core.import("my_freq_rule_library.p");
True, I hadn't thought of Core.import being used that way. I agree
that the algorithm to find module using its string name is left to
the Core implementation. Although, I would suggest that we do
mention how the code is imported and appended to the program that is
including this.
Agreed.
("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");
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?
Thank you,
Alex.