On 4 December 2010 21:49, Michael Anstis <michael.ans...@gmail.com> wrote:
> 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
>
>
>
> On 4 December 2010 18:33, Wolfgang Laun <wolfgang.l...@gmail.com> 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@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
>
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
