Re: API design problem - buffer scatter I/O

[Robert A Duff <bobduff@shell01.TheWorld.com>]

christoph.grein@eurocopter.com writes:

> May be the nomenclature in wiki is wrong or confusing (and you always
> have to be skeptical about the contents), but the incompatibilities
> described there exist. And I remember a discussion with Robert Dewar
> that Access_To_Address_Conversion does not work for access to
> unconstrained just because of the bounds (in GNAT, this is just an
> Unchecked_Conversion of the Address in either way).
>
> So, Bob, could you please elaborate about what is wrong in this
> description.

Well, the very first sentence starts talking about addresses,
which is a confusing approach, IMHO.

I have no objection to teaching people about implementation details
(like thin and fat pointers), but that should come at the end.
FIRST learn about the semantics of access types, which are
pretty much the same as "pointers" or "references" in many
other languages.  (Access types do not allow address arithmetic,
as C and C++ pointers do.  But there are many other languages
that are just like Ada in this regard.)

It says, "objects of this category do not really point to objects":
Of course they do.  "Designate" is the Ada jargon, but "point to" is
just fine as an informal term.  It then introduces its own jargon
"grant access", which is unhelpful.  There's no "granting" going
on here.

It says, "Thin pointers grant access to constrained subtypes."
No.  In all Ada compilers I know of except GNAT, thin pointers
are used in all cases -- there are no fat pointers.  In GNAT,
thin pointers are used for constrained subtypes, but also for
unconstrained scalars, unconstrained records, unconstrained tasks, and
so forth.  The ONLY case where fat pointers are used is for
unconstrained arrays -- and that's just the default (there is
an option to use thin pointers in that case as well).

It implies that constrained subtypes have a static size.
That's not correct -- many constrained subtypes have
dynamic size.

It makes statements about Address_To_Access_Converions that
are not necessarily true of Ada in general -- whether it's
safe depends entirely on the implementation.  And "thin safe,
fat unsafe" isn't quite right anyway -- thin pointers
don't always work with Address_To_Access_Converions, either.

It implies that fat pointers are somehow required for unconstrained
arrays.  It's not true -- as I said, this is just one implementation
approach.

> And I disagree that this should not be in wiki, ...

Sorry, I did not mean to imply it shouldn't be there.
I just don't think it should be used in the explanation
of access types semantics.  Later, there could be some
explanation of implementation strategies.  And it should
take care not to imply that any particular implementation strategy
is required by the language rules.

>... because programmers
> inevitable will fall into this trap (as I did) ...

Beginners have no business using Address_To_Access_Converions in the
first place.  This is an advanced, low-level, and dangerous feature.
Normal use of access types doesn't involve Address_To_Access_Converions
at all.

Warning people about the traps of Address_To_Access_Converions is a good
idea -- but it belongs in the section on Address_To_Access_Converions,
not in the section on access types.

>... and the corresponding
> RM pages are very difficult to grok.

Yes, I agree -- the RM is rather tough going!  I'm not trying to
denigrate the attempt to explain things in a more accessible way.

>...This is not an implementation
> detail.

Sure it is.  How a compiler represents data types (including access
types) is an implementation detail.  You don't need to know about it
until you need to use some low-level chap-13-ish features (and I include
interfacing to C in that category).

> I do not know what a thin and a fat and a far pointer actually are,
> I'm no Ada implementor. From my point of view as language user, a thin
> pointer is simply an address, a fat pointer an address and the bounds.

Almost right.  Change "bounds" to "address of bounds".

> So just the use of "thin" and "fat" is wrong, because it's an
> implementation detail?

It's not "wrong" to teach people about thin and fat pointers.
But it's unhelpful to introduce those concepts to beginners
up front.

- Bob