From: Peter Seibel
Subject: Style question -- destructuring in macro lambda lists
Date:
Message-ID: <m3d6c7daio.fsf@javamonkey.com>
Suppose for some reason I want to write a macro DOTIMES/2D that turns:
(dotimes/2d ((x 4) (y 5))
(print (list x y)))
into:
(dotimes (x 4)
(dotimes (y 5)
(print (list x y))))
Leaving aside the dubious utility of such a macro, here are three
different versions that use destructuring in the lambda list to
varying degrees. Which do you prefer? I think the third is preferable,
despite being slightly longer, since it does better argument checking
than either of the other two. Other opinions?
(defmacro dotimes/2d (bindings &body body)
`(dotimes ,(first bindings)
(dotimes ,(second bindings)
,@body)))
(defmacro dotimes/2d ((binding1 binding2) &body body)
`(dotimes ,binding1
(dotimes ,binding2
,@body)))
(defmacro dotimes/2d (((var1 iters1) (var2 iters2)) &body body)
`(dotimes (,var1 ,iters1)
(dotimes (,var2 ,iters2)
,@body)))
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> Leaving aside the dubious utility of such a macro, here are three
> different versions that use destructuring in the lambda list to
> varying degrees. Which do you prefer? I think the third is preferable,
> despite being slightly longer, since it does better argument checking
> than either of the other two. Other opinions?
[snip]
> (defmacro dotimes/2d (((var1 iters1) (var2 iters2)) &body body)
> `(dotimes (,var1 ,iters1)
> (dotimes (,var2 ,iters2)
> ,@body)))
Definately. In addition to providing better arg checking (which means
more comprehensible error messages that refer to the code the user
wrote, not the code the macro expanded into), you also get a useful
arglist. If you type "(dotimes/2d"<space>, and see
"(bindings &body body)", you didn't learn much.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Peter Seibel <·····@javamonkey.com> wrote:
> (defmacro dotimes/2d (((var1 iters1) (var2 iters2)) &body body)
> `(dotimes (,var1 ,iters1)
> (dotimes (,var2 ,iters2)
> ,@body)))
I find this one the best as well: it's clear, and the argument-list
(if the environment supports such things is informative. For the sake
of completeness and arglist informativeness i'd probably write it:
(defmacro dotimes/2d (((outer outer-list) (inner inner-list) expr) &body body)
`(dotimes (,outer ,outer-list ,expr)
(dotimes (,inner ,inner-list)
,@body)))
I try to avoid foo1 foo2 style argument names unless there is a good
reason for it, since they make my eyes itch. ;-)
Cheers,
-- Nikodemus
From: james anderson
Subject: Re: Style question -- destructuring in macro lambda lists
Date:
Message-ID: <3FA83947.55786E51@setf.de>
Peter Seibel wrote:
>
> Suppose for some reason I want to write a macro DOTIMES/2D that turns:
>
> (dotimes/2d ((x 4) (y 5))
> (print (list x y)))
>
> into:
>
> (dotimes (x 4)
> (dotimes (y 5)
> (print (list x y))))
>
> Leaving aside the dubious utility of such a macro, here are three
> different versions that use destructuring in the lambda list to
> varying degrees. Which do you prefer? I think the third is preferable,
> despite being slightly longer, since it does better argument checking
> than either of the other two. Other opinions?
>
> ...
where the structure of the respective subform does not change, the macro
syntax should reflect that structure. on the other hand, i would actually
prefer a variation:
(defmacro dotimes* (((variable range) &rest others) &body body)
`(dotimes (,variable ,range)
,@(if others
`((dotimes* ,others ,@body))
body)))
...
From: Peter Seibel
Subject: Re: Style question -- destructuring in macro lambda lists
Date:
Message-ID: <m38ymvd710.fsf@javamonkey.com>
james anderson <··············@setf.de> writes:
> Peter Seibel wrote:
> >
> > Suppose for some reason I want to write a macro DOTIMES/2D that turns:
> >
> > (dotimes/2d ((x 4) (y 5))
> > (print (list x y)))
> >
> > into:
> >
> > (dotimes (x 4)
> > (dotimes (y 5)
> > (print (list x y))))
> >
> > Leaving aside the dubious utility of such a macro, here are three
> > different versions that use destructuring in the lambda list to
> > varying degrees. Which do you prefer? I think the third is preferable,
> > despite being slightly longer, since it does better argument checking
> > than either of the other two. Other opinions?
> >
> > ...
>
> where the structure of the respective subform does not change, the macro
> syntax should reflect that structure. on the other hand, i would actually
> prefer a variation:
>
> (defmacro dotimes* (((variable range) &rest others) &body body)
> `(dotimes (,variable ,range)
> ,@(if others
> `((dotimes* ,others ,@body))
> body)))
Yup. Me too. I was asking about this because I'm writing about
destructuring lambda lists[1] for my book--so far I haven't introduced my
readers to recursive macros so I don't want to explode their heads
with too much at once.
-Peter
P.S. Is anyone going to get *really* upset if I call them
"destructuring parameter lists" in the intrest of being slightly more
descriptive and not triggering people's lambda allergies?
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
> P.S. Is anyone going to get *really* upset if I call them
> "destructuring parameter lists" in the intrest of being slightly more
> descriptive and not triggering people's lambda allergies?
I would just make sure you put the word "macro" somewhere close-by or
people might expect they can do this anywhere there's a parameter
list, even outside of macros.
Peter Seibel <·····@javamonkey.com> writes:
> P.S. Is anyone going to get *really* upset if I call them
> "destructuring parameter lists" in the intrest of being slightly more
> descriptive and not triggering people's lambda allergies?
Do you think people with lambda-allergies are going to make if very
far with Lisp or your book or even look at something with "Lisp" in
the title? I personally don't care if you call them lambda lists or
arglists (or even parameter lists, though "arglist" would be the more
usual term). But I don't understand trying to wave your hands and
pretend there aren't lambdas underneath; after swallowing parentheses,
how bad could one little greek letter be? :-) Seems almost Dylan-like
in the impulse...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Peter Seibel
Subject: Re: Style question -- destructuring in macro lambda lists
Date:
Message-ID: <m34qxibqkv.fsf@javamonkey.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > P.S. Is anyone going to get *really* upset if I call them
> > "destructuring parameter lists" in the intrest of being slightly more
> > descriptive and not triggering people's lambda allergies?
>
> Do you think people with lambda-allergies are going to make if very
> far with Lisp or your book or even look at something with "Lisp" in
> the title? I personally don't care if you call them lambda lists or
> arglists (or even parameter lists, though "arglist" would be the
> more usual term). But I don't understand trying to wave your hands
> and pretend there aren't lambdas underneath; after swallowing
> parentheses, how bad could one little greek letter be? :-) Seems
> almost Dylan-like in the impulse...
Heh. It's a balancing act. Basically the deal is at the point--given
the current organization of the book--where I'm talking about lambda
lists, I haven't really had to talk about LAMBDA at all, except
briefly as the funny bit of syntax you use to create anonymous
functions.
There are, as james anderson points out in another post in this
thread, historical and underlying conceputal reasons why lambda lists
are called that but I'm not ready to explain the history or conceptual
basis at that point so calling them lambda lists would just seem weird
to a reader who hasn't yet become one with the lambda nature.
In other words calling them "parameter lists" will be--I believe--more
clear to my readers. And as long as folks here don't say, "Paramater
lists? ... what the f*ck are you talking about? ... Oh, I get it you
mean *lambda* lists!" when my readers--should I be so lucky--show up
here with further questions, that seems like a reasonable trade off.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: james anderson
Subject: Re: Style question -- destructuring in macro lambda lists
Date:
Message-ID: <3FA8C545.61F47BD2@setf.de>
Peter Seibel wrote:
>
>
>
> P.S. Is anyone going to get *really* upset if I call them
> "destructuring parameter lists" in the intrest of being slightly more
> descriptive and not triggering people's lambda allergies?
>
so long as you are not tempted to call them "destructuring argument lists".
still, where is that going to leave you when you then have to explain what a
"by order of arguments parameter list" is?
and, there is an also aspect of the term "lambda" which motivates and unifies
the treatment of parameter specifications which is lost by just calling them
parameter lists.
...
From: Peter Seibel
Subject: Re: Style question -- destructuring in macro lambda lists
Date:
Message-ID: <m3znfaabsy.fsf@javamonkey.com>
james anderson <··············@setf.de> writes:
> Peter Seibel wrote:
> >
> >
> >
> > P.S. Is anyone going to get *really* upset if I call them
> > "destructuring parameter lists" in the intrest of being slightly more
> > descriptive and not triggering people's lambda allergies?
> >
>
> so long as you are not tempted to call them "destructuring argument lists".
Nope. Not tempted at all. I've been trying to be quite precise in
using "argument" to refer to the value passed, and "parameter" to the
variable that will be bound to the value. Thus when you write a DEFUN
or DEFMACRO the list after the name is the list of parameters or
"parameter list".
> still, where is that going to leave you when you then have to
> explain what a "by order of arguments parameter list" is?
Well, that's going to come--if at all--quite a bit later in the book
so I'll have some time to build up more terminological foundations. Or
something.
>
> and, there is an also aspect of the term "lambda" which motivates and unifies
> the treatment of parameter specifications which is lost by just calling them
> parameter lists.
Yup. But unless I'm willing to explain all of that historical and
conceptual background, LAMBDA is just another random word, and one
that I know happens to give certain folks who I'm trying to reach an
immediate case of the heebie-jeebies. So I need to ease them into it
later.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: james anderson
Subject: Re: Style question -- destructuring in macro lambda lists
Date:
Message-ID: <3FA95B01.DB3C01F4@setf.de>
Peter Seibel wrote:
>
> ...
> > and, there is an also aspect of the term "lambda" which motivates and unifies
> > the treatment of parameter specifications which is lost by just calling them
> > parameter lists.
>>
> Yup. But unless I'm willing to explain all of that historical and
> conceptual background, LAMBDA is just another random word, and one
> that I know happens to give certain folks who I'm trying to reach an
> immediate case of the heebie-jeebies. So I need to ease them into it
> later.
>
just as long as you've included a lesson in smelling-salt adminstration before
they find out about this:
http://www.lispworks.com/reference/HyperSpec/Body/03_d.htm
...