Subject: Re: [CSG111] CSG111: MP4 Extend-Env-Rec?
From: Wendy (wendybeth.minton@gmail.com)
Date: Sun Feb 26 2006 - 21:29:21 EST
Hi,
In the assignment, it asks for the test cases from mp3 to be run. However,
we are missing a bit f functionality. There was already an email saying we
don't have to worry about all-of, cond, and, or, not. But what about
addition, mutliplication, and integer divsion? I'm assuming these should not
be implemented either. So, should we just exclude all test cases for these?
Also, I'm having a lot of trouble with letrec. I have no idea how to make
recursion happen. The examples from lecture three are building a data
structure, and this method makes sense. But I am just not seeing how this
can be done with a list. My code is currently dying after the first run of
the procedure. The issue is that the environment is storing the value of the
first run of the procedure, and then nothing else. I guess the issue I have
is I dont see how to take the closure. When you said closure in your email,
were you talking about the "closure" function in the notes? At this point
any help would be great as I am definitly not understanding this.
Thanks,
Wendy
On 2/26/06, Therapon Skotiniotis <skotthe@ccs.neu.edu> wrote:
>
> On Sun, Feb 26, 2006 at 05:23:20PM -0500, Wendy wrote:
> > Hi,
> >
> > I'm having an issue understanding the difference between extend-env and
> > extend-env-recursively. I'm looking at the code from lecture three,
> where
> > both these are not procedures, but types of environments. The only
> > difference I'm seeing is that extend-env-recursivily is adding a proc
> body,
> > and extend-env does not. Is that the only difference, or does the use
> of
> > "extend-env-recursivly" imply that recursion is occuring? i
>
> That is one difference sure. What is important is also how apply-env deals
> with extend-env-recursivily. Have a look at that.
>
> > I'm assuming that
> > the actual recursion is handled by a call to value-of on a procedure,
> > thus creating a nesting of such calls to value-of. So the addition of a
> > proc in an extend-env-recursivly is more or less a place holder in the
> > call stack. Is this correct, or am I missing something here?
>
> I find it easier not to think about call stacks for this. Evaluation of a
> recursive call is handled just as any other call, that is we look up the
> environment to find out what the operator and the operands of a call are.
> The difference in a recursive call is that the operator we are looking for
> is the closure that represents the function we are currently evaluating.
> So
> we need to keep that around in the environment.
>
> Your description seems to be on the right path.
>
> HTH,
>
> -- Theo
>
>
> _______________________________________________
> csg111 mailing list
> csg111@lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/csg111
>
_______________________________________________
csg111 mailing list
csg111@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/csg111
This archive was generated by hypermail 2b28 : Tue Feb 27 2007 - 19:00:11 EST