[#6363] Re: rescue clause affecting IO loop behavior — ts <decoux@...>

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

17 messages 2000/11/14
[#6367] Re: rescue clause affecting IO loop behavior — David Alan Black <dblack@...> 2000/11/14

Hello again --

[#6582] best way to interleaf arrays? — David Alan Black <dblack@...>

Hello --

15 messages 2000/11/26

[#6646] RE: Array Intersect (&) question — Aleksi Niemel<aleksi.niemela@...>

Ross asked something about widely known and largely ignored language (on

23 messages 2000/11/29
[#6652] RE: Array Intersect (&) question — rpmohn@... (Ross Mohn) 2000/11/29

aleksi.niemela@cinnober.com (Aleksi Niemel) wrote in

[#6723] Re: Array Intersect (&) question — Mathieu Bouchard <matju@...> 2000/12/01

> >Use a hash. Here's code to do both and more. It assumes that

[#6656] printing/accessing arrays and hashes — raja@... (Raja S.)

I'm coming to Ruby with a Python & Common Lisp background.

24 messages 2000/11/30

[ruby-talk:6572] Re: Relational operators in Ruby.

From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2000-11-24 10:18:57 UTC
List: ruby-talk #6572
On Fri, 24 Nov 2000, Dave Thomas wrote:

> Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
> 
> > I have been thinking about relational operators in Ruby, (which is 
> > why I have ben messing about with alias_method and so on!) and I 
> > have written a small page explaining my thoughts on this.
> 
> Would '==' produce it's RHS on success? If so,
> 
>    x == nil
> 
> would always be false.

This is a tricky one.  This doesn't come up in Icon, because it has
the concept of success and failure of statements and expressions. This
expressin's equivalent in Icon would return the right hand side, but it
would succeed. (Expressions that fail in Icon leave state unchanged.)

I think that == and != woould have to be excluded from this scheme,
because any sensible way of working around the nil/false problem
would create other difficulties in the longer expressions, or
difficulties with existing code, and consistency.  Also, these
would not be used in the mathematical type expressions that are the
strongest case for this change.  I mean, you do not see expressions
like 'k < x == m' or 'k >= x != m', and not with the same semantics
as 'k < x <= m'.  You may see 'k < x where x == m' but that is quite
different -- it is really '(x == m) && (k < x)'.

So I'd just apply my scheme to <, >, <=, >=, and I would not even
apply it to <=>.
 
> I'm planning to keep my eyes open as I code to see how often this
> would be useful for me.
> 
> Nice proposal.
> 
Thank you.
> 
> Dave
> 
> 
	Hugh
	hgs@dmu.ac.uk


In This Thread

Prev Next