[erlang-questions] Erlang vs Clojure

[Ciprian Dorin Craciun]

On Nov 25, 2007 12:28 AM, Kostis Sagonas <kostis@REDACTED> wrote:
>
> Ciprian Dorin Craciun wrote:
>  > On Nov 24, 2007 11:28 PM, Kostis Sagonas <kostis@REDACTED> wrote:
>  >>
>  >> In what areas/applications the macro system is not doing what you
>  >> want it to?  Some examples would help (at least me).
>  >
>  >     For example if I would like to execute a piece of code if a
>  > condition is true and do nothing otherwise I have to write:
>  >     if
>  >         guard -> {do something}
>  >         true -> false
>  >     end
>  >
>  >     So instead of introducing a new control structure, I could define
>  > a macro that would be used like you can see below, but is expanded
>  > like the code above:
>  >     if_ guard -> {do something} end
>  >
>  > I hope this is a good example even if it is a trivial one.
>
> Yes, it's a good example alright, but this is something that can easily
> be done with the current macro system.  For example, in the HiPE native
> code compiler for Erlang we need similar functionality: doing some pass
> when a compiler option is specified and doing nothing otherwise.
> So, we have the macro:
>
> -define(when_option(__Opt,__Opts,__Action),
>          case proplists:get_bool(__Opt,__Opts) of
>            true -> __Action;
>            false -> ok
>          end).
>
> and we use it all over the place as in e.g:
>
>     ?when_option(verbose, Opts, ?debug_msg("Compiling ~w~n",[MFA])),
>
> Is there something else that you want to do and you can't?
>
> Kostis

   It's not only about something you can or can not. It's also about
aesthetics.

   Compare the following two forms:
   ?if_(guard, {do something})
   vs
   if_ guard -> {do something} end

   Which one looks more natural?

   What if I want to execute two operations?
   ?if_(guard, begin {operation-1}, {operation-2} end)
   vs
   if_ guard -> {operation-1}, {operation-2} end

   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.

   The idea behind a good macro is to be able to "blend" inside the
"built-in" syntax and not stand out.

   For example what if I want to create a special purpose receive
that has a default pattern that just removes the unmatched messages,
but allows me to have unlimited number of patterns? Can I achieve this
with the current macro system? (In your case the macro system should
allow me to declare a macro with variable number of arguments.)

   Ciprian.