OK, I've read Paul Graham's "Hackers & Painters" and I'm intrigued by
Lisp. I'm currently an Access/VB programmer who feels stifled and would
like to branch out.
Paul's site lists several dozen Lisp implementations, of which several
look like they run natively on Windows:
* newLisp
* MIT Scheme / Chez Scheme
* Larceny
* Corman Lisp
* EdScheme / PLT Scheme (learning oriented?)
Beyond learning, I'm interested in working with databases, and trying
to explore web services.
Do any of you have suggestions or experience with any of these
implementations, or are there others I should look at?
Thanks,
-Ken
From: Edi Weitz
Subject: Re: Suggestions for Beginner's Lisp?
Date:
Message-ID: <ubrbu5len.fsf@agharta.de>
On 12 Jan 2005 13:54:50 -0800, "Ken Ismert" <·······@texassystems.com> wrote:
> OK, I've read Paul Graham's "Hackers & Painters" and I'm intrigued
> by Lisp. I'm currently an Access/VB programmer who feels stifled and
> would like to branch out.
>
> Paul's site lists several dozen Lisp implementations, of which several
> look like they run natively on Windows:
> * newLisp
> * MIT Scheme / Chez Scheme
> * Larceny
> * Corman Lisp
> * EdScheme / PLT Scheme (learning oriented?)
>
> Beyond learning, I'm interested in working with databases, and
> trying to explore web services.
>
> Do any of you have suggestions or experience with any of these
> implementations, or are there others I should look at?
For Windows get the trial version of LispWorks if you want to learn
Common Lisp. And note that your list above mixes several different
programming languages, namely Common Lisp, Scheme, and "newLisp." See
<http://groups-beta.google.com/group/comp.lang.lisp/msg/3861fb62a1f7d9c2>
and the rest of the thread for more info.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
As Paul says on his site, "if you want to start learning Lisp, it
doesn't matter which [Scheme or Common Lisp] you choose." If you
decide to start with Scheme, I strongly recommend DrScheme
(http://www.drscheme.org/), which is very user-friendly and is
cross-platform to boot (I mainly use it under Linux, but I've used it a
bit under Windows and it's basically the same). You should also check
out How To Design Programs (http://www.htdp.org/) or, if that proves
too easy/slow, try Structure and Interpretation of Computer Programs
(SICP = 'sick-pee')
(http://mitpress.mit.edu/sicp/full-text/book/book.html). The entire
text of both books is available online (though I've never regretted
coughing up the dough to buy a hard copy of SICP).
Michael
······@post.harvard.edu wrote:
> As Paul says on his site, "if you want to start learning Lisp, it
> doesn't matter which [Scheme or Common Lisp] you choose."
I personally regret learning Scheme first. The way it is taught in
SICP, Little/Seasoned Schemer, etc, is in a highly function-oriented
manner, with only vague convenience in operating on code. (You know,
"code-is-data.")
Dr. Scheme's IDE is very good. But despite that, I ended up preferring
Python. I took a further foolhardy risk on Common Lisp, which actually
did pay off quite well.
Scheme is very worthwhile on its own, but there are a million
worthwhile things. And of course, it may fit the contours of other
people's minds in a way it doesn't with mine. It seems textbook Scheme
is a very different beast from what Scheme could become.
MfG,
Tayssir
On Wed, 12 Jan 2005 20:56:23 -0800, Tayssir John Gabbour wrote:
> ······@post.harvard.edu wrote:
>> As Paul says on his site, "if you want to start learning Lisp, it
>> doesn't matter which [Scheme or Common Lisp] you choose."
>
> I personally regret learning Scheme first. The way it is taught in
> SICP, Little/Seasoned Schemer, etc, is in a highly function-oriented
> manner, with only vague convenience in operating on code. (You know,
> "code-is-data.")
FWIW I don't regret learning Scheme first at all. SICP was a real
eye-opener for me, and there is still one thing I do miss from Scheme when
I'm working in Common Lisp: consistent naming of functions. I can
never remember which of REMOVE or DELETE is destructive, for example.
Having said that though, I don't regret having now moved on from Scheme to
Common Lisp.
Cheers,
Bill.
William Bland <·······@abstractnonsense.com> writes:
> FWIW I don't regret learning Scheme first at all. SICP was a real
> eye-opener for me, and there is still one thing I do miss from Scheme when
> I'm working in Common Lisp: consistent naming of functions. I can
> never remember which of REMOVE or DELETE is destructive, for example.
If it was really that important, by now you'd have written a trivial
package CONSISTENT-CL (and I hope would have published under a freedom
license). Then you'd only have to write: (defpackage :x (:use
:consistent-cl)) instead of (defpackage :x (:use :common-lisp)) and
forget about delete and remove.
(defpackage "CONSISTENT-COMMON-LISP"
(:nickname "CONSISTENT-CL")
(:use "COMMON-LISP")
(:export "NDELETE" "DELETE" #|...976 consistent symbols...|#))
(in-package "CONSISTENT-COMMON-LISP")
(setf (symbol-function 'ndelete) (symbol-function 'remove))
;; ...
;; (use define-symbol-macro to rename variables
;; and defmacro to rename special operators).
> Having said that though, I don't regret having now moved on from Scheme to
> Common Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
Pascal Bourguignon wrote:
> If it was really that important, by now you'd have written a trivial
> package CONSISTENT-CL (and I hope would have published under a freedom
> license). Then you'd only have to write: (defpackage :x (:use
> :consistent-cl)) instead of (defpackage :x (:use :common-lisp)) and
> forget about delete and remove.
>
>
> (defpackage "CONSISTENT-COMMON-LISP"
> (:nickname "CONSISTENT-CL")
> (:use "COMMON-LISP")
> (:export "NDELETE" "DELETE" #|...976 consistent symbols...|#))
> (in-package "CONSISTENT-COMMON-LISP")
> (setf (symbol-function 'ndelete) (symbol-function 'remove))
> ;; ...
> ;; (use define-symbol-macro to rename variables
> ;; and defmacro to rename special operators).
>
Actually, that would be kind of _inconsistent_ since DELETE is the
destructive cousin of REMOVE... :)
David Sletten <·····@slytobias.com> writes:
> Pascal Bourguignon wrote:
>
>
> > If it was really that important, by now you'd have written a trivial
> > package CONSISTENT-CL (and I hope would have published under a freedom
> > license). Then you'd only have to write: (defpackage :x (:use
> > :consistent-cl)) instead of (defpackage :x (:use :common-lisp)) and
> > forget about delete and remove.
> > (defpackage "CONSISTENT-COMMON-LISP"
> > (:nickname "CONSISTENT-CL")
> > (:use "COMMON-LISP")
> > (:export "NDELETE" "DELETE" #|...976 consistent symbols...|#))
> > (in-package "CONSISTENT-COMMON-LISP")
> > (setf (symbol-function 'ndelete) (symbol-function 'remove))
> > ;; ...
> > ;; (use define-symbol-macro to rename variables ;; and defmacro to
> > rename special operators).
> >
> Actually, that would be kind of _inconsistent_ since DELETE is the
> destructive cousin of REMOVE... :)
Yes, that's why the Non destructive version of DELETE is REMOVE.
N DELETE := REMOVE
NDELETE := REMOVE
(to stay consistent with COMMON-LISP).
But you could as well write a SCHEMY-CL package with:
REMOVE! instead of CL:DELETE,
INTERSECTION instead of CL:NINTERSECTION and
INTERSECTION! instead of CL:INTERSECTION.
But that would be more confusing I guess...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal Bourguignon wrote:
> David Sletten <·····@slytobias.com> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>
>>
>>>If it was really that important, by now you'd have written a trivial
>>>package CONSISTENT-CL (and I hope would have published under a freedom
>>>license). Then you'd only have to write: (defpackage :x (:use
>>>:consistent-cl)) instead of (defpackage :x (:use :common-lisp)) and
>>>forget about delete and remove.
>>>(defpackage "CONSISTENT-COMMON-LISP"
>>> (:nickname "CONSISTENT-CL")
>>> (:use "COMMON-LISP")
>>> (:export "NDELETE" "DELETE" #|...976 consistent symbols...|#))
>>>(in-package "CONSISTENT-COMMON-LISP")
>>>(setf (symbol-function 'ndelete) (symbol-function 'remove))
>>>;; ...
>>>;; (use define-symbol-macro to rename variables ;; and defmacro to
>>>rename special operators).
>>>
>>
>>Actually, that would be kind of _inconsistent_ since DELETE is the
>>destructive cousin of REMOVE... :)
>
>
> Yes, that's why the Non destructive version of DELETE is REMOVE.
> N DELETE := REMOVE
> NDELETE := REMOVE
> (to stay consistent with COMMON-LISP).
>
My point was that the pseudo-convention in Common Lisp is to name
destructive operators by sticking "n" in front of the name for the
non-destructive version:
(append) -> nconc
subst -> nsubst
reverse -> nreverse
string-upcase -> nstring-upcase
etc...
But
remove -> delete
Thus for consistency:
remove -> nremove
(not ndelete <- delete)
David Sletten <·····@slytobias.com> writes:
> Pascal Bourguignon wrote:
> >>>(defpackage "CONSISTENT-COMMON-LISP"
> >>> (:nickname "CONSISTENT-CL")
> >>> (:use "COMMON-LISP")
> >>> (:export "NDELETE" "DELETE" #|...976 consistent symbols...|#))
> >>>(in-package "CONSISTENT-COMMON-LISP")
> My point was that the pseudo-convention in Common Lisp is to name
> destructive operators by sticking "n" in front of the name for the
> non-destructive version:
> (append) -> nconc
> subst -> nsubst
> reverse -> nreverse
> string-upcase -> nstring-upcase
> etc...
>
> But
> remove -> delete
>
> Thus for consistency:
> remove -> nremove
> (not ndelete <- delete)
Yes. I was wrong. Let's make it:
(setf (symbol-function 'nremove) (symbol-function 'delete))
(export '(nremove remove))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
From: Edi Weitz
Subject: Re: Suggestions for Beginner's Lisp?
Date:
Message-ID: <uoeftvhh7.fsf@agharta.de>
On 13 Jan 2005 09:31:39 +0100, Pascal Bourguignon <····@mouse-potato.com> wrote:
> David Sletten <·····@slytobias.com> writes:
>
>> Actually, that would be kind of _inconsistent_ since DELETE is the
>> destructive cousin of REMOVE... :)
>
> Yes, that's why the Non destructive version of DELETE is REMOVE.
> N DELETE := REMOVE
> NDELETE := REMOVE
> (to stay consistent with COMMON-LISP).
In case you haven't noticed yet, in Common Lisp the /destructive/
functions usually start with N - NSUBLIS, NSUBST, NCONC,
NINTERSECTION, NSET-DIFFERENCE, NSET-EXCLUSIVE-OR, NUNION, NBUTLAST,
NREVERSE, NSUBSTITUTE, ...
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On 13 Jan 2005 09:31:39 +0100, Pascal Bourguignon <····@mouse-potato.com> wrote:
>
> > David Sletten <·····@slytobias.com> writes:
> >
> >> Actually, that would be kind of _inconsistent_ since DELETE is the
> >> destructive cousin of REMOVE... :)
> >
> > Yes, that's why the Non destructive version of DELETE is REMOVE.
> > N DELETE := REMOVE
> > NDELETE := REMOVE
> > (to stay consistent with COMMON-LISP).
>
> In case you haven't noticed yet, in Common Lisp the /destructive/
> functions usually start with N - NSUBLIS, NSUBST, NCONC,
> NINTERSECTION, NSET-DIFFERENCE, NSET-EXCLUSIVE-OR, NUNION, NBUTLAST,
> NREVERSE, NSUBSTITUTE, ...
Oops, indeed.
So the N stands for Non-Consing, not for Non-Destructive...
Now I should check all my lisp code since I don't remember when this
bit flipped in my brain.
After all, perhaps it's good to have DELETE/REMOVE instead of
NREMOVE/REMOVE then, at least I knew that DELETE was DEstructive.
Thanks.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Pascal Bourguignon wrote:
>
> So the N stands for Non-Consing, not for Non-Destructive...
>
>
I imagine that must originally have been the case. But the convention
appears to be broader now with NSTRING-CAPITALIZE, NSTRING-UPCASE,
etc... included since strings aren't CONSes.
From: Edi Weitz
Subject: Re: Suggestions for Beginner's Lisp?
Date:
Message-ID: <upt09fcjk.fsf@agharta.de>
On Thu, 13 Jan 2005 17:33:25 GMT, David Sletten <·····@slytobias.com> wrote:
> Pascal Bourguignon wrote:
>
>> So the N stands for Non-Consing, not for Non-Destructive...
>>
> I imagine that must originally have been the case. But the
> convention appears to be broader now with NSTRING-CAPITALIZE,
> NSTRING-UPCASE, etc... included since strings aren't CONSes.
From the CLHS glossary:
"cons n.v. [...] 3. v. Idiom. to create any object, or to allocate
storage."
So to cons doesn't necessary mean to create CONSes.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Thu, 13 Jan 2005 17:33:25 GMT, David Sletten <·····@slytobias.com> wrote:
>
>
>>Pascal Bourguignon wrote:
>>
>>
>>>So the N stands for Non-Consing, not for Non-Destructive...
>>>
>>
>>I imagine that must originally have been the case. But the
>>convention appears to be broader now with NSTRING-CAPITALIZE,
>>NSTRING-UPCASE, etc... included since strings aren't CONSes.
>
>
> From the CLHS glossary:
>
> "cons n.v. [...] 3. v. Idiom. to create any object, or to allocate
> storage."
>
> So to cons doesn't necessary mean to create CONSes.
>
> Edi.
>
OK, so it's _that_ idea which has been broadened. Thanks for the tip.
David Sletten
Pascal Bourguignon <····@mouse-potato.com> writes:
> William Bland <·······@abstractnonsense.com> writes:
> > FWIW I don't regret learning Scheme first at all. SICP was a real
> > eye-opener for me, and there is still one thing I do miss from Scheme when
> > I'm working in Common Lisp: consistent naming of functions. I can
> > never remember which of REMOVE or DELETE is destructive, for example.
>
> If it was really that important, by now you'd have written a trivial
> package CONSISTENT-CL (and I hope would have published under a freedom
> license). Then you'd only have to write: (defpackage :x (:use
> :consistent-cl)) instead of (defpackage :x (:use :common-lisp)) and
> forget about delete and remove.
This approach breaks as soon as you read other people's code. Or a
book. Or a spec. Or you talk to somebody. Or ask a question somewhere.
Redefining standard names just for the sake of the redefinition is
almost always a bad idea. A relatively consistent naming scheme can
be cute, but it has to be built into the language and/or be followed
by the community of it's users.
Matthias <··@spam.pls> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
> > William Bland <·······@abstractnonsense.com> writes:
> > > FWIW I don't regret learning Scheme first at all. SICP was a real
> > > eye-opener for me, and there is still one thing I do miss from Scheme when
> > > I'm working in Common Lisp: consistent naming of functions. I can
> > > never remember which of REMOVE or DELETE is destructive, for example.
> >
> > If it was really that important, by now you'd have written a trivial
> > package CONSISTENT-CL (and I hope would have published under a freedom
> > license). Then you'd only have to write: (defpackage :x (:use
> > :consistent-cl)) instead of (defpackage :x (:use :common-lisp)) and
> > forget about delete and remove.
>
> This approach breaks as soon as you read other people's code. Or a
> book. Or a spec. Or you talk to somebody. Or ask a question somewhere.
>
> Redefining standard names just for the sake of the redefinition is
> almost always a bad idea. A relatively consistent naming scheme can
> be cute, but it has to be built into the language and/or be followed
> by the community of it's users.
Of course, but I'd say it depends on the size and independance of the
project at hand. If you're going to write a 2 MLoC embedded
application down to device drivers, it might be worthwhile to
establish a naming scheme to avoid silly errors.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> I personally regret learning Scheme first. The way it is taught in
> SICP, Little/Seasoned Schemer, etc, is in a highly function-oriented
> manner, with only vague convenience in operating on code. (You know,
> "code-is-data.")
PAIP would be the book that you wished you started with, then, followed
by On Lisp.
Getting deep into macros involves first learning the language, so that
you have something worth macroizing. PAIP does get to that point really
quickly, though.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
I personally find Lisp more gratifying than Scheme, just because you
can do everything in Lisp that you can in Scheme (as far as I know),
however, Lisp is more challenging to learn ecpessially if you coming
from a crappy language like VB. For the small amount of windows
programming I've done in the past, I liked Allegro CL (www.franz.com)
which is in a 60 day (renewable) trail version, or you can spit out the
$99 for it if you really want.
Better yet, jsut move to Linux and start using CMUCL or SBCL :)
--
Certum quod factum.
Philip Haddad
All,
Thanks for the input. Since my goals have a practical side to them, I
leaning towards a Common Lisp implementation. Allegro or LispWorks seem
like good suggestions. I'm still looking at Clisp (SBCL too, if the
Windows port progresses). If I can find the pieces to go along with a
free solution (text editor, IDE, forms toolkit, ODBC, etc) it may be
the way to go. I'd eventually like to move to Linux or a BSD, but one
step at a time.
Fellow newbies -- check:
http://alu.cliki.net/index
http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html
http://www.cliki.net/index
> ...a crappy language like VB...
Crappy?!? We VBers like to think of our language as having an 'earthy
barn aroma' ;-)
-Ken
lol. see even VB programmers admit it ;)
--
Certum quod factum.
Philip Haddad
From: Edi Weitz
Subject: Re: Suggestions for Beginner's Lisp?
Date:
Message-ID: <ufz15c5gu.fsf@agharta.de>
On 13 Jan 2005 14:31:11 -0800, "Ken Ismert" <·······@texassystems.com> wrote:
> If I can find the pieces to go along with a free solution (text
> editor, IDE, forms toolkit, ODBC, etc) it may be the way to go.
For a free editor and IDE check out the Emacs/SLIME combo, see
<http://common-lisp.net/project/slime/>.
That should work with CLISP on Windows. Ask on the SLIME mailing list
if you have problems.
For Windows forms and ODBC you might want to play with my RDNZL
library, see
<http://weitz.de/rdnzl/>.
This'll enable you to interact with .NET. Unfortunately, the CLISP
port isn't complete yet but maybe you can bother the CLISP gurus to
help you out... :)
Good luck,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Ken Ismert" <·······@texassystems.com> writes:
> All,
>
> Thanks for the input. Since my goals have a practical side to them, I
> leaning towards a Common Lisp implementation. Allegro or LispWorks seem
> like good suggestions. I'm still looking at Clisp (SBCL too, if the
> Windows port progresses). If I can find the pieces to go along with a
> free solution (text editor, IDE, forms toolkit, ODBC, etc) it may be
> the way to go. I'd eventually like to move to Linux or a BSD, but one
> step at a time.
>
> Fellow newbies -- check:
> http://alu.cliki.net/index
> http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html
> http://www.cliki.net/index
On MS-Windows you have VisualCLisp for clisp which is reported to work well.
http://ciapek.uci.agh.edu.pl/~kwlodarc/VisualCLisp/en.htm
--
__Pascal_Bourguignon__ . * . .*
http://www.informatimago.com/ * . . /\ ( . . *
. . / .\ . * .
.*. / * \ . .
. /* o \ .
* '''||''' .
******************
OK, I've bookmarked a lot of stuff, and will be studying it for the
next few days.
Some final thoughts:
Two things really grabbed me about Lisp:
* Paul Graham's statement about using it to get around the
statelessness of a web session. I am naive about web programming, but I
know that this is a profound problem. ASP.NET has a solution to this,
but it strikes me as ugly.
* Pascal Costanza's comment about aspect-oriented programming under
Lisp and MOP. I read an article about AspectJ in a Linux journal, and
while I didn't fully understand it, it was easy to grasp how much
effort it could save, compared to standard VB development. Microsoft,
as far as I know, hasn't even explored the idea - they wouldn't
know an aspect if it bit them on the, umm, asp.
Again, I truly appreciate everyone's input.
-Ken
Ken Ismert wrote:
> OK, I've bookmarked a lot of stuff, and will be studying it for the
> next few days.
>
> Some final thoughts:
>
> Two things really grabbed me about Lisp:
> * Paul Graham's statement about using it to get around the
> statelessness of a web session. I am naive about web programming, but I
> know that this is a profound problem. ASP.NET has a solution to this,
> but it strikes me as ugly.
> * Pascal Costanza's comment about aspect-oriented programming under
> Lisp and MOP. I read an article about AspectJ in a Linux journal, and
> while I didn't fully understand it, it was easy to grasp how much
> effort it could save, compared to standard VB development. Microsoft,
> as far as I know, hasn't even explored the idea - they wouldn't
> know an aspect if it bit them on the, umm, asp.
Thanks for the flowers. :)
But actually Microsoft seems to notice AOP and already has added (or
plans to add, I don't know the current state) a few very minor AOPish
things to C#.
Pascal
Up spake Philip Haddad:
> I personally find Lisp more gratifying than Scheme, just because you
> can do everything in Lisp that you can in Scheme (as far as I know),
Going through SICP, I see lots nested procedure definitions:
(define (sum-of-squares x y)
(define (^2 x)
(* x x))
(+ (^2 x) (^2 y)))
In Lisp, this doesn't DWIM -- (^2) is defined outside (sos)
(defun sos (x y)
(defun ^2 (x)
(* x x))
(+ (^2 x) (^2 y)))
I'm looking at lexical scoping, right? The recent smug-scheme-weenies
thread observes that it is the default in Scheme but not CL. How
*should* I be translating the above to CL?
> Lisp is more challenging to learn especially if you coming
> from a crappy language like VB.
Well, C and POSIX sh[0]. But I *am* finding it easier to grasp the
fundamentals in Scheme[1], although I fully expect to switch to CL in a
few months.
[0] I got to explain closure to my boss yesterday via sh's "eval"
builtin. Yay!
[1] Partly due to the *excellent* courseware from MIT's 6.001, partly
due to the minimalist syntax and library.
--
-trent
Every program has at least one bug and can be shortened by at least one
line. By induction, every program can be reduced to one line which does
not work.
Trent Buck wrote:
> Up spake Philip Haddad:
>
>>I personally find Lisp more gratifying than Scheme, just because you
>>can do everything in Lisp that you can in Scheme (as far as I know),
>
>
> Going through SICP, I see lots nested procedure definitions:
>
> (define (sum-of-squares x y)
> (define (^2 x)
> (* x x))
> (+ (^2 x) (^2 y)))
>
> In Lisp, this doesn't DWIM -- (^2) is defined outside (sos)
>
> (defun sos (x y)
> (defun ^2 (x)
> (* x x))
> (+ (^2 x) (^2 y)))
>
> I'm looking at lexical scoping, right? The recent smug-scheme-weenies
> thread observes that it is the default in Scheme but not CL. How
> *should* I be translating the above to CL?
(defun sos (x y)
(labels ((^2 (x)
(* x x)))
(+ (^2 x) (^2 y))))
You can replace LABELS with FLET if the functions being defined are not
recursive.
-- MJF
(slowly catching up on my usenet reading after a week break)
Up spake M Jared Finder:
> > (define (sos x y)
> > (define (^2 x)
> > (* x x))
> > (+ (^2 x) (^2 y)))
>
> [becomes]
>
> (defun sos (x y)
> (labels ((^2 (x)
> (* x x)))
> (+ (^2 x) (^2 y))))
>
> You can replace LABELS with FLET if the functions being defined are not
> recursive.
Much obliged.
--
-trent
When the sysadmin answers the phone, politely say `sorry', hang up and
run awaaaaay! -- advice to users at Karolinska Institutet, 1993-1994
Actually, nested structure is allowed in CL, and is even a default
setting in CMUCL 18e.
This observes the same scope as presented in SICP as well, so you can
use CL for nested function definitions, what the compiler does is
compile the nested definition as if it a seperate function (which it
is).
--
Certum quod factum.
Philip Haddad
"Philip Haddad" <·············@gmail.com> writes:
> Actually, nested structure is allowed in CL,
> and is even a default setting in CMUCL 18e.
> This observes the same scope as presented in SICP as well,
> so you can use CL for nested function definitions, what the
> compiler does is compile the nested definition as if it
> a seperate function (which it is).
I'm not sure what you are trying to say here.
In Common Lisp, DEFUN always defines a new function
of the given name in the global environment.
DEFUN cannot create local functions.
hm, then why does this compile just fine?
(defun fact (n)
(defun iter (product counter)
(if (> counter n)
product
(iter (* counter product)
(+ counter 1))))
(iter 1 1))
That's translated into Lisp from p. 33 of SICP
--
Certum quod factum.
Philip Haddad
Ah, that's interesting, I wouldn't have thought of that. So I suppose
that means that CL does not really support block structure at all.
Bummer. I do find Scheme easy to catch on to after learning Lisp - it's
like Lisp for little kids. Because Scheme is not as powerful as Lisp, I
will always use Lisp over it.
So if (iter) gets defined every time fact is called, why doesn't the
function run noticably slower? And I guess that the nested defun in the
fact definition is still a global function (iter is global)? Because I
would have thought it was local to fact. Or would you really have to
use labels or flet to do that?
--
Certum quod factum.
Philip Haddad
start quoting Philip Haddad :
> Ah, that's interesting, I wouldn't have thought of that. So I suppose
> that means that CL does not really support block structure at all.
I'm not quite sure what you mean.
Lisp supports block structure just fine; you just have to use the right
calls. In that sense, it's defun that's atypical, not flet/labels.
defun modifies the global definition of iter; flet/labels shadow it. If you
want block structure, just don't use defun. What kind of structure were you
looking for that flet/labels don't support?
> (...)
> So if (iter) gets defined every time fact is called, why doesn't the
> function run noticably slower? And I guess that the nested defun in the
> fact definition is still a global function (iter is global)? Because I
> would have thought it was local to fact. Or would you really have to
> use labels or flet to do that?
>
A sufficiently smart compiler (or simply one that macroexpands defun to a
lambda, such as SBCL) might cache the results of compiling iter, so
repeating the definition wouldn't be nearly as slow as you'd think.
In any case, what are you comparing against?
Yes, though; for local functions, use flet, labels or lambda.
Trent Buck <·········@tznvy.pbz> writes:
> Going through SICP, I see lots nested procedure definitions:
>
> (define (sum-of-squares x y)
> (define (^2 x)
> (* x x))
> (+ (^2 x) (^2 y)))
>
> In Lisp, this doesn't DWIM -- (^2) is defined outside (sos)
>
> (defun sos (x y)
> (defun ^2 (x)
> (* x x))
> (+ (^2 x) (^2 y)))
>
> I'm looking at lexical scoping, right? The recent smug-scheme-weenies
> thread observes that it is the default in Scheme but not CL.
> How *should* I be translating the above to CL?
No. Common Lisp uses lexical scoping (for variables) unless you do
something special. DEFUN always defines functions globally.
For local functions in Lisp, use FLET or LABELS.
Here's the answer to the problem you are working on now:
(defun sos (x y)
(flet ((^2 (x)
(expt x 2)))
(+ (^2 x) (^2 y))))
By the way, when you get a little further, you are also probably
about to confuse yourself over the fact that in Lisp, names of
functions and variables are seperate. So you can't put a variable
in the CAR of a form, bind a function to that variable, and expect
it to be called. You have to put the name of a function in the CAR.
You're going to need to know about FUNCALL, and about FUNCTION,
which is related to QUOTE. Also note that this means you can have
a variable with the same name as a function, at the same time.
And when you get around to functions that close over variables,
please see LAMBDA (for creating an anonymous function object
that can be passed around).
Up spake Christopher C. Stacy:
> No. Common Lisp uses lexical scoping (for variables) unless you do
> something special. DEFUN always defines functions globally.
> For local functions in Lisp, use FLET or LABELS.
Righto.
> Here's the answer to the problem you are working on now:
I'm actually a good deal deeper than that. I picked that example
because it doesn't conflate the question at hand with other stuff.
> By the way, when you get a little further, you are also probably
> about to confuse yourself over the fact that in Lisp, names of
> functions and variables are seperate. [...] You're going to need to
> know about FUNCALL, and about FUNCTION, which is related to QUOTE.
Thanks, Graham explains that in detail in ACL.
--
-trent
"Don't iron, don't put in a triangle, don't put in an oval."
Is there a translation table for the washing tag on clothing?