From: Adam Beneschan <adam@irvine.com>
Subject: Re: Real syntax problems in Ada
Date: Tue, 28 Aug 2012 08:14:15 -0700 (PDT)
Date: 2012-08-28T08:14:15-07:00 [thread overview]
Message-ID: <289703e7-1fba-41ce-b781-9e58ff2ec7df@googlegroups.com> (raw)
In-Reply-To: <1p5r39cusgc1n$.18nj9sytckk6$.dlg@40tude.net>
On Tuesday, August 28, 2012 1:13:02 AM UTC-7, Dmitry A. Kazakov wrote:
> What are real problems with Ada syntax as opposed to the imaginary ones
>
> (e.g. Ada does not look like C, Forth, Elder Futhark, you name it)?
Ada does not look like Intercal ...
> My short list:
>
> 1. Too many unnecessarily reserved keywords;
I've never found this to be a problem. Having a lot of reserved words is a problem only if there are more than one or two that you wish you could use as identifiers, and I haven't had this happen. For what it's worth, Ada has 73 keywords, Java has 50. Eiffel has somewhere from 50 to 69 (I looked at one web page and there seems to be some dispute about whether certain predefined names are reserved). C++ (the latest version) has 84, which actually shocked me because I've been assuming C-type languages preferred punctuation characters or sequences over reserved words (e.g. & instead of "and", && instead of "and then", { instead of "begin", etc.).
> 2. "end record" instead of "end <record type name>";
Yep, this is one I wish were different. After working with Ada for about 24 years I still sometimes type in "end <type-name>" before I catch myself.
> 3. "task type" and "protected type" instead of "type T is task ...";
This one just seems like a matter of personal preference, not a real problem. I understand what J-P said was the purpose, to make singleton tasks and task types look the same; on the other hand, there's merit in making task type declarations follow the same form as other type declarations. Either way, though, this seems like a minor nuisance at best.
> 4. "overriding procedure Foo" instead of "procedure Foo is overriding";
It's possible for "overriding" to occur on a procedure body (and necessary in some less-common cases). I'd worry that if Foo has a long parameter list, an overriding keyword could get buried in a case like that, making it harder to spot for a reader. That's a minor point, though.
> 5. "X : T := E", but "procedure X is <body>";
I'm not clear on what you mean here.
> 6. Lack of per point notation for nD array aggregates, e.g.
>
> Diag : Matrix := ((1,1)=>1.0, (2,2)=>1.0, (3,3)=>1.0, others => 0.0);
I can see how this could be useful.
> 7. "exception" must be required in the bodies of tasks, Initialize,
> Finalize (however, this could be resolved by non-syntactic means, e.g. by
> contracted exceptions);
This isn't really a syntax issue since you're not proposing any difference in the grammar. (If you disagree, fine; I'm not going to get involved in a long discussion about the definition of "syntax".)
> 8. The order in which the keywords "new", "interface", "limited",
> "abstract", "tagged", "private" may appear should be free.
I've definitely run into problems with "limited" and "abstract"; I keep having to look up which one comes first. One could argue that some of these key words are the "important" ones that tell you the main thing about what category of type it is, and those should be last; the keywords in that group are "new", "interface", "private" (as well as "record", "array", "delta", "digits", "range", "access"). Others are more like adjectives that modify the type, and I can see how it would be useful to allow more freedom in the order.
With respect to *syntax* problems (as opposed to new features), my own wish list would include allowing a generic formal part to be repeated on a generic package or procedure body. (Otherwise, if the specification and body are in different source files, you can't see the definitions of the formal parameters when they're used in the body. I usually just copy in the generic formal part as comments.)
-- Adam
next prev parent reply other threads:[~2012-08-28 15:14 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 8:13 Real syntax problems in Ada Dmitry A. Kazakov
2012-08-28 10:20 ` Georg Bauhaus
2012-08-28 10:47 ` Niklas Holsti
2012-08-28 11:33 ` J-P. Rosen
2012-08-31 13:35 ` Robert A Duff
2012-08-28 13:27 ` Vasiliy Molostov
2012-08-28 15:23 ` Dmitry A. Kazakov
2012-08-28 20:18 ` Vasiliy Molostov
2012-08-29 7:25 ` Dmitry A. Kazakov
2012-08-29 10:47 ` Vasiliy Molostov
2012-08-29 11:58 ` Dmitry A. Kazakov
2012-08-30 17:38 ` Vasiliy Molostov
2012-08-28 15:14 ` Adam Beneschan [this message]
2012-08-28 16:18 ` J-P. Rosen
2012-08-28 16:39 ` Dmitry A. Kazakov
2012-08-28 21:38 ` Randy Brukardt
2012-08-29 6:58 ` Dmitry A. Kazakov
2012-08-29 10:43 ` stefan-lucks
2012-08-29 10:58 ` stefan-lucks
2012-08-29 13:14 ` Niklas Holsti
2012-08-29 17:52 ` stefan-lucks
[not found] ` <fbps38pgcuf8fgioptt39s6u7dme1aqs7r@invalid.netcom.com>
2012-09-02 10:16 ` svaa
2012-08-29 13:33 ` Georg Bauhaus
2012-08-29 17:20 ` Jeffrey Carter
2012-08-29 17:51 ` stefan-lucks
2012-08-30 9:12 ` Georg Bauhaus
2012-08-28 21:49 ` Randy Brukardt
2012-08-28 23:09 ` Adam Beneschan
2012-08-29 7:34 ` Egil Høvik
2012-08-28 19:41 ` Florian Weimer
2012-08-28 20:53 ` Shark8
2012-08-28 21:07 ` Adam Beneschan
2012-08-28 21:25 ` Shark8
2012-08-28 22:59 ` Adam Beneschan
2012-08-29 7:06 ` Dmitry A. Kazakov
2012-08-30 21:08 ` Randy Brukardt
2012-08-30 22:06 ` sbelmont700
2012-08-30 22:34 ` Adam Beneschan
2012-08-30 22:54 ` William Findlay
2012-08-31 7:39 ` Dmitry A. Kazakov
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox