[on lisp] 5.7 When to Build Functions

Expressing functions by calls to constructors instead of sharp-quoted lambda expressions could, unfortunately, entail unnecessary work at runtime.
#'(lambda ...)대신 생성자 호출을 통한 함수 표현은, 불필요한 일을 런타임에 하도록 한다.
A sharp-quoted lambda-expression is constant, but call to constructor function will be evaluated at runtime.
#'(lambda ...)는 상수다, 하지만 생성자호출 함수는 런타임에 평가된다.
If we really have to make this call at runtime, it might not be worth using constructor functions.
만약 정말로 런타임에 이런 호출을 해야 한다면, 생성자 함수를 사용하는 것은 가치가 없을 수 있다.
However, at least some of time we can call the constructor beforehand.
하지만, 최소한 어떤 때는, 우리는 생성자를 그전에 호출할 수 있다.
By using #., the sharp-dot read macro, we can have the new functions built at runtime.
#., 샤프도트 리드 매크로, 를 이용하면 런타임에 새로운 함수를 가질 수 있게 된다.
So long as compose and its arguments are defined when thie expression is read, we could say, for example:

(find-if #.(compose #'oddp #'truncate) lst)

Then the call to compose would be evaluated by the reader, and the resulting function inserted as a constant into our code.
compose에 대한 호출은 리더에 의해 평가되고, 컴파일 되면 상수로 코드에 들어가게 된다.
Since both oddp and truncate are built-in, it would safe to assume that we can evaluate the compose at read-time, so long as compose itself were already loaded.
oddp, truncate 모두 built-in이기 때문데, read-time에 compose를 평가해도 안전하다는 것을 예측하고, 그렇기 때문에 compose자신은 이미 로드가 되었음을 알 수 있다.
In general, composing and combining functions is more easily and efficiently done with macros.
일반적으로, composing/combining함수들은 매크로를 이용하면 더 쉽고 효율적이다.
This is particularly true in Common Lisp, with its separate name-space for functions.
특히 커먼리습에는 함수와 다른 네임스페이스를 가진다.
After introducing macros, we will in Chapter 15 cover much of the ground we covered here, but in a more luxurious vehicle.
매크로는 15챕터에서 소개한다.