I'm working on my first LISP project of more than a couple dozen lines
and I'm confused about some behavior I'm seeing. I'm running clisp
2.29, if it matters.
[1]> (defun foo () (lambda () 'bar))
FOO
[2]> (foo)
#<CLOSURE :LAMBDA NIL 'BAR>
[3]> ((foo))
*** - EVAL: (FOO) is not a function name
Now, to explain why I wanted ((foo)) to equal 'bar...
I have a bunch of functions for generating data X, depending on input Y
and some other stuff. I want these functions to call function F with Y
and some additional parameters to generate function G, then use G to
generate data X.
A solution I see is to replace (G ...) with (apply G (list ...)). G is
called often, and this sucks. Another solution is to put the code for G
where it is called, this sucks even more. Another solution is to
refactor the code not to use G. This involves writing the most code of
all solutions, it sucks the most.
At this point, either:
1. I have hopelessly generalized the problem and someone should smack me
so I can give specifics.
2. I am missing something really obvious.
3. I am missing something not obvious.
4. I should be using interpreter / dialect X where functions and
variables share a namespace.
5. I should go back to using my own dialect / interpreter where
functions and variables share namespaces.
Dietrich Epp <········@zdome.net> writes:
> I'm working on my first LISP project of more than a couple dozen lines
> and I'm confused about some behavior I'm seeing. I'm running clisp
> 2.29, if it matters.
>
> [1]> (defun foo () (lambda () 'bar))
> FOO
> [2]> (foo)
> #<CLOSURE :LAMBDA NIL 'BAR>
> [3]> ((foo))
> *** - EVAL: (FOO) is not a function name
>
(funcall (foo))
> A solution I see is to replace (G ...) with (apply G (list ...)). G
> is called often, and this sucks.
No need to listify the arguments if you use FUNCALL instead of APPLY.
Dietrich Epp <········@zdome.net> wrote:
> [1]> (defun foo () (lambda () 'bar))
> FOO
> [2]> (foo)
> #<CLOSURE :LAMBDA NIL 'BAR>
> [3]> ((foo))
> *** - EVAL: (FOO) is not a function name
Short answer: Common Lisp is not Scheme. Try looking up FUNCALL and
APPLY in the docs.
> A solution I see is to replace (G ...) with (apply G (list ...)). G is
> called often, and this sucks.
I must be missing something obvious here. Why does it suck?
If you really want ((g) ...) to work like you expect, you can either:
* Get over it. ;-)
* Reader-macroize #\{ so that {(g) ..} => (funcall (g) ...).
* Check out <······························@news.netcologne.de> for a
more elaborate scheme.
> 4. I should be using interpreter / dialect X where functions and
> variables share a namespace.
It's not about namespaces, as Pascal Costanza notes in the article
referenced above: "Lisp-1 vs Lisp-2 is not what the fuzz is all about
- it is in fact just about a certain programming style that treats the
first positions in cons expressions specially."
I personally really prefer the (funcall (g)) style over ((g)). Why?
Because when things get any hairier than that I find the explicit
application more readable:
(foo (funcall (baz)) (funcall (funcall (quux))))
(foo ((baz)) (((quux))))
I don't know about the rest of the world, but the first one I can read
at a glance, and see that the second argument has two nested
applications. In the second version I have to stop and count the
parens.
This is especially true with other peoples code.
It may be that with sufficent exposure to the latter style you develop
an ability to "just see" it, but during my Scheme time I never did.
Cheers,
-- Nikodemus
Dietrich Epp wrote:
> I'm working on my first LISP project of more than a couple dozen lines
> and I'm confused about some behavior I'm seeing. I'm running clisp
> 2.29, if it matters.
>
> [1]> (defun foo () (lambda () 'bar))
> FOO
> [2]> (foo)
> #<CLOSURE :LAMBDA NIL 'BAR>
> [3]> ((foo))
> *** - EVAL: (FOO) is not a function name
>
> Now, to explain why I wanted ((foo)) to equal 'bar...
>
> I have a bunch of functions for generating data X, depending on input Y
> and some other stuff. I want these functions to call function F with Y
> and some additional parameters to generate function G, then use G to
> generate data X.
>
> A solution I see is to replace (G ...) with (apply G (list ...)). G is
> called often, and this sucks. Another solution is to put the code for G
> where it is called, this sucks even more. Another solution is to
> refactor the code not to use G. This involves writing the most code of
> all solutions, it sucks the most.
(funcall G ...) sucks less. ;)
> 4. I should be using interpreter / dialect X where functions and
> variables share a namespace.
Indeed, Common Lisp has different namespaces for forms in car and cdr
posititons respectively. This has both advantages and disadvantages.
(f f) takes the function available in the function namespace under the
name f and calls it, with the value stored in the value namespace under
the name f as a parameter.
funcall and function are the standard namespace-shifting functions.
(funcall form ...) takes the value to which form evaluates and treats it
as if it was taken from the function namespace. (i.e., calls it)
(function sym) takes the function available under the name sym and
treats it as if it was taken from the value namespace. (i.e., returns it
as a value)
> 5. I should go back to using my own dialect / interpreter where
> functions and variables share namespaces.
The other alternative is to use Scheme which has a single namespace for
both functions and values.
But please bear in mind that a single namespace is not generally the
better option. You should try to understand the trade-offs.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Dietrich Epp wrote:
> I'm working on my first LISP project of more than a couple dozen lines
> and I'm confused about some behavior I'm seeing. I'm running clisp
> 2.29, if it matters.
>
> [1]> (defun foo () (lambda () 'bar))
> FOO
> [2]> (foo)
> #<CLOSURE :LAMBDA NIL 'BAR>
> [3]> ((foo))
> *** - EVAL: (FOO) is not a function name
This is Scheme syntax. In CL you have to use funcall or apply:
(funcall (foo))
--
Ivan Toshkov
email: ··········@last-name.org
Dietrich Epp wrote:
> I'm working on my first LISP project of more than a couple dozen lines
> and I'm confused about some behavior I'm seeing. I'm running clisp
> 2.29, if it matters.
>
> [1]> (defun foo () (lambda () 'bar))
> FOO
> [2]> (foo)
> #<CLOSURE :LAMBDA NIL 'BAR>
> [3]> ((foo))
> *** - EVAL: (FOO) is not a function name
>
> Now, to explain why I wanted ((foo)) to equal 'bar...
>
> I have a bunch of functions for generating data X, depending on input Y
> and some other stuff. I want these functions to call function F with Y
> and some additional parameters to generate function G, then use G to
> generate data X.
>
> A solution I see is to replace (G ...) with (apply G (list ...)). G is
> called often, and this sucks. Another solution is to put the code for G
> where it is called, this sucks even more. Another solution is to
> refactor the code not to use G. This involves writing the most code of
> all solutions, it sucks the most.
>
> At this point, either:
>
> 1. I have hopelessly generalized the problem and someone should smack me
> so I can give specifics.
>
> 2. I am missing something really obvious.
>
> 3. I am missing something not obvious.
>
> 4. I should be using interpreter / dialect X where functions and
> variables share a namespace.
>
> 5. I should go back to using my own dialect / interpreter where
> functions and variables share namespaces.
Lessee:
(a) you know enough to identify ((foo)) not working as a namespace issue
(b) you have in fact written your own one-namespace interpreter
(c) you correctly identify apply as one alternative.
This in a "help the newbie" thread, in which you are shocked, shocked!,
to learn ((foo)) does not work? And finally:
(d) you use the word "suck" so much.
How about?:
6. You are a troll.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Thanks to all who replied, except Kenny who only insulted me, and didn't
even catch that I was saying 'sucks' tongue-in-cheek. I have been
working mostly out of Abelson and Sussman because I don't have any books
on Common Lisp, and the online documentation that I have found is all
either thick reference or light tutorial.
The reason I didn't want to use apply is because this generated function
is called upwards of twenty times in a function that is only a little
longer, and that's a lot of apply (or funcall. My solution was to learn
how macros work, then change all my (let ((f (genfunc ...))) to the macro.
The real reason I couldn't figure this out is not because I'm working
from a Scheme book, but because I'm still operating with a Haskell
mindset. I've caught myself trying to curry functions all over the
place. Again, thanks to all who gave me pointers. I think I can figure
the rest out.
Dietrich Epp <········@zdome.net> writes:
> Thanks to all who replied, except Kenny who only insulted me, and didn't even
> catch that I was saying 'sucks' tongue-in-cheek.
It certainly didn't seem to be tongue-in-cheek. You used sucks a lot, without
ever explaining why. You seemed to be complaining. Moreover, you used a
misleading subject line.
> I have been working mostly out of Abelson and Sussman because I don't have
> any books on Common Lisp, and the online documentation that I have found is
> all either thick reference or light tutorial.
That seems to be your first problem. Perhaps you should have started here,
asking for advice on a good reference for your needs, for the language you're
actually using.
> The reason I didn't want to use apply is because this generated function is
> called upwards of twenty times in a function that is only a little longer,
> and that's a lot of apply or funcall.
This statement is silly. What alternative do you have in mind? Apply and
funcall are merely syntactic markers in Common Lisp. Even if your desired
((FOO)) worked the way you want, how do you think it would be implemented at
the machine level? Answer: just the same way a compiled funcall is
implemented.
Now, if you had said that it was the consing of the LIST function when you use
APPLY that bothered you, people could have pointed out FUNCALL. And you should
be happy. But complaining about calling FUNCALL 20 times, when you would have
been happy with ((FOO)), seems kind of silly, doesn't it? What's the
difference?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I must have forgotten to explain why I didn't like funcall in this
situation... I'm not concerned about overhead. I don't care if the lisp
interpreter spawns another process for each cons. Look up the three
rules of optimization. The bottleneck in my code is the keyboard. It
matters I have to type funcall or apply 86 times in one function.
I worked out of Structure and Interpretation of Computer Programs
because I have it, and buying a book right now isn't an option. Thanks
to anyone who suggested a book, I'll look them up when I get the chance.
I'll look into flet maybe next time, I don't need to reimplement
something that works fine right now (the macro that calls defun).
Maybe I could have explained a little more about my program. Once it
was a small Python script that loaded lots of XML, then I started
embedding LISP in the XML, then I decided to rewrite it in LISP. Now
I'm content with the way it works, so I don't need anyone to tell me
that I don't have a clue (I already know that) or telling me I'm wrong
(so why am I on usenet?).
But this is a boring, dead thread and I am tempted to delete my email
account or at least never launch my newsreader again.
Dietrich Epp <········@zdome.net> writes:
> But this is a boring, dead thread and I am tempted to delete my email
> account or at least never launch my newsreader again.
Based on your attitude, I'd have to support that sentiment. (Although
deleting your email account would probably be an effort to hide under a
new identity later, so that may not be the most optimal result for the
rest of us.)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Dietrich Epp <········@zdome.net> writes:
> I must have forgotten to explain why I didn't like funcall in this
> situation... I'm not concerned about overhead. I don't care if the
> lisp interpreter spawns another process for each cons. Look up the
> three rules of optimization. The bottleneck in my code is the
> keyboard. It matters I have to type funcall or apply 86 times in one
> function.
Abstraction is great to avoid typing a lot. Macros and functions can
be used to factor out repetitive typing. I hardly type twice or
thrice the same pattern...
Look for example this nice with-funcalls macro:
;; From: Pascal Costanza <········@web.de>
;; Subject: Scheme-like expressions in CL
;; Newsgroups: comp.lang.lisp
;; Date: Fri, 06 Jun 2003 23:50:30 +0200
;; ...formerly, this was called the "Lisp-1 vs. Lisp-2" issue. However,
;; this code shows that Lisp-1 vs Lisp-2 is not what the fuzz is all about
;; - it is in fact just about a certain programming style that treats the
;; first positions in cons expressions specially. And you can get that in
;; CL as well without resorting to Lisp-1 semantics.
;; The following code has two parts:
;; - with-funcalls is a low-level macro that allows you to specify that
;; either conses in first positions are funcall'ed in its body, or symbols
;; from a specific set, or both. Here is how it goes:
;; (with-funcalls t (a b c)
;; ...)
;; The first parameter is a boolean flag that turns funcalls for conses on
;; or off; the second parameter is a list of symbols that are funcall'ed in
;; first positions; the rest is an implicit progn in which these settings
;; are switched on.
;; - letrec is the high-level access to with-funcalls. It switches funcall
;; treatment of conses on, and takes a list of function definitons (given
;; in Scheme style) and turns funcall treatment on for the symbols that are
;; defined as functions by that letrec form. Examples:
;; (letrec ((f (lambda (x) (+ x x))))
;; (list (f 5) (f 6) (f 7)))
;; => (10 12 14)
;; (letrec ((f (lambda (x) (lambda (y) (+ x y)))))
;; ((f 5) 6))
;; => 11
;; I have tested the code to a certain degree with Macintosh Common Lisp
;; 5.0. However, I can't guarantee that it is free of bugs. (Warning: Bugs
;; can be very annoying because I modify the macro expansion hook, and that
;; hook is usually used by the CL environment for all macros.)
;; Still, I am pretty sure by now that it this code is conceptually sound.
;; Thanks to Erann Gat, Kent Pitman and Dorai Sitaram for giving me the key
;; ideas.
;; Any kind of feedback is appreciated - especially with regard to the way
;; I pass information around between macro calls, because it's the first
;; time that I have done so.
;; Here is the code:
(defvar *original-macroexpand-hook* *macroexpand-hook*)
(setq *macroexpand-hook* *original-macroexpand-hook*)
(define-symbol-macro funcall-conses nil)
(define-symbol-macro funcall-symbols nil)
(defun with-funcalls-hook (expander form env)
(if (macro-function (car form) env)
(let ((result (funcall *original-macroexpand-hook* expander form
env))
(funcall-conses (macroexpand 'funcall-conses env))
(funcall-symbols (macroexpand 'funcall-symbols env)))
(if (or funcall-conses funcall-symbols)
(functify result funcall-conses funcall-symbols env)
result))
form)) ;;with-funcalls-hook
(defun functify (form conses symbols env)
(labels
((funky-form (form)
(if (consp form)
(cond
((symbolp (car form))
(cond
((member (car form) symbols)
`(funcall ,(car form) ,@(mapcar #'funky-form (cdr form))))
((eq 'declare (car form))
form)
((eq 'lambda (car form))
(funky-lambda form))
((special-operator-p (car form))
(funky-special form))
((macro-function (car form) env)
form)
(t `(,(car form) ,@(mapcar #'funky-form (cdr form))))))
((consp (car form))
(cond
((eq 'lambda (caar form))
`(,(funky-lambda (car form)) ,@(mapcar #'funky-form (cdr form))))
(conses
`(funcall ,@(mapcar #'funky-form form)))
(t form)))
(t form))
form))
(funky-lambda (lambda-form)
`(lambda ,(nth 1 lambda-form)
,@(mapcar #'funky-form (nthcdr 2 lambda-form))))
(funky-special (form)
(ccase (car form)
((block eval-when multiple-value-call return-from the)
(destructuring-bind
(op non-eval &rest forms) form
`(,op ,non-eval ,@(mapcar #'funky-form forms))))
((flet labels macrolet)
(destructuring-bind
(op defs &rest forms) form
`(,op ,(mapcar (lambda (def)
(destructuring-bind
(name args &rest forms) def
`(,name ,args ,@(mapcar #'funky-form forms))))
defs)
,@(mapcar #'funky-form forms))))
((go load-time-value quote) form)
((catch function if locally multiple-value-prog1 progn progv
tagbody throw unwind-protect)
(destructuring-bind
(op &rest forms) form
`(,op ,@(mapcar #'funky-form forms))))
((let let*)
(destructuring-bind
(op defs &rest forms) form
`(,op ,(mapcar (lambda (def)
(if (consp def)
`(,(car def) ,(funky-form (cadr def)))
def))
defs)
,@(mapcar #'funky-form forms))))
(setq
(destructuring-bind
(op &rest sets) form
`(,op ,@(let (switch)
(mapcar (lambda (elem)
(setf switch (not switch))
(if switch elem (funky-form elem)))
sets)))))
(symbol-macrolet
(destructuring-bind
(op defs &rest forms) form
`(,op ,(mapcar (lambda (def)
(destructuring-bind
(sym form) def
`(,sym ,(funky-form form))))
defs)
,@(mapcar #'funky-form forms)))))))
(funky-form form))) ;;functify
(defmacro with-funcalls (conses symbols &environment env &body body)
(assert (every (lambda (sym)
(and (not (special-operator-p sym))
(not (member sym '(declare lambda)))))
symbols))
`(let ,symbols
(symbol-macrolet (,(if conses '(funcall-conses t))
(funcall-symbols ,(append symbols (macroexpand
'funcall-symbols env))))
(macrolet ((trigger-with-funcalls (form) form))
(trigger-with-funcalls (progn ,@body)))))) ;;with-funcalls
(defmacro letrec (defs &body body)
`(with-funcalls t ,(mapcar (lambda (def) (if (consp def) (car def)
def)) defs)
,@(loop for def in defs
when (consp def) collect `(setf ,(car def) ,(cadr def)))
,@body)) ;;letrec
(setq *macroexpand-hook* #'with-funcalls-hook)
;;;; lisp1-in-cl.lisp -- 2003-06-07 07:46:25 -- pascal ;;;;
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Dietrich Epp wrote:
> I must have forgotten to explain why I didn't like funcall in this
> situation... I'm not concerned about overhead. I don't care if the lisp
> interpreter spawns another process for each cons. Look up the three
> rules of optimization. The bottleneck in my code is the keyboard. It
> matters I have to type funcall or apply 86 times in one function.
>
> I worked out of Structure and Interpretation of Computer Programs
> because I have it, and buying a book right now isn't an option. Thanks
> to anyone who suggested a book, I'll look them up when I get the chance.
a) Scheme and Common Lisp are sufficiently different that it's no
surprise that you run into problems like this. Imagine what would happen
if you tried to compile a Java program with a C++ compiler. The distance
between Scheme and Common Lisp is similar.
b) There are many excellent books on Common Lisp downloadable for free.
It's not so hard to dig them up. For a starter, try "On Lisp" by Paul
Graham. (http://www.paulgraham.com)
> I'll look into flet maybe next time, I don't need to reimplement
> something that works fine right now (the macro that calls defun).
You didn't know about flet?!? Hey, your problem is very likely much much
easier to solve than you think...
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
On 8593 day of my life Pascal Costanza wrote:
> b) There are many excellent books on Common Lisp downloadable for
> free. It's not so hard to dig them up. For a starter, try "On Lisp"
> by Paul Graham. (http://www.paulgraham.com)
Even Paul Graham doesn't think that this books is good for starters :)
--
Ivan Boldyrev
Is 'morning' a gerund?
Dietrich Epp <········@zdome.net> writes:
> Thanks to all who replied, except Kenny who only insulted me, and didn't
> even catch that I was saying 'sucks' tongue-in-cheek.
And you didn't even give any indication to that effect.
> I have been working mostly out of Abelson and Sussman because I don't
> have any books on Common Lisp, and the online documentation that I
> have found is all either thick reference or light tutorial.
Successful Lisp would have taught you this in Chapters 3 and 4.
Abelson and Sussman isn't really a great book for learning Scheme in any
case, from my experience. It's geared towards being something like the
PAIP for Scheme, except more theoretical (PAIP actually references SICP
for the reader who wants to see a simpler, less efficient implementation
of some of the projects).
If learning programming techniques in CL is your goal, PAIP is your
book, IMO. If learning CL itself is your goal, I think Successful Lisp
is a great way to become familiar with most of the language, but no book
really covers all the different bits and pieces in depth. After looking
at SL for the first time in a while, it looks like many of the chapters
have really been fleshed out, and maybe it's close to covering all of
the major parts of CL, but with just a rudimentary intro to
CLOS. Keene's CLOS book is ok for learning CLOS, but it's also a bit
rudimentary. AMOP is a wonderful book, not only for learning MOP, but
for learning about OO design using CLOS in general (as the MOP is the
primary). I've heard good things about Slade's OOCL book, but haven't
gotten a chance to see it. And of course, there's On Lisp for your
macro-edicfication. SL and the ALU have nice lists of books on CL that
you can peruse at your leisure.
Personally, my main sources of education about CL were this newsgroup
and the hyperspec. I guess the fundamentals of CL just sort of made
sense to me when I started learning it.
> The reason I didn't want to use apply is because this generated function
> is called upwards of twenty times in a function that is only a little
> longer, and that's a lot of apply (or funcall. My solution was to learn
> how macros work, then change all my (let ((f (genfunc ...))) to the
> macro.
You sure you want a macro and not a function (flet)? Unless you mean
something significant by 'generated', but I can't tell what that's
supposed to mean, other than that the function's body is generated by a
macro. If it's slightly different each time, and these differences can't
be encapsulated in a parameter to a function (e.g., they require control
over whether some parameter gets evaluated or not), then a macro would
be appropriate.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Dietrich Epp wrote:
> Thanks to all who replied, except Kenny who only insulted me, and didn't
> even catch that I was saying 'sucks' tongue-in-cheek.
Sounds like you can dish it out but you can't take it. That sucks.
:)
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application