From: SCAM 2009 Date: Tue, Jun 2, 2009 at 5:47 AM Subject: SCAM 2009 Notification To: Ralf Laemmel Dear Authors, Thank you for your submission to SCAM 2009, the IEEE 9th International Working Conference on Source Code Analysis and Manipulation, which is to be held in Edmonton, Canada on September 20-21, 2009. We are pleased to inform you that your submission has been accepted for presentation at SCAM 2009, and publication as a full paper in the conference proceedings. All papers went through a rigorous review process including an open virtual PC meeting. Every paper but one was reviewed in detail by at least three program committee members, and every decision was open for discussion by the entire committee before confirmation. In the end, out of 38 technical papers submitted, 17 were accepted, and 4 of 5 tools demonstrations were accepted. Each accepted paper will be presented in one of the technical sessions and, in the SCAM tradition, these will be grouped with two or three others in a themed discussion session led off with very short presentations of each of the papers. Registration will open in July - please see the conference web site for further information. http://www2009.ieee-scam.org/ There are three main steps remaining in the process: 1. Below you will find the detailed reviews of your paper. Please read the reviews carefully and the concerns raised into account in your final paper. In some cases certain revisions are required as a condition of acceptance, and you will receive a separate email from the program chairs outlining the required changes that must be satisfactorily performed before the paper can be included in the proceedings. 2. At least one of the paper's authors will be required to register for the conference in order for your paper to appear in the conference proceedings. Please send the name and contact information of the person who will be presenting your paper to Andrew Walenstein (walenste@ieee.org) by 30th June 2009, quoting your paper reference number in the title of the email. You can find your paper reference number in the reviews. Tools demonstrations will be receiving additional instructions from the Tools Demonstration Chair. 3. You will be receiving detailed information on submitting your final camera-ready paper from IEEE Press within the next week or so. Please see that your paper and copyright release are submitted within the strict deadlines set by IEEE in order that it may be included in the published proceedings. Full papers are limited to 10 pages in IEEE conference format, with no additional pages allowed. Congratulations again on having your paper accepted, and we look forward to seeing you in Edmonton in September. Best regards, Sibylle Schupp and Andrew Walenstein SCAM 2009 Program Chairs --------------------------------------------- Paper: 45 Title: Recovering Grammar Relationships for the Java Language Specification -------------------- review 1 -------------------- PAPER: 45 TITLE: Recovering Grammar Relationships for the Java Language Specification General comments: This is very nice work, clearly useful in an important area. We all wish that the JLS authors had had access to such a tool! My main reservation is that the well-reported case study is presented without enough context about the earlier work (and overall direction of the research) to help the reader understand all the implications of the study. Specific comments: The numbers appearing in citations are green when viewed in color, but print as very pale gray in monochrome; this made the citations very difficult to read in my hard copy. "SUN" -> "Sun Microsystems" Section 1: para 4: please define "liberal" here, as applied to grammars "Contributions": I'm unfamiliar with the term "sized grammars" Section 2.3: para 1: Table 2 doesn't "measure" anything; it displays metrics (what you measured). para 1: The observation about grammar differences being dominated by two characteristics is a good one and should be illuminated in the conclusions. Section 5: "leafs" -> "leaves" -------------------- review 2 -------------------- PAPER: 45 TITLE: Recovering Grammar Relationships for the Java Language Specification The paper presents an automated approach to comparing the different versions of the Java Language, using sophisticated grammar level transformations (partly developed by the authors themselves in previous work) to understand, extract and document the relationships between the different versions of the JLS. The work is clearly highly relevant to SCAM and (I believe) is a very important piece of work that should definitely be published. I see the work as having two aspects to it: 1. It acts as a detailed real world case study evaluation of the authors' previous work on grammar transformation 2. The work (clearly) has tremendous value in itself, as a document of the relationships between various incarnations of the JLS. I am not an expert in grammar(ware) engineering. Indeed, I did not know this phrase before reading the paper for this review. However, I have to say that as a (hopefully informed) outsider, I found this to be an interesting and very valuable paper (even an exciting paper, and that is quite high praise given that I come as an outsider and in our field outsiders seldom get excited about work not in their own field!). I also thought that the underlying philosophy, as I understand it, of grammarware engineering is a very sensible and timely one. I believe that grammars are increasingly important and that understanding the relationships between them is also very valuable and important work that deserves to be regarded as an important form of meta-SCAM. I have not kept pace with all the recent developments in parsing techniques, though I have been previously inspired by (one of) the authors work on island grammars and so I would defer to other referees concerning the novelty of this work. However, I would say that I personally found it to be a most interesting use of grammar transformation technology and I certainly have not seen work like this before. The authors claim originality and give a very compelling and cogent account of related work and I have no reason at all to doubt them on this point. The paper will be very useful to those who use Java (clearly) and also to language designers. It occurred to me that the approach could be combined with grammar extraction techniques that capture coding styles of different programmers to explore the relationship between programmers and sets or teams of programmers. Since I have little of value to say about the paper other than I feel that it is very exciting and important and should be accepted, I will spend a little time explaining this idea in case it is of interest to the authors. This is merely my attempt to add value with what would,otherwise, be a rather short (though positive) review! I wonder whether the authors have come across the work of Di Penta et al. on SBSE techniques for inferring sub- grammers from examples? This work essentially uses search based optimization to extract from a grammar and sets of instances, a subgrammer (actually specialized would be a better word, since the extracted grammar is not a "subset" of the production rules of the original). The extracted grammar captures the nuances of the programmers in a very clever way It allows us to understand and document the idiosyncrasies of the programers and also to explore their implicit guidelines on coding styles and such like. One can even, potentially, see how different programmers implement (or fail to) coding standards using this approach. One of the pleasing aspects is that it is all automated, since it uses SBSE to extract the specialised grammar from the programmers' code. If the authors are interested there are tow papers (and CMSR paper and a subsequent journal version): @inproceedings{DiPentaT05, author = {Massimiliano Di Penta and Kunal Taneja}, title = {Towards the Automatic Evolution of Reengineering Tools}, booktitle = {Proceedings of the 9th European Conference on Software Maintenance and Reengineering (CSMR '05),}, publisher = {IEEE Computer Society}, year = {2005}, pages = {241-244}, doi = {http://dx.doi.org/10.1109/CSMR.2005.52} } @article{DiPentaLTT08, author = {Massimiliano Di Penta and Pierpaolo Lombardi and Kunal Taneja and Luigi Troiano}, title = {Search-based Inference of Dialect Grammars}, journal = {Soft Computing - A Fusion of Foundations, Methodologies and Applications}, year = {2008}, volume = {12}, number = {1}, pages = {51-66}, doi = {http://dx.doi.org/10.1007/s00500-007-0216-5} } I was thinking that, based on this work, the authors approach could be applied as a complement to explore the relationships between the grammars found for different groups of programmers. We could extract various specialized grammars from sets of real coders (this has been done by Di Penta et al. I believe, or it could be using their approach) and then, we could us the authors' approach to understand the relationships between these coding styles. It may seem a bit of a leap, but this could have a number of interesting applications. Clearly it would be interesting in and of itself, to understand these relationships. However, we could also identify those programmers who have most opposing styles (perhaps in pair programming or other co-working situations these two programmers, or groups of programmers, should not be paired!). Also we could see how the same programmer evolved their style by extracting grammars (using the Di Penta approach) over time and using the Lammel and Zaytsev approach to understand their evolution. I hope that the authors find this idea interesting and that it make an otherwise rather dull but appreciative review a little more valuable to them. -------------------- review 3 -------------------- PAPER: 45 TITLE: Recovering Grammar Relationships for the Java Language Specification The paper addresses the problem of keeping consistency between different grammars for the same language, and how to consistently evolve several such grammars consistently as the language itself evolves. The authors are developing an algebra and tools for this purpose. The paper is nice, though it is not quite clear how it improves over their earlier work. In general the presentation seems somewhat light-weight compared to what they could present. I would like to see a complete presentation of their algebra of grammar transformations, and proofs of the claimed properties of these (section 3). It would also be useful if the authors would elaborate more on their experience on how to evolve languages and grammars. They have some side comments hinting on useful guidelines, but it should be possible to elaborate this. Gramamr problem: line 8-9 in section 4. Make certain that the colouring in Figure 2 also separates well on (bad) black and white printers. -------------------- review 4 -------------------- PAPER: 45 TITLE: Recovering Grammar Relationships for the Java Language Specification This paper describes a process to recover differences and ensure consistency between different versions of a grammar. Namely, the process is applied to the Java Language Specification Grammar. I think this is a very useful contribution for SCAM and in general for people dealing with source code analysis, as we are facing this kind of problem very often. Providing a systematic description of how to ensure consistency between grammars is surely helpful. I have a few comments that can be used to improve the paper: - In Section 3, you mention a set of operators. It's not clear whether these operators are specific for JLS or are they generalizable to other cases. If they are specific, how should I define a set of operators for a specific language (e.g., suppose I have to do the same for several COBOL or C dialects). Probably it would be useful to summarize in a table a sort of operator taxonomy. - Page 4: can you please better explain what the term "massage" means in the grammar terminology? At the end it is clear however I guess the reader is not used to such a term, while for instance other terms as "factoring" are more common. - I think the tricky part is how to decide what operator apply before and what after. Can you provide some guideline on how to proceed? It looks like this is a problem where the engineer has to search among possible solutions and sometimes stepping back because the application of an operator before the other is changing the grammar in the wrong direction. - What does it happen when the grammar adds a new terminal? A classical example is the "enum" keyword between Java grammars 1.4 and 1.5, I remember I had to deal with that to make a grammar able to parse both versions of the language - Section 4.1: you mention a tool-supported grammar comparison. How is it made? What kind of tool did you use? - Related work: you might want to mention other papers describing approaches aimed at recovering grammars, e.g.: Oscar Nierstrasz, Markus Kobel, Tudor Gîrba, Michele Lanza, Horst Bunke: Example-Driven Reconstruction of Software Models. CSMR 2007: 275-286 Massimiliano Di Penta, Pierpaolo Lombardi, Kunal Taneja, Luigi Troiano: Search-based inference of dialect grammars. Soft Comput. 12(1): 51-66 (2008) - Conclusions: you mention the productivity of engineers. This is a very important point. To what extend did the process you described help to improve productivity? How long did it take to perform the tasks described in the case study?