[erlang-questions] Lisp syntax for Erlang
Fri Nov 30 00:06:48 CET 2007
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".
On 26/11/2007, Eric Merritt <cyberlync@REDACTED> wrote:
> Why try to use scheme syntax at all. Come up with a lisp that works
> given erlang semantics. A lisp is a lisp is a lisp after all. I thing
> trying to implement scheme on top of lisp is not a good direction, it
> will be difficult to get parity between the semantics one expects when
> using scheme and the semantics enforced by its layering on top of the
> erlang vm. So embrace both lisp and erlang and come up with a good
> fusion between the two.
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
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.
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:
(remote-call mod func arg1 arg2 ... )
which is a normal function and have:
(: mod func arg1 arg2 ... )
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:
(remote-call 'mod 'func arg1 ... )
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions