Perl doesn’t have casting, it has autoconversion. Casting is getting the runtime to ignore type information and reinterpret the same data. Autoconversion relies on type information and changes the underlying data.
Not possible from within Perl. Perl is strongly typed.
Nobody really quite agrees on what “strong typing” actually means. That said, if you go down the list of possible definitions of strong typing, C fails more of them than Perl.
Even so, IMO the very existence of void* as a construct that requires no special libraries to use and carries no additional compiler warning by default pretty much makes it one of the most weakly typed languages. (Compare to, say, Go which has unsafe.Pointer with roughly the same function, but without unsafe imported it will only let you do type conversion and with unsafe imported things like Google App Engine won’t even let you upload it because of the safety dangers. And the unsafe package is actually implemented in the standard library in languages other than pure Go because doing what unsafe does is not possible with just the syntax of the language)
But this is still all definitions.
We’ve been over this before in a different thread. In short, you have a definition of “storng” vs. “weak” typing which doesn’t match my own. I doubt that either of us can come up with proof that our definition is the one and only correct one.
The pack and unpack functions allow you to reinterpret data. Any language with sufficiently powerful file IO also allows reinterpretation.
If we wanna go there, any language that’s provably Turing Complete will let you do anything. 
Sure, any pointer will autocast to void *… but you can hardly use that for anything without additional casting (or warnings). You can use it to free memory, which is safe. You can’t do any pointer arithmetic, or pass it to functions that expect a typed pointer, or anything like that, without aditional casting.
I suppose that one reason for disagreements on the nature of typing is that of one’s goals as a programmer. For instance, it is extremely important to me to know about numeric conversions. C/C++ is fairly good in that respect: it always warns if I try to shove a double into a float, or an unsigned int into a signed int, etc. And of course it actually allows these different types in the first place.
Perl/PHP/etc. support very little of this. They freely move between floats, int, and strings, with little or no warning on loss of data. And of course the type system in general is extremely weak in the sense that I can’t even specify the type of number I want.
But they are safe, in the sense that I can’t crash the program or get into too much trouble. Ironically, this matters more for one off scripts where I don’t want to think too much about how to get things done. For serious programs I want more control, and can afford to give up some safety to achieve that.
Taking this line to the logical conclusion, you can imagine a language where absolutely everything is a string. All arithmetic works on strings. Data structures like arrays and hashes are always serialized/deserialized to a string. And so on.
By some narrow definition, this is a strongly typed language. How could it not be, if there’s only one type, and there’s no way to get at the internals of that type? And yet it seems a little odd, since I can easily break a hash table by tweaking its string representation. It’s strongly typed in some weird theoretical sense but not in any practical sense (at least not what I would consider a practical sense).
External modules can be written in C (or probably any language) and do whatever they want, including exposing internal representations to the script.
Sure, the module isn’t in Perl, but allowing non-Perl modules is a Perl feature.
If casting in C worked as you describe, then casting the number 33 from an integer into a float, would not result in 33.0 but rather some crazy value based on whatever that bit pattern means in IEEE floating-point representation. But that’s not how it works – the value will get properly converted, showing that the compiler is quite aware of the original type. (It won’t change the type of the original variable, since C is statically typed, but it will automatically create a temporary value on the stack if needed.)
In order to reinterpret an integer as a float without conversion, you need to take its address, cast that from a pointer-to-integer to a pointer-to-float, and then access the same memory via the float-pointer. At that point you’re simply telling the compiler “trust me, I know what I’m doing”. But even this is still type-safe in the sense that the compiler knows what the type of each pointer is, knows how to convert between those types, and will not allow unsafe conversions unless you explicitly ask for them.
But when it comes to being aware of the type of every value in the code and not allowing operations between incompatible types unless you go out of your way to assure the compiler that that is what you want to do, C is actually a lot stricter and more nitpicky than Perl, which will happily autoconvert things implicitly at the drop of a hat, even when the result will almost certainly not be what the programmer intended. E.g. cos(“three”) in Perl will silently autoconvert the string into the number 0, while C will give an error because you cannot call ‘cos’ with a string argument without explicitly telling the compiler how you want it to convert that string into a number.
[QUOTE=Jragon]
Nobody really quite agrees on what “strong typing” actually means.
[/QUOTE]
“In general, these terms do not have a precise definition. Rather, they tend to be used by advocates or critics of a given programming language, as a means of explaining why a given language is better or worse than alternatives.” Heh. 
But apparently, the original definition from the people who invented the term, is “whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function.” And “in a strongly typed language each data area will have a distinct type and each process will state its communication requirements in terms of these types.”
That seems to describe C/C++ better than Perl, in my opinion, since the latter will almost never complain about calling a function with a value of the wrong type, but will just happily autoconvert that value even if the result probably won’t be what the programmer intended.
Like I wrote earlier it actually doesn’t display anything…
BTW…
echo 'false:'.false;
echo '<br><br>';
echo 'true:'.true;
echo '<br><br>';
echo 'true == 1: ';
if (true == 1) {
echo 'yes';
}
else {
echo 'no';
}
echo '<br><br>';
echo 'true === 1: ';
if (true === 1) {
echo 'yes';
}
else {
echo 'no';
}
Displays:
false:
true:1
true == 1: yes
true === 1: no
So though “true” displays as “1” they’re not actually the same thing if you use ===
BTW for the first bit:
print(2) + 3 is the same as
print (2) + (3)…
(and print 2 + 3)
IMHO I don’t think support for brackets was explicitly coded in for print (and echo and include, etc) but it supports brackets like $a = ((5) * ((2) + (3))) supports brackets…