Lisp Flavored Erlang - Messaging primitives

I've read through all the docume开发者_如何学Pythonntation, and most of the source of LFE. All the presentations emphasize basic lisp in traditional lisp roles - General Problem Solving, Hello world and syntax emulating macros.

Does anyone know how LFE handles messaging primitives? To specify a more precise question, how would you express this erlang:

A = 2,  
Pid = spawn(fun()->  
    receive  
        B when is_integer(B) -> io:format("Added: ~p~n",[A+B]);  
        _ -> nan  
    end  
end), 
Pid ! 5.  

And then, you know, it mumbles something about having added up some numbers and the answer being 7.

I'm not an LFE user, but there is a user guide in the source tree. From reading it I would guess it is something like this:

(let ((A 2))
  (let ((Pid (spawn (lambda ()
                      (receive
                        (B (when (is_integer B))
                          (: io format "Added: ~p~n" (list (+ A B))))
                        (_ nan))))))
    (! Pid 5)))

But I'm very likely to have made a mistake since I haven't even evaluated it in LFE.

Some questions of mine:

• Is there a LET* form or is it behaving like one already?
• Are guards called the more lispy is-integer and not is_integer as I wrote?

There is a serious lack of examples in the LFE release, all contributions are welcome.

Christian's suggestion is correct. My only comment is that there is no need to have capitalized variable names, it is not wrong, but not necessary.

The LFE let is a "real" let in which the variable bindings are visible first in the body. You can use patterns in let. There is also a let* form (macro actually) which binds sequentially.

No, I have so far kept all the Erlang core function names just as they are in vanilla erlang. It is definitely more lispy to use -instead of _ in names, but what do you do with all the other function names and atoms in OTP? One suggestion is to automatically map - in LFE symbols to _ in the resultant atoms, and back again going the other way of course. This would probably work, but would it lead to confusion?

I could then have a behaviour module looking like:

(defmodule foo
  (export (init 1) (handle-call 2) (handle-cast 2) (handle-info 2) ...)
  (behaviour gen-server))

(defun handle-call ...)

(defun handle-cast ...)

etc ...

But I am very ambivalent about it.