On 4 December 2010 21:49, Michael Anstis <michael.anstis(a)gmail.com&gt; wrote: Good. Longer term, I wonder whether our DSL syntax is too weak? Indeed, rhere are several things that have crossed my mind. I'm currently trying to create a non-trivial DSL, so some of the ideas below result from practical work. 1) The leader [x][y], where the meta-section [y] is optional, is in conflict with a pattern that begins with [...]. So, although I can write [when]There is a foo I cannot write [when][Th]here is a foo A better "leader" syntax would be to include any metadata (key=value or key, value "true") in the first and only bracket, e.g. [when type=y]. The parser should simply put all such metadata into a map, and the expander could use it at its discretion. For instance, global match flags could be added like this: [when flags=i]there is a foo=... rather than with the less readable [when][](?i:there is a foo)=... 2a) Another possibly useful processing option that might be specified as mentioned previously could be "redo", instructing the expander to match and replace an entry as often as possible. 2b) I've also felt the wish of retaining a matched value across entries, for later substitution within the same rule. Option: [when global=foo] and foo remains set until the end of the rule or query. (!) 2c)And a "debug"! (How do people see what is expanded without hacking the source? The code is in there, just commented out...) 3) It should be possible to have an empty "value" sentence: [when] [Tt]here is a= This lets you get rid of blahs with a single entry, rather repeat it everywhere. (Workaroud: replace by /**/ - ugh.) 4) Substitutions in the value section should be restricted to such occurrences of {x} where x is a name defined in the key section. Then, one could use, e.g., modify( a ){ ,,, } without having to escape the brace. 5) The proposed \EOL isn't an ideal. solution. It would perhaps be preferable to consider any non-empty, non-comment line that doesn't start with one of "[when",..., "[*" as a continuation of the last entry. [then][][Bb]ook the customer for the flight= $f.setAvailable( $f.getAvailable() - 1 ); update( $f ); 6) Those of you who can say "man bash" might skip to the section "Parameter Expansion" to get some ideas what might be done in the substitutions of the value section. Also, some transformations enforcing certain case patterns (uc, lc, ucfirst) would be handy. [when]there is a {what}={what:ucfirst()}() > Even the ability to declare blocks would be nicer than long lines (and line > split markers):- > then [Book the customer for the flight] > { > $f.setAvailable( $f.getAvailable() - 1 ); > update( $f ); > Booking booking = new Booking(); > booking.setCustomer( $r.getCustomer() ); > booking.setFlight( $f ); > insert( booking ); > } Only with utmost care ;-) The combination of DRL, Java, regex patterns is a convoluted mixture of characters. Parsing is like walking into a minefield of which you don't have the map. Cheers -W > On 4 December 2010 18:33, Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; wrote: >> Currently each entry must be a single line of text. This results in long >> lines, especially on the RHS. >>> I have experimentally inserted a transformation of the DSL text (in >> DSLTokenizedMappingFile) >> which converts '\'+EOL on the fly to a space. (The passed-in reader is >> read into a buffer, '\'+EOL >> is translated to space, and EOLs are inserted later to readjust the line >> number.) In a text editor, >> I can now write, e.g., >>> then][][Bb]ook the customer for the flight=\ >> $f.setAvailable( $f.getAvailable() - 1 );\ >> update( $f ); \ >> Booking booking = new Booking(); \ >> booking.setCustomer( $r.getCustomer() ); \ >> booking.setFlight( $f ); \ >> insert( booking ); >>> Of course, the DSL editor will not preserve this, but future development >> might provide more >> convenient editing there, too. >>> Any objections? >> -W >>> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >>> _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev

On 5 December 2010 11:23, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: So what? Leave the current DSL with all its deficiencies and bugs? -W

Anyway, fully understanding the current approaches and getting them to work correctly and conveniently is a pragmatic first step to any progress ;-) I have created JIRAs 2814 and 2819, addressing the current problems of DSL parsing and expansion, and I've mailed three reworked source files to Edson, but I can't handle the parser. (Also, I don't know for some of the "relics" in the code intend to implement in the first place.) -W On 5 December 2010 21:17, Mark Proctor <mproctor(a)codehaus.org&gt; wrote:

Well, it won't give you a proper line number for an error that's somewhere within a single range of \-escaped newlines, but I reinsert the "stolen" newlines at the earliest possible moment. This ensures that line numbers in error messages are correct w.r.t. the start of a logical line. -W On 6 December 2010 21:00, Michael Neale <michael.neale(a)gmail.com&gt; wrote: