[rules-dev] Drools syntax diagrams - redrawn

[Anstis, Michael (M.)]

Why the two different operators for in- and cross-pattern "or" i.e. "||"
and "or". What a pain that surely would be from a user perspective...
 
Where does that fit in with the language orthogonality too (blogged
about by Edson some time ago - sorry to drag the past up
http://tirelli.blogspot.com/2007/08/quick-catch-up-and-language.html)?
 
+1 for infix too :-)


________________________________

	From: rules-dev-bounces at lists.jboss.org
[mailto:rules-dev-bounces at lists.jboss.org] On Behalf Of Mark Proctor
	Sent: 22 September 2010 16:03
	To: rules-dev at lists.jboss.org
	Subject: Re: [rules-dev] Drools syntax diagrams - redrawn
	
	
	On 22/09/2010 14:40, Wolfgang Laun wrote: 

		Service:
		http://www-cgi.uni-regensburg.de/~brf09510/syntax.html
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.html> 
		
		The grammar syntax is the same as used in DRL.g but
stripped of all the antsy additions, and simplified.
		
		@Mark: I'm well aware of the limitations of a 1:1
translation of a parser's grammar into diagrams. I have reduced the
splits into separate rules in DRL.g considerably. But what do you want
to hide from the users? The syntax is the syntax, and there's no
sweet-talking around it after you have reduced all the noise from
technical splits.
		
		One thing that might help would be deprecating things
like infix or/and.
		

	yes agreed. Simplifying the grammar, reducing ambigiiouty or
multiple ways of doing the same thing, will make any resulting grammar
both easier ot maintain and grok.
	
	Edson, Davide and I have already discuss this. Both are working
on a new parser and are trying to address these issues. So things that
are doing are:
	
	Single binding on 'or'
	$binding : ( Pattern() || Pattern() )
	
	We are thinking of only allowing 'or' between patterns and not
allowing users to mix and match 'or' and '||'.  Inside of patterns '||'
is the only connective allowed and will remain so.
	
	We will also probably make a choice and only allow infix 'or'
and 'and', at the moment users can chose infix or prefix. Personally I
find prefix quite attractive as it works sort of like a "choice":
	(or Person(  ... )
	      Person( ... )
	      Person( ...) )
	
	But I think most peopel are more comfortable with infix:
	(Person(  ... ) or
	  Person( ... ) or
	  Person( ...) )
	
	return value, eval, literal constraint, variable constraint are
going. These are left overs of a Clips based grammar. So instead we'll
have a generic "expr" class that follow more common modern ASTs for
expression engines, like say MVEL.
	
	Davide has also requested that we make $ prefix mandatory for
LHS bindings as that is deterministic and again makes the grammar
cleaner. I personally like it being optional and it's still open to
debate. But I recognise the need to have better maintained grammar, that
is more consistent and regular with easy to main documentation.
	
	Mark
	


		Some rules can be omitted if they coincide with Java's
own rules; just add an explanation.
		
		-W
		
		
		
		On 22 September 2010 14:56, Anstis, Michael (M.)
<manstis1 at ford.com> wrote:
		

			What was the service and was it the ANTLR
grammar you uploaded to
			generate the images?
			
			Thanks,
			
			Mike
			

			-----Original Message-----
			From: rules-dev-bounces at lists.jboss.org
			[mailto:rules-dev-bounces at lists.jboss.org] On
Behalf Of Wolfgang Laun
			Sent: 22 September 2010 13:38
			To: Rules Dev List
			Subject: [rules-dev] Drools syntax diagrams -
redrawn
			
			I've found this online service and stuffed the
Drools grammar into it.
			
			You may see the results while they are still
there:
	
http://www-cgi.uni-regensburg.de/~brf09510/syntax.tmp/x45371x0x0x.ebnf.h
			tml
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
f.h%0Atml> 
			
	
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
			f.html
<http://www-cgi.uni-regensburg.de/%7Ebrf09510/syntax.tmp/x45371x0x0x.ebn
%0Af.html> >
			
			-W
			
			
			
			_______________________________________________
			rules-dev mailing list
			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/20100922/d9554463/attachment-0001.html