[adrianmsmith]

Great stuff, nevertheless the following is a surely a regression:

> Note that in Perl 6, cmp is smart enough to compare strings with string semantics and numbers with number semantics, so producing numbers in the transformation code generally does what you want.

Perl 5 had a clear distinction between "cmp" (string comparison) and "<=>" (numeric comparison). Trying to work out the data type, and thus the comparison approach, from the actual data itself, is surely going to create subtle bugs, that don't appear in testing, but do appear with live data.

[colomon]

Perl 6 has three comparisons: "<=>" for numeric, "leg" for string (stands for less equal greater), and "cmp" as described above.

[colomon]

I should have also said that a great deal of thought went into making the default behaviors for "cmp" robust. But if (as in the article's example) you're producing numbers in the transformation code, "cmp" is guaranteed to do the right thing for you. Likewise if you produce strings in the transformation.

[adrianmsmith]

"Likewise if you produce strings in the transformation" What if you produce strings that look like numbers? Where, for example, extra leading zeros differ in significance between string and numeric comparison? Surely trying to use heuristics for this stuff is always a recipe for disaster, as with the == operator in PHP?

[colomon]

Perl 6 has proper types. If you produce a string, you are producing a Str object (well, technically it could be an object that does the Stringy role, but I don't think there are any other Stringy types implemented yet) and it will compare as a string, not a number, no matter what it looks like.

Likewise, if you produce a number, you have an object which does the Numeric role, and it will compare as a number.

[perlgeek]

If you produce strings, they are compared as strings, even if they look like numbers.

[orblivion]

This caught my eye as well. As a Python programmer who never learned Perl, this validates some stereotypes. Or maybe it's the budding Haskell programmer in me. "smart enough"? Sounds pretty dangerous to me.

[laumars]

I don't know what stereotypes you are referring to, but Perl is actually one of the better loosely typed languages for not causing the aforementioned bugs. And also one of the best languages for not overloading operators too (which is one of the reasons it looks like executable line noise)

[ugexe]

So don't use the comparison operator that attempts to detects the correct type and use the operator made for the specific type you know you are comparing?

[adrianmsmith]

If an operator has no use (i.e. you should always use a type-specific operator) then why is it in the language at all? If it's there, someone will use it, and if it shouldn't be used, then that's bad that someone uses it.

[ugexe]

Why would you use a type specific operator in a quick script where you don't need to really think about typing and all your perl 6 variables are typed as 'Any' as they aren't specifically typed?