Talk:Comparison of type systems

Why this table?

What's the point of this table and how's it going to get accurate given the various definitions of the terms and different grades of their application in real programming languages. --TuukkaH 11:41, 6 February 2006 (UTC)

If you look at the old versions of Programming language and Datatype you will see two things:

1. Lot's of sentences/sections like "Examples of ... are ...", Common languages using ... are ...
2. Lot's of duplication - because both pages had allmost the same lists.

From that I thought a table would give the reader a better overview than lists scattered all over the text. And a template was needed since the lists had been in two pages.

I did not think that deleting was an option. For one, since the informations is useful for the reader and also they would just be re-added by languages advocates (like me ;-) ).

As for accuracy: The Wiki concept should take care of that - the languages advocates will make their entry accurate.

--Krischik ^T 11:55, 6 February 2006 (UTC)

It can be useful to give some examples also in connection with theory, but I agree, everybody plugs "their" language. I'd still like to voice the need of clear definitions. At least all the headings should link to a section at datatype so there would be less chance of incoherency. Static vs. dynamic is easy, but isn't strong vs. weak pointless as there is not one accepted definition? --TuukkaH 17:26, 6 February 2006 (UTC)

Links to datatype

Yes having all headings link to datatype might indeed be a better.

--Krischik ^T 07:23, 7 February 2006 (UTC)

strong / weak

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)

C is (almost) structurally typed

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)

typedef does not do what the name suggests

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)

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)

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)

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)

struct Int1 {int x;};
struct Int2 {int x;};
typedef struct Int1 *Ptr;

int main(){
  struct Int1 s,*p;
  Ptr q;
  struct Int2 *r;

  /* The following are all legal. */
  p = &s;
  q = &s;
  p = q;
  q = p;

  /* The following generate warnings (gcc 3.4.4) */
  r = &s;
  r = p;
  r = q;

  return 0; 
}

assignment in C does not work on structs

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)

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)

assembly untyped?

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)

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)

On machines which depend on address roundedness to carry out certain instructions, for every address computable at assembly time, assemblers generally protect authors. Thus, assembly language is static-typed.

A given machine's instruction-mandated address roundings (called address boundaries) are assembly language's symbol types: usually whole and even numbers, multiples of four and sometimes multiples of eight. Or they might be whole numbers, multiples of three and multiples of nine, or any combination of numbers. Also are block boundaries, often used in memory segmentation. On some machines, identical address numbers (even computed finally at run time by the processor) can be in different address spaces, e.g., instruction space and data space. This creates different symbol types.

Whatever the given machine's combination of address roundednesses, its assemblers generally take trouble to enforce them statically. One enforcement method is silently to adjust the address of a symbol up to the most restrictive boundary needed by its containing instructions, which has surprised authors packing things.

However, regarding incomputable addresses at assembly time (for instance, the sum of a fixed address and an address register's contents) assemblers generally do nothing.

See most processor instruction manuals, e.g., University of Maryland UNIVAC 1108 reference manual. Georgesawyer 16:07, 27 March 2006 (UTC)

Scheme

How's typing in Scheme different from typing in LISP? --TuukkaH 09:43, 10 February 2006 (UTC)

Well, there is a clear indication that the author has not thought enouch before adding Scheme. He has not taken note on the fact that each type has it's own background color (adding nominative with the background color of duck). A programmer trained in methodic thinking should have seen that. --Krischik ^T 11:25, 10 February 2006 (UTC)

You really seem to be pissed off about these colours. I'd suggest you remove the colouring so everybody can contribute to the content without anyone messing up the (not so important) colours. See for example Wikipedia:Manual of Style#Keep markup simple. --TuukkaH 12:23, 10 February 2006 (UTC)

I am not "pissed off" because of some colors - if the content was undisputed and just the color wrong then I would just correct the color and all is good. --Krischik ^T 13:20, 10 February 2006 (UTC)

I'm sorry for choosing an emotional phrase, but I can't see any other explanation if instead of discussing the subject you attack an author based on their not complying with your colour scheme. I had your edit summary from yesterday still fresh in mind: "If they could just remeber to change the colors as well." I hope we concentrate on content now. --TuukkaH 16:22, 10 February 2006 (UTC)

Actually, a good programmer assumes that properties that directly depend on others either update automagically. Since I know wikimedia doesn't support that in this case, I didn't think the colours mattered. Big deal. Wouter Lievens

Leaves the problem why Lisp is (dynamic strong safe structural) and Scheme is (dynamic weak safe nominative). When Scheme is a dialect of Lisp than this seems wrong but then I might be wrong. --Krischik ^T 13:20, 10 February 2006 (UTC)

Ruby Strongly typed?

Some anomymous user change Ruby to strong. However I feel that strong and duck won't go well with each other. Strong typing means "strong seperation between types" and duck means that types are distinquished by: "if it walks like a duck, and talks like a duck, then it might as well be a duck". Mutually exclusive comes to my mind.

Prehaps the anomymous user mistaken "strong " for "save". While it is usually true that static + weak → unsave this does not hold true for dynamic typed languages. In fact most dynamicly typed languages are save no matter if they are strict or weakly typed.

--Krischik ^T 07:27, 24 February 2006 (UTC)

PS: I like this list: It give raise to many interesting discussions which broadens one mind.

Ruby is strongly typed. Something like the following:

         10 + "11" # => TypeError
         "11" + 10 # => TypeError

...does not work in Ruby, as the coercion from a String to a Fixnum (or vice-versa) must be done explicitly:

         10 + "11".to_i # => 21
         "11" + 10.to_s # => "1110"

A weakly typed language wouldn't produce a type error in such a situation.— pmcm 23:13, 26 February 2006 (UTC)

Thanks. --Krischik ^T 07:10, 27 February 2006 (UTC)

Haskell?

Any reason that ML is labeled as having structrual typing, while Haskell is nominative? Haskell has a Hindley/Milner type system very similar to ML's with inference.

It's worse than that. The fact that datatypes in ML are "generative" means they are treated nominally; the whole point of abstract types defined in modules is that their structure is invisible for type equivalence purposes. I've said it before: structural versus nominal is not a useful distinction and should not be used to classify type systems. Cjoev 00:11, 19 April 2006 (UTC)

I second that objection. I can use many languages in either style, e.g. Haskell:

--structural
listContainingAtLeastOneElement :: [a]  --shares structure with other lists
type AssocList1 a b = [(a,b)]  --type aliases have structural equivalence (like C typedef)

--nominal
data ListContainingAtLeastOneElement a = ListWithHead a [a]  --nominal equivalence (like C struct)
newtype AssocList2 a b = AssocList2 [(a,b)]  --nominal equivalence

--some combination:
data Association a b = Association a b
type AssocList3 a b = [Association a b]
data AssocList4 a b = Cons (a,b) (AssocList4 a b) | Tail

While these may be contrived examples, it does come up in real design with tradeoffs to be made between abstraction and convenience and many other things, each circumstance decided separately by the programmer. At least (strongly) statically typed languages, such as C/C++ and Haskell, need both manners of equivalence to be available. Each language is unique though and the other categorizations I used are not absolutes either...

"nominative type systems operate based on explicit annotations in the code" -- e.g. C++ "struct Foo {int i;};" but equally Haskell "data Foo = Foo { i :: Int }". Using type inference elsewhere doesn't keep it from being nominative! Overuse of generic tuples leads to more structural code, but that can be done in any language that can have tuples, including C++ (explicit static typing with templates), Python (dynamic typing), and Haskell. —Isaac Dupree^(talk) 15:03, 20 April 2006 (UTC)

I was just going to point out the coexistence of both in C++ (pointer types are trated structurally until reaching the pointed class), when I found your "(strongly) statically typed languages, need both manners of equivalence". What's the reason behind this? I mean, why do they need both? --euyyn 13:45, 12 August 2006 (UTC)

Should xHarbour be in the table?

xHarbour is just an implementation of a dialect of Clipper. We already have Clipper on the list and xHarbour isn't as notable as the other languages. Should it be removed? - DNewhall

PHP

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

It absolutely is. I am changing it here in this table. Here is an example of PHP's weak typing (based on code found at http://wiki.riteme.site/wiki/Type_system):

 $x = 5;
 $y = "37";
 echo $x + $y;

The result is 42. --Vizspring 06:27, 15 May 2006 (UTC)

assembler type-save ?

I don't know why the assembler entry was changed to type save. Assembler is certanly not type-save. Remember: Type-savety is about problem space not computing space.

Say you store a 1 as INT32 into some memory address and later on read the same memory address as FLOAT32 - will the bit pattern still represent a 1 and if not will an error be reported?

It is not enough that the computer won't crash - the value must still represent a 1 in problem space. And a 1 in problem space must - among others - have the following properties: 1 + 1 = 2 and 1 - 1 = 0.

--Krischik ^T 10:38, 2 May 2006 (UTC)

According to the formal definition at Type safety, based on preservation and progress, type safety is just about whether or not a crash will result. In the case of assembly language, the key fact is that when you store a bit pattern as INT32 and then read it as FLOAT32, something well-defined happens -- not only does the computer not crash, it produces a result that you can predict by reading the manual, and it does so reliably. You could imagine someone doing that on purpose under sufficiently bizarre circumstances. That makes this behavior safe according to the type-theoretic definition. As it says in the article on type safety, the properties of preservation and progress are not the same for all languages: in particular, progress depends on what the particular language in question defines as an erroneous condition. -- Cjoev 19:43, 2 May 2006 (UTC)

The article about Type Safety you linked to says in the first paragraph:

(About the term "type safety",) most uses have in common the notion of employing a type system to prevent certain forms of erroneous or undesirable program behavior (called type errors). This enforcement can be static, catching potential errors at compile time, or dynamic, associating type information with values at run time and consulting them as needed to detect imminent errors, or a combination of both.

In assembly there's no type system enforcement at all: you just move chunks of bits from here to there as you like. The fact that certain operations (as a float.p. mult.) assume the data you present to them meets certain organization (type) doesn't make that data a member of this type. For the same reason, when you void*-cast some pointer in C you can make type-unsafe things with it. Moreover, the way stored files are type-unsafe in most (all?) filesystems (as the FS doesn't prevent you from reading them with any random structure you invent) is the same way the main memory is type-unsafe in assembly. You can write a double and read its middle word as an int, for example. There's no intent to catch those things at compile (assembly) time, nor is it at runtime. Sure the result is well-defined in the family of processors for which that language was designed, but I would say that's a side effect of the standarization of float.p. representations, not an design goal.

Maybe the fact that you cannot make a float.p. op with integer registers could be considered a type enforcement (the assembler could well write the register number in the machine-code instruction, ignoring wether you said integer or f.p.). So someone could say there's an enforcement differentiating integral from f.p. registers. There's no enforcement, e.g., about which kind of integral you're using: bytes, nibbles, words, signed/unsigned.

The test of wether a crash is produced seems rather unnatural to me. It's not so easy to crash a computer program. If the program crashes or if it ends but giving an incorrect result, in the presence of an error, is fairly random. Reading a float32 as an int32 doesn't crash the program inmediatly, but it could lead to a crash, or not. Anyway, if doing it wasn't your intention, the program would be erroneous, and the language washes its hands, so, by "my" standards, it's type-unsafe. Sorry for the lengthy argument. --euyyn 14:36, 12 August 2006 (UTC)

The last entry in the same topic up there mentions another kind of "type enforcement" in assembly languages: the rounding of addresses. Although the thing doesn't really enforce types, but properties of types (in this case, its size). For example, it doesn't differentiate between signed and unsigned. Interesting conversations in this talk page... --euyyn 14:54, 12 August 2006 (UTC)

Make each row a template?

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

{{type system|Ada|Ada programming language|static|strong|safe|nominative}}

instead of the current

|- 
| [[Ada programming language|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)

Objective-C is strongly typed

At least as strong as Smalltalk. —Preceding unsigned comment added by 89.173.3.51 (talk) 14:34, 14 February 2011 (UTC)

C++ strongly typed. Sorry no.

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)

Well, yeh, this is surely a C compatibility thing... The problem isn't it printing 429..., but it allowing you to assign -1 to an unsigned. Remember C was very permissive with folk that knew what they were doing, and it has a straightforward translation to assembler. So if you wanted to put all-1s in your unsigned, heck, you just typed -1, and everybody was happy.

But remember you can always create a class "Unsigned" that has an implicit constructor from "Signed", so C++ folks could wash their hands by pretending they were actually doing a conversion. Well, indeed I remember numeric conversions are all of them implicit in C/++ and well documented, so probably assigning a negative to an unsigned is section 3.b.iii.7.h of the "Implicit Numeric Conversions" chapter. If I remember well, the standard came to say something like "we'll convert between floats and ints, and will pretend that we have a plan for integral conversions, while indeed you'll be using assembler". --euyyn 22:49, 10 November 2006 (UTC)

Requested move 21 May 2016

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: No consensus to move the article has been established within the RM time period and thus defaulting to not moved. (closed by non-admin page mover) — Music1201 ^talk 02:24, 11 June 2016 (UTC)

---

Comparison of type systems → Comparison of programming languages (type systems) – Consistent naming in Category:Programming language comparisons 128.70.197.164 (talk) 23:19, 21 May 2016 (UTC)--Relisted.  InsertCleverPhraseHere  06:09, 29 May 2016 (UTC)

• Content fork of Comparison of programming languages (types, type system) ?? wbm1058 (talk) 01:51, 28 May 2016 (UTC)

There were multiple pages on the same topic:

* Comparison_of_programming_languages#Type_systems

* Comparison of type systems (this page)

page Comparison of programming languages (types, type system) was created to merge them more easily and also to re-use this content later on.

See Category:Programming languages by language concept for context. Ushkin N (talk) 09:14, 28 May 2016 (UTC)

• Oppose since the present title makes more sense; the backwards-disambig-like title does not. More likely plan is to merge Comparison_of_programming_languages#Type_systems into Comparison of type systems, while Comparison of programming languages by type system seems like an unneeded content fork. Dicklyon (talk) 05:15, 30 May 2016 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.