Robert Virding robert.virding@REDACTED
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 
get right.

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:
> Hi,
> 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...
> regards,
> Vlad

More information about the erlang-questions mailing list