Are macros really a neccessity, or a coverup of language deficiencies?

56 views
Skip to first unread message

Peaker

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
I have been thinking a lot about language design lately.

This has made me doubt the real necessity of macros, as they always seem

to cover up for one or another language deficiency.

In general, macros are a messy thing:

- Since the macros are actually source code generators of some sort,

they create trouble such as namespace collisions, which result in

messy workarounds, such as gensym.

- Since macros are inline by nature, they make it much harder to

seperate the low-level code into units of functions.

Macros usually have a function-like syntax, and perform 'operations'

on the arguments (is this the right term for the case?) of the macro.

Those operations are commonly unusable on function arguments in the

same way, because function arguments are COPIES of the original values

and not transparentely pointing at them. This is the most common use

of macros, I believe, and is only there to make up for a method of

calling functions 'By value'. Can someone explain to me the

advantages of the implicit copying when sending 'By value'? This, I

would consider a language defiency, because it requires the use of a

messy solution (namely macros) when a non-messy one (functions) WOULD

have been possible.

Most other uses of macros I would consider ABUSES of macros, however

some non-abusive forms also exist, those are creating 'patterns' by

which the generate source code follows. I believe the language could

offer the ability to create those patterns using powerful language

features rather than the messy solution.

I would appriciate an example of something a macro can be used for,

for which a function, in a more powerful language (In terms of what

functions can do), cannot be used.

Thanks, Eyal Lotem

--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).


David J. Cooper

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
Peaker <pea...@makif.omer.k12.il> writes:

> I have been thinking a lot about language design lately.
>
> This has made me doubt the real necessity of macros, as they always seem
>
> to cover up for one or another language deficiency.
>
> In general, macros are a messy thing:
>
> - Since the macros are actually source code generators of some sort,
>
> they create trouble such as namespace collisions, which result in
>
> messy workarounds, such as gensym.
>

You are partially correct. Macros are not necessary, but they also are
not a "coverup of language deficiency." They are a convenience. When
used appropriately, they allow you to define a language which allows
you to write code in a much more concise manner than you otherwise
would have to.

In my opinion, the convenience afforded by appropriate use of macros
far outweighs the drawbacks which you mention above.

But you are right, anything which you can produce with a macro can
also be written by hand. Assembler language can be written by hand, as
well. The point of macros is much like the point of a compiler - to
get the computer to do much of the grunt work of writing your program
for you.


-dave


--
David J. Cooper Jr, Chief Engineer Genworks International
dco...@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com

Jim Bushnell

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
I suggest that you read "OnLisp" by Paul Graham. He gives many examples of
both the convenience aspects of macros, and their use in "language design",
and shows how macros extend the power of lisp, for example where CLOS
originally was implemented.

Peaker <pea...@makif.omer.k12.il> wrote in message
news:390371F0...@makif.omer.k12.il...


> I have been thinking a lot about language design lately.
>
> This has made me doubt the real necessity of macros, as they always seem
>
> to cover up for one or another language deficiency.
>
> In general, macros are a messy thing:
>
> - Since the macros are actually source code generators of some sort,
>
> they create trouble such as namespace collisions, which result in
>
> messy workarounds, such as gensym.
>

Larry Elmore

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
"David J. Cooper" <dco...@genworks.com> wrote in message
news:pmqem7w...@lang.genworks.com...

> Peaker <pea...@makif.omer.k12.il> writes:
>
> > I have been thinking a lot about language design lately.
> >
> > This has made me doubt the real necessity of macros, as they always seem
> >
> > to cover up for one or another language deficiency.
> >
> > In general, macros are a messy thing:

I'd agree that they _can_ be messy, which is why they should be used
somewhat cautiously. They aren't necessarily messy, though, and can be
invaluable.

> You are partially correct. Macros are not necessary, but they also are
> not a "coverup of language deficiency." They are a convenience. When
> used appropriately, they allow you to define a language which allows
> you to write code in a much more concise manner than you otherwise
> would have to.
>
> In my opinion, the convenience afforded by appropriate use of macros
> far outweighs the drawbacks which you mention above.

That's the key phrase: "appropriate use". I regard (and use) macros (in any
language) the same way I do chainsaws -- powerful and sometimes invaluable,
but only a fool would use them anywhere except where they really are the
best answer.

Larry

Robert Monfera

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to

Courageous wrote:

> (defun f ( str &rest body )
> `(format t ,str ,@body)
> )
...
> Actually, if there's a way of doing that *without* macros, I sure
> would like to know about it.

(defun format-t (string &rest args)
(apply #'format t string args))

Robert

Courageous

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to

> That's the key phrase: "appropriate use". I regard (and use) macros (in any
> language) the same way I do chainsaws -- powerful and sometimes invaluable,
> but only a fool would use them anywhere except where they really are the
> best answer.

I view a language without metalinguistic constructs as hamstrung.
Java, for example is soooo not extensible. Standard macros in C++
and ANSI C are barely a solution, although the gcc style macros
at least offer variatic argument support. In lisp, I've found that
macros are outright mandatory when you want to pass of a &rest
form to a function which expects that &rest form as not a list. e.g.,

(defun f ( str &rest body )
`(format t ,str ,@body)
)

(example of writing a format that passes through to format
a bit silly, but gets the point across; hope I got the syntax
right, not at work and don't have all this memorized yet).

Actually, if there's a way of doing that *without* macros, I sure
would like to know about it.

Overall, I like macros, however, as long as the programmer
doesn't go so overboard with them that the code becomes "write
only". :)

You do learn macro-expand and macro-expand1 pretty quickly
using them, though. :)


C/

Rob Warnock

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Courageous <jkra...@san.rr.com> wrote:
+---------------

| In lisp, I've found that macros are outright mandatory when you want
| to pass of a &rest form to a function which expects that &rest form
| as not a list.
+---------------

Sorry, macros are not "mandatory" at all for doing that. There's a
straightforward functional way to do it.

+---------------


| Actually, if there's a way of doing that *without* macros, I sure
| would like to know about it.

+---------------

It's called "apply". See: <URL:http://www.xanalys.com/software_tools/
reference/HyperSpec/Body/fun_apply.html>


-Rob

-----
Rob Warnock, 41L-955 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043

Courageous

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to

> > Actually, if there's a way of doing that *without* macros, I sure
> > would like to know about it.
>
> (defun format-t (string &rest args)
> (apply #'format t string args))

Thank you! That's very helpful.

C/

Courageous

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to


Come to think of it, that neatly wipes out most of the macros
I've used in my current project. Still, I sleep better knowing
that `(,@) is available. :)-


C/

Courageous

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to

> > (defun f ( str &rest body )
> > `(format t ,str ,@body)

> (defun format-t (string &rest args)


> (apply #'format t string args))


Are either of these forms preferred over one another?
Or is it just a matter of style?


C/

Tom Breton

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Peaker <pea...@makif.omer.k12.il> writes:

> I have been thinking a lot about language design lately.
>
> This has made me doubt the real necessity of macros, as they always seem
>
> to cover up for one or another language deficiency.

OK, please don't be entirely surprised if the ng has a defensive
reaction to this. Your comments sound like, well, like you haven't
used Lisp long enuff to understand its macros. Which is not meant as
a flame, just an observation.

> In general, macros are a messy thing:
>

> - Since the macros are actually source code generators of some sort,
>
> they create trouble such as namespace collisions, which result in
>
> messy workarounds, such as gensym.

I don't consider an occasional (let ((... (gensym))) ...) to be so
messy. But supposing it were, IMO a better solution would be to make
it prettier. EG, perhaps add something to backquote syntax to
indicate that a given symbol must be a gensym.

> - Since macros are inline by nature, they make it much harder to
>
> seperate the low-level code into units of functions.

I don't follow this.

> Macros usually have a function-like syntax,

More than that, in Lisp they *are* functions that are entered "funny".

> and perform 'operations'
>
> on the arguments (is this the right term for the case?) of the macro.
>
> Those operations are commonly unusable on function arguments in the
>
> same way, because function arguments are COPIES of the original values
>
> and not transparentely pointing at them. This is the most common use
>
> of macros, I believe, and is only there to make up for a method of
>
> calling functions 'By value'.

Whoa! Back way up, please! It sounds like you are describing some
completely different language. True, it's *possible* to abuse Lisp
macros that way, but that's not what they are typically used for.
They operate lexically on forms before those forms are "really"
evaluated.

> I would appriciate an example of something a macro can be used for,
>
> for which a function, in a more powerful language (In terms of what
>
> functions can do), cannot be used.

Defining a function. I say that off the top of my head because that's
what the last macro I dealt with a short time before reading Usenet
did.

--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Rethink some Lisp features, http://world.std.com/~tob/rethink-lisp/index.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.

Tom Breton

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Courageous <jkra...@san.rr.com> writes:

>
> I view a language without metalinguistic constructs as hamstrung.
> Java, for example is soooo not extensible. Standard macros in C++
> and ANSI C are barely a solution, although the gcc style macros

> at least offer variatic argument support. In lisp, I've found that


> macros are outright mandatory when you want to pass of a &rest

> form to a function which expects that &rest form as not a list. e.g.,

>
> (defun f ( str &rest body )
> `(format t ,str ,@body)

> )
>
> (example of writing a format that passes through to format
> a bit silly, but gets the point across; hope I got the syntax
> right, not at work and don't have all this memorized yet).

I assume you meant:

(defmacro f ( str &rest body )
`(format t ,str ,@body))

> Actually, if there's a way of doing that *without* macros, I sure
> would like to know about it.

Without backquote?

(defmacro f ( str &rest body )
(list* 'format t str body))

or equivalently:

(defmacro f ( str &rest body )
(append (list 'format t str) body))

Without using any macro? No, unless you care to write it out longhand
every time, which defeats the purpose.

> Overall, I like macros, however, as long as the programmer
> doesn't go so overboard with them that the code becomes "write
> only". :)

> You do learn macro-expand and macro-expand1 pretty quickly
> using them, though. :)

Ooh yeah.

Tom Breton

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Tom Breton <t...@world.std.com> writes:

> Courageous <jkra...@san.rr.com> writes:
>
> > Actually, if there's a way of doing that *without* macros, I sure
> > would like to know about it.
>
> Without backquote?
>
> (defmacro f ( str &rest body )
> (list* 'format t str body))
>
> or equivalently:
>
> (defmacro f ( str &rest body )
> (append (list 'format t str) body))
>
> Without using any macro? No, unless you care to write it out longhand
> every time, which defeats the purpose.

Egg on my face! I was focussed on creating that precise lexical form,
but of course that misses the point. Use:

(defun f ( str &rest body )

(apply #'format t str body))

Joe Marshall

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Courageous <jkra...@san.rr.com> writes:

> (defun f ( str &rest body )

> `(format t ,str ,@body)
> )
>
> (example of writing a format that passes through to format
> a bit silly, but gets the point across; hope I got the syntax
> right, not at work and don't have all this memorized yet).
>

> Actually, if there's a way of doing that *without* macros, I sure
> would like to know about it.

(defun my-format (str &rest arguments)
(apply #'format t str arguments))

or

(defun my-format (str &rest arguments)
(format t "~?" str arguments))

--
~jrm

Joe Marshall

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Peaker <pea...@makif.omer.k12.il> writes:

> I have been thinking a lot about language design lately.
> This has made me doubt the real necessity of macros, as they always seem
> to cover up for one or another language deficiency.

What do you mean by `deficiency'? Macros allow you to extend the
syntax of a language in ways that the language designers didn't
forsee. This is analagous to the way procedures allow you to extend
the functionality of the language in ways the designers didn't
forsee.

Macros can also be used to extend the language compiler in ways that
the compiler writer didn't forsee. This use of macros is less
common.

Some languages are so poorly designed that it is difficult or
impossible to program without using lots of macros, and some languages
are so poorly designed that macros cannot be used without a complete
understanding of how they expand.

> In general, macros are a messy thing:
>
> - Since the macros are actually source code generators of some sort,
> they create trouble such as namespace collisions, which result in
> messy workarounds, such as gensym.

Gensym is much less messy than some alternatives (like making a `rule'
that macro writers must mangle the names of any variables they
introduce). `Hygenic' macros are another solution popular in the
Scheme world.

> - Since macros are inline by nature, they make it much harder to
> seperate the low-level code into units of functions.

Not if you use them correctly.

> Macros usually have a function-like syntax, and perform 'operations'


> on the arguments (is this the right term for the case?) of the macro.
> Those operations are commonly unusable on function arguments in the
> same way, because function arguments are COPIES of the original values
> and not transparentely pointing at them. This is the most common use
> of macros, I believe, and is only there to make up for a method of

> calling functions 'By value'. Can someone explain to me the
> advantages of the implicit copying when sending 'By value'? This, I
> would consider a language defiency, because it requires the use of a
> messy solution (namely macros) when a non-messy one (functions) WOULD
> have been possible.

Macros *can* be used to simulate call-by-reference, but I try to
eschew this use. When people see a form like (FOO A), they
generally do *not* expect the value of A to be modified, especially
if A is atomic. Unless I have a really good reason to do otherwise, I
would suggest that (SETQ A (FOO A)) would be a far better alternative
than a macro.

> Most other uses of macros I would consider ABUSES of macros, however
> some non-abusive forms also exist, those are creating 'patterns' by
> which the generate source code follows. I believe the language could
> offer the ability to create those patterns using powerful language
> features rather than the messy solution.
>

> I would appriciate an example of something a macro can be used for,
> for which a function, in a more powerful language (In terms of what
> functions can do), cannot be used.

Here's how I use macros:

1. Creating new concise syntax for a particular problem:

(define-alu-operation MOVI (register destination) (immediate value))

2. Creating new language extensions that deliberately mimic existing
special forms. For example, you could imagine a macro called
TOGGLEF that was essentially (SETF ,place (NOT ,place)). Then you
would call (togglef (light-switch (current-room)))

3. Extending other macros or abstracting certain features that cannot
be done via functions.

(with-log-file (stream "foo") ...) =>
(with-open-file (stream (make-pathname :name "foo" :type "log")
:direction :output :if-does-not-exist :create)
....)

4. Truly hairy preprocessing (examples would be too large to include).

I generally avoid using macros just to delay argument evaluation. It
is just as easy to wrap a LAMBDA around the appropriate argument, and
it avoids creating code that isn't applicative order. So you might
see this in my code:

(call-with-temp-file #'(lambda (file) ....))

whereas other lisp hackers would write a macro

(with-temp-file (file) ....)

Obviously, I was brought up on the wrong side of the tracks.

--
~jrm


Peaker

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Jim Bushnell wrote:

> I suggest that you read "OnLisp" by Paul Graham. He gives many examples of
> both the convenience aspects of macros, and their use in "language design",
> and shows how macros extend the power of lisp, for example where CLOS
> originally was implemented.

Their convience, and CLOS are examples of how macros extend
LISP. As I tried to explain, I'm not referring to macros as
unnecessary in LISP, but as unnecessary in a different
language design that allows ANY desired feature of macros
through other means and features.

Peaker

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Larry Elmore wrote:

> > You are partially correct. Macros are not necessary, but they also are
> > not a "coverup of language deficiency." They are a convenience. When
> > used appropriately, they allow you to define a language which allows
> > you to write code in a much more concise manner than you otherwise
> > would have to.

The point I tried to make, though, was that the convinience, or ANY other
feature macros can provide, CAN be available by a non-macro language,
and the fact macros ARE indeed a convinence suggests that the language
had a deficiency. The reason I would call that a deficiency, is that to
achieve convinience, you are forced to use inline code, with a lot of potential
name-
space conflicts, and extra complexity on the overall.

> That's the key phrase: "appropriate use". I regard (and use) macros (in any
> language) the same way I do chainsaws -- powerful and sometimes invaluable,
> but only a fool would use them anywhere except where they really are the
> best answer.

Your accurate laser isn't powerful/accurate enough :)

Peaker

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Courageous wrote:
I view a language without metalinguistic constructs as hamstrung.
Java, for example is soooo not extensible. Standard macros in C++
and ANSI C are barely a solution, although the gcc style macros
at least offer variatic argument support. In lisp, I've found that
macros are outright mandatory when you want to pass of a &rest
form to a function which expects that &rest form as not a list. e.g.,

(defun f ( str &rest body )

   `(format t ,str ,@body)
)

(example of writing a format that passes through to format
a bit silly, but gets the point across; hope I got the syntax
right, not at work and don't have all this memorized yet).

Actually, if there's a way of doing that *without* macros, I sure
would like to know about it.

I am not sure if LISP has a way of making that work, but I do know
that in another language design, it would definitely be possible
without the use of a macro.   I am not sure that the Java language
design is complete in removing the need for macros, and I do not
think it is provable that a language makes macros obselete.
However,  I would request that you bring a few cases where
proper C++ macros are necessary (ones that form a complete
syntax expression). Excluding for example:
#define  InproperMacro(x)        ((x) +
Any Java problems resulting from the lack of macros would also be
interesting to view, and perhaps I can offer solutions by either
proposing a more complete language design, or by demonstrating a
non-macro solution that is already existant.
Overall, I like macros, however, as long as the programmer
doesn't go so overboard with them that the code becomes "write
only". :)
I obviously don't like macros :)   As much as I wouldn't like a program
that integrates all functions code (except impossible cases, as recursion)
into callers' function bodies :)

Paolo Amoroso

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
On Sun, 23 Apr 2000 21:58:08 +0000, Peaker <pea...@makif.omer.k12.il>
wrote:

> I would appriciate an example of something a macro can be used for,
>
> for which a function, in a more powerful language (In terms of what
>
> functions can do), cannot be used.

Check:

"On Lisp - Advanced Techniques for Common Lisp"
Paul Graham
Prentice Hall, 1994
ISBN 0-13-030552-9


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Tim Bradshaw

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
* Peaker wrote:

> I am not sure if LISP has a way of making that work, but I do know
> that in another language design, it would definitely be possible
> without the use of a macro. I am not sure that the Java language
> design is complete in removing the need for macros, and I do not
> think it is provable that a language makes macros obselete.
> However, I would request that you bring a few cases where
> proper C++ macros are necessary (ones that form a complete
> syntax expression). Excluding for example:
> #define InproperMacro(x) ((x) +
> Any Java problems resulting from the lack of macros would also be
> interesting to view, and perhaps I can offer solutions by either
> proposing a more complete language design, or by demonstrating a
> non-macro solution that is already existant.

I don't think you get the point of macros. You can obviously cover
any *specific* case where Lisp needs a macro by simply adding that
special case to the syntax of the basic language. But that doesn't
solve the problem at all, because you've lost the generalisation which
is that the language has an extensible syntax, in a way that C and
Java just don't.

I don't understand why you are talking about C++ and Java by the way.

--tim

Tim Moore

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to

On Mon, 24 Apr 2000, Courageous wrote:

>
> > > (defun f ( str &rest body )
> > > `(format t ,str ,@body)
>

Assuming that's
(defmacro f (str &rest body)
`(format t ,str, ,@body))

> > (defun format-t (string &rest args)
> > (apply #'format t string args))
>
>
> Are either of these forms preferred over one another?
> Or is it just a matter of style?

For this kind of simple thing the second is preferred; it's a first-class
function, so you can do a lot more with it. For example:

(defun flexi-format (formats vals)
(mapc #'format-t formats vals))

(flexi-format '("foo: ~S~%" "bar: ~D~%" "naggum: ~@R~%")
'(silade 100 2112))

(It would be an interesting diversion to write flexi-format using only
format strings :)

Tim


Barry Margolin

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
In article <390463E5...@makif.omer.k12.il>,

Peaker <pea...@makif.omer.k12.il> wrote:
>Larry Elmore wrote:
>
>> > You are partially correct. Macros are not necessary, but they also are
>> > not a "coverup of language deficiency." They are a convenience. When
>> > used appropriately, they allow you to define a language which allows
>> > you to write code in a much more concise manner than you otherwise
>> > would have to.
>
>The point I tried to make, though, was that the convinience, or ANY other
>feature macros can provide, CAN be available by a non-macro language,
>and the fact macros ARE indeed a convinence suggests that the language
>had a deficiency. The reason I would call that a deficiency, is that to
>achieve convinience, you are forced to use inline code, with a lot of potential
>name-
>space conflicts, and extra complexity on the overall.

Namespace conflicts are a consequence of a specific macro mechanism.
Scheme, for instance, has hygienic macros, so namespace conflicts are not a
problem. Common Lisp has chosen to keep the macro expansion mechanism
simple, shifting the burden of preventing namespace conflicts onto the
programmer. Even if you don't GENSYM the variables introduced by the
macro, the package system usually prevents unexpected conflicts.

You're correct that macros sometimes indicate a missing feature in the
basic language. But it's impossible to expect language designers to
foresee everything, so macros are the way in which the language evolves.
For instance, MacLisp didn't originally have LET, SETF, or LOOP -- they
were all added to the language using macros, and became so popular that
they were included as built-in features when Common Lisp was being defined.

However, many macros are application-specific, and do not indicate a
language deficiency at all.

--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Jon S Anthony

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Peaker wrote:
>
> Jim Bushnell wrote:
>
> > I suggest that you read "OnLisp" by Paul Graham. He gives many examples of
> > both the convenience aspects of macros, and their use in "language design",
> > and shows how macros extend the power of lisp, for example where CLOS
> > originally was implemented.
>
> Their convience, and CLOS are examples of how macros extend LISP.
> As I tried to explain, I'm not referring to macros as unnecessary in
> LISP, but as unnecessary in a different language design that allows
> ANY desired feature of macros through other means and features.

In other words, a macro system which is not called a macro system.
Not very interesting. Certainly there are no extant programming
languages where you can achieve the same sort of context specific
uplift of the base language that you have with macros.

I think the core issue here is that you don't understand the how, why,
what, and where of Lisp macros. You need to get this square in your
own head before you can even begin further discussion. As someone
else pointed out, Grahm's On Lisp book would be an excellent source
for gaining such understanding.

/Jon

--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari

Jon S Anthony

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Peaker wrote:

> Macros usually have a function-like syntax, and perform 'operations'
>
> on the arguments (is this the right term for the case?) of the macro.
>
> Those operations are commonly unusable on function arguments in the
>
> same way, because function arguments are COPIES of the original values
>
> and not transparentely pointing at them.

You're completely lost. A macro's arguments are the "bits of the
input stream" making up the syntactic elements of the macro call. A
macro is just like a function, it just happens to run at compile time
and _typically_ returns transformed source.

Functions do not get "copies" (whatever this might mean) of their
arguments. They get the current evaluated _values_ of the objects
passed in at a call point during execution. Just like macros.

> This is the most common use of macros, I believe, and is only there
> to make up for a method of calling functions 'By value'.

This has no discernable semantic content.


> Can someone explain to me the advantages of the implicit copying
> when sending 'By value'?

Since this doesn't happen, I believe the answer is no.


You really need to first get an _understanding_ of macros before
proceeding with this, otherwise you will continue to be completely
lost, say incorrect or semantically empty things as if they were fact,
and in the process honk off a bunch of people who do know what is
going on.

Tom Breton

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Courageous <jkra...@san.rr.com> writes:

> > > (defun f ( str &rest body )
> > > `(format t ,str ,@body)
>

> > (defun format-t (string &rest args)
> > (apply #'format t string args))
>
>
> Are either of these forms preferred over one another?
> Or is it just a matter of style?

Well, using a macro instead of a function adds one more level of
indirection, so don't use it unless it accomplishes something extra.

And as someone else pointed out, the function can be used, well,
functionally, the macro can't.

Peaker

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to

> Tim Bradshaw wrote:I don't think you get the point of macros. You can


> obviously cover
> any *specific* case where Lisp needs a macro by simply adding that
> special case to the syntax of the basic language. But that doesn't
> solve the problem at all, because you've lost the generalisation which
> is that the language has an extensible syntax, in a way that C and
> Java just don't.

First, I would be very interested to see where macros are actually used to extend
the LANGUAGE (syntax) and not program model. Second, I would propose converting
all macros to functions, and essentially allow functions to do whatever macros
do in compile-time, OR in run-time, by using either "Syntax Lists" for example,
which can make the fact a certain piece of code is not written in normal LISP but
some new defined syntax explicit. For example, a macro that would expand:
(+ 2 2) to (+ 4 4) and (* 1 3) to (*1 9), can be implemented by sending a
"Syntax list" (for example {(+ 4 4)}, or quoting thee list) to the function, which
can parse the syntax list the same way a macro would. Then I would propose
extending the function paradigm, so that every function can be "expanded" (as a
macro is, in compiletime), whenever it is beneficial to do so.

Another extension to functions that can be used to replace macros, is specifying
certain arguments are to be treated just as macro arguments are, and not to be
evaluated. You may ask what the point of all this is - and I will answer that it
makes the whole definition syntax of functions and macros simpler, more unified
and consistent. It also makes it possible to optimize code to the best desired
efficiency in each instance of the macro/function usage.

The next question I may ask though, is: Are "Syntax Lists" ever useful, or is
there always a simpler, cleaner solution (Which I always seemed to be able to
find)? Why would you want the compile-time language to support new ways to
express programming-related concepts, when the original langugae expresses any
thinkable ones very well?

Harley Davis

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Peaker <pea...@makif.omer.k12.il> wrote in message
news:390463EE...@makif.omer.k12.il...

> Any Java problems resulting from the lack of macros would also be
> interesting to view, and perhaps I can offer solutions by either
> proposing a more complete language design, or by demonstrating a
> non-macro solution that is already existant.

"A more complete language design" seems to mean extending the compiler to
support a new linguistic abstraction. Macros (and let's focus on Lisp
macros in this newsgroup) are precisely a mechanism for a programmer to
express novel linguistic abstractions, thus providing a more complete
language design for their specific problems. You seem to believe the
language designer can and should foresee all such abstractions; the Lisp
philosophy is that the language designer should instead focus on providing
two things:

1. A rich set of base abstractions.
2. A powerful mechanism for defining new abstractions.

From this perspective, it's not clear what your beef with macros really
amounts to.

-- Harley

Joe Marshall

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Barry Margolin <bar...@genuity.net> writes:

> The problem with these types of functions (FEXPRs) is that they complicate
> the evaluation model significantly.

Another problem with FEXPRs, if I understand correctly, is that they
stymie compilation.

~jrm

Jon S Anthony

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Peaker wrote:
>
> > Tim Bradshaw wrote:I don't think you get the point of macros. You can
> > obviously cover
> > any *specific* case where Lisp needs a macro by simply adding that
> > special case to the syntax of the basic language. But that doesn't
> > solve the problem at all, because you've lost the generalisation which
> > is that the language has an extensible syntax, in a way that C and
> > Java just don't.
>

> First, I would be very interested to see where macros are actually
> used to extend the LANGUAGE (syntax) and not program model. Second,
> I would propose converting all macros to functions, and essentially
> allow functions to do whatever macros do in compile-time, OR in
> run-time, by using either "Syntax Lists" for example,

...


> Why would you want the compile-time language to support new ways to
> express programming-related concepts, when the original langugae
> expresses any thinkable ones very well?

PLEASE, get a book (some have already been suggested) and learn
something about this before you proceed any further. All the above
shows you are _completely_ lost on this subject and need to get some
very basic fundamental things straight before you even begin any more
attempts at discussion. If you continue wasting everyone's time and
bandwidth making pronouncements that show an utter lack of
understanding (while stating them as if fact) you will only succeed in
starting an irrelevant flame war.

Or are you just a troll and starting such a flame fest is your real
intent??

Barry Margolin

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
In article <3904DA09...@makif.omer.k12.il>,

Peaker <pea...@makif.omer.k12.il> wrote:
>First, I would be very interested to see where macros are actually used to extend
>the LANGUAGE (syntax) and not program model.

I mentioned several examples in my earlier message: SETF, LET, and LOOP
were originally macros that extended the Maclisp language.

>Another extension to functions that can be used to replace macros, is specifying
>certain arguments are to be treated just as macro arguments are, and not to be
>evaluated. You may ask what the point of all this is - and I will answer that it
>makes the whole definition syntax of functions and macros simpler, more unified
>and consistent. It also makes it possible to optimize code to the best desired
>efficiency in each instance of the macro/function usage.

Maclisp had something called "fexprs" that were functions that received
their arguments unevaluated. Zetalisp implemented a variant of this by
having &QUOTE and &EVAL lambda list keywords, to indicate that the
arguments between them should not be evaluated. The problem with these
types of functions is that they complicate the evaluation model
significantly, since it's often the case that you want to evaluate those
functions eventually; it's just being deferred so that the evaluation can
be done in a special way (for instance, you might be defining a conditional
like COND or IF, which should only evaluate certain arguments or parts of
arguments). But in a lexically-scoped language, you then have to arrange
for the evaluation to take place in the proper environment (Maclisp was
dynamically scoped, so this wasn't an issue -- the fexpr could simply call
EVAL).

Macros make this all much, much easier, which is why little consideration
at all was given to including user-defined special operators in Common
Lisp. Pretty much anything you could do with fexprs can be done just as
easily with macros. The evaluation model of macros is simple, so no
special hooks into the evaluator are needed.

Christopher Browne

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Centuries ago, Nostradamus foresaw a time when Peaker would say:

>Larry Elmore wrote:
>
>> > You are partially correct. Macros are not necessary, but they also are
>> > not a "coverup of language deficiency." They are a convenience. When
>> > used appropriately, they allow you to define a language which allows
>> > you to write code in a much more concise manner than you otherwise
>> > would have to.
>
>The point I tried to make, though, was that the convinience, or ANY other
>feature macros can provide, CAN be available by a non-macro language,
>and the fact macros ARE indeed a convinence suggests that the language
>had a deficiency. The reason I would call that a deficiency, is that to
>achieve convinience, you are forced to use inline code, with a lot of potential
>name-space conflicts, and extra complexity on the overall.

I think this misses the point.

A fuzzy substitution of
s/macro/recursion/
provides:

"The convenience, or any other feature, that recursion can provide,
CAN be made available via explicit use of stacks, in a nonrecursive
language. The fact that recursions _are indeed_ a convenience
suggests that the language had a deficiency. The reasoning is that
to achieve convenience, you have to have functions call themselves,
with potential namespace conflicts, and overall additional
complexity."

Trolls periodically wander to comp.lang.lisp, actually claiming things
similar to the above statement.

I could add in any language feature that is a "convenience" and
contend that the desirability of addition of the "convenience" is
indicative of the language having some deficiency.

Reduction can thus continue to the point of absurdity until we arrive
at some language that be trivally encoded onto one of the minimal
Turing Machine representations.

The _real_ point is that if some language abstraction makes it
considerably more _convenient_ to build a notation to represent the
characteristics of a particular problem, this is a useful thing, and
is quite likely to be desirable.

--
BASIC is not a language. It's a plot to sucker poor unsuspecting
consumers into believing that they should buy a computer because
ANYONE can learn how to program.
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

Tim Bradshaw

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
* Peaker wrote:

> First, I would be very interested to see where macros are actually used to extend
> the LANGUAGE (syntax) and not program model.

LOOP, DEFUN, LAMBDA...

> [Elided stuff where you give what looks like a grotesquely
> over-complex equivalent to macros]

Would it not be easier simply to allow the language to have functions
which operate on a representation of its source code, to produce other
source code?

> The next question I may ask though, is: Are "Syntax Lists" ever useful, or is
> there always a simpler, cleaner solution (Which I always seemed to be able to

> find)? Why would you want the compile-time language to support new ways to


> express programming-related concepts, when the original langugae expresses any
> thinkable ones very well?

Because that's what Lisp is *about*! If you don't see that this is
just fundamental to the Lisp approach then you need to learn something
about the way it works. If you want some fixed little language, then
program in C or hex, and leave us to do our own thing.

--tim


Courageous

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to

> Assuming that's
> (defmacro f (str &rest body)
> `(format t ,str, ,@body))

Thanks for the help, everybody. Looking at my code today,
it was much worse than what the (defmacro...) form you
all assumed it was. It was actually embedded in an eval
inside a defmethod; a syntactically horrific aberration
that existed primary because I ,@ was the way I knew how
to do what I needed to do.

One poster pointed me to list* the same time he pointed
me to apply. Most helpful. I also got a good half dozen
explanations in my email box of the same thing, but
better more than less.

Thanks again,


C/

Frode Vatvedt Fjeld

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to

> > > (defun f ( str &rest body )
> > > `(format t ,str ,@body)
>
> > (defun format-t (string &rest args)
> > (apply #'format t string args))
>

Courageous <jkra...@san.rr.com> writes:

> Are either of these forms preferred over one another? Or is it just
> a matter of style?

Those two functions perform two completely different tasks, so I guess
the answer is no; it is not a matter of style. If you can't see that,
I'd suggest you study the _basics_ of lisp more carefully before you
try to understand the finer points of lisp style.


Tom Breton <t...@world.std.com> writes:

> Well, using a macro instead of a function adds one more level of
> indirection, so don't use it unless it accomplishes something extra.

What do you mean by "one more level of indirection"? Myself, while
programming lisp, _very_ rarely make considerations like "should I use
a macro for this or a function". That _was_ something I did when
programming C, however. In lisp, macros and functions are used for
completely different things (more or less), although they accomplish
it by the same interface (the lisp language).

--
Frode Vatvedt Fjeld

Erik Naggum

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
* Peaker <pea...@makif.omer.k12.il>

| I have been thinking a lot about language design lately.

it is important to have an explicit goal when thinking about language
design. your goal seems implicit, given that you don't mention it at
all. could you talk a little bit about what you want to accomplish?

| This has made me doubt the real necessity of macros, as they always seem
| to cover up for one or another language deficiency.

yes, that's what they do. the problem is, however, that _solving_ all
those deficiencies is impossible, and without macros, they would merely
be visible deficiencies, instead of covered-up deficiencies. now, macros
may cover up deficiencies so well that it would take an inordinate amount
of deconstructionism to find the deficiency, but I take this as evidence
that "cover up" is misapplied: the deficiency no longer _exists_ because
of the macro solution.

in short, macros are about building languages. _any_ such facility would
be messy if it were able to do its job well, and it would only be "neat"
if it were able to build things people had thought of while designing it.
trust me on this: we don't want that.

the core problem I sense in your approach to your language design has
been discussed at times, but seldom directly, so I'll summarize my
position on it and see if you recognize it: (Common) Lisp is such an
obviously elegant solution to the programming language problem that when
people look carefully at it, they get disappointed by warts and spots
with a rough finish, and then they start to think about how the language
would be if it were _all_ elegant. other languages are equally obvious
inelegant solutions to the programming language problem, and individual
features are hailed as elegant (or "cool hacks") when discovered, which
means that digging deeper uncovers isolated inelegances in Common Lisp
and isolated elegances in most other languages. since we all appreciate
more elegance rather than less, users of inelegant languages learn by the
rewards they get from doing it that digging deeper in particular ways is
a good way to _improve_ their language appreciation, and so they continue
with this habit when they come to Common Lisp, only to be disappointed.
if you don't realize the ramifications of this reversal, you will lose
track of the big picture: you should not need to dig deep into a language
to find its elegance, and it doesn't matter whether the innards that you
don't know about are inelegant.

#:Erik

Rolf Rander Naess

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
[ Christopher Browne, 25 Apr 2000 00:58 ]

> BASIC is not a language. It's a plot to sucker poor unsuspecting
> consumers into believing that they should buy a computer because
> ANYONE can learn how to program.

Great fun!

And following your example with fuzzy substitution, I get the
following:

WINDOWS is not an os. It's a plot to sucker poor unsuspecting


consumers into believing that they should buy a computer because

ANYONE can learn how to use it.

:-)


Rolf Rander

--
(c) 2000 Rolf Rander Næss
http://www.pvv.org/~rolfn/

My mailer limits .sigs to 4 lines. But ingeniously I bypassed this by

Barry Margolin

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
In article <ukwln225k...@pvv.org>,

Rolf Rander Naess <rolfn...@pvv.org> wrote:
>[ Christopher Browne, 25 Apr 2000 00:58 ]
>> BASIC is not a language. It's a plot to sucker poor unsuspecting
>> consumers into believing that they should buy a computer because
>> ANYONE can learn how to program.
>
>Great fun!
>
>And following your example with fuzzy substitution, I get the
>following:
>
>WINDOWS is not an os. It's a plot to sucker poor unsuspecting
>consumers into believing that they should buy a computer because
>ANYONE can learn how to use it.

While I certainly don't consider BASIC to be the epitome of programming
languages, I don't think I would be where I am today if it weren't for
BASIC. It allowed me to learn programming on my own pretty easily at a
time when there weren't many resources (the late 70's).

David Hanley

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to

Peaker wrote:

> > Tim Bradshaw wrote:I don't think you get the point of macros. You can
> > obviously cover
> > any *specific* case where Lisp needs a macro by simply adding that
> > special case to the syntax of the basic language. But that doesn't
> > solve the problem at all, because you've lost the generalisation which
> > is that the language has an extensible syntax, in a way that C and
> > Java just don't.
>

> First, I would be very interested to see where macros are actually used to extend
> the LANGUAGE (syntax) and not program model.

Look at it this way: you can take lisp, without many language features, and
build in most of it's features via macros. Even very basic things such as
do, loop, dolist, defun, let, and let*.

> Second, I would propose converting
> all macros to functions, and essentially allow functions to do whatever macros
> do in compile-time, OR in run-time, by using either "Syntax Lists" for example,

> which can make the fact a certain piece of code is not written in normal LISP but
> some new defined syntax explicit. For example, a macro that would expand:
> (+ 2 2) to (+ 4 4) and (* 1 3) to (*1 9), can be implemented by sending a
> "Syntax list" (for example {(+ 4 4)}, or quoting thee list) to the function, which
> can parse the syntax list the same way a macro would. Then I would propose
> extending the function paradigm, so that every function can be "expanded" (as a
> macro is, in compiletime), whenever it is beneficial to do so.

Very nice, but what's the point? What you're suggesting is already very like
macros anyways. There are ways to design languages that are conceptually
cleaner than lisp ( *gasp* ) but lisp is largely about getting the job done. It's
elegance that it has is there in cases where it makes coding in it easier. After
all, compilers are already allowed to inline function as they see fit.

I was designing a language for myself as an exercise that was extremely elegant
and conceptually concise, but I asked myself, would it be easier to write code in
this as opposed to lisp? I realized that it really was not, but it was still an
interesting exercise.

dave


Phil Stubblefield

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Joe Marshall <jmar...@alum.mit.edu> wrote:
>
> [...]

>
> Here's how I use macros:
>
> 1. Creating new concise syntax for a particular problem:
>
> (define-alu-operation MOVI (register destination) (immediate value))
>
> 2. Creating new language extensions that deliberately mimic existing
> special forms. For example, you could imagine a macro called
> TOGGLEF that was essentially (SETF ,place (NOT ,place)). Then you
> would call (togglef (light-switch (current-room)))
>
> 3. Extending other macros or abstracting certain features that cannot
> be done via functions.
>
> (with-log-file (stream "foo") ...) =>
> (with-open-file (stream (make-pathname :name "foo" :type "log")
> :direction :output :if-does-not-exist :create)
> ....)
>
> 4. Truly hairy preprocessing (examples would be too large to include).

*Excellent* examples! I too use macros for all of these purposes.

> I generally avoid using macros just to delay argument evaluation. It
> is just as easy to wrap a LAMBDA around the appropriate argument, and
> it avoids creating code that isn't applicative order. So you might
> see this in my code:
>
> (call-with-temp-file #'(lambda (file) ....))
>
> whereas other lisp hackers would write a macro
>
> (with-temp-file (file) ....)
>
> Obviously, I was brought up on the wrong side of the tracks.

I nearly always define, document, and export both: the macro WITH-xxx
expands into the function CALL-WITH-xxx. Or in the case of iteration
constructs, DO-xxx expands into MAP-xxx. The user (often me!) can
then use whichever is more convenient in a specific context. I find
that if I just take the time to define both such constructs whenever I
first see the need for one of them, then I eventually find a natural
use for the other.

Or perhaps it's just my increasingly anal-retentive nature.... ;)


Phil Stubblefield
Rockwell Palo Alto Laboratory 206/655-3204
http://www.rpal.rockwell.com/~phil ph...@rpal.rockwell.com

Barry Margolin

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
In article <39060F95...@rpal.rockwell.com>,
Phil Stubblefield <ph...@rpal.rockwell.com> wrote:

>Joe Marshall <jmar...@alum.mit.edu> wrote:
>> I generally avoid using macros just to delay argument evaluation. It
>> is just as easy to wrap a LAMBDA around the appropriate argument, and
>> it avoids creating code that isn't applicative order. So you might
>> see this in my code:
>>
>> (call-with-temp-file #'(lambda (file) ....))
>>
>> whereas other lisp hackers would write a macro
>>
>> (with-temp-file (file) ....)
>>
>> Obviously, I was brought up on the wrong side of the tracks.
>
>I nearly always define, document, and export both: the macro WITH-xxx
>expands into the function CALL-WITH-xxx.

Many of Symbolics's macros are implemented this way. It solves the name
clash problem often without requiring any GENSYMs.

If users had to write out all the CALL-WITH-xxx forms, it would have been
much less convenient to use things like the table formatting facility.
Compare:

(formatting-table (...)
(dolist ...
(formatting-row (...)
(present x)
(present y))))

with:

(call-with-table-formatting ...
:function
#'(lambda (stream)
(dolist ...
(call-with-row-formatting ...
:function #'(lambda (stream)
(present x stream)
(present y stream))))))

I know which one I find easier to read, because it doesn't have lots of
lambda's strewn about.

It's certainly possible to program in a Lisp-like language that merely has
lambda and the Y combinator, but I wouldn't want to. It's analogous to
writing in assembly language -- we design high-level languages to abstract
away all these details. Macros give that power to the programmer, not just
the language designer.

Christopher Browne

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to

--

BASIC is not a language. It's a plot to sucker poor unsuspecting
consumers into believing that they should buy a computer because
ANYONE can learn how to program.

cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

Kragen Sitaker

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
In article <LciN4.14$my3.569@burlma1-snr2>,

Barry Margolin <bar...@genuity.net> wrote:
>While I certainly don't consider BASIC to be the epitome of programming
>languages, I don't think I would be where I am today if it weren't for
>BASIC. It allowed me to learn programming on my own pretty easily at a
>time when there weren't many resources (the late 70's).

When I was ten, I could write all kinds of graphics stuff in BASIC, so
I thought I was a terrific programmer. Nobody could teach me anything;
I was convinced I knew all there was to know about programming.

I didn't really grasp the idea of a subroutine, though --- even though
I'd learned to write recursive subroutines in Logo years before, I
never really caught on.

Later on (when I was twelve?) I took another Logo class and started
doing more significant things (including programs composed of multiple
subroutines). But it wasn't until I was forced to take a Pascal class
that I really began to realize how much I had to learn. [I'm still not
sure I've shed that youthful arrogance, unfortunately.]

The languages one writes in guide one's mind --- they're not the only
influence, nor even the most important, but they are significant.

BASIC guides one to focus on syntax and makes things like local
variables, subroutines, parameter passing, and dynamic data structures
difficult enough that a novice like me would have had to invent and
implement them from scratch (and they would be more difficult than in
assembly, in fact).

Lisp guides one to treat syntax as trivial, to take dynamic data
structures, local variables, and subroutines for granted, and to focus
on the computation rather than the program.
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)

Christopher Browne

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Centuries ago, Nostradamus foresaw a time when Barry Margolin would say:

>In article <ukwln225k...@pvv.org>,
>Rolf Rander Naess <rolfn...@pvv.org> wrote:
>>[ Christopher Browne, 25 Apr 2000 00:58 ]
>>> BASIC is not a language. It's a plot to sucker poor unsuspecting
>>> consumers into believing that they should buy a computer because
>>> ANYONE can learn how to program.
>>
>>Great fun!
>>
>>And following your example with fuzzy substitution, I get the
>>following:
>>
>>WINDOWS is not an os. It's a plot to sucker poor unsuspecting

>>consumers into believing that they should buy a computer because
>>ANYONE can learn how to use it.

>
>While I certainly don't consider BASIC to be the epitome of programming
>languages, I don't think I would be where I am today if it weren't for
>BASIC. It allowed me to learn programming on my own pretty easily at a
>time when there weren't many resources (the late 70's).

The "real" BASICs deployed from Dartmouth, as well as the ANSI and ISO
Standard BASICs are a far cry different from Microsoft BASIC. They
actually had matrix operators, for instance.

I've got an even more entertaining commentary on LOGO...

"LOGO is not a language. It's a way to simulate 'skid marks' made by
turtles with serious bowel control problems."

And I _do_ know that LOGO was the nearest "educational" equivalent
to Lisp... Probably about as much like CL as Scheme is...
--
Know the list of "large, chronic problems". If there is any problem
with the window system, blame it on the activity system. Any lack of
user functionality should be attributed to the lack of a command
processor. A suprisingly large number of people will believe that you
have thought in depth about the issue to which you are alluding when you
do.
-- from the Symbolics Guidelines for Sending Mail
cbbr...@hex.net - - <http://www.hex.net/~cbbrowne/lsf.html>

Tom Breton

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Frode Vatvedt Fjeld <fro...@acm.org> writes:

>
>
> Tom Breton <t...@world.std.com> writes:
>
> > Well, using a macro instead of a function adds one more level of
> > indirection, so don't use it unless it accomplishes something extra.
>
> What do you mean by "one more level of indirection"?

Sorry, I don't see what could be unclear. One more level of
indirection; an extra level above and beyond whatever layers of
indirection you have already used. Does that answer your question?

Perhaps you are thinking solely in terms of run-time indirection? Is
that the difficulty? I mean one more level of indirectness in
representation, if that's any help.

Tom Breton

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to

> BASIC is not a language. It's a plot to sucker poor unsuspecting
> consumers into believing that they should buy a computer because
> ANYONE can learn how to program.

> cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

Hey, it worked on me. (More exactly, it was my dad's TRS-80 when I
was a wee child)

Frode Vatvedt Fjeld

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to

Frode Vatvedt Fjeld <fro...@acm.org> writes:

> What do you mean by "one more level of indirection"?


Tom Breton <t...@world.std.com> writes:

> Perhaps you are thinking solely in terms of run-time indirection?
> Is that the difficulty? I mean one more level of indirectness in
> representation, if that's any help.

I'm not thinking in terms of anything, as "indirection" is such a
general term. Representation of what? Code? That would translate in my
terms to "one more level of code transformation", and I don't really
see why you'd want to worry about that, in general.

--
Frode Vatvedt Fjeld

Fernando D. Mato Mira

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Barry Margolin wrote:

> While I certainly don't consider BASIC to be the epitome of programming
> languages, I don't think I would be where I am today if it weren't for
> BASIC. It allowed me to learn programming on my own pretty easily at a
> time when there weren't many resources (the late 70's).

The only reason I learnt BASIC is because I couldn't find a Lisp compiler
for my Timex/Sinclair 2068 (the early 80's) ;-(

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (78) 778 FDMM
Switzerland 3366

www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html


Marc Battyani

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Fernando D. Mato Mira <mato...@acm.org> wrote in message
news:3906FBE1...@acm.org...

> The only reason I learnt BASIC is because I couldn't find a Lisp compiler
> for my Timex/Sinclair 2068 (the early 80's) ;-(

I had more luck. At that time there were LeLisp 80 on the TRS-80.
It worked well with 48Ko of RAM and a 128Ko floppy disk....

Marc Battyani

Fernando D. Mato Mira

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Marc Battyani wrote:

^^^^^^^^^^^^^^^^^

I hate you ;)

--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org

CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720

www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html


Tom Breton

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Frode Vatvedt Fjeld <fro...@acm.org> writes:

> Frode Vatvedt Fjeld <fro...@acm.org> writes:
>
> > What do you mean by "one more level of indirection"?
>
>
> Tom Breton <t...@world.std.com> writes:
>
> > Perhaps you are thinking solely in terms of run-time indirection?
> > Is that the difficulty? I mean one more level of indirectness in
> > representation, if that's any help.
>
> I'm not thinking in terms of anything, as "indirection" is such a
> general term. Representation of what? Code?

Yes.

> That would translate in my
> terms to "one more level of code transformation",

Yes.

> and I don't really
> see why you'd want to worry about that, in general.

All else being equal, it's better to make fewer transformations on
your code; it's less machinery to think about. IMO. Don't you agree?

Rahul Jain

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
In article <m3r9bsb...@world.std.com> posted on Wednesday,

April 26, 2000 11:45 AM, Tom Breton <t...@world.std.com> wrote:

> All else being equal, it's better to make fewer transformations on
> your code; it's less machinery to think about. IMO. Don't you agree?
>

Why would you make a macro if it made writing the code harder?
The point of a macro is to allow for certain constructs which make
writing code easier. Maybe you need to rething why you're writing
whichever macros make writing code harder for you.

--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- mailto:rahul...@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.


Tim Bradshaw

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
* Tom Breton wrote:

> All else being equal, it's better to make fewer transformations on
> your code; it's less machinery to think about. IMO. Don't you agree?

High-level languages are a pretty good indicator that all else is
seldom equal.

--tim

Frode Vatvedt Fjeld

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Tom Breton <t...@world.std.com> writes:

> All else being equal, it's better to make fewer transformations on
> your code; it's less machinery to think about. IMO. Don't you
> agree?

Yes, but if all else was equal, I'd have to call you a lousy macro
writer, no? You shouldn't write a macro unless it gives you some extra
benifit. The benifit should however be great enough to justify the
additional syntax the programmer has to remember, as was discussed in
a thread some weeks ago. But this applies equally to macros and
functions.

--
Frode Vatvedt Fjeld

Erik Naggum

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
* Tom Breton <t...@world.std.com>

| All else being equal, it's better to make fewer transformations on
| your code; it's less machinery to think about. IMO. Don't you
| agree?

I don't agree with this silliness. good macros are abstractions.
I also don't agree with your view of optimization, which seems to
include manual macroexpansion and reducing the amount of work no
human being should ever be doing in the first place. I'm also glad
you don't read this, as I would hate to see the silly response.

#:Erik

Peaker

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
> yes, that's what they do. the problem is, however, that _solving_ all
> those deficiencies is impossible, and without macros, they would merely
> be visible deficiencies, instead of covered-up deficiencies. now, macros
> may cover up deficiencies so well that it would take an inordinate amount
> of deconstructionism to find the deficiency, but I take this as evidence
> that "cover up" is misapplied: the deficiency no longer _exists_ because
> of the macro solution.

Language extension is a reasonable use for such a facility, however, the
problem is, that a common use of macros is not only to extend the language
and its syntax, but also to extend the program model.
Drawing the line between the program model and the language itself, is not
as easy as it may seem, given that function calls are very syntatically close

to special forms or macro forms. What may seem as an extension of the
language itself, under one definition ('if', for example), would seem as the
extension of the program or object model under another ('if' being a method
of a 'Boolean' object).

> in short, macros are about building languages. _any_ such facility would
> be messy if it were able to do its job well, and it would only be "neat"
> if it were able to build things people had thought of while designing it.
> trust me on this: we don't want that.

I understand what you're saying, and I'd take your word if I wasn't
after understanding it myself. Therefore, I would appriciate some small
examples of language extensions that are NOT possible to implement as an
object-model extension, using, for example, SmallTalk.
(The point of this, is to verify that the functionality of extending the
syntax,
achievable by macros, cannot be achieved using extensions to the object
model [Of a language that has built-in object support, ofcourse])

> the core problem I sense in your approach to your language design has
> been discussed at times, but seldom directly, so I'll summarize my
> position on it and see if you recognize it: (Common) Lisp is such an
> obviously elegant solution to the programming language problem that when
> people look carefully at it, they get disappointed by warts and spots
> with a rough finish, and then they start to think about how the language
> would be if it were _all_ elegant. other languages are equally obvious
> inelegant solutions to the programming language problem, and individual
> features are hailed as elegant (or "cool hacks") when discovered, which
> means that digging deeper uncovers isolated inelegances in Common Lisp
> and isolated elegances in most other languages. since we all appreciate
> more elegance rather than less, users of inelegant languages learn by the
> rewards they get from doing it that digging deeper in particular ways is
> a good way to _improve_ their language appreciation, and so they continue
> with this habit when they come to Common Lisp, only to be disappointed.
> if you don't realize the ramifications of this reversal, you will lose
> track of the big picture: you should not need to dig deep into a language
> to find its elegance, and it doesn't matter whether the innards that you
> don't know about are inelegant.

Some unnecessary inelligence of macros does appear to exist in the used-level:

the macro definitions themselves. I would suggest a small change to the macro

system, that in my oppinion, would make it more elegant: Allow 'unevaluated
parameters' to functions (macro-parameters), that would effectively turn them
into compile-time or (using run-time expression representations) run-time
functions. This would require unifying functions and macros, and allowing
both to be "expanded" or "executed", as the compiler sees fit for the case.

--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).


Barry Margolin

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
In article <3907660B...@yahoo.com>, Peaker <GNUP...@yahoo.com> wrote:
>Language extension is a reasonable use for such a facility, however, the
>problem is, that a common use of macros is not only to extend the language
>and its syntax, but also to extend the program model.
>Drawing the line between the program model and the language itself, is not
>as easy as it may seem, given that function calls are very syntatically close
>to special forms or macro forms. What may seem as an extension of the
>language itself, under one definition ('if', for example), would seem as the
>extension of the program or object model under another ('if' being a method
>of a 'Boolean' object).

Notice that in a language like Smalltalk, where 'if' is a method rather
than a macro or special operator like it is in Lisp, you have to wrap the
consequent clauses in special syntax to prevent them from being evaluated
prematurely. Smalltalk has made this convenient by using a simple syntax,
[...], for what Lisp uses LAMBDA expressions for; the brackets look similar
to the braces or begin/end keywords that many languages require as part of
their conditional syntax, so programmers hardly realize that they're doing
it.

So, basically, this all really comes down to different varieties of
syntactic sugar. The Smalltalk philosophy is to try to do as much as
possible using the object model, and they've made it easy to deal with
program blocks as objects. Lisp has first-class functions as well, and we
could do things similarly, but we've chosen instead to use them more
sparingly, prefering to use macros to hide things like this.

>Some unnecessary inelligence of macros does appear to exist in the used-level:
>the macro definitions themselves. I would suggest a small change to the macro
>system, that in my oppinion, would make it more elegant: Allow 'unevaluated
>parameters' to functions (macro-parameters), that would effectively turn them
>into compile-time or (using run-time expression representations) run-time
>functions. This would require unifying functions and macros, and allowing
>both to be "expanded" or "executed", as the compiler sees fit for the case.

As I mentioned a day or two ago, this was tried, and found lacking. Doing
it portably would require standardizing too much of the way that the
compiler works.

You seem to be rejecting macros precisely because of the features that make
them so great. They're a very simple mechanism that is nonetheless quite
elegant and powerful. Given a handful of primitive special forms and a
fully-programmable macro language like Lisp's, you can implement just about
any language extension.

David Hanley

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to

Tom Breton wrote:

>
> All else being equal, it's better to make fewer transformations on
> your code; it's less machinery to think about. IMO. Don't you agree?

Actually, no, I don't see that that necessarily correlates. It's possible that
fewer transformations might mean the programmer having to write more
code, and harder code, to get the same job done.

dave


Bijan Parsia

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
Peaker <GNUP...@yahoo.com> wrote:

[snip]


> > in short, macros are about building languages. _any_ such facility would
> > be messy if it were able to do its job well, and it would only be "neat"
> > if it were able to build things people had thought of while designing it.
> > trust me on this: we don't want that.
>
> I understand what you're saying, and I'd take your word if I wasn't
> after understanding it myself. Therefore, I would appriciate some small
> examples of language extensions that are NOT possible to implement as an
> object-model extension, using, for example, SmallTalk.

Quick note: it's spelled 'Smalltalk'.

Quick caveat: I'm not a Common Lisper, though I do know something of the
langauge. I know Scheme much better which may or may not be a handicap
in the current situation. I'm comming in as a Smalltalker.

(OK, the caveat wasn't so quick...)

My understanding of Lispy macros is that they provide for the
modification or extension of *syntax*, in essence allowing one to add
new special forms. In Smalltalk, at least in most implementations, if
you wish to change the *syntax*, you modify the parser. This is rather
easy, given the simplicity of the base syntax and the availability of
the parsing classes. But it's a rather different style of operation, and
certainly not as flexible or scalable as the macro approach (for the
obvious reasons: changes are global, and the more special cases you add
the more complicated the parser gets).

Now, it's quite easy to change the object model (e.g., to prototypes)
and, thus, to get a rather different langauge (tailored to the
application domain, one might say), but the basic syntactic and statment
level evaluation mechanism don't change.

(Obviously, this is much more like using the MOP. So, perhaps, if you
were to compare the kind of "language extension" achieved via the MOP
and that achieved via macros, you might get a better sense of the vital
difference. It seems instructive that *both* mechanisms are present in
Common Lisp.)

Of course, I find it more congenial to look at Smalltalk's syntax as
*one* way, of many, of manipulating the system of objects embodied in
the image. A way that is coequal to other "IDE" tools. Again, a rather
different approach.

I'll add that in Smalltalk-72 (?...it might be Smalltalk-76) one could
change the syntax on a per class basis, though I confess to be ignorant
of the details.

Oh, one should probably point at Prolog as well, with it's op function
which allows one to define the associtivity and precedence of arbitrary
predicates. Very handy for quickly building domain specific sugar.

--
Bijan Parsia
http://monkeyfist.com/
...among many things.

Tim Bradshaw

unread,
Apr 27, 2000, 3:00:00 AM4/27/00
to
* Peaker wrote:
> Some unnecessary inelligence of macros does appear to exist in the used-level:

> the macro definitions themselves. I would suggest a small change to the macro

> system, that in my oppinion, would make it more elegant: Allow 'unevaluated
> parameters' to functions (macro-parameters), that would effectively turn them
> into compile-time or (using run-time expression representations) run-time
> functions. This would require unifying functions and macros, and allowing
> both to be "expanded" or "executed", as the compiler sees fit for the case.

That's what fexprs were. There's a reason they went away. In 41
years a lot of things have been tried in Lisp...

--tim

Christopher Browne

unread,
Apr 27, 2000, 3:00:00 AM4/27/00