From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Legit Warnings or not
Date: Wed, 27 Jul 2011 19:37:55 -0500
Date: 2011-07-27T19:37:55-05:00 [thread overview]
Message-ID: <j0qb16$rah$1@munin.nbi.dk> (raw)
In-Reply-To: 1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net...
> On Tue, 26 Jul 2011 16:25:03 -0500, Randy Brukardt wrote:
...
>> Why? Only the semantics of the objects should matter to the programmer;
>> the
>> rest of it should be left to the implementers.
>
> Yes, but 'Size, 'Address, 'Access, ":=" (deep vs. shallow), "=" (identity
> vs. equality) are parts of the semantics, which aren't invariant to the
> implementation.
'Address is obsolete junk that should never be used in new code (with the
possible exception of static address clauses). For both 'Size and 'Address,
they are meaningless in general unless the type is elementary or has a
representation clause requiring a continuous representation.
All of the other things are high-level concepts which work the same whether
or not the objects are contiguous. ":=" and "=" are defined in terms of the
subcomponents, 'Access provides an access to the object - the compiler has
to chose the same representation for all such (aliased) objects, but there
is no need for it to be contiguous.
>> Besides that, it is impossible to implement Ada with solely contiguous
>> objects -- the ability to pass slices means that array descriptors and
>> the
>> actual data have to be handled separately.
>
> To the programmer constraints are not a part of the object. E.g. it is OK
> to have discriminants and bounds allocated elsewhere or not allocated at
> all.
Maybe that's the way you think of these, but I'm sure it's not universal.
Discriminants, in particular, are defined by the language to be part of the
object. And in any case, you are saying that discontiguous representations
are fine so long as you think they are good idea. When did you get elected
to be in charge of programmers? :-)
>>> Expectations in an implementation of
>>> Ada.Finalization.Adjust?
>>
>> The semantics of the language doesn't care if objects are contiguous or
>> not.
>> This is all invisible to the programmer if done right.
>
> This presumes a definition of the semantics of "bitwise copy". What is to
> be copied before Adjust called? (The idea behind Adjust is broken anyway)
The phrase "bit-wise copy" does not appear in the Standard, and plays no
role in the formal definition of assignment and Adjust. ("bitwise" as you
spelled it doesn't appear in the Standard or AARM at all.) I assume you got
that from some informal description of how assignment works, but that's
irrelevant in terms of a description of the language.
Assignment of composite types is defined in terms of assigning all of the
(elementary) subcomponents of the type (and then calling Adjust as needed).
That does not require contiguous objects.
>>>> There also are rules supporting allocation/deallocation of objects that
>>>> have
>>>> multiple parts. So far as I know, those are the only rules needed to do
>>>> so.
>>>
>>> E.g. in a user-defined specific pool?
>>
>> Correct; the language allows multiple calls to Allocate for a single use
>> of
>> "new".
>
> Does it require this? How to enforce all parts to land into a pool? It can
> be crucial for certain implementations.
Require what? All of the parts of an designated object have to come from the
same pool (I don't know how else it could work), the pool associated with
the access type that the allocation is for -- that's the language
requirement for "new". But there is no requirement that it be exactly one
part.
>>> As a customer I see that the language separates definite and indefinite
>>> types. If this distinction is necessary, then the same logic applies to
>>> the
>>> implementation. I prefer transparent and simple implementations in order
>>> to
>>> know what to expect. In cases where I need referential semantics I
>>> prefer
>>> to implement it by myself, rather than to rely on the compiler.
>>
>> I don't think the distinction between definite and indefinite types IS
>> necessary; it just one of many expediencies in the Ada language designed
>> to
>> ease implementation. They don't always help, and there is little value to
>> forcing the same mistake on users.
>
> This is the core issue. I think it is important to have this distinction
> as
> well as contiguous objects in order to be able to use the language for
> low-level programming. I want Ada to remain a universal programming
> language.
If you want contiguous objects to do low-level programming, I think it is
reasonable to require you to declare that fact to the compiler. And a
compiler that never supported such objects would clearly be a problem. But
to require implementations to *never* use multiple parts for an object
because someone, somewhere, might use some types for low-level programming
is silly.
After all, you can't use an Ada.Container type for low-level programming.
Does that mean that Ada should not have container types?
> I also think that a fully by-reference Java-like type system would be
> necessarily inconsistent and incomplete.
I don't want or advocate requiring much of anything to be by-reference. But
I think that Ada compilers should be able to do the easy things (like
T'Class and discriminant-dependent arrays) for clients without burdening
them with the details.
> I prefer a simpler language with means to hide references behind primitive
> operations accessing fake components, fake array element etc. Moving the
> mess to the library level. E.g. it should be OK to declare
>
> type A is array (...) of S'Class;
>
> but not as an implementation, because there could be many of them. Instead
> of the compiler vendor choosing one for me, I prefer to make my own choice
> out of several library implementations, or be able to implement it myself.
Experience with containers shows that no one would use such things unless
they were part of the predefined libraries. (Hardly any containers got any
traction at all until Ada 2005 came along, even though they were plenty easy
to define in any version of Ada.) So hardly anyone would use such
abstractions.
Moreover, you cannot create a *better* implementation than the one
built-into the compiler (which doesn't have to have overhead to enforce
Ada's rules as any abstracted version would). You might be able to generate
one that works as well, but it would take heroic efforts in code generation
to do so. (Keep in mind that hardly any compilers optimize finalization,
even though it is possible and reasonably practical, mainly because of the
difficulty of allowing arbitrary user code in such optimizations. The same
would be true for your sorts of abstractions.)
In any case, what I want is more power and more flexibility from Ada
compilers (to do both contiguous and non-contiguous objects) to let the
compiler do more hard work, rather than the programmer. You seem to want the
programmer to work harder (and apparently never want anyone to use dynamic
array objects in Ada, since those have the sort of implicit-reference
semantics that you claim to hate). And it seems that further discussion is a
waste of time, since there is no reason for either of us to change our
opinions on this basic topic.
Randy.
next prev parent reply other threads:[~2011-07-28 0:37 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-20 22:30 Legit Warnings or not Anh Vo
2011-07-20 23:16 ` Robert A Duff
2011-07-21 18:43 ` Anh Vo
2011-07-23 0:26 ` Randy Brukardt
2011-07-23 14:26 ` Robert A Duff
2011-07-21 2:37 ` Jeffrey Carter
2011-07-21 9:50 ` Brian Drummond
2011-07-21 14:39 ` Dmitry A. Kazakov
2011-07-23 0:36 ` Randy Brukardt
2011-07-23 9:03 ` Dmitry A. Kazakov
2011-07-23 11:07 ` Simon Wright
2011-07-23 11:21 ` Dmitry A. Kazakov
2011-07-26 21:25 ` Randy Brukardt
2011-07-27 7:45 ` Dmitry A. Kazakov
2011-07-28 0:37 ` Randy Brukardt [this message]
2011-07-28 9:22 ` Dmitry A. Kazakov
2011-07-28 14:22 ` Robert A Duff
2011-07-28 14:41 ` Dmitry A. Kazakov
2011-07-28 15:10 ` Robert A Duff
2011-07-28 17:05 ` Dmitry A. Kazakov
2011-07-28 23:32 ` Randy Brukardt
2011-07-28 23:48 ` Randy Brukardt
2011-07-29 6:57 ` Simon Wright
2011-07-29 18:56 ` Jeffrey Carter
2011-07-30 0:13 ` Randy Brukardt
2011-07-29 7:41 ` Dmitry A. Kazakov
2011-07-30 0:17 ` Randy Brukardt
2011-07-30 8:27 ` Dmitry A. Kazakov
2011-08-01 22:12 ` Randy Brukardt
2011-08-02 10:01 ` Dmitry A. Kazakov
2011-08-02 21:30 ` Randy Brukardt
2011-08-03 9:01 ` Dmitry A. Kazakov
2011-08-03 20:35 ` Randy Brukardt
2011-08-04 8:11 ` Dmitry A. Kazakov
2011-08-05 23:57 ` Randy Brukardt
2011-08-06 8:23 ` Dmitry A. Kazakov
2011-08-08 21:30 ` Randy Brukardt
2011-07-23 14:32 ` Robert A Duff
2011-07-26 21:32 ` Randy Brukardt
2011-07-21 15:28 ` Adam Beneschan
2011-07-21 15:41 ` Robert A Duff
2011-07-21 20:12 ` Adam Beneschan
2011-07-23 0:31 ` Randy Brukardt
2011-07-21 17:40 ` Jeffrey Carter
2011-07-21 21:30 ` Brian Drummond
2011-07-21 21:54 ` Adam Beneschan
2011-07-22 10:16 ` Brian Drummond
2011-07-22 14:54 ` Adam Beneschan
2011-07-23 0:46 ` Randy Brukardt
2011-07-23 0:42 ` Randy Brukardt
2011-07-23 9:20 ` Niklas Holsti
2011-08-04 5:56 ` David Thompson
2011-07-23 9:24 ` Dmitry A. Kazakov
2011-07-23 12:36 ` Brian Drummond
2011-07-21 15:13 ` Robert A Duff
2011-07-23 0:52 ` Randy Brukardt
2011-07-23 14:48 ` Robert A Duff
2011-07-21 14:17 ` anon
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox