*From Ernest:
> Now, thirdly: you're not the first person to suggest that matching on
> defglobals would be a Good Thing. I was thinking about it, and I
> realized that it would be easy to do the following:
<snip>
That sounds good to me!
*From [EMAIL PROTECTED]:
> This may be a philosophical or stylistic or "purist" issue, but the
way I
> see
> it, if you (the general amorphous "you", I'm not making this personal)
> want to pattern match on a defglobal, you ought to consider making
> it a full-fledged fact. In my mind it raises a flag that there are
other
> design
> problems in a software system making extensive use of them.
Ahem. I assure you I have considered making it a full-fledged fact, and
of course it would be easy to do so, and of course it would be more
purely consistent with production system style. However, I am writing
a system that dynamically builds rules on the basis of user input, and
I need the users to be able to refer to current values in their
specifications.
Globals are the cleanest way to do this. Obviously, I could give them
another notation, let's say I called them Flobals, notated as, say,
^name^ (instead of ?*name*). I could then interpret an occurrence of
the Flobal ^name^ in the user input as a reference to the variable in a
fact of the form (name ?var). But with all due respect to the virtues of
purity, I did not see any benefit to this additional complication.
(Well, that's not true; there are benefits. I just think they don't
outweight the complication.)
Similarly, I did not want to make the user write a fact CE when
what she really wants to do is reference a particular value. Of course
I could make her do so, but I think it would be less user-friendly than
allowing her to reference a variable directly (so that my code generates
the necessary test CE).
More generally, the idea of listening to property changes on globals
seems consistent with the hybrid Java/production-system style that
Jess supports. So I'll buy Ernest's proposal.
As to "other design problems" -- there are always other design problems.
The task of the designer is to evaluate the tradeoffs. (That's my purist
hobby-horse!)
Sidney Bailin
Knowledge Evolution, Inc.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
