Talk:Comparison of type systems

message: Yes having all headings link to datatype might indeed be a better.
--Krischik T 07:23, 7 February 2006 (UTC)
thread_title:  Links to [[datatype]] 

message: Indeed I don't like the article. If you apply the rules strictly any truely Strongly-typed programming language would be useless for real live applications. This is similar to type safety where a truly type safety would be unable to implement it's own runtime system.
In type safety we eventually seperated theory from the actual languages.
:The term weak/strong typing is so vague that it should not be used in a nuanceless table such as this one. Wouter Lievens 09:08, 10 February 2006 (UTC)
thread_title:  [[Strongly-typed programming language|strong]] / [[Weak typing|weak]] 

message: I've changed the table entry for C to structural type equivalence. If it were nominative, the following code would produce a type error, which it doesn't:
 typedef int Int1;
 typedef int Int2;
 
 int main(void)
 {
   Int1 fred;
   Int2 joe;
 
   fred = 5;
   joe = fred;
   return 0;
 }
However, C does use nominative type equivalence for pointers (for instance, to allow dynamic linked lists to be defined). Tim Watson 10:59, 7 February 2006 (UTC)
replies: text: Thanks for the comments Krischik, your explanation of C typing is much clearer than mine. My point was that nominative compares names, i.e. types only match if their names match. Tim Watson 16:52, 7 February 2006 (UTC)

text: The real problem in your example is that assignment in C does not work on structs.  The two struct types are perfectly compatible (but not "the same"); it's the use of = that is erroneous.  "It doesn't compile" doesn't mean "it doesn't compile due to a type error".  --bmills 17:15, 7 February 2006 (UTC)
replies: text: That problem is easily solved with pointers, except that now it's a warning rather than an error.  See the code below.  Personally I have a problem with this whole "nominal vs. structural" dichotomy, because there are too many exceptions.  In reality each language has its own theory of type equivalence, some of them quite complex.  Cjoev 19:19, 7 February 2006 (UTC)

text: Assignment does work for structs in C and has worked since the first standard. Fix the thinkos in the first example (struct foo {...}, not struct {...} foo), and make the two variables be of the same type, and it compiles without warnings and errors in GCC.  AJK 11:08, 8 February 2006 (UTC)
thread_title:  C is (almost) structurally typed 

message: Actually you are mistaken about the function of typedef. typedef does not actualy define a new type - it only defines a new name to a type. It should realy be called typealias or typename.
The only keywords in C that does create new types are struct and union and to a lesser dregree enum.
So your example should be:
 struct {int data} Int1;
 struct {int data} Int2;
 
 int main()
 {
 struct Int1 fred;
 struct Int2 joe;
 
 fred.data = 5;
 joe = fred;
 return 0;
 }
struct Int1 and struct Int2  are structualy identical and sill the example won't compile. So back to nominative.
Of corse it's not all black and while. C function - and with that function pointers - are structualy typed as it is enough when the parameters types match. The names do not need to match (nominative - by name). This also show when you use different parameter names in the header then in the body file. 
If you want to know how a real type system looks like click here.
--Krischik T 12:27, 7 February 2006 (UTC)
replies: text: Thanks for the comments Krischik, your explanation of C typing is much clearer than mine. My point was that nominative compares names, i.e. types only match if their names match. Tim Watson 16:52, 7 February 2006 (UTC)

text: The real problem in your example is that assignment in C does not work on structs.  The two struct types are perfectly compatible (but not "the same"); it's the use of = that is erroneous.  "It doesn't compile" doesn't mean "it doesn't compile due to a type error".  --bmills 17:15, 7 February 2006 (UTC)
replies: text: That problem is easily solved with pointers, except that now it's a warning rather than an error.  See the code below.  Personally I have a problem with this whole "nominal vs. structural" dichotomy, because there are too many exceptions.  In reality each language has its own theory of type equivalence, some of them quite complex.  Cjoev 19:19, 7 February 2006 (UTC)

text: Assignment does work for structs in C and has worked since the first standard. Fix the thinkos in the first example (struct foo {...}, not struct {...} foo), and make the two variables be of the same type, and it compiles without warnings and errors in GCC.  AJK 11:08, 8 February 2006 (UTC)
thread_title:  typedef does not do what the name suggests 

message: Right. I did too much C++ and Ada work - so I forgot that C can't assign structs. The differences between C and C++ are larger then I remember.
But if assignment does not work on structs then you have to use memcpy - and memcpy is structural - it only cares about the amount of bytes copied not the content and certanly not about the name of any type. Or you copy the elementes seperatly joe.data = fred.data - but that too does not take the type names into account.
Pointers, int and real are also readily converted - I stand corrected and change the entry back again.
--Krischik T 07:17, 8 February 2006 (UTC)
replies: text: Assignment does work for structs in C and has worked since the first standard. Fix the thinkos in the first example (struct foo {...}, not struct {...} foo), and make the two variables be of the same type, and it compiles without warnings and errors in GCC.  AJK 11:08, 8 February 2006 (UTC)
thread_title:  assignment in C does not work on structs 

message: Just a few questions:
* Is assembly really untyped?
* Are BYTE, WORD, DWORD, QWORD not to be considered types as such?
* How about floating-point types in modern CPUs?
* Or the LODS, STOS, and MOVS operations of the x86 - would they not suggest the existence of a "C - style string type"?
* Of course assembly only cares about types as part of an operation - it does not track what type of data is stores at what address. Is there a better word then "none" to describe that behaviour?
Just questions - I am not saying we should change anything yet.
--Krischik T 08:47, 10 February 2006 (UTC)
replies: text: No, I don't have a reference for the typedness of assemblers. I'm going from the idea that static typing rejects offending programs at compile time by giving expressions and variables a static type, and dynamic typing rejects them at runtime by associating a type tag with each value. Assemblers do neither and never reject programs. As for your questions, one could think that each operation does an unsafe typecast of operands to get a meaningful interpretation of the bits. As I see it, variables and their types etc. are still just in the mind of the programmer. --TuukkaH 09:43, 10 February 2006 (UTC)
thread_title:  assembly untyped? 

message: Isn't PHP weakly typed ? --Yukoba 06:47, 22 April 2006 (UTC)
thread_title:  PHP 

message: Looking at template parameter passing and m:ParserFunctions#switch, it should be possible to make each row into a simple template call. Thus we would have 

instead of the current
|- 
| Ada
| style="background:azure;"    | static
| style="background:azure;"    | strong
| style="background:honeydew;" | safe
| style="background:azure;"    | nominative
The template would ensure that diffs show all of the language entry and that colours are right. --TuukkaH 11:51, 2 May 2006 (UTC)
thread_title:  Make each row a template? 

message: At least as strong as Smalltalk.  —Preceding unsigned comment added by 89.173.3.51 (talk) 14:34, 14 February 2011 (UTC)
thread_title:  Objective-C is strongly typed 

message: Well back after a while and again something th moan. Well just for good measuere and to be shure I tried a little test programm:
 #include <iostream>
 
 int
 main ()
    {
    unsigned i = -1;
 
    std::cout << i;
 
    return i;
    }
compile and test:
 >g++ test.cpp -o test
 /tmp  Linux  martin@linux2  Mi Sep 27 20:47:18  standart
 >./test
 4294967295
Can we realy say that C++ is stongly typed when it won't return -1? --Krischik T 18:56, 27 September 2006 (UTC)
thread_title:  C++ strongly typed. Sorry no.