in reply to Re: strong typing in thread (Completely OT) - Hero(i)n programming language on Slashdot
Misleading... This isn't "type coercion". This is "evaluation in a scalar context"
I'd be interested to know the difference. Here are some quotes and references I've been able to round up...
- Coercion is the implicit, automatic conversion of the type of an expression to the type required by its context. Most programming languages that have type checking also have some coercions, such as integer to real in mixed expressions. (Dereferencing is a coercion associated with pointers $\S $16.) Coercions can be dangerous because they are not explicit, but depend on declarations that may be some way away in the program text, and it is easy for the user to make mistakes.
- The ($$) is the prototype. It's a shorthand to identify the types of the arguments that will be passed to your subroutine. In this case, Perl is told to expect two scalars. You can prototype your subroutines without defining them:
sub add_two ($$); # add_two will be defined later
If you then try to call your subroutine without two arguments that can be evaluated as scalars, Perl will complain. (However, almost everything can be coerced to a scalar. Scalar prototypes accept @arrays and %hashes without warning!)
- Normally, when an array is an operand of a unary or binary operator, it is evaluated in the scalar context imposed by the operator and yields a single result. For example, if we execute:
$account_balance = @credits + @debits;
$biblical_metaphor = @sheep - @goats;
then $account_balance gets the total number of credits plus the number of debits, and $biblical_metaphor gets the numerical difference between the number of @sheep and @goats.
That's fine, but this scalar coercion also happens when the operation is in a list context:
@account_balances = @credits + @debits;
@biblical_metaphors = @sheep - @goats;
- Tutorial on Collections and References in Perl
$length2 = scalar(@intArray); # type coercion, reports size of the arr
+ay
$hashTable{"third"} = @intArray; # coercion to a scalar type means the
+ value is not the array but its length
- When overloaded operators are applied to mixed expressions such as plus to an integer and a rational number there are two possible choices. Either the evaluation of the expression fails or one or more of the subexpressions are coerced into a corresponding object of another type
- Coercion allows the user to omit semantically necessary type conversions. The required type conversions must be determined by the system, inserted in the program, and used by the compiler to generate required type conversion code. Coercions are essentially a form of abbreviation which may reduce program size and improve program readability, but may also cause subtle and sometimes dangerous system errors.
- Implicit. In this case, no actual notation is required to specify the conversion: conversions are automatically supplied by the language processor. This type of conversion is often called coercion. ...When a type mismatch occurs between the actual type Ta of expression occuring in a context which expects a type Te, a type checker would normally report an error. However, if the language defines a coercion in this case, then that coercion is applied instead of reporting the error.
- JScript can perform operations on values of different types without the compiler raising an exception. Instead, the JScript compiler automatically changes (coerces) one of the data types to that of the other before performing the operation. Other languages have much stricter rules governing coercion.
- Internally, adding a float and an integer is not possible, so the compiler should convert one type to the other type “as necessary”. This is called type coercion and can be the source of some subtle bugs (coercing floats to integers, for example). Type coercion is controversial topic in language design, since it is an easy abstraction, but weakens the type system.
- Truth in Perl is always evaluated in a scalar context. (Other than that, no type coercion is done.)
-- All code is 100% tested and functional unless otherwise noted.
Re^3: strong typing
by herveus (Prior) on Dec 15, 2004 at 12:39 UTC
|
Howdy!
If you "coerce" a value, you still have the same value, expressed in
different units, if you will. For example, 1 (integer) can be coerced
into 1.0 (float) without loss of information. However, when you write
$a + @b, the operation being performed is not, in my mind, type coercion.
There is an implicit operation being performed on @b, but you cannot
say the @b is the same thing as the number of elements it contains.
The two values are incommensurable.
I am reminded of an advertisement that has been on the air lately that
speaks of "miles", "nautical miles" ("a wetter version of miles"), and
"square miles" ("a squarier version of miles"), as if they expressed the
same thing (before segueing to the point of the advertisement). It's
inane to assert that you can somehow compare length with area, just as
it does not make sense to think that @z in "$x = $y + @z" can mean "the
collection of elements in the array z". Now, the hypothetically legal
"@x = $y + @z" could cause @x to contain the elements of @z each with $y
added to them, but that's a whole different kettle of fish.
Many of the alleged "type coercions" sleepingsquirrel presents are of
this sort, where a variable or expression is being evaluated in an unusual
context, causing implicit operations to be performed that extract attributes
of the variable rather than its value. Perl does this a lot more than most
languages.
Now, the lengthy dissertation I reply to dodges the fact that many of the
examples adduced are obfuscated by the misleading comments appended thereto.
Warnings are suppressed at key moments; strictures are misrepresented.
It still comes across as trollish...
| [reply] [Watch: Dir/Any] |
|
|