MIME-Version: 1.0
Received: by 10.90.87.7 with SMTP id k7mr237027agb.2.1219066216600; Mon, 18 
	Aug 2008 06:30:16 -0700 (PDT)
Date: Mon, 18 Aug 2008 06:30:16 -0700 (PDT)
X-IP: 192.35.17.30
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.16) 
	Gecko/20080702 Firefox/2.0.0.16,gzip(gfe),gzip(gfe)
X-HTTP-Via: 1.0 proxy13-int (NetCache NetApp/6.0.6)
Message-ID: <f3a3ce44-5836-4331-b31c-ee4d1bf1b4de@d1g2000hsg.googlegroups.com>
Subject: fc rules and objects - new requirements
From: egon.wuch...@siemens.com
To: PyKE <pyke@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I came across the following when working with fc rules and objects. I
would like to come up with something like a solution approach. But
there
are still some open question I would like to discuss.

Please consider the following example from the features and
application
configuration stuff I'm currently working on in the context of
software product lines.
I haven't got it working until now since I just translated these rules
from prolog in
order to identify any new probable requirements to pyke.

each_script_engine_requires_xml_component_entry
    foreach
        $feat in Feature.Instances

        # $feat.Selected = True does not work,
        # specifying a kb fact makes other relevant
        # assert parts trigger this foreach part
        Feature.Selected($feat, True)

        check $feat.Tags.contains("ScriptEngine")
    assert
        $xml_el = SubElement(config, "component")
        #Element.is_a($xml_el) #  we do not really need this fact

        $xml_el.set("class", $feat.Name + "Class")

        # implies has no matching Feature class member
        Feature.implies($feat, $xml_el)

There are two facts, Feature.Selected and Feature.implies. As you see
I
took the class name as knowledge base identifier. The first one is
reflected by a member of my Feature class, whereas the second one has
no
Feature member equivalent.

Feature.implies only intends to trigger other fc rules which use
Feature.implies within their foreach part. But the same applies to
Feature.Selected as the next small example shows.

feature_selects_parent_featuregroup
    foreach
        $feat in Feature.Instances
        Feature.Selected($feat, True)

        Feature.Selected($feat.Parent, False)
    assert
        Feature.Selected($feat.Parent, True)

Normally, I would have to write the following two statements for any
knowledge base representing a class and a fact representing a class
member.

Feature.Selected($feat, Value)  #Value = [True|False]
$feat.Selected = Value

But I would like to avoid it. Instead, by using Feature.Selected
within
a 'foreach' clause, the member value could be checked automatically.
For
instance, Feature.Selected($feat, True) could check the object member
for True. Similarly, Feature.Selected($feat, True) within an 'assert'
clause could set the member implicitly.

Additionally, in case of Feature.implies we would not need to set any
non-existant  member of the feature object. Asserting this new fact to
the Feature kb would suffice.

Up until know I thought about writing an object knowledge base class.
One would need to explicitly instantiate and add such a oo kb to the
engine before calling any prove or assert methods on this kb. The pyke
compiler would appropriately call oo_kb.prove("Feature", "Selected",
$feat, True) for a 'foreach' clause and the assert method for an
'assert'.

There are some more issues to consider. The first one are compound
class
names (e.g. MyDomain.Feature) as knowledge base names. The kb name
should be exactly the same as the imported class name which dependes
how
the class is imported. Thus, there would be an assumption that a class
is always imported the same way when using the object knowledge base.
But this is a reasonable assumption from my point of view as Python
would treat a class imported by using 'from my_module import Feature'
as
a different class instance as one imported by 'import Feature'.

Secondly, statemtents like FeatureGroup($feat_gr, $children) should be
ok. As I would like to do a check like 'check $child in $children'.
This
complicates a little bit what the object knowledge base would need to
do. It would need to look up whether the second argument actually is a
pattern and bind that pattern to the instance member value.

The last one is about new objects and how to reflect the knowledge
about
their existence within the object kb. I commented out the line
'Element.is_a($xml_el)' in the first rule. I created a new Xml element
in the 'assert' part. Currently, I'm not using it but other 'foreach'
rule parts could depend on newly created xml element objects. My
suggestion is to keep here to both statements

$xml_el = SubElement(config, "component")
Element.is_a($xml_el)

to make it explicit that a new object has been created and that it
gets
added to the object "Element" kb.

Just let me know what you think.

Thanks
Egon