help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Elisp Tutorial dumb question -- but I thought I better doublecheck ?


From: Tim X
Subject: Re: Elisp Tutorial dumb question -- but I thought I better doublecheck ??
Date: Wed, 25 Apr 2007 16:14:29 +1000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux)

William Case <billlinux@rogers.com> writes:

> Subject: Elisp Tutorial dumb question -- but I thought I better doublecheck ??
>
> Hi;
>
> I am working my way through the elisp tutorial
> at 
> :http://www.linuxselfhelp.com/gnu/emacs-lisp-intro/html_mono/emacs-lisp-intro.html#Writing%20Defuns
>
> Section 3.3 on defuns gives an algorithm for the basic defun as:
>
> defun
> (defun function-name (arguments ... )
> "optional-documentation ..."
> (interactive argument-passing-info)
> body ... )  
>
> and later gives an algorithm for the lambda anonymous function as:
> C.4.3 A lambda Expression: Useful Anonymity
>
> (lambda (arg-variables...)
>   [documentation-string]
>   [interactive-declaration]
>   body-forms...)
>
> The differences seem trivial, but can I re-write the lambda algorithm in
> terms of the defun algorithm for myself such that:
>
> lambda
> (lambda (arguments ... )
>       "optional-documentation ..."
>       (interactive argument-passing-info)

plus
     body-forms....)

If I understand things correctly, the answer is sort of yes. The difference
between [interactive ...] and (interactive ....) in the two definitions seems
inconsistent to me because the [...] notation indicates optional features.
On the other hand, 'interactive' is just another body form in both the defun
and lambda. Its just listed separately because it performs a special role.  

'interactive' is only required in a defun when it is to be an interactive
command. Likewise, interactive is only required in a lambda expression if it is
to be called interactively. However, the big difference is that you cannot call
a lambda expression interactively without first associating it with some
symbol/name. Generally, you will see lambda expressions in places where
functions can be if the expression is only going to be used once. for example,
you often see things like

(add-hook 'my-mode-hook (lambda ()
                           (do-something-1)
                           (do-somethint-2)))

instead of 

(defun my-hook-func ()
  (do-something1)
  (do-something2))
(add-hook 'my-mode-hook 'my-hook-func)

With the second approach, there is now an interned symbol called my-hook-func
that is never going to get used again. In the first example, the same outcome
is achieved, but without creating (polluting) the namespace with a symbol which
will never be used again. This same approach is often seen with functions that
take a function as an arguement, like mapcar. 

Since lambda expressions/functions are used in this way, it is rare to see them
include a document string (document strings often just explain what the
function does and how it is called, but as a lambda is not usually going to be
called in other places, such information is rarely useful.

the 'interactive' function is also rarely seen in a lambda for the same
reasons. Putting (interactive) in your function definition means the function
can now be used as a command (i.e. called with M-x func-name or interactively
via a key binding). However, as lambda functions are by definition anonymous
and don't have a name, they are generally of no use in a M-x situation. There
are ways of associating a lambda function/expression with a symbol - sort of
giving them a name, but this is usually only needed in very special situations
and something you can ignore when learning.

There are a few other subtle differences between a regular function and a
lambda expression, but initially, when learning this stuff, you can safely
ignore this. Later, as your understanding grows, these differences will make
more sense and will be easier to understand. 

Note that in emacs lisp, you want to try and minimise the number of distinct
symbols to avoid namespace pollution. Unlike some lisps that have package
namespaces, emacs lisp doesn't. this is why you see a lot of function names
that have a package prefix in emacs lisp, but not in common lisp etc. If you
intern too many symbols, you begin to run out of options for new meanigful ones
or start shadowing/redefining existing functions and all sorts of weird things
begin to happen.

Tim

-- 
tcross (at) rapttech dot com dot au


reply via email to

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