Hi,
Background:
Inside of a macro definition we can work with a code, like we work
with lists. This feature is pretty powerful (when it is needed).
Question:
Where else code-as-lists is used in Common Lisp? Is it only used
inside of a macro definition?
Thanks in advance.
Mikalai wrote:
> Hi,
>
> Background:
> Inside of a macro definition we can work with a code, like we work
> with lists. This feature is pretty powerful (when it is needed).
>
> Question:
> Where else code-as-lists is used in Common Lisp? Is it only used
> inside of a macro definition?
You want me to search through my code and find all the uses of APPLY?
And &rest?
:)
And when I need to store a Cell, I can store (as a tree of symbols) the
code of the lambda form constituting the rule (the code being captured
by my rule-forming macros).
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Mikalai wrote:
> Hi,
>
> Background:
> Inside of a macro definition we can work with a code, like we work
> with lists. This feature is pretty powerful (when it is needed).
>
> Question:
> Where else code-as-lists is used in Common Lisp? Is it only used
> inside of a macro definition?
- when intepreting code (but less often), for example (eval '(+ 2 3))
- as part of the tool chain, for example in the development environment
which analyzes the s-expressions (which are lists and atoms) and
provides information about programs based on such analysis. Or even
simpler, as a basis for automatically indenting code.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Kent M Pitman
Subject: Re: Code as lists -- where is it used?
Date:
Message-ID: <upsg26c09.fsf@nhplace.com>
Pascal Costanza <··@p-cos.net> writes:
> Mikalai wrote:
> > Hi,
> > Background:
> > Inside of a macro definition we can work with a code, like we work
> > with lists. This feature is pretty powerful (when it is needed).
> > Question:
> > Where else code-as-lists is used in Common Lisp? Is it only used
> > inside of a macro definition?
>
> - when intepreting code (but less often), for example (eval '(+ 2 3))
>
> - as part of the tool chain, for example in the development
> environment which analyzes the s-expressions (which are lists and
> atoms) and provides information about programs based on such
> analysis. Or even simpler, as a basis for automatically indenting code.
Implicitly when doing printing and pretty printing in code.
In compiler optimizers.
In automatic programming, which constructs code for execution, not just
as Pascal has noted for EVAL, but you can also do:
(defun add-some-repeatedly (n)
(let ((add-some (compile nil `(lambda (x) (+ x ,(random n))))))
(mapcar add-some '(1 2 3 4))))
In practice, this facility is often used in data-driven rule generators
where you create a specialized language for rule-driven case recognizers
and the rest of the code for actually executing the rule is derived
automatically.
- - - -
But (you didn't think you'd get away without a quiz question at the end,
did you), the question is an odd one. How is this different than asking
a question like:
I note that integers are used to add up counts of things. What else are
they used for?
The reason I pose it this way is that the methodology for finding the
answer is the same--you look to all the operators -- or else to all the
domains that potentially can use those operators. In math, the answer
is that you can either start from the set of math operators and find
that there's really nothing you can't construct using 1's and 0's and
a bit of math... so how much of your program is mathematical is just
a choice of "style". Or similarly at the other end, you can ask what
programs can be broken down into math, and the answer comes out the same:
just about all of them.
Now back to programs as lists. Well, "programs as lists", since pretty
much all programs are lists, means just "programs". And so you're either
asking how many programs use programs, which is pretty much all, or you're
specifically asking "how many programs have to go meta"? Now that's a
question that is independent of the "list" issue and goes to simply the
question of how often either EVAL or COMPILE is used at runtime. The answers
there divide into probably a few specific categories:
- debugging (which is necessarily meta, because you couldn't debug programs
using programs without using programs that understand programs)
- language tools (which is necessarily meta, because you can't write a program
that manipulates programs in it without having both the program and the
programs it's manipulating--although you CAN write such a program without
using Lisp's list datatype -- you could make up your own. There's just
little advantage to that, so most people don't bother).
- AI systems that manipulate knowledge structures, which some would say are
just language tools in disguise.
This sounds like a short list, but it's a huge area. Sort of like saying
"well, the only place we use these things are when writing about things,
thinking about things, and trying to understand the things we think and
write". That's actually enough to fill several libraries.
I think you probably wanted to ask a better question, therefore, and then
maybe you'll get more interesting answers.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Code as lists -- where is it used?
Date:
Message-ID: <87wtaa7obt.fsf@qrnik.zagroda>
Kent M Pitman <······@nhplace.com> writes:
>> Or even simpler, as a basis for automatically indenting code.
>
> Implicitly when doing printing and pretty printing in code.
I'm afraid that indenting and pretty printing should preserve
comments, so it doesn't take advantage of sexpr syntax.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Kent M Pitman <······@nhplace.com> writes:
>
> >> Or even simpler, as a basis for automatically indenting code.
> >
> > Implicitly when doing printing and pretty printing in code.
>
> I'm afraid that indenting and pretty printing should preserve
> comments, so it doesn't take advantage of sexpr syntax.
Don't be silly; it can redefine the macro handlers for ";" and "#|" and
read the comments as objects. Obviously it needs to treat them
specially, but it simply isn't true that you can't both preserve
comments and parse sexprs.
>
> --
> __("< Marcin Kowalczyk
> \__/ ······@knm.org.pl
> ^^ http://qrnik.knm.org.pl/~qrczak/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Code as lists -- where is it used?
Date:
Message-ID: <87wtaatyvt.fsf@qrnik.zagroda>
"Nathan Baum" <···········@btinternet.com> writes:
>> I'm afraid that indenting and pretty printing should preserve
>> comments, so it doesn't take advantage of sexpr syntax.
>
> Don't be silly; it can redefine the macro handlers for ";" and "#|"
> and read the comments as objects.
And redefine ( so that (foo . #| bar |# baz) works, and redefine #.
so that reindentation doesn't have a side effect of inserting
the evaluated result, and redefine #+ and #- to avoid expanding
them prematurely, and redefine ` so the original syntax can be
reconstructed, and be prepared for custom reader macros.
Well, reimplementing the reader is of course doable, but then the
advantage of having the source language parser available in the
runtime is lost. This can be done for any syntax, sexprs offer no
advantage.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> "Nathan Baum" <···········@btinternet.com> writes:
>
> >> I'm afraid that indenting and pretty printing should preserve
> >> comments, so it doesn't take advantage of sexpr syntax.
> >
> > Don't be silly; it can redefine the macro handlers for ";" and "#|"
> > and read the comments as objects.
>
> And redefine ( so that (foo . #| bar |# baz) works, and redefine #.
> so that reindentation doesn't have a side effect of inserting
> the evaluated result, and redefine #+ and #- to avoid expanding
> them prematurely, and redefine ` so the original syntax can be
> reconstructed
You say that like it'd be amazingly hard to do. Compared to the task of
actually performing the indentation, it'd be trivial.
> and be prepared for custom reader macros.
That's obviously impossible. But then although the indenter can't read
custom syntax, it can't indent it either (how would it know how to?).
So the programmer shouldn't be expecting his editor to automatically
indent custom syntax, unless his implementation supports features for
specifying how to indent custom syntax.
> Well, reimplementing the reader is of course doable, but then the
> advantage of having the source language parser available in the
> runtime is lost.
It is of course not reimplementing the reader, but reimplementing a few
features of the reader.
> This can be done for any syntax, sexprs offer no
> advantage.
You seem to be moving the goalposts. The question wasn't "what's the
advantage of using sexprs", the question was, "when is code used as
data?" One answer is "when indenting/pretty printing." The mere fact
that you can't use the standard reader to do so doesn't magically mean
that an indenter doesn't use code as data.
>
> --
> __("< Marcin Kowalczyk
> \__/ ······@knm.org.pl
> ^^ http://qrnik.knm.org.pl/~qrczak/
From: Kent M Pitman
Subject: Re: Code as lists -- where is it used?
Date:
Message-ID: <ubqrmr3j8.fsf@nhplace.com>
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> "Nathan Baum" <···········@btinternet.com> writes:
>
> >> I'm afraid that indenting and pretty printing should preserve
> >> comments, so it doesn't take advantage of sexpr syntax.
Nonsense. Your use of "should" is a subjective judgement, not a law of
the universe.
A great many syntax processors for a great many languages discard comments
because they are inherently problematic to keep track of in the result.
The very nature of Lisp and its INTERN operation is that the result of
a parse must return EQ-ified items for different places in the code.
To do this and to also preserve comments would make no sense, since
the fact that identity is merged would create an inherent ambiguity.
To hold this particular one design goal (of many possible) constant as
if it were immovable, and to not consider the power that has come to the
language by the choice that was made is naive, at best.
Note well: I'm not trying to take a position on the design of CL being
uniquely good. I'm just saying that it's "defensible" and "not an accident"
and even "useful". And a proper analysis does not simply begin with a
"non goal" and work back to the notion that the feature is a failure
without examining why the decision is there.
> > Don't be silly; it can redefine the macro handlers for ";" and "#|"
> > and read the comments as objects.
>
> And redefine ( so that (foo . #| bar |# baz) works, and redefine #.
> so that reindentation doesn't have a side effect of inserting
> the evaluated result, and redefine #+ and #- to avoid expanding
> them prematurely, and redefine ` so the original syntax can be
> reconstructed, and be prepared for custom reader macros.
>
> Well, reimplementing the reader is of course doable, but then the
> advantage of having the source language parser available in the
> runtime is lost. This can be done for any syntax, sexprs offer no
> advantage.
That's true of most programming languages.
It's an engineering trade-off. Had it been a stumbling block, it would
have been fixed ages ago. (In fact, in Maclisp, the pretty printer,
called the "grinder", could handle comments ... the reason it had the
nickname "grinder", I believe, was that it was often like putting your
code through a meat grinder, and it created lots of problems. So we
moved away from caring...)
As always, I encourage people who don't like our engineering choices to
have a good time with the languages whose engineering design choices they
like. CL cannot be all things to all people.
I also welcome a healthy debate about what we should and shouldn't have,
and why. But I don't recognize as "healthy" any debate that just begins
by whining and by omitting material facts and then reaches conclusions
out of context of a legitimate understanding of what's going on.
I've said many times: "Right" and "Wrong" have meaning only within a
context--they are not fundamental immovable things. If you don't do the
work to set up the context, then don't be asserting "wrongness" unless
you just find it fun to provoke a religious war.
Marcin 'Qrczak' Kowalczyk wrote:
> "Nathan Baum" <···········@btinternet.com> writes:
>
> >> I'm afraid that indenting and pretty printing should preserve
> >> comments, so it doesn't take advantage of sexpr syntax.
> >
> > Don't be silly; it can redefine the macro handlers for ";" and "#|"
> > and read the comments as objects.
>
> And redefine ( so that (foo . #| bar |# baz) works, and redefine #.
> so that reindentation doesn't have a side effect of inserting
> the evaluated result, and redefine #+ and #- to avoid expanding
> them prematurely, and redefine ` so the original syntax can be
> reconstructed, and be prepared for custom reader macros.
>
> Well, reimplementing the reader is of course doable, but then the
> advantage of having the source language parser available in the
> runtime is lost. This can be done for any syntax, sexprs offer no
> advantage.
I'm pretty sure someone on c.l.l showed some code that would do this
sometime in the recent past. If someone has then it would be useful if
they could link to it because I can't remember the context of the
thread.
"Rob Thorpe" <·············@antenova.com> writes:
> Marcin 'Qrczak' Kowalczyk wrote:
> > "Nathan Baum" <···········@btinternet.com> writes:
> > > > I'm afraid that indenting and pretty printing should preserve
> > > > comments, so it doesn't take advantage of sexpr syntax.
> > > Don't be silly; it can redefine the macro handlers for ";" and
> > > "#|" and read the comments as objects.
> > And redefine ( so that (foo . #| bar |# baz) works, and redefine
> > #. so that reindentation doesn't have a side effect of inserting
> > the evaluated result, and redefine #+ and #- to avoid expanding
> > them prematurely, and redefine ` so the original syntax can be
> > reconstructed, and be prepared for custom reader macros.
> I'm pretty sure someone on c.l.l showed some code that would do this
> sometime in the recent past. If someone has then it would be useful if
> they could link to it because I can't remember the context of the
> thread.
You may be thinking about discussions about Interlisp and "structured
source code":
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/e22518570a27c7b9/1b28eb0e52baf2e3?#1b28eb0e52baf2e3
No solution was put forward at that time.
Lars Brinkhoff <·········@nocrew.org> writes:
> "Rob Thorpe" <·············@antenova.com> writes:
> > Marcin 'Qrczak' Kowalczyk wrote:
> > > "Nathan Baum" <···········@btinternet.com> writes:
> > > > > I'm afraid that indenting and pretty printing should
> > > > > preserve comments, so it doesn't take advantage of sexpr
> > > > > syntax.
> > > > Don't be silly; it can redefine the macro handlers for ";" and
> > > > "#|" and read the comments as objects.
> > > And redefine ( so that (foo . #| bar |# baz) works, and redefine
> > > #. so that reindentation doesn't have a side effect of
> > > inserting the evaluated result, and redefine #+ and #- to avoid
> > > expanding them prematurely, and redefine ` so the original
> > > syntax can be reconstructed, and be prepared for custom reader
> > > macros.
> > I'm pretty sure someone on c.l.l showed some code that would do
> > this sometime in the recent past. If someone has then it would be
> > useful if they could link to it because I can't remember the
> > context of the thread.
> You may be thinking about discussions about Interlisp and "structured
> source code":
> http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/e22518570a27c7b9/1b28eb0e52baf2e3?#1b28eb0e52baf2e3
I thought about it some more, and now have a prototype that can read
sexps and retain the text at the same time. It handles most of the
issues mentioned above, I think.
Lars Brinkhoff wrote:
> Lars Brinkhoff <·········@nocrew.org> writes:
> > "Rob Thorpe" <·············@antenova.com> writes:
> > > Marcin 'Qrczak' Kowalczyk wrote:
> > > > "Nathan Baum" <···········@btinternet.com> writes:
<snip>
> > You may be thinking about discussions about Interlisp and "structured
> > source code":
> > http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/e22518570a27c7b9/1b28eb0e52baf2e3?#1b28eb0e52baf2e3
>
> I thought about it some more, and now have a prototype that can read
> sexps and retain the text at the same time. It handles most of the
> issues mentioned above, I think.
Clever.
Thank you for the points. I'll summarize:
a) eval
b) functions that can be called be macros, so in function definitions
as well
As for why do I ask this question. I am thinking of a way of putting
macros into Python (have to choose a particular Python implementation,
so that I do not have to code in C :) ), without (!!!) changing much
stuff.
The idea is that inside of a macro definition you actually put code in
list-like structure (think of code not as about words, but as AST). At
the return of macro, this list-like strucutre is converted into native
AST, fed into whatever, etc. Idea is that an extra layer is created for
a lisp-like way of code manipulation.
A simple macro system might be created without code-like-list thingy.
But this will give only something like Ruby's blocks, which will be
limiting for some advanced uses.
So, taking into consideration all of your points, there has to be,
first, a backquote syntax, which will produce a code-object,
addressable as a list. Elements in it will be other code-objects or
simple atoms. In this way, there will be an entire code tree in a
lisp-like form. Secondly, there should be a macro definition, which
returns a code-object, which is automagically turns into
python-(byte-?)code. Third, interpreter will have to distinguish
between macros and other funcs, turning to appropriate handling. Forth,
eval should be able to handle code-object.
If you have a constructive comment about the plan, I'd love to hear it.
Mikalai wrote:
>
> If you have a constructive comment about the plan, I'd love to hear it.
>
Check out Jonathan Bachrach's work on "Dylan Procedural Macros" and
"Java Syntactic Extender". Also, Laurence Tratt is working on a
Python-like language with macros.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Prickle-Prickle, Confusion 53, 3172 YOLD, Mikalai wrote:
> As for why do I ask this question. I am thinking of a way of putting
> macros into Python (have to choose a particular Python implementation,
> so that I do not have to code in C :) ), without (!!!) changing much
> stuff.
When I last tracked Python world (which was about year ago, maybe
more) there were rumors about adding DOM-like access to code (directly
to parse trees) in order to support macro functionality. Hasn't this
been done/started?
--
-><- This signature intentionally left blank. -><-
Le Tue, 18 Jul 2006 12:43:17 -0700, Mikalai a écrit :
> As for why do I ask this question. I am thinking of a way of putting
> macros into Python (have to choose a particular Python implementation,
> so that I do not have to code in C :) ), without (!!!) changing much
> stuff.
You could take a look at Perl6. They have decided to implement macros,
inspired mostly by the Lisp way, it seems. Of course, as they lack
sexprs, the macros will have to work either on the AST or tu return code
as a string.
Alternatively,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A