[Top][All Lists]

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

Re: eval

From: Dirk Herrmann
Subject: Re: eval
Date: Wed, 7 Feb 2001 19:23:28 +0100 (MET)

On 7 Feb 2001, Marius Vollmer wrote:

> Hmm, what about simply `primitive-eval', to go with `primitive-load',
> etc.

Well, personally I don't like these names:  They don't tell much about
what the functions actually do.  Or do you know from primitive-load in
which way it differs from 'load'?  I don't.  I'd have to look into the
documentation.  (OK, looking into the docs is sometimes just the right
thing :-)  But, if it is possible to find a name that helps to get the
right idea at once, this should always be preferred.  And, 'primitive' has
a couple of disadvantages:  Does it mean that this function is actually a
primitive (i. e. implemented in C), while the other one is a closure?  Or
does it mean that it provides a more "basic" functionality?  If so, it is
still open to interpretation what a more basic functionality means:  
Primitive eval could as well mean to evalutate code "as it is", i. e.
without applying macro transformation first.  Maybe there are more
interpretations of what a "primitive" eval would do.

But, I agree with you that "eval*" is also not a good choice:  It has the
same problems with respect to explicity, and in addition is likely to
conflict with user definitions, as people might also like to call their
own difficult-to-name-the-difference version of eval simply as eval*.  At
least, the '*' postfix is what I sometimes use if I fail to find a better

Another suggestion:  
- (eval/no-module-restore <exp> [<env>])

Best regards,
Dirk Herrmann

reply via email to

[Prev in Thread] Current Thread [Next in Thread]