I think [EMAIL PROTECTED] wrote:
> Hello-
>
> 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.
Thanks for bringing this up. The CLIPS manual, IIRC, mentions almost
as a point of pride that more or less any random character can be part
of an identifier. I wonder how many people actually use any of these
characters? Maybe it would be smart to reclaim many of them, so they
could become syntactically more useful.
As to the surprising behaviour of :, ?, and =, these only have special
meanings when they occur at the start of a symbol immediately after
the end of another symbol -- note that the special meanings of '=' and
':' only make sense right after a '&'.
> This could also suggest that certain functions be known specifically to
> the parser, for '+', '<', etc., instead of being written as
> pure Userfunctions.
Yuk. That would be a step backwards, IMO. In fact, the parser already
has to know about a few special functions (assert, modify) and it
would be nice if those could be removed.
>
> 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!");
> }*
>
>
> 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.
Note that compilation of Java code is one option, but building strings
of bytecode from some internal representation is another, and this
latter is something I want to experiment with. Also look at the
jess.Accelerator interface and how it is used: I've got an
implementation (never released) which can speed up wordgame and zebra,
both math-intensive problems, by about a factor of two by turning all
the nested LISP math into Java code.
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
