[antlr-interest] ANTLRWorks 2 (for ANTLR v4)

[Andreas Stefik]

Hi folks,

I'll offer a few thoughts. First, since you said to mention it, I
would hardly consider myself an antlr/antlrworks expert, but I have
used it extensively, have written multiple compilers, teach compiler
theory at the university level, and generally feel comfortable with
this stuff, even if I have a lot left to learn. I use ANTLRworks
typically on Mac OS X 10.6. Here's a general list, for good or ill,
that I would love to see in a future version:

Visualizations:

1. Keep any and all existing visualizations. My students (and I) love
this feature and use it extensively.

2. Allow the visualization window to "Pin" to the bottom, like most
IDE's do, effectively allowing it to auto hide.

3. Create a feature allowing you to click on a rule and generate a PS
or PDF (or something) file showing the visualization for that rule AND
all sub-rules. A figure such as this could get pretty big, but many of
my students tell this would make it easier for them to debug problems
that are related to multiple rules. It would be nice to be able to
even print a whole rule/subset out on a big plotter.

4. Possibly allow the user to select certain parts of a visualization.
For example, the most common problem I see students run into is that
they'll be using a tree walker, get an "Up" or "Down" token inserted
into the visualization, and they'll end up scratching their head as to
what that means. If they could theoretically "click on" one of those
tokens and get a reasonable English explanation, that could be
helpful.

Errors and Syntax:

1. By far my biggest annoyance with errors in antlrworks are that the
default editor delay is too fast. There are two problems: 1) studies
show this is not necessary (called liveness), as there are little user
benefits for key-stroke-by-keystroke checking while the user is
typing, 2) the constant checking is unnecessary usually and really
slows down typing performance. On some slow machines, the default
settings, which students often don't know they can change, are pretty
unbearable. I hear this complaint constantly from students.

This one has an easy fix. NetBeans, for example, only sends off a
check event IF the user has stopped typing for 0.5 seconds (they call
this the parsing and indexing loop). In other words, their update
delay is a measure that gets checked only after the last keystroke. It
never executes while you are typing. This works extremely well and is
a good compromise for fast typers and still gives you the benefit of
"near" liveness, which does have benefits.

In other words:
A. Wait till the user has stopped typing.
B. If <Update Delay> has passed, THEN do the check.

Similarly, 500 mseconds is the default from NetBeans and I think that
also diminishes slowdowns.

2. It would be nice if the Errors/warnings/etc in the console could be
set to automatically clear itself out when you click generate,
especially if the grammar generates successfully. Maybe you can, but I
don't see the setting.

3. It might be nice if the popup window saying whether the grammar
generated successfully/not was off by default. I have observed that
most of my beginner students ignore the box (without reading it), then
click on the console to see what happened.

Code completion:

1. It would be nice if when you typed $, that it popped up a list of
what things are legal.

2. Similarly, for a given target, it would be really, really, nice
(although perhaps challenging, I recognize) if you could take a rule
like this:

access_modifier returns [AccessModifierEnum amEnum]
	:	PUBLIC
	{
		$amEnum = $amEnum.PUBLIC;
	}
	|	PRIVATE
	{
		$amEnum = $amEnum.PRIVATE;
	}
	;

Type $amEnum. (with nothing after) and have it pull up what is
actually legal for that target class.

3. In the "options" area of a grammar:

options {
	tokenVocab=Quorum;
	ASTLabelType=CommonTree;
	output = template;
}

if would be nice if pressing code completion (I forget the key),
pulled up a list of the possible options for the left hand side,
guiding you through the choices or at least giving you a list and the
documentation for them.

Debugger:

I'll admit that I don't really use the debugger. I have before and I
really like it, but most of the projects I do require that you
integrate into the build cycle of projects in the NetBeans development
environment. In practice, I've never found a way I can really run the
debugger, with all of my complicated build information set together
(e.g., tricky dependencies, ant scripts) in such a way that it is
worth the effort.

General user interface considerations:

1. It would be nice if the preferences window followed the standard
paradigm of an Apply, Ok, and Cancel buttons. If no settings need to
be changed, the apply button is greyed out.

2. Most of my students generate antlr code in the same folder as the
grammar, so it might be nice if the output path was the empty string
by default. Others may prefer it the way it is.

3. It would be nice if the font for targets was slightly darker by
default, as I find it somewhat difficult to read.

4. It would be nice if comments (Options -> Syntax -> comments) were a
different color by default. Something subtle, but different then grey,
so it stands out some.

Wish list:

It would be great if there were a NetBeans platform plugin that
integrated all of the great stuff about antlrworks into that IDE.
There is a plugin out there, and it's nice, but the last I checked it
lacked visualizations, the debugger, the interpreter, didn't allow you
to generate the java code from your grammar, and all of the other
features which make antlrworks such a great tool to use.


I don't know if that helps at all, but Antlrworks is a great tool and
I'm looking forward to seeing what you guys come up with. Hopefully
that at least gives you a few ideas to chew on as you go into the next
development cycle.

Andreas Stefik, Ph.D.
Assistant Professor
Department of Computer Science
Southern Illinois University Edwardsville