On Fri, 19 Sep 2003, Anwar M. Haneef wrote:
Do we need a 'switch' statement in P ? - after all, this is a rules
language with lots of if-else statments...
A "switch" statement is only better than a bunch of "if"s when all
if-statement conditions start with (X == ...). In P, the "=="
operator is defined for booleans and integers only. Booleans do not
count (if-else works better for them). I suspect that it is somewhat
unlikely situation for P rules to iterate through a bunch of integer
values.
IMO, what we need is to improve if-statement syntax to make a bunch of
if-else-if-else-if statements look good. Added to the to-do list.
Native support for Regular Expressions?
IMO, the problem with REs is not that they may take a long time to
process, but that available libraries cannot be used to bound/control
processing time. Many services will take a long time to process. But
services are designed so that a processor can terminate them if they
take too long. It is difficult to do that with RE libraries without
threads or other heavy mechanisms.
Thus, regular expression support should be optional (but can still be
native if this working group wants them!).
My vote is against native support in P because the majority of
applications would find existing string operators (substring
searching, essentially) and application-specific interfaces
sufficient. (BTW, I will add a length() and index() string functions
to Core).
These would be used a lot in a rules language.
Can you give a couple of examples where REs would be essential, given
available substring searching operators _and_ ability of
application-specific modules to split application objects (e.g., HTTP
headers) into semantically valid but smaller pieces for you?
having a pure native implementation that is loaded as part of a
module or interpreting the REGEX engine that is part of the P
language interpretor. Performance-wise I might assume that the
native implementation might be more optimized, while on the other
hand having it as part of the language would make the REGEX syntax
more standard and easier to migrate P code.
I think that performance-wise both approaches would be about the same.
Interpreters can use optimized libraries or modules can use optimized
libraries. Native support does allow for somewhat more natural RE
syntax, but it also complicates P syntax.
++++++++++++++++++++++++++++++++
Section 2. Escape sequences for the grammar (from C++):
escape-sequence:
basic-escape-sequence/
octal-escape-sequence/
hex-escape-sequence
Yeah, and we would need to add a universal-character-name as a part of
string-char or escape-sequence. This all looks kind of heavy. Is there
a simpler, but still complete solution? Replacing support for
octal-escape-sequence and hex-escape-sequence with
universal-character-name? What does XML have to offer here?
Thank you,
Alex.