From: Pertti Kellomäki
Subject: Re: why are Macros special? & Protection of codes.
Date:
Message-ID: <g16emc$2to$1@news.cc.tut.fi>
Francogrex wrote:
> I was annoyed because I knew that somehow
> the concept of macros is SAS (or other real programming languages) is
> quite different from the macros in lisp but couldn't explain really
> how, didn't have enough knowledge of other languages. Can someone tell
> me how macros in Lisp are different?
I don't know anything about SAS, but IMO the main difference
between Common Lisp macros and macros in most other languages
is the metalanguage.
What I mean by a metalanguage is that since a macro does a source
to source transformation, there needs to be a language in which
to express the transformation. For example, in C++ this is the
template language, which has been shown to be Turing complete,
so in principle it can be used to express arbitrary transformations.
However, if you have looked at template metaprogramming in C++,
the operative phrase is "in principle". In reality it can be
pretty horrific.
In contrast, in Common Lisp the transformations are expressed
using Common Lisp, i.e. the base language and the metalanguage
are the same. This has two benefits: you only need to know one
language, and more importantly, the metalanguage has actually
been designed to express arbitrary computation in a convenient
form.
An added bonus is that the syntactic forms of the base
language are provided to macros as lists, and Lisp just happens
to have very good capabilities for LISt Processing ;-)
--
Pertti
Pertti Kellom�ki wrote:
> Francogrex wrote:
>
>> I was annoyed because I knew that somehow
>> the concept of macros is SAS (or other real programming languages) is
>> quite different from the macros in lisp but couldn't explain really
>> how, didn't have enough knowledge of other languages. Can someone tell
>> me how macros in Lisp are different?
>
>
> I don't know anything about SAS, but IMO the main difference
> between Common Lisp macros and macros in most other languages
> is the metalanguage.
>
> What I mean by a metalanguage is that since a macro does a source
> to source transformation, there needs to be a language in which
> to express the transformation. For example, in C++ this is the
> template language, which has been shown to be Turing complete,
> so in principle it can be used to express arbitrary transformations.
> However, if you have looked at template metaprogramming in C++,
> the operative phrase is "in principle". In reality it can be
> pretty horrific.
>
> In contrast, in Common Lisp the transformations are expressed
> using Common Lisp, i.e. the base language and the metalanguage
> are the same.
Yes, I think is what distinguishes Lisp from SAS. SAS doc used the
phrase "writing code that writes code", but as they themselves
emphasized in the bit I cited the %constructs were valid only in SAS
macros, so one does not have the full power of the language at ones
disposal in writing SAS macros.
kxo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
As if this topic hadn't been covered enough, I'll add my weight to
it. Not that it's really needed, though, since the answers really add
up to a great conclusion.
I can understand the SAS programmers' blind opinion. Much before
getting to know lisp's existence, I worked on a small SAS project in
parallel with another one more important in C++, using both languages'
metaprogramming features to automate as much out of my programming and
future maintenance responsibilities. I'm such a lazy programmer that
I'm willing to put a lot of effort now instead of later.
In SAS' case, I pushed its macro system to its limits and was able to
build what some people would call a DSL and some code generators that
have been so useful and easy to use that I wasn't needed on this
particular project afterwards. (What a relief! I hated most SAS
language constructs with a passion, although its macro language felt
very powerful to me.)
If you've already discussed with your coworkers the two challenges
that have been suggested to you, you already know that the first one
is doable with SAS macros as long as you have all the information you
need at compile-time. That's exactly something I did on that
project. The second challenge is probably a working example of what
can't be done in SAS macrology, but I ain't sure it couldn't be done
with SAS. I won't speculate further since I'm not sure I understood
enough this challenge.
People have already highlighted many differences of the two macro
systems. I'd say the key ones that should be mentioned to your
coworkers are the facts that SAS macros don't exist at run time and
don't interact natively with the SAS language (nor are they known to
the SAS language compiler); they interact with text, which happens to
be SAS or macro code, and that's all. So SAS macros really only are
text substitutors/generators used at the pre-compilation step. Yes,
they're much more evolved than C/C++'s preprocessor macros, but a deal
less than C++'s templates and lisp macros.
So in essence, SAS macros are great at manipulating SAS macro code,
and only as good at manipulating SAS language code as they are at
manipulating text.
(How to write a 400-word answer when 40 might have been enough...)
Daniel Jomphe <············@gmail.com> writes:
> (How to write a 400-word answer when 40 might have been enough...)
I imagine macros could help with that.
Pertti Kellomäki <················@tut.fi> wrote:
> In contrast, in Common Lisp the transformations are expressed
> using Common Lisp, i.e. the base language and the metalanguage
> are the same. This has two benefits: you only need to know one
> language, and more importantly, the metalanguage has actually
> been designed to express arbitrary computation in a convenient
> form.
There's a third benefit (well, maybe it's a special case of the second,
but in this context it seems worth spelling out fully), and that's the
fact that the metalanguage itself can have transformations applied to
it. Indeed, because of the circularity, rather than a single level of
transformation and metalanguage, we get an unbounded number of levels.
-- [mdw]