A new notion: stronglly-typed-by-user language
in [ADA]
|
From: J-P. Rosen on 17 Apr 2010 07:40 Dmitry A. Kazakov a �crit : > On Sat, 17 Apr 2010 07:25:25 +0200, J-P. Rosen wrote: > >> Note that T'Base is the same type as T, so there is no issue here. > > But it is not all same. The behavior of T'Base may differ, so it might be > unsafe to use one as an equivalent of another in certain contexts > (substitutability violation). > T is a subtype (the first named subtype) of T'Base. This is not different from any issue of type vs. subtype. My point is that two objects are of the same type if they represent the same abstraction. This is true of T and T'Base. Almost any language behaves as if there were only one integer type (represented on various number of bits depending on the constraints). This is somehow the mathematical view. But since we are modelling real world object, it is better to adopt a physicist point of view: objects have dimensions, and it makes no sense to add apples and oranges. That's what I would call strong typing. -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Dmitry A. Kazakov on 17 Apr 2010 10:09 On Sat, 17 Apr 2010 13:40:23 +0200, J-P. Rosen wrote: > My point is that two objects are of the same type if they represent the > same abstraction. This is true of T and T'Base. No, this is certainly untrue. T'Base rather represents a quite arbitrary machine-dependent type chosen by the compiler. It may or may not fir the abstraction of T. Consider: type Angle is digits 5 range 0.0..360.0; X : Angle'Base := -10.0; Putting or lifting a constraint can break abstraction. > Almost any language > behaves as if there were only one integer type (represented on various > number of bits depending on the constraints). This is somehow the > mathematical view. But since we are modelling real world object, it is > better to adopt a physicist point of view: objects have dimensions, and > it makes no sense to add apples and oranges. That's what I would call > strong typing. I would call it mere typing. Strength of typing to me rather indicates how often you get a chance to add apples and orange. It is more frequent in C++ than in Ada. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Maciej Sobczak on 17 Apr 2010 10:33 On 17 Kwi, 07:25, "J-P. Rosen" <ro...(a)adalog.fr> wrote: > >http://www.msobczak.com/prog/typegen/ > > This shows that an educated Ada programmer, well aware of the issues of > strong typing, can mimmic the same behaviour in C++. But how many C++ > programmers use that? Not many, but that does not matter in this discussion - we are discussing the language, not programmers. > > I don't see how type promotion violates the strong type safety. > > Type promotion is based on the underlying representation, not on > abstract types. No. Type promotions in C++ are defined in terms of values, not in terms bit patterns. There is nothing that forces char and int to have similar underlying representation, yet promotion from char to int is well-defined. > And it is a form of automatic type case - which is > always a bad idea IMHO. There are many bad ideas in C++. I don't see how this one affects strong type safety. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: J-P. Rosen on 17 Apr 2010 14:57 Maciej Sobczak a �crit : > On 17 Kwi, 07:25, "J-P. Rosen" <ro...(a)adalog.fr> wrote: > >>> http://www.msobczak.com/prog/typegen/ >> This shows that an educated Ada programmer, well aware of the issues of >> strong typing, can mimmic the same behaviour in C++. But how many C++ >> programmers use that? > > Not many, but that does not matter in this discussion - we are > discussing the language, not programmers. Precisely. You showed you can add type safety to the language - which means that there is not built-in type safety. >>> I don't see how type promotion violates the strong type safety. >> Type promotion is based on the underlying representation, not on >> abstract types. > > No. Type promotions in C++ are defined in terms of values, not in > terms bit patterns. There is nothing that forces char and int to have > similar underlying representation, yet promotion from char to int is > well-defined. Here is what I had in mind. If you have: void p (short S); void p (long L); and you call p (I) where I is an int, it will resolve to the first one if short and int are the same, and to the second one if long and int are the same. This is logical in terms of machine types, but the idea that overloading resolution (and the associated promotion) depends on the implementation will make any Ada lawyer faint ;-) > >> And it is a form of automatic type case - which is cast - typo! >> always a bad idea IMHO. > > There are many bad ideas in C++. I don't see how this one affects > strong type safety. See above -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Maciej Sobczak on 17 Apr 2010 18:02
On 17 Kwi, 20:57, "J-P. Rosen" <ro...(a)adalog.fr> wrote: > Precisely. You showed you can add type safety to the language - which > means that there is not built-in type safety. No. I have shown that the language is capable of supporting user- defined integer types. There is nothing *added* to the language - everything is plain vanilla standard C++. That is, there was nothing missing in there. > Here is what I had in mind. If you have: > void p (short S); > void p (long L); > and you call p (I) where I is an int, it will resolve to the first one > if short and int are the same, and to the second one if long and int are > the same. This is logical No. Not only it is not logical - it will not even compile. First of all, type int is never subject to promotion. "Lower" types can be promoted to int if necessary and this is promotion. Apart from this, integer types can be converted between each other. Promotion has higher rank than conversion in overload resolution and this is basically the only place where the distinction between them is relevant. That is: void foo(char) {} void foo(int) {} short s = 42; foo(s); // this calls foo(int), // because promotion short->int is possible // and has a higher rank // than conversion short->char. Your example above cannot compile, because the actual parameter int cannot be promoted to long (int is never promoted, only "lower" types are) and its conversion to either short or long has equal rank - therefore the call is ambiguous. This has *nothing* to do with representation - these types are all different even if they have the same representation. > the idea that > overloading resolution (and the associated promotion) depends on the > implementation will make any Ada lawyer faint ;-) Overload resolution does *not* depend on implementation in C++, it is precisely defined with no relation to representation. > > There are many bad ideas in C++. I don't see how this one affects > > strong type safety. > > See above I still don't see how this or anything else that was mentioned since the beginning of this thread affects strong type safety. Especially when the presented arguments are incorrect. OK. I'm a C++ programmer and I know how to answer my question. I'm actually surprised that nobody came up with valid explanation of why C+ + sucks for so long, yet many people were ready to make fun of C++ as a language that obviously must suck. This shows that there is a significant bias component in your argumentation and that makes it (the argumentation) much less effective. In other words, you can use it to "preach to the choir", but you cannot use it to reach to an audience that might actually benefit from what you want to say. Just imagine - what would happen if there was a C++ programmer on your tutorial and you presented these arguments? ;-) ;-) ;-) Here is a valid argument that you can use: 1. C++ as a language has a *subset* that supports strong type safety in the sense that it is not possible to modify the value of any type by bypassing the interface of that type. If you stick to that language subset, you are safe. 2. C++ also has some features that allow to undermine the type safety by means of untyped or loosely typed *aliases*. In particular, pointer arithmetic (this includes all kinds of buffer overflows), conversions through void*, reinterpret_casts, unions and dangling pointers all allow to modify values of type T by means that are outside of T's interface and *that* is what makes the whole language unsafe and the sad reality is that these features are too frequently used - most likely because they are too easy to use. You can use point 1. if you want to convince someone that it is possible to build a reliable system in C++. There are people who believe in it and there are such systems. You can use point 2. to convince someone that C++ is not the best choice when support for reliability is required. The argument about untyped aliases is valid and widely acknowledged - even within the C++ community, and if anybody objects you can refer to any well known security vulnerability to make your point. This can create an opportunity to later highlight the advantages of Ada and perhaps recruit some new Ada converts. I hope that this will allow you to better address your audiences. Even if there is a C++ programmer listening. ;-) -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 |