[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ranade: Eval etc.]



    Date:    Tue, 8 Nov 83 16:52:08 EST
    From:    Abhiram Ranade <Ranade>
    Subject: Eval etc.
    
    Suppose you have two lists '(a b c d e f) and '(p q r s t u). How
    do you perform:
    
        (set a 'p)
        (set b 'q)
        (set c 'r)
            .
            .
            .
    
T is different from LISP in that symbols are different from variables.
What you suggest doesn't make any sense because the part of your program
which is doing the SET's can't in general know what variables the
symbols refer to, because it doesn't have the lexical context of the
other part of your program which created the list of symbols.

I suggest that you avoid creating lists of symbols when what you probably
want is lists of locations.  That is, instead of doing:

    (LIST 'A 'B 'C ...)
    
or
    
    '(A B C ...),
    
try:

    (LIST (LOCATIVE A) (LOCATIVE B) (LOCATIVE C) ...)
    
A locative is similar to what is called a "pointer" in some other
languages.

Then to do the assignments, do something like

    (WALK (LAMBDA (LOC VAL)
            (SET (CONTENTS LOC) VAL))
          L)
          
assuming that the variable L is your list of locatives.


    and also:
    
        (set a  p)
        (set b  q)
        (set c  r)
            .
            .
            .
    
Here, you would have two lists of locatives, say L1 and L2, and you
would do:

    (WALK (LAMBDA (LOC1 LOC2)
            (SET (CONTENTS LOC1) (CONTENTS LOC2)))
          L1
          L2)
          

There are ways to implement this kind of thing using EVAL, but in
addition to the problem of figuring out what environment to pass to
EVAL, EVAL is much more expensive than LOCATIVE + CONTENTS.  EVAL
is a very powerful, specialized tool which is inappropriate in most
ordinary programming applications, such as this one.  Would you use
a machine gun to open a can?  In LISP, using EVAL might often
be the right thing.  In T, it almost never is.

There is a bug in LOCATIVE whereby TC complains if the variable to
which you're getting a locative to is a LAMBDA-bound (local) as opposed
to LOCALE-bound (global) variable.  I will fix this as soon as someone
complains about it.  I don't think this will be a problem for the
kind of thing you're doing.