Wed Aug 23 23:43:07 CEST 2006
Being a lisp programmer I must say that I have never before heard the
term "quasi-programming". Back-quote yes, but quasi-programming no.
Now the back-quote macro (it is a macro in lisp) is a wonderful thing in
lisp, but for erlang it would not give you very much, as it stands. It
gives you two things:
1. It allows you to write down a literal pattern for what you want to
build and only mark what is to be evaluated.
2. It allows you to splice in lists into your pattern with ,@REDACTED
Now the first one you already have in erlang, you build a term by
writing it down, the compiler generates the the build primitives for
you. The second doesn't give you much in Erlang where the list isn't the
base of all code.
And as someone already mentioned parse-transform allow you to do any
compile-time meta programming you can think of. What could be useful is
a parse-transform which allows to define lisp like macros and use them.
This would give users the ability to define macros without having to do
a complete parse-transform, which is not difficult but a bit tedious to
The current macros are actually a bit of a joke I added when people
wanted to have named constants. Especially doing it at token level. I
had a bit of fun and added the rest as well. The only thing I really
missed was allowing macros with the same name and different number of
arguments like functions.
What you could do if you did it in a parse-transform is work at the form
level as is done in lisp. This would be more powerful and then you would
need the back-quote nacro.
P.S. Maybe I'll have a go after Erlog and regexps.
Vlad Dumitrescu wrote:
> What I have in store (or more precisely, in a truck on the way to the
> store :-) is to add functionality similar to Lisp's backquote (or more
> precisely to E's quasipatterns, because one can use any language for
> which ione has a scanner and a parser).
> My reason for this is to make handling of source code easier (becaue
> we do a lot of that in Erlide), but it could be used to implement
> lisp-style macros as well.
> It looks pretty good so far, but it's quite tricky. Especially
> handling pattern matching, where I think it might be needed to extend
> PM syntax too...
More information about the erlang-questions