Re: Rational for not making cursor tagged in Containers

[Georg Bauhaus <bauhaus@futureapps.de>]

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?)


> > 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.
That is,

  X.A := whatever(expr);

must in effect become

  whatever(X, expr);

which does whatever it does. (Would we have
  whatever(X, expr(T'access))
in default initializers for limited types?)




> >>> 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).
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.
2 this places the burden of implementing a tasking RTS on the
  shoulders of the programmers.


>  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.


>  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.  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.  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? :-)