Copy vector in Ada

Copy vector in Ada

[katolsster]

Hello, 
I'm trying to figure out the best way to copy a vector into another vector (Ada.Containers.Vectors). Is copying element by element the only way? My vectors are tiny (in the order of max 5 elements). 

Re: Copy vector in Ada

[Jeffrey Carter]

On 10/31/2012 09:26 AM, katolsster wrote:
 >
 > I'm trying to figure out the best way to copy a vector into another vector
 > (Ada.Containers.Vectors). Is copying element by element the only way? My
 > vectors are tiny (in the order of max 5 elements).

What wrong with assignment (":=")?

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: Copy vector in Ada

[katarina.l.olsson]

 What wrong with assignment (":=")? 

Well it's the method I currently use, just thinking whether or not there may be additional problems with references. 

I think the Vector record implementation in itself is a reference type, but maybe it will never cause any problems due to the implementation of the Adjust procedure?

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Fri, 02 Nov 2012 12:10:12 +0100, <katarina.l.olsson@gmail.com> a écrit:

>  What wrong with assignment (":=")?
>
> Well it's the method I currently use, just thinking whether or not there  
> may be additional problems with references.
>
> I think the Vector record implementation in itself is a reference type,  
> but maybe it will never cause any problems due to the implementation of  
> the Adjust procedure?

Ada is not C/C++, if the assignment operator is available in a type  
interface, that means it is safe to use. When the assignment operator  
would not be safe to use and/or would cost too much to the implementation  
to be made available safely, then Ada has well know way to exclude it from  
the interface: “limited type”.

So, yes, if “:=” is available in the interface, that means it's not a hack  
to use it.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Maciej Sobczak]

W dniu piątek, 2 listopada 2012 12:20:04 UTC+1 użytkownik Hibou57 (Yannick Duchêne) napisał:

> Ada is not C/C++, if the assignment operator is available in a type  
> interface, that means it is safe to use.

I'm not sure what you mean by this. The rules and their implications are pretty similar in Ada and in C++.
In other words, if you have an example of unsafe C++ code (that is, unsafe in relation to the assignment operator), I think there should be an equivalent example in Ada as well.

> When the assignment operator  
> would not be safe to use and/or would cost too much to the implementation  
> to be made available safely, then Ada has well know way to exclude it from  
> the interface: “limited type”.

Similarly in C++ - if the assignment operator is too costly (or just impossible) to implement, there is a way to ban it.

> So, yes, if “:=” is available in the interface, that means it's not a hack  
> to use it.

Unless the author of the type forgot to implement it properly?

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Fri, 02 Nov 2012 23:03:05 +0100, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
>> When the assignment operator
>> would not be safe to use and/or would cost too much to the  
>> implementation
>> to be made available safely, then Ada has well know way to exclude it  
>> from
>> the interface: “limited type”.
>
> Similarly in C++ - if the assignment operator is too costly (or just  
> impossible) to implement, there is a way to ban it.

Really? That's a hot news to me. At least at the time I used it (~ 2000),  
there was nothing like that, while Ada already had limited types since  
long. And I'm not even sure there was a way to redefine the copy operation  
(may be this came in a later C++ definition release, or else I forgot) or  
anything like adjustments.

>> So, yes, if “:=” is available in the interface, that means it's not a  
>> hack
>> to use it.
>
> Unless the author of the type forgot to implement it properly?
Not in a standard Ada package. The post is about the standard containers,  
there is not fears to have.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Zhu, Qun-Ying]

Yannick Duchêne (Hibou57) wrote:
> Le Fri, 02 Nov 2012 23:03:05 +0100, Maciej Sobczak
> <see.my.homepage@gmail.com> a écrit:
>>> When the assignment operator
>>> would not be safe to use and/or would cost too much to the
>>> implementation
>>> to be made available safely, then Ada has well know way to exclude it
>>> from
>>> the interface: “limited type”.
>>
>> Similarly in C++ - if the assignment operator is too costly (or just
>> impossible) to implement, there is a way to ban it.
>
> Really? That's a hot news to me. At least at the time I used it (~
> 2000), there was nothing like that, while Ada already had limited types
> since long. And I'm not even sure there was a way to redefine the copy
> operation (may be this came in a later C++ definition release, or else I
> forgot) or anything like adjustments.
>

I think it is a C++11 feature.
[1] http://www.stroustrup.com/C++11FAQ.html#default
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
[3] http://gcc.gnu.org/projects/cxx0x.html (seems have the feature since 
GCC 4.4)

Re: Copy vector in Ada

[Peter C. Chapin]

On 11/02/2012 08:15 PM, Zhu, Qun-Ying wrote:

 > I think it is a C++11 feature.

You can disable copying in a class in C++ 1998 by declaring the copy 
constructor and operator=() as private. You don't need to provide an 
implementation. The annoying thing about that is you could still try to 
use them inside the class's methods and you don't get an error about 
that until link-time. C++ 2011 has a cleaner way of doing it.

Peter

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Sat, 03 Nov 2012 04:47:56 +0100, Peter C. Chapin <pcc482719@gmail.com>  
a écrit:

> On 11/02/2012 08:15 PM, Zhu, Qun-Ying wrote:
>
>  > I think it is a C++11 feature.
>
> You can disable copying in a class in C++ 1998 by declaring the copy  
> constructor and operator=() as private.
As you tell it, yes, I feel to remember there was indeed a copy  
constructor (remembering about this past time, also make me remember of a  
funny bad surprise I had in that time with a class instance passed to  
function and returned truncated, silly… but that's another story).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Maciej Sobczak]

W dniu sobota, 3 listopada 2012 00:45:55 UTC+1 użytkownik Hibou57 (Yannick Duchêne) napisał:

> > Similarly in C++ - if the assignment operator is too costly (or just  
> > impossible) to implement, there is a way to ban it.
> 
> Really? That's a hot news to me. At least at the time I used it (~ 2000),  
> there was nothing like that,

Then you should prepare for an even hotter news: it was "there" always.

> And I'm not even sure there was a way to redefine the copy operation

It was "there" always. The ability to redefine copy operation is a fundamental part of data abstraction. You would not even be able to implement such basic things like a string class without this functionality.
  
I would even say that C++ has a more elegant solution for this problem, as the ability to redefine the assignment operation is orthogonal to other parts of the language and does not interfere with things like polymorphism. Also, banning and redefining are handled in the consistent way (hey, they *are* related issues!), while in Ada these two are done in completely distinct ways - one requires a keyword, while the other requires a derivation from some magic type. Yuck.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Sat, 03 Nov 2012 15:34:17 +0100, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:
> I would even say that C++ has a more elegant solution for this problem,  
> as the ability to redefine the assignment operation is orthogonal to  
> other parts of the language and does not interfere with things like  
> polymorphism. Also, banning and redefining are handled in the consistent  
> way (hey, they *are* related issues!), while in Ada these two are done  
> in completely distinct ways - one requires a keyword, while the other  
> requires a derivation from some magic type. Yuck.
I will trust you for the assertion about C++, as I forget too much since  
that time, but your words invite me to notice the orthogonality you  
mention, is in the big part, more in Ada than C++. Think of separation of  
hiding and attaching methods to a tagged type. That may be true for a that  
particular point, but not for the whole (just wanted to remind a detail  
cannot shadow the whole). Will investigate that point later any way, as  
I've never felt any lack of orthogonality with Ada here; I will try to  
better understand what you meant.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Sat, 03 Nov 2012 16:54:20 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> I will trust you for the assertion about C++, as I forget too much since  
> that time

Some other words: I hardly believe an assignment operator could ever be OK  
within a context where the meaning of what an object is depends on whether  
it is used by value or reference (the truncation case Peter made me  
recall), and where there's nothing like proper class wide type, as C++  
class wide behaviour also depends on whether an instance is used by value  
vs by reference (always class wide with reference). Can you make an  
assignment operator works fine and uniformly in such circumstances? The  
orthogonality C++ lacks here is a fact to be added to the particular point  
you raised.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Maciej Sobczak]

W dniu sobota, 3 listopada 2012 17:03:33 UTC+1 użytkownik Hibou57 (Yannick Duchêne) napisał:

> Some other words: I hardly believe an assignment operator could ever be OK  
> within a context where the meaning of what an object is depends on whether  
> it is used by value or reference (the truncation case Peter made me  
> recall), and where there's nothing like proper class wide type, as C++  
> class wide behaviour also depends on whether an instance is used by value  
> vs by reference (always class wide with reference). Can you make an  
> assignment operator works fine and uniformly in such circumstances?

No and I don't even intend to do it. Mixing assignment with polymorphism is evil and cannot be implemented reasonably anyway. In the case of derivation hierarchy I would rather introduce the "clone" operation or something equivalent. Interestingly, in the hierarchy I would also ban the copying entirely, which means that pass by copy becomes impossible and the whole problem of uniformity just disappears.

Note that Ada does not provide any universal solution to this problem, either - assignment cannot be reasonably implemented apart from the case of matching tags, which introduces a run-time aspect to the whole; this is in contrast to banning assignment, which in terms of limitedness is always resolved statically.
It's a bit messy.

> The
> orthogonality C++ lacks here is a fact to be added to the particular point  
> you raised.

Not much. In the case of derivation hierarchy, neither Ada nor C++ offer anything useful (and that's OK as the concept is broken anyway). C++ does provide a cleaner solution for the case of non-dispatching assignment.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Sat, 3 Nov 2012 14:57:28 -0700 (PDT), Maciej Sobczak wrote:

> No and I don't even intend to do it. Mixing assignment with polymorphism
> is evil and cannot be implemented reasonably anyway.

How so? Assignment is clearly a polymorphic operation.

> Note that Ada does not provide any universal solution to this problem,

Because it is a larger problem, which neither Ada nor C++ have a solution
for, multiple dispatch.

> either - assignment cannot be reasonably implemented apart from the case
> of matching tags,

You mean an implementation generated by the compiler? In such cases the
programmer must be required to override.

> Not much. In the case of derivation hierarchy, neither Ada nor C++ offer
> anything usefu

Yes

>l (and that's OK as the concept is broken anyway).

Concept of what? In C++ you can assign int to double. In Ada you can assign
Positive to Integer. Is this broken? You do want to assign semantically
same values of different types. That depends on the motivation why these
types were designed different. It is not always so, that they were in order
not to have assignments.

> C++ does
> provide a cleaner solution for the case of non-dispatching assignment.

I would not call it cleaner, but usable at least.

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

Re: Copy vector in Ada

[Maciej Sobczak]

W dniu niedziela, 4 listopada 2012 08:25:11 UTC+1 użytkownik Dmitry A. Kazakov napisał:

> > No and I don't even intend to do it. Mixing assignment with polymorphism
> > is evil and cannot be implemented reasonably anyway.
> 
> How so? Assignment is clearly a polymorphic operation.

It is not "clearly" to me. Assigning Rectangles to Triangles does not make any sense.

> > either - assignment cannot be reasonably implemented apart from the case
> > of matching tags,
> 
> You mean an implementation generated by the compiler? In such cases the
> programmer must be required to override.

I also mean what the programmer might possibly provide - Rectanges vs. Triangles and so on.

> > (and that's OK as the concept is broken anyway).
> 
> Concept of what? In C++ you can assign int to double.

No, you cannot. You can assign double to double and there is an implicit conversion from int to double. Both are also numbers with quite straightforward interpretation so these tricks are meaningful. This is nowhere similar to Rectangles vs. Triangles and stuff.

> In Ada you can assign
> Positive to Integer.

It is the same type.

> Is this broken?

Rectangles vs. Triangles is broken.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Sun, 4 Nov 2012 12:49:13 -0800 (PST), Maciej Sobczak wrote:

> W dniu niedziela, 4 listopada 2012 08:25:11 UTC+1 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>>> No and I don't even intend to do it. Mixing assignment with polymorphism
>>> is evil and cannot be implemented reasonably anyway.
>> 
>> How so? Assignment is clearly a polymorphic operation.
> 
> It is not "clearly" to me. Assigning Rectangles to Triangles does not make any sense.

Does the example presume that both are in the same hierarchy of types, e.g.
"shape"? Whether assignment makes sense depends on that.
 
>>> either - assignment cannot be reasonably implemented apart from the case
>>> of matching tags,
>> 
>> You mean an implementation generated by the compiler? In such cases the
>> programmer must be required to override.
> 
> I also mean what the programmer might possibly provide - Rectanges vs. Triangles and so on.

He will replace a triangular shape with a rectangular one.

>>> (and that's OK as the concept is broken anyway).
>> 
>> Concept of what? In C++ you can assign int to double.
> 
> No, you cannot. You can assign double to double and there is an implicit
> conversion from int to double.

This is an implementation detail.

> Both are also numbers with quite
> straightforward interpretation so these tricks are meaningful. This is
> nowhere similar to Rectangles vs. Triangles and stuff.

Both are straightforward geometric shapes. It is not the language business
to judge about the problem space.

>> In Ada you can assign Positive to Integer.
> 
> It is the same type.

They are NOT *semantically* same:

   X : Positive := -1;
   Y : Integer := -1;

>> Is this broken?
> 
> Rectangles vs. Triangles is broken.

What is broken? You make some assumptions about the semantics of
assignment, which may or may not hold. Again, it is not the language
business. [*] It is all up to programmer to decide if he wanted assignment
defined on {Rectangle, Triangle}**2. Depending on that, he will chose an
appropriate mapping of the desired semantics onto the language types. In
this order.

--------------------
* FSA, type systems etc are far too weak to capture complex structures like
real numbers or geometric shapes. This is why the programmer always knows
better. There cannot be a universal computer model of either.

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

Re: Copy vector in Ada

[Maciej Sobczak]

W dniu poniedziałek, 5 listopada 2012 09:31:13 UTC+1 użytkownik Dmitry A. Kazakov napisał:

> > It is not "clearly" to me. Assigning Rectangles to Triangles does not make any sense.
> 
> Does the example presume that both are in the same hierarchy of types, e.g.
> "shape"? Whether assignment makes sense depends on that.

You can always imagine arbitrary meanings of "assignment" and implement it, like:

D : Date;

D := "tomorrow";

But we are diverting from the subject of whether limitedness and assignment are supported consistently and orthogonally to other language features.

> > I also mean what the programmer might possibly provide - Rectanges vs. Triangles and so on.
> 
> He will replace a triangular shape with a rectangular one.

Wrong. The existing alias of Trangle'Class will break.

> You make some assumptions about the semantics of
> assignment, which may or may not hold. Again, it is not the language
> business.

Yes. Let's agree that the language should allow this possibility.
We are still diverting from the subject of whether the existing solution is elegant and orthogonal with respect to other language features.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Mon, 5 Nov 2012 00:50:25 -0800 (PST), Maciej Sobczak wrote:

> W dniu poniedzia�ek, 5 listopada 2012 09:31:13 UTC+1 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>>> It is not "clearly" to me. Assigning Rectangles to Triangles does not make any sense.
>> 
>> Does the example presume that both are in the same hierarchy of types, e.g.
>> "shape"? Whether assignment makes sense depends on that.
> 
> You can always imagine arbitrary meanings of "assignment" and implement it, like:
> 
> D : Date;
> 
> D := "tomorrow";
> 
> But we are diverting from the subject of whether limitedness and
> assignment are supported consistently and orthogonally to other language
> features.

Then it was you who tried. My point was that assignment, or better to say,
copy constructor (from which assignment is deduced), is a
doubly-dispatching "operation." It is not orthogonal and cannot be.

There are lots of further questions about special treatment of copy
constructors, like whether one could introduce them later, e,g, promoting
limited types to non-limited and demoting back. These should be considered
in the larger context of disallowing operations, subtracting interfaces
etc. But the starting position is independent on that.

>>> I also mean what the programmer might possibly provide - Rectanges vs. Triangles and so on.
>> 
>> He will replace a triangular shape with a rectangular one.
> 
> Wrong. The existing alias of Trangle'Class will break.

What is alias?

As for "breaking" anything, that is technically speaking substitutability.
Substitutability is an issue if and only if, you inherit. Once the
programmer overrides or is forced to override there is no issue of
substitutability and there is no breaking. If you say that the programmer
could not implement the overridden operation without violation of some
semantic constraints that is another issue, not a language business, except
for checking static contracts. The programmer must then choose another type
hierarchy design, but that is outside the language scope.

>> You make some assumptions about the semantics of
>> assignment, which may or may not hold. Again, it is not the language
>> business.
> 
> Yes. Let's agree that the language should allow this possibility.
> We are still diverting from the subject of whether the existing solution
> is elegant and orthogonal with respect to other language features.

Neither elegant, nor orthogonal. Both languages did it wrong.

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

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Mon, 05 Nov 2012 10:20:44 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> There are lots of further questions about special treatment of copy
> constructors, like whether one could introduce them later, e,g, promoting
> limited types to non-limited
Would make sense, with a derived type adding capabilities (similar comment  
with unknown discriminant). The proof it would make sense is that in a  
package spec, you can change a limited to a non‑limited, without breaking  
anything.

> and demoting back.
Back from non‑limited to limited? This one is not cool.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Mon, 05 Nov 2012 18:22:45 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 05 Nov 2012 10:20:44 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
>> There are lots of further questions about special treatment of copy
>> constructors, like whether one could introduce them later, e,g, promoting
>> limited types to non-limited
> Would make sense, with a derived type adding capabilities (similar comment  
> with unknown discriminant). The proof it would make sense is that in a  
> package spec, you can change a limited to a non‑limited, without breaking  
> anything.
> 
>> and demoting back.
> Back from non‑limited to limited? This one is not cool.

But "constant T" is cool? Note that constant does just this and also
disallows any other mutators. It is not that simple. However you bend a
type you inevitably break something. So it actually depends on whether
substitutability violations could be detected statically. If yes,
everything is cool. Any dynamic checks are evil per definition, only
permissible if the alternative is worse.

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

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Mon, 05 Nov 2012 19:42:57 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Mon, 05 Nov 2012 18:22:45 +0100, Yannick Duchêne (Hibou57) wrote:
>
>> Le Mon, 05 Nov 2012 10:20:44 +0100, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>> There are lots of further questions about special treatment of copy
>>> constructors, like whether one could introduce them later, e,g,  
>>> promoting
>>> limited types to non-limited
>> Would make sense, with a derived type adding capabilities (similar  
>> comment
>> with unknown discriminant). The proof it would make sense is that in a
>> package spec, you can change a limited to a non‑limited, without  
>> breaking
>> anything.
>>
>>> and demoting back.
>> Back from non‑limited to limited? This one is not cool.
>
> But "constant T" is cool? Note that constant does just this and also
> disallows any other mutators.

A constant is just an easy‑and‑quick function, that's not the same as an  
object. The result returned by a function has a target object, but is not  
an object. At least, that's my personal model of a constant (is this model  
wrong?).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Mon, 05 Nov 2012 21:18:17 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 05 Nov 2012 19:42:57 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> On Mon, 05 Nov 2012 18:22:45 +0100, Yannick Duchêne (Hibou57) wrote:
>>
>>> Le Mon, 05 Nov 2012 10:20:44 +0100, Dmitry A. Kazakov
>>> <mailbox@dmitry-kazakov.de> a écrit:
>>>> There are lots of further questions about special treatment of copy
>>>> constructors, like whether one could introduce them later, e,g,  
>>>> promoting
>>>> limited types to non-limited
>>> Would make sense, with a derived type adding capabilities (similar  
>>> comment
>>> with unknown discriminant). The proof it would make sense is that in a
>>> package spec, you can change a limited to a non‑limited, without  
>>> breaking
>>> anything.
>>>
>>>> and demoting back.
>>> Back from non‑limited to limited? This one is not cool.
>>
>> But "constant T" is cool? Note that constant does just this and also
>> disallows any other mutators.
> 
> A constant is just an easy‑and‑quick function, that's not the same as an  
> object.

   procedure Foo (Object : in T);

here in T = constant T = immutable subtype of T = T - assignment - some
other operations.

> The result returned by a function has a target object, but is not  
> an object. At least, that's my personal model of a constant (is this model  
> wrong?).

What really matters is the type and the operations of the object, be it
run-time or compile-time one. Assignment is effectively disallowed on
immutable types and subtypes.

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

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Mon, 05 Nov 2012 21:33:54 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> A constant is just an easy‑and‑quick function, that's not the same as an
>> object.
>
>    procedure Foo (Object : in T);
>
> here in T = constant T = immutable subtype of T = T - assignment - some
> other operations.

That's a place‑specific restriction, the client knows. That can't apply to  
a derivation hierarchy. That's like a subtype, not a type as a member of a  
class (a subtype of Integer is not a member of a fictitious Integer class).

Interesting note anyway. Thanks for that.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Shark8]

On Monday, November 5, 2012 2:34:40 PM UTC-7, Hibou57 (Yannick Duchêne) wrote:
> 
> a derivation hierarchy. That's like a subtype, not a type as a member of a  
> class (a subtype of Integer is not a member of a fictitious Integer class).

But it is, isn't it?
Universal_Integer ⊃ Integer ⊃ Positive.
Therefore, Universal_Integer ⊃ Positive.

Universal integers are a fictitious class of integers and Positive is a subtype of Integer.

Re: Copy vector in Ada

[Hibou57 (Yannick Duchêne)]

Le mardi 6 novembre 2012 00:45:21 UTC+1, Shark8 a écrit :
> On Monday, November 5, 2012 2:34:40 PM UTC-7, Hibou57 (Yannick Duchêne) wrote: > > a derivation hierarchy. That's like a subtype, not a type as a member of a > class (a subtype of Integer is not a member of a fictitious Integer class). But it is, isn't it? Universal_Integer ⊃ Integer ⊃ Positive. Therefore, Universal_Integer ⊃ Positive. Universal integers are a fictitious class of integers and Positive is a subtype of Integer.

Well try, but I pretty sure it's a wrong interpretation. Inclusion relation in a type hierarchy, is precely the opposite way. A type defines a set of possible values or states, a class is a set, but not the same set. Positives indeed belongs to the set of values specified by an Integer, but a Positive does not belong to the set fictitious set of class whose root type would be Integer.

And no, universal integer does not define a class, but a set of values.

More on "Inclusion relation in a type hierarchy, is precely the opposite way": a derived type has to cover a base type, and will probably do more, but in anyway, not less.

Classes and values do not belongs to the same kind of sets.

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 06 Nov 2012 00:58:53 +0100, Hibou57 (Yannick Duchêne)  
<yannick_duchene@yahoo.fr> a écrit:

> Le mardi 6 novembre 2012 00:45:21 UTC+1, Shark8 a écrit :
>> On Monday, November 5, 2012 2:34:40 PM UTC-7, Hibou57 (Yannick Duchêne)  
>> wrote: > > a derivation hierarchy. That's like a subtype, not a type as  
>> a member of a > class (a subtype of Integer is not a member of a  
>> fictitious Integer class). But it is, isn't it? Universal_Integer ⊃  
>> Integer ⊃ Positive. Therefore, Universal_Integer ⊃ Positive. Universal  
>> integers are a fictitious class of integers and Positive is a subtype  
>> of Integer.
>
> Well try, but I pretty sure it's a wrong interpretation. Inclusion  
> relation in a type hierarchy, is precely the opposite way. A type  
> defines a set of possible values or states, a class is a set, but not  
> the same set. Positives indeed belongs to the set of values specified by  
> an Integer, but a Positive does not belong to the set fictitious set of  
> class whose root type would be Integer.
>
> And no, universal integer does not define a class, but a set of values.
>
> More on "Inclusion relation in a type hierarchy, is precely the opposite  
> way": a derived type has to cover a base type, and will probably do  
> more, but in anyway, not less.
>
> Classes and values do not belongs to the same kind of sets.


Back to tell more, and I hop, clearer.

First a summary, then later more details: there's a difference between  
reuse inheritance and interface inheritance; both must not be confused  
(unfortunately, it often is), then (as already said) there's a set of  
values and a set of types; here also, both must not be confused  
(unfortunately, due to the use of inheritance for reuse, this confusion  
often occurs too).

Personally, I see types only via their interface, so to me the proper  
inheritance is the interface inheritance. The following is not personal  
opinion: a type is defined by a set of value and a set of operations, with  
properties. A derived type must provide at least the same set of  
operations, and in the programming area, it must provide all, even the  
ones which could be derived from provided ones. Ex. even if the equality  
may be derived from some others primitives, if it was specified in a  
parent interface it will have to be provided (software design and math  
analysis differs a bit here, software design is a bit more strict, as it  
does not automatically derives things which could be). Then, with  
operations, comes two things: domains and codomains (also known as target  
domain). For each operation of a derived type, the domain must be a  
superset (at worst, an equal set) of the domain of the corresponding  
operation in the parent. Inversely, the codomain of an operation must be a  
subset (at worst an equal set). Hence, things cannot be described as set  
ownership, except for the set of operations, and the set of values is not  
enough for a caracterisation. You have: a set of values, a set of  
operations, operation's domain sets, and operation's codomain sets.

Now, when you create a “derived” type from Integer, you are restricting  
both the domain and the codomain, which makes it anything you would want,  
but not an interface derivation. That's OK with the codomain which become  
a subset, but the domain too becomes a subset (domain and codomain are  
covariant in this case), which is wrong for an interface derivation.

For a numeric type, say `My_Integer_Type`, to be really derived from  
`Integer`, as an example, the signature for the addition should be defined  
as:

     function "+" (Left, Right: Integer) return My_Integer_Type;

This is actually not the case, and you get instead:

     function "+" (Left, Right: My_Integer_Type) return My_Integer_Type;


Conclusion: `My_Integer_Type` does not belong to anything like an  
`Integer'Class` (which does not exist in Ada, and Ada is right with).


If there was an universal_integer class to which `Integer` would belong,  
then we should have something like:

     function "+" (Left, Right: universal_integer) return Integer;

which does not exist as‑is (except for intermediate results).


So, what's this, if not a proper type derivation (interface inheritance)?  
That's a reuse inheritance. Strictly speaking, reuse inheritance should  
never appears, that's a dangerous practice (from a design point of view),  
and composition should be used instead, defining a fully new root type and  
root class in the while.


Ada is right with its notion of subtype, like in:


    subtype My_Integer_Type is Integer range -10 .. 10;

But Ada is a bit wrong (personal opinion) with this:

    type My_Integer_Type is new Integer range -10 .. 10;

It would better be instead:

    subtype My_Integer_Type is new Integer range -10 .. 10;


When you do:

    type My_Integer_Type is new Integer range -10 .. 10;

you do this just to reuse the Integer type's physical representation and  
built‑in primitives, not to define a type belonging to an Integer class.

I said the inclusion relation you gave is the reverse of that of the class  
relation, here is why: if there is a proper type derivation, that's not  
Integer which derives from universal_integer, but the opposite,  
universal_integer which derives from Integer. You can check if you try to  
apply the rules of a valid type/interface derivation. The domain of  
operation of universal_integer is a superset of that of Integer, the  
codomain is not a subset, but equals the same codomain when the input  
belongs to the same domain, so that universal_integer could belong to a  
class defined by Integer; not the other way. Similarly, Integer belongs to  
the class of Positive or any subtype of Positive. With the numeric type  
hierarchy, the real type hierarchy is head down feet up: universal_integer  
inherits the interface of all Positive subtypes and all Integer subtypes.


All of this also explains why a subtype is not the same as a type  
derivation (and is even the opposite), and Ada is nice to provide this  
distinction (I know no other language with this, even SML don't have  
this). At least, the existence of a notion of subtype, makes things like  
constants, parameter modes and others, describable in the own terms of  
Ada, properly (Dmitry gave a good example).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Types vs Subtypes (was: Re: Copy vector in Ada)

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> All of this also explains why a subtype is not the same as a type
> derivation (and is even the opposite), and Ada is nice to provide this
> distinction (I know no other language with this, even SML don't have
> this). At least, the existence of a notion of subtype, makes things
> like constants, parameter modes and others, describable in the own
> terms of Ada, properly (Dmitry gave a good example).

I suppose it's because I trained as a physicist, not a mathematician,
but I find I can use Ada perfectly well without worrying about all these
arcane distinctions.

Re: Copy vector in Ada

[Georg Bauhaus]

On 06.11.12 03:17, Yannick Duchêne (Hibou57) wrote:
> When you do:
>
>     type My_Integer_Type is new Integer range -10 .. 10;
>
> you do this just to reuse the Integer type's physical representation and built‑in primitives, not to define a type belonging to an Integer class.

Actually, one can specify a physical representation of
My_Integer_Type that is different from Integer's. Also,
one may supplant or subtract "primitives".

When I do not need type substitution, e.g. because all
objects do their work well, and locally, then the solution is
to adapt notions of type to the solution at hand as necessary,
and if necessary at all, rather than to force working solutions
to match orthodox notions of type. Nothing wrong with the
latter, globally.

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 06 Nov 2012 12:33:32 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 06.11.12 03:17, Yannick Duchêne (Hibou57) wrote:
>> When you do:
>>
>>     type My_Integer_Type is new Integer range -10 .. 10;
>>
>> you do this just to reuse the Integer type's physical representation  
>> and built‑in primitives, not to define a type belonging to an Integer  
>> class.
>
> Actually, one can specify a physical representation of
> My_Integer_Type that is different from Integer's. Also,
> one may supplant or subtract "primitives".
>
> When I do not need type substitution, e.g. because all
> objects do their work well, and locally, then the solution is
> to adapt notions of type to the solution at hand as necessary,
> and if necessary at all, rather than to force working solutions
> to match orthodox notions of type. Nothing wrong with the
> latter, globally.

This has nothing to do with orthodoxy, that's proper naming of things.  
Confusing both kind of inheritance (and one is not even inheritance),  
leads to mixing things with no sense, and that's what I believe had lead  
to Python's duck‑typing (personal opinion here). As explained, both  
inheritance contradicts in near to everything. When both are mixed, the  
only things which seems to remains preserved, is operation's names, and  
here you get it: duck‑typing. OOP religion (at least a view of OOP)  
contributed to this misunderstanding, as it promoted inheritance as the  
Holy Grail good to everything, and it indeed promoted inheritance for  
reuse (which is wrong).

I did not want to say the numeric type hierarchy must not be used, just  
that it must not be confused with the interface hierarchy, as Shark8 did.

Now, talking about proper naming of things, how would you explain to a  
student, that sometime “type” must follow the substitution principle, and  
sometime, it do exactly the opposite? That's why I said it would have been  
better to have Ada requires to write “subtype XYZ is new” instead of “type  
XYZ is new”, in such cases.

> Actually, one can specify a physical representation of
> My_Integer_Type that is different from Integer's. Also,
> one may supplant or subtract "primitives".

Yes, it was to keep it simple. You are still reusing anyway (the primitive  
operations, automatically generated checks).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 06 Nov 2012 20:47:58 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> OOP religion (at least a view of OOP) contributed to this  
> misunderstanding, as it promoted inheritance as the Holy Grail good to  
> everything, and it indeed promoted inheritance for reuse (which is  
> wrong).

Wrong, except in the very few cases where this is practically unavoidable,  
as with the numeric types, and that can remains valid, as we don't have  
anything like numeric class wide type.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Georg Bauhaus]

On 06.11.12 20:47, Yannick Duchêne (Hibou57) wrote:
> Now, talking about proper naming of things, how would you explain to a
> student, that sometime “type” must follow the substitution principle, and
> sometime, it do exactly the opposite?

The challenge is to explain why the substitution principle is
a valid commandment: A valuable piece of formal theory, it may
not offer sufficient justification in the workplace.

Why? Because the workplace is governed by rules that language
theory/ideology/religion/principles will not normally cover.

A similar example will explain why principles like a theoretically
clean notion may turn out to be pointless, even a hindrance once
they are used outside the clean room:

Sometimes programs would modify themselves in a perfectly,
provably safe way, leading to sufficient performance in
terms of time and storage. And no matter what one might have
to say about their design, only by violating today's principles
could they achieve their stated goals. Today, it may not even
be possible to run such programs, because modifications are
detected, and the program is stopped. Principles have changed.

But are these self-modifying programs not "programs" anymore
because they were "improperly named `programs'"?

Similarly, I'll say that "inheritance" without further adjectives
is just insufficiently defined, and void of purpose (for the
workplace). And any single definition cannot name the "right"
inheritance.

So we have
 "Thou shalt follow the substitution principle!"
and
 "today's orthodoxy of language theory".

(Well, actually, the 1980s' theory, or even earlier.)

That said, I wish there was more software whose designers had
followed the substitution principle, and not reused hash tables
as parents, say. (Even when that's practical if you have the
source.)

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Wed, 07 Nov 2012 13:03:08 +0100, Georg Bauhaus wrote:

> On 06.11.12 20:47, Yannick Duchêne (Hibou57) wrote:
>> Now, talking about proper naming of things, how would you explain to a
>> student, that sometime “type” must follow the substitution principle, and
>> sometime, it do exactly the opposite?
> 
> The challenge is to explain why the substitution principle is
> a valid commandment:

It is not.

Positive is a legitime subtype of Integer even though violates the LSP.

The valid proposition is that you should not substitute something
non-substitutable, but you cannot enforce that through types. Correctness
cannot be ensured through type checks.

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

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Wed, 07 Nov 2012 14:09:47 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 07 Nov 2012 13:03:08 +0100, Georg Bauhaus wrote:
>
>> On 06.11.12 20:47, Yannick Duchêne (Hibou57) wrote:
>>> Now, talking about proper naming of things, how would you explain to a
>>> student, that sometime “type” must follow the substitution principle,  
>>> and
>>> sometime, it do exactly the opposite?
>>
>> The challenge is to explain why the substitution principle is
>> a valid commandment:
>
> It is not.
>
> Positive is a legitime subtype of Integer even though violates the LSP.

That's precisely what was said: both must not be confused.

> The valid proposition is that you should not substitute something
> non-substitutable, but you cannot enforce that through types. Correctness
> cannot be ensured through type checks.

Yes, but just like typing fails to ensure all of the correctness in the  
large (and in some very few cases, even fails to accept valid things).  
That's still the best balance we get between handy and safe.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Wed, 07 Nov 2012 13:03:08 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 06.11.12 20:47, Yannick Duchêne (Hibou57) wrote:
>> Now, talking about proper naming of things, how would you explain to a
>> student, that sometime “type” must follow the substitution principle,  
>> and
>> sometime, it do exactly the opposite?
>
> The challenge is to explain why the substitution principle is
> a valid commandment: A valuable piece of formal theory, it may
> not offer sufficient justification in the workplace.

It was never promoted as a commandment in my comments, but said it is not  
to be confused to something else, and to be followed when expected, and  
not followed when not applicable (like not using it in place of reuse,  
because this always gives the illusion of one thing and give another  
instead). This find as much justifications as predictability do.

> Why? Because the workplace is governed by rules that language
> theory/ideology/religion/principles will not normally cover.

No religion/ideology was spread, but some basic principle recalled.

> A similar example will explain why principles like a theoretically
> clean notion may turn out to be pointless, even a hindrance once
> they are used outside the clean room:
>
> Sometimes programs would modify themselves in a perfectly,
> provably safe way, leading to sufficient performance in
> terms of time and storage. And no matter what one might have
> to say about their design, only by violating today's principles
> could they achieve their stated goals. Today, it may not even
> be possible to run such programs, because modifications are
> detected, and the program is stopped. Principles have changed.

And that's precisely because we don't have proved things, we need guidance  
to prevent errors. Typing and other rules are kind of minimalist and  
default proofs of some properties. And this is there by the lack of better  
(there are other techniques, but so tedious and time consuming to apply,  
they would prevent many thing to be done, so these techniques are  
restricted to some area).

> But are these self-modifying programs not "programs" anymore
> because they were "improperly named `programs'"?

That's unfair, you are drifting too much based on a single definition I  
maid. By the way, I would call these ”programs“, so you did not properly  
guess.

> Similarly, I'll say that "inheritance" without further adjectives
> is just insufficiently defined, and void of purpose (for the
> workplace). And any single definition cannot name the "right"
> inheritance.
>
> So we have
>  "Thou shalt follow the substitution principle!"
> and
>  "today's orthodoxy of language theory".
>
> (Well, actually, the 1980s' theory, or even earlier.)

You should know some old things are still valid today ;)

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Georg Bauhaus]

On 07.11.12 17:11, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 07 Nov 2012 13:03:08 +0100, Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de> a écrit:
> 
>> On 06.11.12 20:47, Yannick Duchêne (Hibou57) wrote:
>>> Now, talking about proper naming of things, how would you explain to a
>>> student, that sometime “type” must follow the substitution principle, and
>>> sometime, it do exactly the opposite?
>>
>> The challenge is to explain why the substitution principle is
>> a valid commandment: A valuable piece of formal theory, it may
>> not offer sufficient justification in the workplace.
> 
> It was never promoted as a commandment in my comments, but said it is not to
> be confused to something else, and to be followed when expected, and not
> followed when not applicable (like not using it in place of reuse, because
> this always gives the illusion of one thing and give another instead). This
> find as much justifications as predictability do.
> 
>> Why? Because the workplace is governed by rules that language
>> theory/ideology/religion/principles will not normally cover.
> 
> No religion/ideology was spread, but some basic principle recalled.


Well, a basic principle about derived types was stated,

 "a derived type has to cover a base type, and will probably
 do more, but in anyway, not less",

The commandment can be called a basic principle in the light of
the substitution principle, but not necessarily in the light of
correct algorithms at workplace. To show the absence of issues might
be more work. However, if this work makes your algorithm work within
specs, the basic principle is at odds with workplace requirements.

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Wed, 07 Nov 2012 19:06:11 +0100, Georg Bauhaus wrote:

> Well, a basic principle about derived types was stated,
> 
>  "a derived type has to cover a base type, and will probably
>  do more, but in anyway, not less",

which evidently does not hold in two major cases used in Ada:

1. specialization:

1.1 Ada's subtypes
1.2 Ada's in-mode arguments
1.3 Ada's constants
1.4 Ada's discriminated types
1.5 Ada's specific types as related to the class-wide counterparts, e.g. T
is a specialization of T'Class.

2. extension = Cartesian product, Ada's tagged types

> The commandment can be called a basic principle in the light of
> the substitution principle,

Generalization, the kind of type deviation you are talking about, does not
save LSP. In particular, it breaks in-operations. This is the reason why,
for example, extensible enumerations (which would be a generalization) pose
such a big problem.

It is important to remember that any non-trivial modification of a type
always breaks something. There is no rule expressed in terms of type values
which could ensure LSP. Bijection of domain sets the only mapping which
would unconditionally satisfy the requirement of weakening pre- and
strengthening post-conditions of all operations.

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

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Wed, 07 Nov 2012 21:04:27 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 07 Nov 2012 19:06:11 +0100, Georg Bauhaus wrote:
>
>> Well, a basic principle about derived types was stated,
>>
>>  "a derived type has to cover a base type, and will probably
>>  do more, but in anyway, not less",
>
> which evidently does not hold in two major cases used in Ada:

Seems every one agree with it.

> 1. specialization:
>
> 1.1 Ada's subtypes
> 1.2 Ada's in-mode arguments
> 1.3 Ada's constants
All are subtypes, not just the first alone.

> 1.4 Ada's discriminated types
Specifies possible subtypes. That's just user defined subtypes (unlike the  
aboves, which are Ada predefined).

> 1.5 Ada's specific types as related to the class-wide counterparts, e.g.  
> T is a specialization of T'Class.
Both belong to a different category, can't be compared. Why do you say “T  
is a specialization of T'Class”? Anything in T'Class is expected to be  
predictable to behave like T, so why is T a specialization compared to  
T'Class?

> 2. extension = Cartesian product, Ada's tagged types
I don't see, and on the contrary, feel extensions is even where it applies  
the best.

>> The commandment can be called a basic principle in the light of
>> the substitution principle,
>
> Generalization, the kind of type deviation you are talking about, does  
> not
> save LSP. In particular, it breaks in-operations. This is the reason why,
> for example, extensible enumerations (which would be a generalization)  
> pose
> such a big problem.
What do you call generalization here? Something which would be like giving  
an ancestor to a type which don't have one? (not sure to understand)

> It is important to remember that any non-trivial modification of a type
> always breaks something. There is no rule expressed in terms of type  
> values
> which could ensure LSP. Bijection of domain sets the only mapping which
> would unconditionally satisfy the requirement of weakening pre- and
> strengthening post-conditions of all operations.
Yes, that's why using pre/post requires to be careful, to not break  
anything or too much. Especially with preconditions, which may be the most  
easy to forget about, due to the disjunction.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Wed, 07 Nov 2012 22:00:14 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 07 Nov 2012 21:04:27 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> 1.5 Ada's specific types as related to the class-wide counterparts, e.g.  
>> T is a specialization of T'Class.
> Both belong to a different category, can't be compared. Why do you say “T  
> is a specialization of T'Class”? Anything in T'Class is expected to be  
> predictable to behave like T, so why is T a specialization compared to  
> T'Class?

Because:

1. T is substitutable (considered such by the compiler) for T'Class = T
inherits operations of T'Class (the class-wide operations) = T <: T'Class
(a subtype of T'Class).

2. Some values of T'Class have no corresponding values of T

3. All values of T have corresponding values of T'Class

2+3 = injection. 1+injection = specialization

>> 2. extension = Cartesian product, Ada's tagged types
> I don't see, and on the contrary, feel extensions is even where it applies  
> the best.
> 
>>> The commandment can be called a basic principle in the light of
>>> the substitution principle,
>>
>> Generalization, the kind of type deviation you are talking about, does not
>> save LSP. In particular, it breaks in-operations. This is the reason why,
>> for example, extensible enumerations (which would be a generalization)  
>> pose such a big problem.

> What do you call generalization here?

S is a generalization of T when S is considered substitutable (no type
errors) and there exists a reverse injective mapping : T->S

> Something which would be like giving  
> an ancestor to a type which don't have one? (not sure to understand)

That is supertyping. Sub-/supertyping relation of types S and T is
independent on the nature of mapping defined between values of S and T.
Specialization and generalization are forms of subtyping or supertyping.

>> It is important to remember that any non-trivial modification of a type
>> always breaks something. There is no rule expressed in terms of type  values
>> which could ensure LSP. Bijection of domain sets the only mapping which
>> would unconditionally satisfy the requirement of weakening pre- and
>> strengthening post-conditions of all operations.
> Yes, that's why using pre/post requires to be careful, to not break  
> anything or too much. Especially with preconditions, which may be the most  
> easy to forget about, due to the disjunction.

Precondition of any operation shall be statically true. As simple as that.
Dynamic preconditions make no sense. When precondition is static the case
shall be promoted to a distinct [sub]type. But this is another discussion.

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

Re: Copy vector in Ada

[Georg Bauhaus]

On 07.11.12 21:04, Dmitry A. Kazakov wrote:
> type deviation

Interesting notion!

Re: Copy vector in Ada

[Dmitry A. Kazakov]

On Thu, 08 Nov 2012 10:58:04 +0100, Georg Bauhaus wrote:

> On 07.11.12 21:04, Dmitry A. Kazakov wrote:
>> type deviation
> 
> Interesting notion!

"derived" and "inherited" are contaminated by language-specific meanings.

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

Re: Copy vector in Ada

[Yannick Duchêne (Hibou57)]

Le Mon, 05 Nov 2012 09:31:41 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> * FSA, type systems etc are far too weak to capture complex structures  
> like
> real numbers or geometric shapes. This is why the programmer always knows
> better. There cannot be a universal computer model of either.

Or even simple dimensional numbers, like speed, acceleration, density, …


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Copy vector in Ada

[Georg Bauhaus]

On 02.11.12 12:10, katarina.l.olsson@gmail.com wrote:
>  What wrong with assignment (":=")? 
> 
> Well it's the method I currently use, just thinking whether or not there may be additional problems with references. 

Assignment statements for containers have copy semantics. For example,
LRM A.18.2 says about vectors:

"                         Implementation Requirements

"254/2 The execution of an assignment_statement for a vector shall have
 the effect of copying the elements from the source vector object to
 the target vector object."

So, backed by the LRM, programmers need not worry about Adjust procedures,
if any.

Re: Copy vector in Ada

[Shark8]

On Friday, November 2, 2012 8:10:56 AM UTC-6, Georg Bauhaus wrote:
> 
> Assignment statements for containers have copy semantics. For example,
> 
> LRM A.18.2 says about vectors:
> "                         Implementation Requirements
> 
> 
> "254/2 The execution of an assignment_statement for a vector shall have
>  the effect of copying the elements from the source vector object to
>  the target vector object."
> 
> So, backed by the LRM, programmers need not worry about Adjust procedures,
> if any.

Dang, that is _nice_.
I'm glad we've got a lot of smart guys on the language-definition group.

Re: Copy vector in Ada

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:32001fef-4d96-455e-a706-3512500dda49@googlegroups.com...
> On Friday, November 2, 2012 8:10:56 AM UTC-6, Georg Bauhaus wrote:
>>
>> Assignment statements for containers have copy semantics. For example,
>>
>> LRM A.18.2 says about vectors:
>> "                         Implementation Requirements
>>
>>
>> "254/2 The execution of an assignment_statement for a vector shall have
>>  the effect of copying the elements from the source vector object to
>>  the target vector object."
>>
>> So, backed by the LRM, programmers need not worry about Adjust 
>> procedures,
>> if any.
>
> Dang, that is _nice_.
> I'm glad we've got a lot of smart guys on the language-definition group.

Thanks, I think. :-)

Of course, it is always possible for an implementer to screw this (or 
anything) up. But if they do, you at least have firm ground for a bug 
report.

                                  Randy.

Re: Copy vector in Ada

[Katarina Olsson]

Wow, thanks for all the answers and the interesting discussion. :-) 

I now feel convinced that it's safe to use the assignment operator for standard ada classes, unless there are pointer types inside the record (I reckon these have to be initialized to new objects if there is no possibility to avoid them). 

Re: Copy vector in Ada

[Katarina Olsson]

Edit; I mean, if I'm using non-standard ada objects with no implemented "="-operator.