To the 'crazy-gone' people which have finally overblown my last thread [
[ LISP - an excercise for experts? ] i'd like to say:
Be friedly and choose civility.
Now the first results from a LISP novice.
for you to remeber:
> now, i found something interesting about macros here:
> http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
>
> Page 213
>
> (defmacro abbrev (short long)
> `(dfmacro ,short (&rest args)
> `(,',long ,@args)))
>
> with this, you can give unconsistent naming an end.
>
> eg defun & defmacro
>
> (abbrev df defun)
> (abbrev dm defmacro)
>
> now my problem.
>
> i don't like the syntax. And now i try to change it. People say, its
> possible with LISP, its easy with LISP.
note: i've changed the name of the macro from 'abbrev' to 'alias'
;;; ------------------------------------------------------------
;;; The Challenge of Nested Macros
;;; ------------------------------------------------------------
(set-syntax-from-char #\[ #\,)
(set-syntax-from-char #\] #\Space)
;;; ------------------------------------------------------------
;;; this enables the following writing-style, which clarifies
;;; optically the level of the macro-variables.
;;; [s1-a] [s1-b] = ,symbol = evaluate in first pass
;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
(defmacro alias (short long)
`(defmacro [short] (&rest args)
`( [ '[long] [@args] ] )))
;;; simple test code:
(alias df defun)
(df alias-test (x y z) (* x y z ) )
(alias-test 2 3 5)
;;; As ] is only whitespace, u can move them around as you like.
;;; this is a little bit dangerous. Keep in mind that:
;;; `( ['[long]] [@args] ) ==
;;; `( ['[long] [@args] ]) ==
;;; `( ,',long ,@args )
;;;
;;; I imagine the backquote '`' as a gun, which shots over lines
;;; and the 'ball' destroys one level of [].
;;; what happens in the above test-code:
;;;
;;; (defmacro alias (short long) ; call: (alias df defun)
;;; `(defmacro [short] (&rest args)
;;; `( [ '[long] [@args] ] ) ))
;;;
;;; 1st shot:
;;; (defmacro df (&rest args)
;;; `( '[long] [@args] ) )
;;;
;;; 2nd shot:
;;; ( defun (x y z) (* x y z) ) ; args: (x y z) (* x y z)
;;;
;;; ------------------------------------------------------------
;;; Tested with Allegro.
;;; Should run on any conformant CL.
;;; ------------------------------------------------------------
;;; ilias - 2002-09-02 - #V0.2
;;; ------------------------------------------------------------
any questions / corrections?
lets discuss!
On Mon, Sep 02, 2002 at 07:35:45AM +0300, ilias wrote:
> ;;; ------------------------------------------------------------
> ;;; The Challenge of Nested Macros
> ;;; ------------------------------------------------------------
> (set-syntax-from-char #\[ #\,)
> (set-syntax-from-char #\] #\Space)
> ;;; ------------------------------------------------------------
>
> ;;; this enables the following writing-style, which clarifies
> ;;; optically the level of the macro-variables.
> ;;; [s1-a] [s1-b] = ,symbol = evaluate in first pass
> ;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
>
> (defmacro alias (short long)
> `(defmacro [short] (&rest args)
> `( [ '[long] [@args] ] )))
>
[...]
>
> any questions / corrections?
>
> lets discuss!
Well, what I dislike about this is the usage of the ] characters. As
you said, they can be dangerous, and I think you tripped yourself up
here. [ '[long] [@args] ] seems to indicate that both LONG and ARGS are
coming from the same level, when in fact they aren't. ['[long]] [@args]
seems to indicate what you wanted better. But I don't find this a great
advantage because it is, so to speak, a misnomer. The , operator is
supposed to act on only one s-expression, but a syntax such as [ ... ]
would indicate that it operates on a list of s-expressions. Defining ]
as a Space gives it a "comment-like" characteristic, but comments are
supposed to give information, not mislead (and not be superfluous, one
would hope).
Not to mention the troubles this will cause when used in conjunction
with the SQL reader syntax of the UncommonSQL package; which also uses
[]s. That is why I think most library packages don't use fancy
reader-macro syntax---they don't want to pre-empt the user or conflict
with other libraries. (Obviously there are exceptions to this, where
you specifically obtain the library for the syntax it provides).
I rarely write macros-defining-macros and when I do, I generally
consider it worth my while to devote extra thought to it; most certainly
enough to handle parsing ,',. Whereas in an UncommonSQL-using program I
will often use the SQL syntax, where it saves time and offers a great
deal of additional clarity (to someone already familiar with SQL anyway).
It's fun to experiment with the reader, but overuse/abuse of it in
actual programs can lead to difficult to maintain code; particularly if
involving new developers or new libraries. There are better places to
extend the language than the first-level syntax.
This is all just my opinion, anyway. YMMV.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Mon, Sep 02, 2002 at 07:35:45AM +0300, ilias wrote:
>
>>;;; ------------------------------------------------------------
>>;;; The Challenge of Nested Macros
>>;;; ------------------------------------------------------------
>>(set-syntax-from-char #\[ #\,)
>>(set-syntax-from-char #\] #\Space)
>>;;; ------------------------------------------------------------
>>
>>;;; this enables the following writing-style, which clarifies
>>;;; optically the level of the macro-variables.
>>;;; [s1-a] [s1-b] = ,symbol = evaluate in first pass
>>;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
>>
>>(defmacro alias (short long)
>> `(defmacro [short] (&rest args)
>> `( [ '[long] [@args] ] )))
>>
>
> [...]
>
>>any questions / corrections?
>>
>>lets discuss!
>
>
> Well, what I dislike about this is the usage of the ] characters. As
> you said, they can be dangerous, and I think you tripped yourself up
> here. [ '[long] [@args] ] seems to indicate that both LONG and ARGS are
> coming from the same level, when in fact they aren't.
that's the confusion.
they are in the same level.
but i don't know why, when i wrote this.
> ['[long]] [@args]
> seems to indicate what you wanted better.
so i' had written it initially. then i've corrected, as the evaluation
was different.
you'll see the why in the new posting.
> But I don't find this a great
> advantage because it is, so to speak, a misnomer. The , operator is
> supposed to act on only one s-expression, but a syntax such as [ ... ]
> would indicate that it operates on a list of s-expressions. Defining ]
> as a Space gives it a "comment-like" characteristic, but comments are
> supposed to give information, not mislead (and not be superfluous, one
> would hope).
i understand.
it thought to use it only with macros.
> Not to mention the troubles this will cause when used in conjunction
> with the SQL reader syntax of the UncommonSQL package; which also uses
> []s. That is why I think most library packages don't use fancy
> reader-macro syntax---they don't want to pre-empt the user or conflict
> with other libraries. (Obviously there are exceptions to this, where
> you specifically obtain the library for the syntax it provides).
this sounds like a conceptual dilemma.
will see.
> I rarely write macros-defining-macros and when I do, I generally
> consider it worth my while to devote extra thought to it; most certainly
> enough to handle parsing ,',.
yes, ok. but there are situation you could need 3,4,5 or more levels.
> Whereas in an UncommonSQL-using program I
> will often use the SQL syntax, where it saves time and offers a great
> deal of additional clarity (to someone already familiar with SQL anyway).
under this circumstances the decision is clear.
>
> It's fun to experiment with the reader, but overuse/abuse of it in
> actual programs can lead to difficult to maintain code; particularly if
> involving new developers or new libraries. There are better places to
> extend the language than the first-level syntax.
xexe!
yes. in the specs.
>
> This is all just my opinion, anyway. YMMV.
>
ok
ilias <·······@pontos.net> wrote in message news:<················@pontos.net>...
> (defmacro alias (short long)
> `(defmacro [short] (&rest args)
> `( [ '[long] [@args] ] )))
The comma syntax is better because it's just one character instead of
two and because it especially looks neater when the form is not just a
symbol.
E.g. ,(intern "XYZ") vs [(intern "XYZ")]
And, in natural language writing, a comma would be out of place at the
start of a word. That makes it easier to recognize at a glance when
reading such CL code.
Software Scavenger wrote:
> ilias <·······@pontos.net> wrote in message news:<················@pontos.net>...
>
>
>>(defmacro alias (short long)
>> `(defmacro [short] (&rest args)
>> `( [ '[long] [@args] ] )))
>
>
> The comma syntax is better because it's just one character instead of
If so, what about the parentheses?
What about the typing-effort for the word 'defmacro'?
> two and because it especially looks neater when the form is not just a
> symbol.
> E.g. ,(intern "XYZ") vs [(intern "XYZ")]
Context and priority here is:
Recognition of nested macro variables.
In a nested macro with e.g. 4 levels i run personally into recognition
problems.
> And, in natural language writing, a comma would be out of place at the
> start of a word. That makes it easier to recognize at a glance when
> reading such CL code.
I think LISP code has many optical non-natural-language points. Thus the
pre-symbol-comma (,symbol) does not really differentiate.
,symbol ,(form) `(,form) `(sym ,var1 ,var2)
Additionally, a "standard-language" trained mind reconizes the , as
vardelimiter.
Recognition of ` and ' and , when coding for hours in deeply nested
macro-code can be a nightmare.
Maybe something like %var or $(func dummy)
But then it will look like BASIC, PHP or some other ordinary language.
But why not?
If it is better for the eyes?
ilias wrote:
> I think LISP code has many optical non-natural-language points. Thus the
> pre-symbol-comma (,symbol) does not really differentiate.
>
> ,symbol ,(form) `(,form) `(sym ,var1 ,var2)
>
> Additionally, a "standard-language" trained mind reconizes the , as
> vardelimiter.
>
> Recognition of ` and ' and , when coding for hours in deeply nested
> macro-code can be a nightmare.
>
> Maybe something like %var or $(func dummy)
>
> But then it will look like BASIC, PHP or some other ordinary language.
>
> But why not?
>
> If it is better for the eyes?
Hi ilias,
I have read through several of your past messages and tried to
reconstruct what you're actually after. As far as I understand you are
trying to create your own "dream language" on top of another promising
language. (In the past you have also tried this on top of Smalltalk and
probably other languages as well.)
As far as I can see by now you are confusing several things. (1) You
have read somewhere that Lisp is a "programmable programming language";
and then (2) you have found some arbitrary specifications about how to
change the syntax of Lisp.
What you need to understand is that the statement about Lisp being a
"programmable programming language" was most probably meant as a
metaphor to describe the expressive power of Lisp at the semantic level.
The real power of Lisp lies in the fact that it includes a theory of
computation by treating data and programs in a unified way. For example,
this allows you to write functions in Lisp that generate new functions
on thy fly. Because this can be done both at runtime and at compile-time
this basically means that you can create new abstractions that are not
available in the base language per se. This doesn't necessarily mean
that these abstractions introduce new syntax. Lisp programmers rather
try to keep the syntax for new abstractions as close to standard Lisp
syntax as possible. So especially this means that noone tries to change
parentheses or replace them by arbitrary other characters. This just
doesn't fit into the Lisp culture.
The specifications you have found for replacing special characters of
the Lisp syntax are _not_ about creating new abstractions at the
semantic level. They are just about changing minor aspects of the
syntax. So this is definitely not what is meant by the metaphor of a
"programmable programming language". Especially these means to change
the syntax of Lisp weren't introduced in order to allow for replacement
of parentheses, because this wouldn't make sense in the Lisp culture.
Parentheses are so essential to the Lisp syntax that you should start to
try to live with them if you really want to stay with Lisp.
If it is the case that you don't like this particular aspect of Lisp,
then probably it is not the right language for you; you could
alternatively try out languages like Python and/or Dylan that try to
keep some of the expressive power of Lisp but whose syntaxes are
deliberately closer to a more "standard language" (whatever this means).
So they look more like C, C++ or php or similar languages. Other
languages you could look for are ML or Objective CAML that are, however,
somewhat different in spirit.
Please keep in mind that, as of yet, you are only playing around with
the syntax level of Lisp. You haven't even come close to touching the
things that are possible by means of the features of the "programmable
programming language" Lisp. The fact that you insist to stay on the
syntax level is surely the main reason why many people are so annoyed
about your posts and even start flame wars about your person. The syntax
level is generally regarded a minor aspect when compared to the things
that are in fact possible in Lisp at the semantic level. It _is_
irritating to see that someone dismisses these possibilities because of
purely superficial reasons.
If you really want to keep with your goal of creating a totally new
"dream language" you should rather learn how to implement interpreters
and/or compilers, look at tools like yacc/lex or ANTLR and read books
about compiler construction. You should actually start to write your own
language completely from scratch, not just as a modification on top of
another language. However, let me warn you: it takes a great amount of
work and a hard, and long time of learning complicated topics, before
you can actually achieve something of considerable value. You're
definitely not the first person in the world who tried to create a new
and substantial programming language.
Good luck,
Pascal
Pascal Costanza wrote:
...many things
Which i'm sorry to be unable to answer in detail.
I'm sure that many readers will gain informaions or some essence out of it.
Pascal Costanza wrote:
...many things
Which i'm sorry to be unable to answer in detail.
I'm sure that many readers will gain informaions or some essence out of it.
Pascal Costanza wrote:
> ilias wrote:
>
>> Pascal Costanza wrote:
>>
>> ...many things
>>
>> Which i'm sorry to be unable to answer in detail.
>
>
> Why?
cause there are to many off-topic and irrelevant details in it.
you give me to much information that i've not requested.
ilias <·······@pontos.net> writes:
> Pascal Costanza wrote:
> > ilias wrote:
> >
> >> Pascal Costanza wrote:
> >>
> >> ...many things
> >>
> >> Which i'm sorry to be unable to answer in detail.
> > Why?
>
> cause there are to many off-topic and irrelevant details in it.
>
> you give me to much information that i've not requested.
``Casting pearls before swine'' comes to mind.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
"ilias" <·······@pontos.net> wrote in message
·····················@pontos.net...
> Pascal Costanza wrote:
> > ilias wrote:
> >
> >> Pascal Costanza wrote:
> >>
> >> ...many things
> >>
> >> Which i'm sorry to be unable to answer in detail.
> >
> >
> > Why?
>
> cause there are to many off-topic and irrelevant details in it.
>
> you give me to much information that i've not requested.
>
I lurk here a lot, but rarely post, but your latest post really takes the
cake! I discovered the news group microsoft.public.vb.syntax, and I suggest
that you switch your syntactic preoccupation to this newsgroup, and give up
on Lisp.
Jim Bushnell
Jim Bushnell wrote:
> "ilias" <·······@pontos.net> wrote in message
> ·····················@pontos.net...
>
>>Pascal Costanza wrote:
>>
>>>ilias wrote:
>>>
>>>>Pascal Costanza wrote:
>>>>
>>>>...many things
>>>>
>>>>Which i'm sorry to be unable to answer in detail.
>>>
>>>Why?
>>
>>cause there are to many off-topic and irrelevant details in it.
>>
>>you give me to much information that i've not requested.
>>
>
> I lurk here a lot, but rarely post, but your latest post really takes the
> cake! I discovered the news group microsoft.public.vb.syntax, and I suggest
> that you switch your syntactic preoccupation to this newsgroup, and give up
> on Lisp.
i've apologized by the poster in another posting.
ilias wrote:
> Pascal Costanza wrote:
>> ilias wrote:
>>
>>> Pascal Costanza wrote:
>>>
>>> ...many things
>>>
>>> Which i'm sorry to be unable to answer in detail.
>>
>>
>> Why?
>
> cause there are to many off-topic and irrelevant details in it.
>
> you give me to much information that i've not requested.
Ilias, I've read Pascal's long post, and I think you'll find it insightful
if you do read and understand it.
He basically wrote that you are paying too much attention to syntax (e.g.
{} vs ()) which is unimportant compared to the semantics, i.e. the core of
the language.
I sense however that you are the kind of person who learns better from
personal experience rather than from verbal communcation with others. If
this is true, here is a challenge for YOU:
Write an alpha-beta or minimax search library in C++ and in Lisp (I
personally prefer O'Caml, but what the hell), the requirement being that
this library should be re-usable in any of the two-player games such as
chess, checkers, othello, tic-tac-toe. If that sounds too time-consuming,
just write an interface (header file) for the possible C++ implementation.
Cheers,
Oleg
Pascal Costanza wrote:
> ilias wrote:
>
>> Pascal Costanza wrote:
>>
>> ...many things
>>
>> Which i'm sorry to be unable to answer in detail.
>
>
> Why?
>
>
> Pascal
>
Of more time i'd like to beg your pardon for rejecting you here in this
ungentle way.
I had overflown you article before i decide to not take information out
of it (which, when i answer automaticly happens).
I must simply take care which knowledge i assimilate in which sequence.
The best way to deal with this is to answer the given questions and to
place additional information, comments and suggestion of how to process
in a seperate block.
Althouth i generally don't use this additional information, it can be
very usefull for other readers.
It is nearly impossible to change my process-model. But if i stuck, i've
no problem to ask for suggestions. As i've done now.
I have just opened a topic:
"LISP - When you've seen it, what else can impress?"
I would like to let you know, that i have i've forgotten you posting
about psychology yesterday already.
And i would like to see you writing in this topic.
Because of the simple fact that you have the expertise to do this.
* ilias <·······@pontos.net>:
> I think LISP code has many optical non-natural-language points. Thus the
> pre-symbol-comma (,symbol) does not really differentiate.
>
> ,symbol ,(form) `(,form) `(sym ,var1 ,var2)
Why would it?
> Additionally, a "standard-language" trained mind reconizes the , as
> vardelimiter.
Assuming you mean what I think you mean when you say "standard-language", my
background is in languages that use the comma to separate arguments and
other things and I've never had a problem switching from those languages, to
Lisp, and back again. I'd be surprised to find that anyone has a problem
with this after the first few moments.
Finger memory is the hardest aspect of this but anyone who works with more
than one language will have overcome that disability pretty quickly.
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
From: Erik Naggum
Subject: Re: LISP - The Challenge of Nested Macros
Date:
Message-ID: <3240048483968979@naggum.no>
* Dave Pearson
| Assuming you mean what I think you mean when you say "standard-language", my
| background is in languages that use the comma to separate arguments and
| other things and I've never had a problem switching from those languages, to
| Lisp, and back again. I'd be surprised to find that anyone has a problem
| with this after the first few moments.
The problem with syntax is in the programmer's opiniated mind. Suppose you
were told that you had to write all of Common Lisp's multi-word symbol names
without a hyphen, but instead with shifting the first letter of the word.
Would you scream and shout and think this idiotic or would you adjust to the
new requirement and keep going at what is more important to you, namely what
you seek to accomplish with your software-writing skills and abilities?
After all, it is only a question of which key to press between words, right?
So, the real question is: at what point does syntax become more important
than your real task? To someone who has nothing whatsoever to accomplish,
syntax can be arbitrarily important.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
* Erik Naggum <····@naggum.no>:
> * Dave Pearson
> | Assuming you mean what I think you mean when you say "standard-language", my
> | background is in languages that use the comma to separate arguments and
> | other things and I've never had a problem switching from those languages, to
> | Lisp, and back again. I'd be surprised to find that anyone has a problem
> | with this after the first few moments.
>
> The problem with syntax is in the programmer's opiniated mind.
I'd say that's a fair summary of what I was saying.
> Suppose you
> were told that you had to write all of Common Lisp's multi-word symbol names
> without a hyphen, but instead with shifting the first letter of the word.
> Would you scream and shout and think this idiotic or would you adjust to the
> new requirement and keep going at what is more important to you, namely what
> you seek to accomplish with your software-writing skills and abilities?
I suppose, personally, it would depend on the reason for the imposed change.
I guess it's like the paren placing "issue" with Lisp code. The first time I
ever wrote some Lisp (emacs Lisp, I guess I'm not alone there) I placed the
parens in the "correct" place to make my Lisp code more "readable" (see your
point about "opiniated"). I soon got out of the habit, thankfully.
I guess I find it hard to think what I would personally think and feel in
the above scenario because it's such an unlikely event. For what it's worth
I spend a large part of the day UsingThisSortOfLanguage but don't have a
problem using this-sort-of-language and I find I write in and read both with
ease and no desire to shout or scream. Which, if I'm reading the above
correctly, is part of your point? Accept, or reject, the language for what
it is?
> After all, it is only a question of which key to press between words,
> right?
Hmm, I think it's a little more than that, I personally see it as a "talking
like a native" issue. CL's quoting wasn't hard for me to grasp because I
accepted it for what it is, if I'd wrung my hands over how it was different
from languages some see as "standard" I probably would have shouted and
screamed.
> So, the real question is: at what point does syntax become more
> important than your real task? To someone who has nothing whatsoever to
> accomplish, syntax can be arbitrarily important.
That seems to make sense.
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
Dave Pearson wrote:
> * ilias <·······@pontos.net>:
>
>
>>I think LISP code has many optical non-natural-language points. Thus the
>>pre-symbol-comma (,symbol) does not really differentiate.
>>
>>,symbol ,(form) `(,form) `(sym ,var1 ,var2)
>
>
> Why would it?
this was an reply to this:
>>> And, in natural language writing, a comma would be out of place at the
>>> start of a word. That makes it easier to recognize at a glance when
>>> reading such CL code.
>>Additionally, a "standard-language" trained mind reconizes the , as
>>vardelimiter.
>
> Assuming you mean what I think you mean when you say "standard-language",
why don't you say it: C, C++, some assemblers (if i remember right)
> my background is in languages that use the comma to separate arguments and
> other things and I've never had a problem switching from those languages, to
> Lisp, and back again.
ok. you.
> I'd be surprised to find that anyone has a problem
> with this after the first few moments.
it's ok, if you're surprised.
> Finger memory is the hardest aspect of this but anyone who works with more
> than one language will have overcome that disability pretty quickly.
or he customizes one of the languages to fit to his needs.
ilias <·······@pontos.net> writes:
> > Finger memory is the hardest aspect of this but anyone who works with more
> > than one language will have overcome that disability pretty quickly.
>
> or he customizes one of the languages to fit to his needs.
Ai d�nt laik inglish spelling, s� ai h�v k�stomaised it tu mai �vn nids!
If ju d�nt laik th�t, its j�r pr�blem, n�t main! (�r meibi n�t?)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> ilias <·······@pontos.net> writes:
>
> > > Finger memory is the hardest aspect of this but anyone who works with more
> > > than one language will have overcome that disability pretty quickly.
> >
> > or he customizes one of the languages to fit to his needs.
>
> Ai d�nt laik inglish spelling, s� ai h�v k�stomaised it tu mai �vn nids!
> If ju d�nt laik th�t, its j�r pr�blem, n�t main! (�r meibi n�t?)
http://english-zone.bravepages.com/language/mayhem.html
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Espen Vestre wrote:
> ilias <·······@pontos.net> writes:
>
>>> Finger memory is the hardest aspect of this but anyone
>>> who works with more than one language will have
>>> overcome that disability pretty quickly.
>>
>> or he customizes one of the languages to fit to his
>> needs.
>
> Ai d�nt laik inglish spelling, s� ai h�v k�stomaised it
> tu mai �vn nids! If ju d�nt laik th�t, its j�r pr�blem,
> n�t main! (�r meibi n�t?)
N�is. Ai H�v n� pr�blem ridin th�t. �rlth� ai h�v t� fink t�
wriat it.
--
Jens Axel S�gaard
From: Hannah Schroeter
Subject: Re: LISP - The Challenge of Nested Macros
Date:
Message-ID: <al2o7e$1lp$1@c3po.schlund.de>
Hello!
Jens Axel S�gaard <······@soegaard.net> wrote:
>[...]
>N�is. Ai H�v n� pr�blem ridin th�t. �rlth� ai h�v t� fink t�
>wriat it.
Hau �baut j�sing �� �orn �nd e� k�r�kt�rs f�r �� dent�l frik�tifs?
Kajnd rigards,
Hannah.
* ilias <·······@pontos.net>:
> Dave Pearson wrote:
>
> > I'd be surprised to find that anyone has a problem with this after the
> > first few moments.
>
> it's ok, if you're surprised.
I take it that you find it hard to grasp then?
> > Finger memory is the hardest aspect of this but anyone who works with
> > more than one language will have overcome that disability pretty
> > quickly.
>
> or he customizes one of the languages to fit to his needs.
I've generally found that this route isn't a very fruitful one, you seldom
learn much about the language in question.
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
ilias <·······@pontos.net> wrote in message news:<················@pontos.net>..
> ;;; ------------------------------------------------------------
> ;;; The Challenge of Nested Macros
> ;;; ------------------------------------------------------------
> (set-syntax-from-char #\[ #\,)
> (set-syntax-from-char #\] #\Space)
> ;;; ------------------------------------------------------------
>
> ;;; this enables the following writing-style, which clarifies
> ;;; optically the level of the macro-variables.
> ;;; [s1-a] [s1-b] = ,symbol = evaluate in first pass
> ;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
Notice how this notation looks like it denotes some kind of nested
structure. But in fact this resemblance is a lie, because s2-a and
s2-b are not in fact grouped in any way. The notation simply means
,,s2-a ,s2-b
The closing brackets don't match anything; they have the effect
of whitespace.
All you have done is introduce confusion. This is the height of
stupidity, because a notation should clarify, not obscure.
In the English language we have an idiomatic phrase that accurately describes
the action of your ] symbols: ``red herring''. A red herring is something
irrelevant that masquerades as something relevant, thereby contributing to
confusion. Adding red herrings to a programming notation is irresponsible
buffoonery.
> ;;; I imagine the backquote '`' as a gun, which shots over lines
> ;;; and the 'ball' destroys one level of [].
> ;;; what happens in the above test-code:
Your imagination is wrong. Consider
``,(+ 2 2)
The backquote does not cancel any unquote because the result is `,(+ 2 2).
So the gun shoots into the air, in this case.
The unquote belongs to the outer backquote, not to the inner one.
The inner backquote has to provide two levels of unquote in order
to engage any evaluation in the outer backquote:
``,,(list '+ 2 2) ==> `,(+ 2 2)
If this resulting form is then evaluated again, it finally yields 4. In other
words, the original (list '+ 2 2) ends up evaluated twice.
This double evaluation is sometimes unwanted, in which situations you
have to write ,', rather than ,, . This way the first round of backquoet
processing will produce ,(quote X) which will shield the X from
another evaluation.
This isn't all that easy to understand at first. In fact, if we search old
Usenet archives, we find that around 1980 this double evaluation managed to
trip up a certain bright gentleman by the name of Ronald Rivest, who had to hit
Usenet to learn about the ,', trick.
> any questions / corrections?
>
> lets discuss!
You should learn to crawl before you try to run, never mind walk. Try to write
some software in Lisp before you try to change the language, and then if you
want people to be interested, don't do it in stupid or useless ways.
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
> This double evaluation is sometimes unwanted, in which situations you
> have to write ,', rather than ,, . This way the first round of backquoet
> processing will produce ,(quote X) which will shield the X from
> another evaluation.
>
> This isn't all that easy to understand at first. In fact, if we search
> old
> Usenet archives, we find that around 1980 this double evaluation managed > to
> trip up a certain bright gentleman by the name of Ronald Rivest, who had > to hit
> Usenet to learn about the ,', trick.
My apologies, this was not Usenet at all, but a Lisp mailing list at
MIT. Here is an archive which contains the relevant e-mail
exchange: http://its.svensson.org/LSPMAI;BUG%20MAIL8
Enjoy!
Kaz Kylheku wrote:
> ···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<····························@posting.google.com>...
>
>>This double evaluation is sometimes unwanted, in which situations you
>>have to write ,', rather than ,, . This way the first round of backquoet
>>processing will produce ,(quote X) which will shield the X from
>>another evaluation.
>>
>>This isn't all that easy to understand at first. In fact, if we search
>>old
>>Usenet archives, we find that around 1980 this double evaluation managed > to
>>trip up a certain bright gentleman by the name of Ronald Rivest, who had > to hit
>>Usenet to learn about the ,', trick.
>
>
> My apologies, this was not Usenet at all, but a Lisp mailing list at
> MIT. Here is an archive which contains the relevant e-mail
> exchange: http://its.svensson.org/LSPMAI;BUG%20MAIL8
>
> Enjoy!
thank you for the link.
i'll come back to this topic. The Lisp-reader has captured me more than
i've expected expected.
=========================================================================
Date: 30 JAN 1980 1257-EST
From: ALAN at MIT-MC (Alan Bawden)
Subject: backquote
To: RIVEST at MIT-ML
CC: (BUG LISP) at MIT-MC
It is not true that there is no way to accomplish what you wish with
the current backquote. What I think you want is this:
(defmacro setprop (x y z)
`(prog2 (putprop ,x ,y ,z)
(defmacro ,z(v) `(get ,v ',',z))))
This means that a form like (setprop a b c) produces a macro named
c that is defined as (defmacro c (v) `(get ,v 'c)) which I presume
is what you want, right?
I have inserted a quote between the two commas to prevent z from
being "evaluated twice" (that is, to prevent the result of evaluating
z from being reevaluated at the time the macro named ,z is invoked).
There are occasions when you want such double evaluation to happen
so to change backquote in the way you suggest would be breaking it.
You are quite correct that there is no good explaination of this
anywhere. (Probably because it is damned difficult to explain!)
Probably the next LispMachine manual will contain a "double backquote
cookbook" to help macro defining macro writers to stay sane.
······@MIT-ML 01/30/80 10:55:41
To: (BUG LISP) at MIT-ML
This is a minor gripe and suggestion about `
First the gripe: the documentation doesn't adequately describe
what happens with nested backquotes and commas, etc.
Perhaps this is obvious to some (and in retrospect is pretty reasonable)
but LISP NEWS might have a word here.
Second the suggestion. I think backquote needs to be extended.
Consider the
following problem: I want to define a macro SETPROP so that (SETPROP x y z)
does two things: a (PUTPROP x y z) and also it defines a macro for z so that
(z foo) will extract foo's z property. My first attempt was something like:
(defmacro setprop (x y z)
`(prog2 (putprop ,x ,y ,z)
(defmacro ,z (v) `(get ,v ',z))))
This almost works, except that the commas in the nested backquote are at
different levels. The first-level expansion of the macro call (SETPROP
'a 'b 'c) tries to expand v.
Nope! (Boy am I a little confused!) I just tried that and discovered that
thhe problem is that Z is undefined when the defmacro for C is evaluated.
So I guess the rule is that in the evaluation of a back-quoted form, only
those comma-expressions are evaluated and plugged in which are not
themselves
inside further nested backquoted forms. (please explain this clearly
somewhere
in the documentation !)
So how do I get what I want (elegantly, of course)? Some way of
associating commas with backquotes seems a useful possibility. In the
above example, we want Z to be evaluated and plugged in when the outer
backquoted form is evaluated.
Let me suggest the following extension: let a series of k commas
associate that comma with the k-th backquote, working outwards from the
occurence of the commas. Thus one comma works as before, and I get what
I want with:
(defmacro setprop (x y z)
`(prog2 (putprop ,x ,y ,z)
(defmacro ,z(v) `(get ,v ',,z))))
So the Z is evaluated with the outer backquoted form. This generalizes
to ,@ etc.
Comments?
Ron Rivest
Kaz Kylheku wrote:
> ilias <·······@pontos.net> wrote in message news:<················@pontos.net>..
>
>>;;; ------------------------------------------------------------
>>;;; The Challenge of Nested Macros
>>;;; ------------------------------------------------------------
>>(set-syntax-from-char #\[ #\,)
>>(set-syntax-from-char #\] #\Space)
>>;;; ------------------------------------------------------------
>>
>>;;; this enables the following writing-style, which clarifies
>>;;; optically the level of the macro-variables.
>>;;; [s1-a] [s1-b] = ,symbol = evaluate in first pass
>>;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
>
...
>>;;; I imagine the backquote '`' as a gun, which shots over lines
>>;;; and the 'ball' destroys one level of [].
>>;;; what happens in the above test-code:
>
> Your imagination is wrong. Consider
>
> ``,(+ 2 2)
>
> The backquote does not cancel any unquote because the result is `,(+ 2 2).
> So the gun shoots into the air, in this case.
you are wrong.
not in the air.
` ------> into my cortex.
thats why i'm terribly confused with this here.
in terms of the specs i would say:
"Backquote syntax: underspecified"
but then people 'kill' me again.
i try now a second pass.
then i'll get it.
From: Kenny Tilton
Subject: Re: LISP - The Challenge of Nested Macros
Date:
Message-ID: <3D7D9D99.3020601@nyc.rr.com>
ilias wrote:
> in terms of the specs i would say:
>
> "Backquote syntax: underspecified"
>
> but then people 'kill' me again.
In other words, whether or not people agree with your words (which you
cannot have known when writing this), you will anyway be excoriated for
your words because (may I take a guess?) we who have responded are
basically foaming-at-the-mouth unreasoning monsters.
This after a hundred emails explaining in detail where you have gone
wrong. Whether you accept the explanations or not, the earnest feedback
was sincerely offered, as you know.
Shame on you. (Cue the "ilias sorry" Mongo-ripoff act.) Or do we get the
"time to sleep" BS?
:)
bored, kt
Kenny Tilton wrote:
> ilias wrote:
>
>> in terms of the specs i would say:
>>
>> "Backquote syntax: underspecified"
>>
>> but then people 'kill' me again.
>
> In other words, whether or not people agree with your words (which you
> cannot have known when writing this), you will anyway be excoriated for
> your words because (may I take a guess?) we who have responded are
> basically foaming-at-the-mouth unreasoning monsters.
'kill' can be interpreted via imagination.
as you've done.
"foaming-at-the-mouth unreasoning monsters"
i prefere the term "savages".
> This after a hundred emails explaining in detail where you have gone
> wrong.
The '100 emails' are wrong.
And i am right.
See "LISP - The Scary Readtable - ()=>[] - [#V0.4]
> Whether you accept the explanations or not, the earnest feedback
> was sincerely offered, as you know.
I don't know.
> Shame on you. (Cue the "ilias sorry" Mongo-ripoff act.) Or do we get the
> "time to sleep" BS?
I cannot translate "Mongo-ripoff".
There is no sorry i've to say.
And i just wake up.
ilias <·······@pontos.net> writes:
> There is no sorry i've to say.
>
> And i just wake up.
For the love of life, I hope he's not speaking metaphorically here.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Quoth ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick):
> ilias <·······@pontos.net> writes:
>
>> There is no sorry i've to say.
>>
>> And i just wake up.
>
> For the love of life, I hope he's not speaking metaphorically here.
You might as well shoot yourself. (Or jump in the lake with Mrs
Poundstone.)
I don't think we're visiting metaphor territory here...
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.ntlug.org/~cbbrowne/languages.html
"My mom said she learned how to swim. Someone took her out in the lake
and threw her off the boat. That's how she learned how to swim. I
said, 'Mom, they weren't trying to teach you how to swim.' "
-- Paula Poundstone
Kaz Kylheku wrote:
> ilias <·······@pontos.net> wrote in message news:<················@pontos.net>..
>
>>;;; ------------------------------------------------------------
>>;;; The Challenge of Nested Macros
>>;;; ------------------------------------------------------------
>>(set-syntax-from-char #\[ #\,)
>>(set-syntax-from-char #\] #\Space)
>>;;; ------------------------------------------------------------
>>
>>;;; this enables the following writing-style, which clarifies
>>;;; optically the level of the macro-variables.
>>;;; [s1-a] [s1-b] = ,symbol = evaluate in first pass
>>;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
[...]
> All you have done is introduce confusion. This is the height of
> stupidity, because a notation should clarify, not obscure.
[...]
> If this resulting form is then evaluated again, it finally yields 4. In other
> words, the original (list '+ 2 2) ends up evaluated twice.
>
> This double evaluation is sometimes unwanted, in which situations you
> have to write ,', rather than ,, . This way the first round of backquoet
> processing will produce ,(quote X) which will shield the X from
> another evaluation.
Finally it looks that you belong to the big group of "Nested Macro
Confused People".
The literature i used, is a little misleading at this point. And i think
there is an error, too:
> now, i found something interesting about macros here:
> http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
Page 215
Reading the specs:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
Brings more confusion.
Confusion in the literature.
Confusion in the specification.
Confusion in c.l.l.
Confusion in the old mailing lists.
Due to this confusion (i now that something is wrong, so i cannot
understand) i try to find a more convient optical representation, so i'm
able to understand.
Thus i tried this parentheses thing, which was additionally "an exercise
for the experts" (?).
Now i've understand.
Will write this down.
But for now a break.
Hope i have enough time.
> ;;; ------------------------------------------------------------
> ;;; The Challenge of Nested Macros #V0.3 - ilias - 2002-09-12
> ;;; ------------------------------------------------------------
This is an intermediate version, which may confuses the reader more than
he may already is.
It is a showcase for the "Process of Understanding Wrong"
If you get confused, wait for #V0.4, which will contain the new results.
for you to remeber:
> now, i found something interesting about macros here:
> http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
>
> Page 213
>
> (defmacro abbrev (short long)
> `(defmacro ,short (&rest args)
> `(,',long ,@args)))
Please keep this line in mind: `(,',long ,@args)))
The derivation line in the book confuses me a little. This was mainly
due to an intermediate variable called 'name', which was used by the
author for simplification reasons.
Reading the specs:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
Brings more confusion.
So i decide to enclose the variables by brackets to support my
recognition process.
(defmacro abbrev (short long)
`(dfmacro ,short (&rest args)
`( ['[long]] [@args] )))
> note: i've changed the name of the macro from 'abbrev' to 'alias'
> ;;; ------------------------------------------------------------
> ;;; The Challenge of Nested Macros
> ;;; ------------------------------------------------------------
This simple solution implements the above in a simple way:
> (set-syntax-from-char #\[ #\,)
> (set-syntax-from-char #\] #\Space)
> ;;; ------------------------------------------------------------
But to my surprise, the evaluation of 'long' and ·@args' occour in the
same 'level'.
So i changed the line:
`( ['[long]] [@args] )))
`( ['[long] [@args] ] )))
which doesn't matter anyway, as ] is only whitespace and is placed
'manually' to clarify the picture of the macro-variable-expansion.
this conclusion is wrong:
> ;;; this enables the following writing-style, which clarifies
> ;;; optically the level of the macro-variables.
> ;;; [s1-a] [s1-b] = ,symbol = evaluate in first pass
> ;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
although this code runs fine:
> (defmacro alias (short long)
> `(defmacro [short] (&rest args)
> `( [ '[long] [@args] ] )))
>
> ;;; simple test code:
> (alias df defun)
>
> (df alias-test (x y z) (* x y z ) )
>
> (alias-test 2 3 5)
and this is correct, too:
> ;;; As ] is only whitespace, u can move them around as you like.
> ;;; this is a little bit dangerous. Keep in mind that:
> ;;; `( ['[long]] [@args] ) ==
> ;;; `( ['[long] [@args] ]) ==
> ;;; `( ,',long ,@args )
But the following imagination is again wrong:
> ;;; I imagine the backquote '`' as a gun, which shots over lines
> ;;; and the 'ball' destroys one level of [].
> ;;; what happens in the above test-code:
> ;;;
> ;;; (defmacro alias (short long) ; call: (alias df defun)
> ;;; `(defmacro [short] (&rest args)
> ;;; `( [ '[long] [@args] ] ) ))
> ;;;
> ;;; 1st shot:
> ;;; (defmacro df (&rest args)
> ;;; `( '[long] [@args] ) )
> ;;;
> ;;; 2nd shot:
> ;;; ( defun (x y z) (* x y z) ) ; args: (x y z) (* x y z)
> ;;;
> ;;; ------------------------------------------------------------
> ;;; Tested with Allegro.
> ;;; Should run on any conformant CL.
> ;;; ------------------------------------------------------------
> ;;; ilias - 2002-09-02 - #V0.2
> ;;; ------------------------------------------------------------
the main reason for all this confusion:
> now, i found something interesting about macros here:
> http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
>
> Page 213
>
> (defmacro abbrev (short long)
> `(defmacro ,short (&rest args)
> `(,',long ,@args)))
,',long is the same as ,long
,' evaluates to 'nothing' so you can simply drop it.
(defmacro abbrev (short long)
`(defmacro ,short (&rest args)
`(,long ,@args)))
looks easier now.
From: Joe Marshall
Subject: Re: LISP - The Challenge of Nested Macros - [#V0.3]
Date:
Message-ID: <y9a7mcm6.fsf@ccs.neu.edu>
ilias <·······@pontos.net> writes:
>
> ,',long is the same as ,long
>
This is not true.
> ,' evaluates to 'nothing' so you can simply drop it.
Nor is this.
> (defmacro abbrev (short long)
> `(defmacro ,short (&rest args)
> `(,long ,@args)))
>
> looks easier now.
Looks wrong now, too.
(defmacro abbrev1 (short long)
`(defmacro ,short (&rest args)
`(,',long ,@args)))
(defmacro abbrev2 (short long)
`(defmacro ,short (&rest args)
`(,long ,@args)))
(abbrev1 nice-and-short horrendously-long)
(macroexpand '(nice-and-short a b c)) => (horrendously-long a b c)
(abbrev2 shorter even-more-horrendously-long)
(macroexpand '(shorter a b c))
;; Error: The variable LONG is unbound
I only mention this because there just *might* be newbies still
reading these and I don't want them to become confused.
Joe Marshall wrote:
> ilias <·······@pontos.net> writes:
>
>>,',long is the same as ,long
> This is not true.
in context of macroexpansion: of course it is.
>>,' evaluates to 'nothing' so you can simply drop it.
> Nor is this.
of course it is.
>> (defmacro abbrev (short long)
>> `(defmacro ,short (&rest args)
>> `(,long ,@args)))
>>
>>looks easier now.
> Looks wrong now, too.
simply correct.
> (defmacro abbrev1 (short long)
> `(defmacro ,short (&rest args)
> `(,',long ,@args)))
>
> (defmacro abbrev2 (short long)
> `(defmacro ,short (&rest args)
> `(,long ,@args)))
>
> (abbrev1 nice-and-short horrendously-long)
>
> (macroexpand '(nice-and-short a b c)) => (horrendously-long a b c)
>
> (abbrev2 shorter even-more-horrendously-long)
>
> (macroexpand '(shorter a b c))
> ;; Error: The variable LONG is unbound
oh.
macroexpand.
i'm a lisp-novice.
this function is new to me.
i'll use it.
btw: The LISP you use seems to be *not* conforming to the ANSI Standard.
Cause ANSI-Conforming Common Lisp must execute this code.
> I only mention this because there just *might* be newbies still
> reading these and I don't want them to become confused.
Have you broken an agreement? you sound like this.
Anyway.
From: Tim Bradshaw
Subject: Re: LISP - The Challenge of Nested Macros - [#V0.3]
Date:
Message-ID: <ey37khqq2tk.fsf@cley.com>
* at news wrote:
> oh.
> macroexpand.
> i'm a lisp-novice.
> this function is new to me.
> i'll use it.
> btw: The LISP you use seems to be *not* conforming to the ANSI Standard.
> Cause ANSI-Conforming Common Lisp must execute this code.
Stop, please stop. You're making me frighten the cat and spill
perfectly good whisky on the keyboard. Oh dear, I'll have to stop
because I can't stand up from laughing.
--tim
The world rejoiced as Tim Bradshaw <···@cley.com> wrote:
> * at news wrote:
>
>> oh.
>
>> macroexpand.
>
>> i'm a lisp-novice.
>
>> this function is new to me.
>
>> i'll use it.
>
>> btw: The LISP you use seems to be *not* conforming to the ANSI Standard.
>
>> Cause ANSI-Conforming Common Lisp must execute this code.
>
> Stop, please stop. You're making me frighten the cat and spill
> perfectly good whisky on the keyboard. Oh dear, I'll have to stop
> because I can't stand up from laughing.
That's an unfriendly thing to do to your cat. I don't _like_ cats,
and I find myself appalled.
--
(concatenate 'string "chris" ·@cbbrowne.com")
http://cbbrowne.com/info/lisp.html
"Some people, when confronted with a Unix problem, think "I know, I'll
use sed." Now they have two problems." -- Jamie Zawinski
From: Joe Marshall
Subject: Re: LISP - The Challenge of Nested Macros - [#V0.3]
Date:
Message-ID: <k7lquji8.fsf@ccs.neu.edu>
Christopher Browne <········@acm.org> writes:
> The world rejoiced as Tim Bradshaw <···@cley.com> wrote:
> >
> > Stop, please stop. You're making me frighten the cat and spill
> > perfectly good whisky on the keyboard. Oh dear, I'll have to stop
> > because I can't stand up from laughing.
>
> That's an unfriendly thing to do to your cat. I don't _like_ cats,
> and I find myself appalled.
Forget the cat, spilling whisky is appalling.
navigation information to related topics:
initial
·····················································@pontos.net
V0.3
·················································@usenet.otenet.gr
V0.4
················································@usenet.otenet.gr
V0.5
·················································@usenet.otenet.gr
V0.6
·················································@usenet.otenet.gr
V0.7
·················································@usenet.otenet.gr
V0.8
·················································@usenet.otenet.gr
V0.9
·················································@usenet.otenet.gr
From: ilias
Subject: Re: LISP - The Challenge of Nested Macros - [#V0.4]
Date:
Message-ID: <alrd87$6v$1@usenet.otenet.gr>
;;;; ------------------------------------------------------------
;;;; The Challenge of Nested Macros #V0.4 - ilias - 2002-09-13
;;;; ------------------------------------------------------------
I've found something interesting about macros here:
http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
Page 213
(defmacro abbrev (short long)
`(dfmacro ,short (&rest args)
`(,',long ,@args)))
This looks somehow more complicated than it should be.
,' can be normalized to 'nothing', cause it looks like "evaluate-quote".
(defmacro abbrev (short long)
`(defmacro ,short (&rest args)
`(,long ,@args)))
With this macro 'abbrev', you can give unconsistent and annoying
naming an end.
Eg. defun & defmacro
(abbrev df defun)
(abbrev dm defmacro)
If the macros gets nested deeper, you may run into problems to
recognize evaluation-behaviour.
The code demostrates the implementation of an quick an easy
solution. You can of course modify it to your own needs. E.g.
to replace , with $.
;;; ------------------------------------------------------------
;;; The Challenge of Nested Macros code section
;;; ------------------------------------------------------------
;;; Set [ to behave like ,
;;; Set ] to behave like a Space-Character
;;; this enables the following writing-style, which clarifies
;;; optically (at least for some people) the level of the
;;; macro-variables.
;;; [s1-a] [s1-b] = ,symbol = var evaluated once
;;; [[s2-a]] [[s2-b]] = ,,symbol = var evaluated twice
;;; As ] is only whitespace, u can move them around as you like.
;;; this is a little bit dangerous. Keep in mind that:
;;; `( [long] [@args] ) ==
;;; `( [long [@args ]]) ==
;;; `( ,long ,@args )
(set-syntax-from-char #\[ #\,)
(set-syntax-from-char #\] #\Space)
(defmacro abbrev (short long)
`(defmacro [short] (&rest args)
`( [long] [@args] )))
;;; simple test code:
(abbrev df defun)
(df abbrev-test (x y z) (* x y z ) )
(abbrev-test 2 3 5)
;;; ------------------------------------------------------------
;;; Should run on any conformant CL.
;;; ------------------------------------------------------------
From: Andreas Hinze
Subject: Re: LISP - The Challenge of Nested Macros - [#V0.4]
Date:
Message-ID: <3D81BDEF.82261DE1@smi.de>
ilias wrote:
>
> ;;;; ------------------------------------------------------------
> ;;;; The Challenge of Nested Macros #V0.4 - ilias - 2002-09-13
> ;;;; ------------------------------------------------------------
>
> I've found something interesting about macros here:
> http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
> Page 213
>
> (defmacro abbrev (short long)
> `(dfmacro ,short (&rest args)
> `(,',long ,@args)))
>
> This looks somehow more complicated than it should be.
>
> ,' can be normalized to 'nothing', cause it looks like "evaluate-quote".
>
Why didn't you read until pg. 215 ? You will find enlighting explanations.
> (defmacro abbrev (short long)
> `(defmacro ,short (&rest args)
> `(,long ,@args)))
>
AFAIK Joe Marshall shows you that it doesn't work yesterday. Please check
his example code and think about it.
Best
AHz
Andreas Hinze wrote:
> ilias wrote:
>
>>;;;; ------------------------------------------------------------
>>;;;; The Challenge of Nested Macros #V0.4 - ilias - 2002-09-13
>>;;;; ------------------------------------------------------------
>>
>>I've found something interesting about macros here:
>>http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
>>Page 213
>>
>>(defmacro abbrev (short long)
>> `(dfmacro ,short (&rest args)
>> `(,',long ,@args)))
>>
>>This looks somehow more complicated than it should be.
>>
>>,' can be normalized to 'nothing', cause it looks like "evaluate-quote".
>>
>
> Why didn't you read until pg. 215 ? You will find enlighting explanations.
i've done this.
the explanations confused me.
there is something wrong in all this.
>>(defmacro abbrev (short long)
>> `(defmacro ,short (&rest args)
>> `(,long ,@args)))
>>
>
> AFAIK Joe Marshall shows you that it doesn't work yesterday. Please check
> his example code and think about it.
i've read this.
i've answered him.
From: Andreas Hinze
Subject: Re: LISP - The Challenge of Nested Macros - [#V0.4]
Date:
Message-ID: <3D8206A4.B6DC71F9@smi.de>
ilias wrote:
>
> Andreas Hinze wrote:
> > ilias wrote:
> >
> >>;;;; ------------------------------------------------------------
> >>;;;; The Challenge of Nested Macros #V0.4 - ilias - 2002-09-13
> >>;;;; ------------------------------------------------------------
> >>
> >>I've found something interesting about macros here:
> >>http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
> >>Page 213
> >>
> >>(defmacro abbrev (short long)
> >> `(dfmacro ,short (&rest args)
> >> `(,',long ,@args)))
> >>
> >>This looks somehow more complicated than it should be.
> >>
> >>,' can be normalized to 'nothing', cause it looks like "evaluate-quote".
> >>
> >
> > Why didn't you read until pg. 215 ? You will find enlighting explanations.
>
> i've done this.
>
> the explanations confused me.
>
> there is something wrong in all this.
>
It's not simple but it's not wrong (I spend hours this night to understand
how it works and i'm even not shure that i get it right).
Maybe it would be a good idea for you to try it again. IMHO it will not help
to not understand the but to reinvent the wheel here.
Best
AHz
Andreas Hinze wrote:
>>i've done this.
>>
>>the explanations confused me.
>>
>>there is something wrong in all this.
>>
>
> It's not simple but it's not wrong (I spend hours this night to understand
> how it works and i'm even not shure that i get it right).
> Maybe it would be a good idea for you to try it again. IMHO it will not help
> to not understand the but to reinvent the wheel here.
I've understand it.
But i've not understand what is wrong there.
Wait until the #V0.5 or #V0.6
I hope that everything will be clear.
This here is clear:
The Scary Readtable #V0.5
············@usenet.otenet.gr
You can give me an reply, if you like.
You've maybe noticed, that this here is something like 'Not
Understanding Nested Macros'.
;;;; ------------------------------------------------------------
;;;; The Challenge of Nested Macros #V0.5 - ilias - 2002-09-13
;;;; ------------------------------------------------------------
As you may have noticed, the code provided in 0.4 is *not* running.
I'll drop the bracket notation for now, to concentrate on the behaviour
of the backquote-syntax.
Backquote (`) is used to simplify the creation of lists.
Take a quick overview here, and come lighted or confused back:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
For code evaluation i'll use Xanalys LispWorks Personal Edition for
Windows. (Yes, this funny thing which exits without saving after 5 hours)
The original macro:
(defmacro abbrev (short long) ; [1]
`(defmacro ,short (&rest args)
`(,',long ,@args)))
I've said that ,' can be normalized to 'nothing', cause it looks like
"evaluate-quote".
It looks not only so, it is so. ,'<expression> simply returns <expression>:
(setq var 18) ; => 18
`var ; => VAR
`,var ; => 18
`,'var ; => VAR
....zzzzt!
What is "....zzzzt!" ???
the 4 hours warning window from Xanalys LispWorks Personal Edition.
at this point: push ok button, save, exit, restart, reopen.
anyway.
back to the work. where i've stopped?
ah, ok. The resulting modified macro:
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,long ,@args)))
;;; simple test code:
(abbrev df defun) ; df acts now like defun
(df abbrev-test (x y z) (* x y z ) ) ; define a function
(abbrev-test 2 3 5) ; execute the function
;;;; => Error: The variable LONG is unbound.
Now why?
The basic backquote-syntax is easy [ ` , ]. When nesting it, things
became a little more difficult.
The above macro generates a *code-template* when evaluated by LISP.
(this is an 'out-of-imagination-evaluation', i mean i don't typed this
into a LISP command-line.)
(abbrev df defun) ; this call
(defmacro df (&rest args) ; produces this code internally
`(,long ,@args)
(df abbrev-test (x y z) (* x y z)) ; this call
(,long ) => here comes the error. The variable LONG is unbound
The information "defun" is not related to long.
The variable 'long' which holds the symbol-name 'defun' has to be
evaluated with the *first* call.
why?
I need a break.
to be continued...
--------------------------------------------------------------------
[1]
I've found something interesting about macros here:
http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
Page 213
ilias <·······@pontos.net> wrote in message news:<············@usenet.otenet.gr>...
> (defmacro abbrev (short long) ; [1]
> `(defmacro ,short (&rest args)
> `(,',long ,@args)))
Your fallacy is in thinking the quote is a form. But it's an
operator. The form affected by the first comma of ,',long is ',long
rather than just the ' alone.
The easiest way to read this, and to remember how it works, is to
treat ,', as an idiom or magic formula meaning the same thing as ,
except that it associates with the outer backquote instead of the
inner.
If you don't understand something: you are not alone. simply continue
reading.
This is the continuation of #V0.5! Avoid reading, if you are confused.
In #V0.7 you'll find the first clean text.
;;;; ------------------------------------------------------------
;;;; The Challenge of Nested Macros #V0.6 - ilias - 2002-09-14
;;;; ------------------------------------------------------------
a few lines for remembering:
The original macro:
(defmacro abbrev (short long) ; [1]
`(defmacro ,short (&rest args)
`(,',long ,@args)))
,' "evaluate-quote" can be normalized to 'nothing'.
--------------------------------------------------------------------
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args) ;
`(,long ,@args))) ; notice: ,long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; this call
;;;calling this, we got the error.
;;;The variable LONG is unbound
(defmacro df (&rest args) ; so this should be the
`(,long ,@args) ; created macro.
The information "defun" is lost. 'long' is not longer related to the
symbol name 'defun'.
The variable 'long' which holds the symbol-name 'defun' has to be
evaluated with the *first* call.
Because in the *second* call, the symbol-name 'defun' is not available
anymore.
--------------------------------------------------------------------
[ *V0.6 section* ]
--------------------------------------------------------------------
It looks like if there is only one comma, it belongs to the *second*
backquote and not how you may would expect to the *first* backquote.
So we have to place a second comma in front of the symbol 'long', thus
the *first* backquote gets its 'hands' on the variable long.
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args) ; *first* backquote.
`(,,long ,@args))) ; notice: ,,long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; this call
;;;calling this, we got a new error.
;;;=> The variable DEFUN is unbound.
(defmacro df (&rest args) ; so this should be the
`(,defun ,@args) ; created macro.
Why that now?
cause `(,defun...) tries to evaluate defun. That was not our intention.
--------------------------------------------------------------------
We wan't simply (defun ...). Again we change the macro:
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,,'long ,@args))) ; noctice: ,,'long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; call to df
;;;calling this, we got the old error again.
;;;=> The variable LONG is unbound.
(defmacro df (&rest args) ; so this should be the
`(,long ,@args) ; created macro.
`(,long...)
it seems that in the *first* pass: (,,'long) gets to (,long)
and in the *second* pass : ( ,long)
Thus: the *first* backquote gets the right comma.
and : the *second* backquote gets the left comma.
--------------------------------------------------------------------
We wan't 'long' to evaluate in the *first* pass:
,long
And we want the resulting value ('defun') to remain untuched:
But we must provide a second comma. Thus:
[2]
,' = do nothing, so ,',long
,' = speak: evaluation skip (e.g.)
--------------------------------------------------------------------
The resulting macro should remind you something. It is the same macro we
started with, but we are little bit wiser now and so we see it with
different eyes.
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,',long ,@args))) ; noctice: ,',long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; call to df
(defmacro df (&rest args) ; so this should be the
`(,'defun ,@args) ; created macro.
(abbrev-test 2 5 10) ; => 100
--------------------------------------------------------------------
preview:
of course there's something 'wrong' with all this backquote-syntax.
after writing down the clear document, i'll look to see what it is.
at this point i only feel it. This could be simply: it is correct but
much to difficult. It could be: standard violated. It could be: spirit
violated.
could. could.
--------------------------------------------------------------------
[1]
I've found something interesting about macros here:
http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
Page 213
[2]
Kay Kylheku excavated here an 20year old discussion:
http://its.svensson.org/LSPMAI;BUG%20MAIL8
search for string ,',
> [2]
> Kay Kylheku excavated here an 20year old discussion:
> http://its.svensson.org/LSPMAI;BUG%20MAIL8
> search for string ,',
correction:
Kaz Kylheku
the merger of 0.5 and 0.6
some corrections.
;;;; ------------------------------------------------------------
;;;; The Challenge of Nested Macros #V0.7 - ilias - 2002-09-15
;;;; ------------------------------------------------------------
The original macro:
(defmacro abbrev (short long) ; [1]
`(defmacro ,short (&rest args) ; *first* backquote
`(,',long ,@args))) ; *second* backquote
,' can be normalized to 'nothing', cause it looks like "evaluate-quote".
It looks not only so, it is so. ,'<expression> simply returns <expression>:
(setq var 18) ; => 18
var ; => 18
`var ; => VAR
`,var ; => 18
`,'var ; => VAR
The resulting modified macro:
--------------------------------------------------------------------
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args) ;
`(,long ,@args))) ; notice: ,long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; usage of df results in err
;;; *err: The variable LONG is unbound*
(defmacro df (&rest args) ; so this should be the
`(,long ,@args) ; created macro.
The variable 'long' which holds the symbol-name 'defun' has to be
evaluated with the *first* call.
Because in the *second* call, the symbol-name 'defun' is not available
anymore.
It looks like if there is only one comma, it 'belongs' to the *second*
backquote and not how you may would expect to the *first* backquote.
So we have to place a second comma in front of the symbol 'long', thus
the *first* backquote gets its 'hands' on the variable long.
--------------------------------------------------------------------
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args) ;
`(,,long ,@args))) ; notice: ,,long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; usage of df results in err
;;; *err: The variable DEFUN is unbound.*
(defmacro df (&rest args) ; so this should be the
`(,defun ,@args) ; created macro.
Why that now?
The ,,long was evaluated correctly by the *first* backquote.
But the resulting ,defun is then reached by the *second* backquote. But
we don't want this evaluation.
So we may place simply a ' (quote) to avoid evaluation.
--------------------------------------------------------------------
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,,'long ,@args))) ; notice: ,,'long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; usage of df results in err
;;; err: *The variable LONG is unbound.*
(defmacro df (&rest args) ; so this should be the
`(,long ,@args) ; created macro.
it seems that in the *first* pass: (,,'long) gets to (,long)
and in the *second* pass : ( ,long) gets to *error*
Thus: the *first* backquote strikes the *right* comma.
and : the *second* backquote strikes the *left* comma.
So we have to place the ' after the left comma. ,',long.
Or another way of thought:
--------------------------------------------------------------------
We wan't 'long' to be stroked by the *first* backquote:
,long
We must provide a *second* comma, as there is a *second* backquote.
But we want the resulting symbol ('defun') to remain unevaluated.
Thus we apply:
[2]
,' = do nothing, so we get ,',long
,' = speak: evaluation skip, or strike skip, or 'your imagination'
--------------------------------------------------------------------
The resulting macro should remind you something. It is the same macro we
started with, but we are little bit wiser now and so we see it with
different eyes.
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,',long ,@args))) ; noctice: ,',long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; usage of df is OK!
(defmacro df (&rest args) ; so this should be the
`(,'defun ,@args) ; created macro.
(abbrev-test 2 5 10) ; => 100
--------------------------------------------------------------------
we know now:
- the *first* backquote 'strikes' the right comma.
- the *second* backquote 'strikes' the left comma.
- the right comma is evaluated first
--------------------------------------------------------------------
at this point i get more information from sub-conscious. But still not
enouth to decipher. have a look:
at template-generation time:
innermost-backquote to leftmost-comma.
at template-usage time
outermost-backquote to rightmost-comma.
(note: this is directly written down. must *not* make any sense.
i try to analyze. this should be the source of confusion:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]
after sleep will be much clearer!!!
--------------------------------------------------------------------
--------------------------------------------------------------------
[1]
I've found something interesting about macros here:
http://www.paulgraham.com/lib/paulgraham/onlisp.pdf
Page 213
[2]
Kaz Kylheku excavated here an 20year old discussion:
http://its.svensson.org/LSPMAI;BUG%20MAIL8
search for string ,',
continuation of V0.7
I should change title into: Analyzing Subconscious Analyzis
But not sure if the term Subconscious fits.
;;;; ------------------------------------------------------------
;;;; The Challenge of Nested Macros #V0.8 - ilias - 2002-09-15
;;;; ------------------------------------------------------------
reminder:
The resulting macro should remind you something. It is the same macro we
started with, but we are little bit wiser now and so we see it with
different eyes.
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,',long ,@args))) ; noctice: ,',long
(abbrev df defun) ; use abbrev to create df...
(df abbrev-test (x y z) (* x y z)) ; usage of df is OK!
(defmacro df (&rest args) ; so this should be the
`(,'defun ,@args) ; created macro.
(abbrev-test 2 5 10) ; => 100
--------------------------------------------------------------------
*Conscious knowledge* gained *now* through aware reading of the standard
document
The standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"The backquote introduces a template of a data structure to be built.[...]"
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "the *innermost* backquoted form *should be* expanded first"
=> "the *leftmost* comma belongs to the *innermost* backquote"
This leads to the conclusion:
=> expand *innermost* backquoted form first and process leftmost comma
first.
(*process* comma: evaluate expression after the comma)
--------------------------------------------------------------------
*Conscious knowledge* gained through evaluation of the different
versions of the abbrev macro (see #V0.7).
- the *first* backquote 'strikes' the right comma.
- the *second* backquote 'strikes' the left comma.
- the right comma is evaluated first, thus...
the *first* backquote is evaluated first.
i normalize my *internal* terminology to *common* terminology (here:
that of the specs):
=> the *rightmost* comma belongs to the *outermost* backquote
[note: *only* if the no. of commas is equal to the no of backquotes]
=> the *leftmost* comma belongs to the *innermost* backquote
=> the *outermost* backquoted form is processed *first*.
This leads to the conclusion:
=> expand *outermost* backquoted form first and process *rightmost*
comma first [if no. of commas = no. of backquotes].
--------------------------------------------------------------------
here is the contradiction:
specs:
=> expand *innermost* backquoted form first and process leftmost comma
first.
subconscious [clarified & passed to conscious through testing]:
=> expand *outermost* backquoted form first and process *rightmost*
comma first [if no. of commas = no. of backquotes].
--------------------------------------------------------------------
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
The definition of the backquote refers to the *expansion* of the
datastructure.
Applied to macros, this means: usage of macros to generate code.
Applied to the macro 'abbrev', this means: calling macro 'abbrev' to
generate macro 'df'.
The test-sequence with the different versions of the nested macro
'abbrev' have shown, that the *outermost* backquote is expanded first.
So it seems that the defininition of backquote is wrong at this passage.
Or my test-results of the different macro-versions are wrong.
But it doesn't look so.
One last possibility (or: one last remaining confusion):
--------------------------------------------------------------------
*preconscious knowledge* - gained *yesterday* from Subconscious, fuzzy
output written directly down, uncorrected:
a) at template-generation time:
innermost-backquote to leftmost-comma.
b) at template-usage time
outermost-backquote to rightmost-comma.
What could this mean?
This could mean, that the processing of nested backquote expressions may
differs in the two cases:
- when *generating* the template itself (during evaluation)
- when *using* the template to *expand* the expression defined by the
template.
This could possibly explain the contradictions.
The passage of the backquote-definition may not refere, as implied by
the term *expanded*, to the *expansion* of the template to code...
...but to the creation-process of the template itself, when it is parsed
and build into memory by the backquote-macro-function.
This is a thin detail.
And i don't know if this is true at this point.
Cause it looks that nearly all of the passage talks about 'expanding'.
And somehow i feel that it is the same thing.
But I don't know.
--------------------------------------------------------------------
*subconscious knowledge* - gained before 20 days through reading around
in books an in the standard document. Additionally increased by
conversation in the newsgroups and the work on this article.
don't know it.
it's subconscious.
--------------------------------------------------------------------
this is really a desaster.
i read a little around in literature, but i cannot find absolute
clearness with thorough and indeep description about this topic.
--------------------------------------------------------------------
Subconcious signals:
- LISP is my language.
- LISP is Bleeding.
--------------------------------------------------------------------
I ate 2 bananas.
Are we really more worth than monkeys?
ilias <·······@pontos.net> wrote in message news:<············@usenet.otenet.gr>...
> (defmacro abbrev (short long) ;
> `(defmacro ,short (&rest args)
> `(,',long ,@args))) ; noctice: ,',long
>
Hello,
I'm trying to understand this also, maybe this helps:
Believe it or not, but the above is equivalent to:
(defmacro abbrev (short long)
`(defmacro ,short (&rest args)
(cons ',long args)))
Just try it, it worked in emacs Lisp.
Using this definition you replace the second backquote and maybe this
makes the whole image clearer.
To understand why those two definitions are equivalent just think
about the following part and remember that like any function backquote
is evaluated beginning at the innermost form:
`(,',long ,@args) <=> (cons ',long args)
This is explained in detail at:
http://www.supelec.fr/docs/cltl/clm/node190.html#BACKQUOTE
Hope it helped a bit...I'm also a LispNewbie
thelifter wrote:
> ilias <·······@pontos.net> wrote in message news:<············@usenet.otenet.gr>...
>
>>(defmacro abbrev (short long) ;
>> `(defmacro ,short (&rest args)
>> `(,',long ,@args))) ; noctice: ,',long
>>
>
> Hello,
>
> I'm trying to understand this also, maybe this helps:
>
> Believe it or not, but the above is equivalent to:
>
> (defmacro abbrev (short long)
> `(defmacro ,short (&rest args)
> (cons ',long args)))
>
I'm a lisp novice.
And i must stay that for a long time.
Undereducation gives me the strength to analyze abstract.
And backquote is abstract.
cons i don't know.
and i don't have to know, to understand and analyze backquote.
> Hope it helped a bit...I'm also a LispNewbie
It helps. Although in another way you've maybe expected:
i picked a passage out of the link:
> If the backquote syntax is nested, the innermost backquoted form should be expanded first. This means that if several commas occur in a row, the leftmost one belongs to the innermost backquote.
It's exactly the text of the ANSI Document.
So i've traced back the PSOD (Primary Source of Definition) until CLTL1.
ilias <·······@pontos.net> writes:
> thelifter wrote:
> > ilias <·······@pontos.net> wrote in message news:<············@usenet.otenet.gr>...
> >
> >>(defmacro abbrev (short long) ;
> >> `(defmacro ,short (&rest args)
> >> `(,',long ,@args))) ; noctice: ,',long
> >>
> > Hello,
> > I'm trying to understand this also, maybe this helps:
> > Believe it or not, but the above is equivalent to:
> > (defmacro abbrev (short long) `(defmacro ,short (&rest args)
> > (cons ',long args)))
> >
>
> I'm a lisp novice.
>
> And i must stay that for a long time.
>
> Undereducation gives me the strength to analyze abstract.
>
> And backquote is abstract.
>
> cons i don't know.
>
> and i don't have to know, to understand and analyze backquote.
Why is that so? I did not understand the backquote until I understood
`cons' and `list'.
That is just mw however.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
> ilias <·······@pontos.net> writes:
>
>
>>thelifter wrote:
>>
>>>ilias <·······@pontos.net> wrote in message news:<············@usenet.otenet.gr>...
>>>
>>>
>>>>(defmacro abbrev (short long) ;
>>>> `(defmacro ,short (&rest args)
>>>> `(,',long ,@args))) ; noctice: ,',long
>>>>
>>>
>>>Hello,
>>>I'm trying to understand this also, maybe this helps:
>>>Believe it or not, but the above is equivalent to:
>>>(defmacro abbrev (short long) `(defmacro ,short (&rest args)
>>> (cons ',long args)))
>>>
>>
>>I'm a lisp novice.
>>
>>And i must stay that for a long time.
>>
>>Undereducation gives me the strength to analyze abstract.
>>
>>And backquote is abstract.
>>
>>cons i don't know.
>>
>>and i don't have to know, to understand and analyze backquote.
>
>
> Why is that so? I did not understand the backquote until I understood
> `cons' and `list'.
We have simply a different learning/understanding-model.
I can understand only if i manage to decouple knowledge into small
independent. Otherwise i reject it.
I think a minimum knowledge of the reader is important here, but only
for a thorough understanding of the 'why's'.
However, i hope that i'am able to write an article so people can
understand backquote as this which it is: a simple but powerfull
construct for flexible code-generation.
Will see.
> That is just mw however.
>
> Cheers
>
>
ilias <·······@pontos.net> wrote in message > i try to analyze. this should be the source of confusion:
>
> http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
> [...] If the backquote syntax is nested, the innermost backquoted form
> should be expanded first. This means that if several commas occur in a
> row, the leftmost one belongs to the innermost backquote.[...]
>
> after sleep will be much clearer!!!
I suspect that this text is defective. The expansion of a backquote
expression only takes place when that backquote is evaluated. The only
way inner backquotes are evaluated at all is if evaluation is forced
with commas. Otherwise they are simply incorporated into the resulting
form.
Example:
`(a `(b `(c `(d ,,,,(+ 2 2)))))
==> (A `(B `(C `(D ,,,4))))
As you can see, the outer backquote disappears, leaving us with the
list (A ...). The inner backquote expressions are untouched, except
that the four commas in the row trigger evaluation and substitution of
(+ 2 2). If there were fewer then four commas, the evaluation would
not take place. In any case, it is the rightmost comma that
disappears, as if ,(+ 2 2) was replaced by 4.
Kaz Kylheku wrote:
> ilias <·······@pontos.net> wrote in message > i try to analyze. this should be the source of confusion:
>
>>http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
>>[...] If the backquote syntax is nested, the innermost backquoted form
>>should be expanded first. This means that if several commas occur in a
>>row, the leftmost one belongs to the innermost backquote.[...]
>>
>>after sleep will be much clearer!!!
>
>
> I suspect that this text is defective. The expansion of a backquote
yes, it seems.
there are cases in which macros are expanded fully, see below.
> expression only takes place when that backquote is evaluated. The only
> way inner backquotes are evaluated at all is if evaluation is forced
> with commas. Otherwise they are simply incorporated into the resulting
> form.
>
> Example:
>
> `(a `(b `(c `(d ,,,,(+ 2 2)))))
>
> ==> (A `(B `(C `(D ,,,4))))
you have a 'friendly' CL implementation. which is it?
Output LispWorks:
(A (SYSTEM::BQ-LIST (QUOTE B) (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST)
(QUOTE (QUOTE C)) (SYSTEM::BQ-LIST (QUOTE SYSTEM::BQ-LIST) (QUOTE (QUOTE
SYSTEM::BQ-LIST)) (QUOTE (QUOTE (QUOTE D))) 4))))
Output Allegro:
(A
(EXCL::BQ-LIST `B
(EXCL::BQ-LIST `EXCL::BQ-LIST ``C
(EXCL::BQ-LIST
`EXCL::BQ-LIST
``EXCL::BQ-LIST
```D
4))))
>
> As you can see, the outer backquote disappears, leaving us with the
> list (A ...). The inner backquote expressions are untouched, except
> that the four commas in the row trigger evaluation and substitution of
> (+ 2 2). If there were fewer then four commas, the evaluation would
> not take place. In any case, it is the rightmost comma that
> disappears, as if ,(+ 2 2) was replaced by 4.
yes, this fits with the results of the different macros 'abbrev' (see
#V0.7).
and this don't fits with the text of the specs.
>>http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
>>[...] If the backquote syntax is nested, the innermost backquoted form
>>should be expanded first. This means that if several commas occur in a
>>row, the leftmost one belongs to the innermost backquote.[...]
but i'd like to know, what the initial author meant by that and how it
relates exactly to my confusion.
i'll bring this to an end.
otherwise cannot find silence.
continuation of V0.8
Bugs in the specs.
I'll concentrate here to the paragraph of the specs and its influence to
my understanding-process.
The challenge of nested macros starts with the desaster of fighting
through the definitions.
i'm collapsing !!!
;;;; ------------------------------------------------------------
;;;; The Challenge of Nested Macros #V0.9 - ilias - 2002-09-17
;;;; ------------------------------------------------------------
--------------------------------------------------------------------
The standard-document states:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
=> "the *innermost* backquoted form *should be* expanded first"
=> " if several commas occur in a row, the *leftmost* comma belongs to
the *innermost* backquote"
Applying this definition to our abbrev-macro:
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,',long ,@args))) ;
(abbrev df defun)
=> innermost first, left commas first
`(defmacro ,short (&rest args)
(,long ,@args )))
^ .........this evaluates correctly (,',long => ,long
^... here we *would* get an error, as 'args' is not available.
It looks like the definition of backquote is wrong.
--------------------------------------------------------------------
Verifying with evaluations:
(macroexpand-1 '(abbrev df defun))
LispWorks:
=> (DEFMACRO DF (&REST ARGS) (SYSTEM::BQ-LIST* (QUOTE DEFUN) ARGS))
manual 'translation':
(DEFMACRO DF (&REST ARGS) `(,'DEFUN ,@ARGS))
Allegro:
=> (DEFMACRO DF (&REST ARGS) (EXCL::BQ-CONS 'DEFUN ARGS))
manual 'translation':
(DEFMACRO DF (&REST ARGS) `(,'DEFUN ,@ARGS))
We see in the processing of both implementations:
- The *outermost* backquoted form is processed first.
- The innermost backquoted form is processed partially by the outermost
backquote to evaluate the ,',long to ,'DEFUN.
This confirms: The definition of backquote is wrong.
--------------------------------------------------------------------
The clear human understanding (whatever this means, i'm writing now, so
i reduce complexity in my head):
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`(,',long ,@args))) ;
(abbrev df defun)
Imagine the backquote as an intelligent projectile (BIP), which is fired
over the code due to a call to abbrev.
(defmacro df (&rest args)
----------`--------------> continues next line
^here the BIP evaluates the target (comma) ,short to df
`(,',long ,@args)))
-`-`-`-----`--------
| | | ^here it ignores *one* again, as there is *one* BIP coming
| | ^here it evaluates ,long to defun
| ^here it ignores *one* tartget, as there is another *one* BIP coming
^here the BIP remembers that theres another *one* BIP to come later.
This confirms: The definition of backquote is wrong.
This confirms: Backquote-syntax has social behaviour.
The projectiles count 'how many projectiles will came next' and leave
exactly this no. of targets 'undestroyed', so the later fired
projectiles can hit them.
Notice that each symbol has its own targets.
--------------------------------------------------------------------
Suggested correction:
http://www.lispworks.com/reference/HyperSpec/Body/02_df.htm
"[...] If the backquote syntax is nested, the innermost backquoted form
should be expanded first. This means that if several commas occur in a
row, the leftmost one belongs to the innermost backquote.[...]"
should be corrected to:
If the backquote syntax is nested, the evaluation-process remains as
usual, from left-to-right, so the *outermost* backquoted form should be
expanded first. If several commas occur in a row, the leftmost one
belongs to the innermost backquote.
better: If serveral commas occur in a row, the innermost backquote would
...i cannot articulate.
i think the thing with the gun is clear.
and this is a 0.x document, so i'm free to be a little fuzzy.
--------------------------------------------------------------------
now i'm happy to delete all the rest.
all the confustion: *innermost* => *outermost*
--------------------------------------------------------------------
*please confirm* me the error in the standard-document.
really a desaster this is.
this small detail, placed in sub-conscious destroys all my
understanding-process.
I hope that nobody comes now and says: very fine all that, but you miss
a detail there.
when i write the final document, hopefully people can understand quicker
the nested-macro.
some ideas:
I've dropped the brackets.
This syntax would be easier i think:
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`( !,long ,@args))) ; ! = don't evaluate.
or better:
(defmacro abbrev (short long) ;
`(defmacro ,short (&rest args)
`( !,long ,·@args))) ; notice: ,·@args
you can recognize immediately in which pass the evaluation happens.
making the 'target'-count mandatory to fit with the backquote-level
gives possibility off error-detection.
i mean, backquote should signal an error, if only *one* comma is in the
second level. so you must place either , or ! - thus minimizing
possibilitie of error.
making e.g 5th level:
`( !!!,!eval-in-2nd-pass !,,,!eval-in-2-3-4-pass ,!!!!eval-in-last-pass)
`( ,!!!eval-in-5th-pass => would signal an error "5th level eval-marker
missing"
thus you correct to
`( ,!!!!eval-in-5th-pass
-
i hope you are not too tired due to my english.
the final document i'll process with spell-check.
does emacs have spell-check???