[antlr-interest] RE: antlr-interest Digest, Vol 12, Issue 7

Damon Carr damon at agilefactor.com
Sun Nov 6 11:38:32 PST 2005


"Everytime I ask someone for an example for the use of Aspect Oriented 
Programming the only thing they can come up with is logging... "


What about run-time instrumentation of your application with no code? You
can write the status of every method call including parameter values and
names, time, machine, individual, etc. all with one AOP and should have the
ability to be turn off, typically. For production intelligence into the
run-time state of your applications it's the easiest 'no manual code'
technique I have found.

I all to often see developers deploying applications with no real
Instrumentation and have a 'logging' approach for exceptions. This is a very
'reactive' approach when instead , in addition to the AOP Instrumentation
(which, damn, I guess IS a form of logging (grin), you can add CPU Usage
(per processor), Network Bandwidth Utilization, Memory Usage and Page
Faults, etc.

This has allowed me in the past to monitor a family of servers and
applications via a command console (and you could use SNTP, WMI, or whatever
works) and PROACTIVELY see when trouble may be about to happen. Like the
server who's memory usage goes up linearly every week by 20MB (due to a
memory leek), or that you are CPU Bound typically around 9AM every day and
your requests/sec drop down to 2. So is this logging? Yes but it is more
then that. 

Another example.. IN .NET 1.0-1.1+ (pre 2.0) we had no type specific
collections (expect one for Strings). Therefore you had a problem with
boxing (a value type being stored in these collections always as a reference
type boxed on the managed heap) and no ability (unless you coded it) to
enforce the commonality of the Type(s) that were placed into these
collections.

I created an AOP Attribute that would automatically throw an exception if
the declarative types you specify in the attribute were not being placed in
the collection. There was no way to get around the boxing problem  really
(unless I somehow in my interception modified the storage Type from a
collection to Strongly Type array), but it was very useful to be able to
simply say:

[StronglyTypedCollectionAttribute(typeof(System.Guid),
typeof(System.String)]
This is synonymous in .NET:
[StronglyTypedCollection(typeof(System.Guid), typeof(System.String)]


For the Context Attribute the signature would be: 

StronglyTypedCollection(Type KeyType, Type ValueInCollectionType)

With an overload for simply ArrayList type collections of:

StronglyTypedCollection(Type ValueInCollectionType)

This full code sample is downloadable on www.gotdotnet.com under "Damon
Carr" I believe. Under 'User Samples'.

This would be for a qualified collection where the accessor key is a GUID
and the value is a String. So if I tried to say:

//Threadsafe for single line operations (but never for iteration)
public static Hashtable HashExample = Hashtable.Synchronized(new
Hashtable());

// Invalid Line
HashExample.Add(1533, new ArrayList());


This would throw an exception stating the Key was not a Guid and the Value
was not a String.

On a side note (I see this all too often) if you ARE dealing with a
multi-threaded static (for example) collection and iteration is occuring
remember YOU MUST use SyncRoot:

IDictionaryEnumerator Enumerator;
			
// Even with a synchronized collection 
// an exclusive lock is necessary for iteration
// I often see: lock(HashExample) which is useless and
// the cayuse of many 'mysterious' threading issues

lock(HashExample.SyncRoot)
{
	Enumerator = HashExample.GetEnumerator();
    
	while (Enumerator.MoveNext())
	{
		Trace.Assert(Enumerator.Key is Guid);
		Trace.Assert(Enumerator.Value is String);
	}


}


Sorry for the off-topic and ranting post.. Hope someone finds it usefull..

Kind Regards,
Damon Carr, CTO
agilefactor
www.agilefactor.com

-----Original Message-----
From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of
antlr-interest-request at antlr.org
Sent: Sunday, November 06, 2005 10:35 AM
To: antlr-interest at antlr.org
Subject: antlr-interest Digest, Vol 12, Issue 7

Send antlr-interest mailing list submissions to
	antlr-interest at antlr.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.antlr.org/mailman/listinfo/antlr-interest
or, via email, send a message with subject or body 'help' to
	antlr-interest-request at antlr.org

You can reach the person managing the list at
	antlr-interest-owner at antlr.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of antlr-interest digest..."


Today's Topics:

   1. Do we need an antlr tutorial (Suman Karumuri)
   2. Re: Do we need an antlr tutorial (Sohail Somani)
   3. Re: Do we need an antlr tutorial (Bryan Ewbank)
   4. Re: Serious Bug when using BitSet generation-Forgot:	USING
      ANTLR 2.7.5 !!!! (Terence Parr)
   5. Re: Serious Bug when using BitSetgeneration-Forgot (Terence Parr)
   6. action syntax proposal for v3 (Terence Parr)
   7. Re: action syntax proposal for v3 (Sebastian Mies)
   8. Re: action syntax proposal for v3 (Martin Probst)
   9. Re[2]: [antlr-interest] action syntax proposal for v3
      (Sebastian Mies)
  10. rule classDef trapped: unexpected token: IDENTIFIER
      (Peter-Frank Spierenburg)


----------------------------------------------------------------------

Message: 1
Date: Sun, 6 Nov 2005 04:39:00 +0530
From: Suman Karumuri <mansuk at gmail.com>
Subject: [antlr-interest] Do we need an antlr tutorial
To: antlr-interest at antlr.org
Message-ID:
	<c26541e00511051509l1dd9ed19h4c47ab51edb41aaf at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I have been working on antlr for the past one month and i have implemented a
version of hoc(as described in "The unix programming environment" by
kernighan and pike) using antlr and python.

This is a complete language with loops,conditionals and functions.
>From the tree parser i generate a byte code which is interpretted by
the interpretter. One advantage of this system over hoc is that it is easy
to learn when compared to hoc. However, there are some minor deviations from
the hoc described in the book.

So, is working on the program to convert into a tutorial worth the effort?If
there is some interest i can put in my spare time in writing the
tutorial.There are also some code clean ups that should be done.

-Suman


------------------------------

Message: 2
Date: Sat, 05 Nov 2005 15:28:30 -0800
From: Sohail Somani <sohail at taggedtype.net>
Subject: Re: [antlr-interest] Do we need an antlr tutorial
To: Suman Karumuri <mansuk at gmail.com>
Cc: antlr-interest at antlr.org
Message-ID: <1131233311.12163.1.camel at localhost.localdomain>
Content-Type: text/plain

On Sun, 2005-06-11 at 04:39 +0530, Suman Karumuri wrote:
> Hi all,
> 
> I have been working on antlr for the past one month and i have 
> implemented a version of hoc(as described in "The unix programming 
> environment" by kernighan and pike) using antlr and python.
> 
> This is a complete language with loops,conditionals and functions.
> >From the tree parser i generate a byte code which is interpretted by
> the interpretter. One advantage of this system over hoc is that it is 
> easy to learn when compared to hoc. However, there are some minor 
> deviations from the hoc described in the book.
> 
> So, is working on the program to convert into a tutorial worth the 
> effort?If there is some interest i can put in my spare time in writing 
> the tutorial.There are also some code clean ups that should be done.

Tutorials are always welcome, especially those with real applications.
The javadude antlr tutorial was awesome for this reason.

I vote yes.

Sohail



------------------------------

Message: 3
Date: Sat, 5 Nov 2005 19:12:08 -0500
From: Bryan Ewbank <ewbank at gmail.com>
Subject: Re: [antlr-interest] Do we need an antlr tutorial
To: ANTLR Interest <antlr-interest at antlr.org>
Message-ID:
	<dd3a065f0511051612y44db5969o58fcfe4ce98e6e71 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

[Sorry for the "me too", but...]

There's always more to be learned, especially from substantial tutorials and
examples.  Even if you can't post a complete /tutorial/, posting an
/example/ is a great start.  Tutorial later!

I look forward to seeing anything you can share!

On 11/5/05, Sohail Somani <sohail at taggedtype.net> wrote:
> On Sun, 2005-06-11 at 04:39 +0530, Suman Karumuri wrote:
> > So, is working on the program to convert into a tutorial worth the 
> > effort?If there is some interest i can put in my spare time in 
> > writing the tutorial.There are also some code clean ups that should be
done.
>
> Tutorials are always welcome, especially those with real applications.
> The javadude antlr tutorial was awesome for this reason.


------------------------------

Message: 4
Date: Sat, 5 Nov 2005 16:57:37 -0800
From: Terence Parr <parrt at cs.usfca.edu>
Subject: Re: [antlr-interest] Serious Bug when using BitSet
	generation-Forgot:	USING ANTLR 2.7.5 !!!!
To: ANTLR Interest <antlr-interest at antlr.org>
Message-ID: <30D96FF1-652A-41A0-AB9F-FF37D446E5DD at cs.usfca.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi.  I'm looking into this for 2.7.6 release imminent this weekish.

First, this is a bug in your grammar right:

> commonLibraryBlock3
>  : {isCategory}? libraryDeclarations
>  | {isCategory}? ( )

that 2nd production is impossible, right?

Now, you have a rule with:

  | {isProgram}? ( )         ****************   NOTE : These kind of  
empty productions FAIL to match an empty Production when using BITSET
generation !
  | {isCategory}? ( )
  | {isConstants}?   ( )

Now.  "( )" is not necessary, so remove those; extra code is generated I
think.

Your intent is to have an if-then-else chain with predicates tested, right?
ANTLR should remove all lookahead for the last n-1 productions as the
lookahead clearly is the FOLLOW(your rule) and therefore identical for all n
productions.  I'm stunned there is any lookahead even with no bitsets.
ANTLR should delete all lookahead for 2..n-1 productions.  Seems to me it's
a bug that it *does* work without bitsets.  I'm making an example.

Ter



------------------------------

Message: 5
Date: Sat, 5 Nov 2005 17:02:04 -0800
From: Terence Parr <parrt at cs.usfca.edu>
Subject: Re: [antlr-interest] Serious Bug when using
	BitSetgeneration-Forgot
To: ANTLR Interest <antlr-interest at antlr.org>
Message-ID: <FA9F0DE1-1ECE-4C68-8FCD-34D9CDC95B4E at cs.usfca.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

> Hopefully we can find a solution to this "Empty Pruction & BitSet 
> wrong code generation".
>
> It has kept my puzzling about errors in my grammar for a long long 
> time, but I have put off investigating it because there had been other 
> more important things to look at. However, I know had to solve it, and 
> it turned out to be a Bug !

Hi.  Here is my test case:

class T extends Parser;

x : A|C|D|E|F|G|H;

s : a b ;

// here is the rule of interest
a : B
   | {p1}? ( )
   | {p2}? ( )
   ;

b : A|D|F|G|H;

All is well.  It generates the following for rule a:

             if ((LA(1)==B)) {
                 match(B);
             }
             else if (((_tokenSet_1.member(LA(1))))&&(p1)) {
                 {
                 }
             }
             else if (((_tokenSet_1.member(LA(1))))&&(p2)) {
                 {
                 }
             }

clearly the bitsets are there.  Can you nail your bug down to a simple
grammar like this that fails?

I realized that ANTLR will not (as I said in last email) delete the
lookahead; it's smart enough to know that the predicates are only valid in
the right context and so it keeps the lookahead the same.

Thanks,
Ter


------------------------------

Message: 6
Date: Sat, 5 Nov 2005 17:14:54 -0800
From: Terence Parr <parrt at cs.usfca.edu>
Subject: [antlr-interest] action syntax proposal for v3
To: ANTLR Interest <antlr-interest at antlr.org>
Cc: stringtemplate-interest at antlr.org
Message-ID: <FA75639E-5CB9-4A17-BAD1-4E4CF75C81C1 at cs.usfca.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Howdy.

While Ric Klaren was here, he and I decided a change in syntax would be
useful for actions so that you can set code into more places in the output.
In fact, we'll be going further.  I think John Mitchell suggested that we
expose the code gen templates to the user so they can alter things as they
want without overrides and w/o creating a new output template file for
ANTLR.  For example, if you want to change how ANTLR generates code for
exception handling in rules, you might want to change the template once
rather than cut/paste it yourself manually with exception rule clauses.
Perhaps:

@rule.exception {
         reportError(re);
         recover(input,re);
}

where template rule has a region called exception; in StringTemplateGroup
notation (new for 2.3) you would do something similar so syntax is
consistent.  This may let us avoid an option that turns off exception
handling...you can just make rule.exception an empty action. :)

This provides flexibility.  In v2 we have named headers for C++ so you can
stick where you need it for C++.  I'm extending that to just be @name{...}.
Currently in v3 rule init actions are:

rulename
init {
  blort
}
	: 	...
	;

We'd change this syntax also so @ implies action:

rulename
@init {
  blort
}
	:	...
	;

I hate to use a valuable symbol like @ for this but it's consistent with
StringTemplateGroup's syntax, a good thing.

A grammar file might look like this:

grammar t;

@parser.header {
package org.antlr.foo;
}

@lexer.header {
package org.antlr.foo;
}

@parser.members {
int i; // parser needs this
}

@lexer.members {
int j; // lexer needs this, dude
}

a : ID {i++;} ;

ID : 'a'..'z'+ {j++;} ;

It's very explicit but a bit more typing.  What do you think?  I like it.
Tweaks?  Counter proposals?

Ter


------------------------------

Message: 7
Date: Sun, 6 Nov 2005 11:58:49 +0100
From: Sebastian Mies <sebastian.mies at gmx.net>
Subject: Re: [antlr-interest] action syntax proposal for v3
To: Terence Parr <parrt at cs.usfca.edu>
Cc: stringtemplate-interest at antlr.org,	ANTLR Interest
	<antlr-interest at antlr.org>
Message-ID: <285644472.20051106115849 at gmx.net>
Content-Type: text/plain; charset=us-ascii

Hi Terence,

this would be great!
There will be something like @rule.enter { } and @rule.exit { } I hope
;-)
I think adding some conditional generation would be nice too.
Something like:

@define(niceexceptions)
@if(niceexceptions) {
    @rule.exception { }
}

you could also add parameterization to grammars, like

grammar whatever(niceexceptions, ...)

this would avoid having multiple copies of a grammar, but reduce refactoring
capabilities.
It would also give the grammars a slight aspect-oriented touch.

Sebastian.

TP> Howdy.

TP> While Ric Klaren was here, he and I decided a change in syntax would 
TP> be useful for actions so that you can set code into more places in 
TP> the output.  In fact, we'll be going further.  I think John Mitchell 
TP> suggested that we expose the code gen templates to the user so they 
TP> can alter things as they want without overrides and w/o creating a 
TP> new output template file for ANTLR.  For example, if you want to 
TP> change how ANTLR generates code for exception handling in rules, you 
TP> might want to change the template once rather than cut/paste it 
TP> yourself manually with exception rule clauses.  Perhaps:

TP> @rule.exception {
TP>          reportError(re);
TP>          recover(input,re);
TP> }

TP> where template rule has a region called exception; in 
TP> StringTemplateGroup notation (new for 2.3) you would do something 
TP> similar so syntax is consistent.  This may let us avoid an option 
TP> that turns off exception handling...you can just make rule.exception 
TP> an empty action. :)

TP> This provides flexibility.  In v2 we have named headers for C++ so 
TP> you can stick where you need it for C++.  I'm extending that to just 
TP> be @name{...}.  Currently in v3 rule init actions are:

TP> rulename
TP> init {
TP>   blort
TP> }
TP>         :       ...
TP>         ;

TP> We'd change this syntax also so @ implies action:

TP> rulename
TP> @init {
TP>   blort
TP> }
TP>         :       ...
TP>         ;

TP> I hate to use a valuable symbol like @ for this but it's consistent 
TP> with StringTemplateGroup's syntax, a good thing.

TP> A grammar file might look like this:

TP> grammar t;

TP> @parser.header {
TP> package org.antlr.foo;
TP> }

TP> @lexer.header {
TP> package org.antlr.foo;
TP> }

TP> @parser.members {
TP> int i; // parser needs this
TP> }

TP> @lexer.members {
TP> int j; // lexer needs this, dude
TP> }

TP> a : ID {i++;} ;

TP> ID : 'a'..'z'+ {j++;} ;

TP> It's very explicit but a bit more typing.  What do you think? I like 
TP> it.  Tweaks?  Counter proposals?

TP> Ter



--
Best regards,
Sebastian                            mailto:sebastian.mies at gmx.net



------------------------------

Message: 8
Date: Sun, 06 Nov 2005 12:38:52 +0100
From: Martin Probst <mail at martin-probst.com>
Subject: Re: [antlr-interest] action syntax proposal for v3
To: Sebastian Mies <sebastian.mies at gmx.net>
Cc: stringtemplate-interest at antlr.org,	ANTLR Interest
	<antlr-interest at antlr.org>,	Terence Parr <parrt at cs.usfca.edu>
Message-ID: <436DEB4C.9090106 at martin-probst.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi,

> I think adding some conditional generation would be nice too.
> Something like:
> 
> @define(niceexceptions)
> @if(niceexceptions) {
>     @rule.exception { }
> }

Do I smell the C pre-processor and his macros-of-doom? I would be very 
careful to enable a macro-ish language aspect.

I would vote to rather provide specific options like this as runtime 
flags, e.g. "Parser.setContinueAfterErrors(true)". You really don't need 
a full blown macro compile-time language to provide such a small feature.

> It would also give the grammars a slight aspect-oriented touch.

Everytime I ask someone for an example for the use of Aspect Oriented 
Programming the only thing they can come up with is logging...

Martin


------------------------------

Message: 9
Date: Sun, 6 Nov 2005 13:09:42 +0100
From: Sebastian Mies <sebastian.mies at gmx.net>
Subject: Re[2]: [antlr-interest] action syntax proposal for v3
To: Martin Probst <mail at martin-probst.com>
Cc: ANTLR Interest <antlr-interest at antlr.org>
Message-ID: <154849433.20051106130942 at gmx.net>
Content-Type: text/plain; charset=us-ascii

Hi Martin,

>> I think adding some conditional generation would be nice too.
>> Something like:
>> 
>> @define(niceexceptions)
>> @if(niceexceptions) {
>>     @rule.exception { }
>> }

MP> Do I smell the C pre-processor and his macros-of-doom? I would be very
MP> careful to enable a macro-ish language aspect.
Well, actually this is no macro at all.

MP> I would vote to rather provide specific options like this as runtime
MP> flags, e.g. "Parser.setContinueAfterErrors(true)". You really don't need
MP> a full blown macro compile-time language to provide such a small
feature.
I did not suggest a full-blown macro engine. Its just a way to generate
different versions of one grammar - when a runtime solution is not
suitable. And I admit, that it IS a small feature.

>> It would also give the grammars a slight aspect-oriented touch.

MP> Everytime I ask someone for an example for the use of Aspect Oriented
MP> Programming the only thing they can come up with is logging...
Well, the alternative is having lots of macros.
And BTW: there are many cases where aspect-oriented programming can be
helpful - considering synchronized versions of datastructures,
creating primitive versions...
Just consider ArrayList in java: if you want an IntArrayList you would
have to write one by copy, paste, and replace - that could be solved
with a nice aspect or you have to use a transformation tool, like
inject/j ;-)

Sebastian.





------------------------------

Message: 10
Date: Sun, 06 Nov 2005 12:35:23 -0400
From: Peter-Frank Spierenburg <peter at fortha.org>
Subject: [antlr-interest] rule classDef trapped: unexpected token:
	IDENTIFIER
To: antlr-interest at antlr.org
Message-ID: <1131294923.26179.7.camel at greenlyph.fortha.org>
Content-Type: text/plain

Greetings,

The TreeParser in the following grammar is giving me some problems. I
would actually prefer to have resourceTypeIdentifier in place of
IDENTIFIER in the toSQL rule, but

"The root of a tree pattern must be a token reference, but the children
elements can even be subrules." from
http://www.antlr.org/doc/sor.html#_bb1

I'm not sure why that is, but I can play along.

Does anyone have any ideas what I might be doing wrong?

$ java -cp ~/lib/antlr-2.7.5.jar antlr.Tool Query.g
ANTLR Parser Generator   Version 2.7.5 (20050128)   1989-2005 jGuru.com
Query.g:17:12: rule classDef trapped:
Query.g:17:12: unexpected token: IDENTIFIER
error: aborting grammar 'QueryTreeWalker' due to errors
Exiting due to errors.


// Query.g
class QueryParser extends Parser;
options {
    buildAST = true;
}
propertyExpression : resourceExpression OP_PROPERTY^
propertyNameIdentifier ;
resourceExpression : resourceTypeIdentifier ( OP_REFERENCE^
propertyNameIdentifier )* ;
resourceTypeIdentifier : IDENTIFIER ;
propertyNameIdentifier : IDENTIFIER ;

class QueryLexer extends Lexer;
WHITESPACE : ( ' ' | '\t' | '\n' { newline(); } | '\r' )+
{ $setType(Token.SKIP); } ;
IDENTIFIER : ('A'..'Z' | 'a'..'z')+ ;
OP_REFERENCE : '/' ;
OP_PROPERTY : '@' ;

class QueryTreeWalker extends TreeParser;
toSQL : #( IDENTIFIER ) ;



------------------------------

_______________________________________________
antlr-interest mailing list
antlr-interest at antlr.org
http://www.antlr.org/mailman/listinfo/antlr-interest


End of antlr-interest Digest, Vol 12, Issue 7
*********************************************



More information about the antlr-interest mailing list