Re: Rational for not making cursor tagged in Containers

[Georg Bauhaus <bauhaus@futureapps.de>]

On Fri, 2007-04-20 at 14:55 -0500, Randy Brukardt wrote: 
> "Georg Bauhaus" <bauhaus@futureapps.de> wrote in message
> news:1177097829.26685.36.camel@localhost.localdomain...
> ...
> > By analogy, and consistent with the desired record interfaces,
> > I will be asking for task type interfaces (no, not really).
> 
> Ada already has task interfaces, so you don't need to ask. ;-)

I meant something different (i.e. not synchronized interfaces),
based on my initial understanding that the concept of record
was to be changed, not that there be some publicly visible
syntactic sugar for read/write access to private components.

If the suggested "record interface" allows programmers to write
a subprogram that defines what R.A means, then the analog
*change* for task types will be "type T is interface task ...".
It will allow programmers to specify what "accessing"
The_T.A means, i.e. they not only write an acceptor A, but they
will also be writing what "accept" means. Only be default
will "accept" fall back to the LRM thing. :-)

Now the argument was that in a sense I can write "callable
components" of packages, of protected objects, of tasks, but
not of simple composite types. If this distinction seems
unwarranted, it is perhaps interesting to compare with
Eiffel counterparts. ECMA Eiffel defines Dmitry's suggestion
AFAICS. (I'll leave out the complication introduced by expanded
objects.) Access to a record component in Eiffel is either a
function or looks like a function, depending on how it is
defined. A client writing a record component in Eiffel will
always call a procedure of the record class, even when it
is written like assignment (":="), because the only way to modify
an object from the outside is to call a procedure. The function
will have an assigner command associated with it,

class FOO inherit FLOAT
feature
   get: INTEGER assign put is ...
   put (Value: INTEGER) is ...

Suppose Ada was to give up simple record component read/write
in favor of programmer defined subprograms implementing record
interfaces. There are cases when the translated code will have
to move memory words from here to their (as per LRM and reps.)
When this is to be done for an Eiffel record, then reportedly,
it always is tricky. Either the Eiffel literature 
suggest that the compiler has built in magic, or you revert
to the programmer's knowledge of how the Eiffel code is
translated to C and have him use this C knowledge to achieve the
desired effect (assignment) at the C level.



> Shouldn't it be possible
> to create a complete abstraction that works like the built-in ones?

Yes and No. I had (mis)understood that the built-in "abstractions"
like "record" should only default to built-in mechanics. The more basic
new "record interface" mechanism would in fact be less basic, because
programmers can write a subprogram for what .Integer_Component := 5;
will mean. If this were the only mechanism, wouldn't we soon be
entering an infinite loop of a missing basic assignment? For what
is the reason that I cannot make Integer assignment be an interface
;-) ;-)


> After all, it's not about the syntax:
> 
>    X := Y;
> 
> looks simple, but I've had to debug as much as 1K of machine code that
> actually implements it. There can be a lot of complexity hidden behind the
> two characters ":=". There is no reason to think that it would be a problem
> if '.' or '(' or '"' had similar complexity. (Indeed, there are cases where
> they do, you just can't write such cases yourself.)

Exactly, and I was trying to suggest that it might or might not
be a good idea to have the programmers write such cases, as they
will have to manage the complexity of assignment in a way that
is likely more complex than understanding ":=".
  But then, I think Dmitry is basically suggesting different
syntax, not a new record mechanism; after all, with tagged
records and Controlled components, the call side syntax is almost
part of Ada.