|WikiProject Computer science||(Rated NA-class)|
Error in Code
The code is not correct for C and C++. casting a character to an integer in C, and C++ does not return the numerical value, it returns the ASCII character code; in this case int(b) would return 50, not 2. — Preceding unsigned comment added by 126.96.36.199 (talk) 17:04, 28 May 2011 (UTC)
Visual Basic Literal
- Visual BASIC is a hybrid language. In addition to including statically typed variables, it includes a "Variant" data type that can store data of any type. Its implicit casts are fairly liberal where, for example, one can sum string variants and pass the result into an integer literal.
What is the meaning of the phrase 'integer literal' here? I have always understood the term to mean an integer that is in decimal form in the source code, i.e. in the code:'int x = 5' - '5' is an integer literal. In this context, the above quote doesn't make sense, as there can obviously be no assignment into an integer literal. I would correct it, but I have no idea what is trying to be said there, and I'm not familiar enough with VB.
Typing doesn't refer to keying
Perhaps it should be noted somehow that the term 'Typing' refers to data types, not keyboard typing. It took me a couple paragraphs before I realized this.. 188.8.131.52
5 + 6.2 Incompatible Example
The article reads "A few languages would not regard these two types as being compatible in this context." ... Does anyone have an example to list?
Ada is one example of such a language.
(and most other childreen Pascal language tree).
You would either need to type
Float (5) + 6.2 or
5 + Integer (6.2) or introduce one of the fillowing two user defined + operators.
function "+" (Left : Integer; Right: Float) return Float; function "+" (Left : Integer; Right: Float) return Integer;
The definitions of the user defined + operators shows that the problem runs deeper then most programmers expect: There are three types (left, right and return) and two in question.
Recently there was a change to the article that was described as "Better introduction". While I would be happy to see a better introduction to this article, I think that the introduction that was inserted wasn't better.
The substantive addition of the new introduction was the statement that:
This is an inane truism. The linked article weakly-typed programming language added nothing useful; it was a link back to this one. I have replaced it with a redirect.
The introduction that the article has now suggests that Strongly-typed language has no generally agreed-upon meaning:
- the phrase strongly-typed, when applied to a programming language, may have one of several incompatible meanings, depending on context.
-- Dominus 14:21, 1 Nov 2004 (UTC)
auto unsigned X = -1;
is valid in C and neither a compile-time nor a run-time error is raised C language does not fulfill requirement 2 or 3.
- -1 is of type int and not of type unsigned.
- There are two lexical tokens here, [-] . The literal 1 is negated by an arithmetic operation. [-1] is not the token denoting minus one. Derek farn 16:10, 30 March 2006 (UTC)
- -1 is converted to ''unsigned by bit pattern without checking if -1 is valid.
- This is not true. The C language leaves the behavior unspecified.
- The behavior is fully specified, see signed unsigned conversion. Derek farn 16:10, 30 March 2006 (UTC)
- -1U would be of type unsigned.
- However: -1U is not within the valid range for unsigned.
- This is not true either. It is a combination of the unary minus operator, applied to the unsigned integer constant "1U". The result of this operation is well-defined by the standard; it is guaranteed to be the maximum possible unsigned value.
- In any case, this is not considered a type violation in the C type system. Operations of subtraction and negation are defined consistently for unsigned values and are not considered to be type errors. -- Dominus 19:59, 22 Dec 2004 (UTC)
--Krischik 10:33, 17 Nov 2004 (UTC)
Over the past few months, the point of this article has changed significantly. In the past, it made the point that the phrase "strongly typed" has no generally accepted meaning, and cited several of the many meanings that this phrase has been given in the technical literature. It pointed out that people tend to assume that the phrase has one or another meaning, and use it with their own favorite meaning, as though this were the generally accepted definition, oblivious to the fact that most other people will use the phrase in an entirely different way.
Unsurprisingly, one Wikipedia editor has taken it upon himself to rewrite the article from the point of view that his own favorite definition is the correct and widely-accepted one, when, in fact, there is no widely-accepted definition. The rewritten introduction follows:
- The specification of nearly every high level computer programming language includes the concept of type. Variables are declared to have a type and a language's specification will include rules for the behavior that occurs when variables having different types occur together (eg, as operands in an expression).
Already we see here an implicit assumption that the concept of data type is something associated with variables rather than with, say values. For the author of this paragraph, the entire notion of type can be determined statically. But this view is not borne out by reality or by its description in technical literature. It is only the author's personal bias toward the problem.
The rest of the introduction continues:
- Some languages (eg, PL/I) go to great lengths to allow variables of almost any type to be intermixed, while other languages (eg, Ada) severely restrict the mixing of variables having different types.
- Two examples: ...
- A language that places many restrictions on how variables of different types may interact with each other is said to be strongly typed, while a language that has few such restrictions is said to be weakly typed. Whether a given language is viewed as being strongly or weakly typed often depends on the person making the judgement. Being strongly typed is often seen as a positive attribute of a programming language and supporters of a language may refer to it as being strongly typed for this reason.
An inportant point has been lost in all this: There are at least eight different commonly-used meanings for the phrase "strongly typed language", and this is only one of them. The new introduction simply does not reflect the real meaning of the phrase "strongly typed language" as well as the old one does.
Accordingly, I have reverted the introduction to its state of a few months ago.
-- Dominus 13:58, 23 June 2006 (UTC)
While it's true that there is some disagreement about what constitutes "strong" typing, a lot of the controversy is due to people who use "strong typing" when they really mean static typing (and "weak typing" when they really mean dynamic typing). These people are simply using the terms incorrectly. I am fine with mentioning that some people are confused about the subject, but the article should not make it sound like all these usages are somehow equivalent and acceptable.
184.108.40.206 18:48, 5 July 2007 (UTC)
The point about banning conversions is wrong. Eiffel has a conversion mechanism, but this in no way violates the requirements of strong typing. I understand the point, of course (e.g. banning C-style casts), but there has to be a better way of expressing this.
-- fuchsias, 29 July 2006
- The article does not say that strongly-typed languages ban conversions. It says that some people say that strongly-typed languages ban conversions. This is true. -- Dominus 20:24, 30 July 2006 (UTC)
I removed the Perl example because I could not edit it to be correct. The example stated that a list assigned to a scalar converts to the length of the list. Although an array in scalar context produces the number of elements in the array, this is not true for a list. Additionally, the notion of Perl auto-assigning type is a bit misleading. As variables, the programmer chooses the type and they do not change (a scalar is always a scalar). As values, they depend on the context, but the data themselves do not change (although meta-information may change). None of this really fits in with the article, at least not without a much wider and longer discussion. 220.127.116.11 20:01, 27 November 2006 (UTC)
Java and casts
I removed the claim that "a Java program will usually require casts, which can only be type-checked at runtime", which is unsupported and dubious. It may or may not be the case that the majority of pre-generics Java programs require casts: this can't be claimed without references, and it should be made clear that it's referring to the pre-generic type system. It is certainly the case that generics aimed to eliminate the majority of explicit casts, replacing them with implicit casts checked at compile time. —The preceding unsigned comment was added by 18.104.22.168 (talk) 11:20, 24 February 2007 (UTC).
/* Question: strongly typed = allows creation of subtypes that are kept type-incompatible */
I would like to ask about the following usage of the phrase "strong typing". The first time I ever saw the phrase in use, 25 years ago, was in a (presumably non-standard) option for a Pascal compiler. The following definition was given by example.
In an example program we define two new types; say, the type 'volts' as a subtype of (say) float, and we then define, say, the type 'amps' as a subtype of (say) float.
Definition: in the above case our programming language is termed "strongly typed" if assignment statements (say) of volts=amps; are a prohibited.
This is a highly useful form of type-checking, which is not available with base types such as int or float in C for example. (But I suspect that C enums and structs can be employed to provided strong typing in the sense we are using it here.)
The basic point here is that with this kind of assignment prohibition, assignments are prohibited even if the ranges of possible values of the two types are identical. (We would also want to have type checking on other operators too so as to prohibit nonsense such as volts+amps.)
So this would generalise to read something like "a language offers the strong typing feature if new (sub)types can be defined and are assignment-incompatible even if their definitions are identical." Type definitions that happen to be structurally identical are not considered to be compatible.
Now I have no idea how much, if at all, this kind of definition might have been in use elsewhere? Any ideas?
Concept: Every expression has exactly one type
The concept that an expression has exactly one type is present in some languages. In other languages like Ada it is not present. Specially in combination with the prohibition of implizit casts it makes reading of expressions (for humans and programs) easier. This concept should be mentioned here also. Zron 15:15, 1 November 2007 (UTC)
Removed Most "static typing" mentions
I removed most of the text which mentioned static/dynamic typing, since it could be confused with strong/weak typing. References were left only when unambiguous or relevant. --Lurenai (talk) 20:14, 3 February 2009 (UTC)
- It would be better if you transferred them to the Static typing section of the "Type system" article, to comply with WP:PRESERVE ("Do not simply remove valid but out-of-place information."). --Antonielly (talk) 20:47, 3 February 2009 (UTC)
- Night and Daytime (astronomy) are roughly the same length, while this article is roughly twice as long as Weak typing. Random the Scrambled (?) 19:37, 25 December 2010 (UTC)
- I support this merge, per above. However, the merged article would need a new name that reflects its content on both strong and weak typing. Random the Scrambled (?) 19:37, 25 December 2010 (UTC)
- Support. Suggest we call the merged article strong and weak typing, with redirects from both the current names. I'm no computer scientist though. --Qwfp (talk) 10:12, 25 January 2011 (UTC)
Definitely disagree with this... More can be said about weak typing, with PHP examples or ather examples from other languages and such etc.......... ... ... elipses haha. Then they can be about the same length like the night and day articles. Where an wikipedia do you see two articles for opposites. If you can tell me I'll be surprised.u --email@example.com (talk) 10:12, 25 January 2011 (UTC)
- Support. The concepts do not exist without each other, and one cannot be explained without contrasting it against the other. In practice, no programmer would only need to know about just one of the two "typings." For example, a novice programmer might have only used C, and would therefore only be familiar with strong typing, but would not know that strong typing is a feature of the language — he is oblivious to the difference. Not until he discovers another language (e.g. Perl), is he even aware that different languages support different typing. -LesPaul75talk 16:12, 27 April 2011 (UTC)
The article includes the following quotation:
- Benjamin C. Pierce, author of Types and Programming Languages and Advanced Types and Programming Languages, says, "I spent a few weeks... trying to sort out the terminology of "strongly typed," "statically typed," "safe," etc., and found it amazingly difficult.... The usage of these terms is so various as to render them almost useless."
Current Wikipedia standards require that quotations be citable to a reliable source. I believe that this quotation is uncitable, since it comes originally from a private communication from Pierce to myself. I added it to the article in 2004, when Wikipedia standards were laxer. I believe it is time to retire this quotation. Perhaps a replacement can be found, perhaps from Types and Programming Languages itself.
- Agree. If only Pierce would publish a brief citeable webpage on the subject, we could retain/tweak the quote. But lacking that, yeah, private correspondence fails WP:V. --Cybercobra (talk) 17:49, 18 December 2010 (UTC)
- I can find nothing like this in Types and Programming Languages. —Mark Dominus (talk) 15:22, 19 December 2010 (UTC)
strongly typed languages
the example suggests that C,C++ and java are strongly typed languages while another section claims that java,C# etc are 'stronger' than C. while the second statement maybe true, the first example is not. C especially is a weakly typed language. that section is misleading IMO. regards, Sriraam —Preceding unsigned comment added by 22.214.171.124 (talk) 15:19, 27 April 2011 (UTC)
- It's not correct to say that "C is weakly typed." An argument could be made that it is "strongly typed with some exceptions" just as easily as it could be argued that it is "weakly typed with some exceptions." C is statically typed, which is often what is implied by calling a language "stongly typed." See the example. -LesPaul75talk 16:27, 27 April 2011 (UTC)
- i understand your argument but do not see how static typed languages can be regarded as strongly typed. Perl for example can be static typed and dynamic (as suggested by wikipedia article on static/dynamic typing) whereas the example treats perl as weakly typed.All i am saying is that the example is misleading as C is not a full fledged strongly typed language.It looks like people with different views wrote the example section and the sections that follow.cheers. —Preceding unsigned comment added by 126.96.36.199 (talk) 05:22, 28 April 2011 (UTC)
get rid of this article?
There's redundant info about Weak typing in Type system and Strong typing. In my opinion, Type system should have a brief explanation about both (possibly having the example table currently available in Strong typing), then link to an article that handles both Weak and Strong typing, since the explanation of each is brief and the concepts are compared everytime. This should make for a much cleaner way to organize this knowledge inside wikipedia. (I'm writing this opinion to all 3 current discussion pages) --Roberto.cr (talk) 09:13, 6 May 2011 (UTC)
- I agree about the merge obviously: #Suggested_merge. Just never got around to implementing it. --Cybercobra (talk) 12:11, 6 May 2011 (UTC)
Not the least of which is that a great deal of this article is ambiguous and incorrect. This is a pretty misleading account of strong typing, and there aren't any significant sources for such a well defined field. — Preceding unsigned comment added by Jpancier (talk • contribs) 17:45, 16 September 2011 (UTC)
I think it would be useful to have an article (or at least a section of the Type system article) dedicated to debunking the myth that a type system can be "strong" or "weak". It would demonstrate a number of ways that type systems can differ, and would explain the proper terminology for each one. For example, it could have an example of a language with static type-checking (think C), with dynamic type-checking (think Python), with both (think Java), and with neither (like assembly). Ideally, all the examples would all use the syntax of some imaginary psuedo-Algol language, to highlight the fact that the type system differences have nothing to do with syntax.
I would be happy to write this article. Do people agree with me that this would be more useful and more appropriate than what we have now? — Preceding unsigned comment added by SashaMarievskaya (talk • contribs) 00:30, 26 May 2013 (UTC)
By the way, I should add that I am a professional programming language designer and implementer, and have co-authored two PL papers: http://www.cis.upenn.edu/~mgree/papers/oopsla2009_flapjax.pdf and http://homes.cs.washington.edu/~csgordon/papers/oopsla12.pdf . So I'm not just some person off the street. ;-) SashaMarievskaya (talk) 00:33, 26 May 2013 (UTC)
I added a purpose section. In my perception, the article was overly directed to experts who foster various definitions of "strong typing", while most encyclopedia users probably want a basic definition, and a basic description of the purpose. I am aware that this is to some extent a duplication of the much more elaborate "literature vision" section below - which incidentally mixes properties with benefits. Rbakels (talk) 07:07, 23 April 2012 (UTC)