Small reviewer issues
Look at reviews and fix all small comments
Reviewer 1
-
Figure 2 lacks axis labels, units, and the shifting is only explained much later in the paper. -
Talking about "all possible execution paths" without mentioning loops or recursion leaves questions open (some of which the paper never answers, as said above). -
Page 5: what are L
andS
? -
Section 3.1 fails to make clear that function calls (and component calls) are considered expressions (which also is non-standard, for expressions usually don't have side effects). -
i
is not a number ("While loops carry a numberi
.") - maybe "an integer-typed variable?" -
What is the initial state of a hardware component model? -
It is surprising that both sensors and terminals are considered "output-producing." A sensor, by definition, is a source of input. Now, of course, it produces output towards the software, but then a terminal would be "input-producing"?!
Reviewer 2
-
"in practise" -> "in practice" -
british english intermixed with american english - "software is analysed"
- "meant to analyze programs"
-
inconsistent use of "full stops" in figure captions -
inference rule names are bold in the text but not in their definitions -
widow line on page 11, club line on page 12 -
Figure 3: it is not clear why x
is assigned the result ofTERM.readInt()
-
Figure 4: more x-ticks would improve readability, e.g. for every other line number -
Figure 5: y-axis overlaps with labels (similar for figures 13 & 14) -
Start of Section 3: The type of the transition function (compared to Haskell) falls from heaven as the components are only defined later on. -
Section 7: incomplete sentence "It would give insight in..." -
References: [18] contains two URLs -
style decision: "The program in fig. 1" -> "The program in Fig. 1" (similar for sections, ...)
Reviewer 3
-
Figure 3 uses different font than Figure 1 (you switch the font repeatedly). Moreover, the textual description implies that the value of TERM.readInt() should be stored in x, but it is not. -
page 5: "this paper use" -> "this paper uses" -
In the second paragraph on page 5, you write the type of the transition function of component models, but you do not comment it at all (and individual components as L,S,... are also not mentioned anywhere around, only one page later). Is the formal definition of hardware component model really needed for the paper? (The main result works only with their symbolic mode.) -
In the syntax of SECA, the integer at the end of while loops is not sufficiently explained: I understand that you use it in semantics, but I'm not sure you really expect this number in the SECA programs (probably not as it is not in Figure 12). -
The last sentence before the paragraph on "Energy-aware semantics" (especially the part "on their own line") sounds like there is nothing else on a line that the listed elements. But this is not true. It wants to say that there cannot be two such elements on one line (if I'm right). -
page 7, line -3: "the variable name occurs" -> "the left-hand side of the assignment occurs" -
Please typeset figures on top or bottom of the page. Especially the one line above Fig. 10 and the one line below Algorithm 1 look weird. -
In the algorithm, the comments are marked too far on the left (It took me some time to recognize that there is "//"). Also, in "sky[i]", the part [i] is typeset in italics on some lines but not everywhere. Please unify it. -
In algorithm 1, continuation is not set up if the processed skyline element is J(.). Hence, the algorithms cannot detect open circle as described on page 14 (the conditions are never met) -
In algorithm 2, the topmost if-statement should be evaluated only if fragments[i] is not null (top improve performance of the algorithm). -
The third paragraph in section 7 ends with an unfinished sentence.
Edited by Markus Klinik