Grandmother, what a big signature you have!

I tend to agree more with MJD on this point than with Dan.

Here's some more typing goodness from MJD.

---

-- All code is 100% tested and functional unless otherwise noted.

Strong typing loses most of its meaning when most everything is automatically coerced into a new type...

#!/usr/bin/perl -w
use strict;  #try to catch as many type errors as possible

#setup a few initial things
$\="\n";
my $a=4;       my $ref_a=\$a;
my @b=("b",5); my $ref_b=\@b;
my %c=("c",6); my $ref_c=\%c;

print $a+@b;     #coerce array into number
print $a+$ref_b; #coerce reference into number 
my $d=eval %c;   #coerce hash into string
print "d=$d";    #amusing result

my @e=%c;print "@e";  #hashes and arrays are different types.  Oh wait
+...
print "c=$_" for %c;

my @t=12;        #coerce number into array
print @t;
print 0+@t;

print "\\4 = ".(\4->{"what???"});  #???

sub test{ return ("a",123) }; #sub returns a list
my $scalar_list=test(); #coerce into scalar
my  @array_list=test(); #coerce into array
my   %hash_list=test(); #coerce into hash
print "\$scalar_list=$scalar_list\n\@array_list=@array_list";

no warnings;
my %i=$ref_a;
print %i;      #apparently hashes can be scalar refs...

no strict;
$$ref_a->[88]=7;
print $$ref_a->[88]
[download]

---

-- All code is 100% tested and functional unless otherwise noted.

print $a+@b;     #coerce array into number
[download]

This is exactly the same as array.length() in Java. It's not a type conversion.

print $a+$ref_b; #coerce reference into number
[download]

Those are both scalars. Not a type conversion.

my $d=eval %c;   #coerce hash into string
[download]

This one is tricky. What the eval actually gets is certain internal information concerning the hash, which happens to be output as a valid perl expression (a division operation). You've lost all real information about the hash, and therefore is not a type conversion.

my @e=%c;print "@e";  #hashes and arrays are different types.  Oh wait
[download]

My own view on this is that hashes and arrays are both subtypes of lists. So it's not so much a conversion between different types than between different subtypes. There are those that disagree, though.

my @t=12;        #coerce number into array
[download]

This simply makes a scalar containing 12 that is placed as the first element of the list, and the list is then assigned to an array. The scalar is still there, so it's not a type conversion.

I think I've established a pattern here. None of these are really type conversions.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Howdy!

There's a whole bunch of misdirection in them thar comments...

use strict;  #try to catch as many type errors as possibleWrong... The strict pragma is meant to "restrict unsafe constructs", according to its POD. This is not the same thing as "catching type errors". See below for applications...

print $a+@b;     #coerce array into number
[download]

Misleading... This isn't "type coercion". This is "evaluation in a scalar context".

print $a+$ref_b; #coerce reference into number
[download]

A reference is a species of scalar that numifies to the memory address of its referent. No coercion here. It's still a scalar.

my $d=eval %c;   #coerce hash into string
print "d=$d";    #amusing result
[download]

Misleading again. This is "evaluation of a hash in a scalar context". I'm not sure what is actually amusing about the result. It's all there in the documentation.

my @e=%c;print "@e";  #hashes and arrays are different types.  Oh wait
+...
print "c=$_" for %c;
[download]

They are both collections, so one could group them as the same meta-type, but they have different characteristics that warrant treating them as different types. The assignment is simply "evaluation of a hash in a list context". 'for %c' produces the same situation. As usage goes, it's value is limited.

my @t=12;        #coerce number into array
print @t;
print 0+@t;
[download]

The assignment sets up a list context, in which there is only one item, the "12". I don't see "type coercion" here either. The two 'print' statements are unremarkable demonstrations of evaluating an array in list and scalar contexts.

print "\\4 = ".(\4->{"what???"});  #???
[download]

The output of this line lies. \4 produces a different value than does \4->{"what???"}. In the debugger, 'p \4' prints a ref to a scalar; 'x \4' shows that '4' is the referent. The numeric part of the ref is different from that printed by this line, which is, in fact, a scalar reference to an undefined value. What was this supposed to demonstrate?

Further fun with perl -MO=Deparse finds that this print is parsed as

print '\\4 = ' . \$4{'what???'};
[download]

How interesting...

sub test{ return ("a",123) }; #sub returns a list
my $scalar_list=test(); #coerce into scalar
my  @array_list=test(); #coerce into array
my   %hash_list=test(); #coerce into hash
print "\$scalar_list=$scalar_list\n\@array_list=@array_list";
[download]

$scalar_list demonstrates the comma operator in action. What are you trying to demonstrate here? What did you intend to demonstrate with %hash_list? Where does "coercion" come into play here?

no warnings;
my %i=$ref_a;
print %i;      #apparently hashes can be scalar refs...
[download]

Oh? How do you demonstrate that? I note that you "cleverly" turn warnings off so the casual observer won't see "Odd number of elements in hash assignment" pop up from the assignment, nor "Use of uninitialized value in print" from the print. What do you think is actually stored in %i? Iterate over the keys and dereference them, if you dare. Hint: it won't work. Spectacularly.

Further investigation with Deparse show that this is parsed as

my (%i) = $ref_a;
[download]

creating the list context from which it expects to get an even number of items. The same condition applies above at 'my @t=12;'

no strict;
$$ref_a->[88]=7;
print $$ref_a->[88]
[download]

Why turn strict off here? Which facet of strictures were you hoping to sneak by here? Pray explain.

Deparse reports a triple dollar sign, not a double.

So, to get to the bottom: bad troll; no biscuit.

yours,
Michael

Consider the difference between value typing and container typing. Then consider that you've told perl not to check for type violations. Why would you expect it to complain about type system violations?

One other thing: note that even the most strongly typed langauge will let you define a function that takes one type and returns another:

$ ocaml
        Objective Caml version 3.08.1

# let rec sum = function
      [] -> 0
      | i :: l -> i + sum l;;
val sum : int list -> int = <fun>
# let list = 1 :: 2 :: 3 :: [];;
val list : int list = [1; 2; 3]
# sum list;;
- : int = 6
[download]

(If you're not familer with OCaml, the above makes a function that takes a list of integers and sums them, returning a single integer. In OCaml, "int list" and "int" are totally seperate types.)

Indeed, a language that didn't allow you to do this would be very limited. All Many of the examples you presented essentially do this, although the actual function call is hidden away by Perl.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

I've following along on this thread waiting for the punchline, but it seems to be missing :)

Arguing about whether Perl is or is not strongly typed --and by which of the myriad (conflicting) definitions of that phrase it is or is not so--seems a little like arguing whether Lamborghinis or Ferraris are 'true sports cars'. Everyone has their of understanding of the term and places their own level of importance upon it.

A better discussion might be whether Perl's type system is useful or not. One of the things missing and sorely needed by most languages that have static typing is a generic or polymorphic type, that allows generic collection libraries to be written without wholesale cut&paste (automated or not), to support each different containable type.

After C++ first started gaining popularity, the absence of polymorphic container classes, and the near impossibility of writing them became apparent very rapidly.

The proposed and adopted answer was Templates. These are a mess, especially the early variants. They are essentially nothing more than (slightly) sophisticated C-style source-code macros. Create a template Bag class and then instantiate a Class for each of chars, ints, longs, floats, doubles, strings, Dogs and Widgets, and you end up with 8 copies of the 90% of the code that is common. Cut&Paste under a different name.

Newer veriants of Templates may be more sophisticated than this. I haven't touched C++ for years--and fervantly hope I never have to again.

Anyone who's done anything remotely complicated in Java will also know this problem, of a lack of a generic type. And the problems it creates when dealing with any external data source where the type of the data can only be determined after you've read it. Example, communications protocols. The lack of C/C++ unions makes for very clumbsy handling of datastreams where you cannot predetermine whether the next few bytes are a string, an int, a float etc.

There are now moves afoot to correct this limitation in Java. I can't comment on it, beyond that the fact that as the home page is not on a Sun site, it makes me a little wary. But it does highlight that people are seeking to address this limitation.

Here we are with Perl's 'roll-your-own' OO and 3 1/2 types, and yet we have two, simple, powerful, infinitely flexible polymorphic container types: Hashes of scalars; and arrays of scalars; from which it is possible to construct any number of easily usable containers with specific behaviours, that have a common syntax, and can be efficiently operated on (iterated over, tested for existance, compared, deleted etc.), using many of the built-in language features and functions*.

In addition, we have the tie mechanism that allows us to use our 3 1/2 types to encapsulate a whole raft of other types, behaviours and complexities behind those same, 3 1/2 simple interfaces.

We should be laughing ourselves silly at all those pundits that think that calling Perl "not strongly typed" is an insult.

Whilst they continue to to try and devise a polymorphic container mechanism, that they obviously need, and fighting their compiler over who knows best about what the program should and should not needs to do--we can just get on with the business of writing code, easily and quickly, that does what we need it to do.

*Why people ignore the simplicity and usability of Perl's hashes and arrays as polymorphic containers and instead opt for using the so-called "Factory Pattern" to achieve the same thing with a much less usable and much less efficient interface puzzles me greatly.

But I think that this Heron language just uses the worst parts of the syntax of Object-Pascal (Delphi) and C++!

On C/C++ and Delhpi a lot of things could be done automatically by the compiler, and they are missing this again with Heron.