Re: Iterator

"Robert A Duff" <>
31 May 2002 23:06:54 -0400

          From comp.compilers

Related articles
Iterator (2002-05-23)
Re: Iterator (2002-05-27)
Re: Iterator (Randall Hyde) (2002-05-27)
Re: Iterator (Joachim Durchholz) (2002-05-27)
Re: Iterator (Hans Aberg) (2002-05-27)
Re: Iterator (Robert A Duff) (2002-05-31)
| List of all articles for this month |

From: "Robert A Duff" <>
Newsgroups: comp.compilers
Date: 31 May 2002 23:06:54 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 02-05-125 02-05-132
Keywords: design, storage
Posted-Date: 31 May 2002 23:06:54 EDT

"Randall Hyde" <> writes:

> I'm not familiar with iterators in Sather, but if they're like the
> ones in CLU then you don't need two stacks, you can use "resume
> frames" to accomplish this (see "Programming Language Concepts by
> Ghezzi & Jazayeri).

First, isn't this really two stacks, in a way -- the iterator's stack
being allocated within the stack frame of the caller?

Sather iterators are more powerful that CLU's in that Sather has a way
to run two or more iterators in lock step. For example, suppose a
compiler wants to match up formal parameters with actual parameters.
You have an iterator for looping through a formal parameter list, and a
different iterator for looping through an actual parameter list. (The
two kinds of lists might be completely different data types, represented
in different ways.) In Sather, you can write a loop that invokes both
iterators -- each iteration of the loop is looking at the N'th formal
and the N'th actual. So in Sather, you need to keep the state of
multiple iterators around at the same time for the same loop. This
requires some sort of coroutine-like mechanism. CLU doesn't do that

- Bob

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.