Bengt is right Erlisp would probably be better as Elisp is already taken (by Emacs lisp), which I do know being an old Elisp hacker my self. It was just a mild "in joke".<br><br><div><span class="gmail_quote">On 26/11/2007, 

<b class="gmail_sendername">Eric Merritt</b> <<a href="mailto:cyberlync@gmail.com">cyberlync@gmail.com</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Why try to use scheme syntax at all. Come up with a lisp that works<br>given erlang semantics. A lisp is a lisp is a lisp after all. I thing<br>trying to implement scheme on top of lisp is not a good direction, it<br>will be difficult to get parity between the semantics one expects when

<br>using scheme and the semantics enforced by its layering on top of the<br>erlang vm. So embrace both lisp and erlang and come up with a good<br>fusion between the two.</blockquote><div><br>In many ways CL and Scheme are quite similar, but, of course, there are some fundamental differences. For example in CL symbols have two bindings, a function binding and a value binding, whereas in Scheme symbols have only a value binding. It was more at this level I was thinking. Seeing this would be an implementation of Erlang and must interact smoothly with the rest of Erlang it will never *be* a Scheme or CL, the differences are too great. 

My idea is just that you take good from where you can but try and keep things consistent. So do we base our Erlisp on the CL way or the Scheme way? My suggestion is that we do as Scheme and just have one binding for a symbol.

The way Erlang handles modules, and atoms/symbols, is different from either lisp so we will have to go our own way there. I personally think that it is a benefit to try and use the same name for things in Erlisp which is why I re-used names like 'receive' and 'case' but expanded to have guards. I personally think that 'if' should be the lisp if not the erlang if, though there is the problem of handling errors in the guards. One way would be to do as list comprehensions do if it a test can be a guard test make it one otherwise treat it a normal call. But it is not consistent.

We have to handle functions with the same name but with different number of arguments as in Erlang, different functions. No way around it. But I wonder if macros should be like that. Some nice macros would be tedious to define like that. Perhaps there should only be one macro definition per name which can handle various numbers of arguments, as in list. Either using a defmacro from CL or something similar to define-syntax from Scheme which uses matching to select expansion.

<br><br>Intermodule calls are the biggest problem, not to implement but to come up with a good syntax for it. In CL the symbol mod:func means the symbol func in the package mod, while in Scheme it is just a normal symbol which you can tell the system it refers to the function func in the library/module mod. I will try with a suggestion, both mine and others, from a different thread:

<br><br>(remote-call mod func arg1 arg2 ... )<br><br>which is a normal function and have:<br><br>(: mod func arg1 arg2 ... )<br><br>for the special case where both mod and func are the actual names of e the module and function. This to save having to write:

<br><br>(remote-call 'mod 'func arg1 ... )<br><br>Sorry for rambling on here, but these are just some ideas I have had about it all. Probably should blogg it but I don't want to release it to a poor unsuspecting public just yet. :-) I'll be back when I have something to show,

<br><br>Robert<br><br></div></div>