Subject: Re: Creating functions at runtime
From: Erik Naggum <>
Date: 06 Oct 2002 01:10:27 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Henrik Motakef
| Trying to learn about the "Code as Data" feature of CL, I'd like to have
| some feedback if I'm on the right track or already misusing things.

  There are at least two different ways to look at this.  The first is to
  realize that a compiler will expect to read code and then examine the
  mechanisms by which the compiler reads code.  Common Lisp has the
  function `read´ which is used by the compiler to read the code.  By
  making this an ordinary part of the language and exporting it to the
  environment that ordinary users can use, too, programs that need to work
  on code can use it to read code and be able to work with it without
  having to duplicate the work the compiler needs to do to read code.  You
  realize that this in sharp contrast to most other programming languages,
  which generally do not contain neither functionality nor the system types
  to deal with source code.  This leads us to the second way to look at
  code is data.  The fundamental data type for source code is the list, and
  this is the same list as user programs work with.  (Some therefore think
  that the only data type in Lisp is the list, but even though we do not
  represent source code with vectors or strings, these types are just as
  fundamental to the programmers as the list.  Just wanted to clear that
  thing up preventatively.)  Since the functions to manipulate the list are
  ordinary parts of the languages and exported to the user environment like
  `read´, there is some functionality waiting to happen like an emergent
  property of the language: functions called by the compiler to operate on
  the code being compiled.  Languages without `read´ invent some complex
  rewriting systems and a lot of theory to go with them, but Common Lisp
  offers the programmer the /macro/, which processes an expression in the
  language as data, but it really is code and momentarily be turned into
  machine code by the compiler.  This leads to yet another way to look at
  "code is data", because functions are also ordinary language objects and
  may be passed around at will.  This is usually referred to as first-order
  functions and not usually as "code is data".  Then there is `eval´, of
  course, but I personally think that this is not the regular meaning of
  "code is data", either.  Common Lisp would have "code is data" even if
  you did not have `eval´ or the compiler available at run-time.

| Pretending *names* might be huge and testing whether an argument is nil
| might be expensive, I don't want to do the test for every name, so the
| general idea is to first build some function based on the passed
| arguments that returns whether a given name matches, and use this to
| filter the list of names, like this:

  Although testing for `nil´ is among the fastest things a Common Lisp
  program can do, it will probably slow things down a bit, so this is not
  an unreasonable plan.  However, actually constructing the code at runtime
  is not a good idea in this particular case.  Much better techniques are
  available.  For instance, while you have seen that you can create a
  /predicate/ according to the parameters, there are other options.

(defun get-matching-name (first-name last-name)
   ((and first-name last-name)
    ;; if multiple matches for one full name are possible, use
    ;; (remove (list first-name last-name) *names* :test-not #'equal)
    (find (list first-name last-name) *names* :test #'equal))
    (remove first-name *names* :test #'string/= :key #'first))
    (remove last-name *names* :test #'string/= :key #'second))

  It really would be useful to agree on a name for the opposite of
  `remove´/`delete´, like perhaps `collect´/`retain´.

| While this might be not optimal [...], it doesn't look too bad, IMHO.

  I think run-time construction of functions like this should be done when
  you have an input language that is more complex to handle than the code
  that would process it as an interpreted mini-language.

| One thing that still bugs me is the use of EVAL.

  Note that (compile nil '(lambda ...)) produces a compiled function.

| Given that EVAL doesn't seem to have a better reputation among CLers than
| it's equivalents in other languages, I wonder: is there a better way to
| get a function from a list built at runtime?

  `eval´ is perfectly acceptable when the purpose is to evaluate user code
  or expressions from an input language.  As a general principle: If the
  code you evaluate does not come from a run-time source, you should not
  perform run-time evaluation of it, either.

[ If you should dislike the tone or any part or aspect of the contents of
  this message so much that you feel compelled to attack or denounce me
  instead of staying focuesd on the questions you asked and the purpose you
  had when you asked them, please do not post your hostility. ]

Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.