[#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:5121] Re: Crazy idea? infix method calls

From: "Hal E. Fulton" <hal9000@...>
Date: 2000-09-26 02:35:25 UTC
List: ruby-talk #5121
----- Original Message ----- 
From: Louis A. Mamakos <louie@TransSys.COM>
To: ruby-talk ML <ruby-talk@netlab.co.jp>
Sent: Monday, September 25, 2000 7:12 PM
Subject: [ruby-talk:5119] Re: Crazy idea? infix method calls


> If most of the motivation to pursue this is to have a more "natural"
> expression for set membership (e.g., an "in" infix operator), then
> could you just use a method called "contains" instead which wouldn't
> require another mechanism.
> 
> e.g.,  y.contains x 
> 
> which I think reads as naturally as "x in y".

Matter of opinion.

Sets are a fairly rare and unimportant application, I think.

I am more interested in the generalized idea of a container,
whether it be a set, list, tree, graph, whatever.

And the two reaons I like the "x in y" notation are:
   1) operands are reversed
   2) dot is unnecessary

After all, why is there a "for" loop, when all it does is call the "each" 
iterator? We could use "each" instead. We use "for" because it has
a nice feel to it, though the parser would be simpler without it.
 
> I just worry that more syntactic sugar which makes figuring out
> precedence and evaluation order may not really help in the end.

Point taken... but if precedences are chosen wisely (unlike, for
example, Pascal or arguably C) they are hardly even an issue.
Just my opinion.

Hal




In This Thread