Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Copy vector in Ada
516 views
Skip to first unread message
katolsster
Oct 31, 2012, 12:26:04 PM10/31/12
to
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).
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).
Jeffrey Carter
Oct 31, 2012, 12:37:09 PM10/31/12
to
--
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33
katarina...@gmail.com
Nov 2, 2012, 7:10:12 AM11/2/12
to
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?
Yannick Duchêne (Hibou57)
Nov 2, 2012, 7:19:50 AM11/2/12
to
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
Georg Bauhaus
Nov 2, 2012, 10:10:31 AM11/2/12
to
On 02.11.12 12:10, katarina...@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,
> What wrong with assignment (":=")?
>
> Well it's the method I currently use, just thinking whether or not there may be additional problems with references.
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.
Shark8
Nov 2, 2012, 11:28:50 AM11/2/12
to
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_.
>
> 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.
I'm glad we've got a lot of smart guys on the language-definition group.
Maciej Sobczak
Nov 2, 2012, 6:03:05 PM11/2/12
to
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++.
> Ada is not C/C++, if the assignment operator is available in a type
> interface, that means it is safe to use.
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”.
> So, yes, if “:=” is available in the interface, that means it's not a hack
> to use it.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
Yannick Duchêne (Hibou57)
Nov 2, 2012, 7:45:50 PM11/2/12
to
Le Fri, 02 Nov 2012 23:03:05 +0100, Maciej Sobczak
<see.my....@gmail.com> a écrit:
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.
<see.my....@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),
>> 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.
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?
there is not fears to have.
Zhu, Qun-Ying
Nov 2, 2012, 8:15:25 PM11/2/12
to
Yannick Duchêne (Hibou57) wrote:
> Le Fri, 02 Nov 2012 23:03:05 +0100, Maciej Sobczak
> <see.my....@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.
> Le Fri, 02 Nov 2012 23:03:05 +0100, Maciej Sobczak
> <see.my....@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.
>
[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)
Peter C. Chapin
Nov 2, 2012, 11:47:56 PM11/2/12
to
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
> I think it is a C++11 feature.
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
Maciej Sobczak
Nov 3, 2012, 10:34:17 AM11/3/12
to
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.
> > 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,
> And I'm not even sure there was a way to redefine the copy operation
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.
Yannick Duchêne (Hibou57)
Nov 3, 2012, 11:47:46 AM11/3/12
to
Le Sat, 03 Nov 2012 04:47:56 +0100, Peter C. Chapin <pcc4...@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).
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.
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).
Yannick Duchêne (Hibou57)
Nov 3, 2012, 11:54:20 AM11/3/12
to
Le Sat, 03 Nov 2012 15:34:17 +0100, Maciej Sobczak
<see.my....@gmail.com> a écrit:
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.
<see.my....@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
> 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.
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.
Yannick Duchêne (Hibou57)
Nov 3, 2012, 12:03:28 PM11/3/12
to
Le Sat, 03 Nov 2012 16:54:20 +0100, Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:
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.
<yannick...@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
> that time
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.
Maciej Sobczak
Nov 3, 2012, 5:57:28 PM11/3/12
to
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.
> 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?
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.
Dmitry A. Kazakov
Nov 4, 2012, 2:25:10 AM11/4/12
to
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.
> No and I don't even intend to do it. Mixing assignment with polymorphism
> is evil and cannot be implemented reasonably anyway.
> Note that Ada does not provide any universal solution to this problem,
for, multiple dispatch.
> either - assignment cannot be reasonably implemented apart from the case
> of matching tags,
programmer must be required to override.
> Not much. In the case of derivation hierarchy, neither Ada nor C++ offer
> anything usefu
>l (and that's OK as the concept is broken anyway).
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.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Maciej Sobczak
Nov 4, 2012, 3:49:13 PM11/4/12
to mai...@dmitry-kazakov.de
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.
> > 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.
> > 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.
> > (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?
Rectangles vs. Triangles is broken.
Dmitry A. Kazakov
Nov 5, 2012, 3:31:41 AM11/5/12
to
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�:
"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.
> 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.
>>> 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.
"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.
>>> (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.
to judge about the problem space.
>> In Ada you can assign Positive to Integer.
>
> It is the same type.
X : Positive := -1;
Y : Integer := -1;
>> Is this broken?
>
> Rectangles vs. Triangles is broken.
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.
Maciej Sobczak
Nov 5, 2012, 3:50:25 AM11/5/12
to mai...@dmitry-kazakov.de
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:
> > 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.
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.
> You make some assumptions about the semantics of
> assignment, which may or may not hold. Again, it is not the language
> business.
We are still diverting from the subject of whether the existing solution is elegant and orthogonal with respect to other language features.
Dmitry A. Kazakov
Nov 5, 2012, 4:20:44 AM11/5/12
to
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�:
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.
> 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,
>>> 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.
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.
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.
Yannick Duchêne (Hibou57)
Nov 5, 2012, 11:30:45 AM11/5/12
to
Le Mon, 05 Nov 2012 09:31:41 +0100, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
<mai...@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, …
> like
> real numbers or geometric shapes. This is why the programmer always knows
> better. There cannot be a universal computer model of either.
Yannick Duchêne (Hibou57)
Nov 5, 2012, 12:22:45 PM11/5/12
to
Le Mon, 05 Nov 2012 10:20:44 +0100, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
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.
<mai...@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
> constructors, like whether one could introduce them later, e,g, promoting
> limited types to non-limited
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.
Dmitry A. Kazakov
Nov 5, 2012, 1:42:57 PM11/5/12
to
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
> <mai...@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
> Le Mon, 05 Nov 2012 10:20:44 +0100, Dmitry A. Kazakov
> <mai...@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.
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.
Yannick Duchêne (Hibou57)
Nov 5, 2012, 3:18:17 PM11/5/12
to
Le Mon, 05 Nov 2012 19:42:57 +0100, Dmitry A. Kazakov
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?).
<mai...@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
>> <mai...@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
> 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
>> <mai...@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.
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?).
Dmitry A. Kazakov
Nov 5, 2012, 3:33:54 PM11/5/12
to
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
> <mai...@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
>>> <mai...@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);
> Le Mon, 05 Nov 2012 19:42:57 +0100, Dmitry A. Kazakov
> <mai...@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
>>> <mai...@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.
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?).
run-time or compile-time one. Assignment is effectively disallowed on
immutable types and subtypes.
Yannick Duchêne (Hibou57)
Nov 5, 2012, 4:34:30 PM11/5/12
to
Le Mon, 05 Nov 2012 21:33:54 +0100, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
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.
<mai...@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
>> object.
>
> procedure Foo (Object : in T);
>
> here in T = constant T = immutable subtype of T = T - assignment - some
> other operations.
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.
Shark8
Nov 5, 2012, 6:45:21 PM11/5/12
to
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?
>
> 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).
Universal_Integer ⊃ Integer ⊃ Positive.
Therefore, Universal_Integer ⊃ Positive.
Universal integers are a fictitious class of integers and Positive is a subtype of Integer.
Hibou57 (Yannick Duchêne)
Nov 5, 2012, 6:58:53 PM11/5/12
to
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.
> 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.
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.
Yannick Duchêne (Hibou57)
Nov 5, 2012, 9:17:07 PM11/5/12
to
Le Tue, 06 Nov 2012 00:58:53 +0100, Hibou57 (Yannick Duchêne)
<yannick...@yahoo.fr> a écrit:
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).
<yannick...@yahoo.fr> a écrit:
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).
Simon Wright
Nov 6, 2012, 2:28:45 AM11/6/12
to
"Yannick Duchêne (Hibou57)" <yannick...@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,
> 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).
but I find I can use Ada perfectly well without worrying about all these
arcane distinctions.
Georg Bauhaus
Nov 6, 2012, 6:33:32 AM11/6/12
to
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
> 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.
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.
Yannick Duchêne (Hibou57)
Nov 6, 2012, 2:47:58 PM11/6/12
to
Le Tue, 06 Nov 2012 12:33:32 +0100, Georg Bauhaus
<rm.dash...@futureapps.de> a écrit:
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).
<rm.dash...@futureapps.de> a écrit:
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".
operations, automatically generated checks).
Yannick Duchêne (Hibou57)
Nov 6, 2012, 2:53:27 PM11/6/12
to
Le Tue, 06 Nov 2012 20:47:58 +0100, Yannick Duchêne (Hibou57)
<yannick...@yahoo.fr> a écrit:
as with the numeric types, and that can remains valid, as we don't have
anything like numeric class wide type.
<yannick...@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,
> misunderstanding, as it promoted inheritance as the Holy Grail good to
> everything, and it indeed promoted inheritance for reuse (which is
> wrong).
as with the numeric types, and that can remains valid, as we don't have
anything like numeric class wide type.
Georg Bauhaus
Nov 7, 2012, 7:03:08 AM11/7/12
to
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
> 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?
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.)
Dmitry A. Kazakov
Nov 7, 2012, 8:09:47 AM11/7/12
to
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.
> 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:
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.
Yannick Duchêne (Hibou57)
Nov 7, 2012, 11:11:08 AM11/7/12
to
Le Wed, 07 Nov 2012 13:03:08 +0100, Georg Bauhaus
<rm.dash...@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 ;)
<rm.dash...@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.
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.
> 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.
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'"?
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.)
Yannick Duchêne (Hibou57)
Nov 7, 2012, 11:17:51 AM11/7/12
to
Le Wed, 07 Nov 2012 14:09:47 +0100, Dmitry A. Kazakov
<mai...@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.
<mai...@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.
> 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.
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.
Georg Bauhaus
Nov 7, 2012, 1:06:11 PM11/7/12
to
On 07.11.12 17:11, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 07 Nov 2012 13:03:08 +0100, Georg Bauhaus
> <rm.dash...@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,
> Le Wed, 07 Nov 2012 13:03:08 +0100, Georg Bauhaus
> <rm.dash...@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 derived type has to cover a base type, and will probably
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.
Dmitry A. Kazakov
Nov 7, 2012, 3:04:27 PM11/7/12
to
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:
> 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",
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,
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.
Yannick Duchêne (Hibou57)
Nov 7, 2012, 4:00:14 PM11/7/12
to
Le Wed, 07 Nov 2012 21:04:27 +0100, Dmitry A. Kazakov
<mai...@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.
<mai...@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:
> 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
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.
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
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.
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.
anything or too much. Especially with preconditions, which may be the most
easy to forget about, due to the disjunction.
Dmitry A. Kazakov
Nov 8, 2012, 3:31:59 AM11/8/12
to
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
> <mai...@dmitry-kazakov.de> a écrit:
>
> Le Wed, 07 Nov 2012 21:04:27 +0100, Dmitry A. Kazakov
> <mai...@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:
>> 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?
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?
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)
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.
Dynamic preconditions make no sense. When precondition is static the case
shall be promoted to a distinct [sub]type. But this is another discussion.
Georg Bauhaus
Nov 8, 2012, 4:58:04 AM11/8/12
to
On 07.11.12 21:04, Dmitry A. Kazakov wrote:
> type deviation
Interesting notion!
> type deviation
Interesting notion!
Dmitry A. Kazakov
Nov 8, 2012, 9:28:13 AM11/8/12
to
Randy Brukardt
Nov 9, 2012, 1:22:24 AM11/9/12
to
"Shark8" <onewing...@gmail.com> wrote in message
news:32001fef-4d96-455e...@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.
news:32001fef-4d96-455e...@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.
Katarina Olsson
Nov 19, 2012, 5:37:48 PM11/19/12
to
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).
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).
Katarina Olsson
Nov 19, 2012, 5:39:51 PM11/19/12
to
Edit; I mean, if I'm using non-standard ada objects with no implemented "="-operator.
0 new messages