* Re: Real syntax problems in Ada
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
` (4 subsequent siblings)
5 siblings, 0 replies; 40+ messages in thread
From: Georg Bauhaus @ 2012-08-28 10:20 UTC (permalink / raw)
On 28.08.12 10:13, 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)?
>
> My short list:
>
> 1. Too many unnecessarily reserved keywords;
I even avoid using identifiers that are reserved (in whichever
way) in other programming languages. My list of identifiers excludes
words such as "default", "fun", "sub", "otherwise", etc.
> 4. "overriding procedure Foo" instead of "procedure Foo is overriding";
There seems to be a conflict, since we can overriding a procedure with
one that "is null" or "is abstract". But we could write
procedure Foo is overriding and abstract;
> 5. "X : T := E", but "procedure X is <body>";
While plausible, I'd rather test assignment of a procedure in a field
that has a smaller percentage of doctors of science.
Seriously; the idea being similar to what is done in Lisp (or ML's etc.),
what is the proportion of all programmers (not just Lisp programmers)
who are aware of Lisp's procedure binding?
> 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);
I'll venture a guess: AdaCore would require a closer look at least,
since GCC says it translates differently, depending on whether
or not there is an exception handler.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
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-28 13:27 ` Vasiliy Molostov
` (3 subsequent siblings)
5 siblings, 1 reply; 40+ messages in thread
From: Niklas Holsti @ 2012-08-28 10:47 UTC (permalink / raw)
On 12-08-28 11:13 , 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)?
>
> My short list:
And my opinions/votes:
> 1. Too many unnecessarily reserved keywords;
At least the reserved words tend to be short, and therefore not so
suitable for identifiers.
I believe that reserved words make it easier for compilers to give good
error messages.
> 2. "end record" instead of "end <record type name>";
I agree. The second form should be allowed.
> 3. "task type" and "protected type" instead of "type T is task ...";
Neutral. I don't much mind the asymmetry, although I don't see any good
reason for it.
> 4. "overriding procedure Foo" instead of "procedure Foo is overriding";
I prefer the current form, with overriding at the start. "Overriding" is
not a property of "Foo" itself, but of the declaration.
> 5. "X : T := E", but "procedure X is <body>";
I like the present form. The "procedure" and "function" keywords in the
left margin make the source code more readable. The role of subprograms
in a program is so different from the role of variables (objects) that a
different declaration style is motivated.
> 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);
Could be useful on occasion. Would be nice to have.
> 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);
Not really a question of syntax. Best handled by a legality rule.
> 8. The order in which the keywords "new", "interface", "limited",
> "abstract", "tagged", "private" may appear should be free.
Ok, why not. But the present strictness is at most a minor nuisance.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 10:47 ` Niklas Holsti
@ 2012-08-28 11:33 ` J-P. Rosen
2012-08-31 13:35 ` Robert A Duff
0 siblings, 1 reply; 40+ messages in thread
From: J-P. Rosen @ 2012-08-28 11:33 UTC (permalink / raw)
Le 28/08/2012 12:47, Niklas Holsti a �crit :
>> 3. "task type" and "protected type" instead of "type T is task ...";
> Neutral. I don't much mind the asymmetry, although I don't see any good
> reason for it.
>
The reason is to have singleton tasks and task types look the same:
task Single is....
task type Many is...
--
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] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 11:33 ` J-P. Rosen
@ 2012-08-31 13:35 ` Robert A Duff
0 siblings, 0 replies; 40+ messages in thread
From: Robert A Duff @ 2012-08-31 13:35 UTC (permalink / raw)
"J-P. Rosen" <rosen@adalog.fr> writes:
> Le 28/08/2012 12:47, Niklas Holsti a �crit :
>>> 3. "task type" and "protected type" instead of "type T is task ...";
>> Neutral. I don't much mind the asymmetry, although I don't see any good
>> reason for it.
>>
> The reason is to have singleton tasks and task types look the same:
> task Single is....
> task type Many is...
I don't get it.
type Many is array (Index) of Component;
Single: array (Index) of Component;
Jean Ichbiah didn't value consistency nearly as highly as I do.
Why, for example, can some kinds of types be anonymous,
while others can't?
- Bob
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
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 13:27 ` Vasiliy Molostov
2012-08-28 15:23 ` Dmitry A. Kazakov
2012-08-28 15:14 ` Adam Beneschan
` (2 subsequent siblings)
5 siblings, 1 reply; 40+ messages in thread
From: Vasiliy Molostov @ 2012-08-28 13:27 UTC (permalink / raw)
Agree, some relatively new enhancements to Ada syntax look awkward.
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Tue,
28 Aug 2012 12:13:08 +0400:
> 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)?
>
> My short list:
>
> 1. Too many unnecessarily reserved keywords;
Probably yes, but these are simply to grep/calculate using public codebase.
>
> 2. "end record" instead of "end <record type name>";
Really, yes.
>
> 3. "task type" and "protected type" instead of "type T is task ...";
A first word of sentence in declaration is always an entity (procedure,
function, package, type),
it seems that "task type" breaks this way, and "type t is task" is more
eye candy.
>
> 4. "overriding procedure Foo" instead of "procedure Foo is overriding";
I agree, this keyword has a scary place (a property before its entity,
which is not usual way in Ada), breaks eye on it. It seems that this one
came from "virtual" kw from c++/java++, and the result of such incoming is
very horrific.
>
> 5. "X : T := E", but "procedure X is <body>";
Unclear what it is, but should we use the same for T, or how to express T
in this case?
>
> 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);
Unclear, what is per point.
> 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);
Disagree. Exceptions can be disabled by configuration, while ravenscar can
allow tasking, a good example is a linux driver, where is no place in a
thread to raise an ada exception up out from inside kernel.
>
> 8. The order in which the keywords "new", "interface", "limited",
> "abstract", "tagged", "private" may appear should be free.
>
Unclear. Example?
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 13:27 ` Vasiliy Molostov
@ 2012-08-28 15:23 ` Dmitry A. Kazakov
2012-08-28 20:18 ` Vasiliy Molostov
0 siblings, 1 reply; 40+ messages in thread
From: Dmitry A. Kazakov @ 2012-08-28 15:23 UTC (permalink / raw)
On Tue, 28 Aug 2012 17:27:12 +0400, Vasiliy Molostov wrote:
>> 5. "X : T := E", but "procedure X is <body>";
>
> Unclear what it is, but should we use the same for T, or how to express T
> in this case?
There is an asymmetry in how objects of anonymous types are declared and
the subprograms are. E.g.
X : array (1..3) of Integer := (others => 0);
a symmetric declaration of a procedure would be:
X : procedure :=
begin
...
end X;
Not that I advocate for this particular syntax. I only note difference.
>> 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);
>
> Unclear, what is per point.
Using flat nD index additionally to the arrays of arrays of arrays ...
notation like:
Diag : Matrix :=
( 1 => (1 => 1.0, others => 0.0),
2 => (2 => 1.0, others => 0.0),
3 => (3 => 1.0, others => 0.0));
>> 8. The order in which the keywords "new", "interface", "limited",
>> "abstract", "tagged", "private" may appear should be free.
>
> Unclear. Example?
type T is abstract tagged limited null record; -- Only so
type T is abstract limited tagged null record; -- Illegal
type T is limited tagged abstract null record; -- Illegal
...
I bet very few would remember the proper order if asked unprepared. Luckily
GNAT would advise how to reorder the keywords in its error message.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 15:23 ` Dmitry A. Kazakov
@ 2012-08-28 20:18 ` Vasiliy Molostov
2012-08-29 7:25 ` Dmitry A. Kazakov
0 siblings, 1 reply; 40+ messages in thread
From: Vasiliy Molostov @ 2012-08-28 20:18 UTC (permalink / raw)
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Tue,
28 Aug 2012 19:23:42 +0400:
> a symmetric declaration of a procedure would be:
>
> X : procedure :=
> begin
> ...
> end X;
mnmn. where to apply parameter list declaration (suppose this as procedure
type "constraint")?
instead of subprogram access types we have objects in itself, how to
operate them? and ":=" is a re-definable construct, as I remember, while
we can not express operations on sub-program body. How about to implement
simple "<", ">" for sub-program bodies? hehe.
I am not sure that it is appropriate.
> Diag : Matrix :=
> ( 1 => (1 => 1.0, others => 0.0),
> 2 => (2 => 1.0, others => 0.0),
> 3 => (3 => 1.0, others => 0.0));
Yep, agree, it would be very helpful for multidims, but indeed the type of
"(1 => 1.0, others => 0.0)" is unknown (anonymous), we can not cast
already prepared objects (aka tmp := (1 => 1.0, others => 0.0)) to supply
to this construct. So as a result this one is useless without referencing
another variable or constant in this constraint.
How about "(T'(1..1, 1..1 | 2..2) => 1, others => 0)"? And what type of T
should be here?
> type T is abstract tagged limited null record; -- Only so
>
> type T is abstract limited tagged null record; -- Illegal
> type T is limited tagged abstract null record; -- Illegal
> ...
>
> I bet very few would remember the proper order if asked unprepared.
I remember very well, since it is only one order can be (and only one I
should remember), and this can be considered as simplicity. Other variants
can break eye on looking for similar constructs while they are just in
another order, no benefit, useless.
> Luckily
> GNAT would advise how to reorder the keywords in its error message.
if this is for error message only, I can agree, but the rule is real when
it is stable for a long time (e.g. unchanged). e.g. much better to have it
as an error.
Gnat and lucky? Hmmm.
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 20:18 ` Vasiliy Molostov
@ 2012-08-29 7:25 ` Dmitry A. Kazakov
2012-08-29 10:47 ` Vasiliy Molostov
0 siblings, 1 reply; 40+ messages in thread
From: Dmitry A. Kazakov @ 2012-08-29 7:25 UTC (permalink / raw)
On Wed, 29 Aug 2012 00:18:39 +0400, Vasiliy Molostov wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Tue,
> 28 Aug 2012 19:23:42 +0400:
>
>> a symmetric declaration of a procedure would be:
>>
>> X : procedure :=
>> begin
>> ...
>> end X;
>
> mnmn. where to apply parameter list declaration (suppose this as procedure
> type "constraint")?
>
> instead of subprogram access types we have objects in itself, how to
> operate them? and ":=" is a re-definable construct, as I remember, while
> we can not express operations on sub-program body. How about to implement
> simple "<", ">" for sub-program bodies? hehe.
Bodies are not ordered. But if an order were required, e.g. to have
containers, ordered sets of, address could be used for that.
There is an important operation on bodies: composition:
type Float_Valued is function (X : Float) return Float;
X : Float_Valued := begin ... end;
Y : Float_Valued := begin ... end;
Z : Float_Valued := Y * X;
Another operation is inheritance. That is when one body operates T another
S and S <: T, inheritance is the body of T composed with type conversion S
to T.
And of course, parametrization, AKA instantiation of a generic body. Simple
non-generic form could deploy discriminants. That would give
specialization:
type Integrator (Method : ...) is
function (X : Float; ...) return Float;
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 7:25 ` Dmitry A. Kazakov
@ 2012-08-29 10:47 ` Vasiliy Molostov
2012-08-29 11:58 ` Dmitry A. Kazakov
0 siblings, 1 reply; 40+ messages in thread
From: Vasiliy Molostov @ 2012-08-29 10:47 UTC (permalink / raw)
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Wed,
29 Aug 2012 11:25:00 +0400:
> There is an important operation on bodies: composition:
>
> type Float_Valued is function (X : Float) return Float;
> X : Float_Valued := begin ... end;
> Y : Float_Valued := begin ... end;
> Z : Float_Valued := Y * X;
>
> Another operation is inheritance. That is when one body operates T
> another
> S and S <: T, inheritance is the body of T composed with type conversion
> S
> to T.
Intriguing. Perhaps this can be distributed on other things,
where subprogram can be simply implemented by X * Y.
> And of course, parametrization, AKA instantiation of a generic body.
> Simple
> non-generic form could deploy discriminants. That would give
> specialization:
>
> type Integrator (Method : ...) is
> function (X : Float; ...) return Float;
>
matching parameters by position only is awkward, perhaps. What about
type Integrator (Method : ...) is
function (X : Float := Method; ...) return Float;
or
type Integrator (Method : ...) is
function (Method : Float; ...) return Float;
(I dont know what type the Method you mean, but assumed it is a float type)
But this arises a question about X * Y where both are types indeed, and
can have discriminants. I can not imagine this.
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 10:47 ` Vasiliy Molostov
@ 2012-08-29 11:58 ` Dmitry A. Kazakov
2012-08-30 17:38 ` Vasiliy Molostov
0 siblings, 1 reply; 40+ messages in thread
From: Dmitry A. Kazakov @ 2012-08-29 11:58 UTC (permalink / raw)
On Wed, 29 Aug 2012 14:47:19 +0400, Vasiliy Molostov wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> яПНяПНяПНяПНяПН(яПН) яПН яПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН Wed,
> 29 Aug 2012 11:25:00 +0400:
>
>> There is an important operation on bodies: composition:
>>
>> type Float_Valued is function (X : Float) return Float;
>> X : Float_Valued := begin ... end;
>> Y : Float_Valued := begin ... end;
>> Z : Float_Valued := Y * X;
>>
>> Another operation is inheritance. That is when one body operates T
>> another
>> S and S <: T, inheritance is the body of T composed with type conversion
>> S to T.
>
> Intriguing. Perhaps this can be distributed on other things,
> where subprogram can be simply implemented by X * Y.
Already Ada 83 had this, though in a very rudimentary ad-hoc form when type
conversion applied to the argument of a call. It works for all modes, e.g.
for out:
procedure Foo (X : in out Integer);
Y : Float;
begin
Foo (Integer (Y)); -- This is legal Ada 83
>> And of course, parametrization, AKA instantiation of a generic body. Simple
>> non-generic form could deploy discriminants. That would give
>> specialization:
>>
>> type Integrator (Method : ...) is
>> function (X : Float; ...) return Float;
>
> matching parameters by position only is awkward, perhaps. What about
>
> type Integrator (Method : ...) is
> function (X : Float := Method; ...) return Float;
>
> or
>
> type Integrator (Method : ...) is
> function (Method : Float; ...) return Float;
It is not different from how discriminants are used in record types.
There are various applications for discriminants to constraint the
instance:
type Multiplicative (Left, Right : Unit) is
function (X : Dimensioned (Left); Y : Dimensioned (Right))
return Dimensioned (Left * Right);
type Additive (Left : Unit) is
function (X, Y : Dimensioned (Left)) return Dimensioned (Left);
> (I dont know what type the Method you mean, but assumed it is a float type)
>
> But this arises a question about X * Y where both are types indeed, and
> can have discriminants. I can not imagine this.
No problem. Compare:
type T (...) is record ... end record;
type S (...) is record ... end record;
type U (...) is record
X : T (...);
Y : S (...);
end record;
Discriminants of the result type must define the discriminants of the
argument types.
It is no matter if the operation is composition or aggregation as in the
example where T and S are record types aggregated into new result type U.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 11:58 ` Dmitry A. Kazakov
@ 2012-08-30 17:38 ` Vasiliy Molostov
0 siblings, 0 replies; 40+ messages in thread
From: Vasiliy Molostov @ 2012-08-30 17:38 UTC (permalink / raw)
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Wed,
29 Aug 2012 15:58:32 +0400:
> On Wed, 29 Aug 2012 14:47:19 +0400, Vasiliy Molostov wrote:
>
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме
>> Wed,
>> 29 Aug 2012 11:25:00 +0400:
>>
>>> There is an important operation on bodies: composition:
>>>
>>> type Float_Valued is function (X : Float) return Float;
>>> X : Float_Valued := begin ... end;
>>> Y : Float_Valued := begin ... end;
>>> Z : Float_Valued := Y * X;
>>>
>>> Another operation is inheritance. That is when one body operates T
>>> another
>>> S and S <: T, inheritance is the body of T composed with type
>>> conversion
>>> S to T.
>>
>> Intriguing. Perhaps this can be distributed on other things,
>> where subprogram can be simply implemented by X * Y.
>
Yep, this is useful and productive idea. (I have snipped remaining in your
reply to keep only your original message quoted). Perhaps Randy can give
some words on this...
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 8:13 Real syntax problems in Ada Dmitry A. Kazakov
` (2 preceding siblings ...)
2012-08-28 13:27 ` Vasiliy Molostov
@ 2012-08-28 15:14 ` Adam Beneschan
2012-08-28 16:18 ` J-P. Rosen
` (2 more replies)
2012-08-28 19:41 ` Florian Weimer
2012-08-30 22:06 ` sbelmont700
5 siblings, 3 replies; 40+ messages in thread
From: Adam Beneschan @ 2012-08-28 15:14 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 15:14 ` Adam Beneschan
@ 2012-08-28 16:18 ` J-P. Rosen
2012-08-28 16:39 ` Dmitry A. Kazakov
2012-08-28 21:49 ` Randy Brukardt
2 siblings, 0 replies; 40+ messages in thread
From: J-P. Rosen @ 2012-08-28 16:18 UTC (permalink / raw)
Le 28/08/2012 17:14, Adam Beneschan a �crit :
>> 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.
Just remember:
"I Am The Leading Programmer"
("Is Abstract Tagged Limited Private)
--
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] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 15:14 ` Adam Beneschan
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-28 21:49 ` Randy Brukardt
2 siblings, 1 reply; 40+ messages in thread
From: Dmitry A. Kazakov @ 2012-08-28 16:39 UTC (permalink / raw)
On Tue, 28 Aug 2012 08:14:15 -0700 (PDT), Adam Beneschan wrote:
> 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 ...
Not to forget J ...
> 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.
Interesting. Yes. But then it should have been required rather than merely
allowed.
Speaking of generics, the formal parameter declarations could be more
regular:
generic
type T ...;
Object : T;
but
generic
with procedure Foo ...;
with package Bar ...;
From formal part one could expect following the pattern:
<name> : <type> [:= <default>]
On the other hand, it is also clear why one would like to keep it visually
different from the signature of a subprogram.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 16:39 ` Dmitry A. Kazakov
@ 2012-08-28 21:38 ` Randy Brukardt
2012-08-29 6:58 ` Dmitry A. Kazakov
0 siblings, 1 reply; 40+ messages in thread
From: Randy Brukardt @ 2012-08-28 21:38 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1w3xr2kbz8a19$.wpfoz4p1j1sb.dlg@40tude.net...
> On Tue, 28 Aug 2012 08:14:15 -0700 (PDT), Adam Beneschan wrote:
...
> Speaking of generics, the formal parameter declarations could be more
> regular:
>
> generic
> type T ...;
> Object : T;
>
> but
>
> generic
> with procedure Foo ...;
> with package Bar ...;
>
> From formal part one could expect following the pattern:
>
> <name> : <type> [:= <default>]
>
> On the other hand, it is also clear why one would like to keep it visually
> different from the signature of a subprogram.
It's not a case of "liking"; without the "with", the syntax would be
ambiguous, as a generic unit can be a subprogram. And remember that Ada is
technically free-form, so the indentation and line-endings are irrelevant.
So
generic
function Foo...
...
Is this a generic function with an empty formal part, or a generic formal
subprogram parameter? Without the "with", you can't tell. You'd need a lot
of lookahead to figure this out, and clearly such a syntax would be
error-prone. (Argubly, it's already error-prone, given that I forget the
"with" roughly 50% of the time and get weird compiler errors, but it
certainly would be worse without it.)
Randy.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 21:38 ` Randy Brukardt
@ 2012-08-29 6:58 ` Dmitry A. Kazakov
2012-08-29 10:43 ` stefan-lucks
0 siblings, 1 reply; 40+ messages in thread
From: Dmitry A. Kazakov @ 2012-08-29 6:58 UTC (permalink / raw)
On Tue, 28 Aug 2012 16:38:26 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1w3xr2kbz8a19$.wpfoz4p1j1sb.dlg@40tude.net...
>> On Tue, 28 Aug 2012 08:14:15 -0700 (PDT), Adam Beneschan wrote:
> ...
>> Speaking of generics, the formal parameter declarations could be more
>> regular:
>>
>> generic
>> type T ...;
>> Object : T;
>>
>> but
>>
>> generic
>> with procedure Foo ...;
>> with package Bar ...;
>>
>> From formal part one could expect following the pattern:
>>
>> <name> : <type> [:= <default>]
>>
>> On the other hand, it is also clear why one would like to keep it visually
>> different from the signature of a subprogram.
>
> It's not a case of "liking"; without the "with", the syntax would be
> ambiguous, as a generic unit can be a subprogram. And remember that Ada is
> technically free-form, so the indentation and line-endings are irrelevant.
> So
> generic
> function Foo...
> ...
No, I meant rather this:
generic package P (Foo : function return Integer; Q : package...) is ...
instead of
generic
with function Foo return Integer;
with package Q ...;
package P is ...
The problem with that could be distinguishing generic and non-generic
signatures of generic subroutines:
generic procedure Baz (X : Integer);
Is X here a generic formal object or a plain argument of Baz?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 6:58 ` Dmitry A. Kazakov
@ 2012-08-29 10:43 ` stefan-lucks
2012-08-29 10:58 ` stefan-lucks
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: stefan-lucks @ 2012-08-29 10:43 UTC (permalink / raw)
On Wed, 29 Aug 2012, Dmitry A. Kazakov wrote:
> No, I meant rather this:
>
> generic package P (Foo : function return Integer; Q : package...) is ...
Indeed, the syntax for declaring a generic something (after the keyword
"generic" the parameters come first, and the something and its name comes
last) is counter-intuitive, different from any other declarations, and
hurts readability. Consider the following simple example:
generic
type Item is private;
type Many_Items is array(Positive range <>) of Item;
with function "<"(Left, Right: Item) return Boolean is <>;
function Minimum(List: Many_Items) return Item;
Ask programmers without Ada experience what this is. Most would read this
as a generic declaration of something -- but how many would read this as
the generic declaration of a function called "Minimum"?
If the indention is lost, even Ada-programmers would have problems to find
out *what* is generically declared (a function) and what its name is
("Minimum").
Your idea seems to be to alternatively write the above declaration as
generic function Minimum
(type Item is private;
type Many_Items is Array (Natural Range <>) of Item;
function "<"(Left, Right: Item) return Boolean is <>)
(List: Many_Items) return Item;
This would be a lot more readable.
> The problem with that could be distinguishing generic and non-generic
> signatures of generic subroutines:
>
> generic procedure Baz (X : Integer);
>
> Is X here a generic formal object or a plain argument of Baz?
Here we are hurt by another minor but annoying inconsistency of the Ada
syntax. Almost everywhere, we have to write "null" to make it explicit if
we ask for nothing, or for nothing additional. E.g., we must write
type X is new Tagged_Type with null record;
instead of
type X is new Tagged_Type;
Similarly, we write "if B then null; else Do_Something end if;" instead of
"if B then else Do_Something end if;". This is an advantage of Ada that
improves readability and helps to catch flaws.
Back to the issue you raised!
If we introduce the notation "(null)" for empty parameter lists, we can
easily solve your issue:
generic procedure Baz_1 (with X: Integer) (null);
-- X is a generic formal object,
-- (I am not sure if we should allow or even require "with" here.)
generic procedure Baz_2 (null) (X: Integer);
-- X is a plain argument
--
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany ----
<http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------ I love the taste of Cryptanalysis in the morning! ------
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 10:43 ` stefan-lucks
@ 2012-08-29 10:58 ` stefan-lucks
2012-08-29 13:14 ` Niklas Holsti
2012-08-29 13:33 ` Georg Bauhaus
2 siblings, 0 replies; 40+ messages in thread
From: stefan-lucks @ 2012-08-29 10:58 UTC (permalink / raw)
I wrote:
> Similarly, we write "if B then null; else Do_Something end if;" instead of
> "if B then else Do_Something end if;". This is an advantage of Ada that
> improves readability and helps to catch flaws.
Ooops! there is ";" missing behind "Do_Something".
> Here we are hurt by another minor but annoying inconsistency of the Ada
> syntax. Almost everywhere, we have to write "null" to make it explicit if
> we ask for nothing, or for nothing additional.
The inconsistency I mean is that, instead of writing "(null)" for the
empty parameter list, we just skip the parameter list.
> If we introduce the notation "(null)" for empty parameter lists, we can
> easily solve your issue:
>
> generic procedure Baz_1 (with X: Integer) (null);
> -- X is a generic formal object,
> -- (I am not sure if we should allow or even require "with" here.)
>
> generic procedure Baz_2 (null) (X: Integer);
> -- X is a plain argument
--
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany ----
<http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------ I love the taste of Cryptanalysis in the morning! ------
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
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-08-29 13:33 ` Georg Bauhaus
2 siblings, 2 replies; 40+ messages in thread
From: Niklas Holsti @ 2012-08-29 13:14 UTC (permalink / raw)
On 12-08-29 13:43 , stefan-lucks@see-the.signature wrote:
> On Wed, 29 Aug 2012, Dmitry A. Kazakov wrote:
>
>> No, I meant rather this:
>>
>> generic package P (Foo : function return Integer; Q : package...) is ...
>
> Indeed, the syntax for declaring a generic something (after the keyword
> "generic" the parameters come first, and the something and its name comes
> last) is counter-intuitive, different from any other declarations, and
> hurts readability. Consider the following simple example:
>
> generic
> type Item is private;
> type Many_Items is array(Positive range <>) of Item;
> with function "<"(Left, Right: Item) return Boolean is <>;
> function Minimum(List: Many_Items) return Item;
>
> Ask programmers without Ada experience what this is. Most would read this
> as a generic declaration of something -- but how many would read this as
> the generic declaration of a function called "Minimum"?
You may be right, but surely the syntax is very easy to teach and learn:
if you want to make a subprogram or a package generic, stick "generic"
and the list of generic formals in front of the "package", "procedure"
or "function".
> If the indention is lost,
An artificial assumption.
> even Ada-programmers would have problems to find
> out *what* is generically declared (a function) and what its name is
> ("Minimum").
Not really. Start from the end and scan backwards until you find
"package", "procedure", or "function". Or start from the beginning and
find "package", "procedure", or "function" that is not immediately
preceded by "with".
> Your idea seems to be to alternatively write the above declaration as
>
> generic function Minimum
> (type Item is private;
> type Many_Items is Array (Natural Range <>) of Item;
> function "<"(Left, Right: Item) return Boolean is <>)
> (List: Many_Items) return Item;
>
> This would be a lot more readable.
There is always a different opinion... I think it is much less readable,
because the separation between the list of generic formals and
subprogram formals is much less visible.
If Ada syntax is changed to put the name of the generic unit before the
formal parameters, I should want to require "with" before every generic
formal, and all within a single set of parentheses. Like this:
generic function Minimum (
with type Item is private;
with type Many_Items is array (Natural range <>) of Item;
with function "<" (Left, Right : Item) return Boolean is <>;
List : Many_Items)
return Item;
But as I said, I much prefer the current syntax.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 13:14 ` Niklas Holsti
@ 2012-08-29 17:52 ` stefan-lucks
[not found] ` <fbps38pgcuf8fgioptt39s6u7dme1aqs7r@invalid.netcom.com>
1 sibling, 0 replies; 40+ messages in thread
From: stefan-lucks @ 2012-08-29 17:52 UTC (permalink / raw)
On Wed, 29 Aug 2012, Niklas Holsti wrote:
> If Ada syntax is changed to put the name of the generic unit before the
> formal parameters, I should want to require "with" before every generic
> formal, and all within a single set of parentheses. Like this:
>
> generic function Minimum (
> with type Item is private;
> with type Many_Items is array (Natural range <>) of Item;
> with function "<" (Left, Right : Item) return Boolean is <>;
> List : Many_Items)
> return Item;
Actually, I woud like that.
> But as I said, I much prefer the current syntax.
Alas ...
--
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany ----
<http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------ I love the taste of Cryptanalysis in the morning! ------
^ permalink raw reply [flat|nested] 40+ messages in thread[parent not found: <fbps38pgcuf8fgioptt39s6u7dme1aqs7r@invalid.netcom.com>]
* Re: Real syntax problems in Ada
2012-08-29 10:43 ` stefan-lucks
2012-08-29 10:58 ` stefan-lucks
2012-08-29 13:14 ` Niklas Holsti
@ 2012-08-29 13:33 ` Georg Bauhaus
2012-08-29 17:20 ` Jeffrey Carter
2012-08-29 17:51 ` stefan-lucks
2 siblings, 2 replies; 40+ messages in thread
From: Georg Bauhaus @ 2012-08-29 13:33 UTC (permalink / raw)
On 29.08.12 12:43, stefan-lucks@see-the.signature wrote:
> Indeed, the syntax for declaring a generic something (after the keyword
> "generic" the parameters come first, and the something and its name comes
> last) is counter-intuitive, different from any other declarations, and
> hurts readability. Consider the following simple example:
>
> generic
> type Item is private;
> type Many_Items is array(Positive range <>) of Item;
> with function "<"(Left, Right: Item) return Boolean is <>;
> function Minimum(List: Many_Items) return Item;
>
> Ask programmers without Ada experience what this is. Most would read this
> as a generic declaration of something -- but how many would read this as
> the generic declaration of a function called "Minimum"?
It is good to see a reference to at least one of the touchstones
of readability.
> Your idea seems to be to alternatively write the above declaration as
>
> generic function Minimum
> (type Item is private;
> type Many_Items is Array (Natural Range <>) of Item;
> function "<"(Left, Right: Item) return Boolean is <>)
> (List: Many_Items) return Item;
>
> This would be a lot more readable.
(The touchstones of readability are not mentioned here.)
Why would a "(" be more readable? I'd like to 2nd any motion
for bracketing, but not in *this* way. One issue seems to be:
"Where do the generic formals end?"
The example replaces, in a sense, the keyword "function" after the
formals (Ada style) with a "(" (in suggested style). There may be
more "(" among the formals, like there are in the declaration of
Many_Items above. When declarations of formals become a little more
involved, then a "(" may easily make it to the start of a line,
forcing the reader to judge whether or not this "(" is the start of
the function's parameter profile. Thus, "if the indentation is
lost...", then the brackets will surely leave many at loss. (I don't
think that resorting to counting pairs of matching brackets counts as
a solution.) Because
*) the distance between the function's name and
its parameter profile is non-zero, and likely large;
*) the distinction between the two kinds of parameters is blurred,
not made clear, by overloading () once more;
*) using sequences of ()s here introduces ambiguity (in the mind
non-compiler readers) as entry families already use
sequences of ()s in a similar context, but with different
meaning.
The real problem for the reader of Ada generics seems to be finding
the spot where the generic formals end.
Interestingly, this problem is semi-solved in C++ (and Parasail).
Semi-solved because C++ template syntax is notorious for its
qualities, including >>, but nevertheless, there is no bracketing
problem in the sense of brackets marking a start-of-thing, and an
end-of-thing:
template <
bla bla
> class T : ...
Here, the right angle bracket lets the reader see end of generic
formals. Voil�, the usual block structure!
Far from wanting to recommend the syntax of C++---why, when even C++
programmers frown upon it, it seems as though, in Ada, the left
bracket named "generic" would need some kind of matching right
bracket, since then the words "package", "function", and "procedure"
will not need to convey two meanings in the case of generic units
(end of formals, and kind of unit).
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 13:33 ` Georg Bauhaus
@ 2012-08-29 17:20 ` Jeffrey Carter
2012-08-29 17:51 ` stefan-lucks
1 sibling, 0 replies; 40+ messages in thread
From: Jeffrey Carter @ 2012-08-29 17:20 UTC (permalink / raw)
On 08/29/2012 06:33 AM, Georg Bauhaus wrote:
>
> Why would a "(" be more readable? I'd like to 2nd any motion
> for bracketing, but not in *this* way. One issue seems to be:
> "Where do the generic formals end?"
Right. Using "Name : thing" notation could offer a solution to this:
Reductions : generic
-- generic formal parameters (or "null;" if there are none)
Reductions : package is
...
Reductions : private
...
Reductions : end;
The generic formal part ends when the name is repeated. This also means "with"
is not needed for generic formal subprograms and packages.
--
Jeff Carter
"You can never forget too much about C++."
115
--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
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
1 sibling, 1 reply; 40+ messages in thread
From: stefan-lucks @ 2012-08-29 17:51 UTC (permalink / raw)
On Wed, 29 Aug 2012, Georg Bauhaus wrote:
> On 29.08.12 12:43, stefan-lucks@see-the.signature wrote:
> > generic
> > type Item is private;
> > type Many_Items is array(Positive range <>) of Item;
> > with function "<"(Left, Right: Item) return Boolean is <>;
> > function Minimum(List: Many_Items) return Item;
> >
> > Ask programmers without Ada experience what this is. Most would read this
> > as a generic declaration of something -- but how many would read this as
> > the generic declaration of a function called "Minimum"?
>
> It is good to see a reference to at least one of the touchstones
> of readability.
What do you mean by "touchstones of readability"?
In any case. "Normal" declarations have *first* what is declared (e.g.,
"function", then the name, and then the parameter list. Which is logical
-- you first need to know what is declared, before you care about the
parameter list.
Generic declarations have first the parameter list (well, after the
keyword "generic"), and only then *what* is declared. This is convoluted
and ill readable. Or am I the only one who dislikes jumping from "generic"
down to "function" and then back to the line below "generic" when reading
stuff like the above? (Especially, of course, when the paramter list is
longer than just the 3 lines above ...)
--
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany ----
<http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------ I love the taste of Cryptanalysis in the morning! ------
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 17:51 ` stefan-lucks
@ 2012-08-30 9:12 ` Georg Bauhaus
0 siblings, 0 replies; 40+ messages in thread
From: Georg Bauhaus @ 2012-08-30 9:12 UTC (permalink / raw)
On 29.08.12 19:51, stefan-lucks@see-the.signature wrote:
> On Wed, 29 Aug 2012, Georg Bauhaus wrote:
>
>> On 29.08.12 12:43, stefan-lucks@see-the.signature wrote:
>>> generic
>>> type Item is private;
>>> type Many_Items is array(Positive range <>) of Item;
>>> with function "<"(Left, Right: Item) return Boolean is <>;
>>> function Minimum(List: Many_Items) return Item;
>>>
>>> Ask programmers without Ada experience what this is. Most would read this
>>> as a generic declaration of something -- but how many would read this as
>>> the generic declaration of a function called "Minimum"?
>>
>> It is good to see a reference to at least one of the touchstones
>> of readability.
>
> What do you mean by "touchstones of readability"?
I mean programmers reading source text. Someone has mentioned
a controlled experiment. Readers could demonstrate how well
they have understood what they have read.
> In any case. "Normal" declarations have *first* what is declared (e.g.,
> "function", then the name, and then the parameter list. Which is logical
> -- you first need to know what is declared, before you care about the
> parameter list.
Yes, and jumping back and forth means reading is not linear.
There might be readers, though, who would rather see a function
name and its profile declared without something in between,
interrupting the linear flow of thought (about function).
(Incidentally, would context clauses have to come after what is
declared, too? When I see context clauses, I know what to expect.
Arguably, "generic" serves a similar purpose.)
In any case,
generic function Minimum
(type Item is private;
type Many_Items is Array (Natural Range <>) of Item;
function "<"(Left, Right: Item) return Boolean is <>)
<<Minimum>> (List: Many_Items) return Item;
might be another way to indicate where the reader may find
the declared function's profile.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 15:14 ` Adam Beneschan
2012-08-28 16:18 ` J-P. Rosen
2012-08-28 16:39 ` Dmitry A. Kazakov
@ 2012-08-28 21:49 ` Randy Brukardt
2012-08-28 23:09 ` Adam Beneschan
2012-08-29 7:34 ` Egil Høvik
2 siblings, 2 replies; 40+ messages in thread
From: Randy Brukardt @ 2012-08-28 21:49 UTC (permalink / raw)
"Adam Beneschan" <adam@irvine.com> wrote in message
news:289703e7-1fba-41ce-b781-9e58ff2ec7df@googlegroups.com...
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
...
>> 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.
I feel that way too, but there is a semantic reason why this isn't possible.
Specifically, the part after the "is" of a type declaration is a "type
definition". These are anonymous and can appear in various other contexts
(anonymous array and access types, for instance). The name of a type comes
from the type declaration, which is a separate semantic entity (and has
subtly different rules). I know that Janus/Ada processes "type definitions"
separately from the declarations, and thus including a name in the anonymous
part would be difficult to manage.
I once seriously looked at proposing allowing a name in a record type
declaration, and I couldn't figure out a reasonable way to do so given the
existing Ada semantics. Figuring out some way to hack the wording so that
the name associated with the declaration somehow can be matched in the
definition would seem to require changes all over the standard all out of
proportion to the size of the problem. So I don't think this is ever going
to happen.
...
>> 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.
I suspect that if we had added this in Ada 2012 rather than Ada 2005, it
would have been an aspect -- using separate syntax is overkill for this
problem. I.e.
procedure Foo
with Overriding;
...
>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.)
As a user, I agree. As an implementer, I would look forward to implementing
the 5 pages of conformance rules needed for that... :-(
Randy.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 21:49 ` Randy Brukardt
@ 2012-08-28 23:09 ` Adam Beneschan
2012-08-29 7:34 ` Egil Høvik
1 sibling, 0 replies; 40+ messages in thread
From: Adam Beneschan @ 2012-08-28 23:09 UTC (permalink / raw)
On Tuesday, August 28, 2012 2:49:20 PM UTC-7, Randy Brukardt wrote:
> >> 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.
> I feel that way too, but there is a semantic reason why this isn't possible.
> Specifically, the part after the "is" of a type declaration is a "type
> definition". These are anonymous and can appear in various other contexts
> (anonymous array and access types, for instance). The name of a type comes
> from the type declaration, which is a separate semantic entity (and has
> subtly different rules). I know that Janus/Ada processes "type definitions"
> separately from the declarations, and thus including a name in the anonymous
> part would be difficult to manage.
>
> I once seriously looked at proposing allowing a name in a record type
> declaration, and I couldn't figure out a reasonable way to do so given the
> existing Ada semantics. Figuring out some way to hack the wording so that
> the name associated with the declaration somehow can be matched in the
> definition would seem to require changes all over the standard all out of
> proportion to the size of the problem. So I don't think this is ever going
> to happen.
Off the top of my head, it seems like you could modify 3.8 to allow "end <identifier>" in a record_type_definition, without saying anything in the Legality Rules (in 3.8) about the identifier. Then, in 3.2.1, you can add a Legality Rule that if a full_type_declaration includes a record_type_definition, and the record_type_definition ends with "end <identifier>", then the identifier name must match the defining_identifier of the type declaration. This would mean that if a record_type_definition is used anywhere else besides a full_type_declaration, then the identifier could be anything you want, which would be weird. But that's not a real problem, since record_type_definition is used only in one place in the syntax. It seems a little hacky since the Legality Rule would be in the wrong place, but I think it would work and wouldn't affect anything else in the RM.
-- Adam
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 21:49 ` Randy Brukardt
2012-08-28 23:09 ` Adam Beneschan
@ 2012-08-29 7:34 ` Egil Høvik
1 sibling, 0 replies; 40+ messages in thread
From: Egil Høvik @ 2012-08-29 7:34 UTC (permalink / raw)
On Tuesday, August 28, 2012 11:49:20 PM UTC+2, Randy Brukardt wrote:
> I feel that way too, but there is a semantic reason why this isn't possible.
> Specifically, the part after the "is" of a type declaration is a "type
> definition". These are anonymous and can appear in various other contexts
> (anonymous array and access types, for instance). The name of a type comes
> from the type declaration, which is a separate semantic entity (and has
> subtly different rules). I know that Janus/Ada processes "type definitions"
> separately from the declarations, and thus including a name in the anonymous
> part would be difficult to manage.
>
> I once seriously looked at proposing allowing a name in a record type
> declaration, and I couldn't figure out a reasonable way to do so given the
> existing Ada semantics. Figuring out some way to hack the wording so that
> the name associated with the declaration somehow can be matched in the
> definition would seem to require changes all over the standard all out of
> proportion to the size of the problem. So I don't think this is ever going
> to happen.
We can already use the name of a type inside it's own type definition
to denote the current instance of the type, so there must already be some
link between type declarations and type definitions, even in Janus/Ada.
The most famous example of this, is probably the Rosen Trick.
Allowing the type name at the end of the record definition can't be that
much more different from allowing it inside the record definition?
(I'm not a compiler writer, so I may have missed a few nuances here.
Please enlighten me)
--
~egilhh
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 8:13 Real syntax problems in Ada Dmitry A. Kazakov
` (3 preceding siblings ...)
2012-08-28 15:14 ` Adam Beneschan
@ 2012-08-28 19:41 ` Florian Weimer
2012-08-28 20:53 ` Shark8
2012-08-30 22:06 ` sbelmont700
5 siblings, 1 reply; 40+ messages in thread
From: Florian Weimer @ 2012-08-28 19:41 UTC (permalink / raw)
* Dmitry A. Kazakov:
> 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)?
There is no convenient way to write zero-element and one-element array
aggregates.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-28 19:41 ` Florian Weimer
@ 2012-08-28 20:53 ` Shark8
2012-08-28 21:07 ` Adam Beneschan
0 siblings, 1 reply; 40+ messages in thread
From: Shark8 @ 2012-08-28 20:53 UTC (permalink / raw)
On Tuesday, August 28, 2012 1:41:42 PM UTC-6, Florian Weimer wrote:
>
> There is no convenient way to write zero-element and one-element array
> aggregates.
Named null range for arrays? That'd take care of zero-elements.
Single-element... I'm not sure there's a good way to handle it [better] than what we have:
X : Array_Type:= ( 1 => ELEMENT ); -- or similar.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 20:53 ` Shark8
@ 2012-08-28 21:07 ` Adam Beneschan
2012-08-28 21:25 ` Shark8
2012-08-29 7:06 ` Dmitry A. Kazakov
0 siblings, 2 replies; 40+ messages in thread
From: Adam Beneschan @ 2012-08-28 21:07 UTC (permalink / raw)
On Tuesday, August 28, 2012 1:53:01 PM UTC-7, Shark8 wrote:
> On Tuesday, August 28, 2012 1:41:42 PM UTC-6, Florian Weimer wrote:
>
> > There is no convenient way to write zero-element and one-element array
> > aggregates.
>
> Named null range for arrays? That'd take care of zero-elements.
In the past, I've wanted something like (null array), which would be consistent since Ada already has (null record). The language would have to define what the actual bounds of the array are, however, since a program can still refer to A'First or A'Last and they have to be defined to be something. Starting with Ada 2005, it's now possible to say (1..0 => <>), which makes things better than they were before--at least there's no more problem of having to come up with a dummy value to put on the right side of the arrow.
-- Adam
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
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
1 sibling, 1 reply; 40+ messages in thread
From: Shark8 @ 2012-08-28 21:25 UTC (permalink / raw)
On Tuesday, August 28, 2012 3:07:32 PM UTC-6, Adam Beneschan wrote:
> On Tuesday, August 28, 2012 1:53:01 PM UTC-7, Shark8 wrote:
>
> In the past, I've wanted something like (null array), which would be consistent since Ada already has (null record). The language would have to define what the actual bounds of the array are, however, since a program can still refer to A'First or A'Last and they have to be defined to be something. Starting with Ada 2005, it's now possible to say (1..0 => <>), which makes things better than they were before--at least there's no more problem of having to come up with a dummy value to put on the right side of the arrow.
Except in the case of an array of not null access values. :(
(At least w/ GNAT; it rejects <> because the default is null, which is excluded.)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 21:25 ` Shark8
@ 2012-08-28 22:59 ` Adam Beneschan
0 siblings, 0 replies; 40+ messages in thread
From: Adam Beneschan @ 2012-08-28 22:59 UTC (permalink / raw)
On Tuesday, August 28, 2012 2:25:09 PM UTC-7, Shark8 wrote:
> On Tuesday, August 28, 2012 3:07:32 PM UTC-6, Adam Beneschan wrote:
>
> > On Tuesday, August 28, 2012 1:53:01 PM UTC-7, Shark8 wrote:
>
> >
>
> > In the past, I've wanted something like (null array), which would be consistent since Ada already has (null record). The language would have to define what the actual bounds of the array are, however, since a program can still refer to A'First or A'Last and they have to be defined to be something. Starting with Ada 2005, it's now possible to say (1..0 => <>), which makes things better than they were before--at least there's no more problem of having to come up with a dummy value to put on the right side of the arrow.
>
>
>
> Except in the case of an array of not null access values. :(
>
> (At least w/ GNAT; it rejects <> because the default is null, which is excluded.)
Hmmm... I can't even get GNAT to display a warning. I'm using 4.5.2.
Anyway, the behavior seems wrong; I can't find any Legality Rule that makes it illegal to declare an uninitialized object of any kind whose type is null-excluding access. Of course it will raise Constraint_Error at runtime, although it won't in a (1..0 => <>) case since the program doesn't attempt to initialize any values. I'm sure GNAT has a nonstandard mode that will reject a program if it "knows" there is something that is sure to raise an exception like this, but it shouldn't be doing it here.
-- Adam
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 21:07 ` Adam Beneschan
2012-08-28 21:25 ` Shark8
@ 2012-08-29 7:06 ` Dmitry A. Kazakov
2012-08-30 21:08 ` Randy Brukardt
1 sibling, 1 reply; 40+ messages in thread
From: Dmitry A. Kazakov @ 2012-08-29 7:06 UTC (permalink / raw)
On Tue, 28 Aug 2012 14:07:32 -0700 (PDT), Adam Beneschan wrote:
> Starting with Ada 2005, it's now possible to say (1..0 => <>), which makes
> things better than they were before--at least there's no more problem of
> having to come up with a dummy value to put on the right side of the
> arrow.
What about
(<> => <>)
? (:-))
Actually since we have Unicode, we could take use of U+2205 (empty set),
So:
(∅ => <>)
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-29 7:06 ` Dmitry A. Kazakov
@ 2012-08-30 21:08 ` Randy Brukardt
0 siblings, 0 replies; 40+ messages in thread
From: Randy Brukardt @ 2012-08-30 21:08 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:ldvcp6um0oly$.13zvgiqtmhctv.dlg@40tude.net...
> On Tue, 28 Aug 2012 14:07:32 -0700 (PDT), Adam Beneschan wrote:
>
>> Starting with Ada 2005, it's now possible to say (1..0 => <>), which
>> makes
>> things better than they were before--at least there's no more problem of
>> having to come up with a dummy value to put on the right side of the
>> arrow.
>
> What about
>
> (<> => <>)
>
> ? (:-))
>
> Actually since we have Unicode, we could take use of U+2205 (empty set),
> So:
>
> (? => <>)
Lovely. In the font in my newsreader, I get the dreaded square box for an
unrecognized character. So I've got a square box choosing an Ada box (the
name of "<>")! Looks pretty much the same as your first option. :-)
Randy.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-28 8:13 Real syntax problems in Ada Dmitry A. Kazakov
` (4 preceding siblings ...)
2012-08-28 19:41 ` Florian Weimer
@ 2012-08-30 22:06 ` sbelmont700
2012-08-30 22:34 ` Adam Beneschan
5 siblings, 1 reply; 40+ messages in thread
From: sbelmont700 @ 2012-08-30 22:06 UTC (permalink / raw)
On Tuesday, August 28, 2012 4:13:02 AM UTC-4, Dmitry A. Kazakov wrote:
> What are real problems with Ada syntax as opposed to the imaginary ones
Not that it's a syntax problem, but I've always been suprised by the choice to use 'all' to explicitly dereference an access value; I don't think a casual reader of the langauge would be able to guess what it does. Hey, if we can refer to p.all to talk about 'all' of the object, then shouldn't there be a p.some to talk about just a partial part? :-)
-sb
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
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
0 siblings, 2 replies; 40+ messages in thread
From: Adam Beneschan @ 2012-08-30 22:34 UTC (permalink / raw)
On Thursday, August 30, 2012 3:06:41 PM UTC-7, (unknown) wrote:
> On Tuesday, August 28, 2012 4:13:02 AM UTC-4, Dmitry A. Kazakov wrote:
>
> > What are real problems with Ada syntax as opposed to the imaginary ones
>
>
>
> Not that it's a syntax problem, but I've always been suprised by the choice to use 'all' to explicitly dereference an access value; I don't think a casual reader of the langauge would be able to guess what it does.
It makes some sense if A is an access to a record; then you can say A.abc for component "abc" in the record, A.xyz for component xyz, and A.all for the whole thing, i.e. all components. Of course, to be consistent, that would mean that if A were an access to an array, we'd use A(2) for the index=2 element, A(2..5) to refer to a slice of the array, and A(all) to refer to the entire array. Oh well.
-- Adam
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Real syntax problems in Ada
2012-08-30 22:34 ` Adam Beneschan
@ 2012-08-30 22:54 ` William Findlay
2012-08-31 7:39 ` Dmitry A. Kazakov
1 sibling, 0 replies; 40+ messages in thread
From: William Findlay @ 2012-08-30 22:54 UTC (permalink / raw)
On 30/08/2012 23:34, in article
d9d6d423-cc2b-4e97-ac06-8e684c756006@googlegroups.com, "Adam Beneschan"
<adam@irvine.com> wrote:
> On Thursday, August 30, 2012 3:06:41 PM UTC-7, (unknown) wrote:
>> On Tuesday, August 28, 2012 4:13:02 AM UTC-4, Dmitry A. Kazakov wrote:
>>
>>> What are real problems with Ada syntax as opposed to the imaginary ones
>>
>> Not that it's a syntax problem, but I've always been suprised by the choice
>> to use 'all' to explicitly dereference an access value; I don't think a
>> casual reader of the langauge would be able to guess what it does.
>
> It makes some sense if A is an access to a record; then you can say A.abc for
> component "abc" in the record, A.xyz for component xyz, and A.all for the
> whole thing, i.e. all components. Of course, to be consistent, that would
> mean that if A were an access to an array, we'd use A(2) for the index=2
> element, A(2..5) to refer to a slice of the array, and A(all) to refer to the
> entire array. Oh well.
This is more a comment on the thread in general than on Adam's remark.
There is a famous quotation by Emerson: A foolish consistency is the
hobgoblin of little minds.
While there is much to be said for a general predictability of style and
syntax, a principle that Ada follows by and large; it is also true that a
moderate variety of expression sharpens the attention and prevents a text
from melting into a homogeneous mass with few obvious points of reference.
Some of the proposals seem to risk falling into that trap, in my view.
I think Ada has it about right.
--
Bill Findlay
with blueyonder.co.uk;
use surname & forename;
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Real syntax problems in Ada
2012-08-30 22:34 ` Adam Beneschan
2012-08-30 22:54 ` William Findlay
@ 2012-08-31 7:39 ` Dmitry A. Kazakov
1 sibling, 0 replies; 40+ messages in thread
From: Dmitry A. Kazakov @ 2012-08-31 7:39 UTC (permalink / raw)
On Thu, 30 Aug 2012 15:34:08 -0700 (PDT), Adam Beneschan wrote:
> Of course, to be consistent, that
> would mean that if A were an access to an array, we'd use A(2) for the
> index=2 element, A(2..5) to refer to a slice of the array, and A(all) to
> refer to the entire array. Oh well.
There is an alternative. Ada could pointers fully transparent. So Ptr_1 :=
Ptr_2 would have the meaning of present Ptr_1.all := Ptr_2.all.
Pointer-specific operations would be defined explicitly
procedure Shallow_Copy (Left : in out access-type; Right : access-type);
procedure Assign (Left : in out access-type; Right : target-type);
...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 40+ messages in thread