On Wed, 29 Nov 2000, Conrad Schneiker wrote:

> 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 

That is what I was trying to achieve.  I have only seen 
this (a < b < c, etc) in Icon, and I think it is a good thing...

> 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".

This works because find("or", sentence) acts like a generator.
Therefore the whole expression [write(...)] gets re-evaluated
in Icon.  This is not a property of the relational operator
as such, and I was not proposing to add generators to Ruby.

[Adding generators to Ruby would involve preserving state
between calls of a function, and with bindings would be
possible, but since we have yield, there seems to be little
need to add suspend as well. It _would_ allow a function
to RETURN successive values, but people may find the
additional complexity that this creates too surprising.]

> 
> 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 

Not really, it is the behaviour of sentence.index that would have to 
change to make this like Icon -- it would have to store its
state between calls.  I think it is too big a change, myself.

> of the elegant and powerful Icon string scanning expressions.
> 
Yes, I like that feature, and have some ideas about it.

> Conrad Schneiker
> (This note is unofficial and subject to improvement without notice.)
> 
	Hugh
	hgs / dmu.ac.uk