[rules-users] What is inference and how does it facilitate good rule design and maintenance

[Mark Proctor]

Wolfgang Laun wrote:
> 2009/11/11 Mark Proctor <mproctor at codehaus.org>:
>   
>> Wolfgang Laun wrote:
>>
>> 2009/11/10 Mark Proctor <mproctor at codehaus.org>:
>>
>>
>> Wolfgang Laun wrote:
>>
>> It is, however, very desirable to be able to write LHS in a more
>> structured way, not being forced to either repeat CEs or create
>> additional facts establishing secondary properties (such as isAdult).
>>
>>    <result-type> property <name>( <fact-type> <name> ){ <expression> }
>>
>> and use this in LHS the way we are used to
>>
>> What you just described there is prolog "like" in nature, we have some ideas
>> around that. My BRF talk last week showed some ideas on how we can integrate
>> POSL. The are upsides and downsides to fact inferrence and query based
>> inferrence - hopefully we can provide both worlds :)
>>
>> Mark
>>
>>
>>
>> What I'd really like to have does not extend current LHS semantics and
>> shouldn't have any impact on rete and inference mechanisms. The "property"
>> I'm thinking of is a pure CE expression abstraction, without side
>> effects etc. If
>> necessary, it could be implemented by textual expansion. Possibly it might
>> favour compilation into rete but I've never looked into this topic.
>>
>>
>> And if a function calls a function and we allow multiple arguments and
>> return value?
>>     
>
> Nested calls would have to conform to the locally visible objects,
> i.e., the parameters
> of the "property" the call appears in. Having exactly one return value is just
> the point.
>
>   
>> heh, the only thing you'll be missing then is unification
>> arguments ;) And then we have full prolog.
>>
>>     
> No, I don't want that.
>
>   
>> But I get the jist of what you are getting at. Wait till we get the prolog
>> style backward chaining done, then we can see what additional work needs to
>> be done to satisfy your requirements. Id be worried about adding this in
>> first, and the backward chaining after, in-case it stunts anything.
>>
>>     
>
> OK. Gives us time to discuss the details :)
>
> And, perhaps, think about adding (relatively) simple things like
> permitting, in DRL
>    import static ...;
>   
you can already do this, but we call it import function. We just haven't 
done the mapping to allow functions to be imported from different 
namespaces, when they are defined in a drl, instead of on a java class.
>    final static String foo = ...;
>   
This sounds like you want constants defined? I think we need to think 
more on the whole area of constants, data initialisations and setup etc.

Mark
> -W
>
>   
>> Mark
>>
>>     
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091111/2d4b9020/attachment.html