<mfusco> [18:48:40] @Guard rule r1 when LHS then unitA.run(ds1, ds2); end
<mfusco> [18:48:56] where unitA, ds1 and ds2 come from?
<conan> [18:49:44] mfusco  back
<conan> [18:49:46] so I think you and mmatteo went more literal on the declarative aspect that I initial intented.
<conan> [18:49:46] had time to think while in the car
<conan> [18:49:48] but necessarily a bad thing
<conan> [18:49:50] but need to think about some aspects
<conan> [18:50:28] how is unit actually instantiated and with what arguemtns?
<conan> [18:50:30] if you are going to have guards like this
<conan> [18:50:30] then the LHS must be existential
<conan> [18:50:32] it feels clean not to
<conan> [18:51:16] and we could probably introduce @Guard and @Blocked - maybe...
<conan> [18:51:34] the later means a unit can be evaluate while it's true
<conan> [18:51:45] I'd also be interested to see if we caould get some defeasible aspects in here
<conan> [18:52:28] @GuardAllowed @GuardBlocked or something
<conan> [18:52:30] combined with @Superiorirty from defeasible
<conan> [18:52:32] so one can rebut the other
<conan> [18:52:45] now you have something that is interesting :)
<mfusco> [18:54:07] conan: the LHS is existential for what regards the guards
<conan> [18:54:38] the user soudl be explicit
<mfusco> [18:54:41] conan: we count the number of activations and if it is >0 then the guard is active and the guarded unit will be evaluated
<conan> [18:54:44] we don't want mutiple RHT firings
<conan> [18:54:47] it won't make sense
<mfusco> [18:55:21] conan: in our example the consequences of that rules are always empty
<mfusco> [18:55:43] conan: we just use the LHS as guarding condition, there's no consequence
<mfusco> [18:56:11] conan: to reply to your first question, the units are created by the RuleUnitFactory
<mfusco> [18:56:24] conan: that populates the ds and other vars
<mfusco> [18:56:42] conan: but still this means that the unit is a singleton
<mfusco> [18:57:06] conan: at the moment it's impossible to have more than a unit instance of a give class
<mfusco> [18:57:29] conan: not sure if this limitations makes sense or not
<mfusco> [18:57:46] conan: but at the moment you write @Guard(UnitA) I believe this is implicit
<mfusco> [18:58:07] conan: when you write
<mfusco> [18:58:07] @Guard rule r1 when LHS then unitA.run(ds1, ds2); end
<mfusco> [18:58:31] conan: this doesn't make much sense to me if you don't clarify where unitA, ds1 and ds2 come from
<mfusco> [18:58:55] conan: and still in that case I don't understand what @Guard means
<mfusco> [18:59:11] conan: and even more important what is the identity of the unit
<mfusco> [18:59:25] conan: for me the identity of the unit is just its class
<mfusco> [19:00:18] conan: but of course this imply you cannot have more than an instance alive at a given time and I'm not sure if this is a relevant limitation or not
<mfusco> [19:05:01] conan: to recap my doubts are
<mfusco> [19:05:05] 1. what's the identity of a unit? (for me it is its class)
<mfusco> [19:05:05] 2. how do you create it? (at the moment through the RuleUnitFactory)
<mfusco> [19:05:22] conan: and for me both 1. and 2. imply that each unit is a singleton
<conan> [19:08:31] mfusco  sorry bck and forth, as looking after son.
<conan> [19:08:48] I don't think we should have empty RHS rules
<conan> [19:08:57] if that's the case
<conan> [19:09:05] we have a new keword that no longer requires it
<conan> [19:09:15] like query
<mfusco> [19:09:24] conan: you're not obliged, you can put something on the RHS
<mfusco> [19:09:37] conan: however that RHS will just have the usual semantic
<mfusco> [19:09:45] conan: while only the guard is existential
<conan> [19:10:28] if you can put something in the RHS
<conan> [19:10:30] then it can cross product on it
<conan> [19:10:30] LHS shodlu be existential then
<mfusco> [19:11:35] conan: ok we can say that if a rule is annotated with @Guard it is always existential
<mfusco> [19:11:52] conan: but this is not my main concern at the moment
<mfusco> [19:12:04] conan: I believe that the 1st thing to clarify is the unit identity
<mfusco> [19:16:50] conan: sorry but I really have to go now, please ping me asap tomorrow, we need to further discuss this and sort it out
<mfusco> [19:16:51] cya
<conan> [19:18:28] ok