From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2001-03-05T22:12:16+09:00
Subject: [ruby-talk:12011] Re: RCR Summary 02/16/01 -suspend

On Sat, 17 Feb 2001, Dave Thomas wrote:

> Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
> 
> > Yes, it was me.  "wants" should be "wants discussion on" -- I've not
> > really got to grips with Icon enough to say how useful this would be,
> > or if/why it might be better, but I find the idea of a function returning
> > a succession of values to be 'clean', 'aesthetically pleasing' etc --
> > i.e reasons hard to rationalise.  I've nothing against yield, by the way.
> 
> What triggers the creation of a new set of state for this function:
> does each call site get its own, or is it based on scope. For example, 
> say we had a function 'fib' that returned successive Fibonacci
> numbers.
> 
>    loop do
>      n = fib()
>      break if n > 1000
>      puts n
>    end
> 

I got round to exploring the Icon book last night (see:
http://www.cs.arizona.edu/icon/ib3.htm
"The Icon Programming Language", 3rd Edition, Griswold and Griswold.
for book details)

and the implementaion is trickier than I thought.  
suspend is very much tied in to Icon's expression evaluation system, and
to its notion of success and failure.

Failure in Icon is not fatal, usually, it just tends to leave state unchanged.
Every expression succeeds or fails.  If an expression fails, an attempt is
made to re-evaluate it to see if any generators will produce more values.
So it is when the procedure is re-evaluated that suspend comes into play.
Otherwise, when the expression has been completely evaluated the suspended
state in any procedures is forgotten, and any new calls start afresh.

See page 19 of the book.

Now, this leads to two possible routes for this RCR.

1)  This notion of suspend is too Icon specific, being tied up with goal-
    directed execution etc, to be translated cleanly into Ruby.  On this
    basis the RCR should be mercifully slain.

2)  Although an exact translation is not possible, the aesthetics of this
    are worth having, so an implementation based on scope for example, 
    would still be useful. In which case:

> Then we decide to refactor this to get rid of the break:
> 
>    n = fib()
>    while n <= 1000
>      puts n
>      n = fib()
>    end
> 
> Would you expect this to work, or would get expect to get an
> additional '1' at the start of the sequence?
> 
    There would be an extra 1.  So we could rewrite it as:

     n = fib()
     while n <= 1000
       n = fib()
       puts n
     end

    Which would fix that.

> Regards
> 
> 
> Dave
> 

So, is 2 worth persuing, or is it too confusing?  I think it fits in with
other scoping rules, and I think it may fit with eval's 'binding' thingy, but
I only have a hazy conception of what a binding REALLY is, so I'm not sure
if it is quite the same at all.

	Hugh
	hgs@dmu.ac.uk