|Iterator email@example.com (2002-05-23)|
|Re: Iterator firstname.lastname@example.org (2002-05-27)|
|Re: Iterator email@example.com (Randall Hyde) (2002-05-27)|
|Re: Iterator firstname.lastname@example.org (Joachim Durchholz) (2002-05-27)|
|Re: Iterator email@example.com (Hans Aberg) (2002-05-27)|
|Re: Iterator bobduff@shell01.TheWorld.com (Robert A Duff) (2002-05-31)|
|From:||"Robert A Duff" <bobduff@shell01.TheWorld.com>|
|Date:||31 May 2002 23:06:54 -0400|
|Organization:||The World Public Access UNIX, Brookline, MA|
|Posted-Date:||31 May 2002 23:06:54 EDT|
"Randall Hyde" <firstname.lastname@example.org> 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
Return to the
Search the comp.compilers archives again.