Bugzilla – Full Text Bug Listing
| Summary: | Errata in EpsilonBook.pdf, 29-Nov-2010 (mostly typos) | ||
|---|---|---|---|
| Product: | [Modeling] Epsilon | Reporter: | Konrad Schwarz <konrad.schwarz> |
| Component: | Core | Assignee: | Antonio Garcia-Dominguez <agarcdomi> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | agarcdomi, dkolovos |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | interim | ||
The syntax for collection literals (e.g., Sequence { 1, 2, 3, 4, 5 } isn't formally defined.
The syntax for other literals (e.g. strings, including escape sequences, etc.) isn't defined either.
The form of comments aren't defined.gT
Many thanks for pointing out these issues. p 74,, 3rd para: s/ivnariants/invariants/ The EVL chapter does not show the concrete syntax of pre and post blocks. If the syntax is the same as in ETL, you could reference Listing 5.2. Listing 4.4, 4.5, 4.6: Braces, colons, and at signs need to be emboldened, since they are part of the concrete syntax. The concrete syntax of critique levels is not shown. (In reply to comment #5) > Listing 4.4, 4.5, 4.6: Braces, colons, and at signs need to be emboldened, > since they are part of the concrete syntax. You are probably using a listing package that emboldens keywords. Perhaps you could mark up "templates" (akin to EBNF productions) differently, to make the distinction between terminals and non-terminal clear. (In reply to comment #5) > Listing 4.4, 4.5, 4.6: Braces, colons, and at signs need to be emboldened, > since they are part of the concrete syntax. You are probably using a listing package that emboldens keywords. Perhaps you could mark up "templates" (akin to EBNF productions) differently, to make the distinction between terminals and non-terminal clear. Listing 4.4 omits guards from contexts. Listing 4.6 falsely allows guards in fixes. However, I find guarded fixes useful: a fix might not always be applicable. Real numbers do not support exponents. This should be documented or fixed in the implementation. I have resolved most of the minor issues which didn't affect the implementation. There are still a few things to do, though: - I'm afraid that using an EBNF for the EOL abstract syntax may confuse readers into thinking that is the actual concrete syntax. - I have looked at the code and I didn't find the actual typeOf keyword. Do we really support it? - We still need to write the section on literals, but I'd like to integrate the patch in #340669 before doing that. - I still need to check if the syntax for pre/post blocks is the same for ETL and EVL. I think they are the same, as I believe it is defined in a common ancestor, ERL. - I also have to inspect the code handling the EVL critique levels to write that part. - We have a bug for fix guards: #286148 - I'll have a look at the real number handling code. I have improved EOL's support for real literals, as shown in bug #346641: https://bugs.eclipse.org/bugs/show_bug.cgi?id=346641 I will shortly add a section on literals to the Epsilon book. I have added a section to the EOL book on literals. I'll work a bit more on the other issues during the next week. Conferences and other things got the better of me. I've looked at some of the pending issues: (In reply to comment #11) > - I have looked at the code and I didn't find the actual typeOf keyword. Do we > really support it? I still can't find any reference to typeOf except in the EvlEditor class, which highlights it as a keyword. Should we simply remove this keyword from the editor and the documentation? > - I still need to check if the syntax for pre/post blocks is the same for ETL > and EVL. I think they are the same, as I believe it is defined in a common > ancestor, ERL. They are the same. I have copied the pre/post concrete syntax from ETL over to EML and ECL. > - I also have to inspect the code handling the EVL critique levels to write > that part. Just like typeOf, it is mentioned in the book, but it is not implemented. Is it worth implementing? Should I remove it from the documentation? > - We have a bug for fix guards: #286148 I'll work on it a bit now, seeing as we have a recent comment on it (August 23rd). I have implemented fix guards in EVL, so there's only typeOf and the critique levels left. Should we implement them, or should we remove them from the Epsilon book? I'm happy with removing them from the book (limiting the range of types can always be done in the guard) I've removed all mentions of typeOf and critique levels in the book. I think we can close this bug now. Fixed in 1.0 |
24, Figure 3.1: personally, I find EBNF much easier to read than class diagrams. (Not an erratum.) p 25. It is not immediately clear that the context-type of an operation is specified after the keyword operation and the return type is specified after the final colon (Listing 3.1 uses Integer for both the context and the return type). The self special variable should be explained. p 25., 2nd para: s/Therefore, in line 3/Therefore, in line 1/ p 27., Listing 3.4 I find this ambiguous: do the parenthesis belong to the concrete sytax or do they group the regular expression? @ should be bold to clarify that this is a terminal symbol (as should $ in Listing 3.5). p 38. after definition of "excluding(item : Any)": s/hline/\\hline/ p 39. s/Also, EOL collection support/Also, EOL collections support/ p 60., Table 3.15, chooseMany s/to select one/to select one or more/ p 78, Listing 4.8 I could not find a definition of the typeOf keyword. p 96. s/In line 4/In line 5/ p 144. s/displayed in Figurer/displayed in Figure/ p 147. s/The Nodes merge rule In line/The \\emph{MergeNodes} rule in line/ p 152. s/explicit variables (matching CT, matchingAT/explicit variables (matchingCT, matchingAC/