On Wed, 10 Sep 2003, Markus Hofmann wrote:
Alex Rousskov wrote:
"Fortunately", OPES WG group does not have enough active participants
for the above to become a problem :-/.
Well, then it's even more dangerous - with only so few active
participants, we cannot afford to be distracted by disucssions on
grammar/syntax at all - we should leverage whatever we can.
If we decide to move forward with "P", I would assume that its
current grammar/syntax is accepted as is, and that we won't get
distracted by discussions about style preferences.
That's my expectation. There will be some additions and polishing
actions as the current grammar is not 100% complete, but I really
doubt we will run into Bikeshed problems due to P syntax. We can run
into them due to P/IRML semantics, of course.
I do *not* believe that the OPES rules language needs to be designed
for performance, simply because I don't assume that OPES processors
will use this language as internal representation for rules
evaluation anyway.
Let's use English then :-)
Seriously, compilers and interpreters can do only so much. If we care
about performance and the problem domain is not trivial, we must
include human code writers into the loop. We are not talking Assembly
language here, but some major human-hints would be requried in rule
modules for them to be interpreted efficiently.
This is the same as writing programs in modern programming languages
like C++ or Java -- the languages are high-level, but have enough
knobs to optimize performance where it counts. If compilers were so
smart as you may be implying, we would be writing all programs in
Prolog or a similar declarative language.
An OPES processor will receive a rules description in the format to
be specified, and then (in my view) will translate it into an
internal (proprietary) and highly efficient data representation -
something tree based comes to mind.
Yes, but building an efficient bytecode requires programmer hints
(i.e., language support).
Alex.