Talk:Datatype
|
|
Taku, I appreciate your intent, but the discussion of Liskov Substitution Principle was out of place the way it was. I have removed it.
If we want to integrate all discussions of type systems into a single article, that's fine with me. If we want to put the Liskov discussion into the Subtype article, that's fine too (though we ought to mention that Liskov's is only one definition of "subtype"). However, just unceremoniously sticking the Liskov stuff into this article is definitely not appropriate.
Furthermore, a redirect is certainly not appropriate. "Liskov Substitution Principle" is not equivalent to "Datatype". Therefore, while the LSP article could be a very small article that just points to Datatype, IMHO it should not be a redirect. -- P3d0 14:25, 20 Sep 2003 (UTC)
- What I thought is that is LSP such a big topic? To me, it doesn't say more about what I know about subtypes. Since subtype is redirected to datatype, then it makes sense to me to merge LSP to here. Subtype certainly deserves to its own article, but for now it is fine to put a redirect to subtypes. If I use an analogy, it is like there is no object-oriented programming article while there is an article about what is a class. LSP looks out of place because this article should be expanded more and subtype should have its own article. -- Taku 00:12, 22 Sep 2003 (UTC)
- You make a good point. I had thought "Subtype" had its own article. Perhaps we should take a look at all the type-related pages (including LSP) and look for a way to merge them. -- P3d0 10:51, 22 Sep 2003 (UTC)
Taku, Taku, Taku. The "what a type speficies" section is totally bogus. "alighments"? Sheesh. Byte size? I'm speechless. It's truly exhausting keeping track of your changes. Sometimes I wish you weren't so exuberant and prolific. :-) -- P3d0 15:20, 3 Oct 2003 (UTC)
- I am not sure what is wong with that section. For example, you have int type in C and it specifies the value of the type is 4 bytes long usually and signed and so on. Maybe wording doesn't make sense to you. Please remember I am always happy to see you editing too. -- Taku
- Be careful generalizing based on what happens in C. If you only look at C, then a "function" is any subroutine whatsoever, a char is one byte in size, all parameters are passed by value, etc.
- Datatypes may occasionally specify objects sizes, layouts, and padding, but not usually. Can you tell the size, layout, or padding of types in Haskell? Lisp? Eiffel? Smalltalk? Python? Pascal? BASIC? Java specifies sizes of primitive types, but not of objects. Even C doesn't specify how big an int is (despite your assertion) nor how structs should be padded. In fact, I'm having a hard time thinking of any languages in which a datatype specifies size, layout, and padding.
- Anyway, I'm sorry if I was condescending before. -- P3d0 01:07, 4 Oct 2003 (UTC)
- Oh, I see now what confused you. You thinking of specification of languages. Sure, C specification only says int must be of the size of natural length in the target language. What I was thinking is what kind of information is compilers use to analyze code and what information is still avaliable in run-time. For example, you can say virtual methods are kept even at run-time to enable dynamic binding. I guess it is really confusing to say what datatype specifies. For now, I just removed that portion and put revised version later. Let me know your thoughts then! -- Taku
- Refactoring type related articles gets complicated; I put a list of related articles at see also section of the article. They surely need to be merged or seprated. -- Taku
There still seems to be some loose use of language in this article, particularly on the difference between the strong/weak value axis and the static/dynamic type-checking variable axis.
Type safety means that the language will not execute code which uses a value in an operation for which its type is not acceptable. Virtually all languages make some effort towards type safety, in the form of type-checking (be it static or dynamic) and type-conversion. A failure of type-safety occurs in C or assembler when one treats the memory location of a short integer as if it contained a pointer -- and indirecting through the "pointer", one reaches a nonsense value.
Static type-checking means that the type-safety of a program is verified at compile-time, in terms of its variables. Static type-systems may require type declaration, or may use type inference -- either way, a type is assigned to each variable and function argument, and it is shown that no type-unsafe calls are made. Dynamic type-checking means that types are checked at run-time, in terms of argument values. A language which does not check types at run-time (e.g. C) does not have dynamic type-checking.
Static type-checking has been called incompatible with certain kinds of dynamic metaprogramming. This is the topic of a current controversy on comp.lang.lisp which may be enlightening (when it isn't being flamy).
Strong typing means that a value of one type may not legally be used in place of a value of another type. The set of operations which will accept a type is exactly the set of operations defined in terms of that type. Values must be converted or cast. Weak typing is the opposite: conversion is automatic and implicit. Weak typing does not imply that type-unsafe operations must be executed: it does imply that undesirable conversions (such as number truncation) may occur in order to prevent same. A single language may be strong with respect to some type differences, and weak w.r.t. others; weak typing might be more pleasantly called permissive or implicit-conversion-ful. :)
http://cliki.tunes.org/Type%20System has a discussion of these and two other axes upon which type-systems can be described.
Static type-checking prevents you from compiling a program with type errors or undeclared ambiguities in it. Dynamic type-checking stops the type error from causing dangerous behavior, usually by stopping the program. Strong typing protects you from unexpected truncations and other conversion problems.
Here are some possible type-related bugs, and the way that different type systems respond to them:
- I tried to use an integer value as a pointer, and wrote junk data on top of something. Any type-safe system (static or dynamic) will prevent this, by raising a type error either at compile-time or run-time. A system which is weakly typed with respect to the integer/pointer distinction is type-unsafe on most computer architectures!
- I used an integer operation on a real number, but I don't really need the decimal part. A static strong type-system will raise an error at compile-time. A dynamic strong type-system will raise an error at run-time. A weak type-system will convert your real to an integer -- which is not a bug in this case, but see the next.
- I used an integer operation on a real number, and returned an incorrect answer because of it. Any strong type-system will prevent this. Type-systems which are weak (or "permissive") with respect to numeric conversion will not; they will cheerfully truncate your real.
- I used the string "69" where I meant the number 69. Only a type-system that is weak wrt the string/number distinction -- such as Perl's -- will accept this code.
- There's a library function which usually returns a Foo object, but sometimes returns integer zero to indicate error. I write a function which can only accept a Foo, and call it on the return of the library function. A static type-system will refuse to compile your function. A dynamic type-system will not raise a fuss until the erroneous case actually happens. Only a type-unsafe system (such as assembler) will let your code try to use the zero as if it were a Foo, and get corrupt data.
And here are some languages of each category:
- Static, strong: Haskell (type-inference); Java (type declaration)
- Static, weak: C (type declaration -- also, plenty of ways to get around the type-system and do something type-unsafe!)
- Dynamic, strong: Common Lisp (type declarations are optional); Python
- Dynamic, weak: Perl (loves to do implicit conversions ....)
--FOo 23:16, 15 Nov 2003 (UTC)
As you might notice, I made a major structural edit. I basically eliminated a lot of duplication and reorganized contents for readability. I think I worked very carefully not to lose important points but if you have noticed some missing, don't hesitate to restore them. Also, my interest was of organization (as usual?) so spelling and grammar might be terrible. Any copyedit is highly welcome. -- Taku 06:44, Apr 8, 2004 (UTC)
In Subsection 2.1 Static and dynamic typing, in the paragraph that begins with "By contrast, a purely dynamically typed system," a code example is referenced that doesn't appear until later, in the next section, as if it would be close by.
What is the best way to fix this, do you think?
Ehn 19:59, 28 Jul 2004 (UTC)
Latent typing redirects here, but there is no mention of it on this page, let alone a prominent one. - Furrykef 16:12, 4 Sep 2004 (UTC)
Static/Dynamic typing
It's odd that there aren't any seperate pages dedicated to both static and dynamic typing. There could be pages full of pro's, con's, examples, languages, ... but all there is is a small section here? Wouter Lievens 08:59, 22 Mar 2005 (UTC)
- Maybe we should as that section used to be a separate page. I merge it to here because I thought discussing datatype without mentioning typing makes little sense. -- Taku 14:39, Mar 22, 2005 (UTC)
- The mention of type systems and the discussion of type systems are two totally different things. Of course this page should not go without a mention and link to the two other pages, but it shouldn't actually contain them (is my opinion). --seliopou 20:35, 2 Apr 2005 (UTC)