Hi Joel, >Sort of like iterating DO/NEXT with an additional check for REST ? > > > Yes.
>I pondered doing something with DO/NEXT a while back, but gave up in >frustration (I hope you're smarter and/or more patient than I ;-) as >I want to be able to write expressions/functions more sophisticated >than a single block, but still have interruptability. For example: > > eval [ > foreach line read/lines %somefile [ > print line > rest > ] > ] > >Or > > interruptableFunction: func [aLine [string!]] [ > print aLine > doSomethingInteresting aLine > rest > ] > > eval [ > foreach line read/lines %someOtherFile [ > interruptableFunction line > ] > ] > >You said "takes a block" so I inferred that things such as the above >(nested blocks, including function evaluation) are currently out of >reach. Am I too pessimistic? > > Yes and no. Right now, if rest is returned as value of a subexpression, this works nicely. All three code pieces work, but I because I am patching all looping and conditional constructs (to set all kinds of hidden flags for rest and eval). More patient I guess :-) >If I have to do all the work of managing e.g. loops and other "control >structures", including functions, I think I'd probably want to just go >ahead and evert the code into a task object (per the article on >REBOLforces) with a STEP method that does some meaningful (but not over >long) piece of work and then saves state and returns control. > > I agree. Transparancy is the way to go. Once I get some stuff in a decent state I'll need others to test it and see if it works "naturally" --Maarten -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
