Hi Mitch:

>From wand@ccs.neu.edu Tue Dec 16 12:41:52 1997
>From: Mitchell Wand <wand@ccs.neu.edu>
>To: Karl Lieberherr <lieber@ccs.neu.edu>
>Cc: dem@ccs.neu.edu, jcurry@ccs.neu.edu, will@ccs.neu.edu
>Subject: Not jumping to conclusions [was: Eliminating the professor's code]
>
>I'm not sure it's fair to cite
>
>KL> 1. Professor does not have to prepare scanner and parser.
>KL>    Students master entire project from scratch.
>
>as an advantage of Demeter/Java.  Whether the professor prepares the scanner
>and parser or not is a pedagogical decision.  The instructor could equally
>well have asked the students to express the scanner and parser in Lex/Yacc or
>other scanner generator.  I do this in my PPL course.   The effort required to
>express the scanner/parser in Lex/Yacc or Demeter/Java is probably about the
>same. 
>
I think that the issue is that with Demeter/Java the objects (syntax trees)
are available so that they are "strategically traversable".
Lex/Yacc does not generate class definitions with traversal
code.

Luis Blando's project 
http://www.ccs.neu.edu/research/demeter/evaluation/gte-labs/
seems to indicate that to develop a parser with Demeter/Java is
easier than with Lex/Yacc.

JavaCC comes much closer to Demeter/Java. They now generate classes
and provide visitor support. So does the project by Jens Palsberg.
http://www.cs.purdue.edu/homes/taokr/jtb/tools.html

Demeter/Java is a step ahead by using strategies which Jens helped develop.
I don't know why they are not in JTB. What he has are default traversals which
can be changed by overriding.

>
>On a separate issue, John wrote:
>
>JC> The best measure of flexibility for my project is the time required to add
>JC> support for a new feature of the interpreter.  Towards the end of the 
>JC> project, after I had come up the learning curve of Demeter / Java, the
>JC> time to add a new feature (example, support for if/then/else, or while
>JC> loops) was literally measured in minutes.  I estimate that 30 minutes
>JC> would be sufficient time to update the .cd file, add code to any needed
>JC> visitors, modify traversals if needed, rebuild the system, and test.
>
>and Karl concluded:
>
>KL> 2. It is easy to add new features once a basic collection of 
>KL>    strategies and visitors are available. Programs are
>KL>    more flexible.
>
>John's experience supports the "it is easy" part, but does not allow one to
>conclude the "programs are more flexible" part.  More flexible than what?  How
>is flexibility measured?
>
>It would be interesting to compare the difficulty of adding these same
>features using other technology bases-- eg Scheme, C, or C++ .  My conjecture
>is that these are going to be pretty easy in any of these languages. Adding
>if/then/else or while to an interpreter is about a 10 minute exercise using
>the Scheme interpreters in 3351 (as I'm sure John remembers!).
>
>It's also worth mentioning, though Will might not agree with me, that
>compilers and interpreters (at this level of complexity) are fairly different
>creatures, and being able to do one of them easily does not necessarily imply
>that doing the other is equally easy. That's why we have compilers as a
>separate course. :)
>
John makes it clear that his comparison is based on all kinds of estimates.
And an interpreter is probably easier than a compiler.

Regarding flexibility, what John did is actually a family of interpreters.
He can take his interpreter without change and make all kinds
of interesting and uninteresting changes to the grammar and easily
create a new interpreter. A scheme implementation without strategies
would not have this flexibility.

You might ask: what is the use of such flexibility? It is likely
to add only simple new features. But those simple new features
are often stepping stones to the implementation of real new features
and it is a big help if the simple things are taken care of 
automatically.

>
>--Mitch,
>just trying to do good science.
>
Same goal for me.

-- Karl