[#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:6618] Re: Relational operators in Ruby.

From: "Conrad Schneiker" <schneik@...>
Date: 2000-11-29 07:55:40 UTC
List: ruby-talk #6618
Dave Thomas writes:

# "Conrad Schneiker" <schneik@us.ibm.com> writes:
# 
# > While I think the idea of supporting Icon-style goal-directed 
evaluation 
# > is probably a very worthy and powerful capability to add to Ruby, I 
would 
# > prefer to see such a "mode" be more explicitly indicated. I think this 

# > would facilitate "human pattern recognition" with respect to reading 
Ruby 
# > code, and would largely avoid a potential big source of likely 
# > confusion--especially for Ruby users/fans at the "sub-master" level, 
which 
# > is probably the predominant population for successful languages with 
large 
# > followings, such as Perl and Python. The original proposal seems 
(IMHO) a 
# > little too close to the overly context sensitive (or as some say, the 
# > "read only" or "self-encrypting") character of Perl code.
# 
# Conrad:
# 
# A worthy goal, I agree, but can you think of any time where this
# scheme would confuse the neophyte (objection: calls for speculation)?
# I was thinking it was actually quite nice because it sits fairly
# transparently on top of the existing semantics, but I'm sure I missed
# something.

Maybe I am taking something that was only intended to be *somewhat* 
"Icon-like" as being intended to be *seriously* "Icon-like".

Anyway, it seems to me that you get pure "Ruby-like" behavior in the 
trivial cases (e.g.: a > b) and somewhat "Icon-like" behavior in 
non-trivial cases (e.g.: a > b > c). Moreover, without distinguished 
operators, I don't see how things like the following example from 
(http://www.cs.arizona.edu/icon/docs/ipd266.htm) could work. The Icon 
code,

    sentence := "Store it in the neighboring harbor"
    write(5 < find("or", sentence))

prints "23".

I think an approximately equivalent Ruby program is,

    sentence = "Store it in the neighboring harbor"
    puts (5 < sentence.index("or"))

which prints "false", but which we would like to print "23". If we had 
(say) ':<', ':>', and so on, for Icon-like relational operators, then 
(AFAIK), you could have things like,

    a :> b :>  c
    puts (5 :< sentence.index("or"))

both work as expected. And (AFAIK), this approach would generalize to much 
of the elegant and powerful Icon string scanning expressions.

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

In This Thread

Prev Next