Re: Rational for not making cursor tagged in Containers

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

On Fri, 20 Apr 2007 21:37:09 +0200, Georg Bauhaus wrote:

> On Fri, 2007-04-20 at 17:13 +0200, Dmitry A. Kazakov wrote:
>> You still can use
>> plain records as an abbreviation to: this implements a record interface and
>> surprisingly is also built-it record.
> 
> Except for the surprise that's fine, then. (I'm curious
> what your ideas are regarding rules for accessing sister record
> components in .Mumble procedures, elaboration order, etc.. I'm
> assuming that the thing is more than a syntactical device?)

Why should it be anything more? It is no different from any other private
type. It is the private implementation which determines presentation,
construction and finalization.

>>> This is where it becomes dangerous, I think. Suggesting that programmers
>>> can implement "linguistic interfaces" forces programmers to be language
>>> designers, profiting from decades of language research, compilation
>>> technology, etc. etc..
>> 
>> Honestly, I don't see what is so especially dangerous in X.A as compared to
>> A(X).
> 
> I had understood that plain records were to be abandoned in favor
> of a set of record interface rules not only permitting programmers to
> implement record interfaces, but instead forcing them to do
> so because record mechanisms would no longer be part of the language.

Not at all. An ability to write

   type N is range 1..100;

by no means precludes Standard.Integer.

However I can imagine guidelines and code quality requirements which would
limit public use of record types in favor of interfaces. For the same
reasons why one would argue against use of Standard.Integer.

> That is,
> 
>   X.A := whatever(expr);
> 
> must in effect become
> 
>   whatever(X, expr);

It is how it works right now. I bet any compiler generates some inlined
stuff to access record members.
 
> which does whatever it does. (Would we have
>   whatever(X, expr(T'access))
> in default initializers for limited types?)

No. Why should it? Thee is no connection between "." operation and
initialization.

But, why do you see it as a problem? Limited record [interface] is not one
of its members. You can have limited records on non-limited components.

>>>>> Not every programming team consists of real or even wannabe
>>>>> language designers. But who else has even got a chance of knowing
>>>>> what they are doing to a larger program when implementing the
>>>>> concept of record?
>>>> 
>>>> Why they are allowed to implement a concept of task,
>>> 
>>> Uh, what do you mean?
>> 
>> I mean they are allowed to write
>> 
>>    task type X is
>> 
>> but not
>> 
>>    record type X is
>> 
>> (as opposed to type Y is record [X])
>> 
>> IMO, task is far more conceptually complex than a container of fixed number
>> of elements indexed by statically known strings.
> 
> By analogy, and consistent with the desired record interfaces,
> I will be asking for task type interfaces (no, not really).

They already exist in Ada 2005.

> This is a good illustration of what I meant to say. You can choose
> between two points of view:
> 1 this gives programmers the freedom to implement their ideas
>   of a concurrent execution in a guided fashion.

No it does not, because there is no language primitive other than built-in
task to implement a task interface. For this reason it is safe. However, if
Ada would in some future provide interfacing with other concurrent
languages, one could have alternatives to built-in tasks.

>>  I cannot understand why a
>> record view should enforce anything on the implementation of, beyond that
>> view.
> 
> Maybe for ease of recognition and simplicity of prediction in typical
> systems programming?  When I see X.A := 16#FE#; and notice that X
> is of a simple record type, I expect only a small number of mishaps.

You can't. X.A is mapped to a hardware port. The bit 8 set in that port
initiates an emergency shut-down sequence...

>>  Also I fail to understand why polymorphic objects has to be records
>> and not arrays or access types. Why array or number cannot have
>> discriminants, but records can?
> 
> "Uniformity.  Discriminants make sense for any composite type.

Discriminants make sense for ANY type, be it record or Boolean.

> In Ada
> 9X, we allow them for any composite type except array types.  The
> array-type restriction is for ease of implementation -- it does not
> simplify the language nor make it easier to use.

This is disputable. There exists numerous examples when disciminants for
arrays were quite useful. The classical example is arrays of arrays:

type X is array (... range <>) of ..;
type Y is array (... range <>) of Y (??????); -- Go figure out!

It wouldn't be a problem if there were array interfaces, but they don't
exist either.

> Adding another
> restriction for task types would decrease uniformity further.
> Discriminants are allowed for protected types; disallowing them for
> tasks would make tasks a second-class citizen."
> -- http://archive.adaic.com/standards/95lsn/LSN1044.TaskDisc.txt
> 
> 
> You do not want subprogram interfaces, I presume? :-)

We already have then, they are called abstract subprograms.

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