From: Peaker
Subject: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390371F0.36455F4E@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.
- 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).
From: David J. Cooper
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <pmqem7w5w45.fsf@lang.genworks.com>
Peaker <······@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
·······@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
From: Larry Elmore
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8e07hr$g86$1@news.campuscwix.net>
"David J. Cooper" <·······@genworks.com> wrote in message
····················@lang.genworks.com...
> Peaker <······@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
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390463E5.3A830456@makif.omer.k12.il>
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 :)
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <631N4.23$Bf1.1275@burlma1-snr2>
In article <·················@makif.omer.k12.il>,
Peaker <······@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, ······@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.
From: Christopher Browne
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <e56N4.15969$VR.393203@news5.giganews.com>
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.
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Rolf Rander Naess
Subject: OFFTOPIC: basic... (was: Are macros really a neccessity...)
Date:
Message-ID: <ukwln225kg3.fsf_-_@pvv.org>
[ 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
From: Barry Margolin
Subject: Re: OFFTOPIC: basic... (was: Are macros really a neccessity...)
Date:
Message-ID: <LciN4.14$my3.569@burlma1-snr2>
In article <··················@pvv.org>,
Rolf Rander Naess <··········@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).
--
Barry Margolin, ······@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.
From: Fernando D. Mato Mira
Subject: Re: OFFTOPIC: basic... (was: Are macros really a neccessity...)
Date:
Message-ID: <3906FBE1.8ADEC22A@acm.org>
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
Fernando D. Mato Mira <········@acm.org> wrote in message
······················@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
From: Fernando D. Mato Mira
Subject: Re: OFFTOPIC: basic... (was: Are macros really a neccessity...)
Date:
Message-ID: <390719A8.4AEE00E3@acm.org>
Marc Battyani wrote:
> Fernando D. Mato Mira <········@acm.org> wrote in message
> ······················@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....
^^^^^^^^^^^^^^^^^
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
Marc Battyani <·············@csi.com> wrote in message
·······················································@lp.airnews.net...
> Fernando D. Mato Mira <········@acm.org> wrote in message
> ······················@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
>
>
There was also Lisp/80 from Software Toolworks which ran on Heath H89 8 bit
systems,
cheap but slow,
and then muLISP-80, much better, for CP/M and later muLISP-82 for MS-DOS.
muLISP-90 is still good if you must target a DOS machine.
I learned lisp after frustration trying to write a fairly large program in
basic.
-Stan Schwartz
From: Derek Peschel
Subject: Re: OFFTOPIC: basic... (was: Are macros really a neccessity...)
Date:
Message-ID: <slrn8hbojl.p4i.dpeschel@eskimo.com>
In article <······················@news1.wwck1.ri.home.com>,
Stanley Schwartz wrote:
>There was also Lisp/80 from Software Toolworks which ran on Heath H89 8 bit
>systems,
>cheap but slow,
>and then muLISP-80, much better, for CP/M and later muLISP-82 for MS-DOS.
>muLISP-90 is still good if you must target a DOS machine.
>I learned lisp after frustration trying to write a fairly large program in
>basic.
Just a note for computer historians and Apple ][ fans...
muLISP has a companion package called muMATH, which evolved into Derive for
DOS and Windows. There are two Apple ][ versions of muMATH (one for a CP/M
card and the other a native program that used a CP/M-like operating system
called ADIOS). I believe the situation is the same for muLISP. Both
packages were distributed by our old friend Microsoft, who also sold a CP/M
card.
*shameless beg* Anyone know where I can get a copy of the native version of
muLISP? I already have an original package of the native version of muMATH
and I want to expand my collection. :)
-- Derek
In article <················@burlma1-snr2>,
Barry Margolin <······@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.
--
<······@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. :)
From: Stig Hemmer
Subject: Re: OFFTOPIC: basic... (was: Are macros really a neccessity...)
Date:
Message-ID: <ekv7ldeqisv.fsf@verden.pvv.ntnu.no>
> In article <················@burlma1-snr2>,
> Barry Margolin <······@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).
There was a time when I used to think this too.
Quite recently I understood that in reality, this quote:
······@dnaco.net (Kragen Sitaker) writes:
> 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.
is only too true for me as well. (Well, Pascal rather than Logo)
I did pick up on subroutines for readability reasons, but didn't
really get the "a function as an interesting object" concept under my
skin before reading SICP last year. (Which is kinda odd, since I knew
it well from mathematics)
I still haven't _quite_ gotten it, I think, but at least I'm looking
in the right direction now.
I'm quite sure that learning Basic at a young age was better than not
touching a computer at all, but one can only wonder how things would
have worked out if I my first exposure to computing had been Lisp way
back when...
Stig Hemmer,
Jack of a Few Trades.
From: Christian Lynbech
Subject: Re: OFFTOPIC: basic... (was: Are macros really a neccessity...)
Date:
Message-ID: <ofitwukar5.fsf@chl.tbit.dk>
I got a total different view of BASIC (and many other programming
languages) when I happened to stumble across the proceedinngs from the
first HOPL (History Of Programming Languages).
Reading about some of the ideas and thoughts that actually went into
the creation of BASIC was an enlightening experience.
---------------------------+--------------------------------------------------
Christian Lynbech | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J
Fax: +45 8675 6881 | email: ···@ericssontelebit.com
Phone: +45 8675 6828 | web: www.ericssontelebit.com
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Centuries ago, Nostradamus foresaw a time when Barry Margolin would say:
>In article <··················@pvv.org>,
>Rolf Rander Naess <··········@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
········@hex.net - - <http://www.hex.net/~cbbrowne/lsf.html>
From: Tom Breton
Subject: OT digression Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m38zy18u90.fsf_-_@world.std.com>
> 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.
> ········@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)
--
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.
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.
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3903A68C.809F7F98@san.rr.com>
> 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/
From: Robert Monfera
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3903BD4C.228B6B20@fisec.com>
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
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <3903C0F4.AC120BF7@san.rr.com>
> > 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/
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <3903C2C1.E7D07BE9@san.rr.com>
Courageous wrote:
>
> > > 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.
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/
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <3903C3B9.71E8EF71@san.rr.com>
> > (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/
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <m33dobqgka.fsf@world.std.com>
Courageous <········@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.
--
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.
From: Frode Vatvedt Fjeld
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <2h66t6r32w.fsf@dslab7.cs.uit.no>
> > > (defun f ( str &rest body )
> > > `(format t ,str ,@body)
>
> > (defun format-t (string &rest args)
> > (apply #'format t string args))
>
Courageous <········@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 <···@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
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <m3em7t8ugk.fsf@world.std.com>
Frode Vatvedt Fjeld <······@acm.org> writes:
>
>
> Tom Breton <···@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, 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.
From: Frode Vatvedt Fjeld
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <2hog6xbaz0.fsf@dslab7.cs.uit.no>
Frode Vatvedt Fjeld <······@acm.org> writes:
> What do you mean by "one more level of indirection"?
Tom Breton <···@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
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <m3r9bsbyl1.fsf@world.std.com>
Frode Vatvedt Fjeld <······@acm.org> writes:
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > What do you mean by "one more level of indirection"?
>
>
> Tom Breton <···@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?
--
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.
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <8e7h8i$jcv$1@joe.rice.edu>
In article <··············@world.std.com> posted on Wednesday,
April 26, 2000 11:45 AM, Tom Breton <···@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/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <390799EA.6DAA45CE@san.rr.com>
> 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.
About the only thing I can say about macros is that it's a
bit irritating if your own code breaks in someone else's
macro. Usually, though, the macro-expand/1 functions will
help. Still... I'm currently making use of an environment
that involves extensive macros (and I believe reader macros),
and god it behaves badly sometimes: many errors that would
ordinarily be caught by the compiler don't get caught til
runtime. I still haven't figured out why that is.
It will, for example, happily allow me to transpose
characters on an initarg (there are special macros for
implementing "concepts" which are these ai-ish equivelent
of classes). Most bizarre.
Anyway,
Having used C/C++ macros quite a bit, I can say that working
with lisp macros/metalinguistic constructs is quite a
pleasure in comparison.
C/
From: Tim Bradshaw
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <ey38zy07i14.fsf@cley.com>
* 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
From: Frode Vatvedt Fjeld
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <2haeigbnxc.fsf@dslab7.cs.uit.no>
Tom Breton <···@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
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <m31z3s6ygv.fsf@world.std.com>
Frode Vatvedt Fjeld <······@acm.org> writes:
> Tom Breton <···@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?
The question was whether to prefer an equivalent function over a
macro. That's equal *by definition*.
> You shouldn't write a macro unless it gives you some extra
> benifit.
Didn't I write that exact thing a couple of messages back?
--
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.
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <3907C755.9CF3FF28@san.rr.com>
> The question was whether to prefer an equivalent function over a
> macro. That's equal *by definition*.
Am I the only who thinks that macros are harder to debug
and sometimes obfuscating?
Admittedly, working with macros in lisp seems quite
a bit easier than those preprocessor abberations in C,
and certainly has a much more native fit than any of
those beasts, but still... (actually, I'm not sure
what we're all going on about, I think not a one o
us disagrees that macros have their place.... god
forbid, even in C).
C/
From: Chuck Fry
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <390863e2$0$219@nntp1.ba.best.com>
In article <·················@san.rr.com>,
Courageous <········@san.rr.com> wrote:
>Am I the only who thinks that macros are harder to debug
>and sometimes obfuscating?
No; I have a colleague, who is every bit the Lisp bigot I am, who
complains about another colleague's heavy use of macrology for what he
sees as no useful purpose.
Personally, I have no problem dealing with macros and their expansions,
at least in anything resembling a modern Lisp programming environment
(i.e. one with some degree of editor integration, even if the editor is
not actually part of the Lisp environment).
In fact, I find macros one of the key reasons I prefer to program in
Common Lisp.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, car nut, photographer, sometime guitarist and mountain biker
The addresses above are real. All spammers will be reported to their ISPs.
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <rj%N4.21$xb5.1110@burlma1-snr2>
In article <··············@nntp1.ba.best.com>,
Chuck Fry <······@best.com> wrote:
>In article <·················@san.rr.com>,
>Courageous <········@san.rr.com> wrote:
>>Am I the only who thinks that macros are harder to debug
>>and sometimes obfuscating?
>
>No; I have a colleague, who is every bit the Lisp bigot I am, who
>complains about another colleague's heavy use of macrology for what he
>sees as no useful purpose.
While I believe that macros are a good mechanism, and consider myself an
accomplished macrologist, I will also accede Courageous's point. Complex
macros can sometimes be pretty difficult to troubleshoot. Often the
complexity isn't in the macro itself, but in the backquoting (especially
when writing macro-defining macros, which usually require multiple levels
of backquotes). Then again, complex functions can also be difficult to
troubleshoot, and there are usually more of them; if, say, 1% of functions
and 2% of macros have a bug, there's a good chance that a large program
will have several hundred functions, hence several buggy ones, but maybe
only 10-20 macros, in which case there's a good chance that none of them
have bugs. There's rarely a need to go overboard on macros (the Common
Lisp language itself has 5-6 times as many functions as macros, but I think
most applications would have a much higher ratio).
However, I still believe in them because the benefit they provide once they
work can be quite good. Also, there are some techniques that experienced
macro writers learn to make it easier to debug them in the first place.
For instance, many macros can simply transform the original code into a
functional style, e.g. translate WITH-OPEN-FILE into CALL-WITH-OPEN-FILE.
--
Barry Margolin, ······@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.
From: Paolo Amoroso
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <R3wJOZgIxd9FTNFM9smPXDnWrlaY@4ax.com>
On 27 Apr 2000 15:59:30 GMT, ······@best.com (Chuck Fry) wrote:
> Personally, I have no problem dealing with macros and their expansions,
> at least in anything resembling a modern Lisp programming environment
If you have a 3Com Palm device, you may want to try the cute little Scheme
system LispMe :)
http://www.lispme.de/lispme/
It has macros but, unfortunately, no macroexpansion facilities. I debug
LispMe macros by eliminating potential trouble spots and concentrating on
the rest of the code. I do this by double checking at the LispMe
toplevel--i.e. the equivalent of a listener--that forms that select macro
arguments, which are usually complex, do what I expect.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: ········@my-deja.com
Subject: Price of macros: [Was Re: Are macros really a neccessity,...]
Date:
Message-ID: <8ecjmf$cdm$1@nnrp1.deja.com>
In article <··············@dslab7.cs.uit.no>,
> Tom Breton <···@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?
>
Frode Vatvedt Fjeld <······@acm.org> responds:
> 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.
Graham, in one or both of his books (_ANSI Common Lisp_ or _On Lisp_)
makes the point that macros must bear the burden of "breaking" the
usual evaluation rules. Macros therefore must save comparatively more
effort (in both writing and reading code) than a comparable function.
E.g., you might write a function and then use it only once to make
things clearer: it doesn't save any effort of writing code (except of
separate debugging), nor much effort reading code (still the same
number of lines.)
A macro like "with-open-file" doesn't obey function evaluation rules,
but saves so much effort getting things *safe* and *correct* that it
more than makes up for the added "wart" to some abstract "lambda
nature" of the language. Plus, it can be used all over the place.
Furthermore, to tie this to a (different?) thread, the proper use of
&body in the argument list makes the auto-formatting of the macro call
clear in code. Simply by looking at the indenting, one realizes that
with-open-file isn't a function, and its behavior as a wrapper becomes
visually clear, and really no more a burden to understanding than
"let" is.
Obviously, not every macro can be as great a boon.
Note that Graham's criterion really says more about using functional
abstraction vs. code manipulation than about when to use a macro in
isolation. In a language like Lisp with such powerful functional
abilities, macros *might* be relatively *less* desirable than in a
language like C or Fortran. That doesn't say much though, since
neither *offers* Lisp macros. Also, Graham appears to be influenced by
Scheme somewhat in his preference for constructing utility functions
for different types of iteration to using something like "loop".
Personal example:
I've been guilty, probably, of "mis-using" macros
<http://www.people.fas.harvard.edu/~jaoswald/lisp/magic/ident.lisp>
where I write a little "graphics language", allowing me to define
CLOS classes with constructor functions such as
#'make-sideways-number-9, by saying
(def-sideways-numeral 9 ((0 5 0 1) (2 5 2 3) (2 3 1 2) (4 5 1 2)))
specifying what pen strokes are used to write the glyph.
Basically, I did it to combine a defclass and a defun in the same
expression.
I'd be hard pressed to justify this in the abstract. The macro is
pretty ugly, and I can't necessarily say this avoided errors, since I
probably botched the code to create the function symbols from the
digit, so that it must be used in the correct package. But I only use
it 10 times, and actually, since I had already written the function
once, it was pretty easy to write the macro by adding backquote
syntax in the right place, and abstracting things slightly to allow
for different digits to be described.
If I had to do something like this for a publically-exposed interface,
I would have spent much more time fixing the design, probably to use
a more functional interface, with a much simpler helper macro. For me,
in this instance, I let the Lisp compiler do a lot of typing for me,
and that got the job done somewhat quicker.
--Joe Oswald
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Erik Naggum
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <3165769025251773@naggum.no>
* Tom Breton <···@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
From: David Hanley
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <39077839.12A53CC@ncgr.org>
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
From: Hartmann Schaffer
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <39086e2a@news.sentex.net>
In article <··············@world.std.com>,
Tom Breton <···@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?
the purpose of macros is to simplify your code. once the macro is
written and debugged, you shouldn't have to think about it. you just
use it like a built in language construct. pretty much all control
constructs of hlls can be expressed as macros with simple ifs and gotos
inside. do you really think about what is going on inside a while loop?
--
Hartmann Schaffer
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <m3wvljjbmq.fsf@world.std.com>
··@inferno.nirvananet (Hartmann Schaffer) writes:
> In article <··············@world.std.com>,
> Tom Breton <···@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?
>
> the purpose of macros is to simplify your code. once the macro is
> written and debugged, you shouldn't have to think about it.
Wow, this thread just keeps chewing at this statement for no apparent
reason.
> once the macro is written and debugged,
Sure, once it's *done*.
> you shouldn't have to think about it.
Sure, you *shouldn't* have to, that doesn't mean you never will.
--
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.
From: Hartmann Schaffer
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <39092171@news.sentex.net>
In article <··············@world.std.com>,
Tom Breton <···@world.std.com> writes:
> ...
>> the purpose of macros is to simplify your code. once the macro is
>> written and debugged, you shouldn't have to think about it.
>
> Wow, this thread just keeps chewing at this statement for no apparent
> reason.
probably because there is a good reason for it
>> once the macro is written and debugged,
>
> Sure, once it's *done*.
i have news for you: this is one of the essential tasks when you are
programming, esp. when you are writing code that other people have to
use.
>> you shouldn't have to think about it.
>
> Sure, you *shouldn't* have to, that doesn't mean you never will.
fact of life.
btw. if you dislike macros so much, nobody forces you to use them
--
Hartmann Schaffer
From: Tom Breton
Subject: Seems like Erik uses tentacles (Was Re: Are macros really a neccessity, or a coverup of languagedeficiencies?)
Date:
Message-ID: <m31z3qxebh.fsf@world.std.com>
··@inferno.nirvananet (Hartmann Schaffer) writes:
> In article <··············@world.std.com>,
> Tom Breton <···@world.std.com> writes:
> > ...
[misleading snippage undone. I 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?
>
> >> the purpose of macros is to simplify your code. once the macro is
> >> written and debugged, you shouldn't have to think about it.
> >
> > Wow, this thread just keeps chewing at this statement for no apparent
> > reason.
>
> probably because there is a good reason for it
Now I know beyond a reasonable doubt that this thread isn't on the
level. I may not be such a gifted writer that I get my meaning across
100% of the time, but this is ridiculous. There is nothing in my
innocuous statement that should remotely evoke this sudden
insult-hurling conga-line. 3 people so far have attacked me for the
paragraph above - or should I say, 3 user-ids have.
I'm inclined to agree with the guy who suggested that we're seeing a
bunch of Naggum tentacles. Same style, same quick resort to "then
you're a bad programmer", same pattern of zealotry, same type of
conceptual blind spots.
While obviously no-one can be 100% sure, it's done a hell of a lot of
walking like a duck and quacking like a duck; I say it's a duck named
Erik Naggum. I'm disgusted that you would stoop so low as to harrass
the newsgroup under phony names. I believe you used the phrase
"obsessed stalker" in one of your recent attacks; you may want to
apply it closer to home.
I will continue to use this newsgroup and ignore you, regardless your
user-id. I've already killfiled your recent tentacles, I suppose I
shall have to keep doing so for each new tentacle. I assure you, it's
far less work to add you to my killfile each time than it is to create
each "Hartmann Schaffer".
> >> once the macro is written and debugged,
> >
> > Sure, once it's *done*.
>
> i have news for you: this is one of the essential tasks when you are
> programming, esp. when you are writing code that other people have to
> use.
Wow, you really are just trying to goad me, aren't you?
> >> you shouldn't have to think about it.
> >
> > Sure, you *shouldn't* have to, that doesn't mean you never will.
>
> fact of life.
>
> btw. if you dislike macros so much, nobody forces you to use them
Yup, just trying to goad me.
Ob-liten-up-with-some-humor: The insult-hurling conga line goes like
this:
"You're bad programm-ER!
You're bad programm-ER!
..."
--
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.
From: Gareth McCaughan
Subject: Re: Seems like Erik uses tentacles (Was Re: Are macros really a neccessity, or a coverup of languagedeficiencies?)
Date:
Message-ID: <8666t1j3em.fsf@g.local>
Tom Breton wrote:
> I'm inclined to agree with the guy who suggested that we're seeing a
> bunch of Naggum tentacles. Same style, same quick resort to "then
> you're a bad programmer", same pattern of zealotry, same type of
> conceptual blind spots.
I think you're being ridiculous. The articles purporting to be
from Hartman Schaffer aren't in remotely #\Erik's style.
> While obviously no-one can be 100% sure, it's done a hell of a lot of
> walking like a duck and quacking like a duck; I say it's a duck named
> Erik Naggum.
I say you're basing your accusation (which is, after all,
a pretty serious one) on a *very* small amount of walking
and quacking.
*
I think there's been some misunderstanding going on here.
Tom wrote, way back when,
| 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 I think some have taken this as some kind of blanket
attack on macros. I *think* -- and I'm sure Tom will complain
if I'm wrong -- that he was just repeating the old advice:
don't use macros as a hacky way of doing inline functions.
And I'd guess that the adverse reaction is coming from people
who wouldn't dream of using macros that way, and haven't
seriously considered the possibility that Tom might be
referring to doing that.
Unless Tom is saying that he objects to using macros for
things like WITH-OPEN-FILE or extended LOOP, or the people
arguing against him are saying that things like
(defmacro square (x) `(* x x))
are better than inline functions, I think this sub-thread
is an argument about nothing.
--
Gareth McCaughan ················@pobox.com
sig under construction
From: Frode Vatvedt Fjeld
Subject: Re: Seems like Erik uses tentacles (Was Re: Are macros really a neccessity, or a coverup of languagedeficiencies?)
Date:
Message-ID: <2hvh11gbf1.fsf@dslab7.cs.uit.no>
Tom Breton <···@world.std.com> writes:
> [..] Same style, same quick resort to "then you're a bad
> programmer", same pattern of zealotry, same type of conceptual blind
> spots.
Blind spots for what, precisely? Who's to say who's got "blind spots"?
It could be you, even.
> While obviously no-one can be 100% sure [..]
You're being paranoid and quite rude.
--
Frode Vatvedt Fjeld
From: Erik Naggum
Subject: Re: Seems like Erik uses tentacles (Was Re: Are macros really a neccessity, or a coverup of languagedeficiencies?)
Date:
Message-ID: <3165947667587071@naggum.no>
* Tom Breton <···@world.std.com>
| [ truly insane rambling deleted ]
I'm always relieved when my critics turn out to be clinically insane.
#:Erik
From: Hartmann Schaffer
Subject: Re: Seems like Erik uses tentacles (Was Re: Are macros really a neccessity, or a coverup of languagedeficiencies?)
Date:
Message-ID: <390a09b2@news.sentex.net>
In article <··············@world.std.com>,
Tom Breton <···@world.std.com> writes:
> ··@inferno.nirvananet (Hartmann Schaffer) writes:
>
>> In article <··············@world.std.com>,
>> Tom Breton <···@world.std.com> writes:
>> > ...
> [misleading snippage undone. I 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?
>>
>> >> the purpose of macros is to simplify your code. once the macro is
>> >> written and debugged, you shouldn't have to think about it.
>> >
>> > Wow, this thread just keeps chewing at this statement for no apparent
>> > reason.
>>
>> probably because there is a good reason for it
>
> Now I know beyond a reasonable doubt that this thread isn't on the
> level. I may not be such a gifted writer that I get my meaning across
> 100% of the time, but this is ridiculous. There is nothing in my
> innocuous statement that should remotely evoke this sudden
> insult-hurling conga-line. 3 people so far have attacked me for the
> paragraph above - or should I say, 3 user-ids have.
could you please explain in which way i attacked you? where the
insult is? methinks you suffer from paranoia.
> I'm inclined to agree with the guy who suggested that we're seeing a
> bunch of Naggum tentacles. Same style, same quick resort to "then
> you're a bad programmer", same pattern of zealotry, same type of
> conceptual blind spots.
not having seen any of your code i have no idea whether you are a good
or a bad programmer, so i wouldn't make that statement.
> While obviously no-one can be 100% sure, it's done a hell of a lot of
> walking like a duck and quacking like a duck; I say it's a duck named
> Erik Naggum. I'm disgusted that you would stoop so low as to harrass
> the newsgroup under phony names. I believe you used the phrase
> "obsessed stalker" in one of your recent attacks; you may want to
> apply it closer to home.
yes, paranoia. i am not erik. if you were not so paranoid you might
arrive at the conclusion that the contents of your statementtriggers
the "attacks".
> I will continue to use this newsgroup and ignore you, regardless your
> user-id. I've already killfiled your recent tentacles, I suppose I
> shall have to keep doing so for each new tentacle. I assure you, it's
> far less work to add you to my killfile each time than it is to create
> each "Hartmann Schaffer".
be my guest.
>> >> once the macro is written and debugged,
>> >
>> > Sure, once it's *done*.
>>
>> i have news for you: this is one of the essential tasks when you are
>> programming, esp. when you are writing code that other people have to
>> use.
>
> Wow, you really are just trying to goad me, aren't you?
no
>> >> you shouldn't have to think about it.
>> >
>> > Sure, you *shouldn't* have to, that doesn't mean you never will.
>>
>> fact of life.
>>
>> btw. if you dislike macros so much, nobody forces you to use them
>
> Yup, just trying to goad me.
no
> Ob-liten-up-with-some-humor: The insult-hurling conga line goes like
> this:
>
> "You're bad programm-ER!
> You're bad programm-ER!
> ..."
could you explain how you arrive at this conclusion?
--
Hartmann Schaffer
From: Tim Moore
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <8e20oj$dva$0@216.39.145.192>
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
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of languagedeficiencies?
Date:
Message-ID: <390507B5.ECD8DB28@san.rr.com>
> 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/
From: Rob Warnock
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8e0c83$332om$1@fido.engr.sgi.com>
Courageous <········@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 ····@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
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m3og70jhkp.fsf@world.std.com>
Courageous <········@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, 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.
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m366t8b0hg.fsf@world.std.com>
Tom Breton <···@world.std.com> writes:
> Courageous <········@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))
--
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.
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <ud7nfsk0x.fsf@alum.mit.edu>
Courageous <········@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
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390463EE.B788E253@makif.omer.k12.il>
--------------D7DDBE251C410A3D0396081D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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 :)
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
--------------D7DDBE251C410A3D0396081D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Courageous wrote:
<blockquote TYPE=CITE>I view a language without metalinguistic constructs
as hamstrung.
<br>Java, for example is soooo not extensible. Standard macros in C++
<br>and ANSI C are barely a solution, although the gcc style macros
<br>at least offer variatic argument support. In lisp, I've found that
<br>macros are outright mandatory when you want to pass of a &rest
<br>form to a function which expects that &rest form as not a list.
e.g.,
<p>(defun f ( str &rest body )
<br> `(format t ,str ,@body)
<br>)
<p>(example of writing a format that passes through to format
<br>a bit silly, but gets the point across; hope I got the syntax
<br>right, not at work and don't have all this memorized yet).
<p>Actually, if there's a way of doing that *without* macros, I sure
<br>would like to know about it.</blockquote>
I am not sure if LISP has a way of making that work, but I do know
<br>that in another language design, it would definitely be possible
<br>without the use of a macro. I am not sure that the Java
language
<br>design is complete in removing the need for macros, and I do not
<br>think it is provable that a language makes macros obselete.
<br>However, I would request that you bring a few cases where
<br>proper C++ macros are necessary (ones that form a complete
<br>syntax expression). Excluding for example:
<br>#define InproperMacro(x)
((x) +
<br>Any Java problems resulting from the lack of macros would also be
<br>interesting to view, and perhaps I can offer solutions by either
<br>proposing a more complete language design, or by demonstrating a
<br>non-macro solution that is already existant.
<blockquote TYPE=CITE>Overall, I like macros, however, as long as the programmer
<br>doesn't go so overboard with them that the code becomes "write
<br>only". :)</blockquote>
I obviously don't like macros :) As much as I wouldn't
like a program
<br>that integrates all functions code (except impossible cases, as recursion)
<br>into callers' function bodies :)
<pre>--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).</pre>
</html>
--------------D7DDBE251C410A3D0396081D--
From: Harley Davis
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3904e2c0$0$222@newsreader.alink.net>
Peaker <······@makif.omer.k12.il> wrote in message
······················@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
From: Tim Bradshaw
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <ey366t78kvn.fsf@cley.com>
* 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
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3904DA09.B757188C@makif.omer.k12.il>
> 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?
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Jon S Anthony
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3904E89F.24FC@synquiry.com>
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??
/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
From: David Hanley
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3905EA0A.56AE2AEF@ncgr.org>
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
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <xq5N4.48$Bf1.1416@burlma1-snr2>
In article <·················@makif.omer.k12.il>,
Peaker <······@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 "E 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.
--
Barry Margolin, ······@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.
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <u3dobkoqd.fsf@alum.mit.edu>
Barry Margolin <······@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
From: Tim Bradshaw
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <ey3ya636o0w.fsf@cley.com>
* 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
From: Jim Bushnell
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8e066s$hbk$1@sloth.swcp.com>
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 <······@makif.omer.k12.il> wrote in message
······················@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.
>
> - 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).
>
>
>
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390463C9.1180FD92@makif.omer.k12.il>
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.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Jon S Anthony
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3904A9E5.42FD@synquiry.com>
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
From: Jon S Anthony
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3904AC37.3FD3@synquiry.com>
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.
/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
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m3vh18ji05.fsf@world.std.com>
Peaker <······@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.
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <u8zy3si1y.fsf@alum.mit.edu>
Peaker <······@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
From: Phil Stubblefield
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <39060F95.EF5E7ED2@rpal.rockwell.com>
Joe Marshall <·········@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 ····@rpal.rockwell.com
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <YloN4.62$my3.1092@burlma1-snr2>
In article <·················@rpal.rockwell.com>,
Phil Stubblefield <····@rpal.rockwell.com> wrote:
>Joe Marshall <·········@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.
--
Barry Margolin, ······@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.
From: Paolo Amoroso
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <PjwEOb1Trgyb8SMI=BRLFi8rcft4@4ax.com>
On Sun, 23 Apr 2000 21:58:08 +0000, Peaker <······@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/
From: Erik Naggum
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3165647335532305@naggum.no>
* Peaker <······@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
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3907660B.CCA3ECD2@yahoo.com>
> 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).
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <0hKN4.108$my3.2909@burlma1-snr2>
In article <·················@yahoo.com>, Peaker <·········@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.
--
Barry Margolin, ······@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.
Peaker <·········@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.
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3907FD4A.D138F88D@yahoo.com>
> 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).
Well, the idea is, that when the syntax is so small, you may not ever need
to change it, as the language consists of very little syntax, and a lot of
object operations. In my question, I was aware that LISP macros allow
lower-level access to the syntax (changing the way things are parsed),
however, I am suggesting that it may not be necessary, and that an
extendible object model may be all you'll ever need to change about the
language (which is what I want you to contradict by bringing practical
examples of things possible to achieve by affecting the ways things are
parsed (macros), and not by extending the object model).
> 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.
Again, those basic syntatic statement level evaluation may not need be
useful to change.
> 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.
>
If I understand this correctly, it seems to be part of that same mechanism,
if you consider op's (operators) to be object methods and part of the
extendible object model. This only reenforces the idea, that the high-level
syntax is the low-level one, combined with the basic object model.
My theory is, that the high-level syntax is extendible, when the basic
object model is extendible enough, and that the low-level syntax need not
change, which is why I dislike LISP's way of providing means to change
the low-level syntax.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
Peaker <·········@yahoo.com> wrote:
> > 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.
[snip]
> Well, the idea is, that when the syntax is so small, you may not ever need
> to change it, as the language consists of very little syntax, and a lot of
> object operations.
Which idea? I certainly like the Smalltalk approach, and, at least as a
partial consequence, I do most of my programming in Smalltalk. But, um,
Smalltalk is different that Common Lisp, and it seems a tad odd to try
to force the latter into the mold of the former, especially as Smalltalk
isn't as linguisitically oriented as Common Lisp. I'd say, for example,
that one is much more like to extend the IDE than the language, in
Smalltalk, and the reverse in Common Lisp (or in Scheme or in Prolog).
> In my question, I was aware that LISP macros allow
> lower-level access to the syntax (changing the way things are parsed),
Well, evaluated, certainly. I believe others have pointed to the reader.
> however, I am suggesting that it may not be necessary, and that an
> extendible object model may be all you'll ever need to change about the
> language
Change for what end? That's the key question. It seems that serious and
experienced Common Lisp programmers (which I am not) find it useful and
sensible to build up their programs in part via macros.
Sounds reasonable to me. I certainly don't have any experience to
contradict it.
> (which is what I want you to contradict by bringing practical
> examples of things possible to achieve by affecting the ways things are
> parsed (macros), and not by extending the object model).
Sorry, can't help you. I'm not even sure that this is a reasonable
request. Perhaps you supply a more specifc one?
> > 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.
>
> Again, those basic syntatic statement level evaluation may not need be
> useful to change.
Well, maybe. If you want to keep the syntax simple, sure. If you want to
have the syntax bear some of the representation burden, probably not.
But this is mere idle speculation, eh?
> > 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.
> >
> If I understand this correctly, it seems to be part of that same mechanism,
> if you consider op's (operators) to be object methods and part of the
> extendible object model.
Huh?
Suppose one has a predicate 'has', normally one would write that as:
has(sally, information).
By first adding the rule:
:- op(600, xfx, has).
One can write the first clause as:
sally has information.
But no shift in the basic sematics has occured. I'm under the impression
that many Prologs would transform both forms into the same internal
form, which is much closer to the former, which is essentially a sexpr.
Hmm. Perhaps this is more like a reader macro. I'm not sure (anyone?).
Prologs tend to have program representing predicates so that you can do
programs writing programs type things. I'm just not sure how this all
maps onto Common Lisp.
However, I would bet that it maps better onto Common Lisp than onto
Smalltalk.
> This only reenforces the idea, that the high-level
> syntax is the low-level one, combined with the basic object model.
I frankly can make no sense of this. I tend to associate object models
with semantics.
Object new initialize.
and
(send (send Object new) initialize)
are hardly syntactically identical, but they certainly could express the
same thing in the same object model.
> My theory is, that the high-level syntax is extendible, when the basic
> object model is extendible enough,
Using your undefined terms for the moment, if the high-level syntax is
extendible, why not have it be extendible by either componant?
> and that the low-level syntax need not
> change,
Why not the other way 'round?
> which is why I dislike LISP's way of providing means to change
> the low-level syntax.
I think you need, as several people mentioned, to go to the library.
--
Bijan Parsia
http://monkeyfist.com/
...among many things.
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3909A082.3EF9D7C4@yahoo.com>
--------------4C44F5420963E603C47D991C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bijan Parsia wrote:
> > Well, the idea is, that when the syntax is so small, you may not ever need
> > to change it, as the language consists of very little syntax, and a lot of
> > object operations.
>
> Which idea? I certainly like the Smalltalk approach, and, at least as a
> partial consequence, I do most of my programming in Smalltalk. But, um,
> Smalltalk is different that Common Lisp, and it seems a tad odd to try
> to force the latter into the mold of the former, especially as Smalltalk
> isn't as linguisitically oriented as Common Lisp. I'd say, for example,
> that one is much more like to extend the IDE than the language, in
> Smalltalk, and the reverse in Common Lisp (or in Scheme or in Prolog).
The idea I was trying to convey through this thread.
And as much as many think of Smalltalk as a whole enviorment, I prefer
taking just the syntatic and semantic part as an example of what types
of *CLEANER* semantic/syntatic modifications can be used to replace
the unclean macros.
> > In my question, I was aware that LISP macros allow
> > lower-level access to the syntax (changing the way things are parsed),
>
> Well, evaluated, certainly. I believe others have pointed to the reader.
Yes, this is a small terminological mistake on my side, sorry.
> > however, I am suggesting that it may not be necessary, and that an
> > extendible object model may be all you'll ever need to change about the
> > language
>
> Change for what end? That's the key question. It seems that serious and
> experienced Common Lisp programmers (which I am not) find it useful and
> sensible to build up their programs in part via macros.
As I mentioned earlier, LISP *DOES* require macros for the extra
convinience and usefulness. I am not critizing LISP programmers for using
macros. I am criticising LISP for not providing powerful-enough alternative
features such as a built-in powerful object model and syntax features
concerning that, that can also change the ways things are evaluated, and
provide a CLEANER mean than macros, for the same purpose.
> Sounds reasonable to me. I certainly don't have any experience to
> contradict it.
>
> > (which is what I want you to contradict by bringing practical
> > examples of things possible to achieve by affecting the ways things are
> > parsed (macros), and not by extending the object model).
>
> Sorry, can't help you. I'm not even sure that this is a reasonable
> request. Perhaps you supply a more specifc one?
What I am trying to request there is, the contradiction of the claim that in an
ideal language, there is ALWAYS a cleaner way than macros, and therefore
macros only provide extra mess. I don't see how I could have made that any
more specific.
> > > 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.
> >
> > Again, those basic syntatic statement level evaluation may not need be
> > useful to change.
>
> Well, maybe. If you want to keep the syntax simple, sure. If you want to
> have the syntax bear some of the representation burden, probably not.
The representation burden is not on the syntax itself. One does not only use
the syntax to represent things, but also the existing objects, methods,
operators, and functions. My claim is that the representation
ability is just as good with an immutable syntax, when the objects, methods,
operators, etc can be powerfully modified and extended.
> > > 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.
> > >
> > If I understand this correctly, it seems to be part of that same mechanism,
> > if you consider op's (operators) to be object methods and part of the
> > extendible object model.
>
> Huh?
I guess I did not get it exactly right, which is why I preceded it with "if I
..."..
> Suppose one has a predicate 'has', normally one would write that as:
>
> has(sally, information).
>
> By first adding the rule:
>
> :- op(600, xfx, has).
> One can write the first clause as:
>
> sally has information.
This does not change the basic syntax, however, as you can see, it does
add to the ability to represent more things more easily.
> But no shift in the basic sematics has occured. I'm under the impression
> that many Prologs would transform both forms into the same internal
> form, which is much closer to the former, which is essentially a sexpr.
> Hmm. Perhaps this is more like a reader macro. I'm not sure (anyone?).
> Prologs tend to have program representing predicates so that you can do
> programs writing programs type things. I'm just not sure how this all
> maps onto Common Lisp.
> However, I would bet that it maps better onto Common Lisp than onto
> Smalltalk.
Smalltalk and Common Lisp are specific language designs, when I
brought specific languages such as Smalltalk, it was to demonstrate
specific features I thought could replace macros. I certainly did not
mean Smalltalk had all the features to provide the same convinience
and extra expressiveness of macros.
> > This only reenforces the idea, that the high-level
> > syntax is the low-level one, combined with the basic object model.
>
> I frankly can make no sense of this. I tend to associate object models
> with semantics.
>
> Object new initialize.
> and
> (send (send Object new) initialize)
>
> are hardly syntactically identical, but they certainly could express the
> same thing in the same object model.
By "high-level syntax", I hoped I wasn't too wrong on the terminology,
appearntly, I was. Therefore, I will have to make it clear, that what I
meant by "the high-level syntax is the low-level one combined with the
basic object model", is that the ability to express concepts grows not only
if the syntax grows. The ability to easily express concepts can be raised
infinitely with a constant syntax.
> > My theory is, that the high-level syntax is extendible, when the basic
> > object model is extendible enough,
>
> Using your undefined terms for the moment, if the high-level syntax is
> extendible, why not have it be extendible by either componant?
Because that other component is simply worse:
- It is messier.
- It is harder to read, write, and debug.
- It unnecessarily forces certain things that would otherwise not be
forced (inline'ing the "loop" expression, because it was implemented as a
macro, and not as a method, for example).
> > and that the low-level syntax need not
> > change,
>
> Why not the other way 'round?
The "low-level syntax" is part of the same wrong terminology I was using,
it is simply the syntax. A language is much cleaner and easier to use when
the syntax remains pure and static, and the object model is extended to
provide the same extra expressiveness.
> > which is why I dislike LISP's way of providing means to change
> > the low-level syntax.
>
> I think you need, as several people mentioned, to go to the library.
The library might help because there is a problem, I admit. The problem is
not what you think it is - the issues of macros, syntax, and expressiveness
of a language are well understood by me. I do have a problem with
conveying my ideas to some on this group. I tend to use wrong terms, as
I have no formal education on the matter, and English is not my best
language. I appologize for my misuse of terminology, and ask that you
make a bigger effort to understand what I'm trying to convey.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
--------------4C44F5420963E603C47D991C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Bijan Parsia wrote:
<blockquote TYPE=CITE>> Well, the idea is, that when the syntax is so small,
you may not ever need
<br>> to change it, as the language consists of very little syntax, and
a lot of
<br>> object operations.
<p>Which idea? I certainly like the Smalltalk approach, and, at least as
a
<br>partial consequence, I do most of my programming in Smalltalk. But,
um,
<br>Smalltalk is different that Common Lisp, and it seems a tad odd to
try
<br>to force the latter into the mold of the former, especially as Smalltalk
<br>isn't as linguisitically oriented as Common Lisp. I'd say, for example,
<br>that one is much more like to extend the IDE than the language, in
<br>Smalltalk, and the reverse in Common Lisp (or in Scheme or in Prolog).</blockquote>
The idea I was trying to convey through this thread.<br>
And as much as many think of Smalltalk as a whole enviorment, I prefer<br>
taking just the syntatic and semantic part as an example of what types<br>
of *CLEANER* semantic/syntatic modifications can be used to replace<br>
the unclean macros.
<blockquote TYPE=CITE>> In my question, I was aware that LISP macros
allow
<br>> lower-level access to the syntax (changing the way things are parsed),
<p>Well, evaluated, certainly. I believe others have pointed to the reader.</blockquote>
Yes, this is a small terminological mistake on my side, sorry.
<blockquote TYPE=CITE>> however, I am suggesting that it may not be necessary,
and that an
<br>> extendible object model may be all you'll ever need to change about
the
<br>> language
<p>Change for what end? That's the key question. It seems that serious
and
<br>experienced Common Lisp programmers (which I am not) find it useful
and
<br>sensible to build up their programs in part via macros.</blockquote>
As I mentioned earlier, LISP *DOES* require macros for the
extra<br>
convinience and usefulness. I am not critizing LISP programmers
for using<br>
macros. I am criticising LISP for not providing powerful-enough
alternative<br>
features such as a built-in powerful object model and syntax features<br>
concerning that, that can also change the ways things are evaluated, and<br>
provide a CLEANER mean than macros, for the same purpose.
<blockquote TYPE=CITE>Sounds reasonable to me. I certainly don't have any
experience to
<br>contradict it.
<p>> (which is what I want you to contradict by bringing practical
<br>> examples of things possible to achieve by affecting the ways things
are
<br>> parsed (macros), and not by extending the object model).
<p>Sorry, can't help you. I'm not even sure that this is a reasonable
<br>request. Perhaps you supply a more specifc one?</blockquote>
What I am trying to request there is, the contradiction of the claim that
in an<br>
ideal language, there is ALWAYS a cleaner way than macros, and therefore<br>
macros only provide extra mess. I don't see how I could
have made that any<br>
more specific.
<blockquote TYPE=CITE>> > Now, it's quite easy to change the object model
(e.g., to prototypes)
<br>> > and, thus, to get a rather different langauge (tailored to the
<br>> > application domain, one might say), but the basic syntactic and
statment
<br>> > level evaluation mechanism don't change.
<br>>
<br>> Again, those basic syntatic statement level evaluation may not need
be
<br>> useful to change.
<p>Well, maybe. If you want to keep the syntax simple, sure. If you want
to
<br>have the syntax bear some of the representation burden, probably not.</blockquote>
The representation burden is not on the syntax itself. One does not
only use<br>
the syntax to represent things, but also the existing objects, methods,<br>
operators, and functions. My claim is that the representation<br>
ability is just as good with an immutable syntax, when the objects, methods,<br>
operators, etc can be powerfully modified and extended.
<blockquote TYPE=CITE>> > Oh, one should probably point at Prolog as well,
with it's op function
<br>> > which allows one to define the associtivity and precedence of arbitrary
<br>> > predicates. Very handy for quickly building domain specific sugar.
<br>> >
<br>> If I understand this correctly, it seems to be part of that same
mechanism,
<br>> if you consider op's (operators) to be object methods and part of
the
<br>> extendible object model.
<p>Huh?</blockquote>
I guess I did not get it exactly right, which is why I preceded
it with "if I ..."..
<blockquote TYPE=CITE>Suppose one has a predicate 'has', normally one would
write that as:
<p> has(sally, information).
<p>By first adding the rule:
<p> :- op(600, xfx, has).<br>
One can write the first clause as:<br>
<br>
sally has information.</blockquote>
This does not change the basic syntax, however, as you can see, it does<br>
add to the ability to represent more things more easily.
<blockquote TYPE=CITE>But no shift in the basic sematics has occured. I'm
under the impression<br>
that many Prologs would transform both forms into the same internal<br>
form, which is much closer to the former, which is essentially a sexpr.<br>
Hmm. Perhaps this is more like a reader macro. I'm not sure (anyone?).<br>
Prologs tend to have program representing predicates so that you can do<br>
programs writing programs type things. I'm just not sure how this all<br>
maps onto Common Lisp.<br>
However, I would bet that it maps better onto Common Lisp than onto<br>
Smalltalk.</blockquote>
Smalltalk and Common Lisp are specific language designs, when I<br>
brought specific languages such as Smalltalk, it was to demonstrate<br>
specific features I thought could replace macros. I certainly
did not<br>
mean Smalltalk had all the features to provide the same convinience<br>
and extra expressiveness of macros.
<blockquote TYPE=CITE>> This only reenforces the idea, that the high-level
<br>> syntax is the low-level one, combined with the basic object model.
<p>I frankly can make no sense of this. I tend to associate object models
<br>with semantics.
<p> Object new initialize.
<br>and
<br> (send (send Object new)
initialize)
<p>are hardly syntactically identical, but they certainly could express
the
<br>same thing in the same object model.</blockquote>
By "high-level syntax", I hoped I wasn't too wrong on the terminology,<br>
appearntly, I was. Therefore, I will have to make it clear, that
what I<br>
meant by "the high-level syntax is the low-level one combined with the<br>
basic object model", is that the ability to express concepts grows not
only<br>
if the syntax grows. The ability to easily express concepts can be
raised<br>
infinitely with a constant syntax.
<blockquote TYPE=CITE>> My theory is, that the high-level syntax is extendible,
when the basic
<br>> object model is extendible enough,
<p>Using your undefined terms for the moment, if the high-level syntax
is
<br>extendible, why not have it be extendible by either componant?</blockquote>
Because that other component is simply worse:
<br>- It is messier.
<br>- It is harder to read, write, and debug.
<br>- It unnecessarily forces certain things that would otherwise not be<br>
forced (inline'ing the "loop" expression, because it was implemented
as a<br>
macro, and not as a method, for example).
<blockquote TYPE=CITE>> and that the low-level syntax need not
<br>> change,
<p>Why not the other way 'round?</blockquote>
The "low-level syntax" is part of the same wrong terminology I was using,<br>
it is simply the syntax. A language is much cleaner and easier to
use when<br>
the syntax remains pure and static, and the object model is extended to<br>
provide the same extra expressiveness.
<blockquote TYPE=CITE>> which is why I dislike LISP's way of providing
means to change
<br>> the low-level syntax.
<p>I think you need, as several people mentioned, to go to the library.</blockquote>
The library might help because there is a problem, I admit.
The problem is<br>
not what you think it is - the issues of macros, syntax, and expressiveness<br>
of a language are well understood by me. I do have a problem
with<br>
conveying my ideas to some on this group. I tend to use wrong
terms, as<br>
I have no formal education on the matter, and English is not my best<br>
language. I appologize for my misuse of terminology, and ask that
you<br>
make a bigger effort to understand what I'm trying to convey.
<pre>--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).</pre>
</html>
--------------4C44F5420963E603C47D991C--
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <uwvlip8r3.fsf@alum.mit.edu>
Peaker <·········@yahoo.com> writes:
> The idea I was trying to convey through this thread.
> And as much as many think of Smalltalk as a whole enviorment, I prefer
> taking just the syntatic and semantic part as an example of what types
> of *CLEANER* semantic/syntatic modifications can be used to replace
> the unclean macros.
What exactly do you mean by `unclean' or `*CLEANER*'? How are you
measuring `cleanliness'?
> I am criticising LISP�for not providing powerful-enough alternative
> features such as a built-in powerful object model and syntax features
> concerning that, that can also change the ways things are evaluated, and
> provide a CLEANER�mean than macros, for the same purpose.
I guess if CLOS+MOP isn't powerful enough for you, you should consider
using another language. If the ability to modify and extend the
readtable, evaluator, and compiler isn't enough to change the way
things are evaluated, you're SOL as far as Lisp is concerned.
> What I am trying to request there is, the contradiction of the claim that in an
> ideal language, there is ALWAYS a cleaner way than macros, and therefore
> macros only provide extra mess.�
We've been contradicting you.
> I�don't see how I�could have made that any more specific.
How about by defining cleanliness in a quantifiable way, defining what
you mean by `ideal language'?
> My claim is that the representation ability is just as good with an
> immutable syntax, when the objects, methods, operators, etc can be
> powerfully modified and extended.
So what's your beef?
--
~jrm
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3909F804.C49C543C@yahoo.com>
Joe Marshall wrote:
> What exactly do you mean by `unclean' or `*CLEANER*'? How are you
> measuring `cleanliness'?
Its a complex subjective term, and I doubt I can do well defining it, but I can
say it directly relates to readability.
> > I am criticising LISP for not providing powerful-enough alternative
> > features such as a built-in powerful object model and syntax features
> > concerning that, that can also change the ways things are evaluated, and
> > provide a CLEANER mean than macros, for the same purpose.
>
> I guess if CLOS+MOP isn't powerful enough for you, you should consider
> using another language. If the ability to modify and extend the
> readtable, evaluator, and compiler isn't enough to change the way
> things are evaluated, you're SOL as far as Lisp is concerned.
I did not say CLOS+MOP was not powerful. I think it is safe to say,
however, that the LISP syntax values simplicity over many things, and
the syntax/lang. itself is not related in any way to the object model, and
is simply not extendible in means other than macros (such as, for example,
operator overloading). Which is why I also consider examples of how
macros are useful in extending the LISP syntax simply invalid to the
argument of whether or not the concept macros is useful.
As powerful as CLOS+MOP may be, I would not consider it an
alternative to macros in replacing the language extendibility abilities.
> > What I am trying to request there is, the contradiction of the claim that in an
> > ideal language, there is ALWAYS a cleaner way than macros, and therefore
> > macros only provide extra mess.
>
> We've been contradicting you.
I've not yet noticed a contradiction of that claim. The best way to contradict
that would probably be to bring some macro definitions that are simply not
doable using non-macro means. Thomas A. Russ brought a few nice
examples of how macros effectively extend the language. I brought
equivalent non-macro solutions, that show that all the specific macro
functionality from his examples can be implemented using the non-macro
means. I challange you to contradict me by bringing examples of
extensions that I simply cannot replicate using non-macro means.
> > I don't see how I could have made that any more specific.
>
> How about by defining cleanliness in a quantifiable way, defining what
> you mean by `ideal language'?
I was actually referring to my original 'challange' of bringing those
examples, that did not mention an ideal language or cleanliness. Cleanliness
is subjective but some charactaristics are quite absoloute, and can roughly
measure the cleanliness of a piece of code. I would say the simplest way to
measure cleanliness, is to measure readability (probably just as problematic
as well, but probably better defined than cleanliness).
By the concept of an 'ideal language', I obviously refer to my oppinion of
an ideal language, which is a language that has all the extendibility, but not
the macros.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
Peaker <·········@yahoo.com> wrote:
[snip]
> I've not yet noticed a contradiction of that claim. The best way to
> contradict that would probably be to bring some macro definitions that are
> simply not doable using non-macro means.
Since I doubt this is possible, it's hardly the *best* way.
Well, maybe from your perspective!
Of course, all that *really* needs to be shown, as far as I can make
out, is that the macro ways are "cleaner" by some measure.
Alas, there doesn't seem to be consensus on what the measure should be.
You have one, and just about everyone else has another.
Thus, you're arguing at the wrong level.
--
Bijan Parsia
http://monkeyfist.com/
...among many things.
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390ACFEA.F7D4B1A3@yahoo.com>
Bijan Parsia wrote:
> Of course, all that *really* needs to be shown, as far as I can make
> out, is that the macro ways are "cleaner" by some measure.
>
> Alas, there doesn't seem to be consensus on what the measure should be.
> You have one, and just about everyone else has another.
>
> Thus, you're arguing at the wrong level.
Perhaps you are right. Most of the time I was making
the assumption that everyone else found non-macro means
more clean. I do believe that most people really do
find the non-macro means cleaner, just less powerful.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: thi
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m2rd7n8ebl6.fsf@netcom9.netcom.com>
Peaker <·········@yahoo.com> writes:
> Perhaps you are right. Most of the time I was making
> the assumption that everyone else found non-macro means
> more clean. I do believe that most people really do
> find the non-macro means cleaner, just less powerful.
this is called "projection" is pop-psych circles (like c.l.l!).
thi
From: Frode Vatvedt Fjeld
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <2hr9bpgab2.fsf@dslab7.cs.uit.no>
Peaker <·········@yahoo.com> writes:
> [...] The best way to contradict that would probably be to bring
> some macro definitions that are simply not doable using non-macro
> means. Thomas A. Russ brought a few nice examples of how macros
> effectively extend the language. I brought equivalent non-macro
> solutions, that show that all the specific macro functionality from
> his examples can be implemented using the non-macro means.
The point of macros is not that it provides something that is
otherwise _impossible_. Your counter-examples, as was pointed out by
someone else, are considered to be inferior to the macro versions in
every respect (like readability, flexibilty, performace). That is how
you are being contradicted. You may of course say that _you_ find your
non-macro solutions are more readable, that you don't care about the
performance loss etc. But don't expect anyone else to care.
--
Frode Vatvedt Fjeld
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8ed36j$7pi$1@joe.rice.edu>
In article <·················@yahoo.com> posted on Friday, April 28,
2000 3:43 PM, Peaker <·········@yahoo.com> wrote:
> I did not say CLOS+MOP was not powerful. I think it is safe to say,
> however, that the LISP syntax values simplicity over many things, and
> the syntax/lang. itself is not related in any way to the object model, and
> is simply not extendible in means other than macros (such as, for example,
> operator overloading).
In CL the "operators" (methods) are MORE overloadable than in most other
object systems.
> Which is why I also consider examples of how
> macros are useful in extending the LISP syntax simply invalid to the
> argument of whether or not the concept macros is useful.
Macros extend syntax (control structures), they should not be used for
overloading operators.
> As powerful as CLOS+MOP may be, I would not consider it an
> alternative to macros in replacing the language extendibility abilities.
Which is why it's not.
> I've not yet noticed a contradiction of that claim. The best way to contradict
> that would probably be to bring some macro definitions that are simply not
> doable using non-macro means. Thomas A. Russ brought a few nice
> examples of how macros effectively extend the language. I brought
> equivalent non-macro solutions, that show that all the specific macro
> functionality from his examples can be implemented using the non-macro
> means. I challange you to contradict me by bringing examples of
> extensions that I simply cannot replicate using non-macro means.
How did you propose to write LOOP as a function and still have it execute
at a somewhat reasonable speed? Macros are used for transforming code at
_compile_ time, so that these transformations do not need to be applied
at run time.
> By the concept of an 'ideal language', I obviously refer to my oppinion of
> an ideal language, which is a language that has all the extendibility, but not
> the macros.
Macros are what _make_ the language extensible. The alternatives you've
shown have been tried and discarded.
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390AC985.96E8CE39@yahoo.com>
Rahul Jain wrote:
> > I've not yet noticed a contradiction of that claim. The best way to contradict
> > that would probably be to bring some macro definitions that are simply not
> > doable using non-macro means. Thomas A. Russ brought a few nice
> > examples of how macros effectively extend the language. I brought
> > equivalent non-macro solutions, that show that all the specific macro
> > functionality from his examples can be implemented using the non-macro
> > means. I challange you to contradict me by bringing examples of
> > extensions that I simply cannot replicate using non-macro means.
>
> How did you propose to write LOOP as a function and still have it execute
> at a somewhat reasonable speed? Macros are used for transforming code at
> _compile_ time, so that these transformations do not need to be applied
> at run time.
Note that the fact macros force code to be created at compile-time is a
disadvantage, because function code can be inline'd and partially
evaluated (equivalent to macro-expanding) OR called, while macros are
always expanded.
I would write a LOOP as a method on a block returning bool, that used a
'goto' construct that is merely available for the low-level functionality and
implementability of such a concept.
> > By the concept of an 'ideal language', I obviously refer to my oppinion of
> > an ideal language, which is a language that has all the extendibility, but not
> > the macros.
>
> Macros are what _make_ the language extensible. The alternatives you've
> shown have been tried and discarded.
Discarded by whom? Note most languages used today, are far from having
macros as powerful as LISP's, or even have no macros. I would not
conclude things about a language according to hope people use it and what
they choose to discard.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390AD086.260FEDF7@yahoo.com>
Peaker wrote:
> out a language according to hope people use it and what
Small correction:
according to how people use it and what ...
Sorry.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8efj1k$3nm$1@joe.rice.edu>
In article <·················@yahoo.com> posted on Saturday, April 29,
2000 6:37 AM, Peaker <·········@yahoo.com> wrote:
> Rahul Jain wrote:
>
>> How did you propose to write LOOP as a function and still have it execute
>> at a somewhat reasonable speed? Macros are used for transforming code at
>> _compile_ time, so that these transformations do not need to be applied
>> at run time.
>
> Note that the fact macros force code to be created at compile-time is a
> disadvantage, because function code can be inline'd and partially
> evaluated (equivalent to macro-expanding) OR called, while macros are
> always expanded.
That's a non-issue. The memory savings from not having to parse the whole
LOOP body at runtime surely outweigh the slightly increased code size.
(and note that the LOOP body will need to be saved as symbols, not as
machine/byte code so it is likely to be even _larger_.)
> I would write a LOOP as a method on a block returning bool, that used a
> 'goto' construct that is merely available for the low-level functionality and
> implementability of such a concept.
So how does that actually accomplish what LOOP does? Are you saying that we
remove LOOP and just use TAGBODY? Or should we just forget about HLLs and
program everything in assembly?
>> Macros are what _make_ the language extensible. The alternatives you've
>> shown have been tried and discarded.
>
> Discarded by whom? Note most languages used today, are far from having
> macros as powerful as LISP's, or even have no macros. I would not
> conclude things about a language according to hope people use it and what
> they choose to discard.
So your judgement is better than (probably) hundreds of experts in the field
who have actually USED and UNDERSTOOD the language constructs they're
analyzing?
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Rahul Jain <·····@rice.edu> wrote in message
·················@joe.rice.edu...
> So how does that actually accomplish what LOOP does? Are you saying that
we
> remove LOOP and just use TAGBODY? Or should we just forget about HLLs and
> program everything in assembly?
I'm sure he does not want this as most assemblers are macro-assemblers...
In fact the it's interresting that both Lisp and assembly languages are the
languages with the more powerful macro capabilities.
Marc Battyani
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8eflrr$6s0$1@joe.rice.edu>
In article <··················································@lp.airnews.net>
posted on Saturday, April 29, 2000 4:30 PM, "Marc Battyani" <·············@csi.com> wrote:
> Rahul Jain <·····@rice.edu> wrote in message
> ·················@joe.rice.edu...
>> So how does that actually accomplish what LOOP does? Are you saying that
> we
>> remove LOOP and just use TAGBODY? Or should we just forget about HLLs and
>> program everything in assembly?
>
> I'm sure he does not want this as most assemblers are macro-assemblers...
> In fact the it's interresting that both Lisp and assembly languages are the
> languages with the more powerful macro capabilities.
Yeah, I was thinking about that subject while I was writing my post, too...
maybe change that to non-macro assemblers and he'll be happy :)
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Erik Naggum
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3166034318949868@naggum.no>
* "Marc Battyani" <·············@csi.com>
| In fact it's interresting that both Lisp and assembly languages are
| the languages with the more powerful macro capabilities.
especially those popular at the time people were expected to write
real code in assembly. I only got really familiar with the PDP-10
and its MACRO-10 language among the great processors of our time,
but, boy, what an incredibly powerful macro language! tell this to
the kids these days, however, and they just won't believe you.
#:Erik
From: Paolo Amoroso
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <XlAMORjSe4f8D5XXums8yyL=sKiJ@4ax.com>
On 29 Apr 2000 21:58:38 +0000, Erik Naggum <····@naggum.no> wrote:
> real code in assembly. I only got really familiar with the PDP-10
> and its MACRO-10 language among the great processors of our time,
> but, boy, what an incredibly powerful macro language! tell this to
> the kids these days, however, and they just won't believe you.
I am a kid--technologically wise--but I do believe you :) Could you
elaborate on this? What were the most powerful or interesting features of
MACRO-10?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <usnw5pze6.fsf@alum.mit.edu>
Peaker <·········@yahoo.com> writes:
> Joe Marshall wrote:
>
> > What exactly do you mean by `unclean' or `*CLEANER*'? How are you
> > measuring `cleanliness'?
>
> Its a complex subjective term, and I doubt I can do well defining it, but I can
> say it directly relates to readability.
And you measure readability how? If `cleanliness' is some vague,
ill-defined, subjective term, I doubt very much that you'll be
satisfied by *any* answer in here. It would be an issue of taste
and opinion, rather than a technical issue.
> > > I am criticising LISP for not providing powerful-enough alternative
> > > features such as a built-in powerful object model and syntax features
> > > concerning that, that can also change the ways things are evaluated, and
> > > provide a CLEANER mean than macros, for the same purpose.
> >
> > I guess if CLOS+MOP isn't powerful enough for you, you should consider
> > using another language. If the ability to modify and extend the
> > readtable, evaluator, and compiler isn't enough to change the way
> > things are evaluated, you're SOL as far as Lisp is concerned.
>
> I did not say CLOS+MOP was not powerful.
Um, I'm re-reading that sentence and it still looks to me like you are.
> Which is why I also consider examples of how
> macros are useful in extending the LISP syntax simply invalid to the
> argument of whether or not the concept macros is useful.
Ok, so not only are you attempting to `measure' the language against
against some subjective scale, you consider explicit counterexamples
to be invalid.
> > > What I am trying to request there is, the contradiction of the claim that in an
> > > ideal language, there is ALWAYS a cleaner way than macros, and therefore
> > > macros only provide extra mess.
> >
> > We've been contradicting you.
>
> I've not yet noticed a contradiction of that claim.
Read the next sentence carefully; you will see your claim contradicted.
---> `Your claim is false.' <---
> The best way to contradict
> that would probably be to bring some macro definitions that are simply not
> doable using non-macro means.
1. Most things done with a macro simply cannot be done in an
_identical_ way by non-macro means.
2. Everything done with a macro *can* be accomplised in some
non-identical way with a non-macro. At the ludicrous limit, you
write an interpreter.
3. You consider examples of macros simply invalid to the argument.
> Thomas A. Russ brought a few nice
> examples of how macros effectively extend the language. I brought
> equivalent non-macro solutions, that show that all the specific macro
> functionality from his examples can be implemented using the non-macro
> means. I challange you to contradict me by bringing examples of
> extensions that I simply cannot replicate using non-macro means.
LOOP, CLOS, Dick Waters' STREAMS, ....
> > > I don't see how I could have made that any more specific.
> >
> > How about by defining cleanliness in a quantifiable way, defining what
> > you mean by `ideal language'?
>
> Cleanliness
> is subjective but some charactaristics are quite absoloute, and can roughly
> measure the cleanliness of a piece of code. I would say the simplest way to
> measure cleanliness, is to measure readability (probably just as problematic
> as well, but probably better defined than cleanliness).
Not to me. What are these absolutes?
> By the concept of an 'ideal language', I obviously refer to my oppinion of
> an ideal language, which is a language that has all the extendibility, but not
> the macros.
Why is this ideal?
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390ACE66.E5A19AF5@yahoo.com>
> And you measure readability how? If `cleanliness' is some vague,
> ill-defined, subjective term, I doubt very much that you'll be
> satisfied by *any* answer in here. It would be an issue of taste
> and opinion, rather than a technical issue.
Yes, whether or not the alternatives to macros are cleaner is mostly a matter
of taste. However, even most macro-supporters agree that the alternatives
are generally cleaner. Most merely state they are less powerful.
> > > > I am criticising LISP for not providing powerful-enough alternative
> > > > features such as a built-in powerful object model and syntax features
> > > > concerning that, that can also change the ways things are evaluated, and
> > > > provide a CLEANER mean than macros, for the same purpose.
> > >
> > > I guess if CLOS+MOP isn't powerful enough for you, you should consider
> > > using another language. If the ability to modify and extend the
> > > readtable, evaluator, and compiler isn't enough to change the way
> > > things are evaluated, you're SOL as far as Lisp is concerned.
> >
> > I did not say CLOS+MOP was not powerful.
>
> Um, I'm re-reading that sentence and it still looks to me like you are.
What syntax features concerning the object model are there? Can you use the
object model of CLOS to create a Query language as done with the 'retrieve'
macro, and can be done with powerful enough alternative object-models?
> > Which is why I also consider examples of how
> > macros are useful in extending the LISP syntax simply invalid to the
> > argument of whether or not the concept macros is useful.
>
> Ok, so not only are you attempting to `measure' the language against
> against some subjective scale, you consider explicit counterexamples
> to be invalid.
You seriously misunderstood me there. That macros are not useful for
_LISP_ I do not claim. What I claim is, that the fact they are useful for LISP
does not mean that macros are a useful concept in general, and therefore
bringing examples of how macros are useful in LISP may show that
macros are useful for LISP, but not that macros are useful everywhere.
What I'm trying to say is that macros are only useful in languages without
the powerful alternative ways, for those who find those alternative ways
cleaner. Those are most people.
> > > > What I am trying to request there is, the contradiction of the claim that in an
> > > > ideal language, there is ALWAYS a cleaner way than macros, and therefore
> > > > macros only provide extra mess.
> > >
> > > We've been contradicting you.
> >
> > I've not yet noticed a contradiction of that claim.
>
> Read the next sentence carefully; you will see your claim contradicted.
>
> ---> `Your claim is false.' <---
Now I think you're doing this on purpose. You obviously understand that
shooting unestablished contradicting sentences into the air is not what I
mean by 'contradicting me'.
> > The best way to contradict
> > that would probably be to bring some macro definitions that are simply not
> > doable using non-macro means.
>
> 1. Most things done with a macro simply cannot be done in an
> _identical_ way by non-macro means.
How identical do you want those to be? If you want the advantages of the
things done with macros, you have those in the non-macro means, and if
you think you don't, please bring an example to demonstrate that, that I've
yet to see.
> 2. Everything done with a macro *can* be accomplised in some
> non-identical way with a non-macro. At the ludicrous limit, you
> write an interpreter.
If you can bring here a case in which I would have to write an interpretr
to simulate a useful macro of yours, I would agree.
> 3. You consider examples of macros simply invalid to the argument.
>
> > Thomas A. Russ brought a few nice
> > examples of how macros effectively extend the language. I brought
> > equivalent non-macro solutions, that show that all the specific macro
> > functionality from his examples can be implemented using the non-macro
> > means. I challange you to contradict me by bringing examples of
> > extensions that I simply cannot replicate using non-macro means.
>
> LOOP, CLOS, Dick Waters' STREAMS, ....
Loop is implement'able in non-macro means, I've shown the use of a non-
macro LOOP in my reply to Russ's examples, but I've not shown the
implementation. It should be easily implementable with a built-in 'goto'
statement which is there for other control structures to be built with (and
not be used by actual code).
CLOS is impossible to implement as an extension without macros, but note
the alternative I've suggested to macros IS a powerful object model, which
means the features of CLOS are already BUILT-IN.
I would request information, or pointers to information about 'Dick
Waters' STREAMS' so I can suggest how to implement those with macro
alternatives.
> > > > I don't see how I could have made that any more specific.
> > >
> > > How about by defining cleanliness in a quantifiable way, defining what
> > > you mean by `ideal language'?
> >
> > Cleanliness
> > is subjective but some charactaristics are quite absoloute, and can roughly
> > measure the cleanliness of a piece of code. I would say the simplest way to
> > measure cleanliness, is to measure readability (probably just as problematic
> > as well, but probably better defined than cleanliness).
>
> Not to me. What are these absolutes?
For example, the lack of noise. Or the direct link between syntax/semantics
and the actual meaning. I would say, for example, that an RSA-
encrypted piece of code is absoloutely less readable than the original,
unencrypted piece of code.
> > By the concept of an 'ideal language', I obviously refer to my oppinion of
> > an ideal language, which is a language that has all the extendibility, but not
> > the macros.
>
> Why is this ideal?
"... my oppinion ..., which is a language that has all the extendibility, but not
the macros."
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <uya5w4y1p.fsf@alum.mit.edu>
Peaker <·········@yahoo.com> writes:
> > And you measure readability how? If `cleanliness' is some vague,
> > ill-defined, subjective term, I doubt very much that you'll be
> > satisfied by *any* answer in here. It would be an issue of taste
> > and opinion, rather than a technical issue.
>
> Yes, whether or not the alternatives to macros are cleaner is mostly a matter
> of taste. However, even most macro-supporters agree that the alternatives
> are generally cleaner. Most merely state they are less powerful.
I'm not a `macro supporter' (but I play one on C.L.L), however I gave
several examples before where macros are exactly the right tool.
Macros are for modifying the syntax of the language to bring it in
line with the problem you are addressing. Consider my hypothetical
example of:
(define-alu-operation MOVI ((reg register) (value immediate))
(assign-register reg (fetch-indirect (post-increment pc))))
Now imagine the macro DEFINE-ALU-OPERATION expands into something
along the lines of:
(progn
(defun aluop-movi (reg value)
(check-type reg register)
(check-type value immediate)
(assign-register reg (fetch-indirect (post-increment pc))))
(eval-when (:load-toplevel :execute)
(if (gethash 'movi *alu-opcodes*)
(warn "Redefinition of opcode ~a" 'movi))
(setf (gethash 'movi *alu-opcodes*) #'aluop-movi))
)
We want DEFINE-ALU-OPERATION to be a simple syntactic extension of the
language. Sure, we could write it as a function, but look what happens:
(define-alu-operation 'MOVI '((reg register) (value immediate))
#'(lambda (reg value)
(assign-register reg (fetch-indirect (post-increment pc)))))
Or we could write it as a clos object:
(make-instance 'alu-operation
:name 'movi
:arglist '((reg register) (value immediate))
:action #'(lambda (reg value)
(assign-register reg (fetch-indirect (post-increment pc)))))
As a matter of fact, DEFINE-ALU-OPERATION could expand into either of
the previous two forms. The point is that DEFINE-ALU-OPERATION is a
piece of new syntax designed to make alu opcode definition clear,
concise, and obvious.
The main reason macros are `unclean' are because they introduce new
syntax into the language. New syntax, by definition, doesn't follow
the normal rules of evaluation, and therefore imposes a burden upon
the programmer. On the other hand, new syntax may allow you to
express something that was cumbersome to express before, thus
relieving the programmer of a different burden.
If you find *all* new syntax to be too burdensome, then you will never
be satisfied with any use of it.
> > > Which is why I also consider examples of how
> > > macros are useful in extending the LISP syntax simply invalid to the
> > > argument of whether or not the concept macros is useful.
> >
> > Ok, so not only are you attempting to `measure' the language against
> > against some subjective scale, you consider explicit counterexamples
> > to be invalid.
>
> You seriously misunderstood me there. That macros are not useful for
> _LISP_ I do not claim. What I claim is, that the fact they are useful for LISP
> does not mean that macros are a useful concept in general, and therefore
> bringing examples of how macros are useful in LISP may show that
> macros are useful for LISP, but not that macros are useful everywhere.
Perhaps not macros per se, but syntactic extenions may be useful in
*all* languages simply because no language understands all syntax. In
Lisp, syntactic extensions are done with macros, in other languages,
perhaps you use FEXPRS or the equivalent. In some languages perhaps
you use the object system.
> What I'm trying to say is that macros are only useful in languages without
> the powerful alternative ways, for those who find those alternative ways
> cleaner. Those are most people.
I disagree. Macros are perfectly clean for simple syntactic
transformations.
> > > The best way to contradict
> > > that would probably be to bring some macro definitions that are simply not
> > > doable using non-macro means.
> >
> > 1. Most things done with a macro simply cannot be done in an
> > _identical_ way by non-macro means.
>
> How identical do you want those to be? If you want the advantages of the
> things done with macros, you have those in the non-macro means, and if
> you think you don't, please bring an example to demonstrate that, that I've
> yet to see.
I mean *precisely* identical. No quotes, square brackets, #'(lambda
(), make-instance, etc. And this is the main point. The macro
provides a syntactic transformation *only*, and it is the precise
syntax that cannot be duplicated without the macro.
Since macros only tranform syntax, the semantics must be supplied by
other means. That's proof positive that everything a macro does can
be done by non-macro means.
Now if you believe, as you seem to, that all syntactic transformations
to the language are `unclean', then *no* syntactic transformation
could be `cleaner' than the form it is transformed to, in *any*
language. If so, there is nothing to discuss.
> > LOOP, CLOS, Dick Waters' STREAMS, ....
>
> Loop is implement'able in non-macro means.
Of course it is. It has to be. The macro is a syntactic
transformation that simply rewrites LOOP into something that doesn't
involve a macro.
> CLOS is impossible to implement as an extension without macros, but note
> the alternative I've suggested to macros IS a powerful object model, which
> means the features of CLOS are already BUILT-IN.
Actually, the bulk of CLOS *could* be implemented without macros. The
nice syntax of DEFMETHOD, DEFGENERIC, and DEFCLASS, would be replaced
with the uglier expansion, but you could.
But CLOS isn't generally used for syntactic transformations. Not that
you couldn't do this in lisp, its that very few syntactic
transformations need the full CLOS object model behind them to
accomplish the transformation.
> > > > > I don't see how I could have made that any more specific.
> > > >
> > > > How about by defining cleanliness in a quantifiable way, defining what
> > > > you mean by `ideal language'?
> > >
> > > Cleanliness
> > > is subjective but some charactaristics are quite absoloute, and can roughly
> > > measure the cleanliness of a piece of code. I would say the simplest way to
> > > measure cleanliness, is to measure readability (probably just as problematic
> > > as well, but probably better defined than cleanliness).
> >
> > Not to me. What are these absolutes?
>
> For example, the lack of noise.
What's noise in this case?
> > > By the concept of an 'ideal language', I obviously refer to my oppinion of
> > > an ideal language, which is a language that has all the extendibility, but not
> > > the macros.
> >
> > Why is this ideal?
>
> "... my oppinion ..., which is a language that has all the extendibility, but not
> the macros."
I don't understand what you are objecting to. You want `all the
extendibility', I presume that includes simple syntactic
transformations, but you don't want macros, which precludes simple
syntactic transformations. Make up your mind.
--
~jrm
From: Hartmann Schaffer
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390b3995@news.sentex.net>
In article <·················@yahoo.com>,
Peaker <·········@yahoo.com> writes:
> ...
> You seriously misunderstood me there. That macros are not useful for
> _LISP_ I do not claim. What I claim is, that the fact they are useful for LISP
> does not mean that macros are a useful concept in general, and therefore
> bringing examples of how macros are useful in LISP may show that
> macros are useful for LISP, but not that macros are useful everywhere.
> What I'm trying to say is that macros are only useful in languages without
> the powerful alternative ways, for those who find those alternative ways
> cleaner. Those are most people.
did you ever wonder why macros are less useful in other languages? hint
(imo): lisp programs syntax is represented by data structures built
into the language, and you have the full power of the language available
when you write the macros. Also, the language syntax is sufficiently
simple that when writing a macro you need not worry too much about
parsing the source and concentrate your attention on the macro's
functionality. this makes the macrosystem powerful enough that you can
even define new control structures. i don't know any other language
where macros are that easy. i suggest the real reason why other
languages have these features is that they must be built in because
there is no way how you can implement them with their macro facilities.
> ...
--
Hartmann Schaffer
From: Robert Monfera
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390BC0B8.DBAA49C7@fisec.com>
Peaker wrote:
> > > I did not say CLOS+MOP was not powerful.
> >
> > Um, I'm re-reading that sentence and it still looks to me like you are.
>
> What syntax features concerning the object model are there? Can you use
> the object model of CLOS to create a Query language as done with the
> 'retrieve' macro, and can be done with powerful enough alternative
> object-models?
First you make a blanket statement (even worse, you _imply_ things about
CLOS capabilities or their lack thereof) without doing research, then
deny it, then you ask back if this+that possible with CLOS. Try to be
positive: _state_ that CLOS lacks the ability to do this and that, and
that you made your conclusion based on studying and trying hard.
There are a lot of misunderstandings about the relationship of OO and
Lisp. One of them is that CL is less object-oriented than another
language that is object-oriented from head to toe. By the time
Smalltalk evolved, Lisp was already powerful and object-oriented even
without being called OO. Also, nobody stops you from thinking in terms
of classes, depicted this way:
(defmethod 2arg-+ ((arg1 integer) (arg2 integer)) ...)
(defmethod 2arg-+ ((arg1 integer) (arg2 real)) ...)
(defmethod + (&rest args)
(reduce #'2arg-+ args))
Robert
From: Tim Bradshaw
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <ey3zoqes0oh.fsf@cley.com>
* Peaker wrote:
> As I mentioned earlier, LISP *DOES* require macros for the extra
> convinience and usefulness. I am not critizing LISP programmers for using
> macros. I am criticising LISP for not providing powerful-enough alternative
> features such as a built-in powerful object model and syntax features
> concerning that, that can also change the ways things are evaluated, and
> provide a CLEANER mean than macros, for the same purpose.
Lisp has an object model more powerful than any other language I
know, certainly more powerful than smalltalk. It is also essentially
trivial to alter the evaluation rules in the way smalltalk does. You
could easily make things be so that:
(iff form
{...}
{...})
was just a normal function, and {...} is a tiny bit of magic to do
what [...] does in smalltalk.
You really need to learn something about Lisp I think.
--tim
From: Erik Naggum
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3165818279680358@naggum.no>
* Peaker <·········@yahoo.com>
| In my question, I was aware that LISP macros allow lower-level
| access to the syntax (changing the way things are parsed),
this is not true. you seem to be confusing reader macros with
macros, as many complete novices do.
| My theory is, that the high-level syntax is extendible, when the
| basic object model is extendible enough, and that the low-level
| syntax need not change, which is why I dislike LISP's way of
| providing means to change the low-level syntax.
no, you dislike it because you don't understand it on its own terms,
but rather want to force it into a different model. you must make a
distinction between disliking the model and its expression before
you can proceed usefully. but since you appear to dislike the Lisp
model a priori, I don't think there's much point in proceeding in
this direction. just find a language whose model you like and use
it productively.
#:Erik
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <u8zxzpqlh.fsf@alum.mit.edu>
Peaker <·········@yahoo.com> writes:
> Well, the idea is, that when the syntax is so small, you may not ever need
> to change it, as the language consists of very little syntax, and a lot of
> object operations. In my question, I was aware that LISP macros allow
> lower-level access to the syntax (changing the way things are parsed),
You *can* change the way things are parsed, but that is via the
readtable, not macros.
You can differentiate `syntax' (how groups of tokens are taken to form
expressions) from `microsyntax' (how groups of characters are taken to
form tokens). People don't often fool around with the microsyntax of
lisp.
> however, I am suggesting that it may not be necessary, and that an
> extendible object model may be all you'll ever need to change about the
> language (which is what I want you to contradict by bringing practical
> examples of things possible to achieve by affecting the ways things are
> parsed (macros), and not by extending the object model).
That's true. In fact, *objects* aren't needed. Neither are *names*.
If you want, we can reduce the entire language down to strings of S
and K operators. For some reason that idea hasn't caught on, though.
The point of any programming language construct is to allow you to
write down *what you mean* as directly and clearly as possible to
communicate it to other programmers *and* to the computer. Macros are
one tool for doing this, objects are another. You should use either
one as necessary.
> My theory is, that the high-level syntax is extendible, when the basic
> object model is extendible enough, and that the low-level syntax need not
> change, which is why I dislike LISP's way of providing means to change
> the low-level syntax.
So don't use it.
--
~jrm
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <bcZN4.10$xb5.725@burlma1-snr2>
In article <·············@alum.mit.edu>,
Joe Marshall <·········@alum.mit.edu> wrote:
>Peaker <·········@yahoo.com> writes:
>
>> Well, the idea is, that when the syntax is so small, you may not ever need
>> to change it, as the language consists of very little syntax, and a lot of
>> object operations. In my question, I was aware that LISP macros allow
>> lower-level access to the syntax (changing the way things are parsed),
>
>You *can* change the way things are parsed, but that is via the
>readtable, not macros.
>
>You can differentiate `syntax' (how groups of tokens are taken to form
>expressions) from `microsyntax' (how groups of characters are taken to
>form tokens). People don't often fool around with the microsyntax of
>lisp.
"microsyntax" is usually referred to as something like "lexical structure"
(or something with the word "lexical" in it).
--
Barry Margolin, ······@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.
From: Paolo Amoroso
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <RHwJOa16CbJOoyydSo2RJ2o=qfKX@4ax.com>
On 27 Apr 2000 10:26:34 -0400, Joe Marshall <·········@alum.mit.edu> wrote:
> The point of any programming language construct is to allow you to
> write down *what you mean* as directly and clearly as possible to
The INTERCAL designers may disagree :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <un1meqs3l.fsf@alum.mit.edu>
Paolo Amoroso <·······@mclink.it> writes:
> On 27 Apr 2000 10:26:34 -0400, Joe Marshall <·········@alum.mit.edu> wrote:
>
> > The point of any programming language construct is to allow you to
> > write down *what you mean* as directly and clearly as possible to
>
> The INTERCAL designers may disagree :)
Oh, I don't know, suppose you want to effectively change all dynamic
binding of special variables into assignments. This is very directly
and clearly written in INTERCAL:
PLEASE ABSTAIN FROM STASHING + RETRIEVING
If only such power and expressability were available in CommonLisp.
From: Thomas A. Russ
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <ymihfcntpjo.fsf@sevak.isi.edu>
One of the problems is that most of the truly interesting examples of
the power of Common Lisp macros are not simple examples. I will try to
show a couple of examples, however.
The first is the WITH-OPEN-FILE macro from Common Lisp itself. The
fundamental issue is to provide a nice, simple and safe environment for
doing file operations. When a program opens a file, it should close the
file -- even (especially?) if an error occurs while the program is
reading from the file. The way to do this nicely in CL is:
(with-open-file (input-stream "name-of-my-file")
(read-some-stuff input-stream)
(read-other-stuff input-stream))
Now, this can be done using the UNWIND-PROTECT form in CL. (If you
aren't familiar with this form, it is similar to Java's
"try {...} finally {...}" construct.
In fact, that is how the Common Lisp macro is implemented. Looking at
the macroexpansion from Allegro CL version 4.3 I notice that the
implementation is pretty close to what one would naively expect:
(LET ((INPUT-STREAM (OPEN "name-of-my-file")) (#:G15580 T))
(UNWIND-PROTECT
(MULTIPLE-VALUE-PROG1 (PROGN (READ-SOME-STUFF INPUT-STREAM)
(READ-OTHER-STUFF INPUT-STREAM))
(SETQ #:G15580 NIL))
(WHEN (STREAMP INPUT-STREAM) (CLOSE INPUT-STREAM :ABORT #:G15580))))
I also would point out that there are a few minor touches (such as the
:ABORT argument) that make the packaged code a bit safer. In fact,
since the WITH-OPEN-FILE macro only needs to be written once, it is more
likely that such extra effort for safety would be taken than if the
programmers had to include it every time they used an UNWIND-PROTECT
form. That is one of key arguments in favor of using Macros to extend
the language and package commonly useful operations in more convenient
forms. It becomes easier to have uniform code.
I will also note that this particular item would be rather difficult to
package as an object extension, since the body of the macro is a series
of language forms that need to be executed in an evironment established
by the macro itself.
One could do something like passing a list of functions with appropriate
parameters, to be executed once the environment is set up, but this is
often not done. I guess the closest that other languages would come to
this is to create instances of (possibly anonymous) classes which
implement some predefined method call and then package this up in a call
to another function which then calls this magic function name. That is
certainly doable, but is a lot more work (IMO) and which doesn't
generally encourage programmers to do it.
Now the example macro shown is essentially a fairly simple substitution
macro, so it doesn't really exploit the ability of macros to do
extensive code reformulation. But it is hard to find any simple
examples of the latter. I suppose that the LOOP macro might qualify:
(loop for i in L collect i)
partially expands into the following monstrosity in ACL 4.3:
(LET ((I NIL) (#:G15581 L))
(DECLARE (TYPE LIST #:G15581))
(LET* ((#:G15585 (LIST NIL)) (#:G15586 #:G15585))
(BLOCK NIL
(TAGBODY (WHEN (ENDP #:G15584) (GO END-LOOP))
(SETQ I (CAR #:G15584))
(SETQ #:G15584 (CDR #:G15584))
NEXT-LOOP (RPLACD #:G15586 (SETQ #:G15586 (LIST I)))
(WHEN (ENDP #:G15584) (GO END-LOOP))
(SETQ I (CAR #:G15584))
(SETQ #:G15584 (CDR #:G15584))
(GO NEXT-LOOP)
END-LOOP (RETURN-FROM NIL (CDR #:G15585))))))
From other systems you can get additional complexity from macro
expansion, for example from the Loom knowledge representation language
one can get write a query against the knowledge base using the RETRIEVE
macro:
(retrieve (?person ?age)
(:and (person ?person)
(> (height ?person) 1.5m)
(age ?person ?age)))
which produces the following wonderful :) expansion, which is a program
for computing the answer to the query.
(PROGN (LOOM::ENSURE-VISIBILITY-OF-UPDATES)
(LET ((LOOM::*DEFAULTMODEP* T))
(DECLARE (SPECIAL LOOM::*DEFAULTMODEP*))
(LET ((LOOM::*INSIDEQUERYP* T))
(LOOM::FAST-REMOVE-EQUAL-DUPLICATES
(LET ((LOOM::RESULTTUPLES NIL))
(LOOP FOR ?PERSON IN
(LOOM::GENERATE-INSTANCES-IN-QUERY USER-THEORY^PERSON)
WHEN
(LET (LOOM::QUERYRESULT)
(LOOP FOR #:V-15588 IN
(FUNCALL (GET
'USER-THEORY^HEIGHT
:LOOM-NO-DUPLICATES-COMPILED-FUNCTION)
(LOOM::GET-TEMPORALLY-OFFSET-INSTANCE
?PERSON))
DO
(WHEN (MEASURES:DIM> #:V-15588 1.5m)
(SETQ LOOM::QUERYRESULT T)))
LOOM::QUERYRESULT)
DO
(LOOP FOR ?AGE IN
(FUNCALL (GET 'USER-THEORY^AGE
:LOOM-NO-DUPLICATES-COMPILED-FUNCTION)
(LOOM::GET-TEMPORALLY-OFFSET-INSTANCE
?PERSON))
DO (PUSH (LIST ?PERSON ?AGE) LOOM::RESULTTUPLES)))
LOOM::RESULTTUPLES)))))
One beauty of doing this as a macro is that the resulting query program
can be compiled (which will happen fairly automatically if the user
includes the query in code which is compiled), or (with a bit more work)
compiled at run-time and then stored for better performance.
I suppose it is now up to you to explain how to accomplish these feats
using other means.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3908D64D.C42DCE6E@yahoo.com>
"Thomas A. Russ" wrote:
> The first is the WITH-OPEN-FILE macro from Common Lisp itself. The
> fundamental issue is to provide a nice, simple and safe environment for
> doing file operations. When a program opens a file, it should close the
> file -- even (especially?) if an error occurs while the program is
> reading from the file. The way to do this nicely in CL is:
>
> (with-open-file (input-stream "name-of-my-file")
> (read-some-stuff input-stream)
> (read-other-stuff input-stream))
>
> Now, this can be done using the UNWIND-PROTECT form in CL. (If you
> aren't familiar with this form, it is similar to Java's
> "try {...} finally {...}" construct.
This is quite possible as an object operation. I'd declare a method of the class
InputStream (Not of an instance, a method of the class itself), that took a
file-name and closure (a piece of code along with its used 'enviorment')
(A bit of pseudo Smalltalk-like object language code):
InputStream with FileName: "name-of-my-file" do:
input-stream | [ "input-stream is an argument to this anonymous
closure function"
input-stream read: some-stuff.
input-stream read: some-more-stuff.
].
This would call InputStream's "with Filename: do:" function, that takes a file
name to open
as an argument and a piece of closure code to execute under a try{} block once the
file is
open. Note also that since the anonymous code is a closure (I'm not sure if under
SmallTalk it is, but with a language that wishes to avoid macros, this would be a
necessity),
it has access to all the variables external to this small piece of code and
therefore does not
require argument-passing of the enviorment it needs.
> I will also note that this particular item would be rather difficult to
> package as an object extension, since the body of the macro is a series
> of language forms that need to be executed in an evironment established
> by the macro itself.
If anonymous closure code is declared as easily as you can wrap a few
expressions within [], this should not be a problem.
I don't think this is more work, I think it is equivalent, and probably much
easier to debug and a lot less messy to declare :)
> ...
> examples of the latter. I suppose that the LOOP macro might qualify:
>
> (loop for i in L collect i)
I've been informed that Smalltalk has an implementation of 'collect' with
loops, but I will implement another one in a Smalltalk-like language
anyway:
L collectElements: element | [^ True].
"This would return a collected list in which all elements for which 'True'
is true for, are collected. This is obviously all elements, but can also be
a boolean expression concerning the 'element'."
> From other systems you can get additional complexity from macro
> expansion, for example from the Loom knowledge representation language
> one can get write a query against the knowledge base using the RETRIEVE
> macro:
>
> (retrieve (?person ?age)
> (:and (person ?person)
> (> (height ?person) 1.5m)
> (age ?person ?age)))
A slow (yet simple) item-by-item parse (that does not use a query-language
syntax) could use:
database collectElements:
person | [
^(person isPerson & person height > 1.5m & person age =
age).
].
To really duplicate the power of macros in this case, and create a query
'language' as well, some more language features are required, and I am
not aware of Smalltalk providing those (No, I am not referring to features
that replicate macros or features that are specific for this case :)
This language would need some sort of static-typing scheme, and
operator/method overloading, so that a query language syntax can be
provided by a piece of code, in a way similar to how it is provided by the
macro.
Inside the Query namespace (that must be selected for the overloaded
operators to be defined, and therefore the Query language syntax to be
available), a set of operators that take a message/method name as an
l-value, and an arbitrary value as an r-value, and return a Query can
be implemented. For example:
Returns Query, operator= (MethodOfQueryable, Any);
Note that the specified 'Query', 'MethodOfQueryable', 'Any' are type
specifications.
This allows an equation query to be declared as easily as:
(Age = 5)
(isPerson = True)
'Age' is a method of the 'Person' class, that returns its age.
'isPerson' is a method that returns whether or not the class is of the
'Person' type.
Another set of operators can be defined on the (Query) such as '&'
'|' etc, that return Queries which are combinations of existing
queries.
Then, a Database class would be one consisting of many instances
of some 'Queryable' type. Each Database would have attached
tables for all sorts of optimizations (such as a hash-table to optimize
equation checks), for each element in the queryable type.
For example, the database containing a lot of 'Person's would have a
hash-table attached, that allows quickly finding all the entries of
some Age.
When a 'retrieve' method call is issued on a database, it takes a query
(such as: (isPerson = True) & (height > 1.5m) & (age = some_age))
and can use the prepared hash-tables/optimization-tables to perform
the query as efficiently as possible. (Not requiring running code on a
per-element basis). For example, in this case, it would be able to use
the Age hash-table to easily find all entries matching 'some_age', and
run the 'isPerson' method and 'height' method on each of those to
complete the query.
This demonstrates, that using static-typing along with operator
overloading, it is possible to extend the syntax in ways that provide
(IMO) all the useful power from macros, in a way that is much less
messy than macros.
Note that to replace macros, operator/method overloading, static-
typing, and even namespace-shadowing are required mechanisms,
and therefore Smalltalk does not completely remove the need for the
convinience/power in macros, and was only used as an example
language where its features allowed enough extensibility of the
object model to demonstrate how it can extend the usable syntax.
Final example:
database query: (isPerson = True) & (height > 1.5m) & (age = some_age).
I find it a lot more readable, too, don't you?
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Erik Naggum
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3165894081922447@naggum.no>
* Peaker <·········@yahoo.com>
| I find it a lot more readable, too, don't you?
sorry, no. I find the object model extremely constraining, just
like infix syntax is simple and compact for severely constrained
contexts and circumstances. once you leave the constrained world,
you have to _fight_ both of these premature optimizations by going
"underneath" their expression and thinking very carefully about what
they do because it will be uncommon to leave the constrained world,
and this is itself partly because it is painful to leave it. (sort
of like Tom Breton and his "optimization" for fewer levels of code
transformation still thinks he has to do with macros. competent
programmers gain a deep trust in their ability to deal with such
abstractions and do not fear localized and contained complexity,
except that both the object model and infix syntax _export_ their
complexity so you have no choice but to rub against the constraints
when using either.)
#:Erik
From: Courageous
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <39093CCD.E1EB657D@san.rr.com>
Erik Naggum wrote:
>
> * Peaker <·········@yahoo.com>
> | I find it a lot more readable, too, don't you?
>
> sorry, no. I find the object model extremely constraining, just
> like infix syntax is simple and compact for severely constrained
> contexts and circumstances.
Personally, I don't find that infix notation has much
merit, except for the fact that "that's what everyone is
used to". Really, I'd rather write (+ 3 4 5 6) than
(3 + 4 + 5 + 6) any day, and come now: is (+ 3 4) any more
syntactically unwieldly than (3 + 4)? Not that I can tell.
I suppose, perhaps, you're referring to all the very simple
expressions in other languages where the parentheses aren't
necessary? But then you and I both know that lisp programmers
stop seeing parens after a while...
I'm reminded of a study which showed that command line
environments were harder to learn but had higher payoff
in productivity in the end. I wouldn't really characterize
Lisp as being hard to learn at all, but I would still
characterize it somewhat like that: any initial investement
time is certainly paid off for by productivity in the end.
C/
Centuries ago, Nostradamus foresaw a time when Courageous would say:
>Erik Naggum wrote:
>> * Peaker <·········@yahoo.com>
>> | I find it a lot more readable, too, don't you?
>>
>> sorry, no. I find the object model extremely constraining, just
>> like infix syntax is simple and compact for severely constrained
>> contexts and circumstances.
>
>Personally, I don't find that infix notation has much
>merit, except for the fact that "that's what everyone is
>used to". Really, I'd rather write (+ 3 4 5 6) than
>(3 + 4 + 5 + 6) any day, and come now: is (+ 3 4) any more
>syntactically unwieldly than (3 + 4)? Not that I can tell.
The usual accusation is that "forcing" people into "unnatural" practices
like prefix/postfix notation rather than infix is "less intuitive."
It seems to me that this is rather like the mindless focus on having
applications have GUIs that are specifically designed so that users can
get started instantly with no apparent learning curve. The
point that gets pointed out is that this means that the computer is
accomodating the users rather than vice-versa.
The problem is that by starting off this way, the system may wind up
not being extensible, or terribly powerful. You may be able to write
a few expressions more simply by using infix notation, but it it makes
it impractical to do anything more sophisticated, that's a loss.
--
"The chat program is in public domain. This is not the GNU public
license. If it breaks then you get to keep both pieces."
(Copyright notice for the chat program)
········@ntlug.org - - <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Peaker
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3909FE18.F1CBE25C@yahoo.com>
Erik Naggum wrote:
> * Peaker <·········@yahoo.com>
> | I find it a lot more readable, too, don't you?
>
> sorry, no. I find the object model extremely constraining, just
> like infix syntax is simple and compact for severely constrained
> contexts and circumstances. once you leave the constrained world,
> you have to _fight_ both of these premature optimizations by going
> "underneath" their expression and thinking very carefully about what
> they do...
Can you give examples of contexts and circumstances where you'd
have to go underneath the expressions? I have noted the need to
actually understand the underlying implementation of such
abstractions existed, but only when the abstractions were implemented
incorrectly, or in a severely limited manner. Most implementations
have some imposed limitations, but when those are well documented,
they still do not require you to go underneath the expressions and
abstractions.
> .... competent
> programmers gain a deep trust in their ability to deal with such
> abstractions and do not fear localized and contained complexity,
> except that both the object model and infix syntax _export_ their
> complexity so you have no choice but to rub against the constraints
> when using either.)
Could you make yourself clearer on this point?
You do have to deal with some complexity with any
type of interface, but interfaces built of infix
operation definitions, and object models, tend to
make things simpler, and end up exporting less
complexity.
--
Micros~1 is history (www.microsoft.com).
Linux is the present (www.linux.org).
EROS is the future (www.eros-os.org).
From: Erik Naggum
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3165947477983371@naggum.no>
* Peaker <·········@yahoo.com>
| You do have to deal with some complexity with any type of interface,
| but interfaces built of infix operation definitions, and object
| models, tend to make things simpler, and end up exporting less
| complexity.
simpler? simpler than what? it has been pretty obvious for a while
that you don't really understand alternatives to your own one view.
that means you are _unable_ to make comparisons with any merits.
the people you argue against typically know dozens of languages.
Common Lisp has more than 40 years of history behind it. it's quite
amazing that you think you can beat that with arguments from
ignorance of what has been done and without making comparisons of
languages each on their _own_ merits.
I'm sorry to say so, but you're an annoying waste of time when you
don't want to respect the past and the knowledge and the decisions
of this community, before you want to impose your own desires from a
different community at best.
#:Erik
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <F4oO4.96$xb5.3350@burlma1-snr2>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> the people you argue against typically know dozens of languages.
> Common Lisp has more than 40 years of history behind it. it's quite
> amazing that you think you can beat that with arguments from
> ignorance of what has been done and without making comparisons of
> languages each on their _own_ merits.
And Smalltalk has about 30 years of history behind it, and manages to do
just as well with objects as we do with functions and macros.
If we had a reader macro for [ that expanded [ ... | ... ] into (lambda
(...) ...), we could write things like:
(with-open-file '("filename")
[ s |
<stuff that reads from S> ])
and implement WITH-OPEN-FILE as a function rather than as a macro, much as
in Smalltalk it would be implemented as an object call.
Both approaches have their merits. As I've said about 5 times, it's mainly
a stylistic choice -- there's not really anything fundamental about it.
Most of the "40 years of history" is actually "40 years of forming common
habits and idioms".
--
Barry Margolin, ······@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.
In article <·················@burlma1-snr2>, Barry Margolin
<······@genuity.net> wrote:
> If we had a reader macro for [ that expanded [ ... | ... ] into (lambda
> (...) ...), we could write things like:
>
> (with-open-file '("filename")
> [ s |
> <stuff that reads from S> ])
One of the wonderful things about Lisp is that it doesn't take much
more effort to implement such things than it does to lament about
not having them. This took about five minutes:
(defun read-smalltalk-like-[ (stream char &optional arg)
(declare (ignore char arg))
(let* ( (params (read-delimited-list #\| stream nil))
(body (read-delimited-list #\] stream nil)) )
(eval `(lambda ,params ,@body))))
(set-macro-character #\[ #'read-smalltalk-like-[)
(defun f-with-open-file (arg thunk)
(let ( file )
(unwind-protect
(progn
(setf file (apply 'open arg))
(funcall thunk file))
(if file (close file)))))
Erann Gat
···@jpl.nasa.gov
From: Marius Vollmer
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <87ln1xce9t.fsf@zagadka.ping.de>
···@jpl.nasa.gov (Erann Gat) writes:
> (defun read-smalltalk-like-[ (stream char &optional arg)
> (declare (ignore char arg))
> (let* ( (params (read-delimited-list #\| stream nil))
> (body (read-delimited-list #\] stream nil)) )
> (eval `(lambda ,params ,@body))))
^^^^
Why are you calling EVAL here? Doesn't it put the closure in the
wrong lexical environment? I think just returning `(lambda ...) is
the right thing. Just testing my understanding.
- Marius
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8ed2k8$73m$1@joe.rice.edu>
In article <·················@yahoo.com> posted on Friday, April 28,
2000 4:09 PM, Peaker <·········@yahoo.com> wrote:
> You do have to deal with some complexity with any
> type of interface, but interfaces built of infix
> operation definitions, and object models, tend to
> make things simpler, and end up exporting less
> complexity.
Excuse me? Infix syntax is full of ambiguity. You have to constantly
consider the precedence of operators, which is a waste of time. With
prefix syntax, there is never any ambiguity as to the associativity
of the operations.
Object models have nothing to do with this. CL has a HIGHLY developed
OO system. I personally don't know of a single one that has even equal
power and flexibilty. It's not perfect, but that's why we have the MOP.
Infix exports MORE complexity and involves more complexity INTERNALLY.
There really aren't many uses for it. Personally, I prefer both RPN and
prefix notation to infix for almost all situations. Only when you are
dealing with polynomials and have a few operators is infix preferable to
the others. But we rarely program with only 3 or 4 different types of
operations.
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <uCoO4.101$xb5.3308@burlma1-snr2>
In article <············@joe.rice.edu>, Rahul Jain <·····@rice.edu> wrote:
>Object models have nothing to do with this. CL has a HIGHLY developed
>OO system. I personally don't know of a single one that has even equal
>power and flexibilty. It's not perfect, but that's why we have the MOP.
I suspect Smalltalkers would not consider our object model so highly
developed, since CL is not objects all the way down like Smalltalk is.
We're both certainly better than C++, though.
--
Barry Margolin, ······@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.
From: Frank A. Adrian
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <VJpO4.943$x91.34598@news.uswest.net>
Barry Margolin <······@genuity.net> wrote in message
·······················@burlma1-snr2...
> I suspect Smalltalkers would not consider our object model so highly
> developed, since CL is not objects all the way down like Smalltalk is.
> We're both certainly better than C, though.
But, having used both, I'd say that CLOS has the better MOP. Smalltalk has
too much of its inheritance mechanism hardwired into its VM. Multiple
inheritance is a big win over double dispatch hacks, too. Minimal
differences, true, but when you're dealing with two strong contenders,
minutia matter. I won't get into the macro debate too much, but when I was
actively programming in Smalltalk, I found I missed them. I wanted to add a
macro-like capability but, with the heavy syntactic issues involved, it was
easier just to generate code specific to my needs, rather than attempting to
build a generalized code generation system. Again, minimal differences, but
I still choose Lisp.
faa
Frank A. Adrian <·······@uswest.net> wrote:
> Barry Margolin <······@genuity.net> wrote in message
> ·······················@burlma1-snr2...
> > I suspect Smalltalkers would not consider our object model so highly
> > developed, since CL is not objects all the way down like Smalltalk is.
> > We're both certainly better than C, though.
>
> But, having used both, I'd say that CLOS has the better MOP. Smalltalk has
> too much of its inheritance mechanism hardwired into its VM.
Well, I suppose. In most implementations, certainly. It's not hard to
add multiple inheriance, though. Or prototypes. Given that, which parts
do you think are problematically hard wired?
(I should say that one can add those alternative inheritance mechanisms
without giving rise to, e.g., terrible performance problems.)
> Multiple
> inheritance is a big win over double dispatch hacks, too.
Surely you mean multiple dispatch (i.e., selecting methods on the basis
of several or all the arguments rather than just the first)? Otherwise,
I'm confused.
Mutiple dispatch is definitely slicker from double dispatch, but I
believe double dispatch is mostly confined to the arithmetic hierachy.
Some pain when adding new numeric types, to be sure, but perhaps an
acceptible compromise if one isn't typically feeling the need for
multiple dispatch.
> Minimal
> differences, true, but when you're dealing with two strong contenders,
> minutia matter. I won't get into the macro debate too much, but when I was
> actively programming in Smalltalk, I found I missed them. I wanted to add a
> macro-like capability but, with the heavy syntactic issues involved, it was
> easier just to generate code specific to my needs, rather than attempting to
> build a generalized code generation system.
[snip]
I was wondering if you'd mind providing some of the details (e.g., why
you wanted one, what the heavy issues were, etc.)? I have been pondering
this question for some time. The major use for a macro expansion phase
In Smalltalk, as I see it, is to permit more flexiblity with inlining
various messages. This would make implementing *efficient* control
structures much easier. (In general, using the normal dispatch mechanism
for a control structure is only really useful for seldomly used
structures which are not time critical. The standard control stuctures,
e.g., #ifTrue:ifFalse are inlined for precisely this reason. Of course,
Self didn't have to go with compiler based inlining, so perhaps this
should be solved along those lines.)
--
Bijan Parsia
http://monkeyfist.com/
...among many things.
From: Frank A. Adrian
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <GCtO4.1322$x91.51128@news.uswest.net>
Bijan Parsia <·······@email.unc.edu> wrote in message
··································@email.unc.edu...
> Frank A. Adrian <·······@uswest.net> wrote:
>
> > Barry Margolin <······@genuity.net> wrote in message
> > ·······················@burlma1-snr2...
> > > I suspect Smalltalkers would not consider our object model so highly
> > > developed, since CL is not objects all the way down like Smalltalk is.
> > > We're both certainly better than C, though.
> >
> > But, having used both, I'd say that CLOS has the better MOP. Smalltalk
has
> > too much of its inheritance mechanism hardwired into its VM.
>
> Well, I suppose. In most implementations, certainly. It's not hard to
> add multiple inheriance, though. Or prototypes. Given that, which parts
> do you think are problematically hard wired?
>
> (I should say that one can add those alternative inheritance mechanisms
> without giving rise to, e.g., terrible performance problems.)
Unless you had access to and could change the VM code, the added multiple
inheritance stuff was much slower in method dispatch than the one hardwired
into the VM, usually going through the exception handling system and being
interpreted past there. You're correct that some Smalltalk vendors added
support for the notion (V2.5 of ParcPlace's Smalltalk-80, e.g.), but rolling
your own without VM support meant unacceptable performance hits.
>
> > Multiple
> > inheritance is a big win over double dispatch hacks, too.
>
> Surely you mean multiple dispatch (i.e., selecting methods on the basis
> of several or all the arguments rather than just the first)? Otherwise,
> I'm confused.
You, of course are correct. I meant multi-methods. However, mixins are a
lot slicker and convenient than message forwarding.
> Mutiple dispatch is definitely slicker from double dispatch, but I
> believe double dispatch is mostly confined to the arithmetic hierachy.
> Some pain when adding new numeric types, to be sure, but perhaps an
> acceptible compromise if one isn't typically feeling the need for
> multiple dispatch.
Not only in the arithmetic, but throughout the drawing model, as well.
Shapes and screens have to send quite a few messages between each other to
form a picture. It also leads to inconsistencies when it comes to drawing
to a printer context rather than to a screen.
> > Minimal
> > differences, true, but when you're dealing with two strong contenders,
> > minutia matter. I won't get into the macro debate too much, but when I
was
> > actively programming in Smalltalk, I found I missed them. I wanted to
add a
> > macro-like capability but, with the heavy syntactic issues involved, it
was
> > easier just to generate code specific to my needs, rather than
attempting to
> > build a generalized code generation system.
> [snip]
>
> I was wondering if you'd mind providing some of the details (e.g., why
> you wanted one, what the heavy issues were, etc.)? I have been pondering
> this question for some time. The major use for a macro expansion phase
> In Smalltalk, as I see it, is to permit more flexiblity with inlining
> various messages.
The applications I was working on had various rule-based subsystems and
database interfaces that were compiled into methods on the fly for
performance reasons. Generation of Smalltalk's heavier syntax was a
relatively big pain, compared to generating code expansions for Lisp.
Granted, either is a piece of cake compared to doing this for C++ or Java
:-).
>This would make implementing *efficient* control
> structures much easier. (In general, using the normal dispatch mechanism
> for a control structure is only really useful for seldomly used
> structures which are not time critical. The standard control stuctures,
> e.g., #ifTrue:ifFalse are inlined for precisely this reason.
Absolutely. I was going to mention this point as an aside, but I thought it
wasn't really salient. I didn't want to get into a discussion about
built-in compile-time expansion for relatively often used message sends vs.
run-of-the-mill method generation.
> Of course,
> Self didn't have to go with compiler based inlining, so perhaps this
> should be solved along those lines.)
It's quite possible, but most Lisp folk seem more comfortable with
declarations and macro expansion and code that is directly compiled. Self's
approach is more relevant if you're using a JIT'ted VM, have no
declarations, depend heavily on message sends, and can take the time to make
the JIT compiler more reflective. To do so in Lisp would make most of the
compilers out there generate larger code without much improvement in
performance.
faa
Frank A. Adrian <·······@uswest.net> wrote:
> Bijan Parsia <·······@email.unc.edu> wrote in message
> ··································@email.unc.edu...
> > Frank A. Adrian <·······@uswest.net> wrote:
> >
> > > Barry Margolin <······@genuity.net> wrote in message
> > > ·······················@burlma1-snr2...
> > > > I suspect Smalltalkers would not consider our object model so highly
> > > > developed, since CL is not objects all the way down like Smalltalk is.
> > > > We're both certainly better than C, though.
> > >
> > > But, having used both, I'd say that CLOS has the better MOP. Smalltalk
> has
> > > too much of its inheritance mechanism hardwired into its VM.
> >
> > Well, I suppose. In most implementations, certainly. It's not hard to
> > add multiple inheriance, though. Or prototypes. Given that, which parts
> > do you think are problematically hard wired?
> >
> > (I should say that one can add those alternative inheritance mechanisms
> > without giving rise to, e.g., terrible performance problems.)
>
> Unless you had access to and could change the VM code, the added multiple
> inheritance stuff was much slower in method dispatch than the one hardwired
> into the VM, usually going through the exception handling system and being
> interpreted past there.
Ooo. I stand corrected then.
> You're correct that some Smalltalk vendors added
> support for the notion (V2.5 of ParcPlace's Smalltalk-80, e.g.), but rolling
> your own without VM support meant unacceptable performance hits.
That's interesting. I'll have to think about ways of doing MI. I guess a
general optimized delegation mechanism might help.
> > > Multiple
> > > inheritance is a big win over double dispatch hacks, too.
> >
> > Surely you mean multiple dispatch (i.e., selecting methods on the basis
> > of several or all the arguments rather than just the first)? Otherwise,
> > I'm confused.
>
> You, of course are correct. I meant multi-methods. However, mixins are a
> lot slicker and convenient than message forwarding.
I can't say, not having worked with mixins (although they certainly
*seem* appealing).
> > Mutiple dispatch is definitely slicker from double dispatch, but I
> > believe double dispatch is mostly confined to the arithmetic hierachy.
> > Some pain when adding new numeric types, to be sure, but perhaps an
> > acceptible compromise if one isn't typically feeling the need for
> > multiple dispatch.
>
> Not only in the arithmetic, but throughout the drawing model, as well.
> Shapes and screens have to send quite a few messages between each other to
> form a picture. It also leads to inconsistencies when it comes to drawing
> to a printer context rather than to a screen.
Ah. I stand corrected again! Thanks.
[snip]
> > I was wondering if you'd mind providing some of the details (e.g., why
> > you wanted one, what the heavy issues were, etc.)? I have been pondering
> > this question for some time. The major use for a macro expansion phase
> > In Smalltalk, as I see it, is to permit more flexiblity with inlining
> > various messages.
>
> The applications I was working on had various rule-based subsystems and
> database interfaces that were compiled into methods on the fly for
> performance reasons.
Interesting.
> Generation of Smalltalk's heavier syntax was a
> relatively big pain, compared to generating code expansions for Lisp.
I'd imagine. But what about going directly to a parse tree and compiling
that to bytecode? (I.e., it sounds like you were doing source-to-source
transformations. I would have thought that compiling directly to a
MethodNode headed tree would have been simpler.)
> Granted, either is a piece of cake compared to doing this for C++ or Java
> :-).
But of course! :)
[snip]
> > Of course,
> > Self didn't have to go with compiler based inlining, so perhaps this
> > should be solved along those lines.)
>
> It's quite possible, but most Lisp folk seem more comfortable with
> declarations and macro expansion and code that is directly compiled.
True. But can't seem to get those Smalltalker's enthused about it ;)
> Self's
> approach is more relevant if you're using a JIT'ted VM, have no
> declarations, depend heavily on message sends,
Er...Like Smalltalk (which was the context I was considering, which
wasn't obvious from what I wrote; sorry).
> and can take the time to make
> the JIT compiler more reflective. To do so in Lisp would make most of the
> compilers out there generate larger code without much improvement in
> performance.
I'll bet. But, I was wondering at the relative advantages and
disadvantages of adding a macro facility to Smalltalk rather than taking
the Self approach. I suspect that the decision isn't as clear as it is
for Lisp.
But now we're *really* just into talking about Smalltalk, and thus
somewhat off topic for the newsgroup :)
--
Bijan Parsia
http://monkeyfist.com/
...among many things.
From: Frank A. Adrian
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <JZPO4.512$S03.52209@news.uswest.net>
Bijan Parsia <·······@email.unc.edu> wrote in message
····································@email.unc.edu...
> > Generation of Smalltalk's heavier syntax was a
> > relatively big pain, compared to generating code expansions for Lisp.
>
> I'd imagine. But what about going directly to a parse tree and compiling
> that to bytecode? (I.e., it sounds like you were doing source-to-source
> transformations. I would have thought that compiling directly to a
> MethodNode headed tree would have been simpler.)
Yes. If We could have extended our funding, we would have eventually moved
that way. We already had a specialized browser for rules.
When I looked at doing macros for Smalltalk, I looked at doing them right
(i.e., specialize the browser, so it knew when you were looking at a macro,
adding the macro support to the VW compiler, etc.).
The first hurdle would have been what you showed in the macro edit window
for the source code. How do you syntactically differentiate the template
for the generated code from the expansion-time code? I could never come up
with a good syntax that fit into Smalltalk for that. The other problem I
had trouble with was how do you go about parsing the arguments to the macro
and what representation do you pass in? A string representation of the
parameters would make sense at first glance, but it leaves a lot of parsing
work for the user. A parse tree representation would be nice to manipulate,
but harder to understand, traverse, and would have needed different
node-types than the compiler used (mainly because the compiler nodes have a
fair amount of contextual referencing - what method am I in, etc. - that
would not have been available in the context of parsing a disembodied
expression to pass to the expander).
Both of these are non-issues in Lisp. Backquote and comma syntax provide a
nice syntactic interface, and the use of S-expressions as inputs gives a
representation that's easy to destructure, transform, and, in general, just
mess around with.
In the final analysis, I didn't have time to do macros right and so I
decided that it was better to let the matter drop. It's probably just as
well. Other languages with heavier syntax don't seem to fare too well in
the macro department - look at C, C++, Dylan since the syntactic movement
away from its Lisp roots, etc.
Who knows, I might try an implementation in Squeak sometime and see what
turns up. Other things I'd like to add - functions not attached to objects
(Why not? Smalltalk has global variables), better (i.e., more flexible)
MOP, optional arguments (I actually had some VW code that did this, but it
made heavy use of exceptions), etc. Squeak seems open enough to actually do
these things right.
Anyway, sorry to burden c.l.l readers with this.
faa
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8ed9a0$egf$1@joe.rice.edu>
In article <··················@burlma1-snr2> posted on Friday, April
28, 2000 5:52 PM, Barry Margolin <······@genuity.net> wrote:
> In article <············@joe.rice.edu>, Rahul Jain <·····@rice.edu> wrote:
>>Object models have nothing to do with this. CL has a HIGHLY developed
>>OO system. I personally don't know of a single one that has even equal
>>power and flexibilty. It's not perfect, but that's why we have the MOP.
>
> I suspect Smalltalkers would not consider our object model so highly
> developed, since CL is not objects all the way down like Smalltalk is.
> We're both certainly better than C++, though.
I know very little Smalltalk, so I really can't be authoritative when I
make comparisons to it, but it seems that what Peaker is complaining about
can be achieved quite easily in CL. Unfortunately, I'm not really sure
WHAT he proposes as the alternative...
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Duane Rettig
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <4wvlh38k5.fsf@beta.franz.com>
Barry Margolin <······@genuity.net> writes:
> In article <············@joe.rice.edu>, Rahul Jain <·····@rice.edu> wrote:
> >Object models have nothing to do with this. CL has a HIGHLY developed
> >OO system. I personally don't know of a single one that has even equal
> >power and flexibilty. It's not perfect, but that's why we have the MOP.
>
> I suspect Smalltalkers would not consider our object model so highly
> developed, since CL is not objects all the way down like Smalltalk is.
> We're both certainly better than C++, though.
One prominent Smalltalker, Alan Kay, gave a keynote at OOPSLA '97
and had some good things to say about AMOP. The tape of the talk is
circulating somewhere around Franz; perhaps I can find it and quote
precisely what he said. Or maybe someone else knows.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Daniel Barlow
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <878zxwlx9v.fsf@tninkpad.telent.net>
Duane Rettig <·····@franz.com> writes:
> One prominent Smalltalker, Alan Kay, gave a keynote at OOPSLA '97
> and had some good things to say about AMOP. The tape of the talk is
> circulating somewhere around Franz; perhaps I can find it and quote
> precisely what he said. Or maybe someone else knows.
Try http://www.cc.gatech.edu/fac/mark.guzdial/squeak/oopsla.html
I can't verify this right now (offline), but apparently it quotes Alan
Kay as saying "The Art of the Metaobject Protocol is the best book
written in computing in ten years."
-dan
From: Sashank Varma
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <sashank-3004001637130001@129.59.212.53>
In article <··············@tninkpad.telent.net>, Daniel Barlow
<···@telent.net> wrote:
[snip]
>I can't verify this right now (offline), but apparently it quotes Alan
>Kay as saying "The Art of the Metaobject Protocol is the best book
>written in computing in ten years."
[snip]
since it was published in 1991, it only has a year left before it will
be disqualified for this title!
sashank
In article <························@129.59.212.53>,
·······@vuse.vanderbilt.edu (Sashank Varma) wrote:
> >I can't verify this right now (offline), but apparently it quotes Alan
> >Kay as saying "The Art of the Metaobject Protocol is the best book
> >written in computing in ten years."
> [snip]
>
> since it was published in 1991, it only has a year left before it will
> be disqualified for this title!
No. If he said it in 1997, he meant 1987-1997 by 'ten years'.
He might think AMOP is the best book in 13 years _today_ or he
might not. That I don't know.
regards,
abe
From: Paolo Amoroso
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <KRsMOUGwBt969SP3tqMuXECB6Idc@4ax.com>
On 28 Apr 2000 20:11:38 -0700, Duane Rettig <·····@franz.com> wrote:
> One prominent Smalltalker, Alan Kay, gave a keynote at OOPSLA '97
> and had some good things to say about AMOP. The tape of the talk is
> circulating somewhere around Franz; perhaps I can find it and quote
By the way, what about taping/videotaping the keynote speeches of future
Lisp conferences sponsored by Franz? The tapes might be sold together with
the proceedings, or separately.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Jon S Anthony
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3909C8DA.7A20@synquiry.com>
Peaker wrote:
<...tortuous accounts of how to "simplify" things ...>
Let's see. This is clearly more clumsy, more complex, inherently less
efficient, and less general (capable) than the current macro facility.
An obvious loser all the way around. Yet you think it's more "elegant".
I think that speaks volumes.
> database query: (isPerson = True) & (height > 1.5m) & (age = some_age).
>
> I find it a lot more readable, too, don't you?
No.
/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
From: Tim Bradshaw
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <ey3ya605ugv.fsf@cley.com>
* 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
From: David McClain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <sgghr2erqtj126@corp.supernews.com>
Tim Bradshaw <···@cley.com> wrote in message
····················@cley.com...
> That's what fexprs were. There's a reason they went away. In 41
> years a lot of things have been tried in Lisp...
>
I keep hearing about the historical "fexprs". Can someone please explain in
a bit more detail what these things are? Or, better yet, cite some reference
with a good historical explanation. I have seen them mentioned in some of
McCarthy's papers, but I have yet to see a good description of them and why
they went away....
TIA
- DM
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <P%YN4.8$xb5.739@burlma1-snr2>
In article <··············@corp.supernews.com>,
David McClain <········@azstarnet.com> wrote:
>I keep hearing about the historical "fexprs". Can someone please explain in
>a bit more detail what these things are? Or, better yet, cite some reference
>with a good historical explanation. I have seen them mentioned in some of
>McCarthy's papers, but I have yet to see a good description of them and why
>they went away....
Fexprs were in Maclisp, and they were simply functions whose arguments were
not automatically evaluated. The function itself had to call EVAL when
necessary.
For a reference, I guess you'll have to find one of the old Maclisp
reference manuals.
--
Barry Margolin, ······@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.
Barry Margolin <······@genuity.net> writes:
> In article <··············@corp.supernews.com>,
> David McClain <········@azstarnet.com> wrote:
> >I keep hearing about the historical "fexprs". Can someone please explain in
> >a bit more detail what these things are? Or, better yet, cite some reference
> >with a good historical explanation. I have seen them mentioned in some of
> >McCarthy's papers, but I have yet to see a good description of them and why
> >they went away....
>
> Fexprs were in Maclisp, and they were simply functions whose arguments were
> not automatically evaluated. The function itself had to call EVAL when
> necessary.
>
> For a reference, I guess you'll have to find one of the old Maclisp
> reference manuals.
Or try the following paper by Kent M. Pitman, which will also explain
some of the reasons that fexprs were found to be not a good idea(tm):
Special Forms in Lisp
http://world.std.com/~pitman/Papers/Special-Forms.html
(AFAICT it also appeared in paper form in the Conference Record of the
1980 Lisp Conference held at Stanford University, August 25-27, 1980.)
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Espen Vestre
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <w63do6hf15.fsf@wallace.nextel.no>
Barry Margolin <······@genuity.net> writes:
> Fexprs were in Maclisp, and they were simply functions whose arguments were
> not automatically evaluated. The function itself had to call EVAL when
> necessary.
The same as nlambdas in Interlisp?
--
(espen)
From: Tim Bradshaw
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <ey3hfcnttj2.fsf@cley.com>
* David McClain wrote:
>>
> I keep hearing about the historical "fexprs". Can someone please explain in
> a bit more detail what these things are? Or, better yet, cite some reference
> with a good historical explanation. I have seen them mentioned in some of
> McCarthy's papers, but I have yet to see a good description of them and why
> they went away....
fexprs were functions whose arguments were not evaluated. The
function itself would call EVAL to get the argument evaluated. I
think they were in things like Maclisp, though I came across them in
Cambridge Lisp and Standard Lisp, which had both spread (lots of
parameters) and nospread (one parameter which works like &rest)
versions of fexprs and normal functions (as well as macros!).
I think the worst problem with fexprs is that you have to know all
about how the compiler works to use them. For instance if Common Lisp
had an operator DEFF for defining fexprs, you might think that this:
(deff foo (x)
(eval x))
is equivalent to
(defun foo (x)
x)
But it isn't at all, because you've lost the environment:
(let ((y 1))
(foo y))
is (almost certainly) an error for the fexpr, but not for the normal
function.
I don't know about maclisp, but the lisps I used which had fexprs were
dynamically scoped so this kind of thing would work. Actually I think
it probably wouldn't work in the compiler unless you did something to
tell it that y was fluid (which was the same as CL `special', normal
bindings in the compiler were dynamic extent but lexical scope, while
in the interpreter they were like CL `special').
In order to have something like this work for CL, I think you'd need
to have access to environment objects and generally expose a whole
bunch more internals than you'd like to.
--tim
From: Sashank Varma
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <sashank-2704001245020001@129.59.212.53>
In article <··············@corp.supernews.com>, "David McClain"
<········@azstarnet.com> wrote:
[snip]
>I keep hearing about the historical "fexprs". Can someone please explain in
>a bit more detail what these things are? Or, better yet, cite some reference
>with a good historical explanation.
[snip]
i ran across them in franzlisp. as i recall, there were lambdas,
fexprs, lexprs, and nlambdas. one of the latter two forms would
bundle all the arguments in a single list parameter, kinda like
writing (defun foo (&rest lis) ...). not that you'll take my
word for it, but it's a good thing all of this complexity went
away. i think kent pitman might have a paper on the downfall of
these older constructs somewhere on his web page.
sashank
From: Christopher Browne
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <HCLN4.22095$VR.521958@news5.giganews.com>
Centuries ago, Nostradamus foresaw a time when Peaker would say:
>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,
>of course])
An Introduction to Lisp Macros
<http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html> provides some
examples.
The main point of the exercise is that of controlling the evaluation
of arguments.
(defmacro Iff (Test Then &optional Else)
"A replacement for IF, takes 2 or 3 arguments. If the first evaluates to
non-NIL, evaluate and return the second. Otherwise evaluate and return
the third (which defaults to NIL)"
`(cond
(,Test ,Then)
(t ,Else)) )
You couldn't do this using a function, because passing the THEN and
ELSE values to a function would mean that both would get evaluated
before being passed in.
If the plan is to create some sort of specialized control structure,
whether:
a) A nifty variation on "IF", as shown above, or
b) A control structure that is given some data structure, "opens" it,
loops on it, and then "closes it,"
this is useful.
So, for instance, you have:
(with-open-file (s p)
(do ((l (read-line s) (read-line s nil 'eof)))
((eq l 'eof) "Reached end of file.")
(format t "~&*** ~A~%" l)))
This macro does three things:
- Opens the file
- Repeats the body on each line in the file
- Closes the file
--> Guarantees that the file is closed, even if an error is signalled.
Another MAJOR point to the exercise is that of transforming another
language, namely the language of your problem, into Lisp. By
transforming it into Lisp, the optimizations available to the Lisp
compiler may be used on your language without the need for a
specialized optimizer.
>> 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.
That may remove the need for some of the more trivial uses of macros,
but not the more interesting uses, I'd think...
--
(1) Sigs are preceded by the "sigdashes" line, ie "\n-- \n" (dash-dash-space).
(2) Sigs contain at least the name and address of the sender in the first line.
(3) Sigs are at most four lines and at most eighty characters per line.
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Barry Margolin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <r9ZN4.9$xb5.749@burlma1-snr2>
In article <·····················@news5.giganews.com>,
Christopher Browne <········@hex.net> wrote:
>The main point of the exercise is that of controlling the evaluation
>of arguments.
>
>(defmacro Iff (Test Then &optional Else)
> "A replacement for IF, takes 2 or 3 arguments. If the first evaluates to
> non-NIL, evaluate and return the second. Otherwise evaluate and return
> the third (which defaults to NIL)"
> `(cond
> (,Test ,Then)
> (t ,Else)) )
>
>You couldn't do this using a function, because passing the THEN and
>ELSE values to a function would mean that both would get evaluated
>before being passed in.
Not if you wrapped them in LAMBDA expressions:
(defun if-function (test then &optional else)
(cond (test (funcall then))
(else (funcall else))))
(if-function (> x y)
#'(lambda () (format t "~&X is larger than Y.~%"))
#'(lambda () (format t "~&X is less than or equal to Y.~%")))
This is essentially what Smalltalk does; it spells #'(lambda () ...) as
[...].
In fact, we could do this in Lisp if we wanted -- it would be simple to
make [ a reader-macro that expands into the appropriate lambda expression.
>So, for instance, you have:
> (with-open-file (s p)
> (do ((l (read-line s) (read-line s nil 'eof)))
> ((eq l 'eof) "Reached end of file.")
> (format t "~&*** ~A~%" l)))
>
>This macro does three things:
>- Opens the file
>- Repeats the body on each line in the file
>- Closes the file
>--> Guarantees that the file is closed, even if an error is signalled.
It should probably be pointed out that Scheme uses functional analogues to
with-open-file: call-with-input-file and call-with-output-file. So the
above would be written:
(call-with-input-file p
(lambda (s)
(do ...)))
call-with-*-file provides the same guarantees as with-open-file.
As I've said in other messages, in many cases this is just a stylistic
choice that Lisp programmers have collectively made.
--
Barry Margolin, ······@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.
From: Harley Davis
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390a196f$0$228@newsreader.alink.net>
Christopher Browne <········@news.hex.net> wrote in message
··························@news5.giganews.com...
> The main point of the exercise is that of controlling the evaluation
> of arguments.
>
> (defmacro Iff (Test Then &optional Else)
> "A replacement for IF, takes 2 or 3 arguments. If the first evaluates to
> non-NIL, evaluate and return the second. Otherwise evaluate and return
> the third (which defaults to NIL)"
> `(cond
> (,Test ,Then)
> (t ,Else)) )
>
> You couldn't do this using a function, because passing the THEN and
> ELSE values to a function would mean that both would get evaluated
> before being passed in.
Of course, the syntax is a little funny, but there is always the hoary trick
of:
(defun if-fn (pred truefn falsefn)
(cond (pred (funcall truefn))
(t (funcall falsefn))))
(if-fn (condition-true-p arg1)
(lambda () (format t "It's true!"))
(lambda () (format t "It's false!")))
-- Harley
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8ed8tj$e5h$1@joe.rice.edu>
In article <··············@newsreader.alink.net> posted on
Friday, April 28, 2000 6:11 PM, "Harley Davis"
> Of course, the syntax is a little funny, but there is always the hoary trick
> of:
>
> (defun if-fn (pred truefn falsefn)
> (cond (pred (funcall truefn))
> (t (funcall falsefn))))
>
> (if-fn (condition-true-p arg1)
> (lambda () (format t "It's true!"))
> (lambda () (format t "It's false!")))
>
unfortunately, that relies on COND being defined, which could
be used in place of IF-FN directly. The point is that a function
takes in parameters and returns a result. A macro takes in some
symbols and returns code transformed into a form that is defined
in terms of the language features existing before that macro was
defined.
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Harley Davis
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <390e1944$0$224@newsreader.alink.net>
Rahul Jain <·····@rice.edu> wrote in message
·················@joe.rice.edu...
> In article <··············@newsreader.alink.net> posted on
> Friday, April 28, 2000 6:11 PM, "Harley Davis"
> > Of course, the syntax is a little funny, but there is always the hoary
trick
> > of:
> >
> > (defun if-fn (pred truefn falsefn)
> > (cond (pred (funcall truefn))
> > (t (funcall falsefn))))
> >
> > (if-fn (condition-true-p arg1)
> > (lambda () (format t "It's true!"))
> > (lambda () (format t "It's false!")))
> >
>
> unfortunately, that relies on COND being defined, which could
> be used in place of IF-FN directly. The point is that a function
> takes in parameters and returns a result. A macro takes in some
> symbols and returns code transformed into a form that is defined
> in terms of the language features existing before that macro was
> defined.
In what sense could 'cond' be used in the place of 'if-fn'? 'cond' is not a
function. Note that the original example used 'cond' in its expansion of an
'if' macro.
-- Harley
From: Rahul Jain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8eliml$3j6$1@joe.rice.edu>
In article <··············@newsreader.alink.net> posted on
Monday, May 1, 2000 7:00 PM, "Harley Davis" <·············@nospam.museprime.com> wrote:
Note that the original example used 'cond' in its expansion of an
> 'if' macro.
exactly my point...
just use a cond in the first place :)
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
From: Harley Davis
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <39121b6b$0$224@newsreader.alink.net>
Rahul Jain <·····@rice.edu> wrote in message
·················@joe.rice.edu...
> In article <··············@newsreader.alink.net> posted on
> Monday, May 1, 2000 7:00 PM, "Harley Davis"
<·············@nospam.museprime.com> wrote:
> Note that the original example used 'cond' in its expansion of an
> > 'if' macro.
>
> exactly my point...
> just use a cond in the first place :)
Except that the whole point of this subthread was how to write a function
that does what cond does.
-- Harley
From: Erik Naggum
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3165817993224866@naggum.no>
* Peaker <·········@yahoo.com>
| 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.
where do you draw the line between the two? I suspect you have an
artificial view of which is which.
| 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.
right. that's the beauty of the Lisp syntax.
| 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).
yes. isn't it great? language design paradigms come in many
flavors that you can actually choose from. Common Lisp has chosen
some of them. you seem to be unhappy with the paradigms that those
who like Common Lisp favor the most.
| 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.
you want examples of language extension in language X that aren't
possible in language Y? really. this is _ridiculous_ on its face.
| I would suggest a small change to the macro system, that in my
| oppinion, would make it more elegant: ...
really? well, it's been tried. it was a bad idea.
first grok, then suggest. that's general advice.
#:Erik
From: Kent M Pitman
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <sfwn1lzob36.fsf@world.std.com>
In article <·················@makif.omer.k12.il>,
Peaker <······@makif.omer.k12.il> wrote:
> 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.
It's unlikely you'll define a language with no deficiency, therefore the
only question is whether you can cover up the deficiencies that are there
or not.
Java is a case in point. I think the key problem with Java is its lack
of macros means you're stuck forever after with every complicated wart of
syntax in the underlying language. Moreover, it's unlikely that any single
syntax suffices to provide appropriate focus in all circumstances. Some of
what macros do is to move the "solved problems" out of view and leave the
programmer to view the "hard part" that has been left in more plain view.
In Java, you can never move the easy or redundant or well-understood parts
out of the way, so you can never control focus enough to highlight or zoom
in on a specific aspect you want to really see clearly.
From: David McClain
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <shgpp2p4d58176@corp.supernews.com>
Kent M Pitman <······@world.std.com> wrote in message
····················@world.std.com...
> In article <·················@makif.omer.k12.il>,
> Peaker <······@makif.omer.k12.il> wrote:
>
> > 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.
>
> It's unlikely you'll define a language with no deficiency, therefore the
> only question is whether you can cover up the deficiencies that are there
> or not.
>
> Java is a case in point. I think the key problem with Java is its lack
> of macros means you're stuck forever after with every complicated wart of
> syntax in the underlying language. Moreover, it's unlikely that any
single
> syntax suffices to provide appropriate focus in all circumstances. Some
of
> what macros do is to move the "solved problems" out of view and leave the
> programmer to view the "hard part" that has been left in more plain view.
> In Java, you can never move the easy or redundant or well-understood parts
> out of the way, so you can never control focus enough to highlight or zoom
> in on a specific aspect you want to really see clearly.
In retrospect this is quite obvious, but I have never heard it stated so
well!
- DM
From: tom
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <pb8k8h372ta.fsf@aimnet.com>
Kent M Pitman <······@world.std.com> writes:
> It's unlikely you'll define a language with no deficiency, therefore the
> only question is whether you can cover up the deficiencies that are there
> or not.
>
> Java is a case in point. I think the key problem with Java is its lack
> of macros means you're stuck forever after with every complicated wart of
> syntax in the underlying language. Moreover, it's unlikely that any single
> syntax suffices to provide appropriate focus in all circumstances. Some of
> what macros do is to move the "solved problems" out of view and leave the
> programmer to view the "hard part" that has been left in more plain view.
> In Java, you can never move the easy or redundant or well-understood parts
> out of the way, so you can never control focus enough to highlight or zoom
> in on a specific aspect you want to really see clearly.
I agree with your analysis on the important function of macros as a
kind of "safety valve". Java's choice may well have been motivated by
the experiences with large commercial development projects, where
macro abstraction (with all its semantic pitfalls) may cause, or be
perceived to cause, more problems than the time it saves in terms of
code sharing and reduced tedium.
But there is nothing prohibiting anybody from implementing macros
for Java. More and more people, in fact, already use macro
preprocessors with Java in the form of literate programming systems.
You can also use m4 or other standard preprocessors, and there even
some Java-specific ones. Syntax-aware, hygienic macros for Java
would, of course, be really nice. Any volunteers? :-)
Tom.
From: William Deakin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3919427A.D8B72E5E@pindar.com>
tom wrote:
> But there is nothing prohibiting anybody from implementing macros
> for Java...Syntax-aware, hygienic macros for Java
> would, of course, be really nice. Any volunteers? :-)
Why reinvent lisp or a lisp-like language in java?
Best Regards,
:) will
From: Martin Cracauer
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8fc00h$2hla$1@counter.bik-gmbh.de>
>tom wrote:
>> But there is nothing prohibiting anybody from implementing macros
>> for Java...Syntax-aware, hygienic macros for Java
>> would, of course, be really nice. Any volunteers? :-)
The most interesting macros shadow definitions like defun and require
code walkers to rebuild new calls to the original function. At least
that is what makes normally written code be reusable in very special
circumstances.
That is very hard to do for a language with Algol-like syntax.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: Lieven Marchand
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <3919ad15$0$11455@bru5-newsr1.be.uu.net>
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> The most interesting macros shadow definitions like defun and require
> code walkers to rebuild new calls to the original function. At least
> that is what makes normally written code be reusable in very special
> circumstances.
How well does this approach scale? For instance, the SERIES package
does this quite extensively. However, it uses CL:DEFUN quite heavily
internally, so if you try to use a second package that also wants to
shadow DEFUN you're going to run into trouble.
There have been references floating around to a concept of compiler
environments that has people were working on during the ANSI
standardisation but that didn't make it because it couldn't be brought
to a satisfactory form. I've never seen a detailed proposal but it
seems like a hard problem.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
From: Martin Cracauer
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8ff1e9$mq$1@counter.bik-gmbh.de>
Lieven Marchand <···@bewoner.dma.be> writes:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>> The most interesting macros shadow definitions like defun and require
>> code walkers to rebuild new calls to the original function. At least
>> that is what makes normally written code be reusable in very special
>> circumstances.
>How well does this approach scale? For instance, the SERIES package
>does this quite extensively. However, it uses CL:DEFUN quite heavily
>internally, so if you try to use a second package that also wants to
>shadow DEFUN you're going to run into trouble.
I share your concerns. I think this is (one of the things) why Scheme
got call/cc required by the standard, since this provides a macroless
way to implement things like Screamer, while ensuring that systems
that are put together but require different environments fail in a
clean way. Thinking along the same line, Java's "passive" reflection
does 90% of what I use macros in other languages for. I might guess
that I also feel GLS design decisions here. Killing the need for
macros by giving people the power to solve many problems by direct
language support is a good thing.
In Common Lisp, I rarely use the advanced iteration macros or most of
the tricks in the "On Lisp" line, so I guess I'm just a little macro
ignorant. I just want my program to be able to find out certain
things about its source code.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: John Clonts
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8ff5e6$rit$1@nnrp1.deja.com>
In article <···········@counter.bik-gmbh.de>,
········@counter.bik-gmbh.de (Martin Cracauer) wrote:
> Lieven Marchand <···@bewoner.dma.be> writes:
>
> >········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
> >> The most interesting macros shadow definitions like defun and
require
> >> code walkers to rebuild new calls to the original function. At
least
> >> that is what makes normally written code be reusable in very
special
> >> circumstances.
>
> >How well does this approach scale? For instance, the SERIES package
> >does this quite extensively. However, it uses CL:DEFUN quite heavily
> >internally, so if you try to use a second package that also wants to
> >shadow DEFUN you're going to run into trouble.
>
> I share your concerns. I think this is (one of the things) why Scheme
> got call/cc required by the standard, since this provides a macroless
> way to implement things like Screamer, while ensuring that systems
> that are put together but require different environments fail in a
> clean way. Thinking along the same line, Java's "passive" reflection
> does 90% of what I use macros in other languages for. I might guess
> that I also feel GLS design decisions here. Killing the need for
> macros by giving people the power to solve many problems by direct
> language support is a good thing.
Pardon my interruption, but could you give a tiny example of the type of
thing you would do in Java that you would otherwise do with macros?
And, what does GLS stand for?
Thanks,
John
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Sashank Varma
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <sashank-1205001009370001@129.59.212.53>
In article <············@nnrp1.deja.com>, John Clonts <······@my-deja.com>
wrote:
[snip]
>And, what does GLS stand for?
>
>Thanks,
>John
[snip]
1. Guru of Lisp, now at Sun.
2. Gls Loves Sun.
3. Guy L. Steele, jr.
sashank
From: Martin Cracauer
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8foe4g$234o$1@counter.bik-gmbh.de>
John Clonts <······@my-deja.com> writes:
>In article <···········@counter.bik-gmbh.de>,
> ········@counter.bik-gmbh.de (Martin Cracauer) wrote:
>> Lieven Marchand <···@bewoner.dma.be> writes:
>>
>> >········@counter.bik-gmbh.de (Martin Cracauer) writes:
>>
>> >> The most interesting macros shadow definitions like defun and
>require
>> >> code walkers to rebuild new calls to the original function. At
>least
>> >> that is what makes normally written code be reusable in very
>special
>> >> circumstances.
>>
>> >How well does this approach scale? For instance, the SERIES package
>> >does this quite extensively. However, it uses CL:DEFUN quite heavily
>> >internally, so if you try to use a second package that also wants to
>> >shadow DEFUN you're going to run into trouble.
>>
>> I share your concerns. I think this is (one of the things) why Scheme
>> got call/cc required by the standard, since this provides a macroless
>> way to implement things like Screamer, while ensuring that systems
>> that are put together but require different environments fail in a
>> clean way. Thinking along the same line, Java's "passive" reflection
>> does 90% of what I use macros in other languages for. I might guess
>> that I also feel GLS design decisions here. Killing the need for
>> macros by giving people the power to solve many problems by direct
>> language support is a good thing.
>Pardon my interruption, but could you give a tiny example of the type of
>thing you would do in Java that you would otherwise do with macros?
Iterate over fields of structs. In C, I don't have access to the
field's names or types, just the location.
Begin able to write a loop that iterates over the source code names of
a field (and their types) enables be to do:
- Storing/loading bejond simple memory copy
- Print a human-readable representation of the struct's contents
(possibly with other things it points to) for debugging purposes
- Write generic code where user's input (variable names in ASCII
files) automatically sets a field in a struct of the same name
- Put statically allocated const objects in the source code and
connect them to "working" instances of the struct without writing
code for each such struct (i.e. I use this for range checking).
Or in other words: I don't like that a C compiler "takes away" my
source code from my program. The source code I write down contains
more useful information than a C compiler lets through until runtime.
The names and types of variables are useful information in many cases
and in C I had to write them down (or generate them with a completely
seperate program or use very ugly macros) multiple times.
Again, I don't say Java is better than Lisp. I just say that C and
most other static languages are horrible in their requirements for
macros to do the things I listed above. Java is a lot better and does
much of what I use Lisp macros for.
The sad thing is that most other static language share these
restrictions with C. Objective-C showed real vision here.
>And, what does GLS stand for?
Guy L. Steele, inventor of Scheme, a driving force behind Common Lisp
standardization, now at Sun working on Java language features.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: Jeff Dalton
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <x21z37by2l.fsf@todday.aiai.ed.ac.uk>
········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
> Lieven Marchand <···@bewoner.dma.be> writes:
>
> >········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
> >> The most interesting macros shadow definitions like defun and require
> >> code walkers to rebuild new calls to the original function. At least
> >> that is what makes normally written code be reusable in very special
> >> circumstances.
>
> >How well does this approach scale? For instance, the SERIES package
> >does this quite extensively. However, it uses CL:DEFUN quite heavily
> >internally, so if you try to use a second package that also wants to
> >shadow DEFUN you're going to run into trouble.
>
> I share your concerns. I think this is (one of the things) why Scheme
> got call/cc required by the standard, since this provides a macroless
> way to implement things like Screamer, while ensuring that systems
> that are put together but require different environments fail in a
> clean way.
You make it sound like someone came along and said "hey, we'd better
require call/cc in the standard, because it provides a macroless way
to implement things like Screamer ..."
No. Call/cc is in the standard because it's been part of Scheme from
the beginning (though it originally was called CATCH and was a special
form) and hasn't been controversial enought to be kept out of the
revised reports. The standard was based on the revised report.
> Thinking along the same line, Java's "passive" reflection
> does 90% of what I use macros in other languages for.
Well, it does zero percent of what I used macros in Lisp for.
> ... Killing the need for
> macros by giving people the power to solve many problems by direct
> language support is a good thing.
Any language that tried to do that would become incredably bloated and
still fail to kill the need for macros.
From: Martin Cracauer
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8fobrm$20lp$1@counter.bik-gmbh.de>
Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>>
>> Lieven Marchand <···@bewoner.dma.be> writes:
>>
>> >········@counter.bik-gmbh.de (Martin Cracauer) writes:
>>
>> >> The most interesting macros shadow definitions like defun and require
>> >> code walkers to rebuild new calls to the original function. At least
>> >> that is what makes normally written code be reusable in very special
>> >> circumstances.
>>
>> >How well does this approach scale? For instance, the SERIES package
>> >does this quite extensively. However, it uses CL:DEFUN quite heavily
>> >internally, so if you try to use a second package that also wants to
>> >shadow DEFUN you're going to run into trouble.
>>
>> I share your concerns. I think this is (one of the things) why Scheme
>> got call/cc required by the standard, since this provides a macroless
>> way to implement things like Screamer, while ensuring that systems
>> that are put together but require different environments fail in a
>> clean way.
>You make it sound like someone came along and said "hey, we'd better
>require call/cc in the standard, because it provides a macroless way
>to implement things like Screamer ..."
Must be my suboptimal english.
What I meant is: When looking a macro packages like Screamer, it
becomes more clear why having call/cc in a language is a godd thing.
It make *every* piece of of Scheme code usable in nondeterministic
contexts, whereas the macros used in Common Lisp only quarantee the
usability of a *subset* of Common Lisp.
I am of course aware of the drawbacks of requiring call/cc, but for
some applications, it is in fact like the original poster of this
thread implied: sometimes Common Lisp macros can be used as a
suboptimal replacement for what can be done better with direct
language support.
>No. Call/cc is in the standard because it's been part of Scheme from
>the beginning (though it originally was called CATCH and was a special
>form) and hasn't been controversial enought to be kept out of the
>revised reports. The standard was based on the revised report.
>> Thinking along the same line, Java's "passive" reflection
>> does 90% of what I use macros in other languages for.
>Well, it does zero percent of what I used macros in Lisp for.
I have no doubt that I use macros for very different things than other
programmers. See my other posts.
>> ... Killing the need for
>> macros by giving people the power to solve many problems by direct
>> language support is a good thing.
>Any language that tried to do that would become incredably bloated and
>still fail to kill the need for macros.
Sure. But using macros to get what call/cc provides doesn't really
reach the latter's elegance and completeness and "passive" reflection
as in java is rather leightweight compared to its usefullness (for
me).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: Jeff Dalton
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <x2em72jupe.fsf@todday.aiai.ed.ac.uk>
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
>
> >You make it sound like someone came along and said "hey, we'd better
> >require call/cc in the standard, because it provides a macroless way
> >to implement things like Screamer ..."
>
> Must be my suboptimal english.
>
> What I meant is: When looking a macro packages like Screamer, it
> becomes more clear why having call/cc in a language is a godd thing.
> It make *every* piece of of Scheme code usable in nondeterministic
> contexts, whereas the macros used in Common Lisp only quarantee the
> usability of a *subset* of Common Lisp.
Screamer is an example of a language being built on top of Lisp.
So what if there are parts of Lisp that remain "outside"?
Screamer does not at all make it clear why having call/cc in a language
is a good thing. Indeed, there's a pretty good case that having
call/cc in a language is a bad thing, because it's way too powerful
and because it's better to have the call/cc applications that you
actually want provided directly. (Sound familiar?)
> I am of course aware of the drawbacks of requiring call/cc, but for
> some applications, it is in fact like the original poster of this
> thread implied: sometimes Common Lisp macros can be used as a
> suboptimal replacement for what can be done better with direct
> language support.
The functionality of Screamer is not supposted directly in Scheme.
Call/cc is a powerful, low-level mechanism. It is used for many
things that are not supported directly but have instead to be built
on top of call/cc, sometimes in very complicated ways.
> >> ... Killing the need for
> >> macros by giving people the power to solve many problems by direct
> >> language support is a good thing.
>
> >Any language that tried to do that would become incredably bloated and
> >still fail to kill the need for macros.
>
> Sure.
So what are you arguing about?
> But using macros to get what call/cc provides doesn't really
> reach the latter's elegance and completeness and "passive" reflection
> as in java is rather leightweight compared to its usefullness (for
> me).
So what?
From: David Hanley
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <391C2CF5.C95B60E6@ncgr.org>
Martin Cracauer wrote:
> Thinking along the same line, Java's "passive" reflection
> does 90% of what I use macros in other languages for.
I really don't agree with this! It doesn't add syntax to the
language, in any way, shape, or form, which is what I usually
use macros for,
> I might guess
> that I also feel GLS design decisions here. Killing the need for
> macros by giving people the power to solve many problems by direct
> language support is a good thing.
But it will never work. There's too much inherent power in macros. For
Example, I was writing several switch-esque constructs, except that
you had to see if your "switching" string had any of a number of prefixes.
The naive way to do it is:
(cond
((has-prefix string "foo") ....)
((has-prefix string "bar") ....))
But I loathe this sort of redundancy, so:
(defmacro string-prefix-case( string &rest clauses )
"A macro which defines a new structure which apes the case function,
but determines if each clause's string is a prefix which matches the 'case'
string."
`(cond ,@(mapcar #'(lambda(clause)`((is-prefix ,(car clause)
,string),@(rest clause))) clauses)
(T (format t "No matching prefix for:~d~%" ,string))
))
so I could then write
(string-prefix-case string
("foo" ...)
("bar ...))
Another example from the same code. I set fields based on the contests
of a text file I am reading. Well, many fields should be set only once.
rather than always test, i wrote ssetf:
(defmacro ssetf( to from )
"Set a field, warning if it is already set"
`(progn
(when ,to
(format t "resetting ~d to ~d~%" (quote ,to) ,from ))
(setf ,to ,from)))
Both of these were easy to write, and clarify source code greatly.
dave
From: Martin Cracauer
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8fod8k$22a1$1@counter.bik-gmbh.de>
David Hanley <···@ncgr.org> writes:
>Martin Cracauer wrote:
>> Thinking along the same line, Java's "passive" reflection
>> does 90% of what I use macros in other languages for.
>I really don't agree with this! It doesn't add syntax to the
>language, in any way, shape, or form, which is what I usually
>use macros for,
>> I might guess
>> that I also feel GLS design decisions here. Killing the need for
>> macros by giving people the power to solve many problems by direct
>> language support is a good thing.
>But it will never work. There's too much inherent power in macros. For
>Example, I was writing several switch-esque constructs, except that
>you had to see if your "switching" string had any of a number of prefixes.
>The naive way to do it is:
>(cond
> ((has-prefix string "foo") ....)
> ((has-prefix string "bar") ....))
>But I loathe this sort of redundancy, so:
>(defmacro string-prefix-case( string &rest clauses )
> "A macro which defines a new structure which apes the case function,
>but determines if each clause's string is a prefix which matches the 'case'
>string."
> `(cond ,@(mapcar #'(lambda(clause)`((is-prefix ,(car clause)
>,string),@(rest clause))) clauses)
> (T (format t "No matching prefix for:~d~%" ,string))
> ))
>so I could then write
>(string-prefix-case string
> ("foo" ...)
> ("bar ...))
The difference between you and me is that I rarely use such
constructs.
Of course, I want to reduce redundancy as well, but I accept local
redundance (i.e. where the repetive patterns fit on one screenfull or
are local to one normal-sized function). I concentrate on reducing it
in more global contexts. Most of these macros (I'd say "On Lisp"-
style) fall into the "very local" category.
I think that these macros with local effect reduce the readabilty for
other people for not enough gain. Many of Dick Gabriel's writings are
real eye-openeners here (available in book form as "Patterns of
Software" - great reading for those not following JOOP).
>Another example from the same code. I set fields based on the contests
>of a text file I am reading. Well, many fields should be set only once.
>rather than always test, i wrote ssetf:
>(defmacro ssetf( to from )
> "Set a field, warning if it is already set"
> `(progn
> (when ,to
> (format t "resetting ~d to ~d~%" (quote ,to) ,from ))
> (setf ,to ,from)))
>Both of these were easy to write, and clarify source code greatly.
Sorry, I don't like this macro, nil may be a perfect thing to set a
field to. I have no doubt we have very different needs for macros.
BTW, to ensure that for a given struct no field is set twice without
writing or generating code for each field, I could use reflection. I
can allocate a second struct with the same field names that reflect a
"already set" status. The connection between the fields in the real
struct and the indicator struct would have to written down in C
field-by-field, but in Java (and Lisp) I can get the field names and
iterate over them without macros.
I don't say that Java is perfect. Lisp does many things I reall want
that Java can't.
But most classic Lisp macros (the small one people regard as little
utilities) are just not my taste, as they either attack problems I
don't see as real problems (I prefer to be verbose as long as it
doesn't "spread" expressions of single things around the source code)
or - as your later macro - has surpriving requirements for their
arguments.
Things like Screamer or adding memoization to functions in a general
way are what I like Lisp macros for.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: David Hanley
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <39201AD4.BABA441E@ncgr.org>
Martin Cracauer wrote:
> David Hanley <···@ncgr.org> writes:
>
> >Martin Cracauer wrote:
>
> >> Thinking along the same line, Java's "passive" reflection
> >> does 90% of what I use macros in other languages for.
>
> >I really don't agree with this! It doesn't add syntax to the
> >language, in any way, shape, or form, which is what I usually
> >use macros for,
>
> >> I might guess
> >> that I also feel GLS design decisions here. Killing the need for
> >> macros by giving people the power to solve many problems by direct
> >> language support is a good thing.
>
> >But it will never work. There's too much inherent power in macros. For
> >Example, I was writing several switch-esque constructs, except that
> >you had to see if your "switching" string had any of a number of prefixes.
> >The naive way to do it is:
>
> >(cond
> > ((has-prefix string "foo") ....)
> > ((has-prefix string "bar") ....))
>
> >But I loathe this sort of redundancy, so:
>
> >(defmacro string-prefix-case( string &rest clauses )
> > "A macro which defines a new structure which apes the case function,
> >but determines if each clause's string is a prefix which matches the 'case'
> >string."
> > `(cond ,@(mapcar #'(lambda(clause)`((is-prefix ,(car clause)
> >,string),@(rest clause))) clauses)
> > (T (format t "No matching prefix for:~d~%" ,string))
> > ))
>
> >so I could then write
>
> >(string-prefix-case string
> > ("foo" ...)
> > ("bar ...))
>
> The difference between you and me is that I rarely use such
> constructs.
>
> Of course, I want to reduce redundancy as well, but I accept local
> redundance (i.e. where the repetive patterns fit on one screenfull or
> are local to one normal-sized function). I concentrate on reducing it
> in more global contexts. Most of these macros (I'd say "On Lisp"-
> style) fall into the "very local" category.
>
> I think that these macros with local effect reduce the readabilty for
> other people for not enough gain. Many of Dick Gabriel's writings are
> real eye-openeners here (available in book form as "Patterns of
> Software" - great reading for those not following JOOP).
I disagree vehemently that these sort of local macros hurt readability.
It makes it clear that there's one sort of thing being done here--a
switch based on the prefix of a given string. The macro is pretty
simple and self-explanatory, IMO. I don't see how a big (cond..)
with similar clauses is more readable.
>
>
> >Another example from the same code. I set fields based on the contests
> >of a text file I am reading. Well, many fields should be set only once.
> >rather than always test, i wrote ssetf:
>
> >(defmacro ssetf( to from )
> > "Set a field, warning if it is already set"
> > `(progn
> > (when ,to
> > (format t "resetting ~d to ~d~%" (quote ,to) ,from ))
> > (setf ,to ,from)))
>
> >Both of these were easy to write, and clarify source code greatly.
>
> Sorry, I don't like this macro, nil may be a perfect thing to set a
> field to. I have no doubt we have very different needs for macros.
>
> BTW, to ensure that for a given struct no field is set twice without
> writing or generating code for each field, I could use reflection. I
> can allocate a second struct with the same field names that reflect a
> "already set" status. The connection between the fields in the real
> struct and the indicator struct would have to written down in C
> field-by-field, but in Java (and Lisp) I can get the field names and
> iterate over them without macros.
Yes, but that's going to be slower, more difficult, and have more
bookkeeping garbage for the programmer using it. it's not going
to *look* like a normal java set, unless you insert a lot of
code into your class. I don't see that it's an improvement,
though admittedly, the above macro is tailored for my usage
in this specific app.
dave
From: David Bakhash
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m3u2g6z6wb.fsf@alum.mit.edu>
William Deakin <·····@pindar.com> writes:
> tom wrote:
>
> > But there is nothing prohibiting anybody from implementing macros
> > for Java...Syntax-aware, hygienic macros for Java
> > would, of course, be really nice. Any volunteers? :-)
>
> Why reinvent lisp or a lisp-like language in java?
well, despite the fact that I tend away from Java, Java has many
unique features that Lisp does not. Having macros, as a language
feature, is something that is certainly part of Lisp, but not limited
to Lisp. Any language can choose to add macros, if the designer had
wanted them. Dylan is a good example.
One thing about Lisp though, is that it's macros are especially
powerful. The fact that the program is interpreted as data, and each
sexp is data, either a list or an atom, and because the language has
many list-manipulation facilities, it's more than just a language
which provides macros.
Basically, what I'm saying is that while any language can provide
macros, Lisp is specially suited. If the next rev of Java had macros,
they'd be extremely hard to write, and that's just bad, considering
that macros are already very hard to write, even in Lisp.
dave
From: William Deakin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <391A79B8.E87D5A26@pindar.com>
David Bakhash wrote:
> well, despite the fact that I tend away from Java, Java has many
> unique features that Lisp does not.
As I am still unconvinced by the `Joy of Java' but then again this is from
a position of ignorance, could you please expand on this?.
> Having macros, as a language feature, is something that is certainly
> part of Lisp, but not limited
> to Lisp.
Agreed. This is not what I was trying to say.
[...elided some excellent points about Lisp macros...]
> If the next rev of Java had macros, they'd be extremely hard to write,
> and that's just bad, considering
> that macros are already very hard to write...
Yup. Although (in my blissful ignorance) I'm wouldn't say `very hard'
merely `hard'
;) will
From: Frank A. Adrian
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <HELS4.1115$cZ3.55289@news.uswest.net>
William Deakin <·····@pindar.com> wrote in message
······················@pindar.com...
> David Bakhash wrote:
>
> > well, despite the fact that I tend away from Java, Java has many
> > unique features that Lisp does not.
>
> As I am still unconvinced by the `Joy of Java' but then again this is from
> a position of ignorance, could you please expand on this?.
>
> > Having macros, as a language feature, is something that is certainly
> > part of Lisp, but not limited
> > to Lisp.
>
> Agreed. This is not what I was trying to say.
>
> [...elided some excellent points about Lisp macros...]
>
> > If the next rev of Java had macros, they'd be extremely hard to write,
> > and that's just bad, considering
> > that macros are already very hard to write...
>
> Yup. Although (in my blissful ignorance) I'm wouldn't say `very hard'
> merely `hard'
>
> ;) will
>
Look at Dylan's macro language for an example how blecherous grafting real
macros onto an algolish language looks. And they had people who knew how to
do it right! Along with a language that had a fairly open idea about how
identifiers and operators looked to make it easier I shudder to think what
the folks at Sun would do in their hamhanded attempt. I vote for very hard.
faa
From: William Deakin
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <391BCFF9.A21B9D08@pindar.com>
Frank Adrian wrote:
> >> ...considering that macros are already very hard to write...
> >
> > Yup. Although (in my blissful ignorance) I'm wouldn't say `very hard'
> > merely `hard'
>
> I vote for very hard.
You misunderstand me then. In response to the statment that `...macros are
already very hard to write...' (and I took this to be macros in lisp) I quibbled
and said `macros [in lisp] are merely hard'. And as such have passed no
judgement on the difficulty (or not) of `algolish' macro writing. Which I am
sure *is* very hard.
Hey ho,
:) will
From: Dorai Sitaram
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <8fh26a$ikq$1@news.gte.com>
>> >> ...considering that macros are already very hard to write...
>> >
>> > Yup. Although (in my blissful ignorance) I'm wouldn't say `very hard'
>> > merely `hard'
>>
>> I vote for very hard.
>
>You misunderstand me then. In response to the statment that `...macros are
>already very hard to write...' (and I took this to be macros in lisp) I quibbled
>and said `macros [in lisp] are merely hard'. And as such have passed no
>judgement on the difficulty (or not) of `algolish' macro writing. Which I am
>sure *is* very hard.
But why are macros even "merely hard"? Textual
abstraction is arguably easier than procedural
abstraction (which I guess is the tacit
"zero-level" for hardness), because (a) it has less
conceptual machinery (environment) associated w/ it &
(b) all humans learn to do it in natlang already as
small children.
Indeed I would hazard that it's because macros are so
conceptually easy that beginners tend use them
where procs would've been more appropriate.
I guess there is a slight difficulty introduced
because of Lisp's "eval it twice but not really"
strategy for macros, but it still doesn't seem to
outweigh the _conceptual_ easiness for the audience
where this mechanical difficulty could be
make-or-break, i.e., beginners. Of course, hard
macros are hard to write, but beginners seem to accept
that this will be so in Lisp as elsewhere.
Just some observations over the yrs,
--d
From: Philip Lijnzaad
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <u7r9b7251u.fsf_-_@o2-3.ebi.ac.uk>
Dorai> But why are macros even "merely hard"? Textual
Dorai> abstraction is arguably easier than procedural
Dorai> abstraction
not sure I agree here: I think our brains get in the way, in the sense that
it's often easy to confuse the quoting with the quoted. I found this problem
particularly hard in the macro language m4 (which I think tends to use more
levels of quotation).
Dorai> Indeed I would hazard that it's because macros are so
Dorai> conceptually easy that beginners tend use them
Dorai> where procs would've been more appropriate.
Not in my experience, but maybe this is because introductory text books shy
away from them. Would it be better to begin teaching Lisp by starting with
DEFMACRO rather than DEFUN? I don't think so (if only because of the
non-directly-obvious issue of hygiene and the consequent need for GENSYM),
but it might be worth trying nonetheless.
Philip
--
/dev/brain: character special (53/0)
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <u2g3kecw.fsf@alum.mit.edu>
····@goldshoe.gte.com (Dorai Sitaram) writes:
> >> >> ...considering that macros are already very hard to write...
> >> >
> >> > Yup. Although (in my blissful ignorance) I'm wouldn't say `very hard'
> >> > merely `hard'
> >>
> >> I vote for very hard.
> >
> >You misunderstand me then. In response to the statment that `...macros are
> >already very hard to write...' (and I took this to be macros in lisp) I quibbled
> >and said `macros [in lisp] are merely hard'. And as such have passed no
> >judgement on the difficulty (or not) of `algolish' macro writing. Which I am
> >sure *is* very hard.
>
> But why are macros even "merely hard"? Textual
> abstraction is arguably easier than procedural
> abstraction (which I guess is the tacit
> "zero-level" for hardness), because (a) it has less
> conceptual machinery (environment) associated w/ it &
> (b) all humans learn to do it in natlang already as
> small children.
Because textual abstraction is not referrentially transparent, another
thing all humans learn in natlang as small children.
~jrm
From: David Bakhash
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m34s83oa8f.fsf@alum.mit.edu>
William Deakin <·····@pindar.com> writes:
> David Bakhash wrote:
>
> > well, despite the fact that I tend away from Java, Java has many
> > unique features that Lisp does not.
>
> As I am still unconvinced by the `Joy of Java' but then again this is from
> a position of ignorance, could you please expand on this?.
Well, there's object serialization, very extensive and complete
libraries, an interesting portability model, RMI (remote method
invocation, like Corba, but purely done in Java), JDBC, a built-in
security model. There's much more, but I think that people agree that
Java does have some useful features, some of which are language
features and others library features. Lisp lacks several of the
things that Java has, in my opinion.
> > If the next rev of Java had macros, they'd be extremely hard to write,
> > and that's just bad, considering
> > that macros are already very hard to write...
>
> Yup. Although (in my blissful ignorance) I'm wouldn't say `very hard'
> merely `hard'
For whatever reason, programmers don't easily catch on to macros.
macros involve several things that throw people off. You have to
understand when things are eval'd, the differenece between
compile-time and run-time, backquote (usually), gensym-related issues,
etc. Also, you have to know when to use a macro over a function, and
of course, you have to be able to write the guts of the macro, and
manipulate the arguments, and hopefully in a hygenic way. It's hard
enough sometimes for beginners to figure out why you can't write #'if
in Lisp without defmacro.
dave
From: Jon S Anthony
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <391C69FD.7FA8@synquiry.com>
David Bakhash wrote:
>
> William Deakin <·····@pindar.com> writes:
>
> > David Bakhash wrote:
> >
> > > well, despite the fact that I tend away from Java, Java has many
> > > unique features that Lisp does not.
> >
> > As I am still unconvinced by the `Joy of Java' but then again this is from
> > a position of ignorance, could you please expand on this?.
> Well, there's object serialization,
In many ways this sort of thing is not as nice as what Lisp gives with
it's readable output. We've used the Java version here and it has
caused problems due to brittleness and its opaqueness.
> very extensive and complete libraries
This is also rather overrated as they are just as extensively
convoluted and/or simply broken.
> an interesting portability model,
P-code rediscovered. Also we've found that it isn't very "portable".
The only way to be sure your app will actually run when delivered is
to send the JRE you used (which, of course, has obvious negatives to
it).
> RMI (remote method invocation, like Corba, but purely done in Java)
Which makes it closed and problematic at the advantage of a slightly
higher level of out of the box expressiveness. Of course, since RMI
is supposed to be layered on IIOP, it will become a CORBA based
protocol which could (if done right) allow interoperation with other
distributed applications.
> JDBC
ODBC, bfd...
>, a built-in security model.
Granted.
> There's much more,
Not really. Actually nothing of significance comes to mind. Threads?
But then the thread model is low level and broken. Also Java isn't
standardized, probably never will be, and Sun seems more than willing
to change it "randomly" in non backward compatible ways.
> For whatever reason, programmers don't easily catch on to macros.
Some programmers. Others catch on quite easily.
> macros involve several things that throw people off. You have to
> understand when things are eval'd, the differenece between
People who don't know or can't grasp the basics of various translation
technologies (compilers, interpreters, transformers, etc.) may have a
harder time.
/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
From: Joe Marshall
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <r9b7earj.fsf@alum.mit.edu>
David Bakhash <·····@alum.mit.edu> writes:
> Well, there's object serialization,
Print readably, make-load-form,
> very extensive and complete libraries,
Unlike LISP, which only provides....
> an interesting portability model,
`Interesting' is right. `Working' or `reliable' would be nicer.
> RMI (remote method
> invocation, like Corba, but purely done in Java), JDBC,
I haven't used these things, so I won't comment.
> a built-in security model.
It has a rudimentary and crude security model, but I don't see it as
something missing from Lisp: I've never wanted to run untrusted lisp
applications off the net.
> There's much more, but I think that people agree that Java does have
> some useful features, some of which are language features and others
> library features.
If Java has any advantage, it is that it is an incremental step away
from C and C++ toward something reasonable. I really don't see any
language `features' that it provides that are fundamentally impossible
or difficult in Lisp. I don't even see anything that hasn't been done
before in Lisp.
> Lisp lacks several of the things that Java has, in my opinion.
Perhaps a particular lisp out of the box lacks some of the things Java
supplies, but in the project I'm working on, which uses both Lisp and
Java, it is painfully obvious which one has more features.
~jrm
From: David Bakhash
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m3snvmmvtn.fsf@alum.mit.edu>
well, I can't believe I'm even appearing to stand behind Java, but the
sad truth is that Java has some of the features that made Lisp nice
(it's OO, is GC'd, portable). The trade-off for Java was:
1) take the most important features from successful programming
paradigms.
2) make it look enough like C++ so that you can more easily tap into
the existing C++ programming market.
Though it's hindsight, Sun's execution was right on. Their plan
worked, by and large (and even the name was catchy). In fact, I
wouldn't be surprised if more people knew how to program Java nowadays
than people who have only _heard_ of Lisp. How good Java really is --
now that's another story. But there are merits in what Java stives to
be, and they should not be overlooked, even though we are a bunch of
Lisp evangelists.
Honestly, my opinion is that RMI is useless, serialization is
overrated (I have also been successful with simply defining
make-load-form methods, though it's work, and it's slower to read in
the data) and as for security? well, the only applets I really care
about are VNC and Yahoo! Instant Messenger. (this actually reminds me
of another Java thing, which is its windowing system: AWT/Swing.) But
as useless as these things are to me, I have seen some of them being
used in interesting, useful ways, and they cannot be ignored. As the
word suggests, it's ignorant to ignore them.
What about incorporating some of the features into Lisp...I don't
think I'd want most of them. Maybe I'd want the Genera-style MP::
stuff, and maybe ACL's socket stuff. I'd like it if CL had a good
regexp library implemented in Lisp, that was open to the public (the
ones out there are very slow, if you havn't noticed, and ACL's, while
faster, just stinks for other reasons, like the regexp syntax, the
fact that they didn't build a special reader macro for regexps, and
they don't (as far as I can remember) allow for `?' in a regexp).
Basically, anything that Lisp lacks (for me) tends to be "library"
oriented. I am more than satisfied with the language design, and have
figured out the package system to where I can use it. What this means
is that Lisp doesn't need to be changed, but simply augmented with
some libraries (that are not part of CL, but by a broader definition
are, just like all those extra Java classes). For someone like me,
it'll take a lot less work, and less surgical work, to repair Lisp
than something like Java.
That's it for me. I'm sick of defending Java.
dave
From: Tom Breton
Subject: Re: Are macros really a neccessity, or a coverup of language deficiencies?
Date:
Message-ID: <m3n1luqou3.fsf@world.std.com>
David Bakhash <·····@alum.mit.edu> writes:
> William Deakin <·····@pindar.com> writes:
>
> > David Bakhash wrote:
> >
> > > well, despite the fact that I tend away from Java, Java has many
> > > unique features that Lisp does not.
> >
> > As I am still unconvinced by the `Joy of Java' but then again this is from
> > a position of ignorance, could you please expand on this?.
>
> Well, there's object serialization, very extensive and complete
> libraries, an interesting portability model, RMI (remote method
> invocation, like Corba, but purely done in Java), JDBC, a built-in
> security model. There's much more, but I think that people agree that
> Java does have some useful features, some of which are language
> features and others library features. Lisp lacks several of the
> things that Java has, in my opinion.
For an interesting attempt to have the best of both, see Kawa, which
is a Scheme built on top of the JVM. I couldn't say how well it works
in practice. http://www.gnu.org/software/kawa/kawa_8.html
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.
David Bakhash <·····@alum.mit.edu> writes:
> ... considering
> that macros are already very hard to write, even in Lisp.
I don't think they are, actually.
From time to time, people come to c.l.l and spend a lot of effort
trying to discredit Lisp macros as wrong in principle or too difficult
in practice. Sometimes even those who seem to like Lisp macros concede
an awful lot to the critics. Why?
In article <·················@todday.aiai.ed.ac.uk>,
Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
>David Bakhash <·····@alum.mit.edu> writes:
>
>> ... considering
>> that macros are already very hard to write, even in Lisp.
>
>I don't think they are, actually.
>
>From time to time, people come to c.l.l and spend a lot of effort
>trying to discredit Lisp macros as wrong in principle or too difficult
>in practice. Sometimes even those who seem to like Lisp macros concede
>an awful lot to the critics. Why?
I think the main reason they may be "hard to write" is because people find
it difficult to conceptualize the different way they're used, e.g. being
executed at compile time rather than run time. For instance, how many
times have we seen people post macros that try to reference variables that
won't be bound until runtime?
--
Barry Margolin, ······@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.
Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > ... considering
> > that macros are already very hard to write, even in Lisp.
>
> I don't think they are, actually.
>
> From time to time, people come to c.l.l and spend a lot of effort
> trying to discredit Lisp macros as wrong in principle or too difficult
> in practice. Sometimes even those who seem to like Lisp macros concede
> an awful lot to the critics. Why?
I don't find them hard to write actually. I am not writing
intepreters, or creating the support for call/cc like Graham is in
OnLisp, but I have found that in practice, macros are only slightly
more difficult to write than functions once one has the basics down.
Reading OnLisp and reading other people's macros should give you those
basics pretty quickly. Looking back at the time I have spent learning
Lisp (not that I'm done learning it) I don't recall macros as ever
being anything of a burden or obstacle, but they quiet often were a
source of inspiration and awe.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of
oasis making you look twice. -- Mos Def and Talib Kweli
Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > ... considering
> > that macros are already very hard to write, even in Lisp.
>
> I don't think they are, actually.
>
> From time to time, people come to c.l.l and spend a lot of effort
> trying to discredit Lisp macros as wrong in principle or too difficult
> in practice. Sometimes even those who seem to like Lisp macros concede
> an awful lot to the critics. Why?
Well, I'm a total newbie to Lisp, and I find macros difficult to grasp.
Although I can see the use and incredibly language shortcuts one can
make with them, I find them difficult and awkward to build in a sensible
way. I guess it just takes a lot of practice, but for now I'm mainly
sticking to functions and only occasionally building a simple macro.
--
�yvind Gr�nnesby
"Wow, I had knowledge!"
--Buffy
I think I've come up with another reason why some people may find macros
hard to grasp. I think people are more comfortable writing programs that
"do things". Imperative programming is like giving directions, writing
recipes: first do this, then do that, etc.
Macros, on the other hand, usually don't "do" anything. They accept an
input form and just return a transformation of this. While this isn't
inherently complex, it's not the way many programmers are used to thinking.
I imagine that people who are more comfortable with the functional
programming style would find macros less of a problem. They're used to
just computing return values rather than the do-this-then-that style of
imperative programming.
--
Barry Margolin, ······@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.
yes. this is what I meant when I said that macros were hard.
actually, I am an example of a person who really understood macros
from the beginning, just be reading some elisp code where I saw some
implemented, and understood what was going on, and then read the
sections in graham's books years later, only to get a bit more
practice.
but i've also shown people how to use macros, and I know from
experience that while some people understand them right away, that
vast majority of programmers (especially coming from the C/Java
world), get tripped up. Also, optimizing macros *are* without
question hard to write. Of course, parts of the "macro system" are
functions that are called to manipulate input expressions. LOOP would
be a good example, not that LOOP is a single defmacro, of course.
dave
Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > ... considering
> > that macros are already very hard to write, even in Lisp.
>
> I don't think they are, actually.
Like any other function, it depends on exactly what the functionality
has to be.
Simple macros are easy to write. Get a bit less simple and you need
to surround the backquote with (let ((name (gensym))) ...), but it's
still not real work.
If the result form has to contain something complex - say, a let
statement whose bindings the macro controls - then of course you've
got to do the work to build those clauses. No free lunch is possible.
All of which basically applies to functions, too. The extra work with
macros is seeing what exactly it produced, but that's when you use
macroexpand and macroexpand-1, an extra step but not a difficult one.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.
okay.
I think this thread should die right about now. At least, if no one
has anything cool to say (other than the "macros are hard, IMHO" and
such). I think the moral of the story for people to realize is that
while macros *shouldn't* be hard, they *are* for various reasons, and
thinking otherwise would probably make for a very frustrated teacher,
and a very discouraged student.
Lastly, if you consider some of the macros in Graham's 2nd book (the
advanced CL book), then you will that non-hygenic macros can be used
in a way that is extremely powerful and complex (note macrologies that
implement nondeterminism). Of course, macros that just save people
typing are nice, but that's not all macros are used for. I think that
saying macros are easy is like saying that Lisp is easy, and I don't
think that it is, though it happens to be easy-ER than other languages
in my opinion. I still pity the folks who use C++ in situations where
they don't have to.
dave
Jeff Dalton wrote:
>
> David Bakhash <·····@alum.mit.edu> writes:
>
> > macros are already very hard to write, even in Lisp.
>
> I don't think they are, actually.
While I don't have a problem with macros on the basis that they
translate source rather than "do" something, I sometimes find it a
little annoying to have to recompile functions after a change to a
macro.
Robert
From: Tim Bradshaw
Subject: HTML Generation (was Re: Are macros really a neccessity, or a coverup of language deficiencies?)
Date:
Message-ID: <ey38zxa5cg5.fsf@cley.com>
I couldn't find a suitable article in this thread to which to follow
up, but I think the attached code is something I'd find really hard to
write without macros. It's nothing special -- I know of at least one
other (considerably more powerful) similar thing as well as several
other variants that I've written over the last few years, so there are
probably 10s or hundreds of things that do this out there. Indeed
this stuff is so easy to do in CL that I tend to rewrite it on demand
rather than stress out about some library functionality. This one was
written last week in a hotel room while recovering from food
poisoning, and took about an hour or two + some random fiddling
(notably the ESC functionality) since then. There are some commented
examples, but basically what it lets you do is intersperse literal
HTML (or *ML really) in an obvious Lispy syntax, with actual Lisp:
(with-html-output (s)
(:html
(:head (:title (format s ...)))
(:body (:h1 (format s ...))
(dotimes (i 1000)
(htm
((:hr :noshade))
(:h2 ...) ...)))))
Anyway, I'd really like to see this done without macros!
--tim
--cut--
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; -*- Mode: Lisp -*- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; File - htout.lisp
;; Description - trivial HTML output
;; Author - Tim Bradshaw (tfb at KINGSTON)
;; Created On - Fri May 12 05:51:11 2000
;; Last Modified On - Tue May 16 10:01:14 2000
;; Last Modified By - Tim Bradshaw (tfb at lostwithiel)
;; Update Count - 31
;; Status - Unknown
;;
;; $Id$
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;; Trivial HTML output.
;;;
;;; This is fragile, but the right idea.
;;;
;;; the trick of distinguishing HTML elt names by beign keywords might
;;; want to be generalised somewhat (but it's a reasonable approach I
;;; think). It could obviously be infinitely generalised to XML but I
;;; don't want to bother with that.
;;;
;;; the listification of tags with attributes to get evaluation is a bit
;;; fragile -- ((:a href "foo") ...) breaks -- do we care?
;;;
;;; it might be cool to define compiler macros for some things to inline
;;; more code?
;;;
;;; I'm not sure about all these shorthands.
;;;
(defpackage :htout
(:use :cl)
(:export #:with-html-output ;basic macro, and shorthands:
#:htm ;reenter html mode
#:fmt ;format in html
#:esc ;escaped string
#:lfd ;linefeed in html
#:escape-string ;implement ESC, useful in itself
#:define-empty-tags)) ;define a tag to have no content
(in-package :htout)
(defmacro with-html-output ((var &optional stream) &body html)
`(let ((,var ,(or stream var)))
(macrolet ((htm (&body forms)
`(with-html-output (,',var) ,@forms))
(fmt (format-string &rest args)
`(format ,',var ,format-string ,@args))
(lfd (&optional (n 1))
(if (= n 1)
`(terpri ,',var)
`(loop repeat ,n
do
(terpri ,',var))))
(esc (string &optional map)
(let ((mname (make-symbol "MAP")))
`(let ((,mname ,map))
(write-sequence
(if ,mname
(escape-string ,string ,mname)
(escape-string ,string))
,',var)))))
,@(mapcar #'(lambda (f) (htmlify-form f var))
html))))
(defvar *empty-table*
(make-hash-table))
(defun empty-tag-p (tag)
(values (gethash tag *empty-table*)))
(defmacro define-empty-tags (&rest tags)
`(loop for tag in ',tags
do (setf (gethash tag *empty-table*) tag)
finally (return ',tags)))
(define-empty-tags :br :hr)
(defgeneric htmlify-form (form stream-var))
(defmethod htmlify-form ((form cons) stream-var)
(let ((elt (first form)))
(if (or (keywordp elt)
(and (consp elt)
(keywordp (first elt))))
(let ((tag (if (consp elt) (first elt) elt))
(eltexpr (if (consp elt) `(list ,@elt) `(quote ,elt))))
(if (empty-tag-p tag)
(progn
(when (rest form)
(warn "Ignoring body of empty tag ~S" tag))
`(emit-tag ,eltexpr ,stream-var :type :empty))
`(progn
(emit-tag ,eltexpr ,stream-var :type :open)
,@(mapcar #'(lambda (e) (htmlify-form e stream-var))
(rest form))
(emit-tag ',tag ,stream-var :type :close))))
form)))
(defmethod htmlify-form ((form symbol) stream-var)
(if (keywordp form)
`(emit-tag ',form ,stream-var :type :empty)
`(princ ,form ,stream-var)))
(defmethod htmlify-form ((form string) stream-var)
`(write-sequence ,form ,stream-var))
(defgeneric emit-tag (tag stream &key type))
(defmethod emit-tag ((tag symbol) stream &key (type ':open))
(format stream (ecase type
((:open :empty) "<~A>")
((:close) "</~A>"))
(symbol-name tag)))
(defmethod emit-tag ((tag list) stream &key (type ':open))
(ecase type
((:open :empty)
(format stream "<~A" (symbol-name (first tag)))
(loop for tail = (rest tag) then (cddr tail)
while tail
do
(if (second tail)
(format stream " ~A='~A'"
(symbol-name (first tail))
(second tail))
(format stream " ~A" (symbol-name (first tail)))))
(format stream ">"))
((:close)
(format stream "</~A>" (symbol-name (first tag))))))
(defvar *html-escape-map*
'((#\< . "<")
(#\> . ">")
(#\& . "&")))
(defun escape-string (string &optional (map *html-escape-map*))
;; escape the characters in MAP in STRING. This is an easy way of
;; doing it but I haven't thought abut making it efficient.
(declare (type string string))
(if (not (find-if #'(lambda (c)
(assoc c map))
string))
string
(with-output-to-string (o)
(loop for prev = 0 then (1+ found)
for found = (position-if #'(lambda (c)
(assoc c map))
string
:start prev)
while found
do
(write-sequence string o :start prev :end found)
(write-sequence (cdr (assoc (char string found) map)) o)
finally
(write-sequence string o :start prev :end (length string))))))
#||
(defun count-numbers (n w &optional (s *standard-output*))
(with-html-output (s)
(:html
(:head (:title
(fmt "Numbers from zero below ~R" n)))
(:body
(:h1 (fmt "Numbers from zero below ~R" n))
;; Forms beginning with non-keyword symbols are code to be evaluated.
(lfd)
(:p "Table border width "
(princ w s))
;; isolated keywords are empty tags.
:br
(lfd)
;; empty tags with attributes need this slightly crufty syntax,
;; and also need to be defined as empty.
((:hr :noshade))
(:center
;; the values of atttributes are evaluated (in fact the whole
;; attribute list is, but attribute names asre keywords).
((:table :border w
:width "90%")
(:tr
((:th :align :left) "English")
((:th :align :right) "Arabic")
((:th :align :right) "Roman"))
;; you can leap into Lisp...
(dotimes (i n)
(let ((c (if (evenp i) "blue" "white")))
;; ... and then back into HTML: the local HTML macro is shorthand
;; for WITH-HTML-OUTPUT to the same stream.
(htm
((:tr :bgcolor c)
((:td :align :left)
(fmt "~R" i))
((:td :align :right)
(fmt "~D" i))
((:td :align :right)
(if (zerop i)
(fmt "")
(fmt ···@R" i))))
(lfd))))))
((:hr :noshade))))))
(defun create-blank-page (s title)
(with-html-output (s)
(:html
(:head
(:title (esc title))
(lfd))
(:body
(:h1 (esc title))
(lfd)
"<!-- Body here -->"
(lfd)))))
||#