[REBOL] Re: for bug?
From: joel:neely:fedex at: 17-Jun-2002 13:51
On Monday, June 17, 2002, at 09:47 AM, Romano Paolo Tenca wrote:
> It seems to me that the solution is a pre-conditon test and a
> test ...
> I think that an overflow error! is the right thing to do also with
> byte (char). Because this is exactly what is happening with a char in
> 'for: it
> can't add 1 to 255 without overflow.
> I agree: the problem is also how Rebol handles limit values.
> Orthogonality is
For a peek at a different (very clean) strategy to handling loops, I
suggest a peek at the "iterator" concept in Python 2.2 described at
In brief, when you write something resembling (I'll use REBOL-ish
rather than trying to explain Python syntax):
foreachin gleep bletch [...]
the variable GLEEP would iterate across all values offered by the object
The mechanism, however, is seriously cool and scalable. The object
BLETCH merely has to meet two requirements:
- there must be a /NEXT refinement which is invoked for every pass to
the next element to use,
- invoking BLETCH/NEXT must result in a StopIteration exception when
no next element.
Since FOREACHIN is simply looking for the StopIteration exception as the
for "there are no more values", an object can do whatever makes sense to
up the next value (or signal completion). This allows the programmer to
new objects and still use them with the standard iterative loop
no extra overhead.
Since RANGE (remember that I'm still using REBOL notation) returns a
object which already has the required behaviors, and "file" objects also
how to behave, one uses
foreachin foo range 1 100 [...]
foreachin line %glumpf.data [...]
to do just what you think.
Anyway, the idea of having a standard interface that allows extensions
type-specific scenarios, such as we've been discussing with char!) to
consistently with looping seems quite nice.