* Ada grammar rules for names too permissive? @ 2018-12-29 18:20 olivermkellogg 2018-12-31 21:45 ` Randy Brukardt 2019-01-01 19:46 ` Stephen Leake 0 siblings, 2 replies; 22+ messages in thread From: olivermkellogg @ 2018-12-29 18:20 UTC (permalink / raw) Hi, RM section 3.2.2 defines subtype_mark ::= (subtype_)name where (subtype_) is subtype_ rendered in italics, i.e. essentially subtype_mark ::= name This looks overly permissive to me, considering 4.1 name ::= direct_name | explicit_dereference | indexed_component | slice | selected_component | attribute_reference | type_conversion | function_call | character_literal | qualified_expression | generalized_reference | generalized_indexing | target_name The AARM elaborates in paragraph 4a: *Ramification*: Note that name includes attribute_reference; thus, S'Base can be used as a subtype_mark. My question is, why is subtype_mark not defined as follows: compound_name ::= identifier { . identifier } subtype_mark ::= compound_name [ ' Base ] Similarly, RM section 10.1.1 defines parent_unit_name ::= name Here my question also applies, why not parent_unit_name ::= compound_name - Oliver (currently fighting ambiguities in the ANTLR grammar caused by laxity of rules) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2018-12-29 18:20 Ada grammar rules for names too permissive? olivermkellogg @ 2018-12-31 21:45 ` Randy Brukardt 2019-01-01 8:44 ` Dmitry A. Kazakov 2019-01-01 19:46 ` olivermkellogg 2019-01-01 19:46 ` Stephen Leake 1 sibling, 2 replies; 22+ messages in thread From: Randy Brukardt @ 2018-12-31 21:45 UTC (permalink / raw) Ada semantic rules use the syntax rules and vice versa. In this case, one does not want to repeat the various rules for interpreting an expanded name (which are part of selected_component). In this particular case, the resolution rule for subtype_mark eliminates any nonsense cases. There's also two practical considerations: one is that with typical grammar generators, you usually have to allow more syntax than you want, as differentiating between options requires essentially unlimited lookahead. (Most grammar generators use a single token lookahead.) In this case, you would have a lot of trouble telling between a type conversion and an indexed component, if the prefix syntax was different for each. Secondly, error detection for generated grammars tends to be less understandable than hand written error handling. (My understanding is that this is a major reason why GNAT uses a hand-written parser.) So allowing too much syntactically allows providing better error messages. For instance, one could easily require "others" to stand alone with your grammar. However, if you do that, the error message ends up being something like "unexpected |", which is not very helpful. Randy. <olivermkellogg@gmail.com> wrote in message news:30ba8954-a19e-4c95-b350-798b0276db41@googlegroups.com... > Hi, > > RM section 3.2.2 defines > > subtype_mark ::= (subtype_)name > > where (subtype_) is subtype_ rendered in italics, i.e. essentially > > subtype_mark ::= name > > This looks overly permissive to me, considering 4.1 > > name ::= > direct_name | explicit_dereference > | indexed_component | slice > | selected_component | attribute_reference > | type_conversion | function_call > | character_literal | qualified_expression > | generalized_reference | generalized_indexing > | target_name > > The AARM elaborates in paragraph 4a: > > *Ramification*: Note that name includes attribute_reference; thus, S'Base > can be used as a subtype_mark. > > My question is, why is subtype_mark not defined as follows: > > compound_name ::= identifier { . identifier } > > subtype_mark ::= compound_name [ ' Base ] > > > Similarly, RM section 10.1.1 defines > > parent_unit_name ::= name > > Here my question also applies, why not > > parent_unit_name ::= compound_name > > > - Oliver > (currently fighting ambiguities in the ANTLR grammar caused by laxity of > rules) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2018-12-31 21:45 ` Randy Brukardt @ 2019-01-01 8:44 ` Dmitry A. Kazakov 2019-01-01 19:49 ` Stephen Leake 2019-01-03 22:39 ` olivermkellogg 2019-01-01 19:46 ` olivermkellogg 1 sibling, 2 replies; 22+ messages in thread From: Dmitry A. Kazakov @ 2019-01-01 8:44 UTC (permalink / raw) On 2018-12-31 22:45, Randy Brukardt wrote: > Ada semantic rules use the syntax rules and vice versa. In this case, one > does not want to repeat the various rules for interpreting an expanded name > (which are part of selected_component). > > In this particular case, the resolution rule for subtype_mark eliminates any > nonsense cases. > > There's also two practical considerations: one is that with typical grammar > generators, you usually have to allow more syntax than you want, as > differentiating between options requires essentially unlimited lookahead. > (Most grammar generators use a single token lookahead.) In this case, you > would have a lot of trouble telling between a type conversion and an indexed > component, if the prefix syntax was different for each. > > Secondly, error detection for generated grammars tends to be less > understandable than hand written error handling. (My understanding is that > this is a major reason why GNAT uses a hand-written parser.) So allowing too > much syntactically allows providing better error messages. > > For instance, one could easily require "others" to stand alone with your > grammar. However, if you do that, the error message ends up being something > like "unexpected |", which is not very helpful. This discussion repeats each year! (:-() Maybe it is worth to write somewhere in c.l.a: attention! Ada needs no grammar generators! Never push semantic rules into syntax. The grammar as written is never the one actually used for whatever purpose other than explanation or, maybe, validation. An extreme case illustrating why, is source code coloring, but applies to compilers just same. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-01 8:44 ` Dmitry A. Kazakov @ 2019-01-01 19:49 ` Stephen Leake 2019-01-01 20:42 ` Dmitry A. Kazakov 2019-01-03 22:39 ` olivermkellogg 1 sibling, 1 reply; 22+ messages in thread From: Stephen Leake @ 2019-01-01 19:49 UTC (permalink / raw) On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote: > The grammar as written is never the one actually used for whatever > purpose other than explanation or, maybe, validation. An extreme case > illustrating why, is source code coloring, On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P. I'm sure there are other examples that illustrate your point. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-01 19:49 ` Stephen Leake @ 2019-01-01 20:42 ` Dmitry A. Kazakov 2019-01-02 19:21 ` Stephen Leake 0 siblings, 1 reply; 22+ messages in thread From: Dmitry A. Kazakov @ 2019-01-01 20:42 UTC (permalink / raw) On 2019-01-01 20:49, Stephen Leake wrote: > On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote: >> The grammar as written is never the one actually used for whatever >> purpose other than explanation or, maybe, validation. An extreme case >> illustrating why, is source code coloring, > > On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P. In which case it should not work with syntactically incorrect programs. The grammar describing a reasonably good color schema and the grammar describing syntactically correct Ada programs must be sufficiently different. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-01 20:42 ` Dmitry A. Kazakov @ 2019-01-02 19:21 ` Stephen Leake 2019-01-02 20:47 ` Dmitry A. Kazakov 0 siblings, 1 reply; 22+ messages in thread From: Stephen Leake @ 2019-01-02 19:21 UTC (permalink / raw) On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote: > On 2019-01-01 20:49, Stephen Leake wrote: > > On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote: > >> The grammar as written is never the one actually used for whatever > >> purpose other than explanation or, maybe, validation. An extreme case > >> illustrating why, is source code coloring, > > > > On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P. > > In which case it should not work with syntactically incorrect programs. No, it has error correction to deal with that. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-02 19:21 ` Stephen Leake @ 2019-01-02 20:47 ` Dmitry A. Kazakov 2019-01-03 21:45 ` Stephen Leake 0 siblings, 1 reply; 22+ messages in thread From: Dmitry A. Kazakov @ 2019-01-02 20:47 UTC (permalink / raw) On 2019-01-02 20:21, Stephen Leake wrote: > On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote: >> On 2019-01-01 20:49, Stephen Leake wrote: >>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote: >>>> The grammar as written is never the one actually used for whatever >>>> purpose other than explanation or, maybe, validation. An extreme case >>>> illustrating why, is source code coloring, >>> >>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P. >> >> In which case it should not work with syntactically incorrect programs. > > No, it has error correction to deal with that. Ada grammar contains no correction productions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-02 20:47 ` Dmitry A. Kazakov @ 2019-01-03 21:45 ` Stephen Leake 2019-01-03 22:34 ` Jere 2019-01-04 8:53 ` Dmitry A. Kazakov 0 siblings, 2 replies; 22+ messages in thread From: Stephen Leake @ 2019-01-03 21:45 UTC (permalink / raw) On Wednesday, January 2, 2019 at 12:47:22 PM UTC-8, Dmitry A. Kazakov wrote: > On 2019-01-02 20:21, Stephen Leake wrote: > > On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote: > >> On 2019-01-01 20:49, Stephen Leake wrote: > >>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote: > >>>> The grammar as written is never the one actually used for whatever > >>>> purpose other than explanation or, maybe, validation. An extreme case > >>>> illustrating why, is source code coloring, > >>> > >>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P. > >> > >> In which case it should not work with syntactically incorrect programs. > > > > No, it has error correction to deal with that. > > Ada grammar contains no correction productions. True for LRM Annex P, and also for Emacs ada.wy, but irrelevant. For LR parsers, there are error correction algorithms that do not require modifying the grammar. Emacs ada-mode uses the McKenzie algorithm (1); exploration of the parse table near the error location, combined with the redundancy of the Ada language (especially named blocks). One of these days I'll have to write a paper on it ... Meanwhile, it works quite nicely for me, and I'm waiting to hear from more people on how it works for them (a few positive responses so far, no negative). (1) McKenzie, Bruce J., Yeatman, Corey, and De Vere, Lorraine. Error repair in shift reduce parsers. ACM Trans. Prog. Lang. Syst., 17(4):672-689, July 1995. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-03 21:45 ` Stephen Leake @ 2019-01-03 22:34 ` Jere 2019-01-05 18:46 ` Stephen Leake 2019-01-04 8:53 ` Dmitry A. Kazakov 1 sibling, 1 reply; 22+ messages in thread From: Jere @ 2019-01-03 22:34 UTC (permalink / raw) On Thursday, January 3, 2019 at 5:05:34 PM UTC-5, Stephen Leake wrote: > On Wednesday, January 2, 2019 at 12:47:22 PM UTC-8, Dmitry A. Kazakov wrote: > > On 2019-01-02 20:21, Stephen Leake wrote: > > > On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote: > > >> On 2019-01-01 20:49, Stephen Leake wrote: > > >>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote: > > >>>> The grammar as written is never the one actually used for whatever > > >>>> purpose other than explanation or, maybe, validation. An extreme case > > >>>> illustrating why, is source code coloring, > > >>> > > >>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P. > > >> > > >> In which case it should not work with syntactically incorrect programs. > > > > > > No, it has error correction to deal with that. > > > > Ada grammar contains no correction productions. > > True for LRM Annex P, and also for Emacs ada.wy, but irrelevant. For LR parsers, there are error correction algorithms that do not require modifying the grammar. Emacs ada-mode uses the McKenzie algorithm (1); exploration of the parse table near the error location, combined with the redundancy of the Ada language (especially named blocks). > > One of these days I'll have to write a paper on it ... > > Meanwhile, it works quite nicely for me, and I'm waiting to hear from more people on how it works for them (a few positive responses so far, no negative). > > (1) McKenzie, Bruce J., Yeatman, Corey, and De Vere, > Lorraine. Error repair in shift reduce parsers. ACM Trans. Prog. > Lang. Syst., 17(4):672-689, July 1995. Is there a guide on how to manually update the Ada mode part of emacs? I have a slightly older version, but it doesn't list ada mode in emacs when I go through the normal update procedure. I can't really update emacs itself due to IT policies but was hoping to test out the newer Ada mode fixes at some point. In the version I have, it has trouble with things like expression functions (situations where you have "is" but no "begin/end" blocks). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-03 22:34 ` Jere @ 2019-01-05 18:46 ` Stephen Leake 2019-01-07 11:11 ` J-P. Rosen 0 siblings, 1 reply; 22+ messages in thread From: Stephen Leake @ 2019-01-05 18:46 UTC (permalink / raw) On Thursday, January 3, 2019 at 2:34:41 PM UTC-8, Jere wrote: > > Is there a guide on how to manually update the Ada mode part of emacs? The original Emacs Ada mode is a "built-in package"; it is included in the installation tarball. The latest version is a "GNU ELPA package"; it can be installed in any Emacs version >= 25.0. To install, execute M-x list-packages, search for "ada-mode", type 'i' for Install, 'x' for execute. Wait for Emacs to contact the ELPA server and install the package. Then restart Emacs (to ensure everything got done correctly). > I > have a slightly older version, but it doesn't list ada mode in emacs > when I go through the normal update procedure. What do you mean by "the normal update procedure"? If that means 'list-packages' as I said above, then something (presumably your site administrator) has redirected the default package archive; `package-archives' must include ("gnu" . "https://elpa.gnu.org/packages/"). In that case, ask the site admin to include ada-mode in the local archive. If that fails, you'll have to install from source. The simplest approach to that is to check out the git worktree for elpa. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-05 18:46 ` Stephen Leake @ 2019-01-07 11:11 ` J-P. Rosen 2019-01-08 18:58 ` Stephen Leake 0 siblings, 1 reply; 22+ messages in thread From: J-P. Rosen @ 2019-01-07 11:11 UTC (permalink / raw) Le 05/01/2019 à 19:46, Stephen Leake a écrit : > The latest version is a "GNU ELPA package"; it can be installed in > any Emacs version >= 25.0. > > To install, execute M-x list-packages, search for "ada-mode", type > 'i' for Install, 'x' for execute. Wait for Emacs to contact the ELPA > server and install the package. Then restart Emacs (to ensure > everything got done correctly). > Just did that with Emacs 26.1/Windows 10, and it fails with: package--check-signature-content: Failed to verify signature: "ada-mode-6.0.1.tar.sig" What's wrong? -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-07 11:11 ` J-P. Rosen @ 2019-01-08 18:58 ` Stephen Leake 0 siblings, 0 replies; 22+ messages in thread From: Stephen Leake @ 2019-01-08 18:58 UTC (permalink / raw) On Monday, January 7, 2019 at 3:11:45 AM UTC-8, J-P. Rosen wrote: > Le 05/01/2019 à 19:46, Stephen Leake a écrit : > > The latest version is a "GNU ELPA package"; it can be installed in > > any Emacs version >= 25.0. > > > > To install, execute M-x list-packages, search for "ada-mode", type > > 'i' for Install, 'x' for execute. Wait for Emacs to contact the ELPA > > server and install the package. Then restart Emacs (to ensure > > everything got done correctly). > > > Just did that with Emacs 26.1/Windows 10, and it fails with: > package--check-signature-content: Failed to verify signature: > "ada-mode-6.0.1.tar.sig" > > What's wrong? > There must have been a glitch downloading the files - I just tried and it worked for me. So try again. I'm not sure how well the packages tool cleans up after this error - you may have to manually delete files in ~/.emacs.d/elpa Note that to get the error-correcting parser, you have to manually compile Ada code - see ada-mode.info. -- Stephe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-03 21:45 ` Stephen Leake 2019-01-03 22:34 ` Jere @ 2019-01-04 8:53 ` Dmitry A. Kazakov 1 sibling, 0 replies; 22+ messages in thread From: Dmitry A. Kazakov @ 2019-01-04 8:53 UTC (permalink / raw) On 2019-01-03 22:45, Stephen Leake wrote: > On Wednesday, January 2, 2019 at 12:47:22 PM UTC-8, Dmitry A. Kazakov wrote: >> On 2019-01-02 20:21, Stephen Leake wrote: >>> On Tuesday, January 1, 2019 at 12:42:36 PM UTC-8, Dmitry A. Kazakov wrote: >>>> On 2019-01-01 20:49, Stephen Leake wrote: >>>>> On Tuesday, January 1, 2019 at 12:44:17 AM UTC-8, Dmitry A. Kazakov wrote: >>>>>> The grammar as written is never the one actually used for whatever >>>>>> purpose other than explanation or, maybe, validation. An extreme case >>>>>> illustrating why, is source code coloring, >>>>> >>>>> On the contrary, Emacs Ada mode source code coloring uses a generated parser for the Ada language, with only minimal changes from Annex P. >>>> >>>> In which case it should not work with syntactically incorrect programs. >>> >>> No, it has error correction to deal with that. >> >> Ada grammar contains no correction productions. > > True for LRM Annex P, and also for Emacs ada.wy, but irrelevant. For LR parsers, there are error correction algorithms that do not require modifying the grammar. Emacs ada-mode uses the McKenzie algorithm (1); exploration of the parse table near the error location, combined with the redundancy of the Ada language (especially named blocks). Regardless how good or bad that works, it is not the grammar that is actually in use. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-01 8:44 ` Dmitry A. Kazakov 2019-01-01 19:49 ` Stephen Leake @ 2019-01-03 22:39 ` olivermkellogg 2019-01-04 8:58 ` Dmitry A. Kazakov 2019-01-05 18:50 ` Stephen Leake 1 sibling, 2 replies; 22+ messages in thread From: olivermkellogg @ 2019-01-03 22:39 UTC (permalink / raw) On Tuesday, January 1, 2019 at 9:44:17 AM UTC+1, Dmitry A. Kazakov wrote: > [...] > Never push semantic rules into syntax. I'm not so sure about that: A nice feature of ANTLR is that is supports semantic predicates which can be embedded in the grammar. For example, using sem preds on the basis of symbol tables would permit discerning among indexed_component, type_conversion, function_call. > The grammar as written is never the one actually used for whatever > purpose other than explanation or, maybe, validation. The interesting question IMO is: What are the necessary transformations for going from Annex P BNF plus informal description of semantic rules to the actual implementation grammar. - Oliver ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-03 22:39 ` olivermkellogg @ 2019-01-04 8:58 ` Dmitry A. Kazakov 2019-01-05 8:45 ` Randy Brukardt 2019-01-05 18:50 ` Stephen Leake 1 sibling, 1 reply; 22+ messages in thread From: Dmitry A. Kazakov @ 2019-01-04 8:58 UTC (permalink / raw) On 2019-01-03 23:39, olivermkellogg@gmail.com wrote: > On Tuesday, January 1, 2019 at 9:44:17 AM UTC+1, Dmitry A. Kazakov wrote: >> [...] >> Never push semantic rules into syntax. > > I'm not so sure about that: > A nice feature of ANTLR is that is supports semantic predicates which can be embedded in the grammar. > For example, using sem preds on the basis of symbol tables would permit discerning among indexed_component, type_conversion, function_call. In presence of overloading, really? Anyway, I see no use in such a distinction in general. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-04 8:58 ` Dmitry A. Kazakov @ 2019-01-05 8:45 ` Randy Brukardt 0 siblings, 0 replies; 22+ messages in thread From: Randy Brukardt @ 2019-01-05 8:45 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:q0n77h$2e4$1@gioia.aioe.org... > On 2019-01-03 23:39, olivermkellogg@gmail.com wrote: >> On Tuesday, January 1, 2019 at 9:44:17 AM UTC+1, Dmitry A. Kazakov wrote: >>> [...] >>> Never push semantic rules into syntax. >> >> I'm not so sure about that: >> A nice feature of ANTLR is that is supports semantic predicates which can >> be embedded in the grammar. >> For example, using sem preds on the basis of symbol tables would permit >> discerning among indexed_component, type_conversion, function_call. > > In presence of overloading, really? Anyway, I see no use in such a > distinction in general. Right. That might work in other languages, but in Ada that is a very complex algorithm. You'd think that the lack of object overloading would help, and it does, but not enough, since you can have a function that returns an array that is then indexed, as opposed to a function that returns an access-to-function. They both could look like: F (1) (2) And you don't want the grammar to be too smart, simply because hand-written error messages are almost always better than automatically generated ones, once you get past the trivial (missing punctuation). Randy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-03 22:39 ` olivermkellogg 2019-01-04 8:58 ` Dmitry A. Kazakov @ 2019-01-05 18:50 ` Stephen Leake 1 sibling, 0 replies; 22+ messages in thread From: Stephen Leake @ 2019-01-05 18:50 UTC (permalink / raw) On Thursday, January 3, 2019 at 2:39:12 PM UTC-8, oliverm...@gmail.com wrote: > A nice feature of ANTLR is that is supports semantic predicates which can be embedded in the grammar. > For example, using sem preds on the basis of symbol tables would permit discerning among indexed_component, type_conversion, function_call. That could be useful for colorization; Emacs Ada-mode takes a simplistic approach to coloring identifiers. libadalang takes a different approach; it does some semantic analysis after parsing, including name resolution. > The interesting question IMO is: > What are the necessary transformations for going from Annex P BNF plus informal description of semantic rules to the actual implementation grammar. That totally depends on the purpose of the implementation. A compiler has very different requirements from an IDE engine. -- Stephe ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2018-12-31 21:45 ` Randy Brukardt 2019-01-01 8:44 ` Dmitry A. Kazakov @ 2019-01-01 19:46 ` olivermkellogg 2019-01-03 22:36 ` Randy Brukardt 1 sibling, 1 reply; 22+ messages in thread From: olivermkellogg @ 2019-01-01 19:46 UTC (permalink / raw) On Monday, December 31, 2018 at 10:45:46 PM UTC+1, Randy Brukardt wrote: > Ada semantic rules use the syntax rules and vice versa. In this case, one > does not want to repeat the various rules for interpreting an expanded name > (which are part of selected_component). Understood. Thanks for explaining. I still think that when using Annex P as the direct basis for a parser it would make sense to narrow down the name related rules. Along these lines: Do you think it would be permissible to "solidify" the italics? E.g. in the case of subtype_mark, in the implementation grammar there could be an actual rule subtype_name with a much narrower definition. That would avoid forcing the parser to jump through the unnecessary hoops of the heavy weight rule `name'. - Oliver ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-01 19:46 ` olivermkellogg @ 2019-01-03 22:36 ` Randy Brukardt 0 siblings, 0 replies; 22+ messages in thread From: Randy Brukardt @ 2019-01-03 22:36 UTC (permalink / raw) <olivermkellogg@gmail.com> wrote in message news:8f1d7dde-b982-42ff-93d6-5d19dac92f3b@googlegroups.com... > On Monday, December 31, 2018 at 10:45:46 PM UTC+1, Randy Brukardt wrote: >> Ada semantic rules use the syntax rules and vice versa. In this case, one >> does not want to repeat the various rules for interpreting an expanded >> name >> (which are part of selected_component). > > Understood. Thanks for explaining. > > I still think that when using Annex P as the direct basis for a parser it > would make sense to narrow down the name related rules. > Along these lines: > Do you think it would be permissible to "solidify" the italics? > > E.g. in the case of subtype_mark, in the implementation grammar there > could be an actual rule subtype_name with a much narrower definition. > That would avoid forcing the parser to jump through the unnecessary hoops > of the heavy weight rule `name'. So long as you aren't representing that the grammar is exactly that of the RM, you can make any changes to it that you want. You pretty much have to do that in any purely syntactic grammar (indexed_component and type_conversion are ambiguous, for instance). As Dmitry said, the grammar of Annex P isn't directly useful for much of anything (other than human reading). [Yes, we know that, we inherited it from Ada 83 and haven't wanted to change it in part because things like ASIS are heavily dependent on the Annex P grammar.] Randy. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2018-12-29 18:20 Ada grammar rules for names too permissive? olivermkellogg 2018-12-31 21:45 ` Randy Brukardt @ 2019-01-01 19:46 ` Stephen Leake 2019-01-01 21:03 ` olivermkellogg 1 sibling, 1 reply; 22+ messages in thread From: Stephen Leake @ 2019-01-01 19:46 UTC (permalink / raw) On Saturday, December 29, 2018 at 10:20:41 AM UTC-8, oliverm...@gmail.com wrote: > - Oliver > (currently fighting ambiguities in the ANTLR grammar caused by laxity of rules) This is precisely why I use a generalized LR parser for Emacs Ada mode; I don't have to mess with the published grammar. It works very well in practice. The LRM is written for people to understand (not computers), and the current style is good for that, I think. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-01 19:46 ` Stephen Leake @ 2019-01-01 21:03 ` olivermkellogg 2019-01-02 19:42 ` Stephen Leake 0 siblings, 1 reply; 22+ messages in thread From: olivermkellogg @ 2019-01-01 21:03 UTC (permalink / raw) On Tuesday, January 1, 2019 at 9:06:59 PM UTC+1, Stephen Leake wrote: > > [...] > > This is precisely why I use a generalized LR parser for Emacs Ada mode; I don't have to mess with the published grammar. It works very well in practice. Hmm... I downloaded org.emacs.ada-mode-6.0.1.tar.bz2, is that what you are talking about? In there, I see a file ada.wy which seems to be an Ada grammar, is that what you are talking about? What do you do with 12.3 : explicit_generic_actual_parameter ::= expression | (variable_)name | (subprogram_)name | (entry_)name | subtype_mark | (package_instance_)name If I leave away the italics I get: explicit_generic_actual_parameter ::= expression | name | name | name | subtype_mark | name So.. it seems I can answer my own question about solidifying the italics; that's what should be done, otherwise we get nonsense. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Ada grammar rules for names too permissive? 2019-01-01 21:03 ` olivermkellogg @ 2019-01-02 19:42 ` Stephen Leake 0 siblings, 0 replies; 22+ messages in thread From: Stephen Leake @ 2019-01-02 19:42 UTC (permalink / raw) On Tuesday, January 1, 2019 at 1:03:34 PM UTC-8, oliverm...@gmail.com wrote: > On Tuesday, January 1, 2019 at 9:06:59 PM UTC+1, Stephen Leake wrote: > > > [...] > > > > This is precisely why I use a generalized LR parser for Emacs Ada mode; I don't have to mess with the published grammar. It works very well in practice. > > Hmm... I downloaded org.emacs.ada-mode-6.0.1.tar.bz2, is that what you are talking about? Yes. It's also a GNU ELPA package. > In there, I see a file ada.wy which seems to be an Ada grammar, is that what you are talking about? Yes. > What do you do with 12.3 : > > explicit_generic_actual_parameter ::= expression | (variable_)name > | (subprogram_)name | (entry_)name | subtype_mark > | (package_instance_)name I eliminated it, along with generic_actual_part, because "name ( generic_actual_part ) " is a subset of "name ( actual_parameter_part )". That's what the comment at "generic_instantiation" is trying to say. So ada.wy accepts a larger language than LRM Annex P; that's part of the strategy for handling incorrect syntax. Perhaps "minimal changes" is not a correct description for this kind of change, but the changes I made only allow more choices for each token, they don't change the basic structure of the productions. > If I leave away the italics I get: > > explicit_generic_actual_parameter ::= expression | name > | name | name | subtype_mark > | name > > So.. it seems I can answer my own question about solidifying the italics; > that's what should be done, otherwise we get nonsense. It's not nonsense, it's just redundant, and an indication that the legality should be checked by the post-parsing phases. ada.wy deals with such redundancies by including only the minimal set that covers the original. There are still redundancies (listed in the %conflict declarations); those are handled at runtime by the generalized parser. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2019-01-08 18:58 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-29 18:20 Ada grammar rules for names too permissive? olivermkellogg 2018-12-31 21:45 ` Randy Brukardt 2019-01-01 8:44 ` Dmitry A. Kazakov 2019-01-01 19:49 ` Stephen Leake 2019-01-01 20:42 ` Dmitry A. Kazakov 2019-01-02 19:21 ` Stephen Leake 2019-01-02 20:47 ` Dmitry A. Kazakov 2019-01-03 21:45 ` Stephen Leake 2019-01-03 22:34 ` Jere 2019-01-05 18:46 ` Stephen Leake 2019-01-07 11:11 ` J-P. Rosen 2019-01-08 18:58 ` Stephen Leake 2019-01-04 8:53 ` Dmitry A. Kazakov 2019-01-03 22:39 ` olivermkellogg 2019-01-04 8:58 ` Dmitry A. Kazakov 2019-01-05 8:45 ` Randy Brukardt 2019-01-05 18:50 ` Stephen Leake 2019-01-01 19:46 ` olivermkellogg 2019-01-03 22:36 ` Randy Brukardt 2019-01-01 19:46 ` Stephen Leake 2019-01-01 21:03 ` olivermkellogg 2019-01-02 19:42 ` Stephen Leake
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox