>> Do we need to use the standard test suite to test both translation and >> evaluation procedures OR only the evaluation procedures? Thanks You should use the standard test suite to evaluate the COMBINATION of the translation and evaluation procedures. In addition, you should print out the results of your translation procedure so the grader can see that it doesn't have any var-exps.
>> Am I correct when I assume that the problem about changing each
>> variable to its lexical address, has nothing to do with environments?
No. You should turn in a single implementation with a translator and
a matching interpreter.
>> Do we need to put in the changes we did so that cond and/or allof works? >> or is that something that we can safely ignore? No, you don't need to put cond or allof in your lexical address calculator.
A student wrote: > I'm struggling with the pack and unpack implementation in the lexical > translator. > How is the 'pair' datatype represented after translation... > I'm actually so confused it is hard to formulate a question. > > Basically, I think I can't figure out whether I should build and > destructure my pair before or after translation. and the TA replied: > The actual creation of pair objects is going to happen after > translation. When you run the translator, the only thing you're doing is > getting rid of all of the variables in the system. > You have to explore the expressions inside the pack to check for > variables and bind them to their lexical scope, but the pack command > itself doesn't create any new layers of lexical addresses. > Where the fun begins is when you use the unpack command. That creates a > new layer of lexical addresses with the two variables described in the > unpack statement bound there. Anything within the scope there needs to > take into account that layer of addresses. > Hopefully this clarifies things a little.
>> In problem 2 of MP4, can we use the names of >> procedures literally, or do we need to work only with >> their addresses? Also, we were assuming that it's not >> legal to work with the arguments to the procedures- is >> that correct? I don't know what you mean by "work with", but yes, procedure names are definitely variables-- they are no different from any other variable. So when you are done you should have no names whatsoever in your translated code.
MW> I don't know what you mean by "work with", but yes, procedure names MW> are definitely variables-- they are no different from any other MW> variable. >> We were puzzled because we weren't if we need to keep >> track of both the procedure address and the address of >> the arguments. For example, if we've got >> even(x) >> it sounds like we need to compute both the address of >> even and of x. Is this similar to evaluating a >> procedure, or should we expect to write a new kind of >> translator for the left side of a function expression? In the expression letrec even(x) = if zero?(x) then 1 else (odd sub1(x)) odd(x) = if zero?(x) then 0 else (even sub1(x)) in (odd 13) the even and the x in even(x) are both variable _declarations_, not uses. So they don't get replaced by anything: they are like the bound variables in a let.
> Does letrec for this assignment have to be able to define multiple > procedures in one letrec call? No, one is enough. > Can each procedure have more than one argument? No, one argument is enough.
> 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? 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.
Last modified: Mon Feb 12 20:26:13 EST 2007