.equals() should return false if the params aren't the same type

[dbp]

Examples include 2.equals(true), etc

[jpolitz]

(Right now this is a runtime tag-checking/contract error)

[jpolitz]

Note --- this (just) requires tweaking the mk-prim-fun macro to allow for else cases that don't error. We may just want two versions, one that says "bad prim" if you do e.g. "1" < 2, and one that yields a default value like false for 1 == "2".

[blerner]

Has anything happened on this?  Can I please remove my (try: x == y
except(_): false end) drivel now?
If we truly need a way to distinguish "these are not equal" from
"buddy, these aren't even the same type, what're you trying to do?",
I'll suggest two strawman proposals:
1) Add a ? suffix to indicate you don't care about types and
comparisons should never raise errors; the un-suffixed versions can
throw contract errors.  E.g., "1" == 1 --> contract error, but
"1" ==? 1 --> false.  The operators would look like 
     a <? b >? c <=? d >=? e ==? f <>? g +? h -? i
*? j /? k
2) The un-suffixed operators indicate you don't care about types and
comparisons should never raise errors; add a ! suffix to indicate
you do.  So, "1" == 1 --> false, but "1" ==! 1 --> contract
error.  The operators would look like 
    a <! b >! c <=! d >=! e ==! f <>! g +! h -! i
*! j /! k
(I'm not sure that suffixed versions of arithmetic operators make
sense; I included them for visual completeness.)  To my eye, they're
both ugly, but I could see myself using the !-suffixed ones for
comparison operators when I really cared for dynamic brand checks
but didn't want the syntactic hassle of writing a case statement
instead...On 6/11/2013 4:43 PM, Joe Politz wrote:

  Note --- this (just) requires tweaking the mk-prim-fun
    macro to allow for else cases that don't error. We may just want
    two versions, one that says "bad prim" if you do e.g. "1" <
    2, and one that yields a default value like false
    for 1 == "2".
  —
    Reply to this email directly or view
      it on GitHub.

[jpolitz]

== has desugared to equiv for a while now, which does the catching for you,
so you shouldn't need that code in your application anymore.

On Tue, Jun 18, 2013 at 9:47 AM, Ben Lerner notifications@github.comwrote:

Has anything happened on this? Can I please remove my (try: x == y
except(_): false end) drivel now?
If we truly need a way to distinguish "these are not equal" from
"buddy, these aren't even the same type, what're you trying to do?",
I'll suggest two strawman proposals:

1. Add a ? suffix to indicate you don't care about types and
   comparisons should never raise errors; the un-suffixed versions can
   throw contract errors. E.g., "1" == 1 --> contract error, but
   "1" ==? 1 --> false. The operators would look like
   a <? b >? c <=? d >=? e ==? f <>? g +? h -? i
   *? j /? k
2. The un-suffixed operators indicate you don't care about types and
   comparisons should never raise errors; add a ! suffix to indicate
   you do. So, "1" == 1 --> false, but "1" ==! 1 --> contract
   error. The operators would look like
   a <! b >! c <=! d >=! e ==! f <>! g +! h -! i
   *! j /! k
   (I'm not sure that suffixed versions of arithmetic operators make
   sense; I included them for visual completeness.) To my eye, they're
   both ugly, but I could see myself using the !-suffixed ones for
   comparison operators when I really cared for dynamic brand checks
   but didn't want the syntactic hassle of writing a case statement
   instead...On 6/11/2013 4:43 PM, Joe Politz wrote:

Note --- this (just) requires tweaking the mk-prim-fun
macro to allow for else cases that don't error. We may just want
two versions, one that says "bad prim" if you do e.g. "1" <
2, and one that yields a default value like false
for 1 == "2".

—
Reply to this email directly or view
it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-19612041
.

[jpolitz]

Closed by 559fa2d