FAQs for Machine Problem 4

Notice that what's called "pack" and "unpack" in this faq is the same as "pair" and "unpair" in the problem. As you read these, don't w orry if you don't understand the questions. Remember that these students are struggling with the concepts, so their questions may be pretty hard to understand.
  1. Testing the translator
    >> 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.
  2. translation-of and environments
    >> 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.
  3. Do we need to deal with cond and allof?
    >> 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
  4. What happens when?
    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.
  5. Are procedure names considered variables?
    >> 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
    So when you are done you should have no names whatsoever in your
    translated code.
  6. What about procedure names in a letrec?
    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
      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.
  7. Multiple Arguments?
    > 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. 
  8. extend-env vs. extend-env-recursively
    > 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