Hi Ernest,
Treating empty multislot differently than null multislot makes sense.
I tried matching empty multislot (zero lenght arrays) in Bean generated
shadow facts with:
(defrule r1
(fact (multislot))
=>
and it works as you described. The problem is that once it is set up, it is
not easy to return it to
initial value ("(modify ?f (multislot (create$)))" makes no sense with
Beans, right ?). This is the reason
for using null instead of empty array (I expect "(modify ?f (multislot
nil))" to work and to reset array reference in Bean to null).
I still don't know how to match null arrays (null array reference) in
shadow facts. As described in my first note, rules like:
(defrule r2
(fact (multislot nil))
=>
doesn't work. This is a little bit confusing because (save-facts) command
saves corresponding shadow
fact exactly in the form as written on the LHS of r2 rule. Does it mean
that null is not treated as nil, although it is printed out as nil !?
The behaviour is same in Jess 4.3 and 5.0a3.
Thanks in advance.
Miroslav Madecki, I/T specialist - RS/6000
Internet: [EMAIL PROTECTED]
Tel: +385-1-6308-156, Fax: +385-1-6111-119
IBM Croatia, Lastovska 23, 10000 Zagreb, Croatia
> Hi,
>
> Well, this is an interesting point, I think. Jess is doing the best it
> can under adverse circumstances.
>
> As far as both Jess and Java are concerned, an empty multislot (empty
> array) is quite a different thing from a null multislot (null array
> reference.) The fact containing (multislot nil) is Jess's way of
> representing the latter. CLIPS doesn't -have- a way of representing
> the latter, because it can't happen in CLIPS. So I suppose what I've
> done (by default really) is decide that null (as opposed to empty)
> multifields are unmatchable. This is not an unreasonable thing. For
> instance, imagine a scripting language in which Java beans appear as
> objects. Can you call multislot.equals(...) when multislot itself is
> null? No, of course not. Jess is just behaving the same way.
>
> Now, I can't tell you how to write your Beans (you may not even have
> written them) but I think you need to look very carefully at what this
> null return value means, and how it's different from returning
> a zero-length array. Note that if the method returned a zero-length
> array instead of null, you could match the multifield exactly as you
> expect, and everything will work just fine.
>
> One way of dealing with this might be for Jess to automatically turn
> null array references into empty multifields; but I'm not sure I like
> that, since someone might want to distinguish between empty and null.
>
>
> I think [EMAIL PROTECTED] wrote:
> >
> >
> >
> > Hi,
> >
> > Problem 1:
> >
> > I'm trying to match shadow fact with multislot generated by undefined
> > array.
> > Java: int[] = null.
> >
> > Jess 4.3 facts command displays fact in such a way:
> > (fact (multislot nil))
> >
> > I'm trying to match this fact with rule:
> > (defrule r1
> > (fact (multislot nil))
> > =>
> > but without success.
> >
> > How to match unassigned multislots in shadow facts ?
> >
> >
> > Problem 2:
> >
> > Unassigned multislots generated by JESS or CLIPS can be matched with:
> > (defrule r1
> > (fact (multislot))
> > =>
> > In this case empty multifield is assigned to multislot (result of
> > (create$)).
> >
> > How to maintain set of such rules which will work with normal and
shadow
> > facts ?
> >
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
