On Thu, Feb 26, 2009 at 3:56 PM, Jonathan S. Shapiro <[email protected]> wrote:
> So I was scratching my head about iterators, and I don't see why
> something like the following would not work.
>
> An iterator is a structure or capsule having methods value(), next(),
> and hasNext().  value() returns the value at the current "position".
> next() returns an iterator over the "rest" of the collection.
> hasNext() tests for termination.

Cool.  I had forgotten about the object support.

> Given a construct like this, "forall" is simply a procedure that
> applies a function to all values:
>
>   forall: (fn (by-ref (Iterator 'a)) (fn 'a -> ()) -> ())
>
> I'ld have to scratch my head a second about "fold", but I'm sure it's
> comparably straightforward. The main issue here is to ensure that
> appropriate inlining happens so that the higher-order nature of the
> construct gets compiled out appropriately.

Unfortunately, since there is no primitive language construct for
looping other than tail-recursion, efficient compilation of any higher
order construct like forall requires partial specialization, not just
inlining.  It might not be too bad since the partial specialization is
almost inlining in the sense of being inlining that results in tail
recursive structures, but still scary.

I think that as a user of the language, I would only feel secure if I
could be completely sure that the important usages of forall were
partially specialized.  Otherwise I would be frightened into writing
out the tail-recursion form in important places.  This means either
(1) programmer annotations or (2) partially specialize every
occurrence of forall.  Neither one is very attractive.

Actually, a syntactical for-loop construct _is_ a programmer annotated
version of forall, so that might be the way to go.  The translation is

    for i in a: <body>

to

    let f it =
        let i = it.value() in
            <body>
        if it.hasNext():
            f it.next()
        else
            () in
    f (iterator a)

Again, that's the same code you'd get by partially specializing
forall, but it avoids the issue of knowing which forall to specialize.
 Pure inlining (not partial evaluation) suffices to reduce it the rest
of the way.

Geoffrey

P.S.: I'll stop writing code in ML syntax once I know the real syntax :)
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to