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