Well, meaningful examples sure would help :)<br><br>(1) On binding: Did I understand this correctly:<br>A legacy binding denoted by <var> ':' is restricted to the scope of 'for'.<br>The assignment <var> '=' creates a binding that can be used locally but is exported (for use in other CEs or on the RHS).<br>
<br>But note that a legacy form binding may not be usable until the end of the "for", only until the first contracting transformation (see function F below). <br><br><br>(2) On functions: Examples appear to illustrate (at least) 2 kinds of functions:<br>
T : Coll<X> -> Coll<X>, a mapping of a collection of type X to the same domain<br>F : Coll<X> -> Y, a folding of a collection of type X into a single instance of type Y (which could be = X) <br>Possibly you are also thinking of simple functions that map between single instances: <br>
g : X -> Y<br><br>The tricky part here is the transformation type T (such as map()). How will this work in the case<br> map( $, $.price*2)<br>You can't change the objects in the domain collection. So, how will the result be built? Will X have to implement Cloneable? What if the field (here: price) does not have a setter? map applies a function to a list of the function's domain values, which is very well for *values*, but we're living in an object-based environment. [Other transformations such as reverse() or tail() do not imply changes on the components.] <br>
<br>Another example, using a Collection<String> as input; the mapping should produce the uppercased strings, concatenated:<br> for( String( length > 10 ); map( $, $.toUpperCase() ); $c: concatenate( $ ) ) # not sure about the last '$'<br>
But what if I want to implement a transformation such as "every 'x_y' to 'xY'"? How would I specify this function so that map can call it? Java currently does not have functions as objects (and I think the terrible proposal for closures has been shunted into a very dead end track). Or would I have to implement each non-trivial map-type function anew, from scratch? Then map isn't a higher-order function at all!<br>
<br>Finally, permit me to say: If every currently implemented feature were well documented, both in manuals and javadoc, and readily usable, downloaded distributions without broken links (e.g. in javadoc) and missing libraries, and if there were no serious open JIRAs - then, and only then, I'd say that this is worth the time and the effort. I do beg your pardon if you think this is coarse or boorish, but these are my sentiments, and they had to come out, sooner or later.<br>
<br>Cheers<br>Wolfgang<br><br><br><br><br><br><div class="gmail_quote">On 1 November 2010 07:24, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
Look at your responses i would say ignore the content of the
examples, they are there just to illustrate the syntax not to show a
valid use case or scenario. What I'm doing is looking to other
languages to see what works there and try to bring them across, the
CEP type uses cases rely a lot more on functional programming
capabilities.<div class="im"><br>
<br>
On 31/10/2010 13:01, Wolfgang Laun wrote:
<blockquote type="cite">Hello Mark,<br>
<br>
I've been thinking about this, on and off, for 5 days now, and I
still<br>
fail to see the benefits. Perhaps there are more convincing use
cases<br>
than those in your original mail?<br>
<br>
Notice that the "for" scope now contains two kinds of bindings:
one that<br>
is strictly local to for(...) (bi below) and another one that must
be exported<br>
such as the binding $s in<br>
<br>
for( bi : BasketItem( customer == $c ); $s = sum( $bi.price); )<br>
</blockquote></div>
We can certainly make it:<br>
$s : sum(....)<br>
<br>
My thinking is we still need to create a sytnax to assign the
results of the expression when it returns a collection, instead of
iterating it. For this I was thinking of introducting:<br>
$var = someexpr;<br>
<br>
We can't do the following as there isn't enough of a differentiator
in the syntax between normal patterns.<br>
$var : someexpr;<br>
<br>
But we can do = for assignment of expr, but keep : for bindings of a
functional result. Just seeing how different things look.<div class="im"><br>
<blockquote type="cite"><br>
This will be confusing.<br>
<br>
<br>
I fail to see the usefulness of filter() in<br>
<br>
for( $b2 : BasketItem( customer == $c ); filter( $b2, $b2.price
> 100) )<br>
</blockquote></div>
filter is just a function, like min, max and average, it's not
special. Functional programming has a number of higher order
functions, filter, map and fold. There is nothing extra to support
that, so it's just added for completeness to show we could/can do
it.<div class="im"><br>
<blockquote type="cite"><br>
where one can better (and perhaps even more efficiently) write<br>
<br>
for( $b2 : BasketItem( customer == $c, price > 100) )<br>
</blockquote></div>
The filter function was just an example for completeness, it could
have been any function name.<div class="im"><br>
<blockquote type="cite"> <br>
I don't understand what this construct should achieve:<br>
<br>
$r = $bi | map( $, $.price * 2) | filter( $, $.price <
100);<br>
</blockquote></div>
I wouldn't take the example as "best practice"or actually meaningful
I was just trying to illustrate the syntax. <br><div class="im">
<blockquote type="cite"><br>
Given that $bi iterates over BasketItem objects, the first map
would create<br>
a numeric value by doubling $bi.price, so I suppose the next
pipeline transmits<br>
numbers so that filtering applies to - what? java.lang.Number?
Then it can't be<br>
$.price; </blockquote></div>
The contents is automatically passed into the function. The first
argument is what the higher order "map" function would store, the
second one is the modifier. Typically "map" is single argument map(
* 2 ), but I can't see how that would work for our syntax,
especially when passing objects instead of values.<div class="im"><br>
<br>
<blockquote type="cite">it could be $.floatValue or similar. But again: the
entire selection<br>
could be written as a constraint of the BaskerItem pattern.
Creating a<br>
collection just for determining a count isn't straightforward.<br>
<br>
The idea of accumulate is to produce a scalar result from
processing a<br>
collection of facts.</blockquote>
<blockquote type="cite"> It would indeed be useful to extend this so that a
result<br>
tuple can be constructed. But this could be achieved by a complex<br>
accumulate function that returns an object with multiple fields;<br>
in fact, min/max/count/avg/sum can be wrapped into a single
function<br>
"stats" returning an object of class "Statistics" with appropriate
fields.<br>
Any filtering on the result can be written as a constraint on that<br>
temporary fact pattern of type Statistics, e.g.:<br>
<br>
Statistics( $min: min, $max: max )<br>
from accumulate( $bi: BasketItem( $p: price ) stats( $p ) )<br>
</blockquote></div>
that's something that can be achieved now, but requires plumbing
from the end user. Multiple functions support would avoid that and
is what people from other products would expect. The last part of
the acc provides the propagation constraint, it's sugar to avoid
verbosity.<div class="im"><br>
<blockquote type="cite"> <br>
All that remains is the syntactic sugar that's provided by <br>
x in [0..4]<br>
y in [0..4]<br>
$c : Cell( row == y, col == x );<br>
as a on-the-fly pattern for selecting other patterns. Again, this
could be<br>
written more concisely as<br>
</blockquote></div>
Don't take the example as "best practice". It's showing that 'in',
which is the same as 'from', can look more compact and is what
people from a more functional world would expect.<br>
<br>
i'm thinking of allowing 'from' and 'in' to be used interchangable.
Where 'from' would be used with "from entry-point" where as 'in' for
iterationg the results of an expression.<br>
<br>
CEP cases can also need specific ordering, the example below could
find the cells in any order.<div><div></div><div class="h5"><br>
<blockquote type="cite"> $c : Cell( row >= 0 && <= 4, col
>= 0 && <= 4 )<br>
and a (minor) extension such as a set expression might simplify
this:<br>
$c : Cell( row in [0..4], col in [0,1,2,3,4] )<br>
<br>
Regards<br>
Wolfgang<br>
<br>
<div class="gmail_quote">On 26 October 2010 01:36, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org" target="_blank">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">We are thinking of moving "accumulate" to a simple "for"
keyword. We<br>
might allow 'in' and 'from' to be used interchangably and
allow ';' semi<br>
colons to separate the sections. I'm also wondering ho we
could allow<br>
function pipelines for the function part of the element. We
also need<br>
type inference and "default" return values.<br>
<br>
So here are some code snippets to show what I'm thinking, as<br>
improvements over what we do with accumulate now.<br>
<br>
// Simple 'or' very simlar to accumulate before. ; for section<br>
separating. With a new boolean section at the end to decide
whether to<br>
propagate or not. Will probably use '=' for function
assignments.<br>
$c : Customer()<br>
for( $bi : BasketItem( customer == $c );<br>
$s = sum( $bi.price);<br>
$s > 100 )<br>
<br>
// Multiple functions are ofcourse allowed<br>
$c : Customer()<br>
for( $bi : BasketItem( customer == $c );<br>
$mn =min( $bi.price),<br>
$mx = max( $bi.price); )<br>
<br>
// As are multiple patterns, and as before patterns can come
'from' an<br>
expression and with type inference we can get some nice
compact text:<br>
for ( x in [0..4]<br>
y in [0..4]<br>
$c : Cell( row == y, col == x );<br>
$avg = avg( $cell.value );<br>
$avg > 100 )<br>
<br>
The above is possible now with the following:<br>
Integer( this > 100) from<br>
accumulate( x : Integer() from [0, 1, 2, 3, 4]<br>
y : Integer() from [0, 1, 2, 3, 4],<br>
$c : Cell( row == y, col == x ),<br>
avg( $c.value) )<br>
<br>
I think the proposed additions reall help with declarative
readability.<br>
<br>
The normal chaining of elements is supported:<br>
$c : Customer()<br>
for( $b1 : BasketItem() in<br>
for( $b2 : BasketItem( customer == $c );<br>
filter( $b2, $b2.price > 100); );<br>
$a = avg( $b1.price ); )<br>
<br>
'for' will have a default return type for each bound function.
In this<br>
case it returns a single value $a, if there are multiple bound
results<br>
an array/map must be used for access.<br>
<br>
I also think we should allow pipelineing of functions, much as
you would<br>
do in a normal functional programming, possibly using haskell
like<br>
"stream fusion" capable functions.<br>
<br>
// '$' refers to the magic contents of the function which is
"piped" in.<br>
So $bi is piped to map, $ refers to each value evaluated in
the<br>
function, with type inference. 'map' results are piped to
'filter'. The<br>
final results are assigned to $r.<br>
$c : Customer()<br>
for( $bi : BasketItem( customer == $c );<br>
$r = $bi | map( $, $.price * 2) |<br>
filter( $, $.price < 100);<br>
$r.size > 100 )<br>
<br>
More ideas welcome :) But I think this opens up some very
interesting<br>
areas for DRL, with something that will hopefully feel more
natural for<br>
developers.<br>
<br>
Mark<br>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br>