Re: Pondering what rationale behind record type

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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