[antlr-interest] Access to lexer warning/error messages after parsing

[Loring Craymer]

I think that there is even a good way to do this.  First, adopt the ErrorManager mechanism from the ANTLR 3 source, abstracting a base class and building a tool that maps string templates to error  numbers and generates custom ErrorManagers.  Secondly, add a stringtemplate compiler (StringTemplate is currently limited in its targets); a compiled string template group could be a class that (for Java) looks like:
class Foo extends TemplateGroup {
int index;
HashMap<String, Object> fields;
static HashSet<String>[] legalFields = { ... }
public Object getAttribute(String name) {
    if (legalFields[index].contains(name))
         return fields.get(name);
   else
      // throw exception
 }
public Object setAttribute(String name, Object value) {
     if (legalFields[index].contains(name)
        fields.put(name, value);
    else
       // throw exception
}
// ToString methods; names taken from template defs
protected String foo() {  // example
    String retval = "text1 " + fields.get("bar").toString() + "text2 ";
    return retval;
}
toString() {
    switch (index) {
        ...
    }
}
}
and the source template group would look like
group Foo;
foo(bar) ::= "text1 <bar>text2"
...
There would also have to be some machinery to support context variables (table management not shown), but this is fairly doable in a short amount of time.  I have these on my "to do" list for Yggdrasil.
--Loring



----- Original Message ----
> From: Andy Tripp <antlr at jazillian.com>
> To: Jim Idle <jimi at temporal-wave.com>
> Cc: antlr-interest at antlr.org
> Sent: Tuesday, July 1, 2008 1:25:55 PM
> Subject: Re: [antlr-interest] Access to lexer warning/error messages after parsing
> 
> Jim Idle wrote:
> 
> > No need to go into a long conversations about this, but placing the 
> > messages in a collection would then just hide them away. 
> 
> What's being suggested is to have ANTLR store the error in some data structure,
> then ANTLR can call toString() on that and send to stderr, as it does today.
> ...and then just provide access to the data structure.
> 
> > So, they would 
> > just sit there and the users would not even know there WERE any 
> > messages. So, then you have to supply... errr... a method to print them 
> > out. 
> ANTLR would supply that, as it does today.
> 
> > Then you have to override that method to print them out in the way 
> > you want. 
> 
> Yes, if you want to print it in a different way (unlikely).
> 
> > Then one finds that the information in the collection isn't 
> > quite what you want, 
> 
> Yes, that's always a potential problem.
> 
> > or that most people want the messages to print as 
> > they occur, so now there are two methods that you might need to 
> > override.. So, you are back to square one, or maybe worse. In short, 
> > while I don't think that collection the messages is bad idea at all (I 
> > do it myself), my feeling is that creating the collection would actually 
> > complicate things for new users, not simplify them.
> 
> The choice is between:
> today: getting a message sent to stderr, override ANTLR-generated code if that's 
> not good enough
> proposed: getting a message sent to stderr, having access to the error in
>   a data structure, override ANTLR-generated code if that's not good enough
> 
> > 
> > At the end of the day though, if that's what most people wanted and Ter 
> > thought it to be a reasonable request, then I certainly would not object 
> > to it.
> > 
> > Jim
> 
> The situation is analogous to Java stack traces.
> At first, the JVM would just spit out the stack trace as text on an exception.
> Now, it does the same thing, but also gives the programmer the ability to
> access the stack trace as a data structure.
> 
> Andy