[erlang-questions] Lisp syntax for Erlang

[Robert Virding]

On 30/11/2007, Denis <denis.loutrein@REDACTED> wrote:
>
> >
> > 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 show,
> >
> > Robert
> >
>
> Can't we use (mod:fun args) syntax for the function call ? I don't
> know well scheme and CL, and I can't figure which are the differences
> internally.
> But at a syntaxic level, I find it tedious to write (remote-call
> mod ...) each time I want to call a function in another module. The
> (: seems also strange to me, even if I understand it's relevance in
> the lisp context.
> In the same vein, I also prefer to write (defun...) instead of
> (define (call...). Of course, it's just a matter of taste, I don't
> want to start a war :-)


I sort of agree. There are some problems with (mod:fun args):

- How do I write the equivalent of Mod:fun( ... )? I can't use (Mod:fun ...
) see below.

- How do I parse mod:fun? This is a fundamental question as the relationship
between code and data in lisp is 1-to-1. Parsed code *is* just its sexpr,
there is no difference. This is one reason why it is so easy to manipulate
code, for example by macros. Erlang code is has no such direct coupling to
data. This fine if you going to compile the code, but it makes it more
difficult to manipulate it. The problem is what do I parse mod:fun to?
  - In Cl it is the symbol fun in the module mod.
  - In Scheme it is just the symbol mod:fun which can be interpreted as a
call to a function in a library.
I mean I have to sensibly be able to handle the case where someone writes
(cons a mod:fun). What does this mean?

- Seeing this is based on Erlang I can't introduce any new data types. So
with the argument above I can't have variables as a separate data type,
separate from symbols/atoms. So Mod:fun will mean the same as mod:fun but
with a different name. Now that was clear :-)

So that is why I have no better suggestion for the moment to the general
function (remote-call <mod> <fun> ... ) and its short hand form the macro (:
mod fun ... )

Another problem for Erlisp is that while we have to have separate functions
for the case of same function name with different number of arguments (it's
Erlang) we don't need this for macros. In fact it might actually be better
not to have it so I can define general macros which work on any number of
arguments, like : above:

(defmacro : (mod fun . args)
  `(remote-call mod fun ,@REDACTED))

for a slightly bastardised form. Actually Scheme define-syntax does use
matching to select case so it might be better. The problem is that it will
be difficult to call macros as functions.

It can also be interesting to look at paul graham's arc lisp. For
> instance, qrc replace setf by =.
> He also renamed lambda to fn. Not so far from fun.
> http://www.paulgraham.com/arcll1.html


Read it. Interesting, but nothing came of it. Although I thoroughly agree
with its idea of keeping names short. Perhaps I can replace element and
set_element with tget and tset. :-)

Again, I'm not a specialist, and that's why I'm not too attached at
> keeping a known scheme or CL syntax.
> My 2 cents
> Denis
>

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20071202/aa49ffae/attachment.htm>