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 :)
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 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