[rules-dev] DSL expansion: ready for commit

[Mark Proctor]

On 15/12/2010 09:38, Wolfgang Laun wrote:
> Constraining the scope of applicable when-fragment might be added on 
> top of the current DSL syntax, providing a compatible migration path. 
> Notice that constraining the scope is similar to the rule attribute 
> "auto-focus", but unqualified entries may have to remain active 
> throughout.
>
> Expansion will have to be able to handle insertions not only for the 
> last preceding pattern but also to other parenthesized condition 
> phrases, e.g. eval, forall, etc.
Previously DSLs had tried to look like natural text, even in a text 
file, with DRL freely mixed in. But I think most people who are using 
DSLs would probably use them with tooling ontop, such as the guided 
editor. As such I think it's ok to separate DSL and DRL, and maybe use 
more control characters if it makes things easier. So the idea that a 
DRL and DSL can be interchanged freely and almost invisibly in the same 
file does not need to be dogma - going forward we need to do what is 
best to keep the two approaches maintainable and extensible.

I'd even be tempted to say that DSLs could use a complete different 
underlying language, such as lisp or some other document centric 
language, becaus the tooling can always re-present that in a user 
friendly way. Just some food for thought :)

Mark
>
> -W
>
>
>
> On 15 December 2010 10:18, Mark Proctor <mproctor at codehaus.org 
> <mailto:mproctor at codehaus.org>> wrote:
>
>     Thought I'd mention where I'd like to see DSLs go in the future,
>     if anyone is interested. DSLs are template fragments that can be
>     used in conjuction with each other. I'll refer to them as template
>     fragments from now on.
>     -Selecting one template fragment constraints which peer fragments
>     may be used after it.
>     -Template fragments may have nested template fragments. The
>     available nested fragments are themselves constrained and
>     depending on which child fragment is chosen cosntrains any allowed
>     peer child fragments.
>     -As well as constraining which peer or child fragments can be used
>     cardinality can also be constrained.
>     -The peering and nesting itself can be recursively applied,
>
>     So what we are talking about here is something that is almost xsd
>     schema like, for producing constrained documents.
>
>     Mark
>
>     On 15/12/2010 07:41, Wolfgang Laun wrote:
>>     On 13 December 2010 19:58, Edson Tirelli <ed.tirelli at gmail.com
>>     <mailto:ed.tirelli at gmail.com>> wrote:
>>
>>           Hi Wolfgang,
>>
>>           Mark said you would like us to take a look at some of your
>>         commits?
>>         Can you let me know which ones?
>>
>>
>>     Hi Edson,
>>
>>     I have reached a state where I think changes might be committed -
>>     see the attached README. I'll just go through the code and add
>>     some comments and make sure no "noise" remains. Then I'll send
>>     you the zipped tarball of all changes. If there are no
>>     objections, I'll also commit, but I need to do this before the
>>     git change incapacitates me. (I just don't have the time right
>>     now for making this conversion, and I won't have it until
>>     E12/2010. Worst time of the year for doing a change like that!)
>>
>>     @developers: Anybody interested in this set of changes can ask me
>>     for the sources.
>>
>>     Best
>>     Wolfgang
>>
>>
>>
>>
>>     _______________________________________________
>>     rules-dev mailing list
>>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     https://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/20101215/3a970977/attachment-0001.html