Talk:Strongly-typed programming language
From Wikipedia, the free encyclopedia
Contents |
[edit] 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.
[edit] 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.. 24.136.120.12
[edit] 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?
-- Chris
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.
--Krischik T 13:05, 25 June 2006 (UTC)
[edit] Introduction
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:
- In computer science, a strongly-typed programming language is one that is not weakly-typed.
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)
[edit] C Example
Since
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.
Clarification:
- -1 is of type int and not of type unsigned.
- There are two lexical tokens here, [-] [1]. 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)
[edit] Reverted introduction
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)
[edit] Conversions
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)
[edit] Perl
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. 75.212.177.146 20:01, 27 November 2006 (UTC)
[edit] 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 81.102.136.55 (talk) 11:20, 24 February 2007 (UTC).
