On 04/12/2007, <b class="gmail_sendername">YC</b> <<a href="mailto:yinso.chen@gmail.com">yinso.chen@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="gmail_quote"><span class="q"></span>IMHO, the issues above arise from the goal being unclear: is it a lispy syntax for erlang or is it a lisp in erlang? </div></blockquote><div><br>I have tried to be clear, but obviously not succeeded. I am going to do a lisp syntax for Erlang, not implement CL or Scheme which, by the way, is *very* difficult on the BEAM today. That is the main problem as I have to invent lisp constructions which match into Erlang.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>If it's a lispy syntax, IMO a prefix<->infix transformer can handle a lot of cases (below uses vector for tuples):
</div></div></blockquote><div><br>What I want is something which *is* lisp even though it a lisp which has been designed to work seamlessly together with *normal* Erlang. So it is more than just wrapping ( ... ) around expressions after converting them into prefix form. So, for example, there are no syntactic variables, you quote things which you don't want to evaluate. So to comment some of you examples:
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div>%% Erlang => ErlangInLisp <br>A + 1, => (+ A 1)
<br>A = 5. => (= A 5).</div></div></div></blockquote><div><br>This will become a (let ((a 5)) ... ). Let will be extended to match<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div style="margin-left: 40px;">[foo | bar] => (| foo bar) </div></div></div></blockquote><div><br>(cons 'foo 'bar) <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div style="margin-left: 40px;">Pid ! Data => (! Pid Data) </div></div></div></blockquote><div><br>(send pid data) ;Using symbols can sometimes be harder to read<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div style="margin-left: 40px;">
A = {foo, bar}. => (= A #(foo bar)) %% or (= A {foo bar}) (either works fine, but vector version appears more uniform and in spirit of lisp) </div></div></div></blockquote><div><br>(let ((a #('foo 'bar))) ... ) ;or '#(foo bar) here
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div style="margin-left: 40px;">fun(A) -> A + 1. => (lambda (A) (+ A 1)) %% I think fun is fine.
</div></div></div></blockquote><div><br>Agree <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div style="margin-left: 40px;">
case A of foo -> {foo}; bar -> {foo, bar} end. => (case A ((foo) bar) ((bar) #(foo bar)))</div></div></div></blockquote><div><br>As yours but quoted:<br>(case a<br> ('foo #('bar))<br> ('bar #('foo 'bar)))
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div style="margin-left: 40px;">foo(1) -> 2; foo(abc) -> {foo, bar}. => (defun foo ((1) 2) ((abc) #(foo bar)))
</div></div></div></blockquote><div><br>I was more into:<br><br>(defun foo (arg)<br> (case arg<br> (1 2)<br> (abc '#(foo bar)))) <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div style="margin-left: 40px;">{ok, B} = mod:fun(). => (= #(ok B) (mod:fun)) or (= {ok B} ((: mod fun)))</div></div></div></blockquote><div><br>(let ((#('ok b) (: mod fun))) ... ) ;see below
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>And keep the rest of the erlang syntax such as Camel casing for variable, pattern matching built-in default, bare words as atoms unless at the the head of a list (or unless in special syntax such as case), etc.
</div></div></blockquote><div><br>One feature of lisp we must keep is that code has he same form as data, *is* data. That means that if we keep the Camel casing for variables then they have to parse to something other than symbols. If they don't then we will forever be parsing symbol names to discern what they are. That is why I would prefer to use the lisp convention of evaluating everything *except* that which is quoted. That means even using quotes in patterns.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>The issue with (remote-call) is that it's tedious. Think of having to write that for all function calls that don't live in the current module namespace. And it also takes on meaning of apply/3.
<br><br>If mod:fun(Args) is writtten as (remote-call mod fun Args), then how to write apply/3?
<br><br>Should we write apply(mod, fun, Args) as (apply (remote-call mod fun Args))?? Then it's apply/1. <br><br>Probably better to have remote-call take on the meaning of apply/3. I don't think all function calls should go through apply.
</div></div></blockquote><div><br>My current working model is:<br><br>mod:fun(<arg1>, <arg2>, <arg3>) ==> (module-call 'mod 'fun <arg1> <arg2> <arg3>)<br>Mod:fun(<arg1>, <arg2>, <arg3>) ==> (module-call mod 'fun <arg1> <arg2> <arg3>)
<br>Mod:Fun(<arg1>, <arg2>, <arg3>) ==> (module-call mod fun <arg1> <arg2> <arg3>)<br></div><br>with (: mod fun <arg1> <arg2> <arg3>) as a macro for the 1st most common case. It smiles at you because it feels good to be so helpful.
<br><br>You will still need apply:<br><br>apply(Fun, ArgList) ==> (apply fun arglist)<br>apply(Mod, Fun, ArgList) ==> (apply mod fun arglist)<br><br>Apply and module-call are proper functions which evaluate their arguments, : is a macro which doesn't evaluate its first two arguments, the module name and function name, but does evaluate the function arguments.
<br><br>We'll see where it all ends up,<br><br>Robert<br></div><br>