in reply to (ar0n) Re: eq or == with references
in thread eq or == with references

It makes sense that == should not work for references. After all, references are scalars. == is an arithmetic operator that interprets comparable scalars as numbers.

Using arithmetic operators on pointers is a form of pointer arithmetic in C.

Perl, however does not have pointers. It has references. And the major difference between C pointers and Perl references is that C pointers allow pointer arithmetic and Perl references do not allow pointer or reference arithmetic. Hence the use of an arithmetic operator such as == on a Perl reference is not meaningful.

Tye points out that Perl has a feature that interprets the == for references in a meaningful way. Larry and company ought to remove this feature. References are not numbers. The Perl compiler ought to prohibit numeric operations on references.

  • Comment on Re: (ar0n) Re: eq or == with references

Replies are listed 'Best First'.
Re: Re: (ar0n) Re: eq or == with references
by japhy (Canon) on Jul 08, 2001 at 19:38 UTC
    Except that it exists for the purpose of determining likeness between two references. Numerically comparison is generally faster than string comparison.

    japhy -- Perl and Regex Hacker
[reply]
Re: Re: eq or == with references
by Dr. Mu (Hermit) on Jul 08, 2001 at 21:58 UTC
    Treating a reference as a number would only be a problem if it were possible to create (i.e. compute) a new reference numerically. This would be equivalent to allowing pointer arithmetic. As long as this is not the case, one representation for comparison purposes should be as good as any other, as long as there's a one-to-one correspondence between the references and their representations.
[reply]

      Yes, using == on references does not "reference arithmatic" make... (sierrathedog04 wrote

      The Perl compiler ought to prohibit numeric operations on references.
      ). Perl doesn't support any numeric operations on references. It does support converting a reference to a number and then doing numeric operations on those. It certainly doesn't support converting a number (no matter how you got it) into a reference (nor does it support any operations that take a reference and a number as input and return a reference as output). So I don't understand the leap from == to fears of reference arithmatic.

      I don't like using eq to compare references because it feels very much like comparing numbers via:     sprintf("0x%X",$num1) eq sprintf("0x%X",$num2) (And if a design bug I found in overloading is ever fixed, I'm likely to overload the stringification of many of my objects but would never overload the numeric value of them so, if that were to happen, eq would become unreliable while == would continue to work. I think it makes sense to have objects return human-readable stringifications but don't see much use for numeric values of objects except as already provided for.)

      Anyway, I wanted to point out that in (tye)Re: Creative use of pack/unpack I heavily abuse the numeric value of references in a way that I think only the insane would take seriously. In (tye)Re2: resurrecting objects? I hint that even more insanity is technically possible, though not even I have been insane enough to actually try that. ;)

              - tye (but my friends call me "Tye")
[reply]
[d/l]
        Numbers are by definition objects which we can add, subtract, increment, etc. I recall from thirty years ago that some guy named Peano generated the number system using these operations according to his Peano's Postulate.

        That which cannot be added, incremented, etc. is not a number. A reference cannot be added, incremented, etc. Therefore a reference is not a number. The numeric comparison operator '==' is for comparing numbers. A reference is not a number. Therefore Larry and company should not permit the use of '==' to compare references, only numbers.

        I also do not understand the statement that using '==' is more efficient when comparing references than is 'eq'. It seems to me that what we have here is an "amplifier that goes up to 11" type of argument (for those who have seen the film Spinal Tap.) Larry could simply take the algorithm that he uses for the '==' operator and use it for the 'eq' operator when comparing references (just as that amplifier maker could have taken whatever loudness he called 10 and instead called it 11.)

        "Working on a sex farm. Poking your hay."—David St. Hubbins and Nigel Tufnel, "Sex Farm," Smell the Glove.
[reply]

In Section Seekers of Perl Wisdom