[jboss-jira] [JBoss JIRA] Commented: (JBRULES-807) DefaultExpander not recording line numbers of errors correctly

Edson Tirelli (JIRA) jira-events at lists.jboss.org
Mon Apr 23 21:42:33 EDT 2007


    [ http://jira.jboss.com/jira/browse/JBRULES-807?page=comments#action_12360303 ] 
            
Edson Tirelli commented on JBRULES-807:
---------------------------------------

This one is though, but I agree it needs 'fixing' so I could use some advice.

Problem is that the DSL pre-processor as it is today is really a "macro pre-processor". Almost like C/C++ macros where you can really transform the original DRL into a completelly different one when running the expander. One simple example is allowing not only the keywords substitution, but also to change the complete structure of a rule file. Like doing in portuguese somethine like:

regra "rule name"
faça
    // RHS
quando
   // LHS

i.e., reversing the order of RHS/LHS (as woolfel asked for better backward chaining 'feeling') or ommiting  keywords (like the "end" keyword that is not present in the above rule and is automatically appended by the DSL pre-processor.
Also, the current DSL pre-processor is capable of making the DRL file cleaner by allowing for "hiding" ugly stuff. Example: one can define functions in the mapping file now and only add a single "use" clause in the DRL file:

DSL mapping (in XML format for instance):
-----------
<mapping>
<section> keyword</section>
<key>Add finance functions</key>
<value>
function finance1(...) {
...
}
function finance2(...) {
...
}
...
</value>
</mapping>
-----------

So the DRL file would contain a single line, responsible for adding all the "clutter" stuff:
----------
Add finance functions
---------

Not sure if it is really a good idea, but works. :)

Anyway, all this flexibility in the core pre-processor engine has the price of complexity. The way it is now, it is really difficult to map error messages to offsets in the original DRL (even worst to use lines instead of offsets). Although, I understand that this is a needed feature.

What I thought about is to use a datastructure to do the mapping by offset, so each manipulation that is done in the source file is reflected in the data-structure. But this is not easy and I'm still not sure it is feasible, since the core engine supports multi-phase expansion, where a chunk can be expanded to another chunk that is recursivelly expanded. This is good for building DSL hirarchies where a DSL is defined using sentences defined by another DSL. 

Anyway, another approach is to limit the flexibility, i.e., for instance, disallow structural changes. Example, instead of allowing full template rewriting, we could only allow simple keyword translations. This way, we can use the keywords as reference points in the original DRL for error reporting. So, if "rule" is translated to "regra", but we garantee it is present in the original DRL (no structural changes), we calculate offsets using it as a reference point. The question is: is the loss of flexibility worth in this case?

Any other ideas you guys have? questions?


> DefaultExpander not recording line numbers of errors correctly
> --------------------------------------------------------------
>
>                 Key: JBRULES-807
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-807
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>
> In DefaultExpanderTest, I have added a method:
> FIXME_testLineNumberError()
> this shows how it should work. The problem is that the line number calculated and reported is relative to the LHS block (in this case) whereas it have to be relative to the whole "file".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       




More information about the jboss-jira mailing list