[rules-dev] Long DSL lines

Wolfgang Laun wolfgang.laun at gmail.com
Mon Dec 6 02:25:16 EST 2010


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 at codehaus.org> wrote:

>  On 05/12/2010 12:29, Wolfgang Laun wrote:
>
> On 5 December 2010 11:23, Mark Proctor <mproctor at codehaus.org> wrote:
>
>>  On 04/12/2010 20:49, Michael Anstis wrote:
>>
>> None here.
>>
>> Longer term, I wonder whether our DSL syntax is too weak?
>>
>> Even the ability to declare blocks would be nicer than long lines (and
>> line split markers):-
>>
>>  I'd rather see us progress go a constraint and data driven templating
>> system. I'll discuss it more with you when we meet up. The DSLs are just
>> sentence templates and we needmore than that.
>>
>>
> So what? Leave the current DSL with all its deficiencies and bugs?
>
> DSLs are just template fragments, with any luck we can figure out how they
> can fit into the larger picture of a more constrained and validated
> approach.
>
> We haven't planned anything yet, so really don't know. I just know that
> pure fragment templates, with no constraints no data driven suggestions, no
> validation is not an ideal long term approach.
>
> Also being OSS nothing ever dies as long as someone is out there using
> stuff and producing patches for it.
>
> Mark
>
>  -W
>
>
>
>>  Mark
>>
>>
>> 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 );
>>     }
>>
>>
>> On 4 December 2010 18:33, Wolfgang Laun <wolfgang.laun at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>> _______________________________________________
>> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101206/0c1a9d59/attachment-0001.html 


More information about the rules-dev mailing list