I hestitate to suggest that Jess should be dependent on
XML and XML parsing, etc., but this is sounding very XML-ish,
to use the latest craze-phrase.
What I mean is way to implement the ideas Alan is talking
about here, in a flexible and extensible way is to use XML
definitions for everything, with associated DTDs for the
core Jess definitions, AND user-defined DTDs for the
"some-other-language-here" constructs, for example.
You could then use style sheets (or other logic code)
for, among other things, for translation and compilation
of the "some-other-language-here" constructs.
This could also help implement the more general case, that
has been talked about in the past, of mapping "My style X of Jess code" to
the internal Jess constructs in a uniform way.
Thinking about the reverse direction, pretty-printing constructs
like defrules could be mediated by style sheets as well, so that
you'd have a nice, bidirectional mapping between language X and Jess.
This raises a couple of issues though. Somebody would have to write the
XML definitions, and the style sheets. That could open another set of
problems, where people would have to worry about bugs in the XML and
style sheets (i.e. parsing) in addition to solving their REAL problem with
Jess. Also, if you wanted to send someone a rule base, you'd still have to
use Jess format--unless you also sent along the files to support parsing.
Finally, it seems to me there are implicit definitions for various
constructs
in Jess--currently implicit in the parser code, and in the objects. Defining
them in some sort of extensible format, XML or whatever, would essentially
externalize
the definitions--and I'm not sure, on the whole, that you really would want
to do that.
On the second issue, of having the dot as an operator and/or allowing it in
symbols.
On the one hand, it's a matter of syntax--allowing object-oriented syntax
and/or
the current lisp-ish syntax. I personally don't have a problem with the
current syntax,
but I know that several of my co-workers have voiced learning the lisp-style
syntax
as a major pain/risk for them--so they would prefer a more O-O-like style.
Also, as a matter of preference, if *I* were encoding IP addresses, I would
likely
encode them as strings rather than symbols, and deal with whatever
additional
overhead that required. This essentially amounts, as a general strategy, to
quoting
things with dots in them, so that they get evaluated "properly". But again,
I completely understand the desire for convenient representation of things,
so I
understand why being able to define it as a symbol is nice in certain cases.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 07, 2000 6:05 AM
> To: Alan Moore
> Cc: [EMAIL PROTECTED]
> Subject: Re: JESS: Asserting facts across engines
>
>
> I think Alan Moore wrote:
> >
> >
> > In a previous post, I suggested a RHS parser extensibility
> mechanism where
> > upon reaching an extensible set of tokens, the
> parsing/input stream could be
> > passed along to an associated parser. My original post was
> motivated by
> > wanting to do:
> >
> > (defrule myRule
> > (a ?count)
> > (b ?datum)
> > =>
> > (myParser {some; other; language(); here!}
> > )
> > )
> >
> > where the token/parser myParser could be registered with Jess.
>
>
> Indeed, this could be nice. You could accomplish much the same thing
> using unmodified Jess and using "" as the delimiters, however. You'd
> have to escape "" characters appearing in the other-language code.
>
> >
> > CLIPS had a feature (I think?) where you could validate
> your "user function"
> > input parameters. I don't think it let you parse the input
> however. I has
> > been quite a while.
>
> Yes, CLIPS lets you tell it what the proper argument types are for a
> user function when you register it; that's what you're thinking of.
>
>
> I know that the following is also near and dear to your heart: I've
> been starting to think that notation like
>
> (bind ?x ?vec.elementAt(3))
>
> would be nice to have, as opposed to the current
>
> (bind ?x (call ?vec elementAt 3))
>
> The only serious issue regarding this is that currently, a '.' is an
> allowed character in a symbol, so tokenizing the above as the separate
> tokens '?vec' '.' 'elementAt' would require some context-dependent
> parsing. Dots are allowed in symbols only because one user long ago
> requested this - they wanted IP addresses like 127.0.0.1 to be
> valid symbols.
>
> If anyone is reading this far down: how important is it that symbols
> can contain dots?
>
>
>
>
> ---------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
