[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Feature request - I second it

Just a note to say that we are making use of ANTLR's functionality
to do just this in a product we are working on now.

It's very convenient to 
    	  Lexer lex =
    	    new Lexer(new ByteArrayInputStream(unParsed.getBytes()));
    	  Parser parse = new Parser(lex);

without needing to define multiple grammars.

If it is easy to implement, then I would say it is worth it.

Note: I don't officially speak for my employer

John D. Heintz
Software Engineer
Icon Computing, Inc.
(512) 258-8437

>-----Original Message-----
>From:	Archie Cobbs [SMTP:archie@whistle.com]
>Sent:	Sunday, August 16, 1998 7:29 PM
>To:	sablecc-list@sable.mcgill.ca
>Subject:	Re: Feature request
>Etienne Gagnon writes:
>> I've looked quickly at your suggestion. There are at least two ways of
>> achieving your requested functionality without modifying SableCC.
>> The idea is to first recognize that you need two different parsers.
>> The most common case (99,9% of SableCC users) is already handled by
>> It consists in simply using two different packages (and grammar files), one
>> for each parser/AST. This is easy enough, so I won't elaborate more.
>> The other solution is for the unlikely case you where have some need for
>> two parsers to share the same AST.
>Hmm.. your examples are good practical solutions to the problem;
>however, I was really wondering more in theoretical terms...
>The theoretical question being: how hard would it be to make the
>following code possible? (I don't actually need to do this right now,
>though it seems like a great feature to have (especially if you view
>SableCC as a 'competitor' to other compiler-generators))
>  InputStreamReader r = new InputStreamReader(System.in);
>  Parser p = new Parser(new Lexer(r), PSomeRandomProduction.class);
>  try {
>    PSomeRandomProduction ast = p.parse();
>  } catch (ParserException e) {
>    ...
>I mean, from a software designer's (ie, your) point of view (I've
>read the dreaded Dragon book (but it was a while ago)), how would
>the states and transitions have to be augmented for this to work?
>How would the standard compiler generation algorithm have to change?
>My guess is that this would require only a linear increase in the size
>of the automatically generated stuff, plus a few lines of new code.
>This would be a more elegant solution than your two proposals --
>which are perfectly valid as practical solutions, but really fall
>under the "workaround" category.
>Just to reiterate: I think SableCC is great and am perfectly happy
>with it for my application.. but the design and implementation of
>it are very cool and interesting in their own right, and I think
>could get even cooler. Even if nobody has the time to implement them,
>it's fun to think about what new features could be added, etc.
>Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com