Also idly ruminating...
Yes, I've thought about this. The approach I've considered would
basically be to move the (for example) Defrule-building code into the
Defrule class, and have the parser just build nested lists of lists
and invoke an appropriate re-parsing routine from a table as
necessary. This extra step would no doubt slow down parsing and
rule-compiling, although I don't know by how much.
What still bothers me about this is that the grammar is still
irregular. I wish I could require the quote in certain places - i.e.,
(assert '(foo bar)) - but I can't change the basic syntax of the
language - can I?
I think the way (some?) LISPs deal with grammar irregularities like
(assert (foo (bar baz))) (the irregularity is that the reader would by
default evaluate (bar baz) and (foo (bar baz)) as function calls) is
via "defmacro". The arguments to a macro aren't evaluated before being
passed in - it's up to the macro to do the evaluation itself. Maybe
defining a formal defmacro system, then using it to define the various
constructs, would restore the simplicity of the reader.
I always enjoy discussions like this one the most.
I think Alan Littleford wrote:
> Ernest,
>
> as usual it looks as though you are ahead of the curve. I was holding off on 6.x
>for a while (indeed, to
> be honest
> I haven't event downloaded it yet ) -- but that will soon change.
>
> On the issue of the 'general list' it would seem to me that augmenting Jess with
>such a type might not be a
> bad idea - it would allow one to build defrules, facts and funcalls on the fly (or
>take them apart). This
> can be done implicitly for facts (via str- functions and assertString), so why not
>defrules or
> deffunctions ?? So:
>
> (assert '(foo a b c)) would be the same as (assert (foo a b c))
> (defrule '(name (cond1) (cond2) => (action1)(action2))) would do what you would
>expect etc.
>
> Probably multifield fuctions could be applied to the inside of one of these guys ..
>and so on.
>
> It wouldn't impact the speed that comes from Rete compilation since once the list
>was rule or factified
> there is no change in the semantics of the system (well perhaps there is -- I don't
>know what the lifecycle
> of such a constructed rule would be).
>
> Anyway -- idle ruminations.
>
> Tnx
> Alanl
---------------------------------------------------------
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]
---------------------------------------------------------------------