[#4766] Wiki — "Glen Stampoultzis" <trinexus@...>

21 messages 2000/09/04
[#4768] RE: Wiki — "NAKAMURA, Hiroshi" <nahi@...> 2000/09/04

Hi, Glen,

[#4783] Re: Wiki — Masatoshi SEKI <m_seki@...> 2000/09/04

[#4785] Re: Wiki — "NAKAMURA, Hiroshi" <nakahiro@...> 2000/09/05

Howdy,

[#4883] Re-binding a block — Dave Thomas <Dave@...>

16 messages 2000/09/12

[#4930] Perl 6 rumblings -- RFC 225 (v1) Data: Superpositions — Conrad Schneiker <schneik@...>

Hi,

11 messages 2000/09/15

[#4936] Ruby Book Eng. translation editor's questions — Jon Babcock <jon@...>

20 messages 2000/09/16

[#5045] Proposal: Add constants to Math — Robert Feldt <feldt@...>

15 messages 2000/09/21

[#5077] Crazy idea? infix method calls — hal9000@...

This is a generalization of the "in" operator idea which I

17 messages 2000/09/22

[#5157] Compile Problem with 1.6.1 — Scott Billings <aerogems@...>

When I try to compile Ruby 1.6.1, I get the following error:

15 messages 2000/09/27

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

From: Aleksi Niemel<aleksi.niemela@...>
Date: 2000-09-28 00:53:10 UTC
List: ruby-talk #5167
Hal confesses:
> However, I'm still puzzled by two things:

Your persistence is no suprise for me, I know there's people like that. On
your case I can say warmheartedly that's a good thing. Keep it that way.

> 1. Why do we say "case other; when receiver" and not
> "case receiver; when other"?

This is good question. And I have to say the latter is more natural to me to
think, understand and remember.

Please consider thread starting from [ruby-talk:3801] (blade was down so I
didn't make direct link). That thread discusses about my proposition to set
case-when free from forced === usage touching this issue of
receiver.===(other). (Additionally you see neat hack from Dave.)

> 2. Why is the argument order for pattern === string opposite
> from the order for string =~ pattern?

Hmm.. pattern === string is clearer form of pattern.===(string). =~ on the
other hand is a Perl han[dg]over. I think the reasons they exists are
probably coming from different worlds, and partly controversial.

> It almost (I'm not serious here, not entirely) makes me want 
> to propose
> two more operators ==> and <== which point to the receiver... then
> the === could be used for symmetrical cases.

While I'm not sure at all the feasibility of these proposition, I have to
greet them with joy. case-when -construct clearly needs some clarification
and maybe even generalization.

Would you dare to show some examples?

I'm not sure what would be proper way to express which method should be used
for matching, but maybe something like

  kCASE compstmt, id_for_method
  case_body
  kEND

could work. My premise here's that the parser would survive of separation
task of current case form, and "list-form", which specifies method to use.
This leads to the code like

  case other, :<==
  when recv          # same as   if recv.<==(other)
  end

# class Receiver
#   def <==(other)
#     other.==>(recv)
#   end
#   def ==>(other)
#     self.===(other)
#   end
# end

But allows one to write something like:

  case regexp, :match
  when string
    puts "string #{string} matches"
  when "foo"
    puts "foo matches"
  end

If one wants to go further, the :method id could be replaced with a block,
and I'm sure there are other ways to extend the idea more.

Thanks for your ideas.

	- Aleksi

In This Thread

Prev Next