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

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

[William Case]

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)
	body ... )   

or would I be missing some significant difference ?
 


-- 
Regards Bill

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

[Barry Margolin]

In article <mailman.2465.1177432345.7795.help-gnu-emacs@gnu.org>,
 William Case <billlinux@rogers.com> wrote:

> 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)
> 	body ... )   
> 
> or would I be missing some significant difference ?

Are you asking whether [documentation-string] is the same as 
"optional-documentation ..."?  Yes, they are just different notations 
for the same thing.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

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

[Tim X]

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

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

[Maciej Katafiasz]

Den Tue, 24 Apr 2007 12:23:01 -0400 skrev William Case:

> The differences seem trivial, but can I re-write the lambda algorithm in
> terms of the defun algorithm for myself such that:

Not sure what you mean, but defun is simply defined in terms of lambda.

(defun foo (arg) "doc" body)

is the same as

(fset 'foo (lambda (arg) "doc" body))

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

[Maciej Katafiasz]

Den Wed, 25 Apr 2007 16:14:29 +1000 skrev Tim X:

> the 'interactive' function is also rarely seen in a lambda for the same
> reasons.

Well, it's not that rare, especially in packages that perform more complex
command foo. Lambda is a good way to bind a function taking arguments with
some values pre-defined, essentially currying the function into one with
less arguments.

Cheers,
Maciej

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

[Tim X]

Maciej Katafiasz <mathrick@gmail.com> writes:

> Den Wed, 25 Apr 2007 16:14:29 +1000 skrev Tim X:
>
>> the 'interactive' function is also rarely seen in a lambda for the same
>> reasons.
>
> Well, it's not that rare, especially in packages that perform more complex
> command foo. Lambda is a good way to bind a function taking arguments with
> some values pre-defined, essentially currying the function into one with
> less arguments.
>

True, I probably should not have used rarely, but rather 'less frequently
seen'. While I've seen it used in this type of situation and others, I've not
seen it that often. 

Tim

-- 
tcross (at) rapttech dot com dot au