[ruby-talk:5146] Re: Types and ===

Hi,

Hal writes:

# Well, Aleksi,
#
# You and Conrad are certainly following the
# Principle of Greatest Surprise.

I'm have no idea how you drew that connection in my case, especially since
both of you omitted to quote, mention, or summarize most everything of
relevance in my original note, and both of you seemed to miss its main
point.

# But seriously, folks!

I was serious--since this involves case statements, I gave you a list of
example relations that many AI workers deal with in doing case-based
reasoning (hope that's not 2 repundant; all 3 puns intended :-), among
many other things. AFAIK this sort of usage might one day escape the
confines of LISP/CLOS-like languages and exponentially mass produce
themselves in Ruby case statements. (Just my 9K cents worth. :-)

# Can we tweak the universe so that x===y
# always means y===x? Any reason why we
# shouldn't?

Or any reason why maybe we can't? See below....

# Ask yourself this: Why is the case limb expression
# the receiver instead of the tested expression being
# the receiver? (I.e., we say "case other; when receiver..."
# not "case receiver; when other...")
#
# This means that when x is a string and y is a pattern,
# x =~ y means y===x. Why not x =~ y means x===y?

Well, if that were all you wanted to change, I don't have any particular
problem with that. (But I haven't had time to think about it, either.)

# Or why not (as I am really thinking) have both mean
# the same thing?

Because many of the world's common prepositional and similarity relations
(if you are going to include them in the "===" realm) just don't work that
way in general (special cases notwithstanding); hence my original question
(which both of you effectively neglected to mention or answer).

But here is a still more general question: why would you want to preclude
"===" from potentially being *any* suitable 2-place predicate method
whatsoever?

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)