None here.
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
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev