Though it kind of bothered me at first, now I really like the way python handles the semipredicate problem, which is to throw an exception at the end of the iteration rather than try to return a specific value (which may end up as part of an iterable). Besides, I think that python's yield would have been one of the easiest ways to solve this problem. For those who don't know about yield it stops the execution of a function (it can be in the middle of an infinite loop) which will be resumed when the next value is fetched. Perl 6's lazy lists can be used in a similar way according to its faq

As for understanding my code, the concept is actually fairly simple (well, to me it is, but I'm used to working with closures). I started with a flat list iterator: a closure that holds the array and the current index. In the nested list version, each flat list iterator has a children which is an iterator for the current element if the element itself is an array. You could see it as equivalent to this:

def next:
  if array[index].isAnArray() and array[index].hasNext()
    ret = array[index].next();
  else
    ret = array[index]
  endif
  index++
end
[download]

parent.next()
  child.next()
    grandChild.next()
      ...
[download]

»»» This post is about alpha status Perl 6, not rock solid Perl 5 «««

Though it kind of bothered me at first, now I really like the way python handles the semipredicate problem

P6's design for run-time warnings, errors and delayed exception handling is anchored on Failure objects:

... dynamic context can determine the treatment of failures that in other languages would always throw exceptions. This gives Perl 6 programs the flexibility to handle exceptions either in-band or out-of-band. It is particularly important to be able to handle exceptions in-band when you are trying to perform parallel operations, so that the failure of one computation does not result in fratricide of all its fellow computations. (You can think of this as analogous to the way NaN propagates through floating-point calculations.)

(from the design doc / section S02 / Undefined types)

A simple use of this flexibility is the 'fatal' pragma that controls whether "built-ins ... automatically throw exceptions on failure" in its dynamic scope:

use fatal;
[download]

The fail function responds to the caller's use fatal state. It either returns an unthrown exception, or throws the exception. Before you get too happy about this pragma, note that Perl 6 contains various parallel processing primitives that will tend to get blown up prematurely by thrown exceptions. Unthrown exceptions are meant to provide a failsoft mechanism in which failures can be treated as data and dealt with one by one, without aborting execution of what may be perfectly valid parallel computations. If you don't deal with the failures as data, then sink context will automatically throw any unhandled Failure that you try to discard.

In any case, the overriding design principle here is that no unhandled exception is ever dropped on the floor, but propagated outward until it is handled. If no explicit handler handles it, the implicit outermost exception handler will eventually decide to abort and print all unhandled exceptions passed in as its current @! list.

It is possible to fail with a resumable exception, such as a warning. If the failure throws its exception and the exception resumes, the thrower by default returns the null string ('') to whatever caused the failure to throw its exception. This may be overridden by attaching a .resume_value to the warning. Hence numeric coercions such as +"42foo" can be forced to return 42 after issuing a warning.

(from the design doc / section S04 / Exceptions)

»ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}

> Perl 6's lazy lists can be used in a similar way according to its faq

search for "gather / take"

edit

> which is to throw an exception at the end of the iteration rather than try to return a specific value

you can use goto for a poor man's solution here.

Cheers Rolf

PS: Je suis Charlie!