Pondering what rationale behind record type

Pondering what rationale behind record type

[Anh Vo]

Some time I am wondering why record type has different syntax pattern
than the rest with respect to type ending text. That is it ends with
'end record;' no matter what the identifier is. The rest of others end
with 'end identifier'. Below are examples regarding this subject.

type Data is record
   X_Coord : Integer := 0;
   Y_Coord : Integer := 0;
    -- more components
end record;

task type Event_Monitor is
    entry Start;
    entry Process (...)
end Event_Monitor;

Anh Vo

Re: Pondering what rationale behind record type

[Adam Beneschan]

On May 9, 10:47 am, Anh Vo <anhvofrc...@gmail.com> wrote:
> Some time I am wondering why record type has different syntax pattern
> than the rest with respect to type ending text. That is it ends with
> 'end record;' no matter what the identifier is. The rest of others end
> with 'end identifier'. Below are examples regarding this subject.
>
> type Data is record
>    X_Coord : Integer := 0;
>    Y_Coord : Integer := 0;
>     -- more components
> end record;
>
> task type Event_Monitor is
>     entry Start;
>     entry Process (...)
> end Event_Monitor;

Heh ... good question.  I have to say I get tripped up by this a lot;
I type things like "type Some_Type is record ... end Some_Type;"
fairly frequently, and sometimes I don't catch it before the compiler
does.

Maybe the BNF gives a clue.  In Ada 83, the "task type" and "end" were
part of the same syntax definition, so it was clear that the "end"
ended the "task type" and thus sort of belonged to it; while the
"record" and "end record" keywords were part of the
"record_type_definition" syntax rule, which is separate from the rule
that contains "type identifier [discriminant_part] is
type_definition;", so maybe they didn't want an "end" in one syntax
rule to refer to something in another rule.  Just a wild guess, but
perhaps that's the rationale for the original syntax.  (Note that this
doesn't apply in Ada 95+ since the "end" of a task type is now in a
different syntax rule.  I'm just speculating about the original
rationale.)

                               -- Adam

Re: Pondering what rationale behind record type

[Niklas Holsti]

Adam Beneschan wrote:
> On May 9, 10:47 am, Anh Vo <anhvofrc...@gmail.com> wrote:
>> Some time I am wondering why record type has different syntax pattern
>> than the rest with respect to type ending text. That is it ends with
>> 'end record;' no matter what the identifier is. The rest of others end
>> with 'end identifier'. Below are examples regarding this subject.
>>
>> type Data is record
>>    X_Coord : Integer := 0;
>>    Y_Coord : Integer := 0;
>>     -- more components
>> end record;
>>
>> task type Event_Monitor is
>>     entry Start;
>>     entry Process (...)
>> end Event_Monitor;
> 
> Heh ... good question.  I have to say I get tripped up by this a lot;
> I type things like "type Some_Type is record ... end Some_Type;"
> fairly frequently, and sometimes I don't catch it before the compiler
> does.

I make that mistake often, too. I would vote for a change in the 
language to allow "end Some_Type" as an alternative to "end record".

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Pondering what rationale behind record type

[Dmitry A. Kazakov]

On Mon, 09 May 2011 22:51:42 +0300, Niklas Holsti wrote:

> Adam Beneschan wrote:

>> Heh ... good question.  I have to say I get tripped up by this a lot;
>> I type things like "type Some_Type is record ... end Some_Type;"
>> fairly frequently, and sometimes I don't catch it before the compiler
>> does.
> 
> I make that mistake often, too. I would vote for a change in the 
> language to allow "end Some_Type" as an alternative to "end record".

Count me in.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Pondering what rationale behind record type

[Anh Vo]

On May 9, 1:02 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 09 May 2011 22:51:42 +0300, Niklas Holsti wrote:
> > Adam Beneschan wrote:
> >> Heh ... good question.  I have to say I get tripped up by this a lot;
> >> I type things like "type Some_Type is record ... end Some_Type;"
> >> fairly frequently, and sometimes I don't catch it before the compiler
> >> does.
>
> > I make that mistake often, too. I would vote for a change in the
> > language to allow "end Some_Type" as an alternative to "end record".
>
> Count me in.

I am in automatically.

I am hoping that it is still time to put it in Ada 2012. Of course, we
need to hear from Randy, Tucker and others first.

Anh Vo

Re: Pondering what rationale behind record type

[Georg Bauhaus]

On 5/9/11 10:12 PM, Anh Vo wrote:
> On May 9, 1:02 pm, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de>
> wrote:
>> On Mon, 09 May 2011 22:51:42 +0300, Niklas Holsti wrote:
>>> Adam Beneschan wrote:
>>>> Heh ... good question.  I have to say I get tripped up by this a lot;
>>>> I type things like "type Some_Type is record ... end Some_Type;"
>>>> fairly frequently, and sometimes I don't catch it before the compiler
>>>> does.
>>
>>> I make that mistake often, too. I would vote for a change in the
>>> language to allow "end Some_Type" as an alternative to "end record".
>>
>> Count me in.
>
> I am in automatically.
>
> I am hoping that it is still time to put it in Ada 2012. Of course, we
> need to hear from Randy, Tucker and others first.

I'll advocate (and speculate) against, even though I frequently type
"end R" when I should type "end record" (of have my editor expand it
for me).  There might be a fix, though.

I'll list a few points that refer to bracketing constructs that
I think are nicely specific. They make "end record" a logical choice,
but not "end R".

First, in the phrase "end X", the "X" part can usually be omitted.
To have just "end [R]" in record declarations is less specific
(specifically finishing off record declarations), and less informative
than "end record".

Second, in "end [X]", where X is a name, the corresponding left bracket
for "end" either is "begin" or we have seen something that wraps
around declarations of callable constructs, if I'm not missing something.

So whenever we put "record" (or "case", or "if", etc) after an "end",
this is delimiting a bracketed construct that is neither a block
nor a {package, task, protected}. A piece of syntax that helps
the reader keeping different things apart.

By reversing things for reasons of contrasting the options,
assume "package ... end package;" is suggested as a replacement
of the current syntax.  Wouldn't you instead want
"package P ... end package P;" instead?  Fortran and ParaSail
have these conventions, I think.

Consequently, how about this addition to the syntax of record
declarations:

    type R is
      record
         ...
      end record R;

?

Re: Pondering what rationale behind record type

[Dmitry A. Kazakov]

On Tue, 10 May 2011 00:03:37 +0200, Georg Bauhaus wrote:

> First, in the phrase "end X", the "X" part can usually be omitted.

That is another fix to do: a default profile which would forbid omitting
the name. I saw no Ada program in my life which omitted names in the ends.

> So whenever we put "record" (or "case", or "if", etc) after an "end",

These are anonymous constructs. The only reason why record bracket should
not contain its name is when there is no name, e.g. as Randy has pointed
out, in an anonymous record type. They are illegal in Ada, but an imaginary
example could be:

   function Get_Token (File : File_Type) return
      (Matched : Boolean; Length : Positive) record
         case Matched is
            when True => Token : String (1..Length);
            when False => null;
         end case;
      end record;

The result is this anonymous record:

type <anonymous> (Matched : Boolean; Length : Positive) is record
   case Matched is
      when True => Token : String (1..Length);
      when False => null;
   end case;
end record;

We could continue the exercise with other types:

   function Get_Handle  (...) return
      new Ada.Finalization.Controlled with record ... end record;

   function Get_List  (...) return
      array (Positive range <>) of Element;

Do you like it? (:-))

> Consequently, how about this addition to the syntax of record
> declarations:
> 
>     type R is
>       record
>          ...
>       end record R;
> 
> ?

Shudder.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Pondering what rationale behind record type

[Georg Bauhaus]

On 10.05.11 09:45, Dmitry A. Kazakov wrote:
> On Tue, 10 May 2011 00:03:37 +0200, Georg Bauhaus wrote:
> 
>> First, in the phrase "end X", the "X" part can usually be omitted.
> 
> That is another fix to do: a default profile which would forbid omitting
> the name. I saw no Ada program in my life which omitted names in the ends.
> 
>> So whenever we put "record" (or "case", or "if", etc) after an "end",
> 
> These are anonymous constructs.

Though a loop can have a name.

Anything wrong with (i.e. makes you shudder)

   Label_A: loop
     ...
   end loop Label_A;

?

> The only reason why record bracket should
> not contain its name is when there is no name, e.g. as Randy has pointed
> out, in an anonymous record type. They are illegal in Ada, but an imaginary
> example could be:
> 
>    function Get_Token (File : File_Type) return
>       (Matched : Boolean; Length : Positive) record
>          ...

In order to be competitive in the current discussion,
pro "end [X]", the example would have to be

   type Get_Token is function (File : File_Type) return
       ((Matched : Boolean; Length : Positive) record
           case Matched is
             when True => Token : String (1..Length);
             when False => null;
           end case;
        end record)
   end Get_Token;

Re: Pondering what rationale behind record type

[Dmitry A. Kazakov]

On Tue, 10 May 2011 12:12:10 +0200, Georg Bauhaus wrote:

> On 10.05.11 09:45, Dmitry A. Kazakov wrote:
>> On Tue, 10 May 2011 00:03:37 +0200, Georg Bauhaus wrote:
>> 
>>> First, in the phrase "end X", the "X" part can usually be omitted.
>> 
>> That is another fix to do: a default profile which would forbid omitting
>> the name. I saw no Ada program in my life which omitted names in the ends.
>> 
>>> So whenever we put "record" (or "case", or "if", etc) after an "end",
>> 
>> These are anonymous constructs.
> 
> Though a loop can have a name.
> 
> Anything wrong with (i.e. makes you shudder)
> 
>    Label_A: loop
>      ...
>    end loop Label_A;
> 
> ?

loop A do
   ...
end A;

>> The only reason why record bracket should
>> not contain its name is when there is no name, e.g. as Randy has pointed
>> out, in an anonymous record type. They are illegal in Ada, but an imaginary
>> example could be:
>> 
>>    function Get_Token (File : File_Type) return
>>       (Matched : Boolean; Length : Positive) record
>>          ...
> 
> In order to be competitive in the current discussion,
> pro "end [X]", the example would have to be
> 
>    type Get_Token is function (File : File_Type) return
>        ((Matched : Boolean; Length : Positive) record
>            case Matched is
>              when True => Token : String (1..Length);
>              when False => null;
>            end case;
>         end record)
>    end Get_Token;

No, Get_Token would be a function-type. E.g.

   type Func is function (X : Float) return Float;

Then

   function Integrate (...; What : Func) return Float;

Which could be be anonymous as well:

   function Integrate (...; What :  function (X : Float) return Float)
      return Float;

Or the example with Get_Token:

   procedure Parse
   (  File : File_Type;
      Get_Token : function (File : File_Type) return
         ((Matched : Boolean; Length : Positive) record
            case Matched is
              when True => Token : String (1..Length);
              when False => null;
            end case;
         end record
   );

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Pondering what rationale behind record type

[Georg Bauhaus]

On 10.05.11 14:08, Dmitry A. Kazakov wrote:

>> Anything wrong with (i.e. makes you shudder)
>>
>>    Label_A: loop
>>      ...
>>    end loop Label_A;
>>
>> ?
> 
> loop A do
>    ...
> end A;

Consequently,

if ... then A do
   ...
else
   ...
end A;

I guess?

>>    type Get_Token is function (File : File_Type) return
>>        ((Matched : Boolean; Length : Positive) record
>>            case Matched is
>>              when True => Token : String (1..Length);
>>              when False => null;
>>            end case;
>>         end record)
>>    end Get_Token;
> 
> No, Get_Token would be a function-type.

Yes. It was suggested that the meat part of type declarations
should end in "end [X]", not "end keyword", so that

> E.g.

    type Func is
       function (X : Float) return Float;
    end Func;

Re: Pondering what rationale behind record type

[Dmitry A. Kazakov]

On Tue, 10 May 2011 14:18:28 +0200, Georg Bauhaus wrote:

> On 10.05.11 14:08, Dmitry A. Kazakov wrote:
> 
>>> Anything wrong with (i.e. makes you shudder)
>>>
>>>    Label_A: loop
>>>      ...
>>>    end loop Label_A;
>>>
>>> ?
>> 
>> loop A do
>>    ...
>> end A;
> 
> Consequently,
> 
> if ... then A do
>    ...
> else
>    ...
> end A;
> 
> I guess?

What is the reason to name statements? But if you wanted to, it would be

if A do <condition> then
   ...
else
   ...
end A;

>>>    type Get_Token is function (File : File_Type) return
>>>        ((Matched : Boolean; Length : Positive) record
>>>            case Matched is
>>>              when True => Token : String (1..Length);
>>>              when False => null;
>>>            end case;
>>>         end record)
>>>    end Get_Token;
>> 
>> No, Get_Token would be a function-type.
> 
> Yes. It was suggested that the meat part of type declarations
> should end in "end [X]", not "end keyword", so that
> 
>> E.g.
> 
>     type Func is
>        function (X : Float) return Float;
>     end Func;

No, because here there is no left bracket that follows "is". Compare

   type String is array (...) of ...;

The type declaration syntax is:

   type <name> is <definition>;

<definition> can be:

1. plain, e.g. private; range ...; delta ...; array; access ...; mod ...

2. nested, like task, record, protected object. Their declarations are
unfortunately irregular. They should have been

   type Worker is task ... end Worker;
   type Mutex is protected ... end Mutex;
   type Data is record ... end Data;

Of course one could deploy the alternative schema:

   <class-name> type <name> is <definition>; 

E.g.

   task type A is ... end A;
   record type B is ... end B;
   array type String is (Positive range <>) of Character;
   range type Integer is -2**31-1..2**31-1;

But mixing them was a bad idea.

P.S. task and protected should have been record types with entries being
primitive operations.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Pondering what rationale behind record type

[Martin]

On May 10, 1:50 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 10 May 2011 14:18:28 +0200, Georg Bauhaus wrote:
> > On 10.05.11 14:08, Dmitry A. Kazakov wrote:
>
> >>> Anything wrong with (i.e. makes you shudder)
>
> >>>    Label_A: loop
> >>>      ...
> >>>    end loop Label_A;
>
> >>> ?
>
> >> loop A do
> >>    ...
> >> end A;
>
> > Consequently,
>
> > if ... then A do
> >    ...
> > else
> >    ...
> > end A;
>
> > I guess?
>
> What is the reason to name statements? But if you wanted to, it would be
>
> if A do <condition> then
>    ...
> else
>    ...
> end A;
>
>
>
>
>
>
>
>
>
> >>>    type Get_Token is function (File : File_Type) return
> >>>        ((Matched : Boolean; Length : Positive) record
> >>>            case Matched is
> >>>              when True => Token : String (1..Length);
> >>>              when False => null;
> >>>            end case;
> >>>         end record)
> >>>    end Get_Token;
>
> >> No, Get_Token would be a function-type.
>
> > Yes. It was suggested that the meat part of type declarations
> > should end in "end [X]", not "end keyword", so that
>
> >> E.g.
>
> >     type Func is
> >        function (X : Float) return Float;
> >     end Func;
>
> No, because here there is no left bracket that follows "is". Compare
>
>    type String is array (...) of ...;
>
> The type declaration syntax is:
>
>    type <name> is <definition>;
>
> <definition> can be:
>
> 1. plain, e.g. private; range ...; delta ...; array; access ...; mod ...
>
> 2. nested, like task, record, protected object. Their declarations are
> unfortunately irregular. They should have been
>
>    type Worker is task ... end Worker;
>    type Mutex is protected ... end Mutex;
>    type Data is record ... end Data;
>
> Of course one could deploy the alternative schema:
>
>    <class-name> type <name> is <definition>;
>
> E.g.
>
>    task type A is ... end A;
>    record type B is ... end B;
>    array type String is (Positive range <>) of Character;
>    range type Integer is -2**31-1..2**31-1;
>
> But mixing them was a bad idea.
>
> P.S. task and protected should have been record types with entries being
> primitive operations.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Doesn't 'type' become redundant at this point?...

-- Martin

Re: Pondering what rationale behind record type

[Dmitry A. Kazakov]

On Tue, 10 May 2011 07:20:21 -0700 (PDT), Martin wrote:

[...] 
> Doesn't 'type' become redundant at this point?...

At which point? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Pondering what rationale behind record type

[Shark8]

On May 10, 7:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> What is the reason to name statements?

Simple: to aid in readability.
I have a few rather deeply nested items where I'm tokenizing
PostScript
(due the rules of the language) and it is handy to have things like
-- Case C, When C '<' =>
Read_Character( C, Input );
HANDLE_LT: -- less than
if C = '<' then
 Return Dictionary_Type;
elsif C = '~' then
 Return String_Type;
else
 Unread_Character( C, Input );
 Return -- I forgot what the last case, just '<', was...
end if HANDLE_LT;

There's even a few in blocks where I handle things like
names ['identifiers'] vs. numbers; the PLRM defines a name
as a string of "regular characters which cannot be interpreted
as a string." This means that 23E4 is a number while 24F4 is
a name as are $4, 2i3, @, 2^4 and so forth.

It REALLY does help in sorting where you are in the decoding.

Re: Pondering what rationale behind record type

[Dmitry A. Kazakov]

On Tue, 10 May 2011 19:28:16 -0700 (PDT), Shark8 wrote:

> On May 10, 7:50�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>
>> What is the reason to name statements?
> 
> Simple: to aid in readability.
> I have a few rather deeply nested items where I'm tokenizing
> PostScript
> (due the rules of the language) and it is handy to have things like
> -- Case C, When C '<' =>
> Read_Character( C, Input );
> HANDLE_LT: -- less than
> if C = '<' then
>  Return Dictionary_Type;
> elsif C = '~' then
>  Return String_Type;
> else
>  Unread_Character( C, Input );
>  Return -- I forgot what the last case, just '<', was...
> end if HANDLE_LT;

The above should have been a "case", or better matching the input against a
token table with semantic callbacks doing things.

> There's even a few in blocks where I handle things like
> names ['identifiers'] vs. numbers; the PLRM defines a name
> as a string of "regular characters which cannot be interpreted
> as a string." This means that 23E4 is a number while 24F4 is
> a name as are $4, 2i3, @, 2^4 and so forth.

That is semantic analysis to me. No need to burden parser with that. You
parse 23E4 as a token and later interpret it as an identifier or number.

> It REALLY does help in sorting where you are in the decoding.

I don't think that large "if"s is a good style. No names may help that.
BTW, in your case "then", "else", "elsif" must carry the name of the "if"
they belong.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Pondering what rationale behind record type

[Shark8]

On May 11, 2:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 10 May 2011 19:28:16 -0700 (PDT), Shark8 wrote:
> > On May 10, 7:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> >> What is the reason to name statements?
>
> > Simple: to aid in readability.
> > I have a few rather deeply nested items where I'm tokenizing
> > PostScript
> > (due the rules of the language) and it is handy to have things like
> > -- Case C, When C '<' =>
> > Read_Character( C, Input );
> > HANDLE_LT: -- less than
> > if C = '<' then
> >  Return Dictionary_Type;
> > elsif C = '~' then
> >  Return String_Type;
> > else
> >  Unread_Character( C, Input );
> >  Return -- I forgot what the last case, just '<', was...
> > end if HANDLE_LT;
>
> The above should have been a "case", or better matching the input against a
> token table with semantic callbacks doing things.
>
> > There's even a few in blocks where I handle things like
> > names ['identifiers'] vs. numbers; the PLRM defines a name
> > as a string of "regular characters which cannot be interpreted
> > as a string." This means that 23E4 is a number while 24F4 is
> > a name as are $4, 2i3, @, 2^4 and so forth.
>
> That is semantic analysis to me. No need to burden parser with that. You
> parse 23E4 as a token and later interpret it as an identifier or number.

True, it is semantic analysis.
The way I have it set up is this case structure is inside my
tokenizer;
the tokenizer may or may not be on the same machine as the parser
itself.

One of the reasons that I'm forced to use if-statements in the cases
for
the various constructs is because some of them are dependent on state:
Strings, for example are delimited with parentheses, BUT may contain
balanced pairs or be escaped out.

So, (Here we are (nowhere).) is equal to the Ada String "Here we are
(nowhere)."
A quick/easy "go to the next closing paren" will produce incorrect
results,
just as it would in the string (:/)) which is equal the Ada String
":)".

Finally, the case I was writing from memory, the [first] less-than can
be:
1 - The first part of the "<<", a Dictionary, which is self-
delimiting.
2 - The first part of the "<~", which is a Hex-encoded String (IIRC).
3 - I still can't remember what just '<' was...

> > It REALLY does help in sorting where you are in the decoding.
>
> I don't think that large "if"s is a good style. No names may help that.
> BTW, in your case "then", "else", "elsif" must carry the name of the "if"
> they belong.

I don't either; but the PLRM does describe the parser as consuming the
characters/tokens from the input and then producing the proper
object*.

Also, I want to have the ability to have the parser a separate
component,
likely a server on a remote-machine handling multiple clients, and
that
imposes its own constraints as well.

* Not as in OOP-Object, but as in component... though you could use
OOP.

Re: Pondering what rationale behind record type

[Dmitry A. Kazakov]

On Wed, 18 May 2011 15:55:03 -0700 (PDT), Shark8 wrote:

> One of the reasons that I'm forced to use if-statements in the cases for
> the various constructs is because some of them are dependent on state:
> Strings, for example are delimited with parentheses, BUT may contain
> balanced pairs or be escaped out.
> 
> So, (Here we are (nowhere).) is equal to the Ada String "Here we are
> (nowhere)."
> A quick/easy "go to the next closing paren" will produce incorrect
> results,
> just as it would in the string (:/)) which is equal the Ada String
> ":)".

I see, I likely would do this differently as well. Either brackets are
parts of an expression to be evaluated later or a part of a literal
expression handled by a recursively descend part (i.e. in a physically
different case-statement).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Pondering what rationale behind record type

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:90148303-4dc4-4c05-882f-88dd69a95494@z13g2000prk.googlegroups.com...
On May 9, 10:47 am, Anh Vo <anhvofrc...@gmail.com> wrote:
>> Some time I am wondering why record type has different syntax pattern
>> than the rest with respect to type ending text. ...

>Heh ... good question.  I have to say I get tripped up by this a lot;
>I type things like "type Some_Type is record ... end Some_Type;"
>fairly frequently, and sometimes I don't catch it before the compiler
>does.
>
>Maybe the BNF gives a clue.  In Ada 83, the "task type" and "end" were
>part of the same syntax definition, so it was clear that the "end"
>ended the "task type" and thus sort of belonged to it; while the
>"record" and "end record" keywords were part of the
>"record_type_definition" syntax rule, which is separate from the rule
>that contains "type identifier [discriminant_part] is
>type_definition;", so maybe they didn't want an "end" in one syntax
>rule to refer to something in another rule.  Just a wild guess, but
>perhaps that's the rationale for the original syntax.  (Note that this
>doesn't apply in Ada 95+ since the "end" of a task type is now in a
>different syntax rule.  I'm just speculating about the original
>rationale.)

I would guess that you have most of the reason. My guess (and I don't know 
anything more about this than you do) is that the definition syntax exists 
to allow for anonymous types. If you had an anonymous record type, it would 
be hard to write the matching identifier. :-)

But most of the anonymous types were stripped out of Ada early on, because 
they caused problems with where declarations happened (think about the rules 
of 7.3.1 applied to nested, anonymous types - gag!) And they forgot to 
change the syntax.

Every once in a while, someone has suggested some sort of fix for this 
syntax glitch (I think it affects everyone), but we've never actually 
followed through. Probably someone should send a request to Ada-Comment so 
it makes it onto an agenda someday.

                                           Randy.

Re: Pondering what rationale behind record type

[J-P. Rosen]

Le 09/05/2011 19:47, Anh Vo a �crit :
> Some time I am wondering why record type has different syntax pattern
> than the rest with respect to type ending text. That is it ends with
> 'end record;' no matter what the identifier is. The rest of others end
> with 'end identifier'. 
'if' ends with 'end if', 'loop' ends with 'end loop'... Granted, if the
loop is named, then it ends with 'end loop L'. So, maybe the perfect
solution would be 'end record Rec' - but some would find that too much.

TBH, there is not always a strong rationale to issues related with
concrete syntax. It reflects the feeling, ideas, and sense of aesthetic
of the design team. These may vary with people, but also over time: in
the 80s, it was considered good practice to have variables in all caps,
now it is regarded as shouting.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Pondering what rationale behind record type

[anon]

All specification for executable units that have both public and private 
declarations such as task and protected (since Ada 95) types have the 
same basic design. 


         <type> "type" <unit name> [ discriminant part ) is
                declaration section
          private
                declaration section
          end <unit name> 

And To change it to now for Ada 2012. For what reason?

The difference is the task and protected types defines an executable 
unit while normally type declarations define data objects. It is easier 
and less misunderstood to keep the two designs structures separate.

And I think it would cause a bigger problem in the Ada programming 
community. Too many design changes causes too many re-writes of existing 
code to use on newer systems. Plus, there's the learn curve which as been a 
big problem for Ada from the start. Every time someone learns a version
of Ada there's a new one coming out that contains too many changes with a  
few changes having no real reason for that change. That happen when Ada 
first came out. When programmers finally had a working knowledge of Ada 
83. Then Ada 95 comes out with some improvement and a lot of changes to 
Ada 83. And no concern or corrections for compiler checkable "Erroneous 
Errors". Some Ada programmers spent their time back learning the new 
rules and rewriting a lot of Ada 83 code. While others say too many new 
rules and drop Ada for a less altered language like as C. 

So, you could say this type of concepts is just another nail to hurt Ada.


In <e49186b6-9c80-4788-a64f-dd9aba151f02@u26g2000vby.googlegroups.com>, Anh Vo <anhvofrcaus@gmail.com> writes:
>Some time I am wondering why record type has different syntax pattern
>than the rest with respect to type ending text. That is it ends with
>'end record;' no matter what the identifier is. The rest of others end
>with 'end identifier'. Below are examples regarding this subject.
>
>type Data is record
>   X_Coord : Integer := 0;
>   Y_Coord : Integer := 0;
>    -- more components
>end record;
>
>task type Event_Monitor is
>    entry Start;
>    entry Process (...)
>end Event_Monitor;
>
>Anh Vo