Hello-
Concerning the use of '.' in symbols . . . I think the java notation would
be a much better use. For the specific example of IP addresses, Java
either requires a 4 byte array (not sure about IPv6) or a dotted String,
so it would seem that most IP addresses should be represented as a string
anyways. I dare say that other common uses of '.' would also be more
appropriately quoted (for instance, regex, directory path, etc. generally
requires string quotation except in special cases, and so would otherwise
be bad long-term design). The only problem I can see is the existing use
of an IP address as the head of a fact. One workaround would be to
substitute an underscore for dots, but hostnames may suffer. Another
would be to increase the fact size with an 'ip' header, which might
somewhat slow the Rete network down, but if anyone is heavily utilizing
this feature, Jess 5.1 would seem adequate in the meantime.
As I've pretty much said previously, I'll encourage just about anything
that intuitively improves Jess syntax, even at the risk of CLIPS
compatibility. The Java + expert system connection is just too great an
opportunity. For me, I think the most immediate benefit from Java
reference notation would be in accessing internal Jess structures, such as
required by defquery use.
I could also see potential in extending Jess to incorporate features found
in Beanshell, Perl, etc., though risk of language polution raises some
caution. Regular expressions, compilable Java blocks, etc. are niceties
to think about for the long term.
This raises the issue of all the other special characters. I always
thought that the underscore was a perfectly good separator for variable
names and the like, but the concept of an atom destroys this notion.
Section 2.1.1 states that an atom may contain any of "*=+/<>_?#.".
However, the following assertion is valid in Jess 5:
(assert (-) (_) (+) (/) (\) (<) (>) ([) (]) ({) (}) (') (`) (,) (.) (:)
(!) (@) (#) ($) (%) (^) (*))
The following also works:
(assert (a=) (a?))
This leaves, on my keyboard, the following characters which cannot be
used here at all: '|', '&', '(', ')', '~', ';'. This includes the
pattern binding, list grouping, and comment characters, but I'm surprised
that ':', '=', and '?' aren't fully included in this list.
It is confusing but important to understand that Jess mostly lacks any
sort of operator, which most punctuation characters are reserved for in
other languages. Operators are otherwise written as functions, which are
lists of atoms with the car being a defined function name.
I'm not familiar with formal CLIPS, so I'm not sure what is typically
supported in this regard, but I feel there would be a lot more room to
grow Jess if the definition of an atom were a little more restricted.
This could also suggest that certain functions be known specifically to
the parser, for '+', '<', etc., instead of being written as
pure Userfunctions.
Perhaps an atom prefix like the '?' that introduces a variable could be
used to introduce an arbitrary string as an atom. Something like
@127.0.0.1 would do nicely. Everything after '@' up to the next
whitespace would constitute the unusual atom. Otherwise, only letters,
numbers and '_' would be allowed. (Okay, I hardly expect anyone to
support this last bit.) Nevertheless, it seems that the use of an atom
prefix may be the only (most natural) way to conveniently introduce new
syntax. Thus, perhaps object notation should really be written as
something like:
'?var.doSomething(3, 5)
'Integer.toString(?intvar)
This looks like quite a bit of parser rewriting, regardless of the
approach, since things are no longer encapsulated within a single atom.
One could imagine going further. Optionally adding a Beanshell context,
or a byte compiler, Jess could substitute variables in an escaped Java
string and pass it to Beanshell for further evaluation. In this way,
in-line Java blocks would be added to Jess. Syntax for this might combine
the above notation combined with that of defglobals:
'*{
for (int i = 0; i < 5; i++) {
System.out.println("Hello?");
Thread.currentThread().sleep(2000);
}
System.out.println("Hello, world!");
}*
Presumably, the parser work that accounts for reference notation would
facilitate such expansion. Note that '*' embedded within the block would
need to be escaped, but that is easier and less confusing than escaping
''' or '"'.
Having such compact syntax might also speed up procedural evaluation. My
presumption is that Jess' LISP syntax is difficult to optimize in this
regard, particularly having already been built on top of a byte compiled
language. Something like Beanshell has the potential of having a byte
compiler for optimizing in-line code of this sort. I believe it has been
said before that Jess is rather limited by the speed of the reflection
API. There may be a distant light on this issue if this or a similar path
is taken, though I don't currently know of any suitable byte compilers.
-Dave Barnett
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
