[erlang-questions] Erlang vs Clojure

[Ciprian Dorin Craciun]

On Nov 25, 2007 1:29 AM, Kostis Sagonas <kostis@REDACTED> wrote:
> Ciprian Dorin Craciun wrote:
> >
> >    It's not only about something you can or can not. It's also about
> > aesthetics.
>
> Yes.  I very much agree on this.  The only problem is that different
> people have different aesthetics.
>
> (Btw, I am not the one who designed the macro system and I am far from
> enamoured by it, so I am not certain why I am currently defending it.
> But here is a response to your mail in any case.)
>
> >    Compare the following two forms:
> >    ?if_(guard, {do something})
> >    vs
> >    if_ guard -> {do something} end
> >
> >    Which one looks more natural?
>
> Well, in Erlang, I would say it's definitely the first that looks more
> natural for the following two reasons:
>
>   1. It looks like a function call, and function calls are very natural
>      in a functional language.
>
>   2. Erlang's if construct has totally different semantics than the ones
>      you want there; it fails if the guard does not evaluate to true.
>
> >    What if I want to execute two operations?
> >    ?if_(guard, begin {operation-1}, {operation-2} end)
> >    vs
> >    if_ guard -> {operation-1}, {operation-2} end
>
> You are making a good argument, but I'd say the best thing to do is to
> factor the two operations out in a function in such a case. (Actually,
> the only reason why you need the begin+end is that the ',' symbol is
> overloaded in Erlang).
>
> >    What if I decide there is an else case? In my this case it's a
> > matter of removing a character '_' and adding the true case. In your
> > case I would have to rewrite a good portion.
>
> Well, not really.  Your case would be something like:
>
>    if guard -> {do something}; true -> {do something else} end
>
> and in my case it would be a macro:
>
>    ?if_else(guard, {do something}, {do something else}).
>
> (and writing the new macro -- the ?if_ macro would be a special case
> where the true part is just the above macro with the else part 'ok')
>
> >    The idea behind a good macro is to be able to "blend" inside the
> > "built-in" syntax and not stand out.
>
> I can give you many reasons why macros in Erlang suck but the "macros
> stand out in the language" argument comes pretty low on that list. I am
> not so convinced that Lisp-like macros is what Erlang desperately needs.
> But then again, disagreements such as these are exactly the reason we
> have so many different and diverse programming languages...
>
> Cheers,
> Kostis

    :) I think we have converged to a common conclusion:

> [...] I am
> not so convinced that Lisp-like macros is what Erlang desperately needs.
> But then again, disagreements such as these are exactly the reason we
> have so many different and diverse programming languages...

    Indeed a Lisp-like macro system would work only for a Lisp-like
syntax, and this is why I agreed with the thread's starting post (the
question if a Lisp syntax Erlang would be usefull.) Furthermore I
agree that it would be almost impossible to design a macro system for
the current syntax that would approach the flexibility I tried to
simulate in the previous examples.

    But regarding:

> >    Compare the following two forms:
> >    ?if_(guard, {do something})
> >    vs
> >    if_ guard -> {do something} end
> >
> >    Which one looks more natural?
>
> Well, in Erlang, I would say it's definitely the first that looks more
> natural for the following two reasons:
>
>   1. It looks like a function call, and function calls are very natural
>      in a functional language.

    I would disagree... normal if, case, receive, try, etc. don't look
like function calls but as "special" control structures. So a new
version of "if" would look more natural as another "special" control
structure than a function call... But this -- again -- is only a mater
of taste.

    Ciprian.